AI Agent Protocols / MCP / A2A / Tool Integration Playbook

定位: 面向 AI Platform PM / AI BA / AI Architect 的 Agent 工具集成与协议化手册。 目标: 理解企业 AI Agent 如何从一次性 custom plugin 走向 protocol、tool contract、capability discovery、policy boundary、audit trail 和 vendor integration governance。 核心结论: Agent 的价值不只来自模型推理, 而来自它能否以可授权、可审计、可回滚、可治理的方式连接外部工具、数据和服务。

---

Source Anchors

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

---

1. 定位与现有文档关系

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

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

一句话关系:

AI Platform PM 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

对 PM / BA / Architect 来说, 协议化要回答 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, 并返回结构化结果或文本观察。

PM / BA / Architect 需要把每个 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 向用户收集额外信息的交互模式。

在企业落地时, 采用 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 主要解决 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. BA / PM / Architect 输出

7.1 Tool Catalog

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

PM 的用法:

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

BA 的用法:

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

Architect 的用法:

• 设计 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 30 秒版本

企业 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 2 分钟版本

在企业里, 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 PM 深挖

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

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 Architect 深挖

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 深挖

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. 作品集转化建议

可以把本手册转成一个 portfolio case:

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. 自检清单