AI 编码代理和普通聊天机器人的根本区别在于一个持续执行的循环。聊天机器人给你一个答案就结束了，代理会反复执行四步：

• Read ：读取代码库中的相关文件
• Reason ：推理完成目标所需的逻辑步骤
• Act ：编辑文件、运行命令、调用外部工具
• Evaluate ：检查结果，判断是否需要继续

这个循环不断重复，直到任务完成或交还控制权。关键差别在于，代理做的是"问→做→检查→再做"的闭环，不是一次性的"问→答"。

代理的核心循环是一样的，但代理运行的环境决定了你如何与之交互。同一个代理在不同环境下会呈现不同的交互模式。这就是四种工作流的由来。

IDE 代理直接嵌入代码编辑器，在你写代码的同时给出行内建议、显示 diff、让你一键接受或拒绝。

这类工具有两种形态：

AI Native IDE ：从零围绕 AI 构建的编辑器，代表有 Cursor、Windsurf、Kiro。Kiro 支持 spec-driven 模式，你先描述需求，代理独立完成。Cursor 的 Cloud Agents 还能在后台跑长时间任务。

IDE 插件 ：在现有编辑器上增加 AI 能力，如 GitHub Copilot 插件、VS Code 的 Claude Code 扩展、Gemini Code Assist。插件通常更适合"先定位文件再修改"的交互式工作流。

IDE 代理的优势是实时反馈，你在写代码时它就给出建议，就像有个搭档坐在旁边看。缺点是 cloud-backed 的 IDE 代理会把你的代码发到外部服务器做推理。如果公司政策不允许代码离开本地，可以看看 Continue 这类支持本地模型的工具。

Claude Code 的 IDE 模式 ：Claude Code 有 VS Code 和 JetBrains 的原生插件。安装了扩展后可以在编辑器里直接启动 Claude Code 会话。不过我日常主要用终端模式，IDE 插件只在需要时打开。

终端代理运行在 shell 中。你描述任务，代理读取文件、提出修改、执行命令，每步都由你确认后才继续。这是我最常用的模式。

一个是适合复杂跨文件修改。你可以让代理从整个项目出发，追踪 import 链和关联文件，在多个模块之间协调修改。相比 IDE 代理的"打开文件→修改→保存"工作流，终端代理可以一次性理解整个项目的结构。我们经常说"让 AI 理解上下文"，终端模式天然就有全局上下文，因为它能访问整个文件系统和命令行。

另一个是分步确认模型。代理每做完一步都会停下来问你是否满意，让你始终保持控制。我日常的感受是，这种交互既保持了控制感，又让代理干掉了大部分重复劳动。你不用自己记住每个改动的细节，只需要做决策：这个改法对不对，下一步往哪个方向。在 Claude Code 里可以开启 auto mode 减少确认次数，但我通常保持手动模式，因为编程中很多决策不能跳过。

终端模式还有一些高级用法：可以把日志 pipe 给代理分析，与其他 CLI 工具链式组合，或者嵌入自动化脚本。原因是终端代理运行在 shell 中，和现有开发工作流的集成度最高。

终端模式的代表工具包括 Claude Code、Aider、Gemini CLI、OpenCode、Codex CLI。有些代理还能通过 Ollama 连接本地模型，适合不能把代码外发的场景。

PR 代理和前两种完全不同，它不和你实时交互，而是异步工作。通常在 PR 打开或更新时自动触发，跑完后留下审查意见，你稍后回来查看。

PR 代理操作的是团队可见的共享分支，审查结果需要人来决定是否采纳。它的角色是合入前的安全网，而不是编码时能指挥的工具。

典型工作流：你开 PR，代理过一会儿会发布审查意见，你像处理同事的 review 一样接受、修改或驳回。

主要运行在 GitHub、GitLab、Bitbucket 上。代表工具包括 CodeRabbit、GitHub Copilot Code Review。很多团队会统一管控 AI 审查工具的权限，隐私决策通常在组织层面而非个人层面。

Claude Code 的 PR 模式 ：Anthropic 提供 Code Review 托管服务，也开源了 Claude Code GitHub Actions 让团队在自己的 CI 流程中运行。我没有在生产项目中用过这个功能，但原理是清晰的：配置后每个 PR 自动触发代码审查。

云代理的自主性最高。你描述任务，它在远程环境里独立干活，之后返回分支、PR 或原型等你审查。

这让云代理很适合用于新项目原型搭建或耗时较长的任务。你可以通过 Slack、工单系统或网页来启动任务，不用一直守在屏幕前。

代表工具包括 Devin、Claude Code on the web、Codex web、Cursor Cloud Agents。

但自主性高也意味着实时控制少，代码跑在远程基础设施上，不在你本地。所以云代理最适合边界清晰、产出容易审查的任务，比如分支、PR、原型。云生成的代码人工审查更加重要，一个重要原则是没审查过的代码就不要推送。

Claude Code 的云模式 ：Claude Code on the web 运行在 Anthropic 管理的云基础设施上。还可以在 Slack 里用 @Claude 分配任务，它会启动云端的 Claude Code 会话。我没有实际用过云模式，但它的定位很清晰：适合那些你不想守在屏幕前盯着看的长任务。

原文特意指出，有三款工具横跨全部四种工作流：

• Claude Code ：终端（CLI）、IDE（VS Code/JetBrains 插件）、云端（Claude Code on the web）、PR（Code Review + GitHub Actions）
• Cursor ：IDE（编辑器本体）、终端（Cursor CLI）、云端（Cloud Agents）、PR（Bugbot）
• GitHub Copilot ：IDE（Copilot 插件）、终端（Copilot CLI）、云端（Copilot cloud agent）、PR（Copilot code review）

这说明分类法描述的是交互模式，不是产品类别。同一款工具在不同场景下可以切换不同的角色。Claude Code 横跨四种模式跟它"全能"没关系，纯粹是它设计上就支持不同的入口：CLI、插件、云端、CI，每种入口对应一种交互模式。

原文还指出了几个常见陷阱。

不要假设一种代理能包打天下。 IDE 代理擅长交互式编辑，终端代理擅长大范围重构，PR 代理抓住合入前的问题，云代理搞定独立原型。按任务匹配模式比追求"最强"更有意义。

隐私合规要提前确认。 多数代理会把代码发送到外部服务器做推理。用之前查一下公司政策，必要时找本地模型方案。

AI 生成代码必须审查。 代理可能引入隐蔽的 bug、不完善的异常处理、或不符合团队惯例的写法。代理越自主，审查越重要。

AI 编码代理的四种交互模式（IDE、终端、PR、云）给出了一个选择框架：与其问哪个代理最强，不如问当前任务适合哪种模式。Claude Code 横跨全部四种模式是工具设计的结果，但从用户角度，更重要的是理解每种模式适合什么场景。工具会迭代，但交互模式的分类框架不会过时。