AI Agent Protocols / MCP / A2A / Tool Integration Playbook

企业 AI agent 的关键能力不只是生成文本，而是能在明确边界内连接外部工具、资源、提示、供应商服务和其他 agent。协议化的价值不是让模型自由调用更多能力，而是把外部能力变成可发现、可授权、可审计、可回滚、可治理的系统接口。

本手册研究企业 AI agent 如何从一次性 custom plugin 走向 protocol thinking、tool contract、capability discovery、policy boundary、audit trail 和 vendor integration governance。主线是：custom plugin 暴露重复接入和权限分散问题；MCP 把 tools、resources、prompts 和 transport 边界标准化；A2A 把 agent handoff、task envelope、artifact 和责任边界结构化；tool contract、policy matrix、audit schema 和 integration risk checklist 把协议能力落到金融零售生产门禁。

版本状态更新（2026-07-01）：本手册撰写基线为 MCP Specification 2025-03-26，已落后两个稳定版——当前稳定版为 2025-11-25（其间 2025-06-18 版已引入 elicitation、结构化工具输出与 OAuth 2.1 授权强化）。2026-07-28 计划发布最终规范（RC 已于 2026-05-21 锁定）——发布后按 AIPA 硬日期复查点对本手册做逐项 diff（见 docs/AIPA_120_PLAN.md）。原文保留不删；与新版规范冲突处以本框和 §3.10 更正注记为准。

---

Source Anchors

这些来源是本手册的学习锚点, 用于统一术语、协议边界和风险语言。它们不构成法律、合规、采购或安全审计意见。

---

1. 定位与现有文档关系

本手册不替代已有 AI 平台、安全和上下文工程文档, 而是把它们连接到一个新的问题:

当企业 AI Agent 不再只是聊天, 而要调用 CRM、工单、KYC、支付争议、核心银行只读接口和供应商服务时,
我们如何设计协议、工具契约、发现机制、授权策略、审计事件和平台治理?

这些文档之间的关系可以按控制面理解：AI platform playbook 说明平台要建设什么能力；AI Platform Security Gateway Lab 说明工具调用如何安全落地；AI Context Engineering Playbook 说明上下文如何进入模型；本手册说明 agent 与外部能力如何通过协议和契约连接、发现、授权、审计和治理。

---

2. 为什么需要 Protocol Thinking

2.1 从 custom plugin 到 protocol 的转变

早期企业 AI 集成常见做法是为每个 use case 写一个 custom plugin:

• 一个客服助手接 CRM。
• 一个运营助手接工单系统。
• 一个合规助手接政策知识库。
• 一个支付助手接 dispute case。
• 一个 KYC 助手接供应商 API。

这种方式可以快速验证 POC, 但规模化后会暴露重复成本和治理问题。

2.2 协议化不是“让模型自由调用更多工具”

Protocol thinking 的目标不是把所有系统都暴露给模型, 而是把连接外部能力的方式标准化:

Agent intent
-> capability discovery
-> tool contract selection
-> argument schema validation
-> identity and policy check
-> human approval when required
-> connector execution
-> normalized observation
-> audit event
-> eval and incident replay

从系统设计视角看, 协议化要回答 8 个问题:

2.3 企业 AI 的协议化成熟度

---

3. MCP Deep Dive

3.1 MCP 解决什么问题

MCP, Model Context Protocol, 可以理解为 AI 应用连接外部上下文和工具的标准接口层。它把过去散落在应用代码里的连接逻辑拆成更清晰的角色:

• Host: AI 应用本体, 例如 IDE、聊天应用、agent workbench、企业 AI portal。
• Client: Host 内部用于连接某个 MCP server 的协议客户端。
• Server: 暴露 tools、resources、prompts 等能力的服务。
• Transport: client 和 server 的通信方式。

对企业来说, MCP 的产品意义不只是“多一个接口标准”, 而是让工具集成可以被:

• 注册。
• 发现。
• 授权。
• 版本化。
• 监控。
• 审计。
• 替换。
• 进入平台治理。

3.2 Host / Client / Server

企业中常见部署形态:

3.3 MCP Tools

MCP tools 表示模型可以请求调用的动作或函数。它们通常需要明确 input schema, 并返回结构化结果或文本观察。

