企业官网建设流程全解析

MCP 之后是 A2A:多智能体集群怎么解决消息乱序与上下文丢失

单 Agent 跑得很顺，一拆成多智能体就开始乱：A 发出的任务 B 没收到，C 的上下文里缺了 D 上一步的输出，同一个任务重跑三次得到三份不一样的结论。这三种故障并不是模型能力不足，而是工具接入、消息路由、状态传递和验收标准四个工程环节同时失控的表现 [3]。

这篇文章沿一条主线展开：先把「基础 Agent → MCP 本地 → Remote MCP」三级演进讲清楚，理解工具数量从个位数膨胀到 N×M 之后到底带来了什么；再给出一套 MCP + A2A + Skills + DeepAgents 的多角色集群分工方案 [2]；最后把重心压在生产环境三大痛点——消息乱序、上下文缺失、结果不一致——的成因、对策、排障清单与验证方法上 [3]。

需要先说明两点写作约定：

• 本文中的「生产故障」均为通用现象描述，示意任务均为明确标注的设计示例，不代表任何真实生产系统的实测结果。文中不给出未经实测的性能提升百分比。
• MCP、A2A、Skills、DeepAgents 的官方规范版本、维护主体与字段命名，应以各自官方文档为准。本次研究材料以中文技术社区的二手分析为主 [2][3][4]，涉及具体协议字段时，本文统一按「工程设计建议」给出，并标注为示意代码，避免把二手转述当作规范原文。

开篇：为什么单体可控，集群失控

把故障现象拆开看，三类问题的触发路径并不相同：

消息乱序：编排器并行派发了「采集数据」和「拉取模板」两个子任务，模板任务先返回，采集任务因为第三方接口慢而延迟到达。下游分析角色先收到了模板，把「暂无数据」当成了正式输入。

上下文缺失：分析角色把结论写在了自己的会话上下文里，只把最终结论字符串传给写作角色。写作角色拿不到原始数据引用，质检角色更无从核对数字来源。

结果不一致：同样的输入跑三次，一次走的是模型 A，一次因为工具超时触发了降级路径，一次因为采样参数不同生成了不同措辞。三个产物都不算「错」，但没有一份可以被稳定复用。

这三类问题的共同点是：在单 Agent 场景里，工具、状态和决策都在一个进程、一段上下文里，问题被隐式地掩盖了；一旦拆成多角色，原本隐式的状态必须显式化，任何一处没显式化的地方都会变成故障点。这也解释了为什么 2026 年下半年的社区讨论重心从「选哪个框架」转向了「编排与运行时怎么收敛」——框架之争解决的是怎么写，运行时与协议层解决的是怎么稳定地跑 [5][6]。

全文路线：三级演进 → 协议分工 → 角色落地方案 → 三大痛点排障 → MCP 注册清单 → A2A 路由清单 → 验收指标 → 落地顺序。

一、三级演进：基础 Agent → MCP 本地 → Remote MCP

1.1 一张对比表看懂三阶段

社区课程材料给出了一张五维对比表，把单 Agent 工具接入的演进拆成三个阶段 [1]。下表在保留原口径的基础上做了归一化说明：

这里要澄清一个口径差异：原始材料中的「1→4→N×M」里的「4」是该课程 Demo 的具体工具数，属于示例值而非通用规律 [1]；本文命题中的「1→N×M」是把第二阶段一般化为「单 Server 提供 N 个工具」。两种说法不矛盾，但引用时不能把示例值当成协议能力上限。

真正值得注意的是 N×M 这个乘法：它既是收益（工具生态可复用），也是债务（命名、鉴权、版本三类问题随 M 线性甚至超线性增长）。

1.2 Remote MCP 的连接拓扑与边界

Remote MCP 阶段的典型拓扑是三类 Server 并存：

• 本地 stdio Server：进程内或本机启动，适合访问本地文件、本地数据库、需要低延迟的私有工具；
• 通过包管理器拉起的 Server：由客户端按需启动，适合官方或社区维护的通用工具；
• 远程 HTTP Server：独立部署、独立鉴权、独立升级，适合多团队共享或需要统一治理的工具。

MCP 客户端配置的结构示意如下。字段名随 SDK 与版本不同可能有差异，落地时请以所用 SDK 的官方文档与类型定义为准：

