Long-Running Agent设计范式：Planner + Executor + Evaluator

发表于 更新于

一、Anthropic在long-running agent方面的实践脉络

过去六个月，Anthropic的Engineering Blog 有三篇long-running agent主题的文章。时间线是：

2025.09，Effective context engineering for AI agents

2025.11，Effective harnesses for long-running agents

2026.03，Harness design for long-running application development

回头看，发现这三篇实践有明显的演进脉络，每一篇都在回应上一篇遗留下来的“坑”，

1、Context 用完了，但任务没搞定

第一篇文章讲的是 context engineering，核心结论是：context 是有限资源，随着 token 增加，模型的注意力会退化（context rot）。对于长程任务，提出了compaction、structured note-taking、sub-agent 三个方向。

image.png

2、Compaction 也没用，Agent 还是会失败

第二篇发现，即使用了 compaction，long-horizon agent 还是可能失败：

1、试图在单次会话里完成所有任务，上下文耗尽但任务没完，下一个会话的 agent 要先猜发生了什么再继续，每次都在浪费 token；

2、提前宣布完工，做了一部分觉得差不多了就停。Anthropic 把后者叫”上下文焦虑”，在 Sonnet 4.5 上比较明显。

解决方案是拆成两个 agent：initializer agent 负责第一次搭环境，coding agent 在每次会话里做增量功能。

3、任务虽然完成了，但质量不行

第三篇发现随着模型升级，上下文焦虑基本消失了，但新问题出现：agent 完成任务后习惯美化自己的工作质量。做 AI Coding 的人应该都遇到过——任务跑完，模型反馈”完美”、”搞定”，实际上可能还有明显 bug。

解决方案是引入独立的、挑剔的 Evaluator Agent，通过它的反馈驱动 Executor 持续优化。至此，结构收敛到 Planner + Executor + Evaluator

二、为什么说Planner + Executor + Evaluator是通用的

虽然Planner、Executor、Evaluator是从Coding领域实践出来的，但它们其实具备很强的通用性

1、Planner解决的是目标过大的问题，把模糊目标转化成可执行单元。在需求交付场景，Planner把复杂的大需求拆成N个简单的小需求。推广开来，写一份行业研报也需要先拆成数据收集、竞品分析、结论撰写等子任务

2、Executor解决的是跨会话带来的上下文丢失问题。在coding场景，靠进度文件、git commit log 和测试来维持连贯性。在其他场景下，任何多步骤流程都需要检查点和版本管理，让下一个会话的 agent 知道从哪继续

3、Evaluator 解决的是自我评价虚高问题。在coding场景，代码能跑不代表没bug。同样的，在SRE场景，执行完预案也不代表服务恢复。需要独立的评估角色，再做一次double check

可以说，任何需要agent在多个context window里持续长时间工作的场景，都可以通过这几个Agents的组合来搞定。

三、一些值得借鉴的细节点

如果你在构建面向复杂任务的long-running agent，这几篇文章强烈推荐仔细读，有一些细节点很值得借鉴

1、任务拆解用json，而不是markdown

Manus最开始用todo.md来维持Agent在长程任务下的注意力。但Claude code的实践发现，json格式效果会更好。原因也很简单，大模型对markdown文件操作起来会很随意，容易改错格式，修改不相关内容。json的强结构可以约束模型的行为，改错之后也能更快发现。

从著名的“开源项目”Claude code中也能验证这一说法，所有任务都以json格式存在于.tasks/目录下

image.png

2、让Agent快速进入工作状态的prompt

在长程任务中，Executor要通过多个会话完成整体的目标。在新会话创建后，可以通过这三步让Agent快速进入工作状态，

    1. 执行 pwd 来识别当前工作目录，仅可以编辑这个目录下的文件
    1. 读取git的提交日志和进度文件，以便更快理解最近的工作内容
    1. 阅读任务列表文件，并选择尚未完成且优先级最高的功能进行开发

虽然看起来简单，但不做这一步，Agent在没有上下文背景时，会花大量token和时间理解自己下一步该干什么

3、Evaluator，验收评估

Evaluator分两类，一类叫“对不对”，用于验证Executor的正确性；一类叫“好不好”，用于验证Executor产出物的质量。

比如，在Coding领域的Evaluator是测试用例，它主要用于验证代码是否有bug，实现层面是否正确。TDD（Test-Driven-Development）是历史上很流行的开发框架。

对于评估“好不好”这件事，我认为是最难设计的部分，说“好不好”更多是主观判断，具体要怎么量化？

Anthropic在前端设计场景的做法值得借鉴，他们没有试图定义”什么是美”，而是把问题转换成”是否符合良好设计的原则”，然后拆成四个可检查的维度：设计质量、原创性、工艺（字体层级、间距一致性等）、易用性。

所有的主观评价都可以转成结构化、多维度的客观度量标准。明确度量标准之后，Evaluator就能把具体的改进建议给到Executor，迭代几轮之后，质量自然上去了。

四、Evaluator的未完待续

Evaluator 可能是整个结构里最不讨喜的角色，它的工作就是不断告诉 Executor “你没做好”。但少了它，agent的输出质量就只能靠运气。

怎么设计一个好的 Evaluator，也值得单独写一篇文章，后续我们再展开聊聊。