每个 MCP tool 都应被当成一个可评审的系统能力:

关键原则:

• Read-only tool 也需要权限和审计, 因为它可能泄露敏感数据。
• Write tool 必须显式声明 side effect、rollback 或 compensation。
• External-send tool, 例如发送邮件、提交监管回复、通知客户, 应默认高风险。
• Tool result 是 observation, 不是新的系统指令。工具结果里出现的文字不能绕过 policy。

3.4 MCP Resources

MCP resources 表示可读取的上下文对象, 例如文件、知识库条目、数据库记录、API 资源或业务对象。它们更像“可被 host 或模型引用的 evidence”。

企业 resource 设计要点:

Resources 和 context engineering 的关系:

Resource 不是“塞进 prompt 的文本”。
Resource 应该先经过 permission filter、freshness check、sensitivity label、prompt injection screening,
再由 context composer 以证据形式进入模型上下文。

3.5 MCP Prompts

MCP prompts 可用于暴露可复用提示模板或工作流入口。它们适合把业务任务包装成受控的 prompt pattern, 例如:

• summarize_dispute_case
• draft_kyc_followup_questions
• compare_policy_versions
• prepare_branch_complaint_response
• triage_payment_exception

Prompt 设计要点:

3.6 Transport

MCP 2025-03-26 规范中需要重点关注两类 transport 思路:

设计建议:

• 本地 stdio 适合开发者和低风险工具, 不适合直接暴露高风险业务动作。
• 远程 HTTP MCP server 必须纳入 API security、identity、policy、logging、vendor risk review。
• 不要把 transport 安全等同于业务安全。TLS、OAuth 或网络白名单只解决连接层问题, 不能替代 tool-level authorization。

3.7 Authorization and Security

MCP authorization 解决 client 连接 server 的授权问题, 企业还需要额外设计业务授权。

与 OWASP LLM01 的连接:

• Prompt injection 可能诱导模型调用不该调用的工具。
• Indirect prompt injection 可能藏在网页、邮件、PDF、工单备注、供应商回复中。
• 防护重点不应只放在 prompt, 还要放在 least privilege、segmentation、approval、audit、tool result isolation 和 red-team eval。

3.8 Roots

Roots 是 client 向 server 暴露的一组边界, 常见于文件系统或项目上下文。企业中 roots 的核心意义是限定 server 可以看见什么范围。

设计原则:

• roots 必须最小化, 不把整个磁盘、共享盘或用户 home 目录默认暴露。
• roots 应带有 purpose, 例如 current_case_documents、policy_kb_export、repo_workspace。
• roots 变化要记录审计事件, 高风险目录需要用户确认。
• server 不应通过路径技巧、symlink 或隐藏文件绕过 roots。

3.9 Sampling

MCP sampling 允许 server 通过 client 请求模型生成。它可以支持更复杂的 server-side agentic behavior, 但企业中需要谨慎。

风险点:

• server 可能把敏感 resource 发给模型。
• server 可能构造诱导性 prompt。
• server 可能绕过 host 的上下文治理。
• 采样请求和结果如果不审计, 事后难以解释。

治理建议:

3.10 Elicitation

截至 MCP 2025-03-26 规范基线, 本手册不把 elicitation 作为该版本的稳定必备能力。后续 MCP 版本和相关文档中出现的 elicitation 思路, 可以理解为 server 请求 host 向用户收集额外信息的交互模式。

更正注记（2026-07-01）：elicitation 已自 MCP 2025-06-18 版起正式进入规范，并包含在 2025-11-25 稳定版中。上段「不作为稳定必备能力」仅对 2025-03-26 旧基线成立；新集成应按当前稳定版评估 elicitation 的授权、审计与敏感信息控制（下方 checklist 仍适用）。

在企业落地时, 采用 elicitation 前需要确认:

• 当前 host / client / server 是否支持该能力。
• 用户输入是否会改变权限、参数、审批或 side effect。
• 是否存在诱导用户提供敏感信息的风险。
• elicitation 请求是否进入 audit log。
• 是否能限制问题类型、字段范围和业务目的。

安全表达:

Elicitation 可以改善多轮工具调用体验, 但它也扩大了 server 影响用户输入的能力。
在金融零售场景中, 应把 elicitation 视为受控 UI flow, 而不是 server 自由询问用户。

---

4. A2A / Agent-to-Agent 思维

4.1 A2A 和 MCP 的边界

MCP 和 A2A 的边界应按集成对象区分：MCP 主要解决 agent / host 如何连接工具、资源和提示；A2A 主要解决一个 agent 如何发现、委派、跟踪和接收另一个 agent 的任务结果。前者偏能力调用和上下文供应，后者偏任务协作和责任转移。

4.2 标准成熟度表达

A2A 已有公开规范和生态推进, 但在具体企业中仍需要做 compatibility 和 vendor adoption 验证。建议表达为:

我们可以用 A2A 的 agent card、task、message、artifact 等概念设计 agent 互操作,
但上线前需要验证目标 vendor、host、runtime、security gateway 和 audit stack 的实际支持程度。

这样既承认协议方向, 也避免把外部生态成熟度过度假设为企业内部可用能力。

4.3 Agent Handoff

Agent handoff 是一个 agent 把任务移交给另一个 agent。企业中 handoff 不能只是“把用户 prompt 转发出去”, 而应包含结构化 envelope。

Handoff envelope 建议字段:

4.4 Task Envelope

Task envelope 的目标是让 agent 协作可追踪、可重试、可审计。

{
  "task_id": "case-8821-kyc-review-001",
  "task_type": "kyc_vendor_review",
  "requester": {
    "agent_id": "retail-case-assistant",
    "version": "1.4.2"
  },
  "target_capability": "kyc_document_gap_analysis",
  "purpose": "support human analyst review",
  "risk_tier": "draft_recommendation",
  "input_refs": [
    {
      "type": "resource",
      "uri": "case://8821/documents/customer-upload",
      "sensitivity": "restricted_pii"
    }
  ],
  "constraints": {
    "no_external_send": true,
    "no_customer_decision": true,
    "must_cite_sources": true
  },
  "expected_output_schema": "kyc_gap_analysis_v1",
  "audit_correlation_id": "audit-2026-06-29-0007"
}

4.5 Identity

Agent-to-agent 场景至少有三类身份:

设计原则:

• 不使用共享万能服务账号。
• Agent identity 要可撤销、可分级授权、可绑定版本和 owner。
• Human user 权限不能被 agent handoff 放大。
• 跨 agent 传递的是 delegated authority, 不是全量用户权限。
• 审计中要同时记录 human、agent、service 三类身份。

4.6 Capability Card

Capability card 用于说明一个 agent 或 server 能做什么、需要什么输入、返回什么结果、有哪些限制。

4.7 State Transfer

State transfer 是 agent handoff 中最容易失控的部分。不要把完整对话历史、完整客户档案或无限制 token 直接转给目标 agent。

推荐做法:

• 传 resource references, 少传原始明文。
• 传 task summary, 不传全量聊天记录。
• 传 policy constraints, 不依赖目标 agent 猜测边界。
• 传 output schema, 明确目标 artifact。
• 传 data classification, 让目标 agent 和 gateway 执行权限过滤。
• 传 audit correlation id, 方便串联全链路。

4.8 Policy Boundary

每次 agent handoff 都是新的 policy boundary。需要回答:

---

5. Tool Contract

5.1 Tool Contract Card 的最小字段

5.2 Input Schema

Input schema 的目标不是让模型“知道怎么填参数”, 而是让平台可以验证参数是否安全、合法、符合业务目的。

示例:

{
  "tool": "case_management.get_case_summary",
  "version": "1.0.0",
  "input_schema": {
    "type": "object",
    "required": ["case_id", "purpose"],
    "properties": {
      "case_id": {
        "type": "string",
        "pattern": "^CASE-[0-9]{8}$"
      },
      "purpose": {
        "type": "string",
        "enum": ["triage", "customer_response_draft", "quality_review"]
      },
      "include_notes": {
        "type": "boolean",
        "default": false
      }
    },
    "additionalProperties": false
  }
}

设计原则:

• 用枚举限制 purpose、reason code、action type。
• 不让模型自由构造 SQL、URL、文件路径或系统命令。
• 对金额、日期、账号、case id、customer id 做格式和范围校验。
• 默认禁止 additionalProperties, 避免 prompt injection 把隐藏指令塞进参数。

