Agent Harness Engineering 三重前沿实践：Codex、Claude Code、Cursor 如何让人类从编码者升为架构师

公众号名称：AI 启蒙小伙伴

作者名称：邵猛

发布时间：2026-05-09 07:50

OpenAI、Anthropic 和 Cursor 先后都发表了 Harness 相关文章，代表了当前 AI Agent 工程（Harness 设计）最前沿、最深入的实践总结。它们并非孤立的个案，而是共同勾勒出一个正在形成的工程范式：人类从直接编写代码，转向设计和维护让智能体可靠运转的”脚手架”（Harness）。

今天咱们就把三篇文章结合起来一起解读学习，Harness 这个 2026 年最值得学习的方向。

“Harness” 的本质：从工具到基础设施

三篇文章对 “Harness” 的理解在底层是相通的，但各有侧重：

OpenAI 将其定义为智能体优先的工程基础设施——不是辅助人类编码的工具，而是让智能体能够自主完成软件全生命周期的系统。他们的实验极端而彻底：从零开始、五个月内构建了一百万行代码的产品，没有一行人工编写的代码。人类工程师的角色被重新定义为”设计环境、明确意图、构建反馈回路”。

Anthropic 将其视为长时运行任务的编排架构。他们关注的是当 Agent 需要连续工作数小时时，如何避免**“上下文焦虑”和自我评估偏差**。核心方案是借鉴 GAN 思想，将生成与评估分离，形成多智能体协作的闭环。

Cursor 则将其看作持续演进的软件产品——和任何有野心的软件一样，需要愿景驱动、假设验证、A/B 测试和迭代优化。他们强调 Harness 不是一次性设计出来的，而是在模型能力演进中不断”做减法”和”做加法”的动态系统。

三者的共识是：Harness 的价值不在于让模型”更聪明”，而在于让模型在复杂、长时的任务中保持连贯、可靠和可验证。

三种架构模式的对比与互补

1. OpenAI：单智能体深度自治 + 环境工程

Harness engineering: leveraging Codex in an agent-first world

https://openai.com/index/harness-engineering/

OpenAI 和 Anthropic 对 Harness Engineering 不谋而合：从编码到驾驭 Agent，重构 AI Agent 时代软件工程范式

OpenAI 的方案可以概括为 **“一个超级智能体 + 极致环境设计”**。

单智能体（Codex） 驱动几乎所有工作：编码、测试、文档、CI 配置、代码审查、甚至合并 PR。
环境即契约：人类不审查每一行代码，而是通过架构约束（自定义 linter、结构测试、强制依赖方向）来确保代码质量。他们把”品味”编码成了可执行的规则。
渐进式信息披露：AGENTS.md 不是百科全书，而是”地图”（约 100 行），指向代码仓库中结构化的文档系统。这解决了上下文窗口稀缺的问题。

核心洞察：当代码完全由智能体生成时，优化目标必须从”人类可读”转向”智能体可读”。代码仓库本身就是唯一的真相来源——Google Docs、Slack 消息、人类头脑中的隐性知识对智能体而言”不存在”。

2. Anthropic：多智能体对抗 + 任务分解

Harness design for long-running application development

https://www.anthropic.com/engineering/harness-design-long-running-apps

一文看懂 Harness Engineering：OpenAI、Anthropic 们在谈什么，OpenClaw 如何用好 Harness 变得更强？

Claude Code 架构深度解读：Agent 系统的真正护城河不在模型，而在 Harness

Anthropic 的方案是 **“Planner-Generator-Evaluator” 三智能体架构**，灵感来自 GAN。

角色	职责	解决的问题
Planner	将一句话需求扩展为完整的产品规格	避免生成器”边做边想”导致范围不足
Generator	按 Sprint 逐个实现功能	控制复杂度，保持专注
Evaluator	用 Playwright 实际操作用户界面，按标准评分	解决自我评估偏差——生成器倾向于给自己的作品打高分

关键创新：

