替 Agent 接上一個函式並不難。

真正容易失控的是，當系統同時擁有 shell、browser、database、GitHub、email、Slack、internal API、MCP server、skills 和 plugins 時，模型該看到哪些能力、該選哪一個、誰有權執行，以及結果要用什麼格式回到下一輪推理。

假設一個 Agent 要完成「找出本週逾期發票，產生催款草稿，經批准後寄出」：

  • 查詢發票可能是 Tool、SQL CLI 或 MCP tool。
  • 催款規則與語氣可能放在 Skill。
  • 寄信前的審查可以是 Hook 或 Policy Gate。
  • Gmail 整合可能由 Plugin 安裝，也可能透過 MCP server 提供。
  • 若工作委派給另一個獨立財務 Agent，才會進入 A2A 的問題。

這些名詞不是同義詞，也不在同一層。

能力工程（Capability Engineering）處理的，是能力如何被描述、發現、選擇、授權、執行、觀測與持續治理。 把函式名稱丟進 Prompt，只完成其中很小的一段。

Tool、Skill、Plugin、Hook、MCP 與 A2A 的責任分層

Figure 5-1｜Tool 是可執行單元；Skill 是工作方法；Plugin 是宿主擴充包；Hook 是生命週期插入點；MCP 與 A2A 則處理不同邊界的互通。

先把常被混用的名詞拆開

能力層最常見的問題，不是缺少新名詞，而是同一個詞在不同產品裡指向不同東西。比起背某個 Framework 的命名，先看它回答什麼問題更可靠。

以下是本系列採用的工作定義，不代表所有 Host 或 Framework 都使用相同名稱。

名稱它回答的問題典型內容
ToolAgent 能執行哪一個具體能力？search_documents、run_tests、send_email
Command使用者或系統明確觸發哪個入口？/eval、CLI command、API route
Skill這類任務應按什麼方法完成？SOP、工具順序、判斷規則、驗收標準
Plugin宿主可以安裝哪一包擴充能力？tools、skills、commands、hooks、UI、設定
Listener某個事件發生後，誰接收通知？telemetry、audit、analytics
Hook流程到某個生命週期點時，要插入什麼行為？PreToolUse、PostCompact、SessionEnd
Middleware哪段邏輯包住整個 request／response pipeline？auth、trace、normalisation、rate limiting
Interceptor哪個 operation 在執行前後可被攔截或改寫？tool validation、approval、policy extension
MCPAI host 如何連接外部 tools、resources 與 prompts？Host／Client／Server capability protocol
A2A獨立 Agent 如何互相發現、委派與管理任務？Agent Card、Task、Message、Artifact
Full Harness ProtocolClient 如何驅動完整 Agent Runtime？Thread、Turn、Streaming、Approval、Diff、Resume

一個宿主可以同時具備以上多種機制。例如：

Harness
├── Command Router
├── Skill Library
├── Plugin Manager
│ └── MCP Client Adapter
├── Hook / Middleware System
├── Tool Registry
└── Policy / State / Verification

這張樹狀圖不能拿來判斷誰比較「高級」。它只是在標示責任位置。

Tool 是一個可執行單元；Skill 告訴 Agent 怎麼完成一類工作；Plugin 讓宿主安裝一包能力；Hook 在既有生命週期插入行為；MCP 把能力跨程序或跨產品暴露給 AI host；A2A 則把另一個 Agent 當成可協作的遠端系統。

把這些東西全部叫做「工具」，設計審查很快就會失去精度。

Tool 可見、可發現、可授權與可執行是四件事

能力治理最容易被壓成一句：「這個 Tool 已經提供給模型，所以模型可以使用它。」

這句話混合了不同狀態：

  1. Registered：Tool Contract 已進入 Registry。
  2. Discoverable：目前 Actor 可以看見它的 Catalog Metadata。
  3. Model-visible：完整 Schema 已載入這一輪 Context。
  4. Authorised for this call：目前 Actor 可以對 Canonical Resource 執行這次 Operation。
  5. Executed with a known outcome：Runtime 已執行，並提交可關聯的 Terminal Result。

Tool 出現在 Model Context，最多證明它已被暴露。它不會自動證明 Per-call Permission，也不會證明外部副作用已成功完成。

