--- schemaVersion: 1 slug: gp-201-20260515-hitw93-agent ticketId: GP-201 lang: zh-tw title: Agent 真正難的不是模型，而是工程現場 summary: 一篇從控制迴圈、Harness、上下文工程、工具設計、記憶、多 Agent、評測、追蹤到安全邊界的 Agent 工程指南。核心不是把模型換貴，而是把任務、狀態、驗證與工具邊界做成機器能穩定執行的系統。 originalDate: 2026-03-19 translatedDate: 2026-05-15 source: "@HiTw93 on X" sourceUrl: https://x.com/hitw93/status/2034627967926825175?s=46 author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/gp-201-20260515-hitw93-agent status: published replacementTicketId: null replacementUrl: null --- # Agent 真正難的不是模型，而是工程現場 > **來源:** [@HiTw93 on X](https://x.com/hitw93/status/2034627967926825175?s=46) [Agent](https://gu-log.vercel.app/glossary#agent) 最像魔法的地方，通常不是最難的地方。 先看一個很蠢、但很真實的事故。 這篇文章進自動流程時，子任務一度回報「完成」。照理說機器可以收工了。但系統狀態多查一眼，真正的流程還在跑，品質檢查還沒過，文章根本不能發。 這就是 Agent 工程最殘酷也最有用的一課：**Agent 說完成，不等於系統真的完成。** 真正可靠的 Agent，不是會講漂亮完成報告的 Agent，而是會把進度寫下來、會被機器驗收、出錯時查得到紀錄、工具也不會亂摸的 Agent。換句話說，模型只是駕駛；工程系統才是儀表板、煞車、車道線和行車紀錄器。 @HiTw93 這篇長文剛好把這件事拆得很完整。它不是在問「哪個模型最強」，而是在回答一個更工程現場的問題：**Agent 要怎麼從展示玩具變成真的能交付工作的系統？** 如果不想一次吞下所有名詞，可以只帶著三個問題讀： 1. Agent 怎麼知道下一步要做什麼？ 2. Agent 怎麼知道自己做對了？ 3. Agent 出錯時，工程師怎麼抓得到原因？ 後面會講很多零件，但先不用背名字。它們其實都在服務同一件事：讓 Agent 的行為可以被約束、被驗證、出錯時查得到原因，而不是只靠「模型應該懂吧」這種玄學保佑。 如果只記一件事，大概是這句：**讓 Agent 會動不難，讓它跑穩才難。** 這篇比較像一張事故地圖：先看哪裡會爆，再看工程上怎麼補。爆點一路變大：一開始只是迴圈亂跑，接著是完成報告失真，再來是上下文變髒，最後變成多個 Agent 互相踩腳。 放回 gu-log 前面幾篇看，這篇比較像總配電盤：[GP-197](https://gu-log.vercel.app/posts/gp-197-20260512-chrishayduk-codex-goals/) 講 [Codex](https://gu-log.vercel.app/glossary#codex) `/goal` 怎麼把可驗收狀態寫進檔案，[GP-192](https://gu-log.vercel.app/posts/gp-192-20260508-article-agent-ralph/) 講長跑 Agent 怎麼避免勤奮地跑偏，[GP-158](https://gu-log.vercel.app/posts/gp-158-20260403-braintrust-agent-production-trace/) 講執行紀錄和評分回饋怎麼讓系統真的變好，[GP-135](https://gu-log.vercel.app/posts/gp-135-20260328-trq212-agent-file-system/) 則把檔案系統記憶這件事拆開來講。HiTw93 這篇剛好把這些線接成一張工程現場地圖。 > **Mogu 偷偷說：** > > 很多 Agent 產品展示看起來像鋼鐵人管家，實作打開常常像宿舍延長線：模型、工具、資料庫、瀏覽器、命令列、日誌，全插在一起。會動，甚至很神。但一旦出事，沒有人知道是哪個插頭冒煙。 ## 事故一：控制迴圈會跑，不代表任務會完成 先把 Agent 拆到最小，其實沒有那麼神祕。 最小版 Agent 控制迴圈幾乎就是一個 `while` 迴圈：把使用者輸入丟給模型；模型如果要用工具，外部系統就執行工具，再把結果餵回去；模型如果回純文字，任務結束。 這個迴圈可以叫做：感知、決策、行動、回饋。聽起來很像魔法，其實像一個一直問「下一步呢？」的工程流程。 真正麻煩的是：**控制迴圈會跑，不代表任務會被正確完成。** 很多產品掛著 Agent 的招牌，拆開看比較像固定流程：路線早就寫死，只是每一步換成 LLM 處理。這不是壞事。任務固定、驗收清楚時，固定流程反而更穩。硬把所有事情都交給完整自主 Agent，像叫消防車澆桌上的多肉植物。車來了、梯子架好了、水管接好了，多肉淹死了。 @HiTw93 原文列了幾種常見控制模式：提示鏈、路由、並行、編排器-工作者、評估器-優化器。這些名字不用背。比較重要的是知道它們在回答同一個問題：**這件事到底該由程式決定路徑，還是讓模型動態決定下一步？** 如果答案是「流程很清楚」，先用固定流程。只有當任務需要探索、判斷、跨多個工具動態調整時，才真的需要 Agent。 > **Mogu 吐槽時間：** > > Agent 控制迴圈像一台可以自己踩油門的車。問題不是它會不會動，問題是路線、煞車、儀表板、保險、行車紀錄器有沒有裝。很多展示只喊「你看它會動！」，工程現場會問：「撞到誰算誰的？」 --- ## 事故二：Agent 說完成，但沒有人驗收 這一點剛剛才現場打臉一次。 子任務回報完成，但實際流程還在跑，品質檢查還沒過，文章還不能發。幸好系統狀態有再查一次，不然就會出現一種很經典的 Agent 事故：**回報完成的是語言，真正完成的是可驗證的狀態。** 這就是原文一直強調 [Agent Harness](https://gu-log.vercel.app/glossary#agent-harness) 的原因。這個字可以先翻成「驗收架」：Agent 外面的考場設備。它給任務目標、限制範圍、驗收方式、失敗回饋和回滾手段。模型負責開車，這套護欄系統負責紅綠燈、護欄、測速照相和事故紀錄。 OpenAI 的相關案例在原文裡被整理成一組很誇張的數字：3 位工程師、5 個月、約 100 萬行程式碼、近 1,500 個 PR，原文稱約是傳統開發速度的 10 倍。這些數字應視為案例自述，不是通用產能保證；真正值得學的是背後的條件。 那些條件其實很務實。Agent 看不到的內容等於不存在，所以文件要像目錄，不要像百科全書。約束也不能只寫在人的腦袋裡，要進到格式檢查、型別系統、CI 和結構測試。更重要的是，Agent 要能自己重現錯誤、跑測試、查日誌、看執行紀錄，而不是等人類手動餵資訊。合併可以快，紀律不能靠祈禱；祈禱通常只會讓事故報告多一段「當時大家都很有信心」。 所以重點不是「多寫一點文件」，而是把任務變成比較適合 Agent 的樣子：目標清楚，結果也能自動驗證。 如果目標清楚但只能靠人驗收，吞吐量會卡在人類審查。如果驗證很多但目標模糊，系統會很有效率地往錯方向衝。最慘的是目標和驗證都沒有，那就不是 Agent 工程，是電子擲筊。 > **Mogu 吐槽時間：** > > 「Agent 說完成」跟「CI 綠燈」中間差了一整個文明。前者是口頭報告，後者至少有機器願意一起背鍋。工程師不信口頭報告，不是沒有愛，是被正式環境教育過。 --- ## 事故三：Agent 看太多、工具太多，反而變笨 下一種事故更陰險：模型沒有壞，任務也沒有錯，但上下文太髒。 上下文工程聽起來很學術，其實就是收桌面。[Prompt](https://gu-log.vercel.app/glossary#prompt)、工具輸出、長文件、記憶、使用者偏好、錯誤日誌，如果全部揉成一團塞給模型，模型看到很多東西，卻更難抓到真正重要的訊號。原文用「上下文變質」來描述這種現象，也就是內容越多反而越抓不到重點。 比較穩的做法是分層： 1. 常駐層放短而硬的身份、規則和禁止事項。 2. 領域知識放在 [Skill](https://gu-log.vercel.app/glossary#skill) 文件或一般文件裡，需要時再讀。 3. 執行期只放這一輪真的需要的狀態。 4. 長期記憶另外管理，不要把所有聊天紀錄每次都塞回去。 這跟整理工具箱一樣。螺絲起子、電鑽、焊槍都很有用，但修眼鏡時沒有人會把整個五金行倒在桌上。 工具也是同一個問題。工具越多，Agent 越容易選錯；工具描述越抽象，模型越容易猜錯。這裡最重要的一句人話是：**不要給 Agent 一堆底層 API 零件，給它能完成任務的工具。** 例如與其讓 Agent 自己組 `create_file`、`write_content`、`set_permissions`，不如給它一個 `create_script(path, content, executable)`。工具邊界越接近真實任務，Agent 越不需要在一堆零件裡玩猜謎。 記憶也一樣。Agent 沒有原生時間連續性，會話結束就會失憶。跨會話一致性不能靠「它應該記得吧」，要靠外部記憶層。當前任務需要的資訊放眼前，做事方法放文件，歷史經過放紀錄，真正重要的長期事實再收進像 `MEMORY.md` 這種精選筆記。 最重要的是可回退。摘要失敗時，原始資料不能消失；整合記憶時，指標要能回到上一個安全點。否則記憶不是基礎設施，是一台會自動改寫歷史的碎紙機。 > **Mogu 想補充：** > > 工具描述寫成「協助後端」就像便利商店門口貼「本店販賣東西」。沒有錯，但完全沒用。好描述應該像路標：部署才右轉、回滾也右轉、查帳單不要右轉。路標寫成「這裡有路」真的會讓人站在路口懷疑人生 (￣▽￣)／ --- ## 事故四：多個 Agent 跑起來，真正要防的是踩狀態 多 Agent 最容易讓人興奮的地方是「可以同時跑很多事」。但原文提醒，真正先出事的通常不是速度，而是互相踩狀態。 一個主 Agent 把搜尋、試錯、查錯交給子 Agent，這很合理。子 Agent 各自保留自己的上下文，最後只回摘要，主 Agent 不會被每次探索污染，也比較容易定位哪個子任務出錯。 但協作不能只靠口頭約定。至少要先有三樣東西：結構化通信、任務依賴、修改隔離。 這就是為什麼長任務要把進度寫到檔案，而不是只存在聊天裡；為什麼並行修改要隔離；為什麼「誰在等誰、誰完成了什麼」要落成可以恢復的紀錄。 這次流程踩到的坑也在這裡：子任務回報完成，但真正的流程還活著。這不是「模型笨」而已，而是統籌層不能只相信自然語言完成報告。外部狀態才是比較可信的來源。 評測和執行紀錄也是為了同一件事。評測不能只看回答漂不漂亮，還要看環境最後有沒有真的被改對。執行紀錄則要回答更痛的問題：到底是哪一輪開始歪掉？模型當時看到了什麼、工具實際做了什麼、最後系統變成什麼，這三件事缺一個，查錯就很容易變通靈。 原文最後用 [OpenClaw](https://gu-log.vercel.app/glossary#openclaw) 當整機範例。先不用記系統名，只看設計方向：收消息、轉消息、做決策、調工具、存記憶要拆開；長任務狀態要能恢復；安全邊界要擋在危險操作前面。 提示注入也可以用這個角度理解：不是幻想模型永遠不會被髒內容騙，而是讓髒內容摸不到危險按鈕。外部內容進來要標成不可信，敏感操作要確認，工具權限要最小化，關鍵操作要有額外規則或第二層檢查。 --- ## 如果要落地，順序比名詞重要 原文最後給了一堆實務建議。真的要開始做時，不要先追名詞，先追順序。 第一步是跑通一條最小鏈路：訊息進來，Agent 處理，結果回去。第二步就該補安全邊界，工作空間、白名單、參數驗證不要等出事再補。第三步，把第一個真實失敗變成評測案例；不要等「以後有空」，那個以後通常不存在。 知識先放文件，不要全部塞進系統提示。長任務一開始就把進度外化，超過半小時還只靠聊天上下文就是在賭命。多 Agent 則先做隔離，再談並行。 反過來看，很多 Agent 事故都有同一種味道：看起來像模型問題，其實是工程問題。 系統提示越寫越長，是知識管理問題。工具越加越多，是介面設計問題。Agent 說完成但沒驗收，是護欄系統問題。多 Agent 互相踩檔案，是隔離問題。長對話後品質掉下去，是記憶整合問題。改提示後不知道有沒有退化，是評測問題。 模型很重要，但模型不是萬能補土。它補不了髒環境、爛工具、壞評測和失控權限。 > **Mogu murmur：** > > 「請 Agent 小心一點」不是安全策略。這句話在工程上大概等於把重要資料放桌上，旁邊貼便利貼：不要外洩喔。看起來有管控，實際上只是讓事故報告多一張截圖。 --- ## 參考資料 1. @HiTw93，Agent 原理、架構與工程實踐長文，X，2026-03-19。[https://x.com/hitw93/status/2034627967926825175?s=46](https://x.com/hitw93/status/2034627967926825175?s=46) 2. OpenAI, [Harness 工程：在 Agent 優先的世界使用 Codex](https://openai.com/index/harness-engineering/) 3. Anthropic, [打造有效的 AI Agent](https://www.anthropic.com/engineering/building-effective-agents) 4. Anthropic, [Prompt 快取文件](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) 5. Anthropic, [用 Agent Skills 讓 Agent 進入真實世界](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills) 6. Anthropic, [Claude 開發者平台的進階工具使用](https://www.anthropic.com/engineering/advanced-tool-use) 7. Anthropic, [拆解 AI Agent 評測](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) 8. OpenAI, [設計能抵抗提示注入的 AI Agent](https://openai.com/index/designing-agents-to-resist-prompt-injection/) --- ## 結語 Agent 的核心控制迴圈很小：感知、決策、行動、回饋。這件事反而讓工程重點更清楚。不要把複雜度塞進控制迴圈；把它放到更適合的位置：工具邊界、上下文分層、檔案系統狀態、記憶整合、評測護欄、執行紀錄、權限與安全機制。 模型越來越強，會讓 Agent 更能做事；但模型變強不會自動補上髒環境、爛工具、壞評測和失控權限。真正能讓 Agent 從展示走到生產的，不是更像魔法的迴圈，而是更像工程的現場。 Agent 不是一顆會思考的按鈕。比較接近一支新進工程團隊：需要任務、文件、工具、測試、審查、日誌、權限、回滾路徑。少了這些，再聰明也只是在黑箱裡亂衝。