長跑型多代理系統的 Harness 設計

長跑型多代理系統，最常死在小地方。記憶污染、提示詞漂移、上一個 agent 的半成品推理，全都會混進下一步。

這篇講的 Harness Engineering，做法很直白。每次都開新的 Claude Code process。再把 Planner 的輸出轉成 JSON，才交給 Generator。

聽起來很樸素，但很實用。因為它把「思考」和「執行」切開了。長時間跑任務時，這種切法比花俏 prompt 更重要。

為什麼要重置 context

很多多代理系統，會把對話歷史當共享工作區。短任務還行。任務一長，就開始出事。

Planner 會試很多方向。它也可能改主意。那些試探性推理，根本不該流到執行層。可是一旦共用 context，Generator 就可能吃到這些髒資料。

重置 context 的核心，就是讓每個 agent 各跑各的。Generator 不繼承 Planner 的內心戲。它只拿到一個任務 payload，然後照著做。這樣出錯時，也比較好查。

• 每次執行都從新 process 開始
• Planner 輸出先變成 JSON
• Generator 只看最終任務定義
• 上下文污染會少很多

這不是什麼記憶魔法。這是介面設計。講白了，就是把 Planner 當上游編譯器，把 Generator 當下游 runtime。

從對話變成任務規格

這個設計最漂亮的地方，就是把 Planner 的輸出先整理成 JSON。Planner 可以自由思考。真正送到下一步的，只保留必要資訊。

這樣比直接傳文字乾淨很多。因為 JSON 會逼你把欄位講清楚。目標、限制、輸入、輸出，全部都能明確命名。Generator 看到的不是聊天紀錄，而是任務規格。

對做 agent 系統的團隊來說，這還有一個好處。log 比較好看。你可以直接 diff 任務物件，也能先驗證欄位，再決定要不要送去執行。

• Planner 輸出會先被過濾
• JSON 讓任務邊界很明確
• 結構化欄位比自由文字好驗證
• 執行紀錄更容易稽核

這種設計一開始不太炫。真的。可是系統一拉長，你就會發現，介面品質比 prompt 內容更值錢。

Anthropic 怎麼看這件事

Anthropic 在 Claude Code 文件裡講得很直接。它說，Claude Code 是一個直接在 terminal 運作的 agentic coding tool。

“Claude Code is an agentic coding tool that operates directly in your terminal.” — Anthropic

這句話很有意思。因為它把產品定位成執行工具，不是聊天玩具。既然是執行工具，外層 harness 就該幫它隔離雜訊。

新 process 和結構化 prompt，正好就是這個用途。它們不是在加戲。它們是在保護執行層，別被上游的混亂狀態拖下水。

說真的，這對長時間任務很重要。你跑個幾分鐘還好。跑幾小時、幾十個 job 之後，沒有這層保護，系統很容易開始鬼打牆。

跟其他 agent 架構比起來

很多框架會讓多個步驟共用同一條 conversation thread。做 demo 很方便。做正式系統，就很危險。

因為一個 agent 的半成品推理，會變成下一個 agent 的背景知識。系統慢慢就不像 pipeline，比較像群組聊天室。這種架構很難保證穩定。

相對地，context-reset 模型把每一步當獨立計算。Planner 先產出 task description。Generator 只執行 task。兩者之間沒有隱性記憶。

• Claude Code 的新 process 模式，隔離性比較好
• OpenAI Codex 類型的 loop，適合快速原型
• LangGraph 適合狀態圖很複雜的 orchestration
• JSON task spec 比自由 prompt chain 更好測試

當然，重置 context 不是沒代價。你會失去一些對話連續性。可是對長跑系統來說，這個代價通常值得付。穩定執行，比聰明地重用記憶更重要。

這代表什麼產業脈絡

現在很多團隊都在做 agentic workflow。從內部自動化，到 code generation，再到研究助理，大家都想把 LLM 接進工作流。

問題是，很多人先想「怎麼讓 agent 記得更多」。我反而覺得，先想「哪些東西不該記住」更實際。當任務變長，少記一點，常常比多記一點更可靠。

這也解釋了為什麼結構化資料越來越重要。不是每一步都要聊天。很多時候，直接傳 JSON、schema、或 task object 就夠了。這跟傳統軟體工程很像。介面定義清楚，系統才跑得久。

我覺得接下來一年，做得好的多代理系統，會更像 typed pipeline，而不是一串 prompt。誰能把 agent 之間的邊界定清楚，誰就比較少踩 prompt drift 的坑。

你可以怎麼用這套思路

如果你自己也在做 Harness，我會先問一個問題。每個 step 真的都需要 conversational memory 嗎？如果不需要，就把 context reset 掉。

再來，把 Planner 的輸出改成結構化資料。目標、限制、輸入、驗收條件，都寫進 JSON。Generator 只吃這份資料，不吃聊天紀錄。這樣做，debug 會輕鬆很多。

最後，先在介面層做驗證。不要等到 LLM 亂寫完才補救。你可以在送進執行層前檢查欄位、型別、長度，甚至先做 schema validation。這些工作看起來土，卻很值。

我的預測很簡單。接下來的 agent 系統，會越來越少靠長對話記憶。更多團隊會改用短生命週期的 process，加上 JSON 任務流。你如果現在就在做這件事，後面會少掉很多 debug 地獄。

如果你在設計自己的 multi-agent workflow，先別急著加更多 memory。先把邊界切乾淨。這件事，通常比加一個更大的 prompt 有用得多。