星澜

天接云涛连晓雾，星河欲转千帆舞

03. AI Agent 与 Harness：Anthropic 和 LangChain 的 Harness Engineering

mingzaily / Codex / 2026-03-29

聊 harness engineering，资料并不少，真正难的是不同文章经常不在同一层说话。

Anthropic 和 LangChain 这两篇很适合放在一起看：前者更像在谈长任务架构，后者更像在谈运行时调优。

如果前两篇《01. AI Agent 与 Harness：概念梳理》和《02. AI Agent 与 Harness：从 Prompt 到 Harness》解决的是概念和背景，那么这一篇要解决的是三件事：

如果你更关心落地阶段的验证闭环，可以接着读《04. AI Agent 与 Harness：V2 Harness 的验证设计》。

结论

把这两篇放在一起看，结论大致是：

为什么这两篇文章值得单独拿出来看

因为它们都把一个过去经常被模糊处理的问题说透了：

模型能力强，不等于系统就稳定。

过去很多讨论会把注意力放在：

但这两篇文章真正强调的是：

也就是说，它们讨论的重点不是“模型会不会”，而是“系统能不能稳定做完”。

Anthropic 那篇，到底在讲什么

文章原文：

1. 它说的 harness 很重

Anthropic 那篇最重要的一个信号是：
他们说的 harness，不是几个 prompt，不是一份 AGENTS.md，也不是若干个 tool 描述。

在他们的实践里，harness 里面有：

先要看到的是：

skill、tool、MCP 都可能是 harness 的组成部分，但 harness 本身比它们大得多。

2. 它点名了两个核心失败模式

Anthropic 提得很准的两个问题是：

这两个问题其实非常典型。

第一个问题会导致：

第二个问题会导致：

Anthropic 讲的并不是“怎么让模型更聪明”，而是：

怎么让系统别失忆，怎么让系统别自我感觉太良好。

3. 它把验证循环讲得非常具体

这篇文章最有价值的一点，是它没有停留在“做完以后检查一下”这种空话。

它强调的验证循环是真实、具体、可执行的：

也就是说：

验证循环不是附属动作，而是 harness 的核心部件。

这件事非常关键。
因为很多团队已经有 prompt、有规范、有工具，甚至有 skill，但只要没有验证闭环，本质上还是“指导型 harness”，不是“可交付 harness”。

4. 它强调 harness 不是越复杂越好

Anthropic 那篇里我最喜欢的一句是：

every component in a harness encodes an assumption about what the model can't do on its own

这句话的意思其实很狠：

你加上的每一层 harness，都代表你在假设模型自己还做不好某件事。

所以：

这里有个很关键的判断：

用最小但足够有效的 harness，比盲目堆很多组件更重要。

5. 它真正关心的是长任务熵管理

Anthropic 整篇文章其实一直在回答一个问题：

当任务持续很久、跨很多轮、跨很多上下文窗口时，怎么让系统别越跑越乱？

所以他们会强调：

这些东西合起来，其实都在服务于同一件事：

降低长任务里的熵增。

LangChain 那篇，到底在讲什么

文章原文：

1. 它证明了 harness 可以单独拉分

LangChain 那篇最重要的一点，是它明确告诉你：

不是只有换更强模型才能提升效果。

在很多情况下，只改 harness，就能明显提升 agent 在复杂任务里的表现。

这等于把讨论重心从：

拉回到：

2. 它的方法是 trace-driven

LangChain 的味道很工程。

它不是说：

而是说：

也就是说，它把 harness engineering 讲成了一种非常典型的工程调优方法，而不是玄学。

3. 它把 harness 聚焦成几个关键旋钮

这篇文章把一些常见抓手讲得很清楚，比如：

这些东西平时大家都知道，但 LangChain 的重点在于：

不是知道这些组件存在，而是要把它们当成可以系统调参的控制面。

这就很像传统软件工程里的：

4. 它最强调 Build -> Verify -> Fix

这点和 Anthropic 在精神上非常一致。

LangChain 非常明确地反对一种做法：

模型生成一次答案，系统就直接收工。

它更强调：

也就是：

Build -> Verify -> Fix

如果说 Anthropic 更像是在长任务层面强调验证循环，那么 LangChain 更像是在调优层面强调：

没有验证闭环，agent 的输出不值得直接相信。

5. 它把 harness 看成运行时保护机制

LangChain 的另一个特点是，它把 harness 讲得很像“运行时防护层”。

比如它会强调：

这让我很自然地把 harness 理解成：

不是给模型加装饰，而是给运行中的 agent 系统加保护。

两篇文章的共同点

它们虽然视角不同，但核心判断非常一致：

1. 都认为真正拉开差距的，不只是模型

两篇文章都在反复说明：

2. 都认为验证循环是核心能力

这几乎是它们最强的共识。

不管叫 evaluator、checklist、middleware 还是 verify loop，本质都是：

不能只相信模型自己的判断。

3. 都认为 harness 应该围绕 failure mode 设计

不是先堆很多组件，再希望它有效；而是：

4. 都隐含一个前提：harness 不是永恒不变的

模型升级后，harness 也应该跟着变。

有些旧时代必须手动补的东西，未来可能会被更强的模型或更成熟的平台能力吃掉。

两篇文章的差异

如果要做最短的区分，可以这样记：

再展开一点：

Anthropic 的重心

LangChain 的重心

所以：

读完之后最值得记住的几件事

1. Harness 不是宣传词

乍看之下，harness 很容易像一个新的营销包装。

但把这两篇文章读完之后，会更容易发现：

它是在给 agent 时代的软件工程补一套更贴切的语言。

2. Harness 和仓库规则不是一回事

这两篇文章也把一个区分说得更清楚：

前者是仓库规则和团队工作流，后者才是官方语境里更常见的 harness。
这两者不是一回事，但思路可以互相借鉴。

3. 只有规范，没有验证循环，还不算成熟 harness

很多团队现在已经有：

这些当然很有价值。
但如果没有验证循环、没有失败返工、没有 done 定义，那更像是 harness v1，还不是完整的闭环。

4. 长任务的核心问题其实是熵

Anthropic 那篇里，最扎眼的其实就是这个问题。

很多所谓“长任务不稳”，本质上其实都是：

所以长任务 harness 的关键，往往不是“多加一个工具”，而是：

怎么管理熵。

最短总结

最后只留下几句的话，最值得记住的是：

  1. Harness engineering 不是让模型更聪明，而是让系统更稳定。
  2. Anthropic 更像在讨论长任务架构。
  3. LangChain 更像在讨论运行时调优。
  4. 两篇文章都认为验证循环是核心能力。
  5. skill / tool / MCP 可以是 harness 的组成部分，但都不等于 harness 本身。
  6. 长任务最难的不是“开始做”，而是“别越做越乱”。

参考