這條邊界同樣適用於 Built-in Tool、Plugin Tool、MCP Tool 與 Server-executed Tool。執行位置可以不同，產品仍要知道哪一層負責 Identity、Tenant Scope、Business Policy、Approval、Side-effect Evidence 與 Completion。

一次 Tool Call 不是從模型輸出直接跳到 Handler

模型產生結構化 Tool Request，只代表它提出候選操作。

一個較完整的 Tool Execution Lifecycle 是：

Resolve catalog snapshot
→ Parse and schema-validate
→ Canonicalise arguments and resources
→ Classify effect, risk and concurrency
→ Final authorisation / approval
→ Bind execution context
→ Execute in boundary
→ Normalise result
→ Commit audit and observation

Tool Execution Lifecycle

Figure 5-2｜模型提出 Tool Request 後，Harness 先解析成 Canonical Operation，再依實際 Resource 與 Risk 完成最終授權、執行與結果提交。

Resolve catalog snapshot

Runtime 先固定：

  • Stable Tool ID
  • Tool Version
  • Catalog Version
  • Handler 或 Transport
  • Host、Tenant、Region 與 Runtime Availability
  • Name Collision Policy
  • Deprecation／Disabled State

模型輸出的 Tool Name 不是 Executable Pointer。

如果模型看到 billing.send_reminder@v2，執行時只剩語意不同的 v3，Runtime 不應悄悄替換。它應回傳 Structured Stale／Unavailable Result，讓 Controller 重新組裝 Capability Surface。

Parse and schema-validate

Runtime 檢查 Request 結構、Required Fields、Type、Enum、Format 與 Additional Properties。

Schema Validity 只證明資料形狀合法，不證明 Resource 正確，也不代表 Actor 有權操作。

Canonicalise arguments and resources

Policy 必須針對實際要執行的 Operation 做判斷。

例如：

./exports/../payments/config.json

若先對原始字串授權，File API 之後才解析真正路徑，Policy 與 Execution 可能指向不同 Resource。

較安全的順序是：

Parse
→ resolve aliases
→ canonicalise path / URL / entity / command
→ resolve resource identity
→ evaluate policy against that operation

Catalog Search 前可以先做粗粒度 Entitlement Filter，避免洩漏 Tool Metadata；但 Per-call Final Authorisation 必須在 Canonicalization 之後。

Classify effect, risk and concurrency

同一個 Tool 可能因 Arguments 不同而具有不同風險：

  • read_file 讀 README 或 Credential Directory
  • run_sql 執行 SELECT 或 DELETE
  • send_email 寄給測試帳戶或正式客戶
  • deploy 部署 Preview 或 Production

每次 Call 應重新判斷：

  • Read／Write／Destructive／External Send
  • Sensitive Data
  • Financial／Production
  • Idempotency
  • Shared-resource Conflict
  • Parallel Safety
  • Human Approval

Tool Annotation 可以成為 Policy Input，不能單獨當成安全保證。MCP 2025-11-25 規格也要求 Client 將 Tool Annotation 視為不可信，除非它來自受信任的 Server。1

Final authorisation and approval

授權至少要綁定 Actor、Tenant、Workspace、Canonical Resource、Action、Arguments Digest、Tool／Catalog Version、Policy Version 與 Current State Version。

決策不一定只有 Boolean：

allow | deny | ask | passthrough

較低 Authority 的 Hook 或 Plugin 不得覆蓋較高層的 Deny。典型優先序可能是：

Immutable / hard deny
> enterprise or tenant deny
> resource-specific deny
> mandatory ask
> session grant
> project or user allow
> default policy

實際來源可不同，但 Precedence 必須可測、可追蹤，並在衝突時 Fail Closed。

Bind and execute

真正執行前，Runtime 綁定：

  • Least-privilege Credential
  • Sandbox／Filesystem／Network Boundary
  • Timeout 與 Cancellation
  • Rate／Concurrency Limit
  • Idempotency Key
  • External Operation ID
  • Trace／Run／Tool Call ID

Credential 不應從模型 Arguments 取得，也不應因 Skill 或 Plugin 宣稱需要就自動暴露。

執行結果至少要區分：

  • success
  • validation_failed
  • permission_denied
  • approval_required
  • timeout
  • cancelled
  • partial
  • background_accepted
  • unknown_outcome
  • unavailable_tool

執行失敗不代表沒有副作用。Retry、Idempotency、Unknown Outcome 與 Compensation 留到 Part 08 詳談。

Normalise result

