把这四件东西放在一张表里比较"哪个更强"，几乎必然得出错误结论——它们不是同一层的产品。一个是终端里的执行代理，一个是编辑器里的补全引擎，一个是 IDE 内的对话代理，一个是云端跑批的代理。形态不同，能做的事的边界就不同。
选型的正确问法不是"选哪个"，而是"这类任务该派给哪种形态"。下面按七条维度拆。
1. 定位：四种形态各自解决了什么
| 形态 | 代表 | 交互位置 | 核心能力 |
|---|---|---|---|
| 终端代理 | Codex | 终端 / CI | 读仓库、跑命令、批量改文件 |
| IDE 补全 | Copilot | 编辑器行内 | 光标处的下一段代码 |
| IDE 内代理 | Cursor | 编辑器侧栏 | 带上下文的多文件编辑 |
| 云端代理 | Copilot 的云端形态、Codex 的云端形态 | 网页 / PR | 隔离环境里跑完整任务，产出 PR |
四者的差别不在模型强弱，而在能不能执行与上下文从哪来。
- 补全引擎不"执行"，它预测你下一行要写什么，改动的范围是光标附近几十行。
- IDE 内代理能跨文件改，但视野受编辑器打开的文件与索引限制。
- 终端代理能跑命令，所以它能自己获得反馈（跑测试、看报错），代价是必须配沙箱与审批。
- 云端代理把这些放进隔离容器，产出是 PR 而不是本地改动，天生适合"扔进去、回头收"。
2. 上下文获取：读文件系统 vs 依赖编辑器
这是四者最本质的分野。
| 工具 | 上下文来源 | 优势 | 盲区 |
|---|---|---|---|
| 终端代理 | 文件系统 + 命令输出 | 能看到仓库全貌、依赖、构建产物 | 不知道你此刻在看哪一行 |
| IDE 补全 | 当前文件 + 相邻打开的文件 | 与你手上的编辑动作严格对齐 | 看不到未打开的模块 |
| IDE 内代理 | 编辑器索引 + 选中范围 | "改我选中的这段"非常准 | 索引之外的路径容易漏 |
| 云端代理 | 克隆下来的仓库 + 任务描述 | 干净环境、可复现 | 拿不到你本地的未提交状态 |
实践中的差异会以很具体的方式出现：
任务：把 utils/legacy.ts 里的 12 处调用点全改掉
- 终端代理：grep 出全部引用 → 逐个改 → 跑类型检查，一轮成型
- IDE 补全：只能一处一处跟着光标改，且不会主动去找调用点
- IDE 内代理：打开的文件里的能改，未打开的容易漏
- 云端代理：能改，但你本地那几个未提交的改动它看不见
未提交状态这一条值得单独记住：任何在隔离环境里跑的代理，拿到的都是某个提交，不是你工作区。让人在本地改到一半就扔给云端，回来必然冲突。
3. 执行能力：能不能跑命令，决定能不能自我纠错
| 能力 | 终端代理 | IDE 补全 | IDE 内代理 | 云端代理 |
|---|---|---|---|---|
| 跑测试/构建 | 是 | 否 | 部分（受终端集成限制） | 是 |
| 跨文件批量改 | 是 | 否 | 是 | 是 |
| 读命令报错并重试 | 是 | 否 | 部分 | 是 |
| 访问网络 | 由沙箱开关决定 | 否 | 由 IDE 决定 | 通常受限 |
| 产出可评审的单一 diff | 是 | 否 | 是 | 是（PR） |
"能跑命令"这件事的价值不是省一次手动执行，而是形成闭环：改 → 跑 → 读报错 → 再改。没有这个环，任何错误都得靠人转述，而人转述时必然丢信息。
# 有闭环：自己发现类型错误并修
$ codex exec "运行 tsc --noEmit，修掉报告的错误，不要改 tsconfig"
补全类工具没有这个环，所以它给的代码"看起来对"就够了——验证的责任完全在人这边。
4. 审批与沙箱：谁来兜底
| 模型 | 典型形态 | 默认信任级别 |
|---|---|---|
| 每次确认 | 终端代理的保守档 | 低，逐条问 |
| 自动 + 沙箱边界 | 终端代理的常用档 | 中，越界才问 |
| 全自动 | CI / 容器内 | 由容器兜底 |
| 无审批（建议即应用） | IDE 补全、内联改写 | 由"你必须按 Tab"兜底 |
补全类工具的安全模型很朴素：它不执行，你按了 Tab 才生效。风险落在"手快接受了一段错的代码"，可控。
代理类工具的风险面完全不同：它能删文件、能改配置、能跑 rm。所以沙箱与审批不是可选项，而是这类工具的一部分。
# 终端代理的一个保守起点
approval_policy = "on-request" # 越界或失败才问
sandbox_mode = "workspace-write" # 只能写工作区
判断标准：这次运行有没有人在旁边看着。有 → 自动档；没有 → 必须有容器或一次性目录兜底。
5. 并行与后台：一次能做几件事
| 能力 | 说明 | 实际影响 |
|---|---|---|
| 单会话串行 | 补全类工具天然如此 | 只能跟着人走 |
| 本地并行会话 | 终端代理可开多个工作副本 | 适合互不相干的模块 |
| 云端并行任务 | 每个任务一个隔离环境 | 适合"十个独立小修"批量处理 |
| 后台长任务 | 交给 CI 或定时器 | 人不占用 |
能并行的前提是任务之间不共享文件。两个代理同改一个文件，后写的覆盖先写的，且不会有任何报错——这是多工具协作里最贵的坑。
安全的并行划分方式按目录切：
# 两个互斥范围，可以同时跑
agent --dir packages/api "修 lint"
agent --dir packages/web "修 lint"
# 同一个目录开两个 = 互相覆盖
6. 成本结构：按 token 还是按席位
| 计费维度 | 谁按这个算 | 成本随什么增长 | 管理要点 |
|---|---|---|---|
| 按 token | 终端代理、云端代理、API 直连 | 读的文件量、跑的命令量、重试次数 | 控制上下文范围、限制重试、压缩输出 |
| 按席位 | IDE 补全、IDE 内代理 | 人数 | 席位回收、按需开通 |
| 混合 | 多数企业采购形态 | 人数 + 用量 | 分清哪部分可预测、哪部分会失控 |
具体单价按当前版本核对，不作选型依据。真正影响预算的是增长曲线形状：
- 按席位：成本可预测，随团队规模线性增长。
- 按 token：成本不可预测，一次"让它把整个仓库读一遍"就能顶掉一个月的席位费。
所以按 token 的工具必须有使用纪律：明确"允许读哪些目录"、避免无边界重试、把长输出落盘而不是全部回灌上下文。
7. 团队协作与审计
| 需求 | 补全工具 | 终端代理 | 云端代理 |
|---|---|---|---|
| 每笔改动可追溯到人 | 靠 Git 提交 | 靠 Git 提交 + 会话日志 | PR 自带记录 |
| 统一团队规则 | 有限（配置分散在各人 IDE） | 强（仓库内配置文件） | 强（仓库配置 + 平台策略） |
| 审计"AI 改了什么" | 难，混在人写的代码里 | 可（分组提交 + diff 落盘） | 易（独立 PR） |
| 新人上手成本 | 最低 | 中 | 低 |
审计的可行做法只有一个：让 AI 的产出走独立提交或独立 PR。混在同一次提交里，事后无法分离，任何审计要求都会变成"翻聊天记录"。
git commit -m "fix(lint): 类型错误（agent 产出，未人工改动）"
git commit -m "refactor: 人工调整命名"
8. 选型：按任务类型分派
| 任务类型 | 首选形态 | 理由 |
|---|---|---|
| 边写边补 | IDE 补全 | 与人手节奏对齐，零上下文切换 |
| 改一个函数/一个组件 | IDE 内代理 | 选中范围明确，反馈即时 |
| 跨 10 个文件的重命名、接口迁移 | 终端代理 | 需要 grep + 批量改 + 跑校验 |
| 修一整类静态检查错误 | 终端代理或云端 | 步骤固定，可脚本化 |
| 十个互不相干的小修 | 云端并行 | 隔离环境，互不干扰 |
| 依赖升级 + 测试修复 | 终端代理（容器内） | 需要装依赖、跑测试，动作重 |
| 读代码、出方案、写文档 | 终端代理（只读沙箱） | 需要仓库全貌，不需要写权限 |
最后一行别忘：只读任务用只读沙箱，它只要结论，写权限是纯风险。
9. 组合使用的现实做法
真实团队不会只用一种。稳定的组合是：
- 补全留在 IDE，处理每天 80% 的逐行输入；
- 批量改造交给终端代理，一次一个可验收的小目标；
- 无人值守的重复活交给云端或 CI；
- IDE 内代理只用于"改我选中的这段"，不做跨仓库重构。
三条纪律让组合不打架：
- 同一时刻，一个文件只有一个写入者。 开代理前先关掉另一个工具的自动改写。
- 工作区干净再派活。 有未提交改动时，diff 分不清谁改的。
- 产出走独立分支。 谁跑的、跑了什么，分支名和提交信息里写清楚。
10. 排错：五种混用后的典型故障
| 现象 | 原因 | 处理 |
|---|---|---|
| 改动莫名消失 | 两个工具同改一个文件，后写覆盖 | 分目录并行，或串行；关掉重复的自动改写 |
| 补全工具改出来的重构一塌糊涂 | 把补全当重构工具用，它只预测下一行 | 重构交终端代理，补全只管局部 |
| 云端 PR 与本地冲突 | 云端基于某提交，本地有未提交改动 | 派活前先提交或 stash |
| 成本突然翻倍 | 按 token 的工具反复重试或读了整个仓库 | 限定目录、限制重试、长输出落盘 |
| 审计时说不清哪段是 AI 写的 | 混在同一次提交 | 分组提交，AI 产出单独 commit/PR |
第一行最隐蔽：覆盖发生时没有任何报错，只有事后 git log 里少了一段。
11. 边界：工具替代不了的东西
| 需求 | 该靠什么 |
|---|---|
| 需求本身是否成立 | 人；工具只回答"怎么写"，不回答"该不该写" |
| 架构取舍 | 人；代理能给候选方案，不能担责任 |
| 跨团队接口约定 | 人；写进仓库约定文件，别留在聊天里 |
| 上线前的风险判断 | 人；沙箱能限制破坏面，不能判断业务风险 |
| 长期可维护性 | 评审 + 规则文件，不是模型能力 |
一句话：四种形态都在压缩"写"的成本，没有一种在压缩"判断"的成本。 写变便宜之后，判断反而成了瓶颈——这也是为什么团队真正需要先建的是评审标准，而不是工具清单。
12. 自测
- 终端代理与 IDE 内代理在上下文来源上的根本差异是什么？
- 为什么"能跑命令"的价值不止是省一次手动执行？
- 云端代理拿不到的本地状态是什么，会引发什么后果？
- 按 token 计费的成本曲线为什么不可预测，怎么约束？
- 两个代理同改一个文件会发生什么，如何避免？
- 为什么说工具压缩的是"写"的成本而不是"判断"的成本？