昨天認完五種 AI 員工的樣貌。今天來試著拆解改變遊戲規則的那個：一組 agent 接到任務之後，到交出成品之前，中間到底發生了什麼事。

拆解「提案 agent」

昨天提到的場景：需求探索會議紀錄丟進去，帶頭的 agent 把工作拆分下去，提案成品就完成了。今天把這一系列動作拆解，姑且先稱這一組工作的負責 agent 為「提案 agent」。

任務只有一個：「把這個客戶的提案準備好。」

提案 agent 做的第一件事是拆工作、排順序：先背景調查，再出提案架構，接著估報價、排版、比對合約。這張清單順序由它自己排。排完，它把工作一個一個分派下去。

背景調查 subagent。 職責是把「這個客戶是誰、在做什麼」整理成一份摘要。它的架構包含以下三件事：可以伸手用哪些工具（內部客戶紀錄、對方官網、產業新聞、公司基本資料、歷年財報…等。這個「伸手」的動作，就是所謂的 tool calling）；產出要長什麼格式（固定欄位的背景摘要，讓下一棒接得住）；查到什麼程度可以停。在這個框裡面，哪個先查、查多深，是它自己的判斷。

會議摘要 subagent。 對照組。流程每次都一樣：逐字稿進來，摘要和待辦出去。只有內容是每次產生的，它沒有工具可以伸手，也幾乎不用做決定。嚴格說，它比較接近昨天第四種的 agentic workflow。一組裡面，不是每個成員都需要決定權。

提案架構 subagent。 吃背景調查的產出，加上公司過往的提案範本，決定這份提案的結構跟說法。它的邊界：說法可以自己組，承諾不能自己發明。服務範圍、交期這類會變成承諾的內容，只能從範本和報價那裡拿。

提案排版接近固定流程，比對歷史報價是一段規則。 這裡有明確格式和規則的不需要特別引入大語言模型（LLM）。

合約差異標註 subagent。 拿合約草稿對公司標準版，標出差異點，進一步還可以建議修改方向。這一步它伸手叫動的是公司內部的審稿機器人，跑一輪法遵條款檢查、比對標準合約庫。這條線使用 MCP（一種讓 agent 接得上工具的標準接口），資料源包好一次，之後任何 agent 都能重複使用，不用每次重新拉線。因為合約寄出去是收不回來的動作，「寄出」或「建議修改」類型動作前面固定設置人為關卡。這個設計就是 human-in-the-loop（HITL），人介入的位置，就是檢查點。

最後再回到提案 agent。所有產出收回來，它自己可以根據定義好的項目檢查一遍，判斷「這樣可以交了」。將判斷的依據寫成一組可以重複檢查的標準，就是 evaluation（eval）。沒有這一層，完成的標準就只存在於每次的執行現場。

拆到這裡，可以看到兩件事。

第一，每個成員能做的決定，是被它的架構圈出來的：職責、能用的工具、產出格式、什麼時候停。設計一組 agent，做的就是把這疊職位說明書寫出來。說明書寫得越清楚，它越可靠；寫得越鬆，它自由發揮的空間就越大。

第二，決定權最寬的是帶頭的提案 agent：怎麼拆、誰先做、缺料怎麼辦、什麼時候算做完，都是它負責的。這些決定每次都是當場產生的，跟 Day 5 講的回答是同一種：機率的。單獨看每一步，它多半做得不錯，但一步的小偏差會留在半成品裡，被下一棒接著用。步驟越長，偏差就可能越滾越大。

要看手上那個號稱 agent 的東西是不是真的，就看決定權在哪：丟一個它沒料到的狀況進去，真的 agent 會在自己的邊界裡繞路，包著 AI 外殼的固定流程會停在原地等人，或者照原路跑完，交給你一份格式過關但內容不完整的東西。

對經營者意味著什麼：交付的方法變了

回頭看這一趟。交出去的是一句目標，收回來的是一份成品，中間那段過程，沒有人在場。

所以目標、邊界、什麼叫做完，這三件以前靠員工溝通對話確定的事，現在要寫下來。上面那疊職位說明書，就是交辦的新形狀，而 eval，就是驗收的樣子。

交辦下去的那一刻，人的注意力就可以抽出來，去做下一件事。人出現的位置變了。過程移交出去給 agent，檢查點留下來，而且比以前更重要。這已經不只是效率問題。也是前一篇說到的，工作的樣態變了。

不過這一組要能跑起來，靠的是每一個成員的邊界都被刻意圈過。圈得越寬，它能做的事越多，你要管理的事也越多。那麼手上正要交出去的這件事，邊界該畫到哪裡？

要拿走的問題

• 執行層（CTO/CIO）：認清楚我們手上所謂的「agent」：哪些步驟真的是它自己在做決定，哪些只是固定流程？
• 經營層（董事會/CEO）：公司裡這些 agent 的工作，改變了哪些工作的交付方法？

一句話帶走：你可以把工作交給 agent。但什麼叫做完，要由你先定義。