多 Agent 系统如何分工通信与隔离会话

把合同审查拆给两个 AI 专家，难点往往在模型之外：任务耗时太长怎么办，用户中途取消怎么办，各团队独立发布后如何找到彼此？作者用 AgentCore 把编排器、两个专家和一个计费工具服务接起来，再补上可检索的能力目录。

这组实验的价值，是把调用、异步、隔离、部署和治理放进同一条链路验证。不过，跑通一次与证明生产可用之间，还有几处需要分清。

两个专家独立发布，编排器怎么找到它们

场景来自 Northwind Gear 的合同审查：法务专家逐条比对标准条款，合规专家筛查违反政策的内容。两个团队不愿共用 prompt、模型版本和发布节奏，因此各自提供服务，由编排器分派任务。

四个 Runtime 的协议分工很明确：

• 编排器对调用方提供 AG-UI，通过服务端事件流（SSE）发送 RunStarted、文本片段和 RunFinished。
• 法务与合规专家提供 A2A 接口，通过 StrandsA2AExecutor 包装，并由 serve_a2a 在端口 9000 提供服务。
• 计费服务使用 FastMCP 和 streamable-http，暴露三个工具，通过 tools/call 调用，不使用模型。

编排器也没有模型，它只是按意图确定调用哪个专家。

这个设计让实验集中测协议连接，不能据此评价模型自主规划能力。专家侧需要 Bedrock 的 deepseek.v3.2，但入口路由不依赖它。

运行时发现分两步：先用 ListAgentRuntimes 列出服务，再用 GetAgentCard 获取能力说明。部署会添加项目前缀，例如 aiauc07_aia_uc07_legal，作者因此按名称后缀匹配。编排器角色还需通过 additionalPolicies 获得 bedrock-agentcore:ListAgentRuntimes 和 bedrock-agentcore:GetAgentCard 权限，A2A 请求使用 SigV4 签名。

Agent Card 标明 protocolVersion 0.3.0、preferredTransport JSONRPC 和 streaming true。可以把它理解为服务自带的能力说明书。

作者测到，一次合同审查请求让两个专家分别完成 A2A 任务，总耗时 95.0 秒。它证明了调用链成立，没有提供合同判断准确率。

长任务不能只靠延长 HTTP 超时

A2A 的三种调用方式，对应三种交互需求。

较快的审查使用阻塞式 message/send；深度扫描使用 blocking: false，先返回状态为 submitted 的任务，再通过 tasks/get 轮询；需要中途打断时，用 message/stream 接收状态，并发送 tasks/cancel。

作者把深度扫描描述为五轮、预设 75 秒的工作，实际完成耗时为 115.0 秒，接收任务耗时为 0.0 秒。两者差值如何构成，原文没有拆解。

下面这段命令验证阻塞调用的客户端超时行为：

aws bedrock-agentcore invoke-agent-runtime --region us-east-1 \
  --agent-runtime-arn arn:aws:bedrock-agentcore:us-east-1:123456789012:runtime/aiauc07_aia_uc07_compliance-dc8CMTCDwj \
  --qualifier DEFAULT --runtime-session-id uc07-timeout-<uuid> \
  --content-type application/json --accept application/json \
  --cli-read-timeout 60 --payload fileb:///tmp/uc07-a2a-payload.json /tmp/uc07-a2a-out.bin

要看的是 --cli-read-timeout 60：命令经过三个 SDK 重试窗口，最终在 184.9 秒报 ReadTimeoutError；改成 30 秒后，总耗时仍有 93.1 秒。单次读取超时，并不等于整次调用耗时。

原文把 115 秒称为超过同步上限，但这些证据直接证明的是客户端超时，不能据此认定服务端存在统一的 60s 上限。

取消实验则在 11.9 秒收到 working 更新，随后发出取消，12.1 秒时流以 canceled 结束。这里有一个前提：Strands executor 配合取消。界面关闭 SSE 连接，并不能自动证明后台任务停止。

