很多團隊開始導入 AI agent 時，第一個問題會變成：「我們該用哪個框架？」

這個問題不算錯，但通常問太早。因為 agent 專案真正卡住的地方，很少是框架少一個功能，而是團隊還沒說清楚一件事：這個 agent 到底要接手哪一段工作流？

如果工作流沒有畫清楚，選 Mastra、LangGraph、OpenAI Agents API、Pydantic AI 或自己寫 tool calling，最後都會遇到同一個問題：demo 看起來會動，進到日常工作就開始失控。

English TL;DR

AI agent adoption should start with a workflow map, not a framework comparison. Before choosing tools, define the task source, decision boundaries, permissions, review points, success criteria, failure handoff, and operating metrics. This turns agent adoption from a demo into a durable business asset.

為什麼不能先選框架？

框架會讓人產生一種錯覺：只要 agents、tools、memory、workflow、evals、observability 都有，導入問題就已經被解決。

但框架解的是工程組織問題，不會自動替你解產品問題。

產品問題包括：

• 這個任務是不是值得自動化？
• 任務輸入從哪裡來？
• 哪些步驟可以讓模型做？
• 哪些步驟一定要人確認？
• agent 可以讀哪些資料？
• 可以改哪些系統？
• 成功怎麼定義？
• 失敗時誰接手？
• 出錯時能不能回溯？

如果這些答案不清楚，框架愈強，只是讓錯誤更快進入生產流程。

先把任務拆成三層

比較穩的做法，是先把你想導入 AI 的工作拆成三層。

第一層是「單次模型功能」。例如摘要、分類、改寫、翻譯、欄位抽取。這類任務通常不需要 agent framework，用模型 API 或既有後端服務就能處理。過早引入 agent，反而增加維護成本。

第二層是「多步驟輔助」。例如研究一家公司、整理候選工具、產生客服回覆草稿、檢查內容 SEO、比對合約條款。這類任務開始需要工具呼叫、狀態保留、引用來源、審核節點，也開始適合評估 workflow 或 agent 框架。

第三層是「半自主工作流」。例如長時間監控 issue、定期產生報表、跨系統更新資料、批次檢查 repo、協助安全 triage。這類任務才真正需要 agent harness、sandbox、權限邊界、audit trail、重試策略、成本上限與人類接手機制。

很多導入失敗，是把第一層任務硬做成第三層架構，或把第三層風險當成第一層 demo。

一張工作流地圖應該包含什麼？

最小可用的工作流地圖，不需要漂亮。用文件、白板或表格都可以，但至少要回答七個問題。

第一，觸發條件是什麼？是使用者按鈕、定時任務、客服訊息、GitHub issue、CRM 狀態改變，還是人工指派？

第二，輸入資料在哪裡？agent 需要讀文件、資料庫、網頁、郵件、repo、客服紀錄，還是只讀使用者貼上的內容？

第三，agent 可以做哪些動作？只產生草稿、可以呼叫內部 API、可以開 PR、可以改資料、可以寄信，還是只能提出建議？

第四，哪些地方需要人審核？不是每個步驟都要審核，但高風險動作一定要有明確關卡。例如寄出訊息、修改付款資料、刪除資料、部署、調整權限。

第五，成功輸出長什麼樣？如果輸出只是「看起來不錯」，之後就很難評估品質。比較好的定義是：完成哪些欄位、附上哪些來源、符合哪些格式、通過哪些檢查、節省多少人工作業。

第六，失敗時怎麼辦？agent 找不到資料、工具 timeout、模型判斷不一致、輸出不完整、成本超過上限時，是停止、重試、降級成草稿，還是交回給人？

第七，事後怎麼學習？每次任務應該留下輸入、關鍵決策、工具呼叫、輸出、審核結果與人工修改。沒有這些紀錄，就沒有 eval，也沒有持續改善。

框架選型要晚一點，但不能沒有標準

等工作流地圖出來後，框架選型才會變得具體。

如果你的團隊主要是 TypeScript，而且任務是產品內的多步驟流程，Mastra 這類框架的價值就會比較明顯，因為它把 agents、workflows、tools、memory、evals 與 observability 放在同一個工程語境。

如果你需要高度明確的狀態圖、分支、循環與人類審核節點，LangGraph 這類偏 graph/workflow 的方案可能更適合。

如果你希望少管理底層執行環境，並且能接受平台邊界，managed agent harness 會有起步速度優勢，但要更小心 vendor lock-in、資料邊界與可觀測性。

如果任務只是單次摘要、分類或欄位抽取，先不要上框架。這不是保守，而是避免把簡單需求變成長期維護負債。

小團隊最適合從哪裡開始？

小團隊不要一開始就做「全自動員工」。比較好的第一個 agent，是能替人整理資訊、產生草稿、留下判斷依據，但不直接做高風險外部動作的流程。

例如內容團隊可以先做內容審稿 agent：讀草稿、檢查標題、摘要、內鏈、讀者價值、重複題材，最後產生修改建議。這種場景的好處是輸出容易 review，失敗成本低，改善也容易累積。

客服團隊可以先做回覆建議 agent：讀取訂單狀態、歷史訊息、政策文件，產生草稿與引用依據，但由客服人員按送出。這比直接自動回覆安全，也比較容易建立信任。

工程團隊可以先做 issue triage agent：讀 issue、找相關檔案、標記可能模組、建議重現步驟，但不要一開始就自動改 code 或部署。

這些場景都有一個共通點：agent 先成為「高品質副駕」，再逐步接近自動化。

對被動收入內容站的意義

這件事也直接關係到 AI 內容資產的長期價值。

如果內容只追新工具名稱，流量會來，但信任很難留下。讀者看完一篇工具介紹，下一步通常會去官網、GitHub 或另一篇比較文。

但如果內容能提供工作流地圖、選型框架、採用順序、失敗案例與 FAQ，讀者遇到實際導入問題時會回來。這種內容比較慢，但更能累積搜尋流量、內鏈結構、顧問型信任與未來產品轉換。

所以 07:30 長文不應該只是比較完整的工具介紹，而應該承擔「建立判斷系統」的角色。白天後續的導流短文、觀點、工具快評、趨勢文，才有東西可以連回來。

結論

AI agent 導入不是從「哪個框架比較紅」開始，而是從「哪段工作值得被 agent 接手」開始。

先畫工作流地圖，再決定要不要 agent。先定義權限與審核，再比較框架。先做低風險副駕，再讓它碰更高價值的流程。

這樣做看起來慢一點，但比較可能留下真正能複利的東西：可維護的系統、可信任的內容資產，以及不靠爆肝追熱點也能長期轉換的 AI 判斷力。