企业官网建设流程全解析

Agent 协作这件事，过去一年被讨论得很多，但真正落到架构层面，很多团队还是停留在“把几个 Agent 串起来跑通”的阶段。A2A 这个概念被提出来之后，我身边不少做多智能体系统的朋友都在问同一个问题：它到底解决的是通信问题、编排问题，还是协作范式问题？我自己的判断是，A2A 真正要解决的，是多个 Agent 之间如何在不共享内部状态的前提下，完成可信、可组合、可演进的协作。这件事听起来抽象，但拆开看，它直接决定了你在做架构选型时，是继续堆单体 Agent，还是转向分布式协作。

这篇文章我打算分上下两篇来写。上篇先把问题定义清楚：A2A 到底在解决什么，为什么现有的 Agent 编排方案在跨团队、跨进程、跨信任域的场景下会失效，以及架构选型时最容易被忽略的几个决策点。下篇再展开具体的协议设计、消息模型和落地实现。如果你正在做多 Agent 系统，或者正在纠结要不要引入 A2A，这篇内容应该能帮你把思路理清楚。

1. A2A 到底在解决什么问题

1.1 从单 Agent 到多 Agent 的必然性

先说一个我观察到的现象。大部分团队做 Agent 的路径都差不多：一开始做一个全能型 Agent，把工具调用、记忆、规划都塞进去；跑一段时间后发现，这个 Agent 越来越难维护，prompt 越写越长，工具描述互相冲突，不同业务线的需求根本没法在一个 Agent 里共存。于是开始拆，按业务域拆、按能力拆、按角色拆，拆着拆着就变成了多 Agent 系统。

这个演进过程本身是合理的，因为单 Agent 的能力边界受限于上下文窗口、工具数量和决策复杂度。但问题在于，很多团队拆完之后，用的还是“单体思维”——所有 Agent 跑在同一个进程里，共享同一份状态，通过函数调用直接通信。这种方案在早期确实够用，一旦涉及跨团队协作、跨进程部署、或者需要引入外部 Agent 服务，立刻就崩了。

A2A 要解决的第一个问题，就是让 Agent 之间的协作不再依赖共享内部状态。每个 Agent 有自己的记忆、自己的工具集、自己的决策逻辑，对外只暴露一个标准化的协作接口。这跟微服务架构的思路是一脉相承的，只不过服务换成了 Agent，REST 换成了更适合 Agent 交互的协议。

1.2 现有编排方案的三个硬伤

我梳理了一下目前常见的 Agent 编排方案，基本可以归为三类：基于工作流的编排、基于消息总线的编排、基于中心化调度器的编排。这三类方案在特定场景下都能用，但放到 A2A 的语境下，都有明显的硬伤。

第一类，工作流编排。典型做法是用 DAG 定义 Agent 之间的调用顺序，上游输出直接作为下游输入。这种方案的问题是静态。一旦业务逻辑变化，DAG 就要重画；而且它假设 Agent 之间的交互是确定性的，但实际场景里，Agent 经常需要多轮协商、动态选择协作对象，DAG 表达不了这种动态性。

第二类，消息总线。Agent 之间通过发布订阅通信，解耦做得不错，但语义太弱。一条消息发出去，谁处理、处理成什么样、失败了怎么办，总线本身不关心。对于需要强协作语义的场景，比如任务委派、能力协商、结果验证，消息总线只能提供传输层，上面的协作层还得自己搭。

第三类，中心化调度器。所有 Agent 注册到调度器，由调度器统一分配任务。这种方案在可控性上最好，但单点瓶颈和信任问题很突出。调度器挂了整个系统就挂了；而且当 Agent 分属不同团队或不同组织时，没人愿意把控制权交给一个中心调度器。

A2A 的思路是绕开这三类方案的局限，直接定义 Agent 之间的协作语义。它不关心你底层用什么传输，也不强制中心化还是去中心化，它关心的是：一个 Agent 如何描述自己的能力，如何发现其他 Agent，如何发起协作请求，如何处理协作结果。这些语义标准化之后，上面的编排逻辑就可以做得更灵活。

