Anthropic 这篇 Harness 文章讲明白了一件事：想让 Agent 连续干几小时，不能只靠一个模型硬撑

很多人做 Agent，第一反应都是：

• 模型换强一点；
• Prompt 写长一点；
• 工具接多一点；
• 让它自己连续跑久一点。

但 Anthropic 这篇新文章真正想说的，是另一件事：

想让 Agent 连续工作几小时，甚至自己把一个应用做出来，关键不是“让一个模型更拼”，而是给它配一套能上班的工作机制。

这套机制，文章里叫 harness。

你可以把 harness 先简单理解成：给 AI 搭的工作流程和分工系统。

先说人话版结论

如果你只让一个 Agent 从头干到尾，它大概率会遇到两个问题：

1）做久了会跑偏

上下文越来越长，任务越来越杂，Agent 容易开始糊涂、收尾过早，或者表面还在做事，实际已经偏离目标。

Anthropic 在文里把这类现象讲得很直白：有些模型会出现类似“上下文焦虑”的问题——当它感觉对话太长、上下文快满了，就会开始急着结束，而不是继续把事情做好。

2）它会高估自己

这也是更隐蔽、但更致命的问题。

很多 Agent 做完东西后，会对自己的结果很满意，觉得“差不多可以交了”。但从人的角度看，可能只是“看起来像完成了”，并不是真的能用。

一句大白话：

AI 最容易犯的错，不是不努力，而是把半成品当成成品。

Anthropic 给出的解法，不是更长 Prompt，而是“三人小组”

这篇文章里，Anthropic 最核心的做法，是把一个长任务拆成三个角色：

Planner：先把一句话需求扩成靠谱方案

用户可能只说一句：

帮我做一个浏览器里的音乐工作站。

如果直接让 Agent 开干，它很容易边想边做，最后范围失控，或者做得太浅。

所以 Anthropic 先加了一个 Planner，相当于让 AI 先当产品经理，把一句话需求扩成完整规格：

• 这个产品要有什么模块；
• 先做哪些，后做哪些；
• 什么叫“做完了”；
• 哪些地方可以加 AI 能力。

这一步的作用，不是让计划更漂亮，而是让后面少走弯路。

Generator：负责真正把东西做出来

这个角色就是“干活的人”。

它根据规划，一段一段地实现功能，写前端、后端、交互、数据库，把应用真的搭起来。

你可以把它理解成项目里的主力开发。

Evaluator：专门负责挑毛病，不负责鼓掌

这是整篇文章里最值得记住的部分。

Anthropic 发现，如果让同一个 Agent 既负责做、又负责评，结果往往会偏乐观。

所以他们单独设了一个 Evaluator，专门负责：

• 按标准打分；
• 真点页面、真走流程、真测功能；
• 发现 bug 就明确退回；
• 不达标就不算完成。

它更像测试、审稿人、QA，而不是陪跑啦啦队。

而且他们不是让这三个角色“口头协作”就算了，而是把交接写进文件、把每一轮的完成标准提前约定好，再让 Evaluator 用 Playwright 去实际操作页面和接口。

这意味着它检查的不是“你说你做完了没”，而是“我真试过了，能不能用”。

这其实就是长会话 Agent 开始进入“可运营阶段”的关键标志：不是它会不会生成，而是有没有独立验收。

为什么这件事很重要？因为“看起来很像”不等于“真的能用”

Anthropic 在文里举了一个很典型的对比。

他们让单 Agent 和完整 harness，分别去做一个复古游戏制作器。

• 单 Agent：20 分钟，9 美元；
• 完整 harness：6 小时，200 美元。

乍看之下，后者又慢又贵。

但真正拉开差距的，不是页面好不好看，而是：

• 单 Agent 做出来的东西，很多核心流程其实是坏的；
• 完整 harness 做出来的版本，虽然也不完美，但关键玩法真的能跑起来。

