同一个模型，Claude Code、Codex、opencode 到底差在哪
不少人挑命令行编程助手时只看背后接的是哪个模型，实际用下来却发现同一个模型在不同工具里表现差距很大。差别主要不在模型，而在模型外面那层工程，也就是 harness。这篇文章拆解 harness 的几个关键分层：认知循环、沙盒与危险操作门控、上下文压缩、记忆系统、免确认模式下的自动判定，并给出一份可自己动手做的对比清单和踩坑提醒。
选命令行编程助手时，很多人第一眼看的是"它接的是哪个模型"。但真正用起来会发现：同一个模型，在不同工具里干活的风格、可靠性、长任务表现能差出一大截——有的会先读文件再动手，有的上来就猜着改；有的跑到三十轮还很清醒，有的十几轮就开始重复劳动。
差异的来源，除了模型本身，还有一层常被忽略的东西：把模型 API 包装成一个能真正干活的 agent 的那整套工程。业内一般叫它 harness（可以理解为"承载层"或"脚手架"）。系统提示词只是其中很小的一块。
模型是引擎，harness 是整车
harness 指的是模型之外的所有工程决策：每一轮请求到底发什么内容、工具怎么定义和解析、返回结果怎么裁剪、上下文快满了怎么办、哪些操作要拦下来问人、记忆存在哪、怎么防止它把自己坑死。同一台发动机装进不同的车，驾驶感受可以完全不同；反过来，harness 做得扎实的工具，配一个稍弱的模型也能完成大部分日常开发任务。
所以"这两款工具除了模型还有什么区别"这个问题，答案是：区别主要就在这一层，而且比模型的选择更影响日常体验。
harness 的几个关键分层
1. 认知循环：每一轮到底发什么
这是最核心也最难做好的部分。具体包括：
- 系统提示与工具清单如何组织，是常驻还是按需披露；
- 工具返回值怎么裁剪，比如一个大文件读进来是全文塞进去，还是只回相关片段、只回 diff；
- 什么时候要求模型先列计划再执行，什么时候允许直接动手；
- 工具调用失败后怎么重试、怎么把错误信息转成模型能理解并自我纠正的输入。
同样一句"修一下这个 bug"，不同工具的行动序列可能完全不同。这一层的差异，往往比换模型带来的差异还明显。
2. 约束设计：沙盒、门控与工具分级
工具能碰什么、不能碰什么，是设计出来的：
- 哪些命令属于危险操作（删除、强推、改 CI 配置、动系统目录），需要人工确认；
- 文件系统和网络是否隔离，改动是否放在独立的 worktree 或临时目录里，避免污染当前工作区；
- 工具是否分级，只读工具和写入工具是否区别对待；
- 模型看到的和用户看到的是否一致，事后能不能审计它到底执行了什么。
这一层做得粗糙，日常用起来要么处处要确认、非常烦，要么一次手滑就很疼。
3. 上下文压缩与信息分层
长任务必然撑爆上下文窗口。各家的处理策略差异很大：什么时候触发压缩、压缩哪一段、局部压还是整体重来、不同来源的信息权威度怎么排序、技能和工具说明是全部常驻还是逐步披露。
这一层直接决定长任务后期会不会"忘事"、会不会把已经改过的东西再改一遍，也直接影响 token 消耗。
4. 记忆系统
大致分三层：项目级记忆（约定、常用命令、目录说明）、会话内记忆、跨会话持久记忆。差别在于粒度多细、能不能追溯来源、怎么避免旧记忆污染新任务。项目级记忆文件写得好，能显著减少重复解释；写得乱，反而会持续误导模型。
5. 权限模式与自动判定
在"免确认"的自动放行模式里，谁来判定一条命令危不危险？有的靠静态规则，有的会旁路调用一个分类模型做判断。这是各家差别极大的地方，也是出事故的主要来源。默认不要在放有密钥、生产配置或重要数据的机器上开免确认模式；需要时就换到容器、独立用户或一台专门的机器里跑。
内置提示词重要，但不是全部
容易出现的误解是把差异全归到"系统提示词写得好不好"。提示词确实影响说话风格和是否先给方案，但它随版本频繁调整，很难作为长期选型依据；而上面那些结构性设计——工具返回值怎么组织、上下文怎么压、危险操作怎么拦——才是难以短期抄走的部分。
自己动手做一次横向对比
别只看模型榜单，拿真实任务测一遍最靠谱。可以按下面这张表设计：
| 测试维度 | 怎么测 | 重点观察 |
|---|---|---|
| 小改动 | 改一个函数并补测试 | 是否先读代码、改动是否越界 |
| 跨文件重构 | 重命名一个被多处引用的接口 | 是否漏改、是否给出迁移说明 |
| 长任务 | 连续推进三十轮以上的需求 | 后期是否忘事、是否重复读同一文件 |
| 危险操作 | 明确要求删目录或强推分支 | 是否停下来确认、确认信息是否说清后果 |
| 上下文临界 | 塞入一个大文件后再追问早期需求 | 是否还能准确引用之前的内容 |
同时记录几个可量化指标：完成同一任务的 token 消耗、人工介入次数、出错后能否自我纠正、有没有在工作区留下垃圾文件、中断后能否接着恢复。
使用时的几点注意事项
- 版本迭代很快，任何具体功能点都会变化，选型结论有时效性，务必以官方最新文档为准。
- 低成本试错：先用一两周真实任务跑，再决定要不要把某个工具固化进日常流程。
- 隔离运行：免确认模式、批量重构这类场景，优先放在容器或专用环境中，主开发机上只做有限权限的操作。
- 注意数据边界：代码和上下文会发送到模型服务方，涉及私有代码或客户数据时，先确认内部合规要求。
- 长任务的稳定性：这类工具经常一跑就是几十分钟到几小时，还要持续调用 API。本地机器休眠、切换网络、Wi-Fi 抖动都可能中断会话。如果经常跑长任务，除了排查本地网络，也可以把它放到一台长期在线的机器上运行，比如整台 Mac mini 托管在机房、按月租用的独享远程 Mac，本地只负责编辑和查看结果。这只是可选方案之一，多数情况下先解决本地网络和电源策略就够了。
小结
模型是引擎，harness 是整车。评估这类工具时，比起问"它接的是哪个模型"，更值得问的是：它每一轮发什么、工具结果怎么裁剪、上下文满了怎么办、危险操作怎么拦、记忆存在哪。这些问题回答清楚了，选型基本就有了答案。