Raw API、CLI 或 MCP Result 不應原封不動灌回 Model Context。

Normalized Result 應包含 Terminal Status、Structured Output、Error Taxonomy、Retryability、Provenance、External Operation ID、Latency、Partial State、Redaction，以及 Artifact Reference 或 Pagination。

完整 Raw Payload 可以保存成 Artifact；模型下一輪只取得完成工作需要的有限 Observation。

Commit audit and observation

Audit Record 與 Model-visible Observation 是不同產物。

Audit 可能保存 Canonical Arguments Digest、Policy Decision ID、Approval ID、Catalog／Tool Version、Start／Finish Time、External Operation ID、Result Hash 與 Unknown State。

Observation 只回答：模型下一步需要知道什麼？

每個 Tool Request 必須得到一個 Correlated Terminal Result。Background Work 可以另外產生 Progress 與 Completion Event，但不能把後續完成偽裝成原 Request 的第二個 Result。

Tool Contract 要描述執行語意，不只描述參數

一個可治理的 Registry Entry 不只需要名稱與 Input Schema。

下面是示意格式，不是任何產品的固定 Schema：

{
 "id": "billing.invoice.send_approved_reminders",
 "version": "2.1.0",
 "owner": "billing-platform",
 "description": "Send reminders for an approved reminder batch.",
 "input_schema": {
 "type": "object",
 "properties": {
 "batch_id": {"type": "string"},
 "approval_token": {"type": "string"}
 },
 "required": ["batch_id", "approval_token"],
 "additionalProperties": false
 },
 "output_schema": {
 "type": "object",
 "properties": {
 "operation_id": {"type": "string"},
 "sent_count": {"type": "integer"},
 "failed_count": {"type": "integer"}
 },
 "required": ["operation_id", "sent_count", "failed_count"]
 },
 "effects": ["external_send", "customer_communication"],
 "risk_class": "high",
 "approval_class": "mandatory",
 "idempotency": {"required": true, "scope": "batch_id"},
 "concurrency": "exclusive_per_batch",
 "timeout_ms": 15000,
 "error_taxonomy": [
 "approval_invalid",
 "batch_stale",
 "rate_limited",
 "unknown_outcome"
 ],
 "redaction": ["approval_token"],
 "deprecated": false
}

這段說明 Registry 可能需要：

  • Stable ID、Version 與 Owner
  • Input／Output Contract
  • Side Effect 與 Risk
  • Approval 與 Idempotency
  • Concurrency
  • Timeout
  • Error Taxonomy
  • Sensitive-field Redaction
  • Deprecation

它不能證明 15 秒是合適的 Timeout、Handler 真正 Idempotent、Business Authorisation 正確，或模型能穩定選對 Tool。

Contract 是治理入口，不是品質證書。

新 Tool 應採 Fail-closed Default。在完成審查前，不預設為 Read-only、Concurrent-safe、Auto-approved 或 Idempotent。

Agent-Computer Interface：工具也是一種使用者介面

Anthropic 把 Agent-Computer Interface（ACI）和 Human-Computer Interface 並列，建議工具文件與介面設計投入同等認真程度。2

模型並不會因為 Function Calling 使用 JSON，就自動理解模糊介面。

一個好的 ACI 通常具備：

  • 名稱與用途邊界清楚
  • 參數名稱可直接理解
  • Enum 與 resource ID 優先於含糊自由文字
  • Read 與 destructive action 分開
  • Output 結構穩定
  • 錯誤訊息指出可修正原因
  • 大型結果支援 pagination、field selection 或 artifact reference
  • 相鄰工具的差異可以被模型辨識

不要把整個業務塞進 manage()

以下介面看起來彈性很高：

{
 "name": "manage_invoice",
 "arguments": {
 "action": "string",
 "payload": "object"
 }
}

但模型必須猜 action 值、payload 形狀、哪些操作可逆，以及哪種結果代表成功。

更好的設計可能拆成：

search_overdue_invoices
preview_reminder_drafts
approve_reminder_batch
send_approved_reminders

這種拆法不是為了增加 Tool 數量，而是讓操作語意、權限與副作用邊界可被強制。

Poka-yoke：讓錯誤難以發生

比起在 Prompt 裡重複「請小心」，介面可以直接排除部分錯誤：

  • 用受控 invoice_id 取代任意 SQL
  • 將 Preview 與 Commit 拆成不同 Tool
  • 寄信工具只接受已批准的 draft_batch_id
  • 高風險操作要求 approval_token
  • 不允許同一欄位同時接受日期、timestamp 與自然語言