这背后说明一件事：

长任务里最贵的成本，往往不是 token，而是你以为做完了，其实没有。

如果没有独立验收，团队会把很多“像样的半成品”误判成“可交付成果”。

这篇文章还有一个更重要的判断：Harness 不是越复杂越高级

很多人看完这类文章，容易马上得出一个误解：

那我是不是也要立刻堆很多角色、很多脚手架、很多流程？

Anthropic 这篇文反而提醒了另一件更成熟的事：

Harness 的价值，不是不断加复杂度，而是随着模型变强，持续判断哪些结构还真正有用。

他们一开始为了让长任务能跑通，加了 sprint、分阶段 QA、更多约束。 后来模型变强后，又主动把一部分结构拆掉，测试哪些还“承重”，哪些已经可以删。

这个思路特别重要。

因为做 Agent 不是搭一次流程就结束了，而是：

• 先补模型目前做不到的地方；
• 再随着模型升级，把多余脚手架拆掉；
• 最后保留真正长期有价值的部分。

说白一点：

好 harness 不等于复杂 harness；好 harness 是刚好能托住结果的那一层结构。

如果你是小白，最该带走哪 4 个理解？

1）长会话 Agent 不是“一个更长的聊天”

它更像一条工作流。

你不是在跟一个模型连续聊 4 小时，而是在让一套有分工、有交接、有验收的系统持续推进任务。

2）不要让 Agent 自己给自己毕业

只要任务稍微复杂一点，就要想办法加入独立检查。

哪怕不是完整 QA Agent，也至少要有：

• 单独的验收清单；
• 独立的检查步骤；
• 明确的失败条件。

3）“上下文管理”本身就是产品能力

很多人只盯模型，却忽略了上下文怎么交接、怎么压缩、什么时候清空重来。

但当任务变长之后，这些反而会直接决定稳定性。

4）做数字员工，核心不是“会回答”，而是“会交付”

Anthropic 这篇文章本质上证明了一件事：

Agent 想走向真实工作，不只是更像聊天助手，而是更像一个被流程约束、被标准验收、能持续交付的岗位系统。

对 UseClaw / OpenClaw 方向，最有价值的启发是什么？

如果你在做的是数字员工、内容运营 Agent、研究 Agent，或者任何要持续值守和推进的系统，这篇文章至少给了 3 个直接启发：

启发 1：先分角色，再谈自治

不要一上来就想做“万能 Agent”。

先把任务拆清楚：

• 谁负责理解目标；
• 谁负责执行；
• 谁负责验收；
• 谁负责交接上下文。

启发 2：能量化的地方，一定要量化

Anthropic 连“设计好不好看”这种主观问题，都尽量拆成了评分标准。

这对内容、运营、产品工作同样成立。

比如一篇稿子，不要只问“感觉行不行”，而要拆成：

• 相关性够不够；
• 信息密度够不够；
• 结构清不清楚；
• 有没有转化潜力；
• 是否真的可发布。

启发 3：随着模型升级，流程也要重做体检

模型一变，原来很多必须存在的“补丁层”可能就没那么重要了。

所以真正成熟的团队，不是把 harness 当祖传模板，而是把它当成持续演进的运营系统。

最后一句

Anthropic 这篇文章最值得看的，不是它又做了一个多复杂的 Agent，而是它把一件事讲清楚了：

当 Agent 开始做长任务时，决定上限的往往不再只是模型能力，而是你有没有把“规划、执行、检查、交接”搭成一个真正能上班的系统。

这也是为什么，接下来值得做的，不只是更强的 AI 助手，而是更像真人员工的数字工作流。

参考来源

• Anthropic Engineering: Harness design for long-running application development
  https://www.anthropic.com/engineering/harness-design-long-running-apps

UseClaw 持续记录 OpenClaw、Agent 与数字员工的真实案例、方法和产品化实践。
了解更多：https://useclaw.net/