AI agent 與工作流程：哪些步驟值得交給模型？：實作與驗收指南

本課內容

01先把定義說清楚
02現場情境
03實作範例
04照著做，每一步都有檢查點
05實務脈絡
06動手實作
07故障診間
08正式上線前的邊界
09資料來源與主張限制

這一課會完成什麼

用可觀測的營運條件說清楚工作流程與 agent 的邊界
把需要解讀的模糊處，和可以寫死的業務規則分開
用品質、延遲、成本、權限範圍與復原工時比較三種架構
針對具名任務留下採用或不採用 agent 迴圈的決策紀錄

開始前先準備

• 了解基本 API 與事件驅動軟體概念
• 本機 TypeScript 執行環境；不寫程式也可用試算表完成比較

先把定義說清楚

Agent 與工作流程

工作流程的下一步由程式決定；模型輔助的流程，只把需要判斷的節點交給模型。Agent 迴圈則讓模型在核准的工具中連續選擇下一步，由應用程式判定任務是否完成、是否轉交人工，或是否已達預算上限。三種架構都能呼叫 LLM，差別在於誰決定下一步、誰有權停止。本篇用相同需求比較它們，選擇能通過驗收、自治程度最低的版本。

穩定流程若全塞進提示詞，審查、測試與復原都會變麻煩。規則留在程式裡，模型只處理真正有歧義的地方，通常更省，也更容易查出哪一步壞掉。

自治程度每增加一層，失敗面也跟著擴大。多一輪可能多花一次費用、重複錯誤假設、要求權限更高的工具，或讓復原依賴殘缺的對話紀錄。這些成本要在架構決策當下算進去。

現場情境

Northstar 研究需求分流

具名合成情境。Northstar 分析與本模組所有資料都是教學測試資料，不是 Tenten 或客戶的正式部署。

負責人: 你是支援 6 人 B2B 行銷研究團隊的平台工程師。
要做的決策: 替每一類需求選確定性的工作流程、模型輔助的工作流程或有上限的 agent。
目前狀態: 研究員從共用表單收到需求。每筆需求都要檢查範圍、選來源政策、蒐集證據，再交分析師審查。待辦同時有規律的競品更新，也有邊界不明的市場探索。團隊過去把兩種工作都丟給同一個提示詞，遇到錯誤時只看得到最後一段文字。
預期成果: 例行更新走確定性的工作流程；模糊的範圍只用一次結構化模型決策；只有需要廣度探索的研究，在同一套評測擊敗簡單基準後，才使用唯讀有上限的迴圈。

限制條件

• 系統只能讀取，不能發布、寄信、買廣告或修改 CRM。
• 每次執行的模型與工具預算上限為 USD 1.00，時間 90 秒，最多 8 個模型回合。
• 只能查核准的公開網域與合成內部資料集。
• 最終摘要由分析師負責；分析師可直接退回沒有來源的主張。

實作範例

Northstar 用三種架構跑同一批 12 筆需求

證據類型: 具名模擬情境

團隊建立 12 筆合成需求：4 筆例行競品更新、4 筆需要一次分類判斷、4 筆開放式研究。三個版本共用相同來源、工具與驗收規則。工作流程版本按固定步驟查表；模型輔助的版本只讓模型判定請求類型；agent 版本可以在搜尋、讀取與摘要之間選下一步，但受回合、時間與費用限制。

例行題只要確定性的版本能全數通過，就不替它加模型。分類題若單次結構化輸出能穩定送進正確路徑，也不開 agent 迴圈。開放研究則比較證據涵蓋、錯誤主張、分析師修改量、p95 延遲與成本。只有 agent 在同一批測試資料上取得實質改善，且沒有增加重大失敗，才保留自治。

這個練習不預設 agent 會贏。決策表會留下每類題目的最低可行架構、未通過項目、預算與降級路徑。若 agent 只讓文字更長，卻沒有補足證據，結論就是退回模型輔助的工作流程。每次架構變更都要重跑 12 筆測試資料。

主張限制

需求集很小，而且全是合成資料。成本與延遲會受供應商、區域、模型、快取狀態與工具實作影響。Anthropic 的工作流程／agent 指引支援這套決策框架；本例的數字門檻是 Northstar 自訂政策，不是供應商建議。