ACI 的品質最後要用真實 Model Behavior 檢查，包括工具選擇錯誤率、無效參數率、修正次數、任務耗時與相鄰工具誤用率。Schema 看起來整齊，只能證明 Schema 看起來整齊。

能力不是越多越好：Capability Surface 也有預算

每個 active Tool、Skill、Plugin instruction 與 MCP server 都會消耗 Context 與選擇注意力。

Anthropic 在 Context Engineering 的實務建議中，特別指出工具集合過度膨脹與功能重疊會增加錯誤選擇；工具應保持自包含、用途清楚，並以緊湊、高訊號的方式回傳資料。3

Capability Surface Budget 包含：

  • Tool name 與 description
  • Input／Output Schema
  • examples
  • Skill metadata 與 instructions
  • server-level guidance
  • Hook behavior
  • Policy guidance
  • error documentation
  • Tool Result payload

因此啟用策略更適合長成：

Always-on core capabilities
+ task-retrieved tools
+ explicitly activated skills
+ temporary subagent capabilities

而不是每一輪都暴露整間公司的所有能力。

Capability Surface Budget and Dynamic Discovery

Figure 5-3｜先保留最小 always-on surface，再依 Task Intent 從 Catalog 取回少量候選能力；被搜尋到仍不等於獲得執行授權。

Dynamic Tool Discovery：先限制可發現範圍，再搜尋

當 Tool 數量增加，把所有完整 Schema 放進 Context 會提高成本、混淆與 Cache Churn。

一個更完整的 Discovery Flow 是：

Task intent + actor scope
→ filter discoverable catalog metadata
→ search candidate tools
→ return a small candidate set
→ load complete schemas from one catalog snapshot
→ model proposes a call
→ canonicalise operation
→ per-call final authorisation
→ execute

Catalog 至少應保存：

  • Stable ID、Name、Version、Owner
  • Description 與 Example Task
  • Input／Output Schema
  • Domain、Tags 與 Namespace
  • Side Effect、Risk 與 Approval Class
  • Latency／Cost Class
  • Tenant／Region／Entitlement Availability
  • Deprecation State
  • Compatibility Constraints

Discovery relevance 不是 authorisation

Semantic Search 只能判斷 Task Relevance。

若 Catalog Metadata 本身敏感，Search 前就要套用 Actor、Tenant、Region 與 Entitlement Filter；完整執行權仍在 Canonical Operation 形成後重新判斷。

Embedding Model 不應成為 Permission Engine。

Catalog Snapshot 必須一致

一次 Model Turn 應看到同一版本的：

  • Model-visible Schemas
  • Execution Handlers
  • Policy Metadata
  • Prompt Guidance
  • Discovery Index
  • Audit Metadata
  • Catalog Version

Plugin Enablement、MCP Disconnect、Tool Upgrade 或 Policy Change 後，需要失效 Schema Cache、Prompt Tool Section、Discovery Index、Authorisation Cache、Subagent Catalog 與 Replay／Eval Manifest。

Server 失聯或 Tool 被撤回時，Runtime 應增加 Catalog Version，對 Stale Request 回傳 unavailable_tool。不能繼續使用已移除 Handler，也不能悄悄改用同名替代品。

Skill、Plugin 與 Hook 各自承擔什麼？

這三種機制常被放在同一個 Extension 目錄裡，但它們處理的問題不同。

Skill：封裝可重用的工作方法

Skill 比較接近可按需載入的 SOP。它可以包含：

  • 何時啟用
  • 任務判斷程序
  • 建議 Tool 順序
  • failure handling
  • templates
  • scripts
  • references
  • acceptance criteria
  • evals

Agent Skills 公開規格要求 Skill Directory 至少包含 SKILL.md，並允許 scripts/、references/、assets/ 與其他檔案。SKILL.md 需要 name 與 description 等 Frontmatter；allowed-tools 目前標示為 Experimental。4

invoice-reminder/
├── SKILL.md
├── scripts/ # optional
├── references/ # optional
├── assets/ # optional
└── ...

本文另外建議在工程 Package 中加入 evals/ 或額外 Metadata，但這些不是 Agent Skills 規格要求的目錄。

