AI agent 導入最常見的錯誤，不是選錯框架，而是太早選框架。
很多團隊一開始就問：該用 LangGraph、Mastra、Pydantic AI、OpenAI Agents API、n8n，還是某個新出現的 agent platform？這個問題當然重要，但它通常不是第一題。第一題應該是：這個 agent 到底要替誰完成哪一段工作，而且完成後能不能被驗收？
如果這題答不出來，框架選得再精準，也只是把模糊流程包成比較正式的程式碼。
English TL;DR
AI agent adoption should start with workflow and control design, not framework shopping. Before choosing an agent framework, define the task, data access, runtime boundaries, tool contracts, review points, cost limits, failure handoff, and success metrics. A good agent system is not the one with maximum autonomy; it is the one that reduces review and operating cost inside clear boundaries.
先定義任務，不要先定義工具
一個能導入的 agent 任務，至少要回答五件事。
第一，輸入是什麼。它讀的是使用者提問、客服工單、GitHub issue、會議紀錄、網頁、CRM、repo、還是資料庫查詢？
第二，輸出是什麼。它要產生摘要、分類、草稿、比較表、PR、報告、待辦，還是 API 寫入？
第三，誰會使用輸出。是工程師、客服、PM、業務、內容編輯、主管，還是最終客戶？
第四，成功怎麼判斷。不是「看起來不錯」，而是格式是否完整、來源是否可信、欄位是否可用、是否節省人工時間、是否降低返工。
第五，錯了會怎樣。錯誤只是需要人改一下，還是會寄錯信、刪資料、改客戶狀態、部署壞版本、產生合規風險？
這五題回答完，通常就能看出任務適不適合第一週導入。適合的任務多半高頻、低風險、可覆核、有明確輸出。不適合的任務多半高風險、跨很多系統、成功標準模糊，而且出錯代價很高。
把權限拆成讀、寫、送出、刪除
agent 的危險不在於它會講錯話，而在於它能不能把錯誤推進系統。
所以導入前要先把權限拆清楚。讀取資料是一種權限，產生草稿是一種權限，寫入內部系統是一種權限，送出對外訊息是一種權限，刪除或部署又是另一種權限。
很多 demo 會把這些權限混在一起，因為展示時比較順。但產品化時，這樣會讓風險難以控制。
比較穩健的做法，是先把 agent 放在「讀取與草稿」的位置。它可以讀指定資料、整理候選答案、產生回覆草稿、提出下一步建議，但不能直接送出、刪除、付款、改權限或部署。
等到任務穩定、錯誤類型可預測、人工審核成本下降，再逐步開放低風險寫入。高風險動作則應該長期保留人工批准或獨立控制面。
Runtime control 比 prompt 更重要
很多人談 agent safety，會先想到 prompt：要求模型不要亂做、不要洩漏資料、遇到不確定要問人。
這些提示不是沒用，但不夠。只要 agent 能呼叫工具、讀檔、連網、開 issue、改資料庫，真正的安全邊界就不能只存在模型上下文裡。
runtime control 至少要包含幾層：
- 檔案與資料範圍：哪些路徑、資料表、文件可以讀？
- 網路範圍：可以連哪些 domain？是否能任意搜尋或下載？
- 工具白名單：可以呼叫哪些工具？每個工具允許哪些參數？
- 憑證隔離：agent 拿到的是完整權限，還是最小權限 token？
- 審核節點：哪些動作必須停下來等人確認？
- 執行紀錄：模型看了什麼、做了什麼、呼叫什麼、誰批准？
- 停止與回滾：發現越界時誰能停，出錯後怎麼復原？
這些東西聽起來不像酷炫 AI 功能，但它們決定 agent 能不能放進日常工作。
工具契約：型別不是萬靈丹，但能減少混亂
當任務與權限都清楚後，才適合進入工具選型。
Pydantic AI 這類 typed agent framework 的價值，是讓 Python 團隊把工具 schema、結構化輸出、依賴注入、evals、tracing 放回熟悉的工程流程。這對產品化 LLM workflow 很有幫助，因為線上最常壞掉的地方，往往不是模型完全不會回答，而是參數格式飄、輸出欄位缺失、工具錯用、失敗後沒有 trace。
但型別只能保護資料形狀，不能保證業務判斷正確。
一個欄位通過 schema，不代表回覆內容符合政策；一次 eval 通過，不代表線上所有案例都安全；有 tracing，不代表權限設計合理。
所以工具契約應該和任務樣本一起設計。比較務實的起點，是拿 50 到 100 筆真實案例，固定輸入、期望輸出、允許工具、禁止工具、失敗路徑與人工覆核方式。沒有樣本就先補樣本，不要急著堆框架。
驗收標準要比展示更嚴格
agent demo 容易讓人興奮，因為它會把一段原本麻煩的流程演完。但日常導入看的是另一件事：它有沒有真的降低人的工作量？
很多 agent 表面上省時間，實際上只是把工作移到審稿階段。人還是要從頭看一遍，還要猜它為什麼這樣做，最後花更多時間修正。
比較好的驗收標準應該包含：
- 人工覆核時間是否下降？
- 輸出格式是否能直接進下一步？
- 錯誤是否集中在可修正的幾種類型？
- 它是否附上足夠來源與中間依據？
- 失敗時是否能快速接手，而不是整段重跑？
- 成本是否在可預測範圍？
如果這些指標沒有改善，agent 可能只是新鮮感，不是效率系統。
成本封頂是產品規格，不是財務雜事
agent 和單次模型呼叫不同。它可能查很多資料、呼叫很多工具、重試很多次、保留很長上下文，最後把一個小任務跑成不可預測的帳單。
所以第一版就要設成本與時間上限。
例如最多執行幾步、最多呼叫幾次模型、最多查幾個來源、每個工具 timeout 多久、失敗後是否降級成草稿、是否允許重新嘗試、是否要在人審前停止。
這些限制不是為了小氣，而是為了讓流程可營運。成本不可控的 agent，很難變成可持續資產。
三個適合第一週試點的場景
第一個場景是內容資產整理。
讓 agent 讀既有文章，找出可以補 FAQ、比較表、內鏈、摘要、短文導流的地方。這類任務風險低，成果能累積成搜尋入口與信任資產，也很適合內容站建立被動收入路徑。
第二個場景是客服或銷售草稿。
agent 可以讀工單或客戶問題，產生分類、摘要、建議回覆與風險標記，但不直接送出。人類負責最後確認。這能降低前處理成本，也能保留責任邊界。
第三個場景是工程 triage。
agent 可以整理 issue、標記可能相關檔案、找近期 commit、產生測試建議或 PR 草稿，但高風險變更、部署、資料 migration 仍然要人批准。這條路線的重點不是完全自動修 bug，而是降低理解成本。
三個不適合第一週試點的場景
第一，不適合直接處理金流、刪除、權限調整、正式部署。這些任務一旦錯，回復成本高，責任邊界也複雜。
第二，不適合接模糊目標。例如「幫公司自動營運」、「幫我管理所有客戶」、「幫我自動做成長」。這些不是任務，而是一團還沒拆開的經營問題。
第三，不適合把 agent 放到沒有人願意覆核的流程。無人覆核不等於自動化成熟，很多時候只是把風險藏起來。
從被動收入角度看，agent 要累積資產
如果目標是每月穩定收入與更好的生活品質，agent 導入就不該只追求「今天省 30 分鐘」。
更值得做的是讓 agent 幫忙建立可累積資產：文章、FAQ、比較表、內部 SOP、產品文件、銷售素材、評估清單、可重複的分析流程。
這些東西一旦變穩，會同時降低未來工作量，也增加搜尋、信任、轉換與交付能力。相反地，如果 agent 只是每天產出一堆沒有人整理的內容，它反而會製造新的維護負擔。
所以內容產線和 agent 導入其實是同一種問題：不要只看產量，要看資產是否能被搜尋、被引用、被更新、被轉換。
結論：好的 agent 系統，是控制面先於自動化
AI agent 的採用順序，應該是：
- 定義一個高頻、低風險、可驗收的任務。
- 拆清楚資料、工具、寫入、送出、刪除與部署權限。
- 設計 runtime control、log、停止與回滾。
- 用真實案例建立輸入、輸出、evals 與人工覆核方式。
- 再選框架與模型。
- 最後才逐步提高自動化比例。
這個順序看起來比較慢，但它比較接近能留下來的系統。
真正有價值的 agent，不是表演自己能做多少事，而是在清楚邊界內穩定減少人的判斷成本、覆核成本與營運成本。這樣的 agent 才有機會從一次性 demo，變成可持續流量、信任與收入的一部分。