很多團隊開始導入 AI Agent 時，第一個問題會問錯。

他們會問：我們該用 LangGraph、CrewAI、AutoGen、Semantic Kernel，還是直接用某個雲端 agent 平台？

這個問題不是不重要，但它太早了。太早選框架，常常會把團隊帶進一種工程錯覺：只要 workflow 連起來、tool calling 跑起來、memory 接上去，Agent 就會自然變成可用系統。

真實世界剛好相反。

AI Agent 真正難的不是「能不能做事」，而是「能不能在可控範圍內做事，做完後還能被人快速驗收」。如果這兩件事沒有先定義，框架越強，反而越容易把混亂自動化。

為什麼先選框架會出事

Agent 框架通常會讓 demo 變得很快。

你可以把模型接上搜尋、資料庫、文件、Slack、GitHub、CRM，再讓它自己規劃步驟、呼叫工具、整理結果。看起來很像把一個任務交給助理，而且助理還不會累。

但 demo 任務通常有三個被隱藏的前提。

第一，任務範圍很乾淨。
第二，資料來源很清楚。
第三，失敗代價很低。

公司裡的任務不是這樣。

真實任務會混著權限、例外、歷史脈絡、內部政治、資料品質和責任歸屬。客服摘要可能牽涉客戶隱私，銷售線索排序可能影響收入，財務報表整理可能牽涉錯誤決策，工程 PR 可能改壞 production。

這時候如果只是問「哪個框架比較會跑多步驟」，就像在問哪台車加速比較快，卻還沒畫道路、紅綠燈和煞車線。

Agent 越能做事，越需要先定義它不能做什麼。

第一步：把任務分成四種副作用等級

導入 AI Agent 前，先不要寫 prompt。先盤點任務副作用。

我會把任務分成四級。

第一級是讀取型：只讀資料，不改任何東西。例如整理文件、摘要會議、搜尋知識庫、比對公開資料。這類任務最適合早期導入，因為錯了也比較容易人工修正。

第二級是草稿型：產出建議，但不自動送出。例如寫客服回覆草稿、生成採購比較表、整理候選人摘要、草擬 PR 說明。這類任務有價值，因為它能省下起稿時間，但仍保留人工決策。

第三級是內部修改型：會改內部資料，但不直接對外或不可逆。例如更新內部文件、建立任務、開 draft PR、整理 CRM 欄位。這類任務開始需要版本紀錄、回復機制和審批。

第四級是外部動作型：會對客戶、金流、權限、production 或公開內容產生影響。例如寄信、付款、調廣告預算、改正式資料庫、發布文章、合併 PR。這類任務不應該一開始就全自動，至少要有 dry-run、人工確認和回滾。

這個分類比框架選型更早，因為它決定了 Agent 的權限設計。

如果一個任務只是讀取型，用簡單腳本加 LLM call 可能就夠了。
如果任務是第三級或第四級，就算框架很成熟，也需要沙盒、審批、紀錄和監控。

第二步：每個 Agent 都要有權限邊界

很多 AI 導入失敗，不是模型太笨，而是權限太模糊。

一個人類同事剛進公司，不會第一天就拿到所有系統最高權限。Agent 也一樣。

比較務實的做法，是替每個 Agent 定義四種邊界。

第一，它可以讀哪些資料。
例如只能讀指定專案、指定資料夾、指定客戶範圍，還是能讀整個公司知識庫。

第二，它可以呼叫哪些工具。
搜尋、讀檔、寫檔、開 issue、發訊息、查 CRM、更新資料庫，風險完全不同。

第三，它可以改哪些東西。
能不能只產生草稿？能不能建立 draft？能不能覆寫既有資料？能不能刪除？

第四，哪些動作必須停下來問人。
例如對外發送、金額變更、權限變更、刪除資料、公開發布、合併程式碼。

這些規則不該藏在 prompt 裡。Prompt 可以提醒，但不能當權限系統。真正重要的限制，應該在工具層、API 層、執行環境或工作流引擎裡被強制執行。

一句話：不要只相信 Agent 會乖，要讓系統設計讓它只能在安全範圍內動。

第三步：先寫驗收表，再寫 Agent 流程

很多團隊會先把 Agent 跑起來，然後才問結果好不好。

順序反了。

如果你不知道什麼叫好結果，Agent 只是在用很快的速度產出不確定性。它可能看起來很努力，步驟很多，輸出很長，但每一次都需要人從頭判斷。

導入前應該先寫驗收表。

