关于 AI Agent，一个很现实的问题已经越来越突出：模型已经能写代码、能调用工具、能操作浏览器，但真正难的是，怎么让它在长时间任务里持续保持判断力，而不是跑偏、丢上下文，或者交出一个“看起来完成了”的半成品。

这个话题来自一期关于 AI 工程实践的播客。里面讨论的是 Anthropic 应用 AI 团队在 Claude Code、Agent SDK 以及一些长时间运行 Agent 实验里的经验。相比某个具体 demo，我更关注它背后的工程方法：真正稳定的 Agent，不是靠模型自由发挥，而是靠清晰角色、严格标准和可追踪状态。

一、为什么长时间运行 Agent 很难？

我们先想一个场景。

你给一个 Agent 一句话：
“帮我做一个完整的 Web 应用。”

它可能很快生成一个页面：有按钮，有导航栏，有看起来不错的界面。你第一眼看过去，会觉得它好像完成了。

但继续用下去，你可能会发现：

按钮点了没反应；
数据没有保存；
测试没有跑；
边界情况没处理；
页面看起来完整，但核心功能根本不存在。

这就是 Agent 很容易出现的一个问题：它很擅长制造“看起来完成了”的东西，但不一定真的完成了。

播客里提到，模型有几个天然弱点。

第一个弱点是 记忆问题。
如果 Agent 一直运行在一个上下文窗口里，任务越长，上下文越容易被压缩。压缩之后，很多细节会丢。模型可能还记得“我要做一个应用”，但不记得之前已经决定过哪些功能、改过哪些 bug、哪些测试还没通过。

第二个弱点是 规划问题。
很多模型一拿到任务，就想一次性把所有事情做完。结果可能做到一半，上下文用完了，或者它自己也不知道下一步该做什么。

第三个弱点是 自我评估问题。
模型很擅长迎合用户。用户问“这个功能完成了吗？”它可能会说“完成了”。但那个完成可能只是表面完成。

所以，真正的问题不是“模型会不会写代码”，而是：
模型能不能判断自己有没有真正做完？能不能知道自己哪里没做好？能不能在长时间运行中不偏离目标？

这就是长时间运行 Agent 的核心挑战。

二、Ralph loop：用可预测的方式失败

播客里反复提到一个概念：Ralph loop。

这个名字听起来有点奇怪，但它的思想很朴素：
不要让一个 Agent 在一个越来越长的上下文里无限跑下去，而是让它每完成一小段任务，就把状态保存下来，然后开启一个新的上下文继续做。

为什么要这么做？

因为一个长上下文看起来很方便，但它有一个问题：越往后，模型越容易混乱。它可能忘记前面的决策，也可能被大量历史细节干扰。

Ralph loop 的做法，是把任务拆成很多小段。每一段都留下清晰的状态，比如：

这个功能完成了没有；
测试通过了没有；
还有哪些问题没解决；
下一步应该做什么；
当前代码库处在什么状态。

这样，即使某一步失败了，我们也能知道失败在哪里，下一步怎么接上。

这里有一句很重要的话：
“以可预测的方式失败，比以不可预测的方式成功更好。”

因为做工程系统，尤其是 AI 系统，最怕的不是失败，而是失败得莫名其妙。
如果一个 Agent 失败了，但我们知道它为什么失败、失败在哪一步、下一步怎么恢复，那它仍然是可控的。
但如果它偶尔成功了，我们却不知道它为什么成功，这种成功其实也不可靠。

所以 Ralph loop 的核心，不是为了让流程看起来复杂，而是为了让 Agent 的行为更可追踪、更可恢复、更可预测。

三、Harness：不是让模型自由发挥，而是设计工作框架

接下来是另一个重点：Harness，也就是 Agent 工作框架。

很多人一听到 Agent，会觉得它应该很自由：给它一个目标，它自己想办法完成。

但 Anthropic 的经验是，真正稳定的 Agent，不是靠模型自由发挥，而是靠一套好的工作框架。

