Agent 最像魔法的地方，通常不是最難的地方。

先看一個很蠢、但很真實的事故。

這篇文章進自動流程時，子任務一度回報「完成」。照理說機器可以收工了。但系統狀態多查一眼，真正的流程還在跑，品質檢查還沒過，文章根本不能發。

這就是 Agent 工程最殘酷也最有用的一課：Agent 說完成，不等於系統真的完成。

真正可靠的 Agent，不是會講漂亮完成報告的 Agent，而是會把進度寫下來、會被機器驗收、出錯時查得到紀錄、工具也不會亂摸的 Agent。換句話說，模型只是駕駛；工程系統才是儀表板、煞車、車道線和行車紀錄器。

@HiTw93 這篇長文剛好把這件事拆得很完整。它不是在問「哪個模型最強」，而是在回答一個更工程現場的問題：Agent 要怎麼從展示玩具變成真的能交付工作的系統？

如果不想一次吞下所有名詞，可以只帶著三個問題讀：

  1. Agent 怎麼知道下一步要做什麼？
  2. Agent 怎麼知道自己做對了？
  3. Agent 出錯時，工程師怎麼抓得到原因？

後面會講很多零件，但先不用背名字。它們其實都在服務同一件事：讓 Agent 的行為可以被約束、被驗證、出錯時查得到原因，而不是只靠「模型應該懂吧」這種玄學保佑。

如果只記一件事，大概是這句：讓 Agent 會動不難，讓它跑穩才難。

這篇比較像一張事故地圖：先看哪裡會爆，再看工程上怎麼補。爆點一路變大：一開始只是迴圈亂跑，接著是完成報告失真，再來是上下文變髒，最後變成多個 Agent 互相踩腳。

放回 gu-log 前面幾篇看，這篇比較像總配電盤：SP-197 講 Codex /goal 怎麼把可驗收狀態寫進檔案，SP-192 講長跑 Agent 怎麼避免勤奮地跑偏，SP-158 講執行紀錄和評分回饋怎麼讓系統真的變好，SP-135 則把檔案系統記憶這件事拆開來講。HiTw93 這篇剛好把這些線接成一張工程現場地圖。

Clawd 偷偷說：

很多 Agent 產品展示看起來像鋼鐵人管家，實作打開常常像宿舍延長線：模型、工具、資料庫、瀏覽器、命令列、日誌，全插在一起。會動，甚至很神。但一旦出事，沒有人知道是哪個插頭冒煙。

事故一：控制迴圈會跑，不代表任務會完成

先把 Agent 拆到最小，其實沒有那麼神祕。

最小版 Agent 控制迴圈幾乎就是一個 while 迴圈：把使用者輸入丟給模型；模型如果要用工具，外部系統就執行工具，再把結果餵回去；模型如果回純文字，任務結束。

這個迴圈可以叫做：感知、決策、行動、回饋。聽起來很像魔法，其實像一個一直問「下一步呢？」的工程流程。

真正麻煩的是：控制迴圈會跑，不代表任務會被正確完成。

很多產品掛著 Agent 的招牌，拆開看比較像固定流程：路線早就寫死，只是每一步換成 LLM 處理。這不是壞事。任務固定、驗收清楚時，固定流程反而更穩。硬把所有事情都交給完整自主 Agent，像叫消防車澆桌上的多肉植物。車來了、梯子架好了、水管接好了，多肉淹死了。

@HiTw93 原文列了幾種常見控制模式：提示鏈、路由、並行、編排器-工作者、評估器-優化器。這些名字不用背。比較重要的是知道它們在回答同一個問題：這件事到底該由程式決定路徑，還是讓模型動態決定下一步？

如果答案是「流程很清楚」，先用固定流程。只有當任務需要探索、判斷、跨多個工具動態調整時，才真的需要 Agent。

Clawd 吐槽時間：

Agent 控制迴圈像一台可以自己踩油門的車。問題不是它會不會動，問題是路線、煞車、儀表板、保險、行車紀錄器有沒有裝。很多展示只喊「你看它會動！」，工程現場會問：「撞到誰算誰的？」

事故二：Agent 說完成，但沒有人驗收

這一點剛剛才現場打臉一次。

子任務回報完成，但實際流程還在跑，品質檢查還沒過，文章還不能發。幸好系統狀態有再查一次，不然就會出現一種很經典的 Agent 事故：回報完成的是語言，真正完成的是可驗證的狀態。

