随着模型能力不断增强，AI Agent 正在从“单轮对话助手”向“能够连续运行数小时甚至数天的自主系统”进化。然而，工程实践一再证明：让一个 Agent 在长时任务中持续、稳定地推进，远比想象困难。上下文窗口有限、会话之间没有记忆、反复返工、误判进度等问题，会让一个复杂项目在数轮执行后彻底失控。

就在昨天，Anthropic 发布了一套非常重要的工程方案，专门针对这些挑战而设计：基于“Initializer Agent + Coding Agent”的双 Agent 架构。
它的意义在于，它不是通过更大的模型、更长的上下文来对抗问题，而是通过一种工程化的工作流设计，确保 Agent 即使在“失忆”的多窗口条件下，也能像人类工程师一样一步步推进任务。

目录

• 为什么单 Agent 架构无法胜任长时任务？
• 双 Agent 架构：让 Agent 真正“像一个工程团队工作”
  • Initializer Agent：一次性奠定整个项目的工程基础
  • Coding Agent：每一轮只做一件事，但把它做好
• 双 Agent 如何解决长时任务中的结构性难题？
• 未来的方向：从双 Agent 到“Agent 工程团队”

为什么单 Agent 架构无法胜任长时任务？

要理解双 Agent 架构的价值，必须先理解单 Agent 为什么会失败。

一个长时任务，例如构建一个完整的 web 应用，往往涉及几十到数百个功能、多个模块、持续的调试与验证。而当前的模型虽然强大，但每一轮仍然必须在有限的上下文中工作。这意味着，每一次执行都是一次“记忆重置”。模型需要在短时间内重新理解项目、评估状态，并决定下一步行动。

在这种情况下，单 Agent 容易出现两类典型问题：

• 第一类问题是试图“一口气完成所有事情”。模型看到用户需求后，会选择实施一个非常激进的策略：直接开始大规模编码，直到上下文耗尽为止。但这种策略的后果是，它只能写出“半截代码”，不仅未完成、也未记录、没有测试，下一轮 Agent 接手时完全无法判断当前项目进展，从而花大量时间摸索现场。

• 第二类问题则刚好相反：模型在看到部分成果后，误以为项目已经完成。由于缺乏清晰的目标列表与结构化任务定义，模型可能在看到一些 UI、一些 API 或一些响应后，得出“功能齐全”的误解，进而直接终止任务。这种“过早宣布完成”的情况非常常见。

也就是说，Anthropic认为，当前AI Agent无法长时间稳定运行的核心问题不在模型能力，而在缺乏一种能够跨上下文继承任务逻辑的结构化工作方式。

为此，Anthropic提出了双Agent架构。

双 Agent 架构：让 Agent 真正“像一个工程团队工作”

Anthropic 的解决方案非常工程化：不是让一个 Agent 解决所有事情，而是将长时任务拆分为两种角色——一个负责奠基，一个负责迭代。

这个方法和此前大家逆向Claude Code非常相似：

其核心思想：

Claude Code 的核心逻辑建立在一个单一的主循环之上。所有历史消息都被维护在一个扁平的消息列表中，而不是层层嵌套的多代理对话树。

具体这方面也可以参考此前DataLearnerAI的博客：Claude Code 的独特体验：Claude Code 为什么这么好用？从设计细节看下一代 LLM Agent 的范式

这次是Anthropic官方解密这个双Agent价格，即Initializer Agent和Coding Agent。

Initializer Agent：一次性奠定整个项目的工程基础

Initializer Agent 的职责集中在第一次运行，它更像是一位“首席架构师”。
它不会立即进入编码，而是根据用户给出的高层需求，将项目转换为一个可长期维护的工程结构。

这包括三项关键内容：

第一，生成一个“可操作的需求体系”。
Initializer 不会让模型自己猜哪些功能是必要的，而是将用户需求分解为一份详尽的 JSON 结构的功能清单。每项功能都有描述、步骤和验收条件，并全部标记为“未完成”。这使得 Coding Agent 在未来的所有会话中都能明确自己的目标，不会误判进度，也不会跳过必要环节。

第二，创建状态记录机制。
Initializer 会写入一个 progress 文件，记录项目结构、重要说明和之后用于交接的上下文。它同时建立 git 仓库，让每个迭代都能被提交、恢复和追踪。状态记录机制使得未来的 Agent 不必猜测，而是能够基于事实继续推进工作。

第三，提供一个标准化的启动脚本。
Initializer 还会生成一个 init.sh，用于启动开发服务器并进行基础测试。这使得后续所有会话都能迅速验证当前环境是否健康，从而降低“接手时发现项目已坏”的风险。

这样，一个干净、结构化且可持续继承的工程现场就奠定完成了。

Coding Agent：每一轮只做一件事，但把它做好

在完成初始化之后，项目的推进交给 Coding Agent。它的工作方式不再是“尽可能写更多代码”，而是“每一轮修改都要增量、可靠、可验证”。

Coding Agent 的启动流程非常像工程师上班的第一小时：
它会先检查当前目录结构，阅读 git 记录，查看 progress 文件，运行 init.sh，并进行一次基本的端到端测试。它不是为了完成新功能，而是为了确认“现场是否正常”，避免在未知状态下开始工作。

接下来，Coding Agent 会从功能清单中选择一个未完成的功能，阅读它的验收步骤，然后进入真正的实现。
关键在于：

它每一轮只做一件事情。

且在编码完成后，它必须自行完成端到端测试，例如使用 Puppeteer 驱动浏览器，像真正用户那样操作应用：打开页面、点击按钮、输入内容、观察结果。
功能通过后，它会将 "passes": true 写回 JSON 清单，并提交一次 git commit，同时更新 progress 文件，让下一轮 Agent 一眼就能理解变化。

这种节奏虽然缓慢，但极其可靠。
它将“无人监督的长时任务”转换为“每轮可验证的开发迭代”，从而大幅提升任务的稳定性。

双 Agent 如何解决长时任务中的结构性难题？

这套方案之所以有效，是因为它从工程结构层面解决了单 Agent 无法克服的问题。

在这里，我们是稍微总结一下：

难题	单 Agent 的表现	双 Agent 的行为
缺乏任务目标体系	容易误判已完成	功能清单定义完整需求空间
无法继承状态	每轮重头理解项目	progress + git 确保上下文可读
容易写到一半崩溃	爆上下文，留下烂尾	Coding Agent 每轮只做一项功能
缺乏真实测试	代码可运行≠功能完整	自动化 e2e 测试确保真实性能
环境可能已损坏	下一轮无法判断为何损坏	init.sh 的统一自检流程使问题可见

本质上，这是第一次有人把“软件工程的工作流”正式编码进 Agent 架构中。

未来的方向：从双 Agent 到“Agent 工程团队”

Anthropic 的实现，是一个重要基点，但远没有结束。
他们提到，下一步可能会着手将这些角色进一步拆分为：

• 测试 Agent
• QA Agent
• 代码清理 Agent
• 文档 Agent
• 性能 Agent

从而形成真正意义上的“Agent 工程团队”。
这种趋势值得高度关注，因为它可能改写未来的软件开发方式。

这次的Anthropic推出的方案不是模型能力的提升，而是工程方法论的突破。结合此前Claude Skills等，Anthropic正在试图用工程方法来解决实际问题。不过也有人批评说，Anthropic无非是把实际过程遇到的问题写出来，甚至是之前用MCP创造问题，现在再来解决。

不过，可能本来AI Agent的发展就不是一帆风顺，会有各种问题，所以即使是这样的前沿企业可能也有很多坑要来回踩。