Skill 不應把專案 Secret、私有 URL 或不透明 Destructive Behaviour 烘焙進去。它可以建議使用哪個 Tool，不能因為宣告 allowed-tools 就擴大 Runtime Permission。

Plugin：依宿主契約安裝的一包能力

Plugin 沒有跨所有 Agent Host 的唯一通用格式。本文將它定義為：依特定 Host 的 Discovery、Installation、Registration、Permission 與 Lifecycle Contract 安裝的能力包。

Plugin 可能包含 Tools、Skills、Commands、Hooks、UI、設定或 MCP Client／Server 配置。

它需要完整生命週期：

Discover
→ Validate
→ Install
→ Initialize
→ Register
→ Enable
→ Execute
→ Upgrade / Disable
→ Unload

Plugin Manifest 至少要描述：

  • 唯一 ID 與版本
  • Host compatibility
  • entry point
  • 所需權限與資源
  • 包含哪些能力
  • config schema
  • migration／rollback
  • provenance、publisher、digest 或 signature

安裝 Plugin、Skill 或本機 MCP server，可能同時引入文字 instructions 與可執行程式。這比較接近安裝 package，不是單純閱讀文件。完整供應鏈安全會留到 Part 09，但 Part 05 先保留一條操作原則：Remote description 與 extension instructions 都是不可信輸入，不能改寫宿主的 deny policy。

Hook：在穩定生命週期點插入行為

Hook 的目的，是讓 validation、logging、context injection、cleanup 與 policy extension 掛在明確事件上，而不是把核心 Agent Loop 改成一團互相呼叫的條件分支。

常見事件包括：

SessionStart
UserPromptSubmit
PreModelCall / PostModelCall
PreToolUse / PostToolUse / ToolFailure
PreCompact / PostCompact
TaskCreated / TaskCompleted
Stop / SessionEnd
ConfigChanged
WorkspaceChanged

真正重要的不是事件名稱，而是 Event Contract：

  • 何時觸發
  • Input Schema
  • 是否能修改 input／output
  • 是否能 block、ask、cancel 或 retry
  • 多個 Hook 的優先順序
  • timeout
  • failure policy
  • authority ceiling
  • trace fields

Listener、Hook、Middleware、Interceptor 不只差在名字

機制典型語意通常能否改變主流程？
Listener事件後接收通知通常不能
Hook在生命週期點執行擴充依 Contract
Middleware包住整段 pipeline可以
Interceptor攔截特定 operation可以
Policy Gate依 Authority 做 allow／deny／ask必須可以

安全規則若只依賴一個可被 Plugin 移除的 Listener，系統並沒有可強制的 Gate。

Hook 也要防止 Reentrancy。例如 Stop Hook 阻擋結束後觸發新 Turn，新 Turn 又再次進入 Stop Hook，就可能形成永不停止的 Loop。多個 Hook 還需要明確 Ordering 與 Conflict Resolution：Deny／Cancel 通常高優先，Additional Context 可在 Budget 內累加，Updated Input 則不能互相靜默覆寫。Critical Security Hook 應 Fail Closed；Telemetry Listener 可以依風險 Fail Open。Extension 的 Authority Ceiling 不得高於 Enterprise Deny、Tenant Isolation、Sandbox Boundary 或 Mandatory Approval。

選 Integration Surface：先問需要保留多少互動語意

同一個能力可以透過 CLI、SDK、MCP，甚至完整 App Server 暴露。差異不只是開發偏好，而是能保留多少 lifecycle semantics。

Full Harness Protocol、MCP、SDK 與 Exec 的選擇矩陣

Figure 5-4｜Integration Surface 應依 Session、Streaming、Approval、Artifact、Diff、Portability 與部署邊界選擇。

Full Harness Protocol／App Server

適合需要：

  • durable Thread lifecycle
  • bidirectional streaming
  • approval request／response
  • incremental progress
  • diffs 與 artifacts
  • pause、resume、fork、archive
  • rich client UI

OpenAI 在設計 Codex App Server 時，曾嘗試用 MCP 暴露 Codex，但發現 VS Code 所需的 rich session semantics、diff updates 與雙向 approval 很難完整映射，最後採用更貼近完整 Agent Loop 的雙向 JSON-RPC Protocol。OpenAI 也明確區分：把 Codex 作為 MCP Server 適合「把它當成 callable tool」；需要完整 Harness 功能時則使用 App Server。5