这套框架里通常有几个角色。

第一个是 Planner，规划器。
它负责把模糊需求拆成高层计划。比如这个应用大概有哪些模块，哪些功能先做，哪些功能后做。

但注意，规划器不应该一开始就陷入特别细的技术实现。因为如果一开始规划错了，后面几个小时都会沿着错误方向走。

所以规划器要做的是高层设计，而不是把所有细节一次性定死。

第二个是 Generator，生成器。
它负责真正写代码、做功能、实现需求。

第三个是 Evaluator，评估器。
这是非常关键的角色。它不是简单看代码，而是要真正运行应用、打开页面、点击按钮、检查交互、验证功能。

也就是说，评估器不是“看看觉得还行”，而是要像测试工程师一样，把应用真的跑起来。

这个结构其实很像一个小团队：

规划器像产品经理，负责方向；
生成器像开发工程师，负责实现；
评估器像 QA 或者测试工程师，负责挑问题。

但和人类团队不同的是，这些角色各自有自己的上下文窗口，也各自承担明确职责。

这样做的目的，是避免一个模型同时承担太多角色。
如果一个模型既要写代码，又要判断自己写得对不对，它很容易自我合理化。

四、评估器必须严格，不能太客气

这一部分我觉得是整场分享里最实用的地方。

很多 Agent 系统里也有评估器，但问题在于，评估器太容易放水。

它会说：

“这个功能基本完成了。”
“页面看起来还可以。”
“这个问题以后再说。”
“用户可能不会在意这个细节。”

这种评估没有价值。

真正有用的评估器，必须非常具体。

比如不要说“这个页面不够好”，而要说：

这里缺少一个 54 色调色板；
sprite 编辑器不能按真实游戏尺寸预览；
游戏角色移动后没有和障碍物发生碰撞；
AI 关卡助手虽然存在，但没有真正接入游戏流程；
Fast API 路由顺序有问题，单元测试过了，但真实环境会坏。

你看，这种反馈才是可执行的。

播客里有一句很关键的话：
“模糊的批评，只会带来模糊的改进。”

如果评估器只是说“不够好”，生成器不知道该怎么改。
但如果评估器说“缺少碰撞检测”“缺少真实游戏尺寸预览”“按钮没有绑定逻辑”，生成器就知道下一步该补什么。

所以，做 Agent 系统时，最重要的不是让评估器存在，而是让评估器足够严格、足够具体。

五、主观质量也可以被打分

还有一个很有意思的观点：主观质量不是不能打分。

很多人会说，审美、设计感、产品体验这些东西很主观，模型很难判断。

但 Anthropic 的做法是，把主观标准拆成可执行的评分维度。

比如一个前端应用，可以拆成几个标准：

设计是否统一；
交互是否完整；
原创性够不够；
功能是否可用；
是否避免了常见 AI 生成页面的廉价感。

然后他们还会给模型一些参考样例，也就是 few-shot。
告诉它：什么样的页面是好的，什么样的页面是差的，哪些设计细节是应该保留的。

这样一来，模型虽然不能像人一样真正理解审美，但它可以根据明确标准逐步靠近目标。

所以，主观质量不是完全没法处理。
关键是你能不能把“我觉得好”变成一套清晰标准。

这对我们做产品、做代码评审、做 Agent 系统都很有启发。
如果你只说“要高级一点”“要专业一点”“要用户体验好一点”，模型大概率不知道你在说什么。
但如果你把它拆成具体规则，它才有可能稳定执行。

六、先协商“什么叫完成”

这个流程里还有一个很关键的设计：generator 和 evaluator 不是一上来就写代码，而是先协商一份 contract。

所谓 contract，可以理解成一份“完成标准”。它不是 planner 一开始写死的产品规格，而是由 generator 和 evaluator 两个 Agent 在动手前共同谈出来的验收标准。

具体流程大概是这样的：