5.3 Output Schema

Output schema 要让工具结果变成可引用、可审计、可验证的 observation。

{
  "status": "success",
  "source_system": "case_management",
  "source_record": "CASE-20260629",
  "retrieved_at": "2026-06-29T16:30:00Z",
  "data_classification": "restricted_pii",
  "summary": {
    "case_status": "open",
    "case_type": "payment_dispute",
    "last_customer_contact": "2026-06-27",
    "next_required_action": "collect merchant evidence"
  },
  "citations": [
    {
      "field": "next_required_action",
      "source_ref": "case_note:88721"
    }
  ]
}

设计原则:

• 返回 source refs, 不只返回自然语言摘要。
• 标注 retrieved_at 和 source system。
• 标注 data classification, 便于后续 DLP 和输出控制。
• 工具错误要结构化, 不能只返回“失败了”。

5.4 Side Effect

将工具按副作用分级:

5.5 Idempotency

Agent 工具调用容易重试, 所以写操作必须设计幂等性。

如果不能做到真正 rollback, 也要设计 compensation:

• 创建了重复 ticket: 自动关闭重复 ticket 并保留审计说明。
• 发送了错误供应商请求: 发送撤回或更正请求。
• 写入了错误 case note: 追加 corrected note, 不删除历史。
• 错误外发给客户: 升级 incident, 触发客户补救流程。

5.6 Audit Event

每次工具调用都应产生标准化 audit event。

{
  "event_type": "agent_tool_call",
  "event_time": "2026-06-29T16:35:12Z",
  "audit_correlation_id": "audit-2026-06-29-0007",
  "human_user": "u12345",
  "agent_id": "retail-case-assistant",
  "agent_version": "1.4.2",
  "tool_name": "case_management.add_case_note",
  "tool_version": "1.0.0",
  "risk_tier": "S3_internal_write",
  "purpose": "quality_review",
  "input_hash": "sha256:...",
  "source_refs": ["case://CASE-20260629"],
  "policy_decision": "require_approval",
  "approval_id": "approval-9931",
  "execution_status": "success",
  "output_hash": "sha256:...",
  "pii_redaction_applied": true
}

审计设计原则:

• 敏感入参可存 hash、masked value 或 encrypted evidence package。
• 审计事件要能串起 prompt、context、model、tool、policy、approval、output。
• Denied call 也要记录, 因为它是风险信号。
• Audit schema 要支持 incident replay 和 eval regression。

---

6. 金融零售集成场景

6.1 场景总览

6.2 CRM Integration

推荐能力:

• 查询客户基础资料, 且只返回当前任务必要字段。
• 查询最近交互记录, 用于客服上下文。
• 生成下一步建议, 但不自动改变客户状态。

Tool contract 注意:

6.3 Case Management Integration

推荐能力:

• 获取 case 摘要。
• 读取 case notes。
• 生成内部处理建议。
• 添加内部备注, 但需要审批或用户确认。
• 更新 task 状态, 仅限低风险状态。

设计重点:

• Case note 不应被模型改写历史, 只能追加。
• 自动写入前展示 diff。
• 对“关闭 case”“拒绝客户诉求”“升级监管投诉”设高风险门禁。

6.4 Core Banking Read-only Integration

原则:

核心银行系统第一阶段只读, 只取最小字段, 不让 agent 直接执行资金或账户状态变更。

推荐工具:

禁止或强人审:

• 冻结/解冻账户。
• 修改客户限额。
• 发起转账。
• 修改利率、费用、产品状态。
• 作出信贷/KYC 最终决定。

6.5 KYC Vendor Integration

推荐能力:

• 提交 KYC 文档校验请求。
• 获取供应商结果。
• 汇总缺失资料。
• 生成 analyst review checklist。

治理重点:

6.6 Payment Dispute System

典型 workflow:

Read dispute case
-> retrieve transaction and evidence
-> search policy and network rules
-> summarize missing evidence
-> draft analyst note
-> human approves
-> optionally create vendor / merchant request

高风险边界:

• 不自动发起退款。
• 不自动拒绝争议。
• 不自动外发客户或商户通知。
• 不自动关闭 case。
• 所有资金影响动作必须人审或由既有规则引擎执行。

6.7 Policy Knowledge Base

推荐设计:

• Policy KB 暴露为 resources 和 search tools。
• 每条政策包含 version、effective_date、jurisdiction、product、owner。
• 输出必须引用 source refs。
• 过期政策不得作为当前建议依据, 但可用于历史 case 分析。

Prompt injection 风险:

• 外部网页、PDF、供应商文档中可能包含“忽略之前指令”类文本。
• RAG 结果必须作为 evidence, 不作为 instruction。
• 对政策库 ingestion 做 source allowlist、content scanning、approval workflow。

6.8 Ticketing Integration

推荐能力:

• 根据 case 创建内部 ticket。
• 查询 ticket 状态。
• 添加 ticket comment。
• 路由到合适队列。

控制:

• create ticket 要有 idempotency key, 防止重复建单。
• routing 不应只靠模型自由选择, 要基于队列规则和 capability matrix。
• ticket comment 如果包含客户信息, 要经过 PII guard。
• 大规模 ticket 创建要有 rate limit 和异常检测。

---

7. 治理交付物

7.1 Tool Catalog

Tool catalog 是平台治理的基础资产。

Portfolio governance 用法:

• 规划哪些工具先平台化。
• 对齐 use case 和工具能力。
• 管理 adoption 和工具复用率。

Process and requirement 用法:

• 把业务流程动作拆成 tool。
• 定义字段、异常路径、审批条件。
• 和业务 owner 确认验收标准。

Architecture governance 用法:

• 设计 gateway、connector、identity、policy、logging。
• 评估协议、transport、版本、SLA。
• 管理 integration boundary。

7.2 Integration Backlog

7.3 Capability Matrix

7.4 Vendor Risk Questions

7.5 Protocol ADR

Protocol ADR 要记录为什么采用 MCP、A2A、OpenAPI adapter、internal tool gateway 或 vendor SDK。

关键决策点:

• 这是 tool integration、resource access、agent handoff 还是 workflow orchestration?
• 是否需要 capability discovery?
• 是否需要 remote vendor support?
• 当前 host/runtime 是否支持该协议?
• 安全网关能否插入 authorization、policy、approval、audit?
• 是否需要 streaming、long-running task、artifact、push notification?
• 协议版本如何治理?
• 如果 vendor 不支持协议, 是否用 adapter 包装?

7.6 Security Review Checklist

---

8. 14 天 Lab: Agent Integration Platform Blueprint

目标: 14 天后形成一个可展示的 Agent Integration Platform Blueprint, 包含 tool catalog、capability discovery、MCP server intake、A2A handoff 设计、security checklist、vendor risk review 和 platform governance。

Blueprint 推荐结构

# Agent Integration Platform Blueprint

## 1. Use Case and Business Outcome
- Target workflow
- Users
- Baseline pain
- Success metrics

## 2. Capability Map
- Tools
- Resources
- Prompts
- Agent handoff
- Vendors

## 3. Protocol Architecture
- MCP server boundaries
- A2A handoff boundaries
- Tool gateway
- Security gateway
- Context composer

## 4. Tool Contracts
- Input schema
- Output schema
- Risk tier
- Permission
- Approval
- Audit
- Rollback

## 5. Security and Governance
- Policy matrix
- Prompt injection controls
- Vendor risk controls
- Audit and replay
- Kill switch

## 6. Roadmap
- MVP
- Pilot
- Production gate
- Scale plan

---

9. Templates

9.1 MCP Server Intake

# MCP Server Intake

## Basic Information
- Server name:
- Business owner:
- Technical owner:
- Risk owner:
- Source system:
- Environment: dev / test / prod
- Protocol version:
- Transport: stdio / Streamable HTTP

## Business Purpose
- Supported workflow:
- Supported agent / host:
- User roles:
- Business value:
- Non-goals:

## Capabilities
| Capability | Type | Risk tier | Owner | Status |
|---|---|---|---|---|
|  | tool / resource / prompt |  |  | proposed / pilot / approved |

## Data and Permission
- Data classes:
- Tenant / region scope:
- Resource entitlement rule:
- User identity source:
- Service identity:
- OAuth scopes or credential model:
- Data retention:

## Security Controls
- Input validation:
- Output filtering:
- Prompt injection controls:
- Human approval triggers:
- Rate limits:
- Kill switch:
- Secrets handling:

## Audit and Observability
- Audit event names:
- Correlation id:
- Logged metadata:
- Masked or encrypted fields:
- Metrics:
- Alert rules:

## Operations
- SLA:
- Timeout:
- Retry:
- Idempotency:
- Rollback / compensation:
- Deprecation policy:

9.2 Tool Contract Card

# Tool Contract Card

## Identity
- Tool name:
- Version:
- System:
- Business owner:
- Technical owner:
- Risk owner:

## Purpose
- Business capability:
- Intended users:
- Supported workflow:
- Explicit non-goals:

## Input Schema
```json
{
  "type": "object",
  "required": [],
  "properties": {},
  "additionalProperties": false
}
```

## Output Schema
```json
{
  "status": "success",
  "source_system": "",
  "retrieved_at": "",
  "data_classification": "",
  "result": {},
  "citations": []
}
```

## Risk and Permission
- Side effect tier:
- Required role:
- Required purpose:
- Resource entitlement:
- Tenant / region boundary:
- Human approval:
- Dual control:

## Reliability
- Timeout:
- Retry:
- Idempotency key:
- Rate limit:
- Fallback:

## Audit
- Event type:
- Required fields:
- Sensitive fields handling:
- Retention:
- Replay support:

## Recovery
- Rollback:
- Compensation:
- Manual remediation owner:
- Incident severity:

9.3 Capability Discovery Matrix

9.4 Protocol ADR

# ADR: Protocol Choice for Agent Integration

## Status
Accepted

## Context
- Use case:
- Systems involved:
- Agent / host:
- Required capabilities:
- Data classes:
- Risk tier:
- Vendor constraints:

## Decision
- Selected protocol:
- Selected transport:
- Integration boundary:
- Gateway pattern:

## Alternatives Considered
| Option | Pros | Cons | Decision |
|---|---|---|---|
| MCP server |  |  |  |
| A2A handoff |  |  |  |
| OpenAPI adapter |  |  |  |
| Vendor SDK |  |  |  |
| Internal gateway only |  |  |  |

## Security and Governance
- Identity:
- Authorization:
- Policy:
- Human approval:
- Audit:
- Prompt injection controls:
- Kill switch:

## Consequences
- Benefits:
- Trade-offs:
- Migration path:
- Deprecation plan:
- Open operational risks:

9.5 Integration Risk Checklist

---

10. 架构决策叙事

10.1 架构判断摘要

企业 AI Agent 的关键不只是模型能力, 而是它如何安全连接外部工具和数据。设计思路是把工具集成协议化: 用 MCP 这类协议暴露 tools、resources、prompts, 用 tool contract 定义 input/output schema、权限、副作用、限流、审计和回滚; 对 agent 间协作, 用 A2A 思维设计 task envelope、identity、capability card、state transfer 和 policy boundary。这样平台可以统一做 discovery、authorization、human approval、audit、vendor governance 和 release gate。

10.2 System Reasoning Narrative

在企业里, Agent 真正有价值的地方是能连接 CRM、case management、KYC vendor、payment dispute、policy KB 等系统, 但这也是最大风险来源。早期 custom plugin 可以快速 POC, 但规模化后会出现权限分散、审计断裂、供应商锁定、重复接入和安全评审困难。

做法是引入 protocol thinking。第一层是 tool contract, 每个工具必须有 input schema、output schema、side effect tier、permission、rate limit、audit event、idempotency、rollback 和 human approval 规则。第二层是 MCP 或内部 tool gateway, 用标准方式暴露 tools、resources、prompts, 并接入 identity、policy engine、DLP、audit 和 kill switch。第三层是 agent-to-agent handoff, 用 task envelope 和 capability card 明确目标 agent 能做什么、能看什么数据、能调用哪些工具、输出什么 artifact。

对金融零售场景, 应先做只读和草稿类能力, 比如 case summary、policy search、KYC gap analysis draft, 把退款、关闭 case、账户冻结、KYC 最终决定等动作放在强人审或既有规则系统里。上线前用 NIST GenAI Profile 的风险管理语言组织 governance evidence, 用 OWASP LLM01 的 prompt injection 风险做 red-team test, 确保工具调用不是只靠 prompt 防护。