MCP

適合：

  • Host 已有 MCP Client
  • 能力希望跨多個 AI application 重用
  • Tools／Resources／Prompts 足以表達需求
  • 不需要完整 provider-specific session lifecycle

MCP 2025-11-25 使用 Host／Client／Server 架構與 JSON-RPC 訊息，支援 Capability Negotiation、Tools、Resources、Prompts、Progress、Cancellation 與 Logging。6

MCP 也定義適用於 Remote Deployment 的 Protocol-level Authorization 機制，例如 OAuth Protected Resource Metadata 與 Authorization Server Discovery。這不等於產品的 Business Authorisation 已完成。7

Harness 仍要決定哪個 User／Tenant 可以看見 Server 或 Tool、Actor 是否能對特定 Resource 執行 Action、哪些 Operation 要 Human Approval、Credential 如何綁定，以及 Side Effect 如何驗證。

SDK／Library

適合：

  • 同語言 Application 內嵌
  • 需要直接呼叫 Runtime API
  • 不想維護獨立 Client Protocol

代價是 Process、Language、Upgrade 與 Isolation 更緊密耦合。

Exec／CLI

適合：

  • one-shot automation
  • CI／batch
  • 清楚 exit code
  • structured stdout
  • 現成 authentication 與 operator workflow

CLI 不必因 MCP 出現就退休。對模型熟悉、輸出可透過 jq／grep 壓縮、命令數量有限的工作，成熟 CLI 可能是更低成本、更可測的能力入口。

它不適合長期雙向互動、細緻 approval UI 與 durable session control。

MCP 與 A2A：一個接能力，一個接 Agent

MCP 與 A2A 都談互通，但它們面對的對象不同。

MCP and A2A Responsibility Boundary

Figure 5-5｜Agent 可透過 MCP 使用 Tools 與 Resources，再透過 A2A 和另一個獨立 Agent 管理 Task、Message 與 Artifact。兩者可組合，不互相取代。

MCP 的核心對象是 Tools 與 Resources

MCP 讓 AI Host 透過 Client 連接 Server，發現並呼叫：

  • Tools
  • Resources
  • Prompts

它適合結構化、邊界明確的能力，例如資料庫查詢、API 呼叫、檔案資源或計算服務。

A2A 的核心對象是另一個 Agent

A2A 1.0.0 面向彼此獨立、甚至內部不透明的 Agent System，處理：

  • Agent discovery／Agent Card
  • Message
  • Task 與 Task State
  • Artifact
  • streaming update
  • push notification
  • authentication、authorization 與 versioning

對方通常是一個有自己 Runtime、Tools、State 與推理流程的獨立系統，而不是單一 Function。

A2A 官方文件也直接把兩者區分為：MCP 處理 Agent 與 Tools／Resources 的互動；A2A 處理 Agent 彼此的協作。單一 Agent 可以同時用 A2A 委派給另一個 Agent，再由那個 Agent 使用 MCP 呼叫自己的 Tools。8

Agent A
├── MCP → Billing Tools / Customer Data
└── A2A → Compliance Agent B
 └── MCP → Policy Database / Audit Tools

Agent Discovery 不等於信任。Agent Card 需要驗證來源、版本、簽章或 Endpoint；Delegation 也要傳遞 Actor、Tenant、Scope 與 Provenance。Remote Agent 說 completed，本地 Harness 仍要根據自己的 Contract、Policy 與 Evidence 通過 Local Acceptance Gate。

Plugin 與 MCP 不互斥

可以用一句話區分：

Plugin = 掛進某個 Host 的能力包
MCP = Host 與外部能力溝通的標準協議

一個 Plugin 可以：

  • 安裝 MCP Client Adapter
  • 管理 MCP Server 的設定與生命週期
  • 同時提供 UI、commands、skills 與 hooks

一個 MCP Server 也可以被 Plugin 安裝。

若能力只服務單一宿主，且需要深度 UI 或 lifecycle 整合，Plugin 往往比較自然；若能力要跨 IDE、Agent 與 Runtime 重用，則可保留核心 Library，外加一層薄 MCP Adapter。

不要為了「支援 MCP」重寫整份業務邏輯。Protocol Adapter 應該薄，核心規則仍留在可獨立測試的 service／library。

Programmatic Tool Calling：把機械化資料處理移出主 Context

