返回博客

Harness 厚薄之争的真相：这不是技术问题，是信任问题

AI AgentCoding AgentHarnessAnthropicCodex架构设计

所有人都在聊 Harness，但聊的不是同一件事

最近圈子里最热的技术辩论，不是哪个模型更强，而是 AI 编程智能体（Coding Agent）外面那层"壳"该做多厚。

Anthropic 旗帜鲜明：做厚。他们在工程博客里亮出了 GAN 启发的三 Agent 架构——Planner 拆任务、Generator 写代码、Evaluator 当质检员。Sprint 合同、上下文重置、结构化交接，一套重型编排拉满。

OpenAI Codex 针锋相对：做薄。技术负责人 Michael Bolin 公开表态——Harness 应该"尽可能小"，模型应该"尽可能强"。给个沙箱、给个终端，让模型自己决策。

行业主流判断？重型 Harness 是中间态，模型变强了自然会收缩。

这个判断不能说错。但它漏掉了一个关键维度。

先说清楚：Harness 到底是什么

Harness 不是一条 system prompt，也不是一次工具调用。它是模型外部的整套控制结构——Agent 的工程外骨骼。

它负责的事情很具体：

  • 任务拆解：把模糊需求变成可执行步骤
  • 工具调度：决定何时调用什么工具
  • 上下文传递：在多轮对话和多个 Agent 之间搬运记忆
  • 结果校验：检查输出是否符合预期
  • 风险兜底：在模型犯错时拉住它

没有 Harness，模型就是一个裸奔的大脑——聪明，但无法稳定完成长周期、多步骤的编码任务。

两条路线：重装上阵 vs 轻装前行

Anthropic：信不过模型，就用工程来补

Anthropic 在 2025 年底和 2026 年初发布了两篇工程博客，完整展示了他们的"重型 Harness"路线。

架构灵感来自 GAN（生成对抗网络）——把"做事的"和"评判的"分开。

Planner Agent：接受 1-4 句话的用户需求，展开成完整产品规格。它只管"做什么"和"为什么"，刻意不涉及"怎么做"——因为过早的实现细节会导致级联错误。

Generator Agent：按 Sprint 增量写代码。在 Opus 4.6 上可以连续跑 2 小时以上。

Evaluator Agent：拿着 Playwright 像真实用户一样操作应用，对着 Sprint 合同打硬性通过/不通过。

这套架构有一个关键发现：LLM 天生不擅长自我评估。Anthropic 的原话是——"当被要求评估自己的工作时，Agent 倾向于自信地夸赞——即使在人类看来质量明显平庸。"

所以他们把评估权从执行者手里拿走了。

成本数据很说明问题：单 Agent 跑 20 分钟花 9 美元，产出不能用的残次品；三 Agent 跑 6 小时花 200 美元，产出真正能工作的应用。

Codex：模型会变强，框架是过渡补丁

Bolin 的架构极简到几乎可以一句话说完：

组装 prompt → 模型推理 → 工具执行 → 循环

没有 Planner，没有 Evaluator，没有 Sprint 合同。模型自己决定是继续调用工具还是输出结果。

他用 Rust 写 Harness（不是 TypeScript），追求极致性能。三条核心原则：

  • 最小化工具依赖——让模型直接用终端，而不是给一堆专用工具抽象
  • 环境优先于框架——只提供沙箱安全，不做过度流程控制
  • 把能力还给模型——让模型自己学会探索和决策

Bolin 说得很直接：如果模型不够好，Harness 做成花也没用。

行业主流判断：重型 Harness 是中间态

如果你只看技术演进轨迹，"中间态"的结论几乎是不可避免的。

证据一：Anthropic 自己在简化。从 Sonnet 4.5 到 Opus 4.6，他们去掉了 Sprint 分解结构——模型变强后，这层编排不再必要。架构从两 Agent → 三 Agent → 简化回去，说明他们也在不断"减法"。

证据二：Anthropic 说过一句很诚实的话——"Harness 里的每一个组件，都编码了一个关于模型做不到什么的假设。这些假设值得反复压力测试。"

