Codex、Claude Code、Cursor、Kimi Code：从用户体验反推 Harness

1. 先问“用户要完成什么”

Coding Agent 不是单一功能。局部代码补全、跨文件重构、仓库级 Bug 修复、长时间无人值守任务和研究+实现，分别需要不同的上下文、权限、交互和恢复能力。

公平比较的第一步是固定任务合同：同一仓库、同一提交、同一测试、同一网络权限和同一时间预算。否则比较的可能是环境差异，而不是工具差异。

2. 五个观察维度

上下文

观察工具如何获得当前文件、相关文件、索引、终端输出、规则和历史任务；是否允许用户控制上下文；长上下文是否真的带来相关证据，而不是把噪声一并送入模型。

Tool Call

观察工具是直接执行命令、通过 IDE API 操作，还是经过权限网关；参数错误、超时、取消和部分成功如何展示；危险动作能否预览和审批。

任务规划

观察它是否先探索再修改，是否有明确计划，测试失败后是否重规划，能否并行，以及用户中途能否 Steer。

编辑体验

局部编辑需要低延迟、精确 diff 和快速接受/拒绝；跨文件任务需要工作区状态、冲突处理和批量验证。优秀的编辑体验不是让模型改得更多，而是让人能理解、控制和撤销变化。

失败恢复

观察是否保存检查点、是否能从失败步骤继续、是否会重复外部副作用、是否展示失败原因和验证证据。一次任务最终成功但中间反复破坏工作区，不算稳定。

3. 四个工具的分析画像

以下是 Harness 视角下的工作假设，应通过同一任务集验证，不能当作版本无关的绝对结论。

• Claude Code：更适合从 agentic control plane 观察，终端、规则、Hooks 和工具执行边界是重点；优势常体现在控制面迭代和命令式长任务流程。
• Codex：适合从 Agent Loop、代码状态、任务隔离和交付架构观察；重点是如何把探索、编辑、测试和验证组织成可恢复循环。
• Cursor：IDE-first，编辑器上下文、索引、局部 diff 和人机协同是核心；适合高频局部修改，也要观察 Agent 模式跨文件后的控制能力。
• Kimi Code：适合观察长上下文、中文任务、并行协作和推理服务优化；长上下文的价值最终要由相关证据召回、成本和任务成功率证明。

所谓“谁更强”必须改写成“在什么任务、什么权限、什么验收条件下谁更合适”。

4. 以一个 Bug 修复任务为例

先要求工具只读探索并输出任务合同；再允许局部编辑；修改后必须运行测试并展示 diff；测试失败时保存失败原因并重规划；最终交付 patch、测试命令、结果和未解决风险。

这个流程能把产品差异映射到 Harness：上下文影响探索，Tool Gateway 影响权限，Loop 影响重规划，编辑器影响确认成本，Verifier 影响完成可信度。

5. OpenClaw、Kimi-Swarm 与相邻框架怎么说

OpenClaw 可以从 personal、extension、gateway 角度分析，强项是连接个人工作流和扩展能力，同时要关注可维护性、权限和长期状态。

Kimi-Swarm 的价值可以从横向扩展看：任务切割、同类任务并行、交叉验证和证据聚合。但并发不是免费能力，协调、取消、背压、结果冲突和成本都必须进入评测。

不要把产品、Agent Framework 和 Harness 混为一谈：产品提供用户体验，Framework 提供运行抽象，Harness 提供稳定完成任务所需的工程控制。

6. 使用者的选择决策

• 局部补全和快速编辑：优先看 IDE 上下文、diff 和接受/撤销成本。
• 仓库级修复：优先看探索、测试、验证和恢复。
• 长程无人值守：优先看 Session、Sandbox、检查点、预算和 HITL。
• 研究+并行实现：优先看多 Agent 协议、证据图和合并验证。

7. 学习者练习

为四类任务建立任务卡，分别记录首个有效修改时间、人工接受率、测试通过率、Tool 错误、恢复次数、Token、延迟和最终交付质量。写结论时必须附证据和适用边界。