企業AI Agent任務應寫成可執行、可驗收的Task Contract，而不是一句模糊指令。Task Contract至少要定義目標、輸入、輸出、資料範圍、允許工具、禁止事項、完成條件、例外處理、人工接手與回退方式。
這種規格把團隊經驗轉成模型、工具與人都能理解的工作契約。Agent知道做到哪裡應停止；使用者知道會得到什麼；技術與治理團隊也能測試權限、成本與錯誤影響。
重點快讀
- Task Contract把模糊需求轉成可驗收的任務規格。
- 輸入、輸出、權限、停止與人工接手必須同時定義。
- 正常流程之外，還要列出缺資料、來源衝突、工具失敗與越權請求。
- 每次外部寫入都要標示目標、影響、冪等與回退方式。
- 任務規格應有版本與擁有者，不能由Agent自行修改核心規則。
Task Contract包含哪些欄位？
| 欄位 | 要回答的問題 |
|---|---|
| Goal | 這個任務要完成什麼具體結果？ |
| Inputs | 需要哪些資料、格式、版本與來源？ |
| Outputs | 交付物格式、欄位與保存位置是什麼？ |
| Scope | 可處理哪些對象、時間與資料範圍？ |
| Allowed Tools | 可以使用哪些工具與權限層級？ |
| Forbidden Actions | 哪些行動明確禁止？ |
| Acceptance | 如何判斷輸出通過驗收？ |
| Exceptions | 遇到缺漏、衝突、失敗時怎麼處理？ |
| Human Handoff | 什麼情況、交給誰、附哪些資料？ |
| Rollback | 錯誤後如何撤銷或恢復？ |
| Budget | 最大時間、步數、Token與工具成本？ |
| Owner | 誰維護規格並對結果負責？ |
一份可直接套用的Task Contract
task_contract:
id: wp-article-update-v2
owner: content-team
goal: 更新指定WordPress文章，消除重複搜尋意圖
inputs:
required:
- post_id
- existing_content
- target_intent
optional:
- official_sources
- internal_link_targets
scope:
site: yololab.net
allowed_post_ids: [TARGET_POST_ID]
preserve:
- slug
- publication_status
allowed_tools:
- read_post
- search_site
- read_primary_sources
- update_same_post
forbidden_actions:
- create_duplicate_post
- change_slug
- delete_content
- update_other_posts
- publish_unconfirmed_draft
output:
fields:
- title
- excerpt
- content
- seo_title
- meta_description
- focus_keyword
acceptance:
- opening_answers_core_question
- title_matches_unique_intent
- claims_are_traceable
- internal_links_have_distinct_intents
- status_unchanged
- slug_unchanged
exceptions:
missing_source: stop_and_report
conflicting_source: human_review
update_failed: verify_before_retry
permission_denied: no_retry
human_handoff:
before_external_write: required
include:
- target_post_id
- change_summary
- risk_notes
rollback:
- preserve_previous_revision
- record_modified_timestamp範本可以改成客服、報表、程式修復、發票整理或資料分析任務。核心原則相同：讓Agent的自主判斷發生在明確邊界內，外部副作用與責任則受到系統與人工控制。
如何把模糊需求改成可驗收任務？
| 模糊需求 | 可驗收任務 |
|---|---|
| 整理客戶需求 | 彙整本週工單，依產品、嚴重度與重複問題分類，附原工單ID與無法判斷項目 |
| 幫我研究競品 | 整理五家指定競品近三個月功能與定價更新，附官方來源、日期與差異表 |
| 優化網站文章 | 更新指定Post ID，保留slug與狀態，處理一個搜尋意圖並建立兩個相關內鏈 |
| 修復程式 | 重現指定Issue，提交最小Patch，通過既有測試並新增回歸測試 |
| 回覆客戶 | 依知識庫建立回覆草稿，標示引用來源與需要人工決定的補償方案 |
一個任務若無法說明「什麼證據能證明完成」，就不適合直接交給Agent自動執行。應先整理SOP、範例與例外，再決定哪些節點需要模型判斷。
例外處理要在上線前寫清楚
| 例外 | 建議處理 |
|---|---|
| 必要輸入缺失 | 停止並列出缺少欄位 |
| 來源互相衝突 | 保存來源與差異，交人工判斷 |
| 工具暫時逾時 | 有限次退避重試 |
| 參數或Schema錯誤 | 修正一次，仍失敗則停止 |
| 權限不足 | 禁止重試，不要求更高權限自行繞過 |
| 目標範圍改變 | 建立新版本或重新核准Task Contract |
| 不可逆操作不確定 | 停止並顯示完整影響 |
所有錯誤都自動重試，可能把一次小故障變成重複寫入、成本爆炸或更難回復的狀態。例外分類應直接影響重試、停止與Handoff策略。
人工接手需要完整Handoff Packet
- 任務ID、規格版本與目前狀態。
- 已完成步驟與使用過的工具。
- 相關資料、來源、Artifact與版本位置。
- 失敗或衝突的具體原因。
- Agent已嘗試的處理與結果。
- 需要人決定的問題與可選方案。
- 即將產生的外部影響與回退方式。
「無法完成，請人工處理」不是有效交接。接手者應能在不重新執行整個任務的情況下理解現況並作出決定。
工具與資料權限如何寫進契約？
- 指定可讀資料來源與時間範圍。
- 限制可操作的資料列、Post ID、Repository或客戶。
- 區分Read、Draft、Write與High-impact Tools。
- 為寫入設定冪等鍵、Dry Run與最大批次。
- 標示哪些工具呼叫需要逐次核准。
- 禁止把Secrets寫入輸出、Memory與Trace。
Task Contract描述任務層級邊界；真正的權限仍要由API、資料庫、Runtime與Sandbox強制執行。企業治理架構可延伸閱讀企業導入AI Agent怎麼治理？資料、身份、權限與稽核。
如何驗收Task Contract本身？
- 用正常案例確認輸出能通過。
- 移除必要欄位，確認Agent會停止。
- 提供互相衝突來源，確認會Handoff。
- 模擬工具逾時，確認不會重複副作用。
- 要求超出Scope操作，確認權限阻擋。
- 達到成本上限，確認流程能安全結束。
- 更換模型後重跑相同測試。
任務規格與Eval應一起版本化。若模型或工具更新後通過率下降，可以判斷是能力變化、規格模糊，還是外部系統改變。
Task Contract如何進入團隊流程？
- 從一項已有SOP的高頻任務開始。
- 由領域專家整理正常流程與例外。
- 技術人員把工具、Schema、權限與回復寫入契約。
- 實際使用者用真實案例測試。
- 所有修改經Owner審查並增加版本號。
- 通過Shadow Mode後才開放有限寫入。
完整30天試點流程，可接著閱讀AI Agent導入30天計畫：Shadow Mode與上線Gate。
常見問題
Task Contract和Prompt有什麼差別？
Prompt是模型當下收到的指令；Task Contract是任務的正式規格，還包含資料、權限、驗收、例外、成本與責任。Task Contract可以被轉成Prompt、Workflow設定與測試。
每個任務都需要很長的規格嗎？
不需要。低風險、簡單任務可以使用短模板；工具多、影響大或需要跨系統寫入時，規格才需要更完整。
Agent可以自行修改Task Contract嗎？
Agent可以提出修改建議，但不應自行改變Scope、權限與完成條件。核心規格應由Owner審查並版本化。
延伸閱讀
Task Contract讓企業能明確控制Agent的目標、權限、例外與責任。任務被寫清楚後，自動化才有穩定測試、交接與擴張的基礎。
發表迴響