例如客服摘要 Agent，驗收表可以包括：

• 是否列出客戶真正問題
• 是否標出情緒與緊急程度
• 是否引用原始訊息
• 是否避免承諾公司沒有承諾過的事
• 是否把不確定處標成需要人工確認

例如工程 PR Agent，驗收表可以包括：

• 是否只改指定範圍
• 是否附上測試結果
• 是否說明沒有處理的邊界
• 是否列出可能影響的模組
• 是否把高風險改動留給人工確認

例如內容產線 Agent，驗收表可以包括：

• 這篇文章補的是長文、導流、觀點、工具快評、FAQ、選型比較，還是趨勢短文
• 是否提供明確判斷，而不是只有資訊整理
• 是否連到讀者的下一步行動
• 是否有長期搜尋或信任價值
• 是否符合北極星：流量、信任、轉換，而不是只增加發文數

驗收表不是行政文件，它是 Agent 的產品規格。

第四步：把覆核成本當成核心指標

AI Agent 的 ROI，不能只看它跑了幾步。

真正要看的，是人類覆核它結果要多久。

如果一個 Agent 花三分鐘產出報告，但人要花三十分鐘查證，它可能沒有省時間。它只是把工作從「寫報告」轉成「審報告」。

所以每個 Agent 場景都應該記三個時間。

第一，原本人類自己做要多久。
第二，Agent 執行要多久。
第三，人類驗收 Agent 結果要多久。

第三個數字最關鍵。

如果覆核時間下降，Agent 才真的在釋放產能。如果覆核時間沒有下降，就要回頭檢查：是不是輸出沒有引用來源？是不是沒有說明假設？是不是工具呼叫紀錄太亂？是不是結果沒有照驗收表整理？

很多 Agent 產品會把重點放在「更自動」。但在企業場景裡，「更好驗收」常常更值錢。

第五步：從一條窄流程開始，不要一開始做全能助理

全能 Agent 很吸引人，但通常不是好的第一步。

更好的起點是一條窄流程：任務穩定、輸入穩定、驗收明確、失敗代價可控。

例如：

• 把客戶訊息整理成客服工單摘要
• 把會議逐字稿整理成決策與待辦
• 把新開源 AI 工具整理成採用判斷草稿
• 把內部文件轉成 FAQ
• 把 GitHub issue 分類並標出需要人看的高風險項目
• 把每週內容產線缺口整理成補題建議

這些任務不一定酷，但很適合建立信任。因為它們能被驗收，也能反覆執行。

Agent 導入最怕一開始追求「它什麼都能做」。比較好的目標是：它在一個小範圍內穩定做對，做完還能交代清楚。

框架什麼時候才重要

當你完成前面幾件事，框架選型才真的有意義。

如果你的任務需要明確狀態機、分支、回復和人工介入，LangGraph 這類偏工作流控制的工具會比較有用。

如果你的任務重點是多角色協作、研究或原型探索，CrewAI、AutoGen 這類多 agent 框架可以拿來試，但要特別注意可觀測性和失敗邊界。

如果你在 Microsoft 生態裡，需要和企業系統整合，Semantic Kernel 可能比較順。

如果你只是要把 LLM call、工具呼叫、結構化輸出寫得乾淨，Mirascope、Pydantic AI、BAML 這類更貼近程式碼的工具反而可能更合適。

如果你要的是非工程同事快速做內部 AI 應用，Dify、Flowise 或雲端平台會比工程框架更快。

框架不是答案，它只是放大你已經定義好的流程。

流程清楚，框架會加速。
流程混亂，框架會加速混亂。

結論

AI Agent 導入的第一步，不是選框架。

第一步是把任務副作用分級，畫出權限邊界，寫下驗收標準，並把覆核成本當成核心指標。

這些事情看起來不炫，但它們決定 Agent 能不能從 demo 進到真實工作。

對企業來說，真正有價值的 Agent 不是最會自己跑的那個，而是能在清楚邊界內穩定交付、留下紀錄、容易驗收、出錯也能回復的那個。

對想用 AI 建立內容、產品或被動收入系統的人來說，道理也一樣。自動化不是目的，可持續的信任才是目的。只要每一條 Agent 流程都能降低重工、降低覆核、累積可複用資產，它才會從玩具變成收入系統的一部分。

先別急著問哪個框架最強。

先問：這個 Agent 能做什麼、不能做什麼、怎麼驗收、錯了怎麼救。

答得出來，再開始寫流程。