S47：连接 Protocol、Business Semantics、Identity、Version 与 Recovery

内容类型：预习教材（不代表已完成）
日期：2027-01-08
阶段：P2 · AI Systems Engineering 90
总路线：Day 137 / 360
周次：W7 · Protocols & Enterprise Integration
节奏：周五知识整理
状态：教材已备；学习未完成
标签：protocol-semantics、identity、version、recovery、sequence-diagram

一句话定义

可维护的企业集成必须让“怎样传、传什么、代表谁、按哪个版本、失败后怎么办”同时可见；只完成协议握手并不等于完成系统设计。

学习目标

1. 把 W7 的协议、语义、身份、版本和恢复放入同一序列图。
2. 能为每次跨边界调用说明业务前置条件与成功含义。
3. 理解身份与版本信息必须沿异步链传播但不能变成可随意信任的声明。
4. 总结 API、event、Agent task 与 human queue 的选择逻辑。

核心知识

• Protocol 定义消息与交互规则；business semantics 定义领域命令、事实、约束和责任。两者一一对应是理想，现实中同一协议承载多种语义。
• Identity 包括原始用户、代表用户行动的 Agent、调用服务和最终资源 owner。每层需验证，而不是信任上游传来的字符串。
• Version 不只属于 schema：tool implementation、policy、prompt、model 与 consumer 同时影响行为。证据链要记录实际解析版本。
• Recovery 是契约的一部分。调用方需要知道哪些错误可重试、是否有幂等 key、怎样查询状态、完成事件是什么、超时后联系谁。
• 序列图若只画 happy path，会隐藏重复、拒绝、等待和恢复。至少加入一种业务拒绝和一种未知状态。
• 企业 canonical model 可以减少翻译，但过度统一会抹去领域差异；边界映射比单一超级 schema 更现实。

机制与推导

一条可解释的序列应携带：

User -> Agent: intent + delegation
Agent -> Tool Gateway: tool call + actor chain + purpose + idempotency key
Gateway -> Core API: validated command + resolved contract version
Core -> Event Bus: accepted/rejected/completed fact + correlation/causation
Workflow -> Human Queue: evidence refs + decision rights + deadline
Human Queue -> Workflow: versioned decision event

恢复契约可看作每个 operation 的第二输出：正常结果之外，还要提供 retryable? / statusQuery / reconciliationOwner / terminalStates。若这些信息只存在运维人员经验中，Agent runtime 无法安全自动化。

版本证据也应区分 requested 与 resolved。调用者请求 v1，gateway 可能解析到 1.3.2；audit 应保存解析结果。异步 consumer 也要记录自己处理时的版本，才能解释同一事件在不同时间为何结果不同。

最小练习或观察步骤

1. 使用 S43 案例，画一个 happy path 和一个 timeout/拒绝分支。
2. 在每条消息旁写 protocol、business type、actor/audience、schema version 与 key。
3. 为一个 operation 添加 recovery contract：可重试错误、状态查询与终态。
4. 找出一个“协议成功但业务失败”的位置。
5. 写 W7 三条最重要联系与两个仍含糊问题。
6. 不需要实现跨系统调用，清晰序列图就是本日主要产出。

常见误区与边界

• 规范验证通过就认为业务语义一致。
• 事件里有 actorId 就不再验证来源和委托。
• 只记录 latest version，历史无法重现。
• recovery 完全交给调用方猜测，导致所有错误都重试。
• canonical model 变成庞大共享耦合点，任何团队都不敢升级。
• W7 小结不是集成认证，不需列举所有协议特性。

系统 / 金融 / Web3 场景连接

金融案件升级需要知道分析师、Agent、gateway 和核心系统各自身份，事件必须保留目的与版本，人工决定才能回到正确 workflow。Web3 场景中，RPC 返回、交易池接受、区块包含和最终确认是不同语义；协议都可成功，但资产状态可能仍未最终确定。

自检问题

1. 协议兼容为何不能证明业务兼容？
2. requested 与 resolved version 为什么都值得记录？
3. recovery contract 至少包括什么？
4. actor chain 在跨系统委托中怎样验证？

专业课程对齐

• 阅读 A2A Protocol 官方文档 的 Agent Card、task lifecycle、messages 与 artifacts，重点映射长时任务的状态和跨 Agent 身份边界。
• 阅读 Model Context Protocol 官方文档 的 architecture、tools 与 authorization 内容，比较工具调用与 Agent task 的不同恢复语义。
• 阅读 AsyncAPI 官方文档 的 message/operation 与 schema 内容，将异步业务事实、版本和消费者责任落到序列图。

深入学习提示

先完成“无协议名序列图”，再把规范能力贴上去。每个箭头用五问检验：代表谁、请求什么、何时算成功、重复怎么办、哪个版本。若图过密，宁可拆成命令流、事实流和人工流三张小图，不追求一张万能架构图。

学后填写区

• 序列图与异常分支：
• 身份 / 版本传播：
• Recovery contract：
• W7 三条联系：
• 待复习问题：