長運行 Agent
為什麼 Agent 跑不了長任務
讓 Agent 構建一個完整 Web 應用看似簡單，但現實中充滿了交接失敗和上下文斷裂的陷阱。
問題背景
給 Agent 的高層提示
"Build a clone of claude.ai"
這不是一個小任務。一個完整的聊天應用需要認證系統、對話管理、流式輸出、檔案上傳、Markdown 渲染、多輪歷史…加起來可能有 200+ 個獨立功能點。讓 Agent 從零到一完成這樣的項目，會遇到什麼問題？
失敗模式
One-shotting：一口氣做太多
最常見的失敗模式
Agent 試圖在一次會話中完成所有功能，結果：
- 上下文窗口在實現到一半時被用完
- 下一個 Agent 接手時，面對半成品程式碼，只能猜測前任做了什麼
- 大量時間浪費在讓基本功能重新跑起來，新功能反而沒時間做
- 即使有 Compaction（上下文壓縮）也不夠，壓縮後的指令不夠清晰，新 Agent 依然迷路
One-shotting 的典型時間綫
Agent 1 開始寫
寫了 50% 功能
上下文用完
Agent 2 接手
花時間修復半成品
上下文又用完
每次接手都忙於修復，推進陷入停滯
Premature Completion：過早宣佈完成
Agent 覺得「都差唔多啦」
Agent 看到已經實現了一些功能，就認為項目已經基本完成：
- 聲明項目完成，實際上只完成了核心功能的 30%
- 缺乏任務清單，Agent 不知道還差什麼沒做
- 沒有驗證機制，以為做完了但沒有端到端測試證明
模擬演示：看 Agent 如何崩潰
上下文窗口
0%
類比：失憶的換班工程師
想像一個軟件項目
每個工程師都只上一個班次。換班時完全失憶：不知道前一個人做了什麼、為什麼做、下一步該做什麼。每個人坐到電腦前，打開一堆半成品程式碼，只能從零開始理解。這就是沒有交接機制的長運行 Agent 的真實狀態。
核心洞察
長任務的核心挑戰是交接，動手做反而不難。Agent 並不缺乏能力，它缺的是在上下文斷裂時維持連續性的機制。解決交接問題，才能解決長運行問題。