做法

照著做，每一步都有檢查點

現場情境

替每一類需求選確定性的工作流程、模型輔助的工作流程或有上限的 agent。

01固定任務與驗收規則
02先跑確定性的基準
03只在歧義節點加入模型

驗收條件

產出一張按任務類別拆開的比較表。每列都有成功率、證據錯誤、分析師修改量、p95 延遲、費用、重大失敗與復原方式；決策紀錄指定最小可行架構及 agent 的撤回條件。

這張圖要幫你看懂什麼用確定性的圖表並排三種控制拓樸，再把測試資料指標放在同一張比較表。重點是誰決定下一步、哪裡會停，以及差異是否真的量得到。

01
固定任務與驗收規則
替 12 筆需求標示請求類型、必要來源、允許工具、完成條件與禁止動作。這些標籤在比較結束前不能跟著結果調整。
檢查點 · 每一題都有可由程式或分析師觀測的 pass／fail 條件，三種架構讀取同一份清單。
02
先跑確定性的基準
用程式寫出固定控制路徑，記錄品質、步數、延遲、費用與人工修改量。這是後續版本必須超過的基準，不是故意做弱的陪跑組。
檢查點 · 12 筆需求都有停止原因；失敗能定位到規則、來源或工具，而非只有一段自然語言說明。
03
只在歧義節點加入模型
把請求類型改成嚴格結構化輸出，驗證 schema、模型拒絕與未完成狀態。其餘控制路徑保持不變。
檢查點 · 例行題不增加模型呼叫；分類錯誤會停在明確錯誤碼，不會默默流進錯誤流程。
04
最後才加入有上限的迴圈
只讓開放研究使用搜尋與讀取，並由應用程式掌握回合、工具、時間與成本上限。加入重複查詢、工具失敗與證據不足測試資料。
檢查點 · 任何超限、重複或無進展情境都能停下並留下停止原因；agent 沒有外部寫入能力。
05
做出可撤回的決策
按任務類型比較結果，寫出採用條件、未解風險、降級版本與重跑時機。不要用平均分數蓋掉重大失敗。
檢查點 · 另一位工程師只看資料與執行軌跡，就能重現為何某一類需求選這個架構。

實務脈絡

展示版之後

實作拆解

三個版本共用同一份觀察紀錄契約，才能比較延遲、成本與人工修改。把每筆請求的輸入、必要來源、允許操作、停止原因及修改逐欄寫成 JSONL，再由指令彙總。固定流程若漏拿必要證據，可以定位涵蓋缺口；Agent 若多跑 4 個回合仍只拿到相同證據，增加自治便沒有帶來價值。按任務類型選擇架構，並留下採用理由。

延伸實作

架構評審不要只交結論。附上十二筆需求逐題紀錄，標示固定流程在哪裡足夠、單次模型判斷解決哪個歧義、受限迴圈又多取得了哪份證據。分析師修改內容也分類成遺漏來源、範圍過大、事實錯誤與單純文字調整。這能避免團隊把篇幅變長或語氣流暢誤當品質改善。若受限迴圈只在一種開放研究題通過，就只替那種題開啟，不把整個入口都升級成自治。

動手實作

完成三種架構的決策測試

把 Northstar 的 12 筆需求各跑過確定性的、模型輔助的與 agent 三個版本，記錄相同欄位，再針對每類題目選最小自治。

準備項目

• 凍結同一份測試資料、來源政策與驗收規則，避免替不同架構換題。
• 所有工具保持唯讀，並用模擬轉接層回傳固定結果。
• 先定義重大失敗：未授權工具、無來源主張、無終止狀態或超出執行預算。

本課產出

三個可執行版本、12 筆測試資料結果、逐題執行軌跡、比較表，以及一頁架構決策紀錄。

起始模板: 架構決策設定

YAML

scenario: northstar-research-intake
request: "Compare governance claims across four approved competitor domains"
owner: marketing-research-lead
options:
  deterministic:
    path_known: true
    uncertain_decisions: []
    permissions: [read_fixture]
  model_assisted:
    path_known: true
    uncertain_decisions: [classify_governance_passage]
    permissions: [read_fixture]
  bounded_agent:
    path_known: false
    uncertain_decisions: [choose_next_source, decide_evidence_gap]
    permissions: [search_approved_domains, read_public_page]