// 示意：MCP 客户端多 Server 配置结构（非某一 SDK 的可运行示例） { "mcpServers": { "local-fs": { "transport": "stdio", "command": "node", "args": ["./servers/fs-server.js"], "env": { "ALLOW_ROOT": "/data/workspace" } }, "remote-data": { "transport": "http", "url": "https://mcp.internal.example.com/data", "auth": { "type": "bearer", "credentialRef": "env:MCP_DATA_TOKEN" }, "timeoutMs": 30000 } } }

stdio 与 HTTP 的边界可以按三条判断：是否需要跨进程/跨机调用；是否需要独立的生命周期与灰度升级；是否需要独立的身份与审计。三条里满足两条，通常就值得把该 Server 远程化。

1.3 N×M 的代价：命名冲突、鉴权、版本漂移

工具数量爆炸后，最先出问题的不是调用链路，而是工具选择准确率。

命名冲突：M 个 Server 都可能暴露search、query、fetch这类通用名。模型在几十上百个工具里做选择时，同名或近义工具会直接拉低选择准确率。工程上的对策是建立命名空间约定，例如<server>-<domain>-<action>（data-metric-query、chart-echarts-render），并在注册期做全局唯一性校验，冲突即拒绝注册，而不是让模型自己猜。

鉴权分散：远程 Server 各有自己的凭据、有效期和权限范围。凭据散落在客户端环境变量里会导致轮换困难、审计断链。建议统一走凭据引用（credentialRef）+ 集中密钥管理，Agent 侧只持有引用不持有明文。

版本漂移：Server 升级后工具签名或返回结构变化，而 Agent 侧的提示词与解析逻辑没跟着改，故障往往以「参数校验失败」或「结果解析为空」的形式出现。对策是每次注册记录工具清单快照（含 schema 摘要），调用期记录实际使用的服务版本，形成可 diff 的基线。

1.4 升级决策清单

二、协议分工：MCP / A2A / Skills / DeepAgents 各解决什么

2.1 四层职责切分

这四者经常被并列讨论，但它们管的是四件不同的事：

MCP 与 A2A 的关系是正交的：MCP 回答「Agent 怎么用工具」，A2A 回答「Agent 怎么和另一个 Agent 协作」。一个 Agent 可以同时是 MCP 客户端（调用工具）和 A2A 服务端（接受任务）。这正是六角色集群里每个子 Agent 的典型形态 [2][4]。

Skills 的落点是「可复用、可版本化、可审查」的静态能力：报告写作模板、合规审查规则、图表 Schema 约定，都可以做成 Skill，随仓库演进并接受代码评审。DeepAgents 类运行时的落点是动态执行：任务拆分、并行度控制、子 Agent 隔离、工件暂存。近期的行业动向也显示出「编排责任向运行时甚至模型转移」的趋势，例如有材料描述了由 Lead Agent 生成调度代码、按任务复杂度伸缩并行度的动态工作流方案 [7]；但这类方案的可复现性与调试成本仍需在自己的场景里实测，不能直接当成默认选项。

2.2 边界与反模式：什么时候不需要 A2A

A2A 解决的是「多个自治 Agent 在不同进程/不同服务里协作」的问题。以下场景不需要它：

• 单进程内一个 Agent 顺序调用多个 MCP 工具：用 MCP 就够；
• 单 Agent 多步骤规划，步骤间只是工具结果传递：用编排循环加结构化状态就够；
• 只有两个角色、且调用是同步单跳：函数调用或内部消息队列往往比引入完整 A2A 栈更简单。

过早引入消息路由的代价是明确的：你需要为它补上会话标识、投递语义、幂等、重试、死信、观测，这些成本在只有一两个角色时是纯负担。判断标准可以压缩成一句话：当你发现需要「跨服务、可异步、可重试、可追踪」地把任务交给另一个自治体时，才需要 A2A。

2.3 一次任务在四层之间的流转

一个报表类任务的示意时序如下（明确标注为设计示意）：

用户 → 入口Agent：识别意图、补全参数、生成 task_id 入口Agent → 编排Planner：提交任务规格 编排Planner → 采集Agent / 图表Agent：并行派发子任务（各带 seq 与 artifact_ref 约定） 采集Agent ↔ MCP 工具（数据库、HTTP）：取数，落盘为 artifact 分析Agent ← 编排Planner：接收 artifact_ref（不是原始大字段） 分析Agent → MCP 工具（计算库）：清洗、统计、异常检测 写作Agent + 图表Agent ← 分析结果引用：生成报告与图 质检Agent ← 全部 artifact_ref + 验收规则 Skill：校验事实、格式、合规 质检Agent → 编排Planner：通过 / 打回（带缺陷清单） 入口Agent → 用户：返回产物引用与摘要

