🌌 AI 科普系列

  1. 概念篇：从 LLM、Prompt 到 Agent
  2. 工具篇：从聊天框走向本地工作流 ← 当前页

网页聊天非常适合问答、写作和临时分析，但当任务涉及几十个本地文件、反复运行命令或持续几小时的修改时，只在输入框里复制粘贴就会变得低效。

本地 AI 工具解决的关键问题，不是把聊天窗口换一种皮肤，而是让 Agent 在明确的权限边界内直接读取工作区、修改文件、调用终端，并根据测试结果继续迭代。产物落在普通文件和 Git 仓库里，也更容易审阅、回滚、迁移工具和长期维护。

不过，“能直接操作电脑”同时意味着风险升级。一个好用的 Agent 工作流必须同时具备三样东西：足够的上下文、恰当的工具，以及可恢复的权限控制。

先分清模型与工具

模型负责理解和生成，Agent 工具负责把模型接到真实环境中。一次本地任务大致经过：

用户目标
  ↓
Agent 工具：整理上下文、规划步骤、申请权限
  ↓
模型：判断下一步应该做什么
  ↓
文件 / 终端 / 搜索 / MCP 等工具执行
  ↓
结果返回模型，继续判断，直到完成或需要人工决策

因此，同一个模型放进不同工具里，表现可能明显不同。系统提示、文件检索、可用工具、上下文压缩、权限策略和错误恢复都会影响最终完成率。

反过来，同一个 Agent 工具更换模型后也不一定完全兼容。即使某个 API 宣称兼容 OpenAI 或 Anthropic 格式，工具调用、缓存、思考参数、上下文长度和错误处理仍可能存在差异。把“工具外壳”和“底层模型”分开评估，才能知道问题究竟出在哪里。

Web、CLI、IDE 与桌面端

它们并不是能力由低到高的固定阶梯，而是面向不同使用习惯的入口。

形态 优势 更适合 主要代价
Web 聊天 打开即用，适合上传资料与临时问答 写作、研究、轻量分析 本地工程上下文需要手动提供
CLI 启动快、可脚本化、贴近终端与文件系统 开发、运维、批处理、远程服务器 需要熟悉命令行和权限提示
IDE 代码、Diff、诊断和 Agent 同屏 边写边改、调试、代码审查 界面复杂，容易被自动补全干扰
桌面 Agent 多任务、跨工作区、后台执行和可视化审阅 长任务、并行任务、非纯代码工作 权限范围更广，需要更谨慎配置

选择入口时，不必追求“最专业”的形态。经常在终端工作的人会偏爱 CLI；需要逐行理解改动的人更适合 IDE；同时管理多个长任务时，桌面 Agent 的任务列表和后台运行更直观。

CLI：最短路径接入本地环境

CLI 没有复杂界面，却天然靠近源码、Git、编译器和自动化脚本。它既能交互式工作，也能在管道、CI 或定时任务中以非交互模式运行。

Claude Code

Claude Code 是 Anthropic 的编程 Agent。它可以读取项目、编辑文件、运行命令、连接 MCP，并在终端、IDE 和桌面环境中延续工作流。

Claude Code 默认使用 Anthropic 服务，也支持 Amazon Bedrock、Google Vertex AI 和企业 LLM Gateway。部分第三方模型厂商还提供面向 Claude Code 的适配方式，例如：

这些适配依赖服务商实现，不能据此推断所有 Claude Code 功能都与原生 Claude 模型完全一致。模型名、环境变量与套餐规则也可能更新，应以对应服务商文档为准。

Codex CLI

Codex 是 OpenAI 的编程 Agent，可以在终端、IDE 和 ChatGPT/Codex 应用中使用。CLI 适合直接在仓库中分析、实现、测试和审查改动；桌面入口则更适合管理多个任务与后台工作。

Codex 的重点不只是生成代码，而是围绕“读仓库—修改—运行—验证—审阅”形成闭环。无论模型多强，提交前仍应查看 Diff 并运行项目自己的测试。

Antigravity CLI

Antigravity 是 Google 的 Agent-first 开发平台。Antigravity CLI 与 Antigravity 2.0 桌面应用共享 Agent 架构，支持异步任务、Skill、Hook、子 Agent 和插件等工作流。

