如果團隊今天才開始評估 AI agent，第一週最容易犯的錯，是太快進入框架比較。
Mastra、LangGraph、OpenAI Agents API、Pydantic AI 都值得看，但它們不會自動替你回答一個更基本的問題：這個 agent 到底要接手哪一段工作？
所以今天 09:30 這篇不補工具清單，而補一篇 FAQ/導流文。它的任務是把近期幾篇文章串成一條比較能落地的閱讀路徑：先釐清控制面，再畫工作流，再選工具，最後才做第一週試點。
English TL;DR
The first week of AI agent adoption should not start with framework comparison. Teams should answer seven questions first: whether the task is worth automating, where the data lives, which steps the model can perform, who reviews risky actions, how success is measured, how cost is capped, and who takes over when the agent fails.
1. 這個任務真的需要 agent 嗎？
不是每個 AI 功能都需要 agent。
如果任務只是摘要、分類、翻譯、欄位抽取、語氣改寫，通常用一般模型 API 或既有後端流程就夠。硬上 agent framework，會增加狀態、權限、觀測與除錯成本。
比較適合 agent 的任務，通常有三個特徵：需要多步驟判斷、需要呼叫外部工具、需要留下可追蹤的中間過程。
例如內容審稿、客服建議、銷售研究、GitHub issue triage、內部知識整理，才比較接近 agent 的戰場。
2. 資料在哪裡？誰可以讀？
agent 的風險，常常不是模型回答錯，而是它讀了不該讀的資料。
第一週不要急著接所有系統。先列出任務需要的資料來源：文件、CRM、客服紀錄、repo、Notion、Google Drive、資料庫、網頁，或使用者貼上的內容。
然後把資料分級。公開資料、內部一般資料、客戶資料、財務資料、權限資料，不能用同一套工具權限處理。
如果這一步跳過，後面就算框架選對，也會在上線前卡在資安與責任歸屬。
3. 模型可以做哪一步？哪一步不能做？
AI agent 導入不是把整段流程交出去，而是拆出模型適合處理的步驟。
比較穩的拆法是：
- 模型可以整理資訊、提出候選、產生草稿、標記風險。
- 系統可以檢查格式、比對規則、限制成本、記錄工具呼叫。
- 人類負責批准高風險動作、修正商業判斷、承擔對外輸出。
這樣設計的好處，是 agent 即使判斷不穩，也不會直接把錯誤推進生產流程。
4. 哪些動作一定要人審核？
第一週試點最重要的不是讓 agent 自動完成最多事，而是定義哪些事它不能自己做。
寄出 email、改客戶資料、刪除資料、部署、調整權限、發佈公開文章、送出報價，這些通常都應該有人類確認。
如果團隊真的想提高自動化比例，也應該從低風險動作開始。例如產生草稿、開一個待審 PR、建立待辦、整理候選清單，而不是直接執行不可逆操作。
控制面成熟的意思，不是 agent 可以無人看管，而是每個高風險節點都知道誰能批准、誰能回滾、誰要負責。
5. 成功輸出長什麼樣？
很多 agent demo 看起來厲害，是因為驗收標準太鬆。
第一週要把成功定義寫清楚。不是「回答得不錯」，而是：
- 是否完成指定欄位？
- 是否附上來源？
- 是否符合格式？
- 是否標出不確定處？
- 是否能被人快速覆核？
- 是否真的節省時間？
如果 agent 產出的內容需要人從頭重看，那它可能只是把工作移到審稿階段。真正有價值的 agent，應該降低人工覆核與返工成本。
6. 成本與執行時間怎麼封頂？
agent 一旦可以多步驟執行，成本就不再是單次模型呼叫。
它可能查很多頁、反覆重試、呼叫多個工具、保留大量上下文，最後把小任務跑成大帳單。
第一週就要設定基本護欄：最多跑幾步、最多花多少 token、最多重試幾次、工具 timeout 多久、失敗後是否降級成草稿。
這不是財務細節，而是產品規格。成本不可控的 agent，很難變成可持續資產。
7. 失敗時誰接手？
agent 一定會失敗。真正成熟的系統，不是假設它永遠會成功，而是讓失敗容易接手。
至少要留下任務輸入、工具呼叫、模型輸出、引用來源、錯誤訊息、人工修改紀錄。這些不是為了寫漂亮 log，而是讓下一個人不用重新猜它做了什麼。
如果失敗後只能從頭重跑，agent 就沒有減少營運負擔；如果失敗後能快速接手、修正、回饋到下次流程，它才開始變成資產。
推薦閱讀路徑
如果你正在評估 AI agent，可以照這個順序讀：
第一，先看「控制面」。理解 agent 不只是模型，而是 context、工具、沙盒、審核、成本與復原的執行系統。
第二，看「工作流地圖」。在框架比較前，先把任務來源、資料、動作、審核、成功標準與失敗補救畫出來。
第三，看「工具快評」。例如 Mastra 這類 TypeScript agent framework，適合已經要把多步驟 AI 流程產品化的團隊，但不適合每個簡單 demo。
第四，再補「趨勢/反直覺」。AI 安全、agent harness、內容產線這些題目，核心都在同一件事：模型愈能做事，控制面愈值錢。
這條路比直接問「哪個框架最好」慢一點，但更接近能轉換成商業資產的判斷。
對內容產線來說，FAQ 是低摩擦轉換入口
FAQ 不是比較短的文章，也不是拿來補空檔的墊檔文。
它的價值是把讀者心裡已經有的問題接住。讀者不一定會搜尋「agent control plane」，但很可能會問「AI agent 第一週怎麼導入」、「我要不要用 agent framework」、「什麼情況需要人審核」。
這類文章能把工具流量導向場景判斷，也能把觀點文導向可執行清單。對被動收入的北極星來說，它比單純多一篇工具新聞更重要，因為它靠近決策、信任與轉換。
結論很簡單：第一週不要先追框架名。先回答七個問題。回答得出來，再選工具；回答不出來，先補工作流地圖。AI agent 真正的價值，不是看起來會自己做事，而是能在清楚邊界內穩定替你減少判斷成本。
延伸閱讀：