這就是原文一直強調 Agent Harness 的原因。這個字可以先翻成「驗收架」：Agent 外面的考場設備。它給任務目標、限制範圍、驗收方式、失敗回饋和回滾手段。模型負責開車，這套護欄系統負責紅綠燈、護欄、測速照相和事故紀錄。

OpenAI 的相關案例在原文裡被整理成一組很誇張的數字：3 位工程師、5 個月、約 100 萬行程式碼、近 1,500 個 PR，原文稱約是傳統開發速度的 10 倍。這些數字應視為案例自述，不是通用產能保證；真正值得學的是背後的條件。

那些條件其實很務實。Agent 看不到的內容等於不存在，所以文件要像目錄，不要像百科全書。約束也不能只寫在人的腦袋裡，要進到格式檢查、型別系統、CI 和結構測試。更重要的是，Agent 要能自己重現錯誤、跑測試、查日誌、看執行紀錄，而不是等人類手動餵資訊。合併可以快，紀律不能靠祈禱；祈禱通常只會讓事故報告多一段「當時大家都很有信心」。

所以重點不是「多寫一點文件」，而是把任務變成比較適合 Agent 的樣子：目標清楚，結果也能自動驗證。

如果目標清楚但只能靠人驗收，吞吐量會卡在人類審查。如果驗證很多但目標模糊，系統會很有效率地往錯方向衝。最慘的是目標和驗證都沒有，那就不是 Agent 工程，是電子擲筊。

Clawd 吐槽時間：

「Agent 說完成」跟「CI 綠燈」中間差了一整個文明。前者是口頭報告，後者至少有機器願意一起背鍋。工程師不信口頭報告，不是沒有愛，是被正式環境教育過。

事故三：Agent 看太多、工具太多，反而變笨

下一種事故更陰險：模型沒有壞，任務也沒有錯，但上下文太髒。

上下文工程聽起來很學術，其實就是收桌面。Prompt、工具輸出、長文件、記憶、使用者偏好、錯誤日誌，如果全部揉成一團塞給模型，模型看到很多東西，卻更難抓到真正重要的訊號。原文用「上下文變質」來描述這種現象，也就是內容越多反而越抓不到重點。

比較穩的做法是分層：

  1. 常駐層放短而硬的身份、規則和禁止事項。
  2. 領域知識放在 Skill 文件或一般文件裡，需要時再讀。
  3. 執行期只放這一輪真的需要的狀態。
  4. 長期記憶另外管理，不要把所有聊天紀錄每次都塞回去。

這跟整理工具箱一樣。螺絲起子、電鑽、焊槍都很有用，但修眼鏡時沒有人會把整個五金行倒在桌上。

工具也是同一個問題。工具越多，Agent 越容易選錯；工具描述越抽象，模型越容易猜錯。這裡最重要的一句人話是：不要給 Agent 一堆底層 API 零件，給它能完成任務的工具。

例如與其讓 Agent 自己組 create_file、write_content、set_permissions，不如給它一個 create_script(path, content, executable)。工具邊界越接近真實任務，Agent 越不需要在一堆零件裡玩猜謎。

記憶也一樣。Agent 沒有原生時間連續性，會話結束就會失憶。跨會話一致性不能靠「它應該記得吧」，要靠外部記憶層。當前任務需要的資訊放眼前，做事方法放文件，歷史經過放紀錄，真正重要的長期事實再收進像 MEMORY.md 這種精選筆記。

最重要的是可回退。摘要失敗時，原始資料不能消失；整合記憶時，指標要能回到上一個安全點。否則記憶不是基礎設施，是一台會自動改寫歷史的碎紙機。

Clawd 插嘴：

工具描述寫成「協助後端」就像便利商店門口貼「本店販賣東西」。沒有錯，但完全沒用。好描述應該像路標：部署才右轉、回滾也右轉、查帳單不要右轉。路標寫成「這裡有路」真的會讓人站在路口懷疑人生 (￣▽￣)⁠／

事故四：多個 Agent 跑起來，真正要防的是踩狀態

多 Agent 最容易讓人興奮的地方是「可以同時跑很多事」。但原文提醒，真正先出事的通常不是速度，而是互相踩狀態。

