Anthropic 再發 Agent 神文：像人類工程師一樣思考，解決「長程任務」難題

Anthropic 再發 Agent 工程實踐神文：Effective harnesses for long-running agents（適用於長期運行 Agents 的有效工具），強烈建議大家圍觀閲讀

之前我介紹過 Anthropic Agent 文章合集這裏：

• Agent 下半場！比 Prompt 更重要的是「上下文工程」，Anthropic 首次系統闡述
• 萬物皆可 Agent！Anthropic 官方 “三步循環法” 手把手教你造最強智能體
• Anthropic 又出王炸！一個文件夾，把 Claude“調教” 成真正可以幹活的 Agent
• Anthropic 又一篇 Agent 開發神文，新範式讓 Token 消耗暴降 98.7%

隨着 AI Agent 能力的提升，開發者開始要求它們承擔跨越數小時甚至數天的複雜任務。然而，如何讓 Agent 在多個上下文窗口之間保持一致的進度，仍然是一個未解難題

長程 Agent 面臨的核心挑戰在於，它們必須分 “會話”（Session）工作，而每個新會話開始時都像是一個沒有過往記憶的新工程師接班。由於上下文窗口有限，且複雜項目無法在單一窗口內完成，Agent 需要一種機制來彌合編碼會話之間的鴻溝

Anthropic 工程團隊通過觀察人類工程師的工作方式，為 Claude Agent SDK 開發了一套包含兩個部分的解決方案：初始化 Agent（Initializer Agent）和編碼 Agent（Coding Agent）

核心挑戰：上下文壓縮還不夠

Claude Agent SDK 是一個通用的 Agent 框架，具備上下文管理功能（如壓縮），理論上應能讓 Agent 無限期工作

但在實際測試中（例如要求最新的 Opus 4.5 構建一個 claude.ai 的克隆版），僅靠上下文壓縮是不夠的。Claude 主要表現出兩種失敗模式：

1.試圖一次性完成所有工作：Agent 傾向於在一次會話中做太多事，導致中途耗盡上下文，留下的功能只完成了一半且缺乏文檔。下一個會話的 Agent 必須猜測之前發生了什麼，浪費大量時間修復基礎應用

2.過早宣佈完工： 在項目後期，新的 Agent 實例看到已經有一些功能，就誤以為整個工作已完成

解決方案：雙 Agent 架構

Anthropic 將問題分解，提出了雙重解決方案：

初始化 Agent： 第一個會話使用專用提示詞，負責搭建環境。包括生成init.sh腳本、記錄進度的claude-progress.txt文件，以及展示文件添加情況的初始 Git 提交

編碼 Agent： 後續的每一個會話都致力於取得增量進展，並留下結構化的更新

這一方案的關鍵在於讓 Agent 在開啓新窗口時能迅速理解工作狀態——這主要通過claude-progress.txt文件和 Git 歷史記錄來實現

環境管理的三大支柱

為了支持這種工作流，環境設置包含以下關鍵組件：

1. 功能列表（Feature List）

為了防止 Agent 一次性蠻幹或過早結束，初始化 Agent 被要求編寫一個包含所有功能需求的詳細文件。在 claude.ai 克隆案例中，這包含超過 200 個功能點。

這些功能最初都被標記為 “failing”（未通過），為後續 Agent 提供了清晰的工作全景圖

JSON 文件示例：

{     "category": "functional",     "description": "New chat button creates a fresh conversation",     "steps": [       "Navigate to main interface",       "Click the 'New Chat' button",       "Verify a new conversation is created",       "Check that chat area shows welcome state",       "Verify conversation appears in sidebar"     ],     "passes": false }

實驗發現，使用 JSON 格式優於 Markdown，因為模型不太容易錯誤地更改或覆蓋 JSON 文件。同時，提示詞需包含強硬指令，禁止刪除或編輯測試，只允許更改passes字段的狀態

2. 增量進展（Incremental Progress）

有了初始腳手架後，編碼 Agent 被要求一次只做一個功能

為了保持環境整潔，Agent 需要在每次代碼變更後：

通過 Git 提交代碼，並附帶描述性信息；

在進度文件中撰寫摘要

這使得模型可以利用 Git 回滾錯誤代碼，恢復到工作狀態，避免了後續 Agent 需要猜測前任做了什麼的情況。

3. 端到端測試

Claude 的另一個主要失敗模式是：在沒有適當測試的情況下標記功能為完成。它往往只做單元測試或簡單的 curl 命令，卻忽略了端到端的驗證。

解決方案是明確提示 Claude 使用瀏覽器自動化工具（如 Puppeteer MCP server），像人類用户一樣進行測試。通過讓 Claude 看到屏幕截圖，它能識別並修復代碼中不明顯的 Bug

快速上手流程（Getting up to speed）

基於上述架構，每個編碼 Agent 在會話開始時都會被提示執行一系列標準步驟：

1. 運行 pwd 查看當前工作目錄。

2. 閲讀 Git 日誌和進度文件，瞭解最近完成了什麼。

3. 閲讀功能列表文件，選擇一個未完成的最高優先級功能。

4. 運行 init.sh 啓動開發服務器。

5. 在實現新功能前，先運行基本的端到端測試，確保應用未處於損壞狀態。

典型會話流程示例：

[Assistant] 我先了解一下項目當前狀態。
[Tool Use] <bash - pwd>
[Tool Use] <read - claude-progress.txt>
[Tool Use] <read - feature_list.json>
[Assistant] 檢查 Git 日誌...
[Tool Use] <bash - git log --oneline -20>
[Assistant] 檢查是否有啓動腳本並重啓服務器...
[Assistant] 現在驗證基本功能是否正常...
[Assistant] 驗證通過。現在我查看 tests.json 決定下一步做什麼。

常見故障模式與修復方案總結

寫在最後

這項研究展示了長程 Agent 框架的一種可行方案，但仍有未解決的問題：

單 Agent vs 多 Agent：目前尚不清楚是通用的編碼 Agent 表現最好，還是採用多 Agent 架構（如專門的測試 Agent、QA Agent、代碼清理 Agent）更優

領域泛化：本演示針對全棧 Web 開發。未來方向是將這些經驗推廣到科學研究或金融建模等其他長程任務領域

風險提示及免責條款

市場有風險，投資需謹慎。本文不構成個人投資建議，也未考慮到個別用户特殊的投資目標、財務狀況或需要。用户應考慮本文中的任何意見、觀點或結論是否符合其特定狀況。據此投資，責任自負。