长任务需要可查询、可取消的任务状态，连接本身承担不了全部生命周期。

运行时能隔离会话，目录还得单独治理

会话 ID 通过 X-Amzn-Bedrock-AgentCore-Runtime-Session-Id 传递，要求至少 33 个字符。作者介绍，不同 ID 对应不同 microVM，实验状态只存在进程内的普通 dict 中。

他们用十个会话分别存取十个暗号，二十次调用耗时 88.3 秒，全部正确，没有串话。这是有用的边界验证，但没有验证进程重启后的持久化。

计费 Runtime 还绑定了自管计算资源：capacity provider 使用 LINUX_ARM64，实例池包含 m7g.large、c7g.large，空闲超时 300 秒。lookup_invoice 返回 INV-2041 的发票，金额为 12800 美元、状态为 open；刚重新部署后的这次调用耗时 72.5 秒，不能当作稳定延迟。

部署前提包括 Node.js 20 或更新版本、AgentCore CLI 0.31.1、AWS CLI 2.x、已安装依赖的 agentcore/cdk/，以及默认 VPC。全部测量发生在一个账号的 us-east-1。四个 Runtime 和资源池通过 agentcore deploy -y --target default 部署，再用 agentcore status 检查。

能力目录 Agent Registry 则属于独立控制面，没有纳入这份 CLI 配置。作者另外创建了两条记录：计费 MCP 和法务 Agent。前者使用 2025-12-11 descriptor schema，后者携带完整 A2A Card，descriptor schema 为 0.3，服务版本均为 1.0.0。

记录要经过 CREATING → DRAFT → PENDING_APPROVAL → APPROVED 才能被搜索，直接从 DRAFT 改为 APPROVED 会被拒绝。

下面这条查询用于按需求发现能力：

aws agent-registry search-discoverable-registry-records --region us-east-1 \
  --registry-id niFvetsCk7ujKrAO --search-query "payment processing"

关键是 --search-query：查询没有使用记录名 billing，却把它排在首位。不过，描述字段里本来就有 payment processing，这个结果不足以证明它比关键词搜索更好。

目录通过 RAM 共享，资源类型为 agent-registry:Registry。原文展示了共享状态 ACTIVE，但没有展示另一个账号实际搜索的完整结果。

我的判断

我认可这套拆分：AG-UI 管用户交互，A2A 管专家任务，MCP 管工具，Registry 管能力目录。比把所有逻辑塞进一个 prompt，它更适合确实需要独立发布的团队。

代价也很具体：IAM、签名、协议适配、任务状态和目录审批都要维护。若只是一个团队串联几个固定步骤，普通函数调用或任务队列可能更直接。作者没有给出成本、吞吐、维护工时或替代方案的对照数据，架构取舍仍是经验之谈。

另外，编排器发现专家实际走的是 ListAgentRuntimes 和 GetAgentCard，并未展示通过 Registry 动态选择专家。目录检索与业务编排目前是两条分别验证的链路。

清理边界同样容易遗漏。agentcore remove all -y 后还要执行部署才能删除栈，而且会清空 agentcore/agentcore.json 与 agentcore/aws-targets.json；Registry 和 RAM 则需另行删除，顺序是共享、记录、目录。标签查询出现的 22 条记录中，只有 17 个是本用例存活资源，另有三个已删共享和两个旧资源的残留标签，不能把标签列表直接当成存活清单。

能拿来做什么

• 前端接入长任务时，把任务 ID、运行状态、最终结果与 SSE 连接分别管理，并验证取消操作能到达后台执行器。
• Node 编排服务可以先用确定性路由接通发现、鉴权和任务调用，再判断是否需要模型参与选路。
• 做会话隔离验证时，可以照搬不同会话分别写入、读回暗号的方法，再补充重启与失效测试。
• 多团队建设能力目录时，同时设计审批、描述维护和删除流程，并从接收共享的账号实际检索，补齐跨账号验证。