傳統 Tool Loop 每呼叫一次工具，就可能把 Raw Result 放進 Transcript，再觸發下一輪 Model Inference。

對大量查詢、過濾、聚合與轉換，這會同時增加 latency 與 Context Pollution。

Programmatic Tool Calling 的做法是，讓模型先產生一段受控程式，在 Sandbox 內連續呼叫 allowlisted Tools，只把必要摘要、Evidence 與錯誤回傳主 Context。

適合的工作包括：

  • 多筆 API 查詢後聚合
  • CSV／JSON／Log 分析
  • 大量文件篩選
  • 有明確 dependency 的工具鏈
  • Raw Data 很大，但最後只需少量統計與引用

必要邊界包括：

  • generated code 在 Sandbox 執行
  • Tool allowlist
  • CPU、Memory、Network、Wall-clock 與 Call Budget
  • Credential 不直接暴露給生成程式
  • Raw Result 預設留在隔離環境
  • Side-effect Tool 需要更嚴格控制
  • Code、Tool Calls 與輸出都進 Trace

它不是讓模型拿到更大的任意執行權，而是把可程式化的機械工作移出有限推理窗口。

不必從 MCP 開始：先讓核心能力穩定

一個獨立 Script 不會因為套上 Protocol 就突然變可靠。

可以把以下順序視為實用 Heuristic，而不是所有產品必走的成熟度階梯：

Library
→ Stable CLI / API
→ Machine-readable Output
→ Agent-ready SOP and Safety Rules
→ Structured Service Adapter
→ MCP Server or Host-specific Plugin
→ Optional Third-party Extension Surface

先把核心能力做到：

  • 介面穩定
  • 錯誤碼明確
  • 可 timeout／cancel
  • Read 與 Write 分離
  • Idempotency 定義清楚
  • 有 Run ID 與 Trace
  • Authentication 與 Human Action State 可觀察

有些 Remote Service 天生從 API 起步，不需要 CLI；有些 Internal Tool 永遠不需要 MCP。完成這些基礎後，再選擇要不要包成 MCP、Plugin 或 SDK。

否則得到的只是「可以被更多 Agent 遠端呼叫的不穩定腳本」。可攜性提高了，事故半徑也跟著旅行。

Tool Quality 要分層評估

Tool「能被呼叫」只證明 Transport 與 Parser 走通。

Part 10 會展開完整 Evaluation；Part 05 先保留五個層級：

層級主要問題
DefinitionName、Description、Schema、Examples 與 Error 是否可理解？
Selection模型是否選對 Tool？是否產生不必要呼叫？
ArgumentsResource、Scope、Format 與 Permission Input 是否正確？
ExecutionLatency、Timeout、Rate Limit、Idempotency 與 Side Effect 是否可靠？
OutcomeTask 是否完成？Evidence 是否足夠？成本與 Trajectory 是否合理？

模型自評「這個 Tool 很好用」可以是候選診斷，不能取代 Ground Truth、Metrics 與 Adversarial Cases。

用發票催款任務走一次

回到開頭的任務：找出逾期發票、產生催款草稿、經批准後寄出。

Existing CLI／Library

財務系統若已有穩定的 read-only CLI，可以先保留：

billing invoices overdue --account <id> --format json

它負責查詢，不負責寄信，也不把 tenant scope 交給模型自由輸入。

Skill

invoice-reminder-skill 描述：

  • 何時適用
  • 逾期判定規則
  • 建議查詢順序
  • 哪些帳戶不得自動處理
  • 草稿應包含哪些欄位
  • 必須等待 Approval 的步驟
  • 完成證據

Tools

Harness 提供邊界清楚的 Tools：

search_overdue_invoices
preview_reminder_drafts
request_batch_approval
send_approved_reminders

其中 send_approved_reminders 只接受已批准的 Batch ID。

Hook／Policy Gate

PreToolUse(send_approved_reminders) 檢查：

  • Approval Token 是否有效
  • Batch 是否仍是相同版本
  • 收件者是否在允許範圍
  • 是否超過每日寄送限制

Audit Listener 則記錄結果，但不持有 allow／deny Authority。

Plugin 或 MCP

若 Gmail 整合只服務這個宿主，且需要宿主 UI、OAuth 設定與 approval screen，可以包成 Plugin。

若同一寄信能力要提供給多個 Agent Runtime，則保留 Mail Service 核心，另加 MCP Server。