生成与评估分离：让独立的 Evaluator 保持怀疑态度，比让生成器自我批评更容易调优。
Sprint 合约：生成器和评估器在每个 Sprint 前协商”完成标准”，避免目标漂移。
上下文重置（Context Reset）：在 Sonnet 4.5 时代，模型会在上下文窗口接近极限时产生焦虑并提前收尾。通过结构化交接文件（handoff artifact）重置上下文，比压缩（compaction）更有效。

值得注意的是，随着 Opus 4.6 的发布，Anthropic 发现模型原生能力已足够强，可以移除 Sprint 结构，将评估器改为在构建结束后单次运行。这验证了 Cursor 的观点：Harness 的复杂度应随模型能力演进持续重构。

3. Cursor：动态上下文 + 数据驱动的持续优化

Continually improving our agent harness

https://cursor.com/blog/continually-improving-agent-harness

LLM 只是引擎，Harness 才是底盘：Cursor 官方首次系统披露 AI Coding Agents 工程方法论

Cursor 的文章更偏向工程方法论和基础设施，展示了如何像运营互联网产品一样运营 Agent Harness。

上下文策略的演进：

早期（2024 年末）：大量静态上下文（代码库结构、语义匹配的代码片段）+ 强护栏（限制工具调用次数、改写文件读取请求）。
现在：转向动态上下文——模型按需拉取信息（MCP 工具、活跃终端、历史对话），减少预置信息，增加智能体的自主决策权。

评估体系的三层结构：

离线基准（CursorBench）：快速、标准化的质量对比。
在线 A/B 测试：真实用户场景中的多版本对比。
代理指标：

保留率（Keep Rate）：智能体生成的代码在固定时间后仍保留在代码库中的比例——直接反映用户是否满意到无需修改。
语义满意度：用 LLM 读取用户后续消息，判断用户是继续推进（满意）还是粘贴错误堆栈（不满意）。

工具可靠性工程： Cursor 将工具调用错误率视为核心指标，通过分类（InvalidArguments、UnexpectedEnvironment、ProviderError 等）和专项冲刺，将所有工具调用的可靠性推到了”两三个 9”（99.9%）。这看似是基础设施细节，实则是防止上下文腐坏的关键——一次失败的工具调用会留下错误信息，污染后续决策。

五个共同的核心命题

通读三篇文章，可以发现五个被反复验证的深层命题：

1. 上下文是稀缺资源，需要”地图”而非”说明书”

OpenAI 明确反对给智能体”1000 页的说明书”，因为：

会挤占任务和代码的上下文空间；
“当一切都重要时，一切都不重要”；
手册会迅速腐烂，智能体无法判断信息是否过时。

三者的共同解法是渐进式披露：给智能体一个高层的”地图”（OpenAI 的 AGENTS.md、Anthropic 的 Sprint 合约、Cursor 的动态上下文引用），让它按需深入。

2. 评估必须外化，不能依赖自我批评

这是 Anthropic 最突出的贡献，也是 OpenAI 实践中的隐含逻辑。OpenAI 让 Codex 在本地和云端运行”额外的特定智能体审查”，本质上也是外部评估。Cursor 则通过保留率和用户反馈来间接评估。

核心原因是：LLM 对自己的输出有系统性偏袒，特别是在主观质量（如设计品味）和复杂逻辑正确性上。独立的评估器（或人类反馈回路）是打破这种偏见的必要设计。

3. 架构约束比代码审查更有效

OpenAI 的做法最具代表性：他们通过自定义 linter 和结构测试，强制每个业务领域遵循固定的分层架构（Types → Config → Repo → Service → Runtime → UI），依赖方向严格受限。

在智能体吞吐量远超人类注意力的场景下，**“阻塞式合并门”和”人工逐行审查”不再可行**。取而代之的是将人类的工程品味编码为可自动执行的规则，让智能体在边界内自由发挥。

4. 代码仓库是唯一的真相来源

三篇文章都强调：智能体只能看到代码仓库中的内容。OpenAI 将 Slack 讨论、设计决策全部归档到仓库的 docs/ 目录；Anthropic 通过文件进行智能体间通信；Cursor 的动态上下文也最终指向仓库内的可验证信息。

这意味着知识管理范式正在转变：从”文档系统 + 代码仓库”的双轨制，转向”代码仓库即记录系统”的单轨制。