证据三：LangChain 在 Terminal Bench 2.0 上的实验，仅靠调整 Harness（模型不变），成绩从 52.8% 提升到 66.5%。但这也意味着——如果模型本身进步了，很多 Harness 优化会变成冗余。

证据四：Manus 团队半年内重写了五次 Harness，每一次都是在做减法。

所以主流结论是：Harness 不会消失，但会从"流程控制层"收缩为"运行环境层"——安全、沙箱、基础工具。

逻辑自洽。数据支撑。结论清晰。

但我觉得这个分析框架少了一条腿。

我的不同看法：Harness 的厚薄，取决于你服务谁

过去三年，我交付了 7 个以上的 AI Agent 产品，服务对象从个人开发者到企业客户都有。我发现一个行业讨论里几乎没人提的事实：

Harness 的厚度，不只取决于模型的能力，更取决于使用者的身份。

对个人开发者：模型变强 → Harness 变薄 ✅

如果你是一个人写代码，你信任模型，你要的是零摩擦——Codex 的路线完全正确。模型越强，你需要的外部编排越少。给我一个沙箱、一个终端、一个强模型，别挡我的路。

这条逻辑线是直的。

对企业客户：Harness 永远不会薄

但企业客户的世界完全不同。

当我把 AI Agent 部署到企业环境里，客户问的第一个问题从来不是"模型够不够聪明"。他们问的是：

  • "它做了什么决策？能不能回溯？" —— 可审计性
  • "谁批准了这个操作？" —— 审批流程
  • "出了问题谁负责？" —— 责任归属
  • "它符合我们的合规要求吗？" —— 监管合规

这些需求不会因为模型变强而消失。恰恰相反——模型越强、自主权越大，企业对控制层的需求就越重。

Anthropic 在 Harness 里加 Planner、Evaluator、Sprint 合同，表面上是在补偿模型缺陷。但从企业视角看，这些组件同时在提供组织可读性：

  • Planner 的输出 = 可审计的决策记录
  • Sprint 合同 = 可追溯的验收标准
  • Evaluator 的通过/不通过 = 独立第三方校验

把评估权从执行者手里拿走——这不只是工程上的好实践，更是组织治理的基本原则。你不会让写代码的人自己审代码，同样的道理。

更深一层：Harness 的本质是信任的工程化

想清楚这一层，整个辩论就清晰了：

信任模型 → 薄 Harness。 你相信模型能自己做对，那就给它最小约束。

信任流程 → 厚 Harness。 你需要流程来保证可控性，那就把流程编码进 Harness。

Codex 的客户画像是信任模型的个人开发者。Anthropic 的客户画像是信任流程的企业组织。

他们不是在同一个维度上争论。

这也解释了为什么 Anthropic 用 TypeScript 写 Claude Code（快速迭代、生态丰富），而 Codex 用 Rust（极致性能、安全保障）。技术选型背后是客户画像的差异。

我自己做 One-Person Capital（开源 Agent 编排与治理平台）的时候，直觉上倾向 Codex 的极简路线。但每次面对企业客户，我都被拉回 Anthropic 那边——不是因为模型不够强，而是因为企业需要的"厚"和模型需要的"厚"是两码事。

模型需要的厚度会随能力提升而减少。组织需要的厚度不会。

所以谁会赢？

这不是一个"谁对谁错"的问题。而是两条路线服务不同市场。

  • Codex 路线会赢得开发者市场——个人效率最大化，摩擦最小化
  • Anthropic 路线会赢得企业市场——可控性、可审计性、组织信任

真正的竞争力不在于今天的 Harness 厚还是薄，而在于：你能多快地根据模型进步，把不再必要的层减掉，同时保留组织必须的层。

这才是 Harness 工程的核心竞争力——不是搭积木，是拆积木的速度。

而且说实话，这个判断也可能错。我造了这些工具，我也在参与这场赌注。作为 AI 产品的建设者，我不假装中立。但至少我可以告诉你——在真实的产品战场上，"模型变强了 Harness 就能薄"这句话，只在一半的场景里成立。

一句话收尾

Harness 的厚薄之争，表面是技术架构之争，底层是信任架构之争。你信模型，就做薄。你信流程，就做厚。而大多数真实场景，两者都需要。