三、六角色集群落地方案

3.1 角色职责表

先澄清一个必须交代的计数问题：相关材料正文称「拆了六个 Agent」，但其角色表实际列出七行（入口、编排、采集、分析、写作、图表、质检）[2]。本文的处理方式是：六个执行角色（入口、编排、采集、分析、写作、图表）+ 一个质检旁路角色，质检不进入主执行链路而是旁路校验。如果你的实现里质检是主链路上的必经节点，那么它就是第七个角色，按七角色计数即可，不要在文档里含糊带过。

3.2 一个报表类任务的子任务 DAG

以「产出一份带图的数据周报」作为示意任务（设计示例，非真实生产案例）：

T0 入口规格化 └─ T1 编排拆解 ├─ T2 数据采集（并行，可再拆为多个数据源） ├─ T3 模板与图表 Schema 加载（并行） ├─ T4 分析（依赖 T2） ├─ T5 写作（依赖 T4、T3） ├─ T6 图表（依赖 T4、T3） └─ T7 质检（依赖 T5、T6）

关键取舍在于并行边界：T2 与 T3 可以并行，T5 与 T6 可以并行，但 T4 必须等 T2 全部完成。DAG 中每条边都应当是「工件引用」而非「大段文本」，否则并行度越高，消息体积与上下文污染越严重。

3.3 契约设计：消息 Schema 与产物版本

下面是消息对象的字段设计示意，属于通用工程建议，不是任何协议的既定字段：

// 示意：子任务消息对象（工程设计建议，非协议规范字段） { "task_id": "tsk_20261018_0001", // 全局唯一，贯穿全链路 "parent_id": "tsk_20261018_0000", // 父任务关联 "role": "analysis", // 目标角色 "seq": 12, // 因果序号，同一 task_id 内单调递增 "idempotency_key": "tsk_...:12:a1b2",// 幂等键，重试时保持不变 "context_id": "ctx_...", // 显式上下文标识 "artifact_refs": [ // 只传引用，不传大字段 { "name": "raw_metrics", "uri": "artifact://...", "sha256": "..." } ], "schema_version": "1.2", // 消息契约版本 "trace_id": "trc_...", // 全链路追踪 "deadline_ms": 60000, "retry": { "attempt": 0, "max": 3 } }

三个容易被忽略的设计点：

1. seq 与 idempotency_key 分工不同：seq 用于排序与因果校验，idempotency_key 用于去重。重试时 seq 可以不变、重投次数增加，但幂等键必须保持一致，否则接收方无法识别这是同一次逻辑操作。
2. schema_version 必须显式：消息契约升级时，接收方按版本选择解析器，而不是靠字段是否存在来猜。
3. 工件带摘要：sha256之类的完整性摘要可以在质检阶段做产物比对，也是「重跑一致性」指标的基础。

3.4 Skills 与 DeepAgents 的落点

判断一个能力该不该做成 Skill，可以看三条：是否可复用、是否需要评审与版本化、是否与具体任务无关。写作模板、审查规则、图表 Schema 都满足，适合 Skill 化。判断一个逻辑该不该交给运行时，看它是否涉及动态决策：并行度伸缩、失败重派、子 Agent 隔离、执行沙箱，这些属于运行时职责。

一个常见的反模式是把编排逻辑写进提示词：让入口 Agent 「顺便」决定调用顺序。这样做的问题是不可观测、不可重放、不可测试。编排决策应当落成显式的计划对象（DAG + 参数），提示词只负责生成计划，执行由运行时负责。

四、生产三大痛点：成因 → 对策 → 验证

4.1 消息乱序

成因分三条路径：

• 并发派发：多个子任务并行执行，返回顺序不受控；
• 异步回调：结果通过回调或订阅返回，回调到达顺序与完成顺序不一致；
• 失败重试：某条消息超时后重投，旧消息与新消息交错到达，且可能重复。

对策与落地层：