10.3 Platform Governance Review

Platform governance 视角会把它产品化成四个资产:

1. Tool catalog: 所有工具、资源、prompt、agent capability 都有 owner、risk tier、schema、权限、审计和状态。
2. Integration backlog: 按业务价值、风险、复用度排序, 先做 read-only 和 draft, 再做受控写入。
3. Developer experience: 提供 MCP server intake、tool contract template、SDK/reference adapter、local test harness。
4. Governance dashboard: 看 adoption、tool reuse、denied calls、approval rate、latency、cost、incident 和 vendor health。

平台目标不应定义成“让所有业务自己随便接工具”, 而是“让高价值工具以可发现、可授权、可审计、可评估的方式复用”。

10.4 Architecture Review

Architect 视角应明确几个边界:

• Host / client / server boundary: host 控制用户体验、策略入口和审计; server 暴露工具和资源; client 做协议连接。
• Tool gateway boundary: 模型只能提出 tool call proposal, 真正执行前必须经过 schema validation、policy engine、approval、DLP 和 rate limit。
• Context boundary: resources 和 tool outputs 是 evidence / observation, 不是 instruction。
• Identity boundary: 同时记录 human user、agent identity 和 service identity, 不用共享万能账号。
• Protocol boundary: MCP 适合工具和资源连接; A2A 适合跨 agent 任务委派; 不支持协议的 vendor 用 adapter 包装。

架构上应要求 correlation id 串起 model call、context refs、tool calls、policy decisions、approval 和 final output, 这样才能支持 incident replay 和监管问询。

10.5 Security Review

Security 视角的核心观点是: prompt 不是安全边界。Prompt injection 可以来自用户输入, 也可以来自 RAG 文档、网页、邮件、case note 或供应商回复。控制点必须在平台层:

• Least privilege: 每个 agent 只拿当前 workflow 必要工具。
• Tool-level authorization: 结合 user、tenant、purpose、resource entitlement 和 risk tier。
• Human approval: 对 external-send、financial movement、regulated decision 做强审批或双控。
• Data protection: 对 PII、PCI、secret、外发内容做 DLP 和 redaction。
• Audit: denied call、approved call、tool result、output 都要记录。
• Kill switch: 能按 tool、server、vendor、tenant、workflow 关闭能力。
• Red-team eval: 把 prompt injection、excessive agency、data leakage、approval bypass 做成回归测试。

---

11. 治理证据包

可以把本手册转成一个系统证据包:

Case Title:
Designing a Governed Agent Integration Platform for Financial Retail Operations

Problem:
AI assistants need to use CRM, case, KYC, payment dispute and policy systems,
but unmanaged tool access creates security, audit and vendor risk.

Deliverables:
Tool catalog, MCP server intake, tool contract cards, A2A handoff design,
policy matrix, audit schema, vendor risk checklist, 14-day platform blueprint.

Business Impact:
Reduce duplicate integration work, improve governance, enable safe reuse of tools,
and create evidence for security, risk and architecture review.

建议展示 4 张图:

• Capability map: 业务系统、MCP server、tool gateway、agent、user。
• Tool call sequence: proposal、policy、approval、execution、audit。
• A2A handoff: case agent -> KYC specialist agent -> artifact。
• Governance dashboard: adoption、approval、denied calls、latency、incident。

---

12. 上线前检查矩阵

---

SOTA 检查 (2026-07-01)

• MCP：当前稳定版 2025-11-25（本手册基线 2025-03-26 已过时两个版本，关键差异——elicitation、结构化工具输出、OAuth 2.1 授权——见顶部版本状态框与 §3.10 更正注记）；2026-07-28 计划发布最终规范，发布后触发本手册逐项复查。
• A2A：已移交 Linux Foundation 治理（2025-06 起），规范持续演进；引用前以 a2a-protocol.org 当前版本为准。
• 本手册的协议无关结论（tool contract、capability discovery、policy matrix、audit schema、integration risk checklist）不随版本失效。Source Anchors 访问日期 2026-06-30。