為什麼智慧體在長任務中會遺忘並偏離軌道：AWS、Claude Code 和 Manus 解析四大框架

大型語言模型在執行長時間操作時經常失去焦點，偏離其最初目標——這是智慧體領域的一個持續挑戰。該問題通常並非源於模型本身，而是源於周圍的執行框架。AWS 最近釋出的雲程式設計智慧體設計指南清楚地指出了這一點：淺層智慧體會因上下文溢位而失去焦點，在長週期中迷失方向，且無法維持狀態。解決這一問題需要最佳化管理核心模型外部所有操作的“框架”（harness）。

對主流框架的全面審查揭示了這一關鍵層。LangChain Deep Agents、Claude Code、Manus、OpenAI Codex 和 Amazon Bedrock AgentCore 均利用四種關鍵機制——上下文預算、壓縮、任務狀態管理和跨會話記憶——將基本迴圈轉化為能夠處理複雜、長時間執行任務的強大智慧體。

最反直覺的發現是，簡單地擴大上下文視窗並不能解決問題。Chroma 的《上下文旋轉報告》評估了 18 個大型模型，結果顯示，即使在簡單的檢索任務中，隨著輸入長度的增加，模型的可靠性也會下降。Anthropic 解釋說，注意力機制為 n 個令牌生成二次成對關係，這意味著每個額外的令牌都會消耗注意力預算的有限部分。上下文是一種消耗性資源，而非無限容器。Manus 進一步指出，典型任務涉及大約 50 次工具呼叫，輸入與輸出的比率接近 100:1。因此，初始指令逐漸向視窗中心移動——這正是記憶退化最顯著的區域。

第一個引擎專注於上下文預算和解除安裝。Deep Agents 強制執行兩條嚴格規則：如果工具返回超過 20,000 個令牌，資料將寫入檔案系統，僅保留檔案路徑和 10 行預覽；當會話上下文超過視窗容量的 85% 時，較舊的編輯命令將被指標替換。Claude Code 在載入前應用類似的邏輯，將記憶體使用限制在 200 行或 25KB，MCP 工具模式預設為列出名稱並按需獲取詳細資訊。AWS AgentCore 的實施更為嚴格：協調器並行生成三個瀏覽器子智慧體，每個子智慧體都在自己的 MicroVM 中執行。分析子智慧體僅接收結構化結果，將預期持續時間縮短至 4-6 分鐘，而序列執行可能需要長達三倍的時間。

第二個引擎處理壓縮。當解除安裝不足時，框架會在接近容量限制時總結對話並重新啟動過程。Claude Code 的壓縮提示保留了架構決策和未解決的錯誤，同時丟棄冗餘輸出。壓縮後，它會重新讀取最後五個修改過的檔案，並重新注入相關的技能文字。它還將完整的原始記錄歸檔到磁碟，確保在總結過程中丟失的事實可以稍後檢索。Deep Agents 將目標保留視為一種結構特性，將總結文件組織為意圖、生成的輸出和下一步。壓縮也已整合到 API 層面：OpenAI 的 Responses API 透過 compact\_threshold 提供伺服器端壓縮，Codex 利用該功能處理長程式設計任務。Claude 平臺提供可自定義的壓縮設定，並支援寫入指令。

第三個引擎管理任務狀態和持久提醒。Manus 採用了一種簡單的方法：建立一個 todo.md 檔案並逐步勾選專案，有效地將目標嵌入上下文末尾，以對抗“淹沒在中間”的情況。然而，這種方法並非普遍有效：Deep Agents 在 0.7 版本（2026 年 7 月釋出）中使其待辦事項中介軟體變為可選，因為評估顯示禁用它略微提高了獎勵分數並降低了成本。LangChain 仍建議在長時間任務、較弱的模型以及需要進度可見性的介面中重新啟用此功能。

第四個引擎實現跨會話記憶。Claude Code 在每次壓縮週期後重新載入 CLAUDE.md 和自動記憶。AgentCore Memory 在後臺執行提取策略，使協調器能夠直接回憶之前的見解，而不是重新分析它們。然而，蘇黎世聯邦理工學院（ETH Zurich）的研究表明需謹慎：AGENTS.md 等上下文檔案通常不會提高成功率，但會使推理成本增加 20% 至 23%，每次重新載入都會對注意力預算徵收固定稅。因此，Claude Code 建議將 CLAUDE.md 保持在 200 行以下。

該研究得出結論，驗證框架是否真正“掌握目標”需要進行強制壓縮測試。最危險的模式是智慧體在總結後立即請求澄清，或錯誤地宣佈任務完成。最終，在漫長旅程中保持智慧體不偏離軌道，並不取決於模型的大小，而是取決於這些支援引擎的精確性。