5. Harness 是动态的，应随模型能力”做减法”

Anthropic 从 Sprint 结构到连续会话的简化，Cursor 从静态上下文到动态上下文的迁移，OpenAI 从人工审核到智能体自审核的过渡——三者共同展示了一个反直觉的规律：

模型能力越强，Harness 的复杂度不一定越高，但其形态会迁移。 工程师需要持续质疑 Harness 中的每个组件是否仍然”承重”，及时剥离过时的脚手架，同时在新边界上增加新的约束。

关键分歧与不同路径选择

尽管方向一致，三者在具体策略上存在值得注意的差异：

维度	OpenAI	Anthropic	Cursor
智能体数量	单智能体为主，多智能体用于审查	明确的三智能体分工	未强调多智能体，聚焦单智能体上下文管理
评估时机	持续审查（PR 级）	按 Sprint 或最终单次评估	通过用户行为间接评估（保留率）
上下文策略	仓库结构化文档 + 渐进式披露	上下文重置 + 结构化交接文件	动态上下文拉取（MCP、终端、历史对话）
质量保障	架构约束（linter、结构测试）	独立 Evaluator + Playwright 实测	工具可靠性 + A/B 测试 + 代理指标
适用场景	完整产品从零构建	长时运行的复杂全栈开发	日常编程辅助（IDE 内）

这些差异反映了场景的本质不同：OpenAI 探索的是”无人编码”的极限，Anthropic 探索的是”长时自主”的极限，Cursor 探索的是”高频交互”的极限。

对软件工程实践的启示

这三篇文章共同指向几个对行业有深远影响的判断：

1. 工程师的核心竞争力正在转移从”编写正确代码的能力”转向”设计可被智能体理解和执行的系统的能力”。OpenAI 团队说得很直接：“当软件工程团队的主要工作不再是编写代码，而是设计环境、明确意图和构建反馈回路时，会发生什么？”

2. AI slop 需要系统性的垃圾回收机制OpenAI 坦诚地提到，团队曾每周花 20% 的时间清理”AI 残渣”——智能体复现了仓库中不够理想的模式导致的代码漂移。他们的解决方案是将”黄金原则”编码到仓库中，并定期运行后台智能体扫描偏差。这提示我们：完全自主的代码生成必然伴随熵增，需要自动化的”垃圾回收”机制。

3. 主观品味的可编码化Anthropic 的前端设计实验表明，即使是”这个设计是否好看”这类主观判断，也可以通过精心设计的评分标准（设计质量、原创性、工艺、功能性）和少量示例（few-shot）校准，转化为可执行的评估逻辑。这为创意类工作的自动化提供了方法论。

4. 工具可靠性是 Agent 体验的基石Cursor 对工具错误率的极致追求（降到 0.1% 以下）揭示了一个容易被忽视的真相：Agent 的”智能”体验不仅取决于模型能力，更取决于工具链的确定性。一次失败的文件读取或 shell 调用，足以让智能体陷入错误的推理链。

5. 等待模型变强不是唯一策略Anthropic 的结论是：“有趣 Harness 组合的空间不会随着模型改进而缩小，而是会转移。” 这意味着 AI 工程师的工作不会很快被模型能力”吞噬”，而是需要持续在模型能力边界上找到新的组合方式。

总结

这三篇文章共同描绘了一幅清晰的图景：软件工程正在经历从”人类编码”到”人类设计 Harness，智能体编码”的范式转移。

OpenAI 展示了这种转移的极端可能性——完全自主、百万行代码级别的工程；
Anthropic 提供了长时复杂任务的理论框架——生成与评估的对抗性分离；
Cursor 则展示了如何以产品化的方式持续运营和优化这种转移——数据驱动、动态上下文、工具可靠性工程。

对 Agent 设计和开发者而言，最关键的 takeaway 是：不要只关注让模型”更聪明”，而要关注如何让模型在真实工程环境中”更可靠”。这需要的不是更大的模型，而是更好的上下文设计、更清晰的评估标准、更严格的架构约束，以及将人类品味持续编码为机器可执行规则的能力。