https://knightli.com/zh-tw/tags/harness/ Recent content in Harness on KnightLi的博客 Hugo -- gohugo.io zh-tw Mon, 27 Apr 2026 08:19:02 +0800 https://knightli.com/zh-tw/2026/04/27/ralph-multi-agent-long-running-ai-workflows/ Mon, 27 Apr 2026 08:19:02 +0800 https://knightli.com/zh-tw/2026/04/27/ralph-multi-agent-long-running-ai-workflows/ <p>如果你最近在折騰 coding agent，很快就會遇到一個現實問題：<strong>AI 當然能幹活，但怎麼讓它連續幹幾個小時，還不在中途跑偏、忘要求、返工一堆？</strong></p> <p>圍繞 <code>Ralph</code> 和多智能體協同的這類討論，真正值得看的也正是這個問題。它不是單純比較某個模型有多強，而是把重點放在一層更實際的東西上：<strong>怎麼設計工作流，才能讓 AI 在長任務裡保持穩定輸出。</strong></p> <p>把這個問題拆開看，常見的路線主要有兩條：</p> <ul> <li><code>Ralph</code> 方案：不斷啟動新會話，透過檔案系統銜接上下文</li> <li>多智能體方案：主 Agent 做協調，子 Agent 分工執行</li> </ul> <p>如果把它壓成一句更好理解的話，這裡討論的其實不是「哪個模型更厲害」，而是「怎麼把 AI 組織起來，讓它更像一個能持續交付的小團隊」。</p> <h2 id="01-為什麼長時任務容易失控">01 為什麼長時任務容易失控 </h2><p>短任務裡，很多問題不明顯。你給一句指令，模型讀幾份檔案，改幾行程式碼，事情也就結束了。</p> <p>但任務一旦拉長，問題會集中冒出來：</p> <ul> <li>會話越來越長，上下文開始膨脹</li> <li>早先的要求被新資訊擠掉</li> <li>一個 Agent 既要想方案，又要寫程式碼，還要自己測，容易顧不過來</li> <li>沒有明確驗收環節時，看起來「做完了」，其實只是「說自己做完了」</li> </ul> <p>所以長時間運行 AI，真正考驗的往往不是模型單次輸出能力，而是 <strong>任務拆分、狀態銜接、角色分工和回饋回路</strong>。</p> <h2 id="02-ralph-方案把長任務拆成很多短回合">02 Ralph 方案：把長任務拆成很多短回合 </h2><p><code>Ralph</code> 的思路很適合先解決「上下文越跑越髒」這個問題。</p> <p>它的核心做法是：</p> <ul> <li>用循環不斷啟動新的 agent 會話</li> <li>每輪只處理一個足夠小的任務</li> <li>把跨輪狀態放到檔案裡，而不是全壓在同一個對話上下文裡</li> </ul> <p>這樣做的好處很直接：每次都是 fresh context，單輪會更聚焦，也更不容易被歷史訊息拖慢。</p> <p>如果你已經看過 <code>Ralph</code> 相關專案，會發現這套方法背後的邏輯很一致：</p> <ul> <li>當前任務寫在結構化檔案裡</li> <li>中間經驗寫到進度檔案裡</li> <li>程式碼變化留在 git 歷史裡</li> </ul> <p>換句話說，<code>Ralph</code> 不是試圖讓一個 Agent「永遠記住所有事」，而是主動把記憶外置，讓會話本身保持輕一點。</p> <p>這類方案特別適合下面幾種情況：</p> <ul> <li>任務已經能拆成一組小 story</li> <li>每個 story 都能在單個上下文視窗裡完成</li> <li>專案裡已經有測試、typecheck 或其他檢查機制</li> </ul> <p>它解決的是「如何讓 AI 一輪一輪穩定推進」。</p> <h2 id="03-多智能體方案把一個人做不完的事分出去">03 多智能體方案：把一個人做不完的事分出去 </h2><p>另一條路線是多智能體協同。</p> <p>從這類工作流設計思路來看，更值得推薦的通常是這種方式：主 Agent 不直接埋頭幹活，而是負責協調；子 Agent 各自處理開發、測試、檢查、驗收等不同任務。</p> <p>這和 <code>Ralph</code> 的區別在於：</p> <ul> <li><code>Ralph</code> 更像串行迭代</li> <li>多智能體更像並行分工</li> </ul> <p>如果任務裡天然有不同角色，多智能體會更順手。比如：</p> <ul> <li>一個 Agent 負責拆任務和寫執行計畫</li> <li>一個 Agent 負責具體實作</li> <li>一個 Agent 負責測試和驗證</li> <li>一個 Agent 負責回看結果是不是符合最初需求</li> </ul> <p>這樣做的價值不是「多開幾個視窗顯得很高級」，而是讓不同工作職責分離開。原來塞在一個 Agent 身上的幾件事，現在可以拆成幾個更明確的環節。</p> <p>一旦角色邊界清楚，很多問題都會變輕：</p> <ul> <li>寫的人不必同時當審的人</li> <li>跑測試的人不必重新推導整套需求</li> <li>主 Agent 不會被實作細節淹沒</li> </ul> <p>它解決的是「如何讓 AI 像一個小團隊那樣配合」。</p> <h2 id="04-真正關鍵的不是多開而是怎麼拆">04 真正關鍵的，不是多開，而是怎麼拆 </h2><p>無論是 <code>Ralph</code> 還是多智能體，最容易被忽略的一點都是：<strong>流程設計比多開幾個 Agent 更重要。</strong></p> <p>如果任務拆分不對，就算開再多 Agent，也只是把混亂並行化。</p> <p>比較穩的拆法通常有幾個特點：</p> <ul> <li>一個任務只對應一個明確目標</li> <li>一個角色只負責一類輸出</li> <li>每輪都有清楚的完成標準</li> <li>上一輪的結果能被下一輪直接消費</li> </ul> <p>比如比起給 AI 一個「把整個功能做完」的大指令，更穩的方式往往是：</p> <ul> <li>先拆出需求和邊界</li> <li>再拆實作</li> <li>再拆測試</li> <li>最後單獨做驗收</li> </ul> <p>這類拆法的好處是，問題一旦出現，更容易知道是出在理解、實作、測試，還是交付標準上。</p> <h2 id="05-為什麼驗收環節特別重要">05 為什麼驗收環節特別重要 </h2><p>很多 AI 工作流失敗，不是因為前面完全沒做事，而是因為最後缺了一個真正獨立的確認動作。</p> <p>在長任務裡，「已經生成結果」和「結果真的可用」之間，經常隔著一整層差距。</p> <p>這裡有個很值得重視的方向，就是把開發和驗收拆開看。哪怕不做到特別複雜，至少也應該把這些問題單獨問一遍：</p> <ul> <li>它真的完成了最初那條任務嗎</li> <li>有沒有只改表面、沒解決根因</li> <li>測試是不是只驗證了最順利的路徑</li> <li>有沒有把上游要求悄悄改掉</li> </ul> <p>只要這層檢查缺位，AI 很容易在長流程裡不斷「自我宣布成功」。</p> <h2 id="06-兩條路線怎麼選">06 兩條路線怎麼選 </h2><p>如果只是想快速判斷，可以先這麼理解：</p> <ul> <li>你最痛的是上下文膨脹和長會話失焦，先看 <code>Ralph</code></li> <li>你最痛的是一個 Agent 身兼多職、任務之間互相打架，先看多智能體</li> </ul> <p>再具體一點：</p> <ul> <li><code>Ralph</code> 更適合流程清楚、任務細碎、可以按回合推進的工作</li> <li>多智能體更適合角色明顯、需要並行和交叉驗證的工作</li> </ul> <p>很多時候，這兩條路也不是非此即彼。比較成熟的做法，反而可能是把它們組合起來：</p> <ul> <li>外層用 <code>Ralph</code> 這種迭代循環推進大任務</li> <li>內層在單輪裡再用多智能體處理研究、實作、測試和驗收</li> </ul> <p>這樣既能控制長上下文，又能提高單輪內部的協作效率。</p> <h2 id="07-一句話總結">07 一句話總結 </h2><p>這類方法最值得看的地方，不是單獨推薦了 <code>Ralph</code> 或多智能體，而是把一個很現實的問題講清楚了：<strong>讓 AI 長時間穩定工作，關鍵從來不只是模型本身，而是你有沒有把上下文、任務、角色和驗收設計好。</strong></p> <p>如果你已經開始讓 <code>Claude Code</code>、<code>Codex</code> 或其他 coding agent 處理更長的真實任務，這類工作流思路會比「再換一個更強模型」更值得優先補課。</p> https://knightli.com/zh-tw/2026/04/10/anthropic-harness-agent-os/ Fri, 10 Apr 2026 09:22:56 +0800 https://knightli.com/zh-tw/2026/04/10/anthropic-harness-agent-os/ <p>Anthropic 最近發佈了一篇關於 Harness 的工程實踐文章。表面上是在講產品實作，本質上回答的是一個更長期的問題：</p> <p><strong>當模型能力持續變化時，Agent 系統哪些層要穩定，哪些層應該允許快速替換？</strong></p> <h2 id="核心判斷">核心判斷 </h2><p>我對這篇文章的核心理解是：Agent 基礎設施會越來越像一個輕量的 <strong>Agent OS</strong>。</p> <p>重點不在「把今天的最佳流程寫死」，而在「定義長期穩定的系統抽象」。</p> <h2 id="為什麼這點重要">為什麼這點重要 </h2><p>很多 Agent 框架常見的問題是：</p> <ul> <li>把模型的臨時短板固化為永久架構</li> <li>把 prompt 工程誤當成系統邊界</li> <li>把一次有效的補丁寫成長期依賴</li> </ul> <p>模型會變強，今天合理的補丁，明天可能就是技術債。</p> <h2 id="anthropic-的解法從具體-harness-到-meta-harness">Anthropic 的解法：從具體 Harness 到 Meta-Harness </h2><p>這套思路不是承諾某一種固定編排方式，而是抽象出三層穩定介面：</p> <ol> <li><code>session</code>：可恢復的事件與狀態歷史</li> <li><code>harness</code>：推理與調度循環（brain）</li> <li><code>sandbox</code>：執行環境與工具能力（hands）</li> </ol> <p>它們分離後，系統更容易替換、恢復和擴展。</p> <h2 id="1-session-不是上下文視窗">1) Session 不是上下文視窗 </h2><p>一個關鍵觀點是：<strong>Session 不等於模型上下文。</strong></p> <p>Session 應該是可查詢、可回放、可恢復的事件日誌，而不是直接塞給模型的歷史拼接。</p> <p>這樣做的價值：</p> <ul> <li>trimming 不等於歷史消失</li> <li>compaction 不等於事實丟失</li> <li>崩潰恢復可以回到事件層，而不是依賴摘要記憶</li> </ul> <h2 id="2-harness-是可替換的編排層">2) Harness 是可替換的編排層 </h2><p>Harness 應專注於調度，而不是持有業務狀態。</p> <p>理想介面更接近：</p> <p><code>execute(name, input) -&gt; string</code></p> <p>這代表模型只需要關心「我能調用哪些能力」，而不必強綁具體設備、容器或作業系統。</p> <h2 id="3-sandbox-是手不是腦">3) Sandbox 是「手」，不是「腦」 </h2><p>當 brain 和 hands 解耦後：</p> <ul> <li>工具環境可以獨立演進</li> <li>不同基礎設施可以並行接入</li> <li>不必每個會話都預熱完整執行環境</li> </ul> <p>這會直接帶來更好的啟動與擴展表現。</p> <h2 id="效能與安全啟發">效能與安全啟發 </h2><p>這種拆分通常會同時改善效能和安全。</p> <p>效能上：</p> <ul> <li>可以先啟動 brain，再按需拉起 hands</li> <li>降低首 token 延遲（TTFT）</li> </ul> <p>安全上：</p> <ul> <li>不把高敏憑證直接暴露給模型</li> <li>用受控 proxy / vault 做間接憑證訪問</li> <li>安全邊界建立在系統約束上，而不是「模型應該做不到」</li> </ul> <h2 id="相關連結">相關連結 </h2><ul> <li><a class="link" href="https://claude.com/blog/claude-managed-agents" target="_blank" rel="noopener" >Usage patterns and customer examples</a></li> <li><a class="link" href="https://www.anthropic.com/engineering/managed-agents" target="_blank" rel="noopener" >The design of Claude Managed Agents</a></li> <li><a class="link" href="https://platform.claude.com/docs/en/managed-agents/quickstart" target="_blank" rel="noopener" >Onboarding, quickstart, overview of the CLI and SKDs </a></li> </ul>