AWS Agent Registry 运行时 MCP/A2A 工具发现
Hardcoded tool wiring breaks down as an agent's catalog grows from a handful of tools to hundreds. This post walks through a runtime Discover, Instantiate, Execute loop built on AW
本文は SEO 深度のため主に中国語です。上記は要点のローカライズ。言語切替と深リンクで国際ナビできます。
AWS Agent Registry 运行时 MCP/A2A 工具发现
AWS Agent Registry 让 AI 代理能在运行时动态搜索并实例化工具和服务，无需硬编码固定列表。这特别适合 GrokCode API 中转场景：当工具数量从几百增加到数千时，静态绑定容易卡住，运行时发现能让模型天梯和本地部署的代理保持灵活。
GrokCode 作为 API 中转平台，建议在编码模型中转与编程场景中采用此方式。它让 orchestrator 在查询用户意图后，通过 semantic search 找到匹配的 MCP 服务器或 A2A 代理，再实时构建客户端执行。
这种设计避免了每次新能力上线都需代码变更和部署的问题，特别适用于需要集成数百个内部 API 的企业 SaaS 系统。
为什么硬编码绑定会失效
当代理目录从少数工具扩展到数十甚至数百个时，静态 wiring 会出现问题。模型在调用工具时要花费更多 Token 解析名称，而非真正理解用户请求。每新增一个能力，都需要修改 orchestrator 代码、重新部署，并协调团队发布节奏。
这在企业级应用中很常见：定价、支持、订单、库存等内部 API 暴露给代理后，构建时 wiring 就成了瓶颈。GrokCode 编码模型中转通过运行时机制解决了这一痛点，让代理能按需发现新集成。
AWS Agent Registry 的核心机制
AWS Agent Registry 是 Amazon Bedrock AgentCore 提供的托管服务，用于编录和发现 Model Context Protocol (MCP) 服务器、代理以及代理技能。发布者注册协议特定描述符和可搜索描述。运行时，orchestrator 可通过语义搜索批准的记录，并使用返回的端点和描述符内容构建客户端。
Registry 搜索结果不包含调用凭证或认证方案，必须通过单独可信路径获取。GrokCode 在 API 中转中可直接调用此机制，实现工具的动态发现。
官方文档参考：
运行时发现-实例化-执行循环
AWS Agent Registry 示例演示了 Discover（发现）→ Instantiate（实例化）→ Execute（执行）的完整循环。以下是核心流程：
- Discover：orchestrator 向 Registry 发送自然语言查询，获取记录身份、名称、描述、类型、状态、版本以及 MCP 或 A2A 描述符。结果不包含凭证。
- Instantiate：根据记录类型构造客户端。MCP 描述符指向 Amazon Bedrock AgentCore Gateway 端点；A2A 记录则通过 boto3 data-plane 客户端调用 runtime 端点。认证需单独处理。
- Execute：为每个请求构建临时 inner agent，仅包含发现的工具。LLM 选择合适工具后合成结果返回。请求结束后清理资源，下一轮重新搜索。
此架构参考自 AWS 官方样例，适用于 MCP-only、MCP+A2A 链式调用以及纯语义匹配场景（如“return and refund”）。
实际示例：Python 样例循环解析
以 AWS Agent Registry 示例代码为基础，我们可将其适配至 GrokCode API 中转环境。核心 orchestrator_agent.py 包含每请求的发现循环，utils.py 负责解析描述符并创建 MCP/A2A 客户端。
典型代码片段（简化）：
```python
Discover
response = dp_client.search_discoverable_registry_records( query="order management tools", registryId=REGISTRY_ID )
Instantiate
for record in response["records"]: if record["recordType"] == "MCP": client = MCPClient(gateway_endpoint, token=fetch_cognito_token) # A2A case via boto3
Execute
inner_agent = create_ephemeral_agent_with(record["tools"]) result = inner_agent.invoke(user_query) ```
通过此循环，代理可动态扩展，无需静态维护工具列表。GrokCode 可在 /api-transit 页面进一步查看类似中转实践。
对比硬编码 vs 运行时发现
| 维度 | 硬编码绑定 | AWS Agent Registry 运行时发现 |
|---|---|---|
| 工具数量 | 难以扩展至数百 | 动态搜索，轻松支持千级目录 |
| 更新成本 | 需代码变更+重新部署 | 注册后立即可用，无重部署 |
| Token 效率 | 模型耗费 Token 解析名称 | 聚焦意图推理 |
| 集成灵活性 | 静态限制 | 支持 MCP + A2A 混合场景 |
| 安全机制 | 凭证需硬编码 | 注册时分离，运行时动态加载 |
此对比表基于 AWS 官方架构设计。GrokCode 在 /api-lab 工具页可参考类似动态注册场景。
部署与集成建议
- 在 Amazon Bedrock AgentCore 控制台创建 Registry，配置语义搜索。
- 发布 MCP 服务器或 A2A 代理记录（含描述符和工具定义）。
- orchestrator 通过 boto3 或 SDK 调用 discovery 接口。
- 集成 GrokCode 中转层，处理认证和执行。
完整参考样例已在 AWS GitHub 上线：
风险与边界
此机制依赖 AWS 平台可用性与配置正确性。认证处理不当可能暴露凭证；语义搜索质量取决于描述词；高频调用可能增加 VPC 和 Lambda 成本。GrokCode 建议在生产前通过测试环境验证循环稳定性，并避免直接处理敏感用户数据。
此内容非法律意见，仅供参考。
延伸阅读
English summary
AWS Agent Registry enables AI agents to discover and instantiate tools and services at runtime using semantic search on MCP servers and A2A agents. This eliminates hardcoded tool wiring that breaks down as catalogs grow from dozens to hundreds of capabilities. GrokCode recommends integrating this pattern in its API transit and coding model scenarios for scalable orchestration.
The process follows a Discover-Instantiate-Execute loop: query the Registry for records, build clients dynamically with separate authentication, and execute via ephemeral inner agents. Official AWS samples demonstrate MCP-only calls, chained MCP+A2A flows, and ambiguous intent matching.
Compared to static binding, runtime discovery reduces token waste on name resolution, speeds up updates, and maintains flexibility for enterprise SaaS integrations. GrokCode users can adapt the Python orchestrator pattern directly, pairing it with their /api-transit and /api-lab resources for end-to-end testing.
延伸阅读
适用于 GrokCode 倍率榜。信息仅供参考，不构成购买、投资或法律意见。