这里有一个容易混淆的时间点：Google 已在 2026 年将面向个人用户的终端体验从 Gemini CLI 迁移到 Antigravity CLI。Gemini CLI 仍有开源仓库，并继续服务部分企业许可和 API Key 场景，但个人用户选择新工具时应先查看 Google 的迁移公告，不要照搬旧教程的登录和额度说明。

其他 CLI

Kimi Code 等厂商工具，以及 OpenCode、Cursor CLI 等第三方项目，也提供终端式 Agent 体验。选择时至少确认：

  • 项目是否由模型厂商官方维护；
  • 支持哪些操作系统、模型与认证方式；
  • 是否能限制目录、命令和网络权限；
  • 会把哪些代码、日志与遥测发送到云端；
  • 会话、配置和修改结果能否导出或迁移。

名字里带某个模型，不代表就是该厂商官方项目。安装前应核对官网、仓库组织、发布签名和更新记录。

IDE：把 Agent 放进编辑与审查界面

IDE 形态的优势不是“模型一定更聪明”，而是上下文就在眼前：代码跳转、错误诊断、终端、版本控制和 Diff 审阅可以放在同一个窗口。

VS Code 与 GitHub Copilot

Visual Studio Code 是大量 AI 编辑器与扩展的基础。安装 GitHub Copilot 后，可以使用补全、聊天、编辑和 Agent 工作流。

它适合不想迁移编辑器、希望在既有 VS Code 插件和快捷键体系中逐步加入 AI 的用户。企业使用时还要检查组织策略、仓库权限和代码数据处理条款。

Cursor

Cursor 是以 AI 为核心体验的代码编辑器。除了多行补全，它的 Agent 可以搜索代码库、跨文件修改、运行终端命令并根据错误继续修复；Ask 或只读模式则更适合理解代码和制定计划。

Cursor 的价值在于把模型选择、代码库检索、Diff 和 Agent 工具整合得较紧密。代价是需要迁移或同步原有编辑器配置，并理解它自己的套餐与隐私选项。

Windsurf

Windsurf Editor 同样采用 VS Code 类编辑体验，强调代码库上下文、连续的 Agent 操作和编辑器内协作。它与 Cursor 的功能边界会持续变化，不必只看发布会演示；用自己的仓库试一轮“理解—修改—测试—回滚”，更容易判断谁适合自己。

Antigravity IDE

Antigravity IDE 是 Google Antigravity 平台中的完整 Agent IDE，与 CLI 和桌面端共享工作流。它体现了一个越来越明显的趋势：IDE 不再只有一个聊天侧栏，而是逐渐成为管理本地 Agent、任务产物和后台执行的控制台。

许多现代 AI IDE 建立在 VS Code OSS、Electron、Chromium、Node.js 等开源项目之上。这个技术栈让新工具可以快速继承编辑器生态，也意味着界面相似不等于 Agent 架构、模型能力和数据策略相同。

桌面 Agent：管理任务，而不只是编辑文件

CLI 围绕一次终端会话，IDE 围绕当前代码窗口，桌面 Agent 则更像一个任务控制台。

  • Codex 可在 ChatGPT/Codex 应用中管理工作区、后台任务和多 Agent 工作流，并与终端、IDE 入口衔接。
  • Antigravity 2.0 面向跨工作区和多 Agent 管理，CLI 与桌面端共享底层 Agent 架构。
  • ChatGPT 桌面版 更偏通用助手，可围绕文件、截图、语音和桌面内容展开对话；它与具备完整仓库执行闭环的编程 Agent 侧重点不同。

桌面应用不一定比 CLI 更强，但更适合展示任务状态、审阅产物、恢复历史会话和同时跟踪多项工作。

MCP：给 Agent 接上外部工具

MCP 为 AI 应用连接数据与工具提供通用协议。启用 MCP Server 后，Agent 可能获得读取设计稿、查询数据库、操作浏览器、访问工单系统或调用专业软件的能力。

以“根据设计稿修改网页”为例，工作流可能是：

  1. 通过设计工具的 MCP 读取页面结构与素材；
  2. Agent 在本地仓库中找到对应组件；
  3. 修改 HTML、CSS 或前端代码；
  4. 启动本地服务，并用浏览器工具截图验证；
  5. 根据视觉差异继续调整；
  6. 最后由人查看 Diff、页面和测试结果。

MCP 解决的是接入问题，不会自动解决信任问题。添加一个 Server 前要看清：

  • 它能读取和修改什么；
  • 凭证保存在本地还是发送给第三方；
  • 工具调用是否需要确认；
  • 能否限制到测试账号、只读数据库或特定目录；
  • 项目停止使用后如何撤销令牌。