A2A

只有當 Compliance Review 由另一個具有獨立狀態、任務生命週期與協作能力的 Agent 承擔時，才需要 A2A。若它只是一次結構化規則檢查，普通 Tool 或 Service API 可能更合適。

這個案例沒有唯一標準答案，但每一層的責任應該能被說清楚。

一個可用的能力選擇方式

拿到新的 Integration Requirement 時，可以依序問：

  1. 這是具體 Operation、可重用方法、Host Extension，還是 Remote Agent？
  2. 是否已有穩定 Library、Service、API 或 CLI？
  3. Tool 的 Stable ID、Version、Owner、Input／Output 與 Error Taxonomy 是否完整？
  4. Model Visibility、Discovery、Per-call Authorisation 與 Execution 是否分離？
  5. Arguments 是否先 Canonicalise，再套用 Final Policy？
  6. Risk、Concurrency、Idempotency 與 Approval 是否按每次 Call 判斷？
  7. Active Capability Surface 是否根據 Task 維持在可評估範圍？
  8. Catalog Snapshot、Handler、Policy Metadata、Index 與 Cache 是否同版？
  9. Skill、Plugin 與 Hook 的來源、權限、Authority Ceiling 與撤銷路徑是否清楚？
  10. Integration 是否需要 Rich Session Semantics，還是 Callable Capability 已足夠？
  11. 對方是 Tool Provider，還是有自己 Task Lifecycle 的 Agent？
  12. Definition、Selection、Arguments、Execution 與 Outcome 如何被測試？

若第 2～6 題還答不清楚，先不要急著包成 MCP Server。Protocol 不會替核心能力補出穩定 Contract。

理論轉實作：Part 05 檢查表

  • Tool、Skill、Plugin、Hook、Policy Gate、MCP、A2A 與 Full Harness Protocol 的責任沒有混用。
  • Tool Registry 保存 Stable ID、Version、Owner、Input／Output、Effect、Risk、Idempotency、Concurrency、Error 與 Redaction。
  • Discoverability、Model Visibility、Per-call Authorisation 與 Execution 是不同狀態。
  • Tool Request 先經 Parse、Canonicalization 與 Resource Resolution，再做 Final Authorisation。
  • Risk、Concurrency 與 Approval 依 Canonical Arguments 和 Resource 重新判斷。
  • Tool Result 有 Terminal Status、Provenance、Operation ID、Error Taxonomy、大小限制與 Artifact Reference。
  • Capability Surface 依 Task 選擇，並量測 Wrong-tool、Discovery Miss、Argument Validity 與 Payload Cost。
  • Dynamic Catalog 在 Search 前套用可發現範圍，在 Call 前重新授權，並使用一致的 Catalog Snapshot。
  • Skill 的官方格式與團隊建議目錄分開，Skill 不提升 Runtime Permission。
  • Plugin 有 Provenance、Compatibility、Requested Permission、Migration、Rollback、Disable 與 Revoke Path。
  • Hook 定義 Trigger、Authority、Order、Conflict、Timeout、Failure Policy 與 Reentrancy Guard。
  • Extension 無法繞過 Enterprise Deny、Tenant Boundary、Sandbox 或 Mandatory Approval。
  • Full Protocol、MCP、SDK 與 Exec 的選擇保留實際需要的 Lifecycle Semantics。
  • MCP Protocol-level Authorization 沒有被誤當成產品 Business Authorisation。
  • A2A Remote Completion 仍經過本地 Contract、Policy 與 Local Acceptance。
  • Adapter 保持薄型，核心 Business Logic、Authorisation 與 Idempotency 可以獨立測試。

References

Footnotes

  1. Model Context Protocol, Tools specification 2025-11-25, accessed 8 July 2026. ↩

  2. Anthropic, Building effective agents, 19 December 2024. ↩

  3. Anthropic, Effective context engineering for AI agents, 29 September 2025. ↩

  4. Agent Skills, Specification, accessed 8 July 2026. ↩

  5. OpenAI, Unlocking the Codex harness: how we built the App Server, 4 February 2026. ↩

  6. Model Context Protocol, Specification 2025-11-25, accessed 8 July 2026. ↩

  7. Model Context Protocol, Authorization specification 2025-11-25, accessed 8 July 2026. ↩

  8. A2A Protocol, A2A and MCP: Detailed Comparison, accessed 8 July 2026. ↩