1.3 A2A 的核心抽象：Agent Card 与 Task

A2A 里有两个核心抽象，我觉得是理解整个体系的关键：Agent Card和Task。

Agent Card 可以理解为 Agent 的“能力名片”。它描述了这个 Agent 是谁、能做什么、接受什么样的输入、产出什么样的输出、支持哪些交互模式。这个东西的价值在于，它让 Agent 之间的发现和匹配变成了一个可计算的问题。以前你要让两个 Agent 协作，得在代码里硬编码调用关系；有了 Agent Card，你可以根据任务需求动态匹配能力。

Task 则是协作的基本单元。一个 Task 代表一次完整的协作请求，它有明确的生命周期：创建、协商、执行、完成或失败。Task 的设计里有个很重要的点，就是状态是显式的。发起方可以查询 Task 的状态，可以取消，可以在失败后重试。这比简单的请求-响应模型要丰富得多，也更贴近真实协作场景。

我自己的体会是，这两个抽象看起来简单，但它们把 Agent 协作从“函数调用”提升到了“协议交互”的层面。一旦到了协议层面，很多之前没法处理的问题，比如跨信任域协作、能力动态发现、协作过程可观测，就都有了统一的解法。

2. 架构选型前必须想清楚的几个问题

2.1 你的 Agent 是“工具”还是“协作者”

这个问题听起来有点哲学，但它直接决定了你的架构方向。如果你的 Agent 本质上是一个被调用的工具，输入输出确定，不需要协商，不需要多轮交互，那其实不需要 A2A，一个标准的函数调用接口就够了。A2A 的价值在于处理非确定性协作——Agent 之间需要协商、需要根据对方的能力调整自己的行为、需要在协作过程中动态决策。

我见过一些团队，明明场景很简单，非要上 A2A，结果复杂度上去了，收益没看到。也见过一些团队，场景明明需要协作语义，却硬用函数调用拼，最后维护成本爆炸。判断标准其实很简单：如果你的 Agent 之间需要“商量”，那就需要 A2A；如果只是“调用”，那就不需要。

2.2 信任边界在哪里

A2A 的设计里，信任边界是一个核心考量。同一个团队内部的 Agent 协作，和跨团队的 Agent 协作，和跨组织的 Agent 协作，信任模型完全不同。内部协作可以共享更多上下文，可以用更轻量的认证；跨组织协作就必须考虑身份验证、权限控制、数据隔离、审计日志。

架构选型时，我建议先画一张信任边界图：哪些 Agent 在同一个信任域内，哪些跨域，跨域的地方需要什么级别的安全保证。这张图会直接影响你选择什么样的传输层、什么样的认证机制、什么样的消息格式。很多团队上来就选协议，选完发现安全模型对不上，返工成本很高。

2.3 协作是同步还是异步

同步协作和异步协作对架构的要求差别很大。同步协作实现简单，但耦合度高，一方挂了另一方就阻塞；异步协作解耦好，但需要处理消息持久化、顺序保证、重复消费这些问题。

A2A 本身不强制同步或异步，但它的 Task 模型天然更适合异步。因为 Agent 的执行时间往往不可预测，有的任务几秒钟，有的可能几分钟甚至更长。同步等待在这种场景下不现实。我的建议是，默认按异步设计，在确实需要同步的地方再做同步封装。这样架构的扩展性会好很多。

2.4 状态放在哪里

多 Agent 协作里，状态管理是最容易出问题的地方。常见的做法有三种：状态集中在编排层、状态分散在各 Agent、状态放在独立的存储层。

集中式状态管理简单，但编排层容易变成瓶颈，而且当 Agent 分属不同团队时，集中管理状态不现实。分散式状态管理解耦好，但一致性难保证，调试也麻烦。独立存储层是折中方案，但引入了额外的依赖。

