<div id="readability-page-1">Anthropic 再发 Agent 工程实践神文：Effective harnesses for long-running agents（适用于长期运行 Agents 的有效工具），强烈建议大家围观阅读 之前我介绍过 Anthropic Agent 文章合集这里： <blockquote> <ul> <li>Agent 下半场！比 Prompt 更重要的是「上下文工程」，Anthropic 首次系统阐述</li> <li>万物皆可 Agent！Anthropic 官方 “三步循环法” 手把手教你造最强智能体</li> <li>Anthropic 又出王炸！一个文件夹，把 Claude“调教” 成真正可以干活的 Agent</li> <li>Anthropic 又一篇 Agent 开发神文，新范式让 Token 消耗暴降 98.7%</li> </ul> </blockquote> 随着 AI Agent 能力的提升，开发者开始要求它们承担跨越数小时甚至数天的复杂任务。然而，如何让 Agent 在多个上下文窗口之间保持一致的进度，仍然是一个未解难题 长程 Agent 面临的核心挑战在于，它们必须分 “会话”（Session）工作，而每个新会话开始时都像是一个没有过往记忆的新工程师接班。由于上下文窗口有限，且复杂项目无法在单一窗口内完成，Agent 需要一种机制来弥合编码会话之间的鸿沟 Anthropic 工程团队通过观察人类工程师的工作方式，为 Claude Agent SDK 开发了一套包含两个部分的解决方案：初始化 Agent（Initializer Agent）和编码 Agent（Coding Agent） <h2>核心挑战：上下文压缩还不够</h2> Claude Agent SDK 是一个通用的 Agent 框架，具备上下文管理功能（如压缩），理论上应能让 Agent 无限期工作 但在实际测试中（例如要求最新的 Opus 4.5 构建一个 claude.ai 的克隆版），仅靠上下文压缩是不够的。Claude 主要表现出两种失败模式： 1.试图一次性完成所有工作：Agent 倾向于在一次会话中做太多事，导致中途耗尽上下文，留下的功能只完成了一半且缺乏文档。下一个会话的 Agent 必须猜测之前发生了什么，浪费大量时间修复基础应用 2.过早宣布完工： 在项目后期，新的 Agent 实例看到已经有一些功能，就误以为整个工作已完成 <h2>解决方案：双 Agent 架构</h2> Anthropic 将问题分解，提出了双重解决方案： 初始化 Agent： 第一个会话使用专用提示词，负责搭建环境。包括生成<code>init.sh</code>脚本、记录进度的<code>claude-progress.txt</code>文件，以及展示文件添加情况的初始 Git 提交 编码 Agent： 后续的每一个会话都致力于取得增量进展，并留下结构化的更新 这一方案的关键在于让 Agent 在开启新窗口时能迅速理解工作状态——这主要通过<code>claude-progress.txt</code>文件和 Git 历史记录来实现 <h2>环境管理的三大支柱</h2> 为了支持这种工作流，环境设置包含以下关键组件： 1. 功能列表（Feature List） 为了防止 Agent 一次性蛮干或过早结束，初始化 Agent 被要求编写一个包含所有功能需求的详细文件。在 claude.ai 克隆案例中，这包含超过 200 个功能点。 这些功能最初都被标记为 “failing”（未通过），为后续 Agent 提供了清晰的工作全景图 JSON 文件示例： <pre><code>{ &#34;category&#34;: &#34;functional&#34;, &#34;description&#34;: &#34;New chat button creates a fresh conversation&#34;, &#34;steps&#34;: [ &#34;Navigate to main interface&#34;, &#34;Click the 'New Chat' button&#34;, &#34;Verify a new conversation is created&#34;, &#34;Check that chat area shows welcome state&#34;, &#34;Verify conversation appears in sidebar&#34; ], &#34;passes&#34;: false }</code></pre> 实验发现，使用 JSON 格式优于 Markdown，因为模型不太容易错误地更改或覆盖 JSON 文件。同时，提示词需包含强硬指令，禁止删除或编辑测试，只允许更改<code>passes</code>字段的状态 2. 增量进展（Incremental Progress） 有了初始脚手架后，编码 Agent 被要求一次只做一个功能 为了保持环境整洁，Agent 需要在每次代码变更后： 通过 Git 提交代码，并附带描述性信息； 在进度文件中撰写摘要 这使得模型可以利用 Git 回滚错误代码，恢复到工作状态，避免了后续 Agent 需要猜测前任做了什么的情况。 3. 端到端测试 Claude 的另一个主要失败模式是：在没有适当测试的情况下标记功能为完成。它往往只做单元测试或简单的 curl 命令，却忽略了端到端的验证。 解决方案是明确提示 Claude 使用浏览器自动化工具（如 Puppeteer MCP server），像人类用户一样进行测试。通过让 Claude 看到屏幕截图，它能识别并修复代码中不明显的 Bug <h2>快速上手流程（Getting up to speed）</h2> 基于上述架构，每个编码 Agent 在会话开始时都会被提示执行一系列标准步骤： <blockquote> 1. 运行 <code>pwd</code> 查看当前工作目录。 2. 阅读 Git 日志和进度文件，了解最近完成了什么。 3. 阅读功能列表文件，选择一个未完成的最高优先级功能。 4. 运行 <code>init.sh</code> 启动开发服务器。 5. 在实现新功能前，先运行基本的端到端测试，确保应用未处于损坏状态。 </blockquote> 典型会话流程示例： <blockquote> [Assistant] 我先了解一下项目当前状态。 [Tool Use] <code>&lt;bash - pwd&gt;</code> [Tool Use] <code>&lt;read - claude-progress.txt&gt;</code> [Tool Use] <code>&lt;read - feature_list.json&gt;</code> [Assistant] 检查 Git 日志... [Tool Use] <code>&lt;bash - git log --oneline -20&gt;</code> [Assistant] 检查是否有启动脚本并重启服务器... [Assistant] 现在验证基本功能是否正常... [Assistant] 验证通过。现在我查看 tests.json 决定下一步做什么。 </blockquote> <h2>常见故障模式与修复方案总结</h2> <img src="https://imageproxy.pbkrs.com/https://wpimg-wscn.awtmt.com/b470e2a2-bb44-4ba7-888e-fa26ebb56525.png?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" width="829" height="282" original-src="https://imageproxy.pbkrs.com/https://wpimg-wscn.awtmt.com/b470e2a2-bb44-4ba7-888e-fa26ebb56525.png"/> <h2>写在最后</h2> 这项研究展示了长程 Agent 框架的一种可行方案，但仍有未解决的问题： 单 Agent vs 多 Agent：目前尚不清楚是通用的编码 Agent 表现最好，还是采用多 Agent 架构（如专门的测试 Agent、QA Agent、代码清理 Agent）更优 领域泛化：本演示针对全栈 Web 开发。未来方向是将这些经验推广到科学研究或金融建模等其他长程任务领域 风险提示及免责条款 市场有风险，投资需谨慎。本文不构成个人投资建议，也未考虑到个别用户特殊的投资目标、财务状况或需要。用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资，责任自负。</div>

谷歌-C

Anthropic 发布新文章探讨长期运行 Agent 的工程实践，提出解决长程任务难题的方法。文章介绍了如何通过模拟人类工程师的工作方式，为 Claude Agent SDK 开发初始化 Agent 和编码 Agent 两部分解决方案，以应对上下文窗口限制和复杂任务的挑战。

- Anthropic 提出双 Agent 架构以解决长程 Agent 的上下文管理问题。  
- 初始化 Agent 负责环境搭建，编码 Agent 进行增量进展。  
- 该方案通过 Git 和进度文件提高了工作效率，减少了错误。  

Anthropic 再发 Agent 神文：像人类工程师一样思考，解决「长程任务」难题