generator 先说：我要实现 X 功能，你可以用 Y 测试来验证。
evaluator 再反驳：这个范围太大了，而且 Y 测试太弱，还漏掉了 XYZ 这些边界情况。
然后双方继续在一个共享文件里来回写，不断修改 contract，直到双方都认可：满足这些条件，才算完成。

这个设计很值得注意。

因为如果一开始就让 generator 直接实现 planner 的规格说明，问题在于：规格说明通常是模糊的，而且 planner 也可能理解错。更麻烦的是，在长时间运行的 Agent 任务里，一个早期错误会被后面几个小时不断放大。

而 contract 机制把问题往前挪了一步：
先不要急着做，先定义什么叫完成。

这样，后续 evaluator 打分时，也不再依赖 planner 最初的规格说明，而是依赖 generator 和 evaluator 自己协商出来的、更具体、更可测试的标准。

播客里提到，generator 和 evaluator 最后会为应用写出一份包含 27 条标准的 contract。但比“27 条”这个数字更重要的是这个协商过程本身。

这也是 Ash 强调的关键点：
这就是 Ralph loop 一直缺少的关键创新。

Ralph loop 解决了状态保存和上下文切换的问题，但它不一定能解决“什么叫完成”这个问题。contract 机制补上了这一点：它让两个 Agent 在动手前先对齐验收标准，把模糊的用户故事转换成可测试的任务边界。

七、案例：同一个需求，有无 harness 差别很大

播客里提到一个例子：让模型做一个像素游戏制作器。

如果只有一个 Agent 自己跑，它可能会做出一个看起来还行的界面：有 sprite 编辑器，有简单按钮，有基础页面。

但真正深入使用，就会发现：

游戏模式不完整；
实体没有生命值、分数这些核心状态；
方向键和控制逻辑没有真正生效；
玩家移动后没有碰撞检测；
很多东西只是看起来像功能，实际上跑不起来。

但如果用 harness 跑，同样是这个需求，结果就不一样。

它可能会先给自己起一个项目名，比如 RetroForge；
它会设计一个更完整的新项目对话框；
它会做一个 sprite 编辑器，并且能按真实游戏尺寸预览；
它会加入 AI 关卡助手；
它会在游戏模式里加入 debug HUD，方便评估器测试；
它会真的运行游戏，验证玩家能不能移动、能不能和城堡墙发生碰撞。

这个例子说明，差别不只是模型能力，而是系统结构。

同一个模型，在没有 harness 的时候，可能只做出一个玩具；
在有 harness 的时候，它更可能做出一个完整产品。

所以，Agent 的质量，不只是模型的问题，也是工程框架的问题。

八、压缩不等于交接

长时间运行 Agent 还有一个重要问题：上下文压缩。

很多人会以为，只要模型能压缩上下文，它就能记住任务。
但播客里强调了一个观点：压缩不等于交接。

压缩是一种摘要。
交接是一种结构化状态。

摘要会丢细节。
结构化状态可以保留下一步动作。

所以他们很重视文件系统。
把状态写到文件里，比如：

Feature List；
Progress 文件；
测试通过情况；
失败原因；
下一步计划；
评估器反馈；
生成器修改记录。

这样，即使开启一个新的上下文，Agent 也能快速知道之前发生了什么。

这其实很像人类团队协作。
如果我们只靠口头回忆，很容易忘；
但如果我们有文档、有任务列表、有提交记录，新加入的人也能很快接手。

Agent 也是一样。
真正可靠的工作流，不应该只依赖模型记忆，而应该依赖外部状态。

九、模型越强，harness 不是消失，而是移动

还有一个观点很重要：模型变强以后，harness 不会消失，而是会变化。

以前模型弱的时候，可能需要频繁切上下文，频繁评估，频繁拆任务。
因为模型很容易跑偏，所以必须用很多机制把它拉回来。

但模型变强以后，有些步骤可以简化。

比如以前每个 sprint 都要评估一次，现在可能生成器可以一次性完成更多内容，然后评估器再统一检查。
以前必须频繁重置上下文，现在一个长会话配合压缩，也可能跑得不错。