最小复现思路：让一个编排器并行派发两个子任务，人为给其中一个加随机延迟，观察下游是否按完成顺序而非因果顺序处理。

故障注入思路：对同一条消息做重复投递与乱序投递，验证去重表命中率与乱序缓冲的超时升级行为。这里不预设重复次数与延迟区间，应按你的 SLA 与重试策略设定并在实验记录中写明。

4.2 上下文缺失

成因：

• 隐式状态：角色把关键中间结果只留在自己的会话上下文里，跨角色即丢失；
• 只传结论不传引用：下游拿到结论字符串，拿不到原始数据与推导依据；
• 上下文窗口预算：把全部历史塞进提示词会挤占有效信息，反而制造「看似有上下文、实则噪声淹没」的假缺失。

对策与取舍：

1. 共享工件库 + 引用传递：大体积产物落盘或存对象存储，消息里只传artifact_ref。这是首选方案，成本最低、可审计。
2. 显式 context_id：每次任务创建上下文标识，所有角色写入与读取都必须声明它。禁止靠「会话里应该有」这种隐式约定。
3. 关键中间产物落盘：分析结论、清洗后数据集、校验结果都应成为可独立读取的工件，而不是某次模型输出里的一段文字。
4. 上下文摘要：历史过长时生成带引用的摘要版本，但摘要必须保留指向原文工件的引用，否则摘要本身就成了新的丢失点。

# 伪代码：工件引用传递（示意，非可运行 SDK 调用）defpass_artifact(ctx,name,payload):uri,digest=artifact_store.put(ctx.task_id,name,payload)return{"name":name,"uri":uri,"sha256":digest,"context_id":ctx.context_id,"produced_by":ctx.role,"seq":ctx.next_seq(),}# 下游接收方：只根据引用取回，不做「从消息正文猜数据」defconsume(refs):forrinrefs:assertverify_digest(r.uri,r.sha256),"artifact integrity check failed"yieldartifact_store.get(r.uri)

最小复现思路：让两个角色完成「分析 → 写作」，第一次只传结论字符串，第二次传工件引用，观察写作角色在被问到「这个数字来自哪张表」时能否给出可核对的答案。

故障注入思路：在角色切换时人为丢弃artifact_refs字段或截断历史，验证质检角色能否通过完整性检查发现缺失，而不是继续生成看似完整的报告。

4.3 结果不一致

成因四分法与检测信号：

需要注意的是，「一致」不等于「逐字相同」。工程上更实用的口径是结果等价：结构一致、关键数值在容差内一致、引用的工件可核对、通过同一套验收规则。对生成式文本要求逐字复现既不现实，也会逼团队去做没有价值的过度约束。

最小复现思路：同一任务规格固定所有版本与参数，连续执行若干次（次数按你的成本预算设定并记录），比对结构化字段与工件摘要。

故障注入思路：分别注入「改变采样参数」「切换工具版本」「强制走降级路径」三类扰动，观察质检规则能否识别哪一类导致了偏差。三类扰动应当分别注入，不要合并测试，否则无法归因。

五、MCP 服务注册排障清单与验证方法

5.1 注册期检查

• ☐Server 可达性：症状是注册超时或连接拒绝；检查网络连通、进程启动命令、端口占用；期望结果是握手在超时阈值内完成。
• ☐握手/初始化：症状是连接建立但工具列表为空；检查初始化序列、协议版本协商、客户端能力声明；期望结果是初始化成功且返回服务端能力。
• ☐工具枚举完整性：症状是 Server 自称有 N 个工具、客户端只枚举到 K 个；检查分页/截断、权限过滤、日志中的枚举结果；期望结果是枚举数与 Server 声明一致。
• ☐命名冲突：症状是同名工具互相覆盖或模型选择错误；检查全局工具名唯一性；期望结果是冲突注册被拒绝并给出冲突方。
• ☐鉴权与凭据：症状是 401/403 或调用期偶发失败；检查凭据引用、有效期、权限范围、轮换记录；期望结果是鉴权失败有明确错误码而非静默空结果。
• ☐版本声明：症状是升级后解析失败；检查 Server 版本、工具 schema 摘要是否被记录；期望结果是每次注册生成可 diff 的清单快照。

5.2 调用期检查

