# 策展 · X (Twitter) 🔥

> 作者：sysls (@systematicls) · 平台：X (Twitter) · 日期：2026-03-30

> 原始來源：https://x.com/i/article/2038149772901806080

## 中文摘要

長期自主 Agent 工作流設計的核心挑戰在於克服 Agent 偷懶走捷徑或邏輯混亂的傾向。本文深入分析了 Agent 在各階段可能出現的「愚蠢」表現，以及如何透過客製化的任務協調框架（harness）系統地解決這些問題。

**任務前置階段的資訊不完整**

Agent 常因上手前缺乏充分脈絡而採取錯誤行動。解決方案是在任務開始前系統性地檢查資訊的完整性和矛盾之處，因為這些問題一旦啟動就會不斷擴大。這涉及確保程式庫內沒有相互矛盾的資訊，進而防止錯誤的決策層疊。

**規劃階段的陷阱**

Agent 在攻擊向量選擇上常犯兩類錯誤：
- 因資訊不足或誤解使用者需求而選擇完全錯誤的方向——這是目前最常見的問題
- 採取短視的快速修復方案，累積技術債務（這類似於聘用廉價工程人力的風險）

應對策略包括：要求 Agent 在規劃前涵蓋所有相關文件；在規劃階段提醒 Agent 考慮可擴展性、程式碼可維護性和軟體工程最佳實踐；讓 Agent 生成多個方案（例如 5 個），再由另一個 Agent 挑選最符合「乾淨程式碼原則」的方案。

**任務執行期的脈絡耗盡**

這是最大的瓶頸。當面對涉及數百萬個 token 的複雜多輪對話時，Agent 會產生「脈絡焦慮」——隨著時間推進，它們越來越急於結束會話。Claude 特別容易出現此問題。解決方案是進行智慧的會話交接（session handoff），透過設計高密度的交接提示詞來最大化脈絡保真度——利用你對程式庫結構的深刻理解，做得比基礎模型提供商更好的資訊壓縮。

**計劃偏離（Planning Stickiness）**

Agent 常在執行中違背原有計劃，執行接近但不完全符合預期的替代方案（A' 而非 A）。這不僅影響當前任務，更危險的是後續依賴該結果的程式碼全被「接線到」了錯誤的實現上。解決方案是頻繁且早期地驗證任務完成情況是否符合預期，防止連鎖失敗。

**複雜性恐懼**

Agent 害怕複雜任務，會傾向於編寫程式碼樁（stub）或宣稱超出會話範圍。這源於強化學習過程中對複雜任務頻繁出錯的懲罰。對策是將龐大任務拆分成數百個小於百行程式碼的子任務，降低「啟動能量」——這反映了 Agent 心理確實是以人類心理為藍本。

**驗證中的懶惰**

Agent 傾向於撰寫脆弱的測試，觀看測試通過就宣告成功，特別是在脈絡壓力大時。它們可能為行為 A' 編寫測試，儘管函式應該實現行為 A。解決方案是由新鮮脈絡下的專門 Agent 規劃驗證，並驗證實際生產環境的行為——例如測試按鈕時應截圖確認、模擬點擊、驗證後端回應，而非只測試泛用按鈕邏輯。

**程式庫熵最大化**

Agent 編寫勉強可用的程式碼，卻不減少程式庫中的熵。修改函式 X 的行為後不更新文件，重複 100 次就造成維護困難。解決方案是在每個長期會話後配置一個新鮮脈絡的 Agent，清理狀態、解決矛盾、處理合併衝突、移除死程式碼和過期文件。

**為何需要客製化框架**

原生工具（Claude Code、Codex）的內建功能極其有限。關鍵在於，讓 Claude 充當協調器會導致框架充斥與實際任務清單無關的協調脈絡。自有框架允許你實現客製化工作流：例如建立專責 Agent 監督「演算法契約」達成狀況，或在高複雜度檢測時自動拆分任務，或在會話結束前檢查變更的影響範圍。

最關鍵的是收集詳細的遙測資料（提示詞、追蹤、結果）並建立評分基準，持續迭代改進框架。

## 標籤

Agent, 教學資源