所以 harness 不是固定套路。
它应该随着模型能力变化。

这给我们的启发是：
不要迷信某一种 Agent 架构。
今天有效的结构，可能下个月模型升级后就需要调整。

做 Agent 工程，本质上是在不断观察模型短板，然后用框架补上这些短板。

十、Agent Teams 和生成器-评估器模式并不矛盾

播客后面还讨论到 Agent Teams。

有人问：既然现在有 Agent Teams，多个 Agent 可以协作，那是不是就不需要专门的生成器-评估器模式了？

他们的回答是：这两者不矛盾。

Agent Teams 是一种组织方式。
生成器-评估器是一种质量控制方式。

你可以让生成器和评估器作为 Agent Teams 里的两个成员互相通信；
你也可以让主 Agent 负责协调，评估器作为子 Agent 负责检查；
你还可以把多个生成器、多个评估器组合成更复杂的工作流。

关键不是名字叫什么，而是每个角色有没有清晰职责。

如果一个 Agent 团队里，所有 Agent 都差不多，都在自由发挥，那它可能只是把混乱放大了。
真正有用的 Agent 团队，应该有明确分工：谁规划，谁实现，谁测试，谁整合，谁做最终检查。

十一、评估器该不该看生成器的思考过程？

还有一个细节很有意思。

有人问：评估器要不要看到生成器的完整上下文和思考过程？
这样是不是能更准确判断问题？

他们的建议是：要谨慎。

因为如果评估器看到生成器的思考过程，它可能会被生成器的思路带着走。
它可能会开始解释“为什么模型这么做”，而不是独立判断“这个输出到底对不对”。

更好的方式是：
评估器主要判断输出结果，而不是替生成器找理由。

这点对我们做代码评审也很有启发。

如果你看同事的代码，一开始就带着他的解释去看，你可能会更容易接受他的设计。
但如果你先独立看结果，看功能是否满足需求，反而更容易发现问题。

所以，评估器最好保持独立。

十二、读 Trace 是最快的学习方式

最后，他们反复提到一个很朴素的方法：读 Trace。

所谓 Trace，就是 Agent 运行过程中的完整记录。
它记录了模型做了什么、调用了什么工具、看到了什么结果、做了什么判断。

做 Agent 的时候，不能只看最终输出。
你要看它中间怎么想、怎么试、怎么失败。

播客里提到，Anthropic 团队会花很多时间读 Agent 的 trace。
他们甚至会一行一行看模型输出，理解它为什么这么判断，然后回头调整 prompt、评分标准或者工作流。

这个方法听起来不高级，但非常有效。

因为 Agent 系统的问题，很多时候不是模型完全不会，而是它在某些细节上判断错了。
只有读 trace，你才能知道它到底卡在哪里。

所以，做 Agent 最重要的能力之一，不是写很复杂的代码，而是愿意坐下来，认真看模型到底做了什么。

十三、最后总结

如果要把这场分享压缩成几个 takeaway，我觉得可以总结成六点。

第一，不要让 Agent 自己评估自己。
它很容易给自己的半成品找理由。

第二，压缩不等于交接。
真正可靠的是结构化状态、文件记录和清晰下一步。

第三，评估器必须严格。
模糊批评只会带来模糊改进，具体标准才能带来具体行动。

第四，主观质量也可以打分。
只要你把标准写清楚，模型就能逐步靠近目标。

第五，多读 Trace。
这是理解 Agent 行为最快的方式。

第六，先定义什么叫完成。
在动手之前，让 generator 和 evaluator 协商出一份可测试的 contract，比直接让模型开始写代码更重要。

最后，可以总结为一句话：

做 Agent，不是只问模型能不能完成任务，而是要问它怎么知道自己已经真正完成了任务。

真正有价值的 Agent 工作流，不是让模型自由发挥，而是给它清晰角色、严格标准、可追踪状态和可靠反馈。

这样，Agent 才能从“看起来能用”，变成“真的能用”。