A2A

独立的 AI 智能体如何协同工作：面向 Hermes Agent 的 A2A 桥接

作者：IdeaBosque最后更新：2026年7月24日

这对你的业务意味着什么

你的智能体无需重写即可协同。 Agent2Agent Protocol（A2A）是一个开放标准，让 AI 智能体彼此发现、相互委派工作并流式返回结果。一层轻薄的桥接让现有智能体在不改动其内部的情况下讲这套标准语言——你保住了已有的投入。
没有供应商锁定。 由于桥接位于标准与智能体之间，你日后可以更换底层的智能体框架，而不会破坏建立在其上的集成。其他团队仍然调用同一个标准端点。
一套系统服务众多客户或业务单元——且数据严格隔离。 租户隔离在数据库层面强制执行，而非仅在应用代码中，因此一个编码错误无法把一个客户的数据泄露给另一个。这正是能通过安全审计的关键差别。
人类始终掌控敏感操作。 当智能体需要批准时——一次采购、一项数据访问决定、一份报价审批——该请求会以标准的“等待审批”状态出现，并一路回传给发起该链条的人或智能体，即便跨越框架边界也是如此。
它是真实且经过测试的，不是一张幻灯片。 整套内容打包为一个开源部署（docker-a2a-hermes-agent-gateway），并配有自动化测试套件，在你依赖每项能力之前先加以验证。

问题所在：无法彼此对话的智能体

多数组织并非采用“一个 AI 智能体”，而是逐步累积出好几个。这里一个报价智能体，那里一个目录查询智能体，还有一个归属于另一团队的库存智能体——常常基于不同框架，有时来自不同供应商，在不同时期构建。单独看它们都能工作，瓶颈在于让它们协同：把工作交给另一个、等待结果、再交还控制权。

用手工方式把每个智能体与其他所有智能体逐一连线来解决，既缓慢又脆弱，而且每新增一个智能体就更糟。它还会悄悄造成锁定：一旦集成被硬编码到某一供应商的接口，更换该供应商就意味着全部重做。

**Agent2Agent Protocol（A2A）**就是消除这一瓶颈的开放标准。它定义了一套共同语言，让智能体彼此发现、委派任务、流式传输进度并报告完成，无论各自基于什么构建。采用一次标准，此后每个新智能体都与其余智能体讲同一种语言。

难点在于：你现有的智能体并不原生讲 A2A。以 Nous Research 的 Hermes Agent 为例，它暴露的是自有接口。为了新增一个协议而重写一个能正常工作的智能体，恰恰是团队想要避免的那种昂贵且高风险的项目。

答案是一层桥接——一个小小的翻译层，对外讲 A2A，对内用智能体自己的语言与之交流。智能体本身从不改变。docker-a2a-hermes-agent-gateway 项目正是这层桥接的一个可运行的开源示例，打包为单一可部署单元。

各部分如何组合

一共有三个活动部件，而只有其中一个会暴露给外部世界：

前门（网关）。 一切都通过单一的受控入口进入。它决定谁可以进入、一个请求属于哪个客户、调用方可以多快、以及如何流式返回实时进度。其他一切都无法直接访问。
翻译器（桥接）。 它以开放的 A2A 标准接收请求，转换为你的智能体真正能理解的形式，再把答复转换回来。这是唯一了解具体智能体的部件，也正因如此，智能体日后才可被替换。
智能体及其工作记录。 你现有的智能体负责真正的推理。它所做的一切都被记录下来——每个任务、每条消息——并按客户严格隔离。

由于前门与记录都独立于智能体本身，你可以把网关保留在自己的云内，并让它指向运行于别处的智能体，或指向你所选的托管数据库。没有任何东西强制这三者置于同一处。

无需重写智能体即可采用标准

这里最有价值的特性是你的智能体从不改变。 翻译器代替它完成讲标准语言的全部工作。

这带来两点直接的业务影响：

保护你已有的投入。 构建报价智能体的团队不必停下来为一个新协议重新改造它，只需加上一层桥接便可继续前行。
双向避免锁定。 调用方只依赖开放标准，而非你的智能体供应商。若你日后更换智能体——更好的模型、更便宜的供应商、自研实现——只需更换翻译器，建立在其上的所有集成都无需改动即可继续运行。反过来，一个网关可以同时面向多个不同智能体：推理密集的工作路由到一个，日常流程步骤路由到另一个，而在调用方看来它们完全一致。引擎的选择成为你可掌控的实现细节，而非把你套牢的承诺。