• ☐参数校验失败：检查请求 schema 与工具定义是否同源、必填字段与类型是否匹配；期望是错误返回包含字段级定位信息。
• ☐超时：区分连接超时、读超时、执行超时；检查超时值是否与任务 SLA 匹配；期望是超时可被上层识别为可重试或不可重试。
• ☐工具结果过大：症状是上下文暴涨或传输被截断；检查返回体大小、分页能力；期望是大结果落工件、消息内只传引用。
• ☐错误透传与重试语义：检查错误是否带错误码与原因、重试是否幂等；期望是可重试错误与业务错误被区分。

5.3 验证方法

方法一：工具清单快照 diff。注册前后各取一次工具列表（含 schema 摘要），做结构化比对。示意脚本如下，字段解析需按你所用 MCP SDK 的实际返回结构适配：

# 伪代码：工具清单 diff（示意，需按实际 SDK 返回结构适配）importhashlib,jsondefsnapshot(tools):out={}fortintools:body=json.dumps(t.get("inputSchema",{}),sort_keys=True)out[t["name"]]={"schema_sha":hashlib.sha256(body.encode()).hexdigest()[:12],"desc":(t.get("description")or"")[:60],}returnoutdefdiff(before,after):added=sorted(set(after)-set(before))removed=sorted(set(before)-set(after))changed=sorted(nforninset(before)&set(after)ifbefore[n]!=after[n])return{"added":added,"removed":removed,"changed":changed}# 用法：注册稳定期取基线，发布后取新快照并告警 changed / removed

方法二：绕过 Agent 的单工具直连调用。跳过模型与编排，用最小客户端直接调用目标工具，用于区分「工具坏了」与「模型选错了工具」。最小直连脚本应只做三件事：建立连接、枚举工具、用固定参数调用一次，输出原始返回与耗时。

方法三：健康检查探针。为每个注册的 Server 建立周期性探活，指标至少包含：握手成功率、工具枚举数、单工具最小调用耗时、最近一次错误码。探针参数（周期、阈值）按你的 SLA 配置，不在本文预设具体数值。

六、A2A 消息路由排障清单与验证方法

6.1 寻址与会话关联

• ☐能力发现：症状是派发失败或派给了不具备能力的 Agent；检查目标 Agent 的能力声明与注册中心条目是否一致；期望是派发前能查到能力、超时和并发上限。
• ☐任务/会话标识贯穿：症状是日志里无法把一次任务的各跳串起来；检查 task_id、context_id 是否在每一跳日志中出现；期望是任意一跳日志都能反查到完整链路。
• ☐父子任务关联：症状是子任务结果无法归并；检查 parent_id 与 seq 的填写；期望是子任务能唯一定位到父任务与触发它的上游产物。

6.2 路由与投递语义

• ☐路由表/注册中心条目：症状是消息发出去无人接收；检查目标地址、能力匹配、实例存活；期望是路由失败返回明确原因而非静默丢弃。
• ☐超时与重投：症状是重复处理或任务悬挂；检查重投上限、退避策略、幂等键在重试中保持不变；期望是重试不会产生第二个逻辑结果。
• ☐乱序缓冲：症状是下游按到达顺序处理；检查 seq 连续性校验与缓冲超时升级；期望是乱序消息被暂存，超时进入死信。
• ☐死信与人工兜底：症状是任务消失无痕；检查死信队列是否保留原始消息、上下文引用与失败原因；期望是死信可重放且重放同样幂等。

6.3 验证方法

方法一：全链路 trace_id 贯穿。每跳日志必须带trace_id、task_id、role、seq、event、artifact_ref。验收标准很直接：随机抽取一条任务，仅凭日志就能重建出完整的执行序列与产物依赖图。

方法二：消息回放测试。录制一次完整的消息序列（含时间戳与投递顺序），在隔离环境重放。注意两点：重放必须使用与录制时相同的工具与模型版本，否则比对的是环境差异而不是系统行为；重放前应通过幂等键清理或隔离历史状态，避免与旧数据冲突。

方法三：故障注入矩阵。四类注入分别验证，不要混合：

七、可观测性与验收指标

7.1 三个核心指标的口径

相关材料提出用「任务完成率」和「上下文复用」做上线验证，但没有给出具体数据 [3]。因此本文只给定义与计算口径，实测数值由你的实验记录给出：

任务完成率= 通过质检的任务数 ÷ 接收的总任务数。分子必须以质检通过为准，而不是以「有产物返回」为准，否则降级产物会被计入成功。

