主流 Coding Agent 对比
本文是能力边界和选型方法，不是对任何产品的永久承诺。命令和具体开关以各产品官方文档为准。
本页属于 AI Harness 工程化专题，重点比较真实仓库中的能力与治理边界。
选型维度
| 维度 | 需要回答的问题 |
|---|---|
| 运行位置 | 终端、IDE、桌面应用还是远程工作区？ |
| 上下文 | 是否支持仓库规则、目录级规则和会话记忆？ |
| 扩展 | 是否支持 Skills、Plugins、Hooks、Subagents 和 MCP？ |
| 权限 | 能否限制目录、命令、网络和写操作？ |
| 协作 | 是否能保存轨迹、导出 diff、接入 CI？ |
| 模型 | 能否使用目标模型，是否支持 Tool Calls 或 Responses API？ |
能力矩阵
下表用于建立理解框架；具体版本请查看产品官方资料。
| 工具 | 常见入口 | 配置/规则 | 扩展重点 | 更适合 |
|---|---|---|---|---|
| Claude Code | CLI/终端 | CLAUDE.md | Skills、Hooks、Subagents、MCP | 终端驱动的复杂代码任务 |
| Codex | CLI/IDE | AGENTS.md 等 | MCP、Skills、任务隔离 | 受控的工程任务和代码修改 |
| Cursor | IDE | 项目规则 | Rules、MCP、Agent | IDE 内的交互式开发 |
| Trae | IDE | 项目规则 | Agent、MCP、工作流 | IDE 内的中文开发体验 |
| OpenCode | CLI/终端 | Agent 配置 | MCP、Plugins、Subagents | 可配置的终端工作流 |
| OpenClaw | Agent 平台 | 工作区配置 | Skills、Channels、Tools | 多通道 Agent 自动化 |
| DeepSeek Harness | CLI/Web | Profile、Workspace | Skills、MCP、扩展 | DeepSeek 驱动的代码协作 |
为什么需要 Harness
单个 Agent 工具往往解决“如何让模型修改代码”；Harness 解决的是更完整的交付闭环：
因此选型不应只看模型回答质量，还要观察：
- 是否能稳定恢复长任务；
- 工具和权限是否可控；
- 失败是否能被机器验证；
- 是否能在团队中统一规则；
- 升级后是否有回归任务集。
一个通用的项目规则文件
不同工具的文件名和加载规则可能不同，但内容可以抽象为同一份工程契约：
markdown
# Repository Contract
## Before editing
- Read the nearest package README and existing tests.
- Prefer the smallest change that satisfies the task.
## Verification
- Run the formatter for changed files.
- Run the narrowest relevant test first.
- Report commands and results; do not claim tests you did not run.
## Safety
- Never print secrets.
- Ask for approval before destructive or external write operations.
- Keep unrelated user changes intact.落地时应根据工具的规则层级拆分到仓库级、目录级和个人级配置，避免一个巨大文件污染所有任务。
接入真实仓库的六步闭环
选定产品后，不要从“让 Agent 扫描全部代码并自由修改”开始。先在一个可回滚的小任务上跑通：
- 固定工作区与基线：记录仓库根目录、分支、HEAD、未提交改动和任务范围，禁止覆盖用户已有改动。
- 建立上下文地图：先读仓库规则、目录说明、依赖清单、相关实现和既有测试，再按符号与调用链补充内容。
- 按阶段授权：探索阶段只读；实现阶段只写任务目录；验证阶段只运行项目声明的格式化、静态检查和测试命令。
- 设置审批点：安装依赖、访问外网、删除或移动文件、数据库迁移、提交、推送和部署必须单独批准。
- 窄验证后回归：先跑变更文件格式检查和最近测试，再跑受影响模块回归；CI 仍是合入门禁。
- 交付可复核证据：输出 diff、执行过的命令、退出码、失败与重试记录、未运行检查和残余风险。
真实仓库上下文建议分层加载：
| 层级 | 内容 | 何时加载 |
|---|---|---|
| L0 任务契约 | 目标、非目标、验收条件、允许修改路径 | 每轮保留 |
| L1 仓库约束 | 规则文件、构建方式、代码生成与提交约定 | 任务开始 |
| L2 相关代码 | 入口、依赖、相邻实现、测试与配置 | 检索命中后 |
| L3 执行观察 | diff、编译错误、测试结果、审查意见 | 产生后写入状态 |
上下文不是权限。即使模型看到了部署脚本，也不代表它可以部署；即使规则写着“不要推送”，真正的禁止仍应由工具策略执行。
审批与回归怎样做成机器规则
可以将工具按风险分成三组：
- 自动允许：仓库内读取、符号搜索、查看 diff、运行已登记的只读检查。
- 范围内允许：只修改任务 allowlist 中的文件，只执行参数受限的 formatter/test。
- 必须审批或禁用：删除、外部写入、凭证访问、包管理器安装、提交推送、生产部署和任意 Shell。
审批请求必须包含具体动作、参数、影响范围和回滚方式，不能只问“是否允许继续”。批准 git push 不等于批准部署，批准一个路径也不能扩展到整个仓库。
团队还应保留一组稳定回归任务，至少覆盖：精确定位、小范围修改、测试失败修复、越界写入拒绝、高风险动作暂停和中断恢复。升级模型、规则、Skill、MCP Server 或 Agent 产品后，在相同仓库快照上比较成功率、测试通过率、越权次数、人工介入率、耗时和成本。
个人与团队的推荐组合
个人探索
- 一个主力 Coding Agent；
- 一份简短仓库规则；
- 一个格式化和测试 Hook；
- 两到三个只读 MCP 工具。
团队交付
- 统一仓库规则和版本；
- 只允许经过审计的 Skills/MCP；
- Planner、Coder、Reviewer 分工；
- CI 作为最终门禁；
- 固定任务集做升级回归。
生产自动化
- 远程 Harness 服务和身份认证；
- 工具按角色授权；
- 所有写操作保留审批和审计；
- 失败可重试但有预算上限；
- 高风险动作必须人工确认。
练习
- 使用上表为一个 10 人 Go/Java 团队写一页选型记录。
- 将仓库规则拆成“模型建议”和“机器门禁”两列。
- 为同一个缺陷任务分别设计个人模式和团队模式的执行流程。