[AI 分享] 可交付AI Agent系統構建

2026年6月17日星期三

摘要 : 從產品認知、上下文管理到評估體系，整理可交付AI Agent系統的實戰方法與原則。

內容:

這篇內容主要在討論：**如何構建真正可交付的 AI Agent 系統**。整體思路來自 5 月 31 日 AI Engineer 的一支 YouTube 影片，但也與企業 AI Agent 交付、AI Coding Harness 以及陪跑專案中的實際經驗高度契合，因此很值得整理分享。

全文大致可分成五個核心方向，從最底層的認知開始，談人類與 Agent 使用產品的方式差異，接著談上下文管理、狀態機制、評估體系建設，以及提示詞與技術實作上的原則。其中作者特別強調：**評估體系是最關鍵、也最容易被忽略的一環**。

首先，最核心的認知是：**人類與 Agent 消費產品的方式並不一樣**。

以 HTML 為例，人類在看網頁時，往往是從視覺、元素、關聯與互動效果去理解；但 Agent 在處理 HTML 時，更多是從文字結構與語意關係去推斷內容。因此，當我們設計產品或資料給 AI 使用時，不能完全沿用「給人看的方式」，而要開始思考怎樣讓模型更容易抓取、總結與理解。

這也帶出第一個重要原則：**不需要把所有文件都丟給 AI**。

因為很多通用知識模型本來就知道了，真正需要補充的，反而是那些模型最容易誤解的地方，例如產品中的特殊規則、常見踩坑點、容易混淆的邏輯等。換句話說，給 AI 的資訊不在於多，而在於是否能幫助它避開誤解。

此外，在設計產品時，也可以逐步往 **更容易被 AI 理解的結構** 靠攏。比如以往很多頁面設計是優先給人類瀏覽體驗，但未來也許需要兼顧「是否有利於 Agent 抓取、解析、摘要與推理」。這些與人的差異雖然微妙，卻會在實作過程中持續影響成效。

第二個重點是**上下文管理**。

在 AI Coding 或 Agent 工作流中，常常有大量時間花在補充背景資訊與前置條件上，而且每次新開一個上下文，都要重新講一次，效率很低。比較好的做法，是把這些重複性高、可複用的資訊提前整理起來，做成可被調用的內容模組，例如 skills 或 agent cmd，讓模型在需要時自動載入。

這樣做的價值在於：當你發現某些背景資訊、操作說明或工作流程總是要重複提供，就應該把它們結構化，沉澱成系統能力，而不是每次人工重新輸入。這能大幅降低前置溝通成本。

不過，就算把 skills 都準備好了，也不代表模型就一定能從頭到尾穩定執行。

因為大模型本質上仍然是機率性系統，即便 temperature 設為 0，穩定性仍有限，也可能出現幻覺或中途偏離。因此，在 AI Agent 產品中，不論是 AI Coding 還是其他 Agent 類型系統，**狀態機制** 都是很有效的處理方式，可以幫助流程更可控。

接著進入全文最重要的部分：**評估體系建設**。

這裡引用了一個很關鍵的觀點：如果沒有評估，就沒有改進。對可交付的 AI Agent 系統來說，評估不是附屬品，而是核心能力。

曾把過去大量的人類經驗文件整理成 skills，讓 AI 在處理問題時調用，原本以為這樣效果會更好；但在建立評估體系後卻發現，**把所有 skills 都給模型時，準確率只有 70%；反而什麼 skills 都不給時，準確率可以達到 97%**。這是一個非常有啟發性的結果。

原因在於，skills 本身也會佔據上下文，而且其中可能混入過時文件、不夠精準的指導，或與當前專案結構不一致的內容。這些資訊不但沒有幫助，反而可能干擾模型判斷。因此，這裡得到一個非常重要的結論：

**與其給模型固定規定，不如給它指導原則。**

也就是說，不要試圖用大量細碎、陳舊、僵硬的規則去束縛模型，而應該提供方向性的引導，讓模型依據當前情境做合理判斷。這被認為是整支影片中最有價值的一個觀點。

至於評估體系怎麼建立，可以分成幾個層次：

第一層是**確定性驗證**。

例如在程式碼提交流程中，透過單元測試、Lint、Build 驗證等方式做檢查，這些屬於 CI/CD 中本來就應該存在的固定環節。AI 介入後，這些機制不能省，反而更重要，因為它們能提供穩定、可重複的品質保障。

第二層是**規則化檢查**。

像是程式碼規範、靜態檢查、格式化與一些明確可定義的規則，這些也應該交給工具或系統做，而不是完全依賴模型的主觀判斷。

第三層才是**模型評估**。

但這裡有個關鍵技巧：不要讓模型做過於寬泛的評價。例如不要問「這段程式碼好不好」，而應該把問題窄化成具體維度，例如：「找出這段程式碼中與需求不一致的地方」、「列出可能缺失的邊界條件」、「指出風險較高的區域」。當評估範圍被縮小後，模型的焦點會更集中，輸出品質也更穩定。

最後一層仍然是**人工審查**。

即使前面有規則檢查與模型評估，人依然不能完全退出。對於重要程式碼、關鍵業務邏輯、風險區域，例如支付流程、核心架構、可維護性等，人還是需要親自看。也就是說，真正可交付的系統，不是把責任全部推給 AI，而是建立一個多層次驗證機制，讓 AI、規則與人工彼此補位。

因此，不只是 AI Agent，包含 RAG、Harness、AI Coding 流程，只要是要落地交付的系統，**都必須有評估體系**。這一點非常關鍵。

最後回到 skills 的問題，這段內容也再次提醒：**不是 skills 給得越多越好**。

當模型本身的理解與執行能力越來越強時，我們需要做的，不是塞滿所有文件，而是「輕推一下」，把它引導到正確方向。真正有效的做法，不是用大量陳舊規則綁住模型，而是提供清楚、簡潔、方向明確的原則，讓模型在具體任務中靈活發揮。