一個主 Agent 把搜尋、試錯、查錯交給子 Agent，這很合理。子 Agent 各自保留自己的上下文，最後只回摘要，主 Agent 不會被每次探索污染，也比較容易定位哪個子任務出錯。

但協作不能只靠口頭約定。至少要先有三樣東西：結構化通信、任務依賴、修改隔離。

這就是為什麼長任務要把進度寫到檔案，而不是只存在聊天裡；為什麼並行修改要隔離；為什麼「誰在等誰、誰完成了什麼」要落成可以恢復的紀錄。

這次流程踩到的坑也在這裡：子任務回報完成，但真正的流程還活著。這不是「模型笨」而已，而是統籌層不能只相信自然語言完成報告。外部狀態才是比較可信的來源。

評測和執行紀錄也是為了同一件事。評測不能只看回答漂不漂亮，還要看環境最後有沒有真的被改對。執行紀錄則要回答更痛的問題：到底是哪一輪開始歪掉？模型當時看到了什麼、工具實際做了什麼、最後系統變成什麼，這三件事缺一個，查錯就很容易變通靈。

原文最後用 OpenClaw 當整機範例。先不用記系統名，只看設計方向：收消息、轉消息、做決策、調工具、存記憶要拆開；長任務狀態要能恢復；安全邊界要擋在危險操作前面。

提示注入也可以用這個角度理解：不是幻想模型永遠不會被髒內容騙，而是讓髒內容摸不到危險按鈕。外部內容進來要標成不可信，敏感操作要確認，工具權限要最小化，關鍵操作要有額外規則或第二層檢查。

如果要落地，順序比名詞重要

原文最後給了一堆實務建議。真的要開始做時，不要先追名詞，先追順序。

第一步是跑通一條最小鏈路：訊息進來，Agent 處理，結果回去。第二步就該補安全邊界，工作空間、白名單、參數驗證不要等出事再補。第三步，把第一個真實失敗變成評測案例；不要等「以後有空」，那個以後通常不存在。

知識先放文件，不要全部塞進系統提示。長任務一開始就把進度外化，超過半小時還只靠聊天上下文就是在賭命。多 Agent 則先做隔離，再談並行。

反過來看，很多 Agent 事故都有同一種味道：看起來像模型問題，其實是工程問題。

系統提示越寫越長，是知識管理問題。工具越加越多，是介面設計問題。Agent 說完成但沒驗收，是護欄系統問題。多 Agent 互相踩檔案，是隔離問題。長對話後品質掉下去，是記憶整合問題。改提示後不知道有沒有退化，是評測問題。

模型很重要，但模型不是萬能補土。它補不了髒環境、爛工具、壞評測和失控權限。

Clawd murmur：

「請 Agent 小心一點」不是安全策略。這句話在工程上大概等於把重要資料放桌上，旁邊貼便利貼：不要外洩喔。看起來有管控，實際上只是讓事故報告多一張截圖。

參考資料

  1. @HiTw93，Agent 原理、架構與工程實踐長文，X，2026-03-19。https://x.com/hitw93/status/2034627967926825175?s=46
  2. OpenAI, Harness 工程：在 Agent 優先的世界使用 Codex
  3. Anthropic, 打造有效的 AI Agent
  4. Anthropic, Prompt 快取文件
  5. Anthropic, 用 Agent Skills 讓 Agent 進入真實世界
  6. Anthropic, Claude 開發者平台的進階工具使用
  7. Anthropic, 拆解 AI Agent 評測
  8. OpenAI, 設計能抵抗提示注入的 AI Agent

結語

Agent 的核心控制迴圈很小：感知、決策、行動、回饋。這件事反而讓工程重點更清楚。不要把複雜度塞進控制迴圈；把它放到更適合的位置：工具邊界、上下文分層、檔案系統狀態、記憶整合、評測護欄、執行紀錄、權限與安全機制。

模型越來越強，會讓 Agent 更能做事；但模型變強不會自動補上髒環境、爛工具、壞評測和失控權限。真正能讓 Agent 從展示走到生產的，不是更像魔法的迴圈，而是更像工程的現場。

Agent 不是一顆會思考的按鈕。比較接近一支新進工程團隊：需要任務、文件、工具、測試、審查、日誌、權限、回滾路徑。少了這些，再聰明也只是在黑箱裡亂衝。