为什么 Harness Engineering 正在成为 AI Agent 的真正护城河

问题不在模型不够强，而在模型离“完成任务”还隔着一整套系统

过去一年里，大模型在单步能力上进步得非常快：写代码、改 bug、解释报错、生成 UI、读文档、做总结，这些能力都在明显抬升。于是很多人会自然地觉得，下一步只要模型再强一点，Agent 就会自动变得可靠。

但现实正好相反。任务越长、越复杂、越接近真实软件工程，问题就越不在“这一步答得好不好”，而在“整个链路能不能稳定推进”。

• 任务需要跨多个阶段：研究、规划、实现、测试、修复、验证；
• 任务需要跨多个工具环境：终端、浏览器、文件系统、知识库、文档；
• 任务需要跨多个上下文窗口：今天做一半，明天继续，甚至多次切 session；
• 任务需要对中间产物不断做质量判断，而不是只看最后一句“Done”。

这就是为什么“模型更强”并没有自动解决 Agent 的稳定性交付问题。因为从单步能力到长期交付，中间还差一整套系统，而这套系统就是 Harness。

Anthropic 最新工程文章，实际上把 Harness 的核心问题讲得很透

Anthropic 最近那篇 Harness design for long-running application development 的价值，不在于又讲了一次“我们用了多智能体”，而在于它把一个长期被模糊化的问题说清楚了：当任务长到会跨 context window、跨多轮 session、跨多个开发阶段时，必须把连续性从模型记忆里拿出来，迁移到结构化工件里。

从搜索结果和多方转述里，这篇文章至少给出了几个非常关键的点：

这篇文章其实做了一件很关键的事：它把长期以来人们对 Agent 的模糊想象，拉回到了工程现实。不是“给它更多上下文就行”，也不是“给它更强模型就行”，而是你必须为它建立可重启、可交接、可评估、可持续推进的执行结构。

论文和 benchmark 给出的，是为什么“系统设计”不能被忽略的硬证据

如果 Anthropic 的文章偏工程经验，那么学术线索则提供了另一个角度：即使在统一 scaffold 下，长链软件工程任务依然很难，这说明问题不是一句“模型不够强”能解释的。

SWE-agent：Agent-Computer Interface 本身就能显著改变结果

SWE-agent 这篇工作很重要，不只是因为它做了一个 coding agent，而是因为它提出了 ACI（Agent-Computer Interface） 的概念。论文的一个核心结论是：即便不改底层模型，只要把 Agent 和环境交互的接口设计好，性能就会明显提升。

这其实已经在学术语言里说明了一个事实：模型外的系统设计，本身就是能力来源。 ACI 是 Harness 的一个子集，而这恰恰证明，Agent 能力从来都不是纯模型函数。

SWE-Bench Pro / 长链软件工程基准：长任务仍然很难

而像 SWE-Bench Pro 这类面向长任务的软件工程基准，则告诉我们另一个更直接的现实：在统一 scaffold 下，主流 coding model 在长程软件工程任务上的表现依然不高。搜索结果中的描述提到，在统一框架下，广泛使用的模型在这类任务上的 Pass@1 依然偏低，最高模型也没有高到可以“放心自动交付”。

这件事的意义非常大。它意味着什么？意味着哪怕模型已经很强，一旦任务进入长链、跨文件、跨阶段、需要自我验证和长期规划的软件工程环境，单纯依赖模型本身仍远远不够。

也就是说，论文和基准没有削弱 Harness 的重要性，反而强化了它：模型的上限已经不低，但长任务成绩仍然吃力，说明真正缺的正是系统性支撑。

社区热门讨论为什么也在往同一个方向收敛？

如果只看论文和官方博客，你可能会觉得这是少数公司在讲工程细节。但社区最近几周的热门讨论，实际上也在用更草根、更实战的方式重复同一个判断。

最近你收藏的那些帖子——无论是“手搓自用 coding agent”“用 Codex review Claude”“tmux 当消息总线”“harness-creator 技能”“idea file / AI knowledge base”——它们表面上关键词不同，但内核一致：大家都在试图把模型装进一个更可控、更能连续完成任务的系统里。

这也是为什么我认为这不是偶发话题，而是结构性趋势。真正重要的不是某一个工具名，而是社区已经开始普遍意识到：Agent 的问题不能只靠 prompt 解，得靠系统解。

如果把 Harness 真正拆开，它至少有五层结构

1. 任务分解层：把长任务切成可推进、可验收的阶段，而不是一把梭到底。
2. 状态管理层：让任务进展活在文件、日志、feature list、handoff artifact 里，而不是只活在上下文窗口里。
3. 角色协作层：研究、实现、审查、验证尽量分离，不让同一个 Agent 持续兼任所有角色。
4. 验证闭环层：通过测试、浏览器检查、diff 审核、日志回读、人工 gate 等方式建立反馈。
5. 技能沉淀层：把一次性的有效经验提炼成 Skill、模板、SOP、策略规则，形成系统记忆。

这五层并不要求一次到位，但它们勾勒出一个关键事实：Harness 绝不是 Prompt 包装器，而是一套完整的执行体系。谁把这五层做得越清楚，谁的 Agent 就越接近“能持续做事”而不是“偶尔答对”。

为什么它会成为真正护城河，而不是暂时热词？

因为模型会趋同，系统不会。

未来一年，模型还会继续进步，供应商还会继续轮换，价格和榜单也会继续变化。但真正难复制的东西并不是“你今天用的是哪个模型”，而是这些问题的答案：

• 你如何拆解复杂任务？
• 你如何定义完成标准？
• 你如何做结构化交接？
• 你如何让多个角色协作而不失控？
• 你如何让失败可恢复、经验可复用？

这些能力一旦沉淀到产品、团队流程、个人工作流里，就不会像模型供应商那样轻易被替换。换句话说，模型是流动性的，Harness 是沉淀性的。

最后的判断：未来竞争不在模型本身，而在谁更会搭那套让模型真正做成事的系统

把 Anthropic 的工程经验、SWE-agent 的学术结论、SWE-Bench Pro 这类 benchmark、以及社区最近高密度的实战讨论放在一起看，我认为可以得出一个很稳的结论：

Harness Engineering 正在从“高手技巧”变成 AI Agent 时代的基础设施问题。

它之所以重要，不是因为它听起来高级，而是因为它正好处在模型能力和现实任务之间的断层带上。只要这个断层还在，Harness 就会持续有价值。

而且随着模型变强，Harness 不会消失，只会演化：某些为了弥补模型短板而存在的结构会被简化，但任务拆分、验证闭环、权限控制、结构化交接、经验沉淀这些更底层的问题不会消失。

所以如果把这篇文章压缩成一句话，那就是：

这篇文章主要参考的材料与线索