S43：Agent、Tool、Core System、Event 与 Human Queue 的边界

内容类型：预习教材（不代表已完成）
日期：2027-01-04
阶段：P2 · AI Systems Engineering 90
总路线：Day 133 / 360
周次：W7 · Protocols & Enterprise Integration
节奏：周一概念与阅读
状态：教材已备；学习未完成
标签：integration、mcp、a2a、api、event、human-queue

一句话定义

企业 Agent 集成的核心不是连接更多协议，而是为发现、调用、业务事实、异步协作和人工决策划清边界，并保留跨边界的身份与因果证据。

学习目标

1. 能说明 MCP、A2A、OpenAPI、AsyncAPI 和 CloudEvents 大致位于哪类交互边界。
2. 画出 Agent→tool→core system→event→human queue 的端到端图。
3. 区分能力发现、同步命令、异步事实事件和长时任务协作。
4. 理解协议兼容不等于业务语义一致或授权正确。

核心知识

• MCP 为模型/Agent 客户端发现并调用工具、资源与提示提供标准化交互；它不替工具定义业务事务或最终权限。
• A2A 面向 Agent 之间能力发现、任务委派、状态与结果交换；它不应被当作所有内部服务 RPC 的替代品。
• OpenAPI 描述 HTTP API 的请求响应契约，适合明确的同步资源或命令接口。
• AsyncAPI 描述异步消息接口、channel、message 和 operation；CloudEvents 提供跨系统事件 envelope。二者可组合，但都不自动定义业务事件含义。
• Human queue 是有容量、优先级、技能、期限和决策权的运营系统，不是“Agent 失败后的邮箱”。
• 协议层回答怎样交换，领域层回答交换什么、谁有权、成功意味着什么；两层都必须可版本化。

机制与推导

一条典型路径：

Agent discovers tool capability (MCP/A2A metadata)
 -> submits command (tool call / HTTP API)
 -> core system validates identity and business rules
 -> emits accepted/rejected event (AsyncAPI + CloudEvents shape)
 -> workflow waits or creates human task
 -> later event resumes workflow and records outcome

调用返回 200 可能只表示命令被接受，不表示业务效果完成。因而同步 response 与异步 fact event 需要不同名字和 correlation。可用 correlationId 串联旅程、causationId 表示直接因果、subject/businessKey 指向业务实体。

协议选择受等待时间和耦合影响：短时且调用者必须立即得到结果可用同步 API；长时、扇出或需要解耦可用事件；跨 Agent 的持续任务适合任务协议；需要人类判断则进入 human queue。不要只按团队偏好选协议。

最小练习或观察步骤

1. 选择合成的支付争议或 AML 案例，列出 Agent、工具、核心系统、事件总线和人工队列。
2. 为每条箭头标注 command/query/event/task，而不只写“API”。
3. 再标注可用协议，以及业务权威状态实际在哪里。
4. 找出一个 accepted != completed 的位置，并增加后续确认事件。
5. 标出 actor identity、delegation、correlation 与 idempotency key 的传播范围。
6. 只画边界图，不要求启动 broker、MCP server 或外部系统。

常见误区与边界

• 为追求统一把所有交互都改为 MCP 或所有内容都改为事件。
• 把 tool description 当成完整业务契约，遗漏错误、幂等和副作用。
• 只传播用户 ID，不传播 Agent 代表用户执行的委托范围。
• 用一个 trace id 同时冒充业务 key、幂等 key 和授权凭证。
• 核心系统已接受就让 Agent 对用户宣称最终完成。
• 本日只建立协议位置与边界，不评价某协议“胜出”，也不虚构互操作结果。

系统 / 金融 / Web3 场景连接

金融 Agent 可以通过 MCP 发现“读取案件”和“提交升级建议”工具，真正的案件系统仍验证权限并发出状态事件；高风险建议进入主管队列。Web3 Agent 可通过工具读取链状态并构造交易，但钱包负责授权签名，节点/RPC 负责广播，链上确认事件才代表不同程度的最终性。

自检问题

1. MCP、A2A、OpenAPI、AsyncAPI/CloudEvents 各适合哪类边界？
2. 为什么同步响应与业务完成事件要分开？
3. human queue 为什么是一种系统边界而不是 fallback？
4. correlation、business key 和 idempotency key 有何不同？

专业课程对齐

• 阅读 Model Context Protocol 官方文档 的 architecture、servers、tools 与 authorization 导航，重点确认能力发现和调用边界，不把 MCP 当业务工作流引擎。
• 阅读 A2A Protocol 官方文档 的 Agent Card、task 与消息交互概览，具体比较 Agent 委派和普通工具调用的生命周期差异。
• 阅读 AsyncAPI 官方文档 的 channels、messages、operations 概念，观察异步契约怎样描述生产/消费关系，并映射到 core system event。

深入学习提示

先画没有协议名的业务图，再为每条边选择协议。深入时逐条写“调用方等待多久、谁拥有最终事实、能否重复、怎样确认、谁授权”。若这些问题没有答案，换协议不会自动修复设计。保持在架构理解层，不扩展为多协议 demo。

学后填写区

• 选择的案例与系统边界：
• 各箭头的交互类型：
• 一个 accepted / completed 差异：
• 身份与证据传播：
• 尚未理解的问题：