Skill、项目指令与自动化

如果每次任务都要重复说明“先读哪些文档、如何运行测试、代码风格是什么、完成后输出什么”，可以把这些规则放入项目指令或 Skill。

三者可这样区分：

  • 项目指令：当前仓库始终适用的规则，例如目录结构、测试命令和禁改区域；
  • Skill：某类任务按需加载的完整方法，例如发布博客、生成演示文稿或执行数据库迁移；
  • 自动化：按时间或事件触发的任务，例如每日检查失败构建、每周整理依赖更新。

规则写得越多不一定越好。应优先保留能影响决策和验收的项目特有信息，并把脚本、模板和参考资料按需加载。

一套可靠的本地 Agent 工作流

1. 先建立可恢复点

在允许 Agent 修改文件前，确认项目已进入 Git 或其他版本控制系统，并检查当前未提交改动。用户自己的修改应保留，AI 不能用重置、覆盖或大范围格式化把它们抹掉。

对非代码目录，也可以先备份或复制到专用工作区。可恢复性比“禁止所有错误”更现实。

2. 给目标，也给验收方式

不要只说“把项目优化一下”。说明目标文件、用户场景、不能改变的行为以及完成后应运行的检查。例如：

修复登录页在窄屏下按钮溢出的问题。
不要改变桌面布局和后端接口。
完成后运行前端测试，并给出修改文件、测试结果和仍未验证项。

3. 探索与修改分开

面对陌生仓库或高风险任务，先使用只读/计划模式，让 Agent 解释现状、定位文件并提出方案。确认方向后再开放写权限，可以显著降低“一开始就改错层”的概率。

4. 权限逐级开放

一个实用的顺序是：

只读文件
  → 写入指定工作区
  → 运行普通测试命令
  → 访问网络或外部服务
  → 发布、删除、付款、生产变更（始终人工确认）

不要为了少点几次确认就全局跳过权限检查。来自网页、Issue、邮件、依赖包和文档的内容都可能包含提示词注入；它们应被当作不可信数据，而不是高优先级指令。

5. 用机器反馈约束模型

让 Agent 运行格式检查、类型检查、单元测试、构建和本地预览。机器反馈不能证明需求完全正确，却能尽早发现语法错误、类型问题和行为回归。

测试失败时，不只看 Agent 的总结，还要保留真实命令和输出。测试通过时，也要确认它没有删除测试、缩小覆盖范围或悄悄改变验收标准。

6. 人工审阅最终产物

至少检查：

  • Diff 是否只包含预期文件；
  • 是否混入密钥、个人数据或生成垃圾；
  • 新依赖是否必要、来源是否可信；
  • 测试是否真的运行且覆盖关键路径；
  • 文案中的数字、引用和链接是否可验证；
  • 是否存在未经同意的外部发布或数据写入。

AI 可以承担大量实现工作，但“最终批准”仍应由对结果负责的人完成。

如何选择工具

可以从工作方式出发，而不是从热度出发：

你的主要需求 优先尝试
临时问答、总结文件、处理截图 Web 或通用桌面助手
习惯终端，希望脚本化和远程使用 Codex CLI、Claude Code、Antigravity CLI 等
需要边写边看 Diff 和诊断 VS Code + Copilot、Cursor、Windsurf、Antigravity IDE
同时管理多个长任务或工作区 Codex、Antigravity 2.0 等桌面 Agent
敏感数据不能离开设备 支持本地模型与严格网络隔离的工具
团队需要合规、审计和统一计费 提供企业身份、网关、策略和日志的方案

真正评测时，使用同一份真实任务和验收标准，记录完成率、人工干预次数、耗时、费用与最终 Diff 质量。只比较第一次回答的“惊艳程度”，很容易选到会演示、不会收尾的工具。

小结

CLI、IDE 和桌面端只是入口。决定体验上限的是模型、上下文管理、工具链和 Agent 架构；决定能否放心投入真实工作的，则是权限边界、版本控制、测试和人工审阅。

从最小任务开始：给 Agent 一个受版本控制的小项目，让它先只读分析，再完成一次范围明确的修改，最后亲自检查 Diff 和测试结果。跑通这个闭环，比收集几十个工具名称更有价值。

回到基础概念：概念篇：从 LLM、Prompt 到 Agent。