調研結論：截至 2026 年 10 月 3 日，AI agent 已從「回答問題」走到「讀資料、使用工具、修改檔案、檢查結果」的工作流程；程式開發是目前證據最多的用途之一。但能連續運作、能完成任務、值得授權執行，仍是三個不同問題。本文是依公開原始資料整理的現況調研，沒有替任何供應商做獨立實測，也不把展示影片或使用人數當作可靠度證明。
Day 4 盤點的是 2026 年 9 月的前沿事件與安全事故；這篇改問比較日常的問題：現在的 agent 究竟能替人完成什麼、從單體到集群怎麼建、怎麼優化，以及什麼情況值得訓練自己的 agent 模型？ 非技術讀者可先讀定義、成熟度與五個現況；開發者可接著看專案地圖、六道關卡、模型研發與評測。文中的「可做」指已有產品或研究示範，「可靠」必須再看具體任務的驗收資料。
先說清楚什麼是 AI agent
一般聊天模型收到問題後給一段回答。固定自動化則沿預寫步驟執行，例如每週一把報表寄出。AI agent 的差別是：它有目標、可用的工具與回授，會在執行中決定下一步；讀檔後可能發現缺資料，於是搜尋、呼叫程式、再檢查結果。這是行為描述，不是「會自己思考」或「不用人負責」的證明。Anthropic 的實際使用研究也指出業界沒有單一公認定義，採用「具備工具、能採取行動的 AI 系統」作可觀察的研究定義。OpenAI 的 agent loop 說明把模型、使用者與工具之間的循環稱為 agent 的核心。
以「整理十份公開文件」為例：聊天模型只能根據提供的文字回答；檢索工作流程按固定規則找十份文件；agent 則可能自行決定先查哪份、遇到互相矛盾的日期時再追原始頁，最後附證據。但若目標只是固定的「下載 A → 擷取 B → 存入 C」，傳統程式通常更容易測試，也不必付出 agent 每一步推理和除錯的成本。Anthropic 的架構分析同樣區分預定工作流程與模型動態決定工具使用的 agent，主張先採最簡單、足以完成任務的結構。
| 形式 | 下一步由誰決定 | 適合的工作 | 主要限制 |
|---|---|---|---|
| 聊天回答 | 人繼續提問 | 解釋、草稿、一次性分析 | 不會自行驗證外部成果 |
| 固定工作流程 | 程式設計者 | 步驟與例外穩定的重複任務 | 新情況要修改規則 |
| 受限 agent | 模型在指定工具與權限內 | 需搜尋、判斷、重試的窄任務 | 可能選錯工具或把資料當命令 |
| 長任務 agent | 模型加執行環境、記錄與檢查 | 跨多步驟的軟體或研究工作 | 上下文、成本、錯誤累積與接管 |
一張圖看 2026 年的現況
這張圖是本文的成熟度分類，不是替所有產品打分。每升一級，新增的不只是模型能力，還有環境、驗收、權限與負責人。
模型產生文字，人自己執行
程式決定步驟，模型處理局部判斷
模型能查資料、讀檔與重試
跨時間與環境留下中間成果
可在批准的邊界內改外部狀態
現在最穩妥的描述是：工具能力已普及，長任務能力快速提高，真正的生產部署仍需按任務縮小權限和測量成功率。不能因為 agent 會開瀏覽器，就推論它能安全處理付款、醫療、刪檔或正式發布。
五個已經看得見的發展
1 程式 agent 從補字走向完整工作循環
程式 agent 已能搜尋專案、編輯多個檔案、跑測試、讀錯誤，再提交可審查的變更。OpenAI 的 Codex app 說明展示平行工作與隔離工作樹；Anthropic 的 長任務 harness 研究指出即使有前沿模型與上下文壓縮，跨多次工作階段仍會出現「做太多、交接不清、太早宣稱完成」的問題，因而要留下可重讀的進度與測試證據。這些是產品與工程方法的進展，不代表任意程式碼都可免審合併。
使用量也在成長。OpenAI 的自家使用分析記錄了較長、較難的 Codex 委派；Anthropic 對 Claude Code 與 API 的使用研究發現，Claude Code 最長的少數工作回合在三個月內從不到 25 分鐘增至 45 分鐘以上，但中位回合約 45 秒。這是特定產品和觀察窗口的行為資料：較長的運作時間既可能表示能力提升，也可能是任務更難，不能直接讀成成功率。
2 知識工作開始從回答轉成製作可檢查的成果
研究、資料整理、報表、簡報與跨工具工作已出現在 agent 產品和企業試點中。OpenAI 公開的 Codex 使用分析稱 2026 年中每週使用者超過 500 萬、知識工作者約占兩成；這是供應商報告的使用數據，不是獨立抽樣的產業滲透率，也不說明每份成果是否正確。較有意義的比較單位是：引用能否回到原文、表格數字能否重算、檔案能否被下一位同事接手。
長時間執行的基礎設施也商品化了。OpenAI 在 2026 年 9 月推出的 Agents API 公測提供託管 harness 與可選執行環境；Anthropic 的 Managed Agents 工程說明討論持久任務與 harness 版本演進。公測、平台支援、客戶案例各自只證明功能可取得或有人使用，不能代替你的工作流程測試。
3 瀏覽器與電腦操作擴大範圍，也放大失敗
當 agent 能看畫面、點按鈕，理論上可跨沒有 API 的系統；實際上它也要處理頁面變動、登入、彈窗、資料新舊與操作後的外部副作用。以真實網頁長任務建構的 Odysseys 原始論文報告最強受測模型成功率 44.5%；需同時操作 GUI、命令列和程式碼的 WeaveBench 原始論文報告最佳組合 41.2%。兩個數字來自不同任務、環境與評分法，不可當成同一排行榜；它們共同說明，公開評測中的跨介面長任務尚未接近全對。
4 多 agent 與工具協定在成熟，但協作不是免費能力
MCP 2026-07-28 規格發布說明描述工具、資源、授權與跨服務連接的演進；Google Cloud 的 agent 開發指南將 MCP 視為接工具與資料，A2A 視為不同 agent 之間通訊的一種協定。兩者處理的是介面互通，不會自動解決資料是否可信、權限是否過大或兩個 agent 是否互相認可錯誤。
多 agent 值得用在可分離的工作：例如一個找來源、一個核算資料，第三個只檢查來源與結論是否相符。若所有 agent 都讀到同一份錯誤資料，或共用同一種評分漏洞，多加 agent 不會創造獨立證據。評估要算上協調、重複查詢和人工仲裁成本。Anthropic 的 agent 評測指南強調評估整條工具軌跡及環境狀態，而非只讀最終一句「完成了」。
5 企業開始管理 agent 的身份、權限和生命週期
agent 若能讀公司文件、呼叫 API 和替人修改資料，就不只是聊天介面，而是另一種需要身份和審計的執行者。Microsoft Agent 365 文件把可觀察、治理與保護列為控制面；其權限模式說明區分代理使用者、以應用程式身份執行、以及持續擁有自身身份的 agent。這是架構方向；企業是否安全，仍取決於實際權限、工具實作和事故回復。
在 Anthropic 的 API 工具呼叫研究中，軟體工程約占所觀察工具呼叫的一半，且大多動作低風險、可逆；研究者同時提醒，這是單一供應商的工具呼叫抽樣，不能推成「全產業一半 agent 都寫程式」。較高風險用途已出現，但是否是真實執行或安全評測，供應商未必能從呼叫紀錄辨別。
從單體到集群：增加的是協調，不是魔法
這裡的單體是「一個模型主導一次工具循環」，集群是「多個有明確分工的 agent 實例共同完成一個任務」。多個實例可以共用同一個模型；一個 agent 也能在背後使用分散式 GPU 推論。agent 集群、模型數量、GPU 集群是三個不同維度。真正增加的工程問題是：誰分派、誰能看哪些資料、成果如何交接、誰決定完成、失敗由誰回復。OpenAI Agents SDK 的協作說明區分管理者呼叫專家與把控制權交給專家；Google Cloud 的設計模式指南則列出順序、平行與循環等架構。
| 形態 | 任務與控制權 | 一個「公開產品更新調研」的做法 | 何時才值得升級 |
|---|---|---|---|
| 固定流程 | 程式依序搜尋、擷取、去重、產出 | 固定網站和欄位，每週跑一次 | 網站與規則穩定時，通常先停在這層 |
| 單一 agent | 一個 agent 決定要再查哪個來源、何時停止 | 用只讀搜尋與讀取工具，比對日期，列出無法確認項 | 需要動態追查且能逐項核對 |
| 主管加專家 | 主管拆工作，專家各有工具和輸出契約 | 來源搜尋、日期核算分開，主管合併並保留矛盾 | 子題可分離，單體的失敗已被量到 |
| 平行集群 | 多個工作者獨立跑，系統負責排程與彙整 | 按供應商分組查找，另設不共用結論的核驗 | 廣度大、時效重要，且有成本與品質收益 |
| 跨服務集群 | 多個服務各有身份、佇列、狀態與權限 | 搜尋、分析、審計服務跨團隊協作 | 已有多團隊、多資料域與明確營運責任 |
升級判準不是「能不能接更多 agent」，而是相同任務集上，增加實例後的驗收完成率、人工返工、端到端延遲與總成本是否一起改善。Anthropic 的多 agent 研究系統工程紀錄發現平行研究特別適合可分頭探索的問題，同時指出 token 消耗顯著增加、共享狀態或強相依工作不一定適合拆開；其內部成績不能直接當成一般產品收益。程式修改若會碰同一個檔案，應先切工作區、訂整合順序與衝突負責人，否則多 agent 可能只是平行製造合併衝突。
可把交接限制成一張卡：task_id、目標、允許工具、禁止動作、輸入來源、輸出格式、截止與預算、驗收條件、證據連結、未知事項。主管收到子任務時先核對證據，再決定是否讓另一個 agent 重查；不能只接受專家自稱「完成」。Magentic-One 的原始實作展示主管、網頁、檔案、程式與終端角色及進度紀錄，但這是研究架構參考，不是開箱即用的安全營運範本。
從入門到尖端的專案與資料地圖
下面按可學到的系統部位選擇專案，而非用 GitHub 星數排行。專案持續更新；本表是 2026-10-03 查核的入口，照做前需核對當前版本、授權、所需模型、沙箱和費用。不要同時學五種框架；每一層選一個，做出可重跑成果再往上走。
| 層級與原始資料 | 值得拆解的部分 | 可交付的練習 |
|---|---|---|
| 入門概念：Hugging Face Agents Course、smolagents | 思考／動作／觀察循環、工具描述；比較結構化呼叫與生成程式。後者執行程式須隔離 | 用兩個只讀工具回答一個問題，保留每步呼叫與錯誤 |
| 單體產品：OpenAI Agents SDK或 Google ADK | 工具、結構化輸出、狀態、人工接管與 trace | 有停止條件和來源的單一 agent，與固定流程比對 |
| 明確流程與交接：LangGraph、Microsoft Agent Framework | 狀態圖、checkpoint、分支、工作流程與多 agent 交接 | 把搜尋→核算→審核做成可暫停、可重跑的流程 |
| 專家分工：CrewAI 的 Crews／Flows、Magentic-One | 角色式協作與主管規劃；拿它們比較同一任務，不把更多角色當改善 | 一個主管、兩名專家和一個獨立驗收器，量額外成本 |
| 真實程式工作：OpenHands、SWE-agent | 隔離工作區、檔案與終端工具、重現測試、交付可審查差異 | 在可丟棄的測試專案修一個已知 bug，跑隱藏測試 |
| 評測環境：BrowserGym／AgentLab、τ²-bench、OSWorld 2.1 | 網頁、客服工具與電腦操作的可重跑環境；不同資料集不可混排 | 鎖定版本與資料切分，輸出通過率、軌跡與失敗分類 |
| 模型訓練研究：TRL、verl、Agent Lightning | SFT、偏好／結果回饋、多回合工具 rollout；需另外準備 GPU、資料與可驗證環境 | 先在小型模擬任務證明訓練比不訓練有效 |
AutoGen 的現行儲存庫明示進入維護模式，並建議新專案從 Microsoft Agent Framework 開始；舊教學和 Magentic-One 仍有研究價值，但不要未查版本就當作新專案主線。上述 OpenHands 與 Magentic-One 能執行程式或操作環境；研究時應用可丟棄沙箱和假資料，不能將產品示例的預設權限直接搬到自己的電腦或公司系統。
從零做到能比較集群的六道關卡
以下是本文設計的學習實驗，非這些專案官方課表。固定同一批公開產品更新，先由人建立答案與接受規則；每一關只改一項架構，才能知道改善從哪裡來。每個任務都要可重置、保留至少一部分沒拿來調提示詞的案例，並記錄模型、提示詞、工具、資料和程式版本。
- L0 無 agent 基線：用程式或人工列出發布日期、原文網址、變更。驗收：記每件時間、引用錯誤與漏報；若固定規則已夠好，後續 agent 不一定有價值。
- L1 單一工具循環：選 smolagents 或 Agents SDK，只給搜尋和讀頁工具，設最大步數、逾時與「找不到就說找不到」。驗收：合法工具呼叫率、事實與引用正確率，另記無限重試或假連結。
- L2 可回復狀態：加入持久化任務 ID、checkpoint、可重試的只讀工具與重複執行不產生副作用的設計。故意中斷一次。驗收：恢復後不重複提交、不丟失來源、不因舊資料自動宣稱完成。LangGraph 的狀態與持久化介面可供對照。
- L3 雙 agent 分工：一個查來源，一個獨立核對日期與引用；主管只合併通過的項目。驗收：與 L2 在相同案例、模型與預算比較。若只是多花 token、錯誤不減，就退回單體。
- L4 平行集群：按不同資料源平行查找，要求每個工作者回傳證據、未知事項和耗費；彙整器處理重複與矛盾，不用多數決掩蓋共同錯誤。驗收：看端到端延遲、每件有效成果成本、衝突與人工仲裁時間；用佇列和併發上限避免失控。
- L5 有權限邊界的服務：先在假資料環境測寫入、重試、回滾、審計與人工核准；再以 shadow mode 觀察真實任務。驗收：越權為零的測試集、失敗可回復、版本回退與責任人明確；尚未通過就不開自動對外寫入。
Anthropic 的 agent 評測指南強調同時檢查最後成果、工具軌跡與環境狀態。BrowserGym、τ²-bench 與 OSWorld 提供有用測試場，但任務、工具與評分法不一樣；公開跑分之外，仍需一套自己的保留任務集。
先優化流程，再考慮加模型或訓練
優化要以 被接受任務數／總成本 和 人員實際省下的分鐘 衡量，不以 agent 數或 token 數衡量。每次只變一項，重跑同一保留集、分場景報告結果；抽樣查看失敗軌跡。可按下列順序操作：
| 順序 | 具體改動 | 必看的退步訊號 |
|---|---|---|
| 1 量測 | 記每步輸入、工具參數、工具結果來源、模型、耗時、token、錯誤與人員介入；敏感資料先遮罩 | 完成率上升但人工審核更久，或 trace 本身洩露資料 |
| 2 工具與輸出契約 | 縮小工具清單、給明確型別與錯誤碼，將「查詢」和「寫入」分權；用程式驗證輸出欄位 | 工具選錯、無效參數、對錯誤回應反覆重試 |
| 3 上下文 | 去除重複搜尋結果；保留原文連結與時間戳；摘要舊進度但另存不可丟的原始證據 | 摘要後失去限制或來源，跨回合引用錯位 |
| 4 流程 | 把可預測步驟改成固定程式；只在獨立子題平行；給重試上限與停損 | 併發增加導致衝突、成本暴增或共同錯誤 |
| 5 模型選擇 | 用同一測集測小模型路由、強模型處理難例、不同推論預算；必要時再微調 | 便宜但人工返工更多、長尾任務突然失敗 |
| 6 驗收器 | 優先用測試、資料庫狀態、來源比對等可執行檢查；主觀評分才輔以另一模型和人工抽查 | 評審和生成者共享錯誤，或只學會討好評分器 |
Anthropic 的架構分析列出串接、路由、平行、主管工作者和評估優化器等模式；這些是因任務而選的工具箱，不是每套系統必走的升級階梯。MCP 可標準化接工具、A2A 可讓服務間通訊，但協定不能替代驗收與授權；更多 agent 也不等於更獨立的證據。
做 agent 模型：先分清模型能力與外部系統
模型負責理解目標、在不確定下選動作、產生符合格式的工具參數，並根據工具結果修正；harness（外部執行框架）負責真正執行、限制權限、保存狀態、計時、重試、審計與回滾。模型說「我已核准」不會產生核准；模型能輸出 JSON，也不代表工具參數符合商業規則。Hugging Face 的工具對話格式要求把工具呼叫、工具回覆和可用工具 schema 放進訓練資料；Transformers 的 chat template 文件說明推論時的格式須與模型學過的格式一致。
| 需要的能力 | 模型要學／要測 | 系統必須另外保證 |
|---|---|---|
| 指令理解與拆解 | 釐清目標、限制、停止條件；知道何時問人 | 清楚任務規格與超時、步數預算 |
| 工具使用 | 選對工具、有效參數、讀懂錯誤；該不呼叫時停 | schema 驗證、最小權限、隔離與逾時 |
| 多回合工作 | 對新觀察修正計畫、不憑空捏造完成 | 可回復狀態、版本、來源與工具日誌 |
| 證據與驗證 | 引用可回到來源，承認未知；區分測試通過和自我感覺 | 外部測試、資料庫狀態檢查與人工驗收 |
| 特定領域 | 會讀程式與測試、網頁畫面或公司流程；依用途選 | 實際工具與資料權限、領域專家標註 |
| 拒絕與授權 | 不照網頁、文件中的惡意命令行事；遇到高風險求核准 | 身份、政策引擎、執行時阻擋與審計 |
| 效率 | 在有限 token、時間與工具呼叫內解題 | 模型路由、快取、併發和成本上限 |
所以先選一個工具呼叫表現足夠的現有模型做基線，再決定缺的是工具設計、資料、特定能力還是模型本身。Qwen3 的原始專案公開了工具使用與模型家族資料，可作開放權重候選；閉源 API、不同開放權重和小模型的比較必須在同一工具與任務集下做，不能用廠商各自的榜單拼接排名。若任務需要看螢幕，還須圖像輸入、定位與動作對齊能力；只有文字工具呼叫訓練不能推出可靠的 GUI 操作。
從入門微調到尖端 agent 模型的完整研發流程
這裡的「完整」指研發決策與驗收鏈，不代表一人需要從零預訓練基礎模型。可獨立完成的起點是：現有模型加一個小型工具環境，在自建保留集上逐步改進。從零預訓練是另一個量級；OLMo 3 的公開訓練紀錄展示了基礎模型所需的大規模資料、運算、檢查點與訓練配置，適合學研究方法，不能當個人副專案的預算範本。
名詞先對齊：tokenizer 把文字切成模型處理的單位；chat template 規定角色、工具呼叫與回覆如何排成模型輸入；SFT 是用已示範的正確行為做監督式微調；DPO 等方法用成對偏好調整模型；RL 是讓模型在環境中多次嘗試，依結果獎勵調整；rollout 是一次完整嘗試留下的動作、工具回覆與結果軌跡。這些是不同層次，不應把「有更多執行日誌」說成「模型已經學會」。
- 定任務與成功訊號：先選一種工作（例如只讀查證、程式修 bug、客服規則查詢），寫出工具、允許副作用、成功狀態與失敗代價。先做無 agent 和現成模型基線；沒有基線，就不知道訓練是否有用。τ²-bench示範政策、工具、任務和環境共同定義評測。
- 建資料與版本治理：收集合法可用的人工或實際任務軌跡，去重、匿名化、核對資料授權；每條資料記
目標→可用工具→模型動作→工具觀察→最終環境狀態→人工／程式判分。保留錯誤、拒絕、超時和應詢問人的例子，不能只教成功演示。按任務來源或時間切訓練、開發、鎖住的測試集，避免近似重複與答案洩漏。 - 選底模與格式；實驗室才研究從零預訓練：個人先比較候選模型在同一工具 schema 的正確呼叫、長回合、語言、延遲和每件有效成果成本；鎖定 tokenizer、chat template、工具序列化與服務端解析器版本。這不是外觀細節：格式不對，模型會看不懂工具回覆或產生無法解析的動作。Transformers 的工具格式指南可逐項對照。若目標真是從零做基礎模型，另須建立有權利使用的語料、去重與品質過濾、訓練 tokenizer、定架構與資料配比、做下一詞預測預訓練及中期領域／長上下文訓練，追蹤損失與下游能力、儲存可恢復檢查點；OLMo 3 的公開配置可用來研究各階段依賴，不能把「訓好基礎模型」視為前四步自然帶出的結果。
- 先做 SFT 示範微調：用高品質的多回合示範教模型何時呼叫、何時等待工具、何時停止，包含參數錯誤後改正及遭遇未知時拒絕猜測。TRL SFTTrainer支援含
tool_calls、tool回覆與toolsschema 的資料；PEFT／LoRA可降低需要更新的參數與記憶體，但不保證效果等同全量微調。先在小任務做對照，別直接餵大量未核對合成軌跡。 - 逐軌跡評測與偏好修正：除了最終答案，檢查工具選擇、參數、引用、步數、停止與權限；對「兩個答案都可看，但一個更可靠」可蒐集標註偏好，研究 TRL 的 DPO 等訓練器。偏好標籤只表示標註者較喜歡，不保證真實環境完成。
- 有可靠判分才做多回合 RL：在可重置的沙箱讓模型反覆操作，用可執行測試或環境狀態給獎勵；限制步數、工具成本與高風險動作。研究入口是 TRL 的 agent GRPO、verl 的 agentic RL與 Agent Lightning。需監測模型是否鑽評分漏洞、讀到隱藏答案、把測試改掉或犧牲安全換分數；訓練分數上升後一定跑獨立保留集。這是需要算力、環境工程與研究經驗的階段，不是入門必要步驟。
- 進階能力按需求加：跨檔案與長任務要有長上下文和狀態交接資料；瀏覽器／桌面要有畫面、動作與結果配對；語音要有即時延遲與打斷測試；多 agent 交接要有清楚的輸入／輸出契約。各能力分開量，不把「更長上下文」當成已學會記憶與授權。BrowserGym與 OSWorld 2.1分別提供網頁和電腦操作研究環境，版本與任務需固定。
- 部署、監測與再訓練：受限服務先跑影子模式；記有效成果成本、人工接管、延遲、越權與隱私事件，依版本可回退。將真實失敗經授權清理後加入下一輪資料，再做盲測和回歸測試；不把使用者原始資料自動送進訓練集。Agent Lightning 的實作展示從真實 harness 收集 rollout 再訓練的研究方向，但資料權利、獎勵品質與生產上線仍由開發團隊負責。
判斷何時該訓練：若錯在工具權限、壞資料、無驗收器、流程相依，改模型權重往往治不了；若固定環境下反覆出現可標註的工具選擇或格式能力缺口，SFT 才可能划算；若有可靠、可重跑的結果獎勵且 SFT 已到瓶頸，再研究 RL。最尖端的工作不是把 agent 數量堆高，而是把模型、工具、環境、回饋、評測和營運成本做成可重複的閉環。
兩種常被混淆的數字
第一種是能力評測。 METR 的長軟體任務研究用「人類完成該類任務需多久」作難度刻度，觀察 agent 在指定環境以 50% 成功率能完成多長的任務。這裡的「五小時任務」是人類工作時間估計，不是 agent 連續工作五小時，也不是生產環境成功率 50%。任務類型、工具、可用時間與成功門檻變了，數字就不能照搬。
第二種是產品成效。 一篇 agent 文章寫「解出 80% 題目」，仍要問題目來源、是否洩漏到訓練資料、是否有隱藏測試、是否允許人協助、跑幾次取最好成績，以及錯誤是否可回復。OpenAI 2026 年對 SWE-bench Verified的回顧指出污染與測試缺陷；其後對 SWE-bench Pro 的稽核又估計約三成題目有問題。這不是說所有 agent 評測都無效，而是榜單不能取代自己業務的驗收集。
還有反方向的證據：METR 對 2025 年初工具所做的隨機試驗中，16 位熟悉成熟開源專案的開發者在 246 項任務上使用當時 AI 工具，平均完成時間反而增加 19%。此結果限定於當時工具、參與者與任務，不能直接宣稱 2026 年所有 agent 都使人變慢；它提醒我們自覺變快、跑分提高與實際節省人時可以不同方向。
| 公開數字 | 真正量到什麼 | 不能推論什麼 |
|---|---|---|
| 使用者數與工具呼叫數 | 使用與採用 | 成果正確率、節省工時 |
| 任務通過率 | 特定資料集和規則下的表現 | 任意公司流程都能通過 |
| 人類工時難度的 50% 時間跨度 | 某類任務的能力邊界 | agent 實際跑多久或產品可用率 |
| 影片與單次成功案例 | 在展示條件下可做到 | 重複性、例外處理與安全性 |
| 自家試點的「驗收完成率」 | 指定使用者對指定任務的接受情況 | 換資料或換場地後仍維持結果 |
部署時真正要算的成本
模型費用只是成本的一行。每一件被使用者接受的完成任務，至少要算模型與工具呼叫、沙箱與儲存、人工查核、錯誤修復、權限與記錄管理；若 agent 跑 100 次卻只有 60 次可接受，就不能用 100 次作效率分母。可用簡式：
每件有效成果成本 =（推論 + 工具／環境 + 人工審查 + 返工 + 維運）÷ 被接受的成果數
例如每月 100 件原本各需 12 分鐘的窄任務，總共 20 小時。純示例：agent 的 80 件成果各需人審 2 分鐘，另 20 件仍需人完成 12 分鐘，加上 4 小時設定與維護，人工合計 10 小時 40 分，節省 9 小時 20 分，之後仍要扣除模型和基礎設施費用。若錯誤難被發現、一次錯誤的代價高，這個算式還必須加入事故期望損失。此示例沒有假定任何產品真有 80% 的可接受率。
agent 的安全邊界應由系統執行
網頁、郵件、文件與工具回傳都是資料來源，也可能夾帶命令。提示注入會試圖讓 agent 把第三方內容當成使用者要求。Anthropic 的瀏覽器提示注入研究明言瀏覽器 agent 並非免疫；OpenAI 的Codex 安全運作說明列出存取邊界、核准與外部遙測。只靠在提示詞寫「不要洩漏」不足以保護憑證或資料。
一個可落地的控制順序是：先只讀 → 再允許在測試環境寫入 → 限定資料與工具範圍 → 為不可逆動作設人員核准 → 留下 agent 無法自行改寫的紀錄與回復辦法。工具需具明確輸入規格、逾時、輸出來源與錯誤狀態；授權要分「可看」「可改」「可發送」而非給整個帳號的全部權限。MCP 的工具註記說明也提醒，「唯讀、破壞性」等註記只是風險提示，不能代替執行端的存取控制。
一個團隊如何驗證自己的第一個 agent
第一個試點不必挑會寄信或會改資料庫的工作。選整理公開產品更新並附來源這種可人工核查的任務：一週做一次，輸出「變更、發布日期、原文連結、影響範圍、查不到時的標記」。如果固定程式加人工核對已足夠，就不必做 agent。
- 先收集 30–50 件真實舊案例，保留過期公告、相互矛盾的頁面、缺連結、重複資訊與插入惡意指示的頁面；人工寫好可接受的答案或評分規則。這是本文建議的試點樣本量，不是統計保證。
- 量人工或固定流程的基線：每件耗時、遺漏、引用錯誤與返工。把一部分案例鎖起來當驗收集，不拿來調 agent 提示詞。
- 給 agent 最少量的讀取工具，要求輸出每項事實的來源、無法確認之處和處理記錄。先在影子模式跑：它產生成果，但不自動發布。
- 逐件記錄被接受率、引用正確率、人工審查分鐘數、失敗類型、延遲與總成本。對惡意頁面另量是否越權；只看最後答案，會漏掉中途危險的工具動作。
- 只有當它在保留案例及新一週資料上持續優於基線，才擴大範圍；若要加入寄信、發布、刪改等動作，另設權限、核准與回復測試。
這些步驟可對照 Anthropic 的 agent 評測指南與 Google Cloud 的上線指南。它們是工程方法，並非某家平台的採購必要條件。
未來十二個月值得觀察的訊號
以下是根據上述資料的推論，不是已發生的事。長任務服務、工具標準和身份治理會讓更多 agent 從聊天窗進入背景工作；但若只見到更長的運行時間，沒有更高的驗收完成率或更低的人工返工，價值尚未成立。最重要的公開訊號將是：跨供應商可重現的長任務成績、成本與錯誤同時公布、對外動作的事故與復原資料、以及在同一工作流程下與人工或固定自動化的對照。
本文的判斷因此是窄任務、可回復、可量測的 agent 已有實際用途；多 agent 集群必須證明相對單體的增益；高風險、跨系統、長期自主運作仍需逐案驗證。讀者若要選工具，先問「能驗收哪個成果」，再問「需要幾個 agent、是否需要改模型」。本篇只調研公開資料，未取得跨產品、同條件的獨立測試，也未執行文中的開源專案或模型訓練；專案狀態、功能與數字以 2026 年 10 月 3 日為查核時點。