A2A 的 Task 模型其实给出了一种思路：协作状态和 Agent 内部状态分离。Task 的状态是协作层面的，由协作双方共同维护；Agent 的内部状态是私有的，不对外暴露。这样既保证了协作的可观测性，又保护了 Agent 的独立性。我觉得这个设计很关键，选型时值得重点考虑。

3. 从协作模式反推架构设计

3.1 三种典型协作模式

在实际项目里，我总结出三种最常见的 Agent 协作模式，每种对架构的要求都不一样。

第一种是委派模式。一个 Agent 把任务拆解后，委派给其他 Agent 执行，自己负责汇总结果。这种模式里，委派方需要知道被委派方的能力，被委派方需要能接受标准化的任务描述。架构上，重点是能力发现和任务描述标准化。

第二种是协商模式。多个 Agent 针对一个问题反复讨论，逐步收敛到方案。这种模式对消息顺序、上下文共享、冲突解决的要求很高。架构上，重点是消息模型和状态同步。

第三种是流水线模式。Agent 按顺序处理，上游输出是下游输入。这种模式最简单，但对异常处理要求高，因为一个环节失败会影响整条链路。架构上，重点是错误传播和重试机制。

A2A 对这三种模式都支持，但支持的方式不同。委派模式靠 Agent Card 做能力匹配，协商模式靠 Task 的多轮交互，流水线模式靠 Task 的链式组合。选型时，先确定你的主场景是哪种模式，再决定架构重点。

3.2 能力发现机制的设计取舍

能力发现是 A2A 里我觉得最容易被低估的部分。很多团队觉得，Agent 就那么几个，硬编码调用关系就行了，要什么发现机制。但一旦 Agent 数量上去，或者 Agent 是动态加入的，硬编码就不可维护了。

能力发现机制的设计有几个取舍点。一是发现的范围：是全局发现还是局部发现？全局发现需要注册中心，局部发现可以靠广播或点对点查询。二是发现的时机：是启动时一次性发现，还是每次协作前动态发现？前者性能好但灵活性差，后者灵活但有延迟。三是能力的描述粒度：描述得太粗，匹配不准；描述得太细，维护成本高。

我的经验是，从局部发现和动态发现开始，等规模上来了再考虑全局注册中心。因为早期 Agent 少，动态发现的开销可以接受，而且能避免过早引入注册中心的复杂度。等 Agent 数量超过一定阈值，再引入注册中心做优化。

3.3 消息模型：从请求-响应到事件流

消息模型的选择直接影响协作的灵活性和可观测性。最简单的模型是请求-响应，一问一答，实现简单，但表达不了多轮协商和异步通知。稍微复杂一点的是事件流，Agent 之间通过事件通信，灵活但需要处理事件顺序和幂等。

A2A 的 Task 模型其实介于两者之间。Task 本身是一个有状态的对象，可以查询、可以更新、可以取消。这比纯请求-响应丰富，又比纯事件流可控。我觉得这个设计很务实，既保留了异步协作的能力，又提供了足够的状态管理语义。

实际选型时，我建议以 Task 为核心，消息作为 Task 状态变更的载体。也就是说，Agent 之间传递的不是裸消息，而是 Task 的状态更新。这样消息模型和状态模型统一了，实现和调试都会简单很多。

4. 落地时最容易踩的坑

4.1 过度设计：把 A2A 当成万能方案

我见过最典型的坑，就是不管什么场景都上 A2A。结果一个简单的数据处理流程，被拆成五个 Agent，每个 Agent 之间还要走完整的 Task 生命周期，性能掉了一大截，复杂度上去了，收益没看到。

A2A 的适用场景是有明确边界的：需要跨信任域协作、需要动态能力匹配、需要多轮协商。如果你的场景不满足这些条件，用简单的函数调用或者工作流编排就够了。架构选型的第一原则是匹配场景，不是追新。

4.2 忽略协作的可观测性

多 Agent 协作比单 Agent 难调试，这是共识。但很多团队在架构设计时，没有把可观测性作为一等公民。等到线上出问题，发现根本不知道哪个 Agent 做了什么决策、消息在哪个环节丢了、Task 卡在哪个状态。