limits:
  max_turns: 8
  max_wall_seconds: 90
  max_cost_usd: 1.00
  side_effects: 0
acceptance:
  citation_coverage: 1.0
  unsupported_claims: 0
  forbidden_tool_calls: 0
decision: TODO
reason: TODO

預期結果

留給下一課

保留 autonomy-review.yaml、請求清單、三個基準版本與決策紀錄。模組 06 會把有上限的 Agent 分支做成外部狀態機；模組 10 再沿用相同上限做正式環境上線準備審查。

驗收條件

01三種版本使用完全相同的 12 筆測試資料、來源與重大失敗定義。
02每次執行都有架構版本、工具事件、預算事件與停止原因。
03任何 agent 選擇都必須對至少一項預先定義指標有可見改善，且重大失敗不增加。
04決策紀錄包含選擇、證據、限制、負責人、降級路徑與下次重跑條件。

常見故障

故障診間

F1Agent 每次都照相同順序呼叫工具，成本卻高於工作流程。

先檢查: 把每筆執行軌跡的工具序列、模型回合與分支決策排在一起看。
可能原因: 流程其實穩定，自治只把寫死的路徑藏進提示詞。
修復方式: 把固定步驟搬回程式，只在真正有歧義的節點保留模型判斷。
下次怎麼避免: 每次增加自治前，先證明同一批題目不能由較簡單版本通過。

F2Agent 的文字更完整，但分析師仍要重查所有主張。

先檢查: 比對逐項主張的引註、來源涵蓋與分析師修改紀錄，不看篇幅或語氣分數。
可能原因: 驗收只評估輸出可讀性，沒有把證據品質列為門檻。
修復方式: 把必要來源、引用正確性與不受支持的主張設成阻擋執行的評分器。
下次怎麼避免: 所有架構比較都要同時報告任務結果與證據錯誤。

F3政策限制寫在提示詞，某次執行仍要求了禁止工具。

先檢查: 查看工具登錄清單、伺服器端允許清單與執行器拒絕事件。
可能原因: 確定性的規則只是自然語言提醒，沒有成為應用程式必須成立的條件。
修復方式: 在執行器阻擋並記錄禁止工具，模型無權更改。
下次怎麼避免: 把權限與預算規則做成依表格驅動的測試。

F4架構被選中後，團隊說不出什麼情況要退回上一版。

先檢查: 檢查決策紀錄是否有重大失敗、成本上限、品質下限與負責人。
可能原因: 決策只記了選什麼，沒記假設與撤回條件。
修復方式: 補上可量測門檻、降級版本與重跑日期。
下次怎麼避免: 把 ADR 當成發布交付檔案，由非作者審查。

展示版之後

正式上線前的邊界

01先有確定性的或單次呼叫基準，再談 agent 迴圈。
02逐一列出模型能決定、不能決定與必須交人工的事項。
03把權限、預算、逾時與停止條件留在應用程式。
04用同一批測試資料比較品質、證據、延遲、費用與人工工時。
05任何重大失敗都不能被平均分數抵銷。
06替每次執行記錄架構版本、設定、執行軌跡與停止原因。
07寫出工具故障、模型拒絕、證據不足時的降級流程。
08指定決策負責人、重評日期與撤回自治的門檻。

下一篇：LLM API 與結構化產出 →AI-native 行銷基礎 →

證據類型

資料來源與主張限制

資料來源只支撐本課標示的主張，不代表換一個系統也會得到相同結果。

[1]
打造有效的 agent
Anthropic · 官方文件 · 2026-08-20
workflow 與 agent 的定義 · 架構模式 · 成本與控制的取捨
[2]
Orchestration and handoffs
OpenAI · 官方文件 · 2026-08-20
handoff · 把 agent 當成工具 · single-agent 基準
[3]
用來打造 agent 的新工具
OpenAI · 公開案例 · 2026-08-20
Responses API 架構 · Agents SDK 能力 · 公開報導的客戶實作
[4]
AI Risk Management Framework
NIST · 官方文件 · 2026-08-20
風險治理 · 衡量方式 · 營運責任