服务众多客户或业务单元——数据隔离经得起审计

同一套部署可以从单一运行系统服务众多租户——不同客户，或不同的内部业务单元。每一方都拥有各自的智能体、各自的任务历史与各自的消息存储。

让这一切安全而不仅仅便利的，是隔离在何处强制执行。每个请求都被标记它所属的客户，而数据库本身拒绝把一个客户的记录返回给另一个——这一控制施加在数据层，位于应用代码之下。实际上这意味着软件中的一个缺陷或一处遗漏的过滤条件无法跨客户泄露数据，因为兜底的是数据库，而非应用。这正是安全或合规审查者所寻找的区别，也让你能够把多个客户放在共享基础设施上而不危及其数据。

让人类掌控敏感操作

只有当人可以在关键时刻介入时，自治才是可接受的。当智能体到达一个需要签核的步骤——授权一次采购、批准一份报价、放行敏感数据——它不会径自继续，而是暂停并抛出一个标准的“等待审批”状态。

关键在于该状态会传递。一个在若干智能体之前发起的请求——可能位于完全不同的框架、归属于另一团队——会收到同样的、未经改动的“需要输入”信号。人做出批准（或拒绝），工作随之恢复。治理不会止步于单个智能体的边界；开放标准把审批关卡贯穿整条链条。对于任何涉及资金、合同或受监管数据的工作流，这种端到端的控制正是让智能体委派站得住脚而非鲁莽的原因。

在数据必须驻留之处运行

该部署是一个单一、自包含的软件包，既可捆绑运行——智能体、数据库与网关一体——以便快速起步，也可拆分以用于生产。你可以把受控前门保留在自己的网络内，并让它指向一个托管数据库（这样备份、加密与合规由你的云服务商处理），以及一个运行于独立硬件上的智能体。

对于有数据驻留或主权要求的企业，这一点很重要：每一次智能体交互的记录都可以保留在你的政策所要求的边界之内，而非放在你无法掌控的第三方云中。

在你依赖之前先经验证

一项你无法验证的能力就是一项负担。该部署附带一套自动化测试套件，端到端地演练真实运行中的系统——确认智能体可被发现、请求能够完成、实时进度能够正确流式传输、错过一次实时更新的客户仍能取回完整结果，以及故障与取消是否按预期表现。测试对每一项检查给出明确的通过或失败结果，并被设计为可作为自动化关卡运行，从而使有缺陷的变更在抵达生产之前被拦截，而非之后。

其现实价值在于降低风险：你不必听信任何人说集成能用。它会在每次变更时被可重复地加以证明。

在生产中运行它究竟需要什么

对运营成本坦诚以待，是商业论证的一部分。有几点现实值得规划：

它被设计为先轻量运行，再有意识地扩展。 默认是单一、简单的部署。以多副本服务极高流量是受支持的，但那是一个有意为之的步骤，而非偶然：它需要共享基础设施以使各副本保持一致。请规划扩容，别以为它是免费的。
保持更新是例行事务，而非重写。 各构建块从其开源来源拉取，因此保持最新是你的团队按计划执行的一项标准更新操作。
安全姿态由你设定。 该软件包附带占位密码与宽松的默认值，以便开箱即用地轻松起步——它们本就是要在面向互联网之前替换掉的。可选的内置智能体功能强大，只应运行在你信任的基础设施上。这些都不稀奇；它们是任何生产系统都需要的常规加固，理应列入上线检查清单。

这些都不是拦路石。它们是运行一个真实系统的日常职责，而提前把它们说清楚，正是避免上线后意外的方式。

这带来了什么

综合起来，桥接模式带来三样凭一己之力确实难以拼装的东西：

1. 基于标准的协同，无需重写。 任何讲 A2A 的智能体都能立即与你现有的智能体协作——发现它、向它委派、跟踪其进度——而无需改动那个智能体。你在保留既有可用之物的同时采用了一个开放标准。

2. 具备真正隔离的多租户服务。 单一部署服务众多客户或业务单元，数据隔离在数据库层面强制执行。这正是让你能够在不削弱安全的前提下向共享基础设施整合的原因。

3. 跨边界的受治理自治。 人工审批关卡随工作一同传递，因此无论请求经过多少智能体——或多少框架——敏感操作都会有人参与其中。

该功能实现为开源且文档完备：桥接及其集成指南位于 a2a_daemon_engine 代码库（参见 Hermes 集成指南），受控前门的文档见 SilvaEngine Gateway 代码库。完整部署打包于 docker-a2a-hermes-agent-gateway。