我的建议是，从第一天就把协作链路追踪做进去。每个 Task 有唯一 ID，每次状态变更都记录，Agent 之间的消息都带上下文。这些数据在调试时的价值，远超你为此付出的存储和性能成本。

4.3 状态一致性被低估

多 Agent 协作里，状态一致性是个大问题。比如一个 Task 被委派给 Agent B，Agent B 处理到一半，Agent A 又发了一个取消请求。这时候 Agent B 应该怎么处理？是立即停止，还是处理完当前步骤再停？如果 Agent B 已经产生了副作用，怎么回滚？

这些问题在单 Agent 场景里不存在，但在多 Agent 协作里是常态。A2A 的 Task 模型提供了状态机，但状态机的具体语义需要你自己定义。我的经验是，把状态转换规则写清楚，尤其是取消、超时、失败这些边界情况。这些规则不写清楚，线上一定会出问题。

4.4 安全模型后置

安全模型后置是另一个常见坑。很多团队先把协作跑通，再考虑安全，结果发现架构上根本加不进去。比如，一开始 Agent 之间直接传递上下文，后来要加权限控制，发现上下文里混了敏感信息，没法做细粒度控制。

正确的做法是，在架构设计阶段就把信任边界和安全模型定下来。哪些信息可以跨域传递，哪些必须脱敏，认证怎么做，授权怎么做，审计怎么做。这些定下来之后，再设计协作流程，会顺畅很多。

5. 架构选型的决策框架

5.1 一张表帮你判断要不要上 A2A

我把前面讨论的内容整理成一个决策表，你可以对照自己的场景快速判断。

这张表不是绝对的，但能帮你快速定位。如果大部分维度都落在左边，那 A2A 可能不是你的优先选项；如果多个维度落在右边，那值得认真考虑。

5.2 分阶段引入的路径

如果判断下来需要 A2A，我建议分阶段引入，不要一步到位。

第一阶段，先标准化 Agent 的能力描述。不管用不用 A2A，把每个 Agent 的能力、输入输出、交互模式定义清楚，这件事本身就有价值。定义清楚之后，你会发现很多协作问题在描述层面就解决了。

第二阶段，引入 Task 模型，把协作状态显式化。这一步的重点是让协作过程可观测、可控制。即使底层还是简单的调用，有了 Task 模型，调试和扩展都会容易很多。

第三阶段，引入能力发现和动态匹配。当 Agent 数量上来之后，硬编码调用关系不可维护，这时候引入发现机制。发现机制可以先做简单的，比如基于配置的静态发现，再逐步过渡到动态发现。

第四阶段，完善安全模型和可观测性。这一步是长期工作，但随着协作规模扩大，重要性会越来越高。

这个路径的好处是，每一步都有独立的价值，即使中途停下来，前面的投入也不会浪费。

5.3 技术选型的几个关键决策点

具体到技术选型，有几个决策点我觉得值得单独说。

传输层选什么。A2A 本身不绑定传输层，HTTP、消息队列、RPC 都可以。我的建议是优先选 HTTP，因为它的生态最成熟，调试工具最多。如果对性能有极高要求，再考虑其他传输方式。

消息格式选什么。JSON 是最稳妥的选择，可读性好，工具支持多。如果对性能敏感，可以考虑二进制格式，但会增加调试难度。我的经验是，除非有明确的性能瓶颈，否则 JSON 就够了。

状态存储选什么。如果 Task 数量不大，内存存储加持久化就够了。如果 Task 数量大，需要独立的存储层。选型时重点考虑查询能力和一致性保证，因为 Task 状态查询是高频操作。

认证机制选什么。内部协作可以用简单的 token，跨组织协作需要更标准的方案。我的建议是从一开始就用标准化的认证方案，哪怕初期用不上，因为后期迁移成本很高。

6. 一个简化的协作流程示例

6.1 场景描述