上下文复用率= 被下游成功解析并使用的工件引用数 ÷ 上游发布的工件引用总数。这个指标衡量的是「上下文是否真的传到了」，而不是消息里有没有写字段。

重跑一致性= 结构化字段与工件摘要比对通过的重跑次数 ÷ 总重跑次数。比对口径采用「结果等价」（结构一致 + 关键数值在容差内 + 验收规则通过），不采用逐字一致。

7.2 日志与 Trace 必带字段

trace_id、task_id、parent_id、role、seq、idempotency_key、context_id、artifact_ref、tool_name、tool_version、model_id、model_params_digest、retry_attempt、latency_ms、error_code。缺任何一项，上面三个指标都会算不准。

八、落地路线与避坑总结

推荐的最小落地顺序是：

1. 固化工具层：先把工具收敛到 MCP，统一命名、统一参数校验、统一错误语义。退出条件：单 Agent 场景下工具调用可稳定复现。
2. Remote 化：按第 1.4 节的决策清单，把需要共享、独立鉴权、独立升级的 Server 迁到远程。退出条件：注册期清单全部通过，工具清单快照可 diff。
3. 拆角色：按职责切出子角色，但先用同步调用连起来，不引入复杂路由。退出条件：子任务 DAG 与消息契约稳定，工件引用传递跑通。
4. 上 A2A 路由：在确认需要跨服务异步协作后再引入路由层，补上 seq、幂等、去重、死信。退出条件：故障注入矩阵四类注入全部表现符合预期。
5. 补观测与验收：把三个指标接入日常，而不是上线前跑一次。

三个最常见的过早优化：一是还没有稳定工具契约就拆角色，把工具层的不确定性放大成消息层的故障；二是还没有工件化就上路由，上下文缺失会以更隐蔽的方式出现；三是追求「完全一致」而忽略结果等价口径，把工程资源耗在没有业务价值的约束上。

回到开头的三种故障：消息乱序靠因果序号、幂等与乱序缓冲解决；上下文缺失靠工件化、显式 context_id 与完整性校验解决；结果不一致靠版本固定、确定性后处理与质检回路解决。它们都不是模型问题，而是把隐式状态显式化、把隐式契约工程化的问题。MCP 解决工具怎么接，A2A 解决任务怎么走，Skills 解决能力怎么复用，运行时解决执行怎么隔离——四层各司其职，集群才不会在规模上去之后退回「换个方式写 Prompt」的老路。

参考资料

[1] Agent 智能体开发实战 · 第七课：Remote MCP —— 从本地工具到远程服务，掘金，https://juejin.cn/post/7661831969440907318

[2] 多智能体集群实战：MCP+A2A+Skills+DeepAgents 完整落地指南，CSDN，https://blog.csdn.net/weixin_33624741/article/details/167153163

[3] Hermes Agent 实战：用 MCP 与 A2A 让 AI 智能体越用越聪明，CSDN，https://blog.csdn.net/weixin_42591413/article/details/168224217

[4] 2026 AI Agent 开发完全指南：从 MCP 协议到多 Agent 协作系统，CSDN，https://blog.csdn.net/weixin_54908067/article/details/162665003

[5] 从「框架混战」到「运行时收敛」：2026 年 AI Agent 开发框架的三条路线之争，CSDN，https://blog.csdn.net/m0_74899094/article/details/167082205

[6] 编排成主角：从 10 月 7 日五条动态看 Agent 工程栈成形，掘金，https://juejin.cn/post/7693721621530165283

[7] AI 前沿｜2026 年 10 月 14 日：Anthropic Dynamic Workflows + 多智能体自主编排 + Agent 动态拓扑，CSDN，https://blog.csdn.net/gedonshen/article/details/167894930

[8] 2026 年 10 月 10 日 AI 行业日报｜字节 TRAE 开发工具全面升级、史诗级安全事故、千级并行智能体，CSDN，https://blog.csdn.net/Smoothly_Lu/article/details/167463568

说明：以上均为中文技术社区的二手技术分析与课程材料。MCP、A2A、Skills 及 DeepAgents 的官方规范名称、版本号与字段定义，请以各自官方文档为准；本次研究资料未提供官方文档链接，故本文未列出官方来源条目，涉及协议字段的内容均以工程设计示意呈现。