为了把前面的概念串起来，我设计一个简化的场景。假设有一个任务处理系统，包含三个 Agent：一个负责接收和拆解任务的协调 Agent，一个负责数据处理的执行 Agent，一个负责结果校验的验证 Agent。协调 Agent 收到任务后，拆解成子任务，委派给执行 Agent，执行完成后交给验证 Agent 校验，校验通过则返回结果。

这个场景里，协调 Agent 和执行 Agent 可能属于不同团队，信任边界不同；执行 Agent 可能有多个实例，需要动态选择；验证 Agent 的校验规则可能动态变化。这些特点让它适合用 A2A 的思路来设计。

6.2 协作流程拆解

整个流程可以拆成几个阶段。

第一阶段是能力发现。协调 Agent 启动时，通过发现机制获取可用的执行 Agent 和验证 Agent 列表，以及它们的能力描述。这个阶段的关键是能力描述的标准化，协调 Agent 需要能根据任务需求匹配到合适的执行 Agent。

第二阶段是任务创建。协调 Agent 创建一个 Task，包含任务描述、输入数据、期望输出格式。Task 创建后，状态是“待处理”。

第三阶段是任务委派。协调 Agent 根据能力匹配结果，选择执行 Agent，把 Task 委派过去。委派时，Task 状态变为“执行中”。执行 Agent 收到 Task 后，开始处理。

第四阶段是执行和状态更新。执行 Agent 处理过程中，定期更新 Task 状态，比如“处理中，已完成 50%”。协调 Agent 可以查询 Task 状态，了解进度。

第五阶段是结果校验。执行 Agent 完成后，Task 状态变为“待校验”。协调 Agent 把 Task 转给验证 Agent，验证 Agent 校验结果，更新 Task 状态为“校验通过”或“校验失败”。

第六阶段是结果返回。校验通过后，协调 Agent 把最终结果返回给调用方。如果校验失败，根据失败原因决定是重试还是返回错误。

6.3 关键实现细节

这个流程里，有几个实现细节值得注意。

Task ID 的生成和管理。每个 Task 需要全局唯一 ID，方便跨 Agent 追踪。ID 生成可以用 UUID，也可以用带业务含义的编码。我倾向于用 UUID，简单且不会冲突。

状态转换的原子性。Task 状态变更需要保证原子性，避免并发更新导致状态不一致。可以用乐观锁或者版本号机制。

超时和重试。每个阶段都需要设置超时，超时后触发重试或失败处理。重试需要幂等，避免重复执行产生副作用。

错误传播。执行 Agent 失败时，错误信息需要完整传递回协调 Agent，包括失败原因、失败阶段、是否可重试。这些信息决定了后续的处理策略。

6.4 这个示例的局限

需要说明的是，这个示例是简化过的，实际场景会复杂得多。比如，执行 Agent 可能需要和协调 Agent 多轮协商才能确定处理方案；验证 Agent 的校验规则可能需要动态加载；Task 可能需要支持暂停和恢复。这些复杂性在真实项目里都会遇到，但核心思路是一样的：用标准化的协作抽象，把复杂性收敛到可控的范围内。

7. 上篇小结与下篇预告

写到这里，上篇的核心内容基本讲完了。回顾一下，A2A 要解决的核心问题是多 Agent 之间的可信、可组合、可演进协作，它的关键抽象是 Agent Card 和 Task，架构选型时需要重点考虑信任边界、协作模式、状态管理和可观测性。

我自己的体会是，A2A 不是一个具体的技术方案，而是一种架构思路。它不强制你用某种协议、某种传输、某种存储，它提供的是协作的语义框架。理解了这个框架，具体技术选型就是水到渠成的事。

下篇我会展开讲协议设计的具体细节，包括 Agent Card 的字段设计、Task 的状态机定义、消息格式的规范、以及一个完整的实现示例。如果你在上篇里对某个点特别感兴趣，或者有自己的实践经验想交流，欢迎一起讨论。架构选型这件事，没有标准答案，只有适合场景的答案。