1. 多 Agent 团队的真实困境能力散落没人说得清团队里 Agent 一多最先崩掉的不是模型效果而是「资产台账」。上个月我帮一个做智能客服的团队梳理现状他们内部跑着 7 个 Agent、11 个 MCP Server结果问「谁负责发邮件那个工具」三个人给了三个答案。有人说是客服组写的有人说是数据组接的第三方还有人翻出半年前的 wiki 说早就废弃了。最后发现那个邮件 Agent 还在被两个线上流程调用只是没人记得它的存在。这就是 AWS Agent Registry 想解决的问题。它是挂在 Bedrock AgentCore 下面的一个私有目录服务你可以把 Agent、工具、Skill、MCP Server 统一登记进去每条记录带描述、连接信息和工具 schema。团队里谁想找某个能力搜一下就行不用翻代码、不用问人、不用猜。它支持关键词搜索和语义搜索两种方式语义搜索允许你用自然语言描述需求比如「我要一个能从合同 PDF 里抽条款的工具」它能匹配到注册过的对应记录。适合谁用如果你的团队已经跑了 5 个以上的 Agent 或 MCP Server或者你正在做多 Agent 协作、需要统一收敛治理入口这套东西值得花半天跑通。本文会交付可复制的注册配置骨架、TaoToken 统一 Key/API 通道的接入示例以及注册、发现、调用的完整验证动作。我实测下来注册一两条记录跑通搜索半小时够了真正花时间的是后面制定命名规范和审批流程。2. 前置准备Registry 建在哪、Key 怎么统一管Agent Registry 目前是 Preview 版只开在 5 个 Regionus-east-1、us-west-2、ap-northeast-1东京、ap-southeast-2悉尼、eu-west-1爱尔兰。你的 Agent 如果跑在新加坡或者其他没覆盖的区域只能就近连东京跨 Region 延迟会多几十毫秒功能不受影响但体感慢一拍。创建 Registry 之前要先想清楚认证方式因为建好之后不能改。IAM 认证适合内部团队JWT 认证适合对外开放或跨组织场景。我第一次建了 IAM 的后来想换 JWT发现改不了只能删了重建白折腾一轮。生产环境建议关掉 Auto-approval让记录走审批Preview 阶段开着省事提交即生效。另一个前置是统一 Key 通道。多 Agent 场景下最烦的是每个 Agent 各配一套模型 Key轮换时到处改。我习惯用 TaoToken 做统一入口一个 Key 覆盖多个模型通道Agent 侧只认一个 base_url 和 api_key换模型不用动 Agent 代码。官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 注意 API 地址不带 UTM 参数。先把 Key 拿到手后面注册 Agent 记录时把 endpoint 指向这个统一通道治理入口和调用入口就都收敛了。3. 可复制配置从建 Registry 到注册 MCP Server3.1 创建 RegistryCLI 与 Python SDK 双写法CLI 方式最直接跑完返回一个 registryArn状态从 CREATING 变 READY 大概 1 到 2 分钟aws bedrock-agentcore-control create-registry \ --name my-agent-registry \ --description 团队Agent注册中心 \ --region us-east-1Python SDK 写法适合塞进自动化脚本import boto3 client boto3.client(bedrock-agentcore-control, region_nameus-east-1) response client.create_registry( namemy-agent-registry, description团队Agent注册中心 ) print(fRegistry ARN: {response[registryArn]}) print(fStatus: {response[status]})注意文档里部分 Python SDK 示例的参数名和实际 API 对不上我碰到两处。跑之前先用aws bedrock-agentcore-control create-registry help确认参数别直接抄文档。3.2 注册一个 MCP Server 记录以一个 PDF 解析 MCP Server 为例CLI 注册如下aws bedrock-agentcore-control create-registry-record \ --registry-name my-agent-registry \ --record-name data-pdf-parser-v1 \ --record-type MCP_SERVER \ --description 从PDF文件中提取文字和表格数据 \ --metadata {endpoint: https://mcp.example.com/pdf-parser} \ --region us-east-1如果 MCP Server 已经在线且公网可达可以用 URL-based discoveryRegistry 会自动去拉工具定义和 schema省得手动填。我有个 Server 在 VPC 内网Registry 死活拉不到 metadata后来配了 PrivateLink 才通。内网 Server 提前准备。记录 name 是永久的建好不能改想改名只能删除重建。命名建议用team-function-version格式比如data-pdf-parser-v1别用test1、new这种三个月后你自己都不认识。3.3 注册一个 Agent 记录并指向统一 Key 通道Agent 记录的 metadata 里放模型调用信息把 endpoint 指向 TaoToken 统一通道aws bedrock-agentcore-control create-registry-record \ --registry-name my-agent-registry \ --record-name cs-email-agent-v1 \ --record-type AGENT \ --description 客服邮件发送Agent支持模板渲染和附件 \ --metadata {endpoint: https://taotoken.net/api, model: claude-sonnet, owner: cs-team} \ --region us-east-1这样注册中心里既能看到 Agent 的能力描述也能看到它走哪个通道调模型。换模型时只改 metadata 里的 model 字段Agent 代码不动。3.4 关闭 Auto-approval 时的审批动作生产环境关了 Auto-approval记录提交后是 Pending 状态管理员批准后才可见aws bedrock-agentcore-control approve-registry-record \ --registry-name my-agent-registry \ --record-name data-pdf-parser-v1 \ --region us-east-14. 验证请求搜索、发现、调用三步跑通4.1 关键词搜索注册几条记录后先跑关键词搜索确认记录生效aws bedrock-agentcore-control search-registry \ --registry-name my-agent-registry \ --query PDF \ --region us-east-1返回结果里应该能看到data-pdf-parser-v1的 name、type、description 和状态。如果返回空先检查记录是不是还在 Pending。4.2 语义搜索语义搜索不要求关键词精确匹配描述需求就行aws bedrock-agentcore-control search-registry \ --registry-name my-agent-registry \ --query 我需要一个能从文档里提取结构化数据的工具 \ --search-type SEMANTIC \ --region us-east-1实测下来语义搜索的中文效果不如英文。同一个需求英文 query 命中 3 条中文只命中 1 条。如果搜中文没结果先换英文试试别急着怀疑记录没注册上。4.3 把 Registry 当 MCP Server 接进 IDEAgent Registry 本身暴露了 MCP Server 接口你可以在 Claude Code 或 Cursor 的 MCP 配置里把它接进来让 AI 助手在编码时直接查注册中心有什么可用{ mcpServers: { agent-registry: { command: aws, args: [ bedrock-agentcore-control, start-mcp-server, --registry-name, my-agent-registry, --region, us-east-1 ] } } }配好之后你在编码时问「有没有现成的 PDF 解析工具」AI 助手会自动搜注册中心并返回匹配记录。这比纯 Web 管理界面实用Agent 可以在运行时自己搜自己接不需要人工去控制台配「这个 Agent 可以调那个工具」。4.4 调用验证找到记录后用返回的 endpoint 发一次真实请求。如果 Agent 走 TaoToken 通道验证时确认 base_url 是https://taotoken.net/apiapi_key 用统一 Key。调用成功返回正常响应说明注册、发现、调用整条链路通了。5. 本篇常见错排查认证方式建好不能改。IAM 和 JWT 二选一建之前想清楚。我第一次建了 IAM 想换 JWT只能删了重建Registry 里已有的记录也一起没了。Region 只有 5 个。Agent 跑在 ap-southeast-1 的话只能连 ap-northeast-1跨 Region 延迟多几十毫秒。不影响功能但体感慢一拍对延迟敏感的流程要提前评估。语义搜索中文命中率低。中文 query 命中少时先换英文这是目前 Preview 版的已知表现不是你的配置问题。URL-based discovery 要求公网可达。VPC 内网的 MCP Server 拉不到 metadata需要配 PrivateLink。内网 Server 提前准备别等到注册时才发现。记录 name 永久不可改。命名用team-function-version格式别用临时名。想改名只能删除重建重建后引用它的地方都要跟着改。Python SDK 参数名对不上。文档示例和实际 API 有出入跑之前用 CLI help 确认参数别直接抄文档。Auto-approval 关了但忘了审批。记录一直是 Pending搜索搜不到容易误判成注册失败。先查状态再排查其他。6. 把治理入口收敛到一处Agent Registry 解决的问题很具体Agent 多了之后找不到、管不住。我们团队有个客户信息查询 Agent另一个组不知道自己又写了一个注册到 Registry 之后第二个组开工前搜了一下发现已经有了直接接入省了两周工作量。另一个价值是审计每条记录的访问在 CloudTrail 里有日志谁搜了什么、谁调了哪个 Agent 都有迹可查。如果你要把这套跑起来下一步动作很明确先拿统一 Key再建 Registry然后注册第一条 MCP Server 记录跑通搜索。Key 在 https://taotoken.net/api-keys 拿接入文档在 https://taotoken.net/doc 模型对话验证在 https://taotoken.net/chat 长期编码和 Agent 场景可以看 https://taotoken.net/coding-plan 。注册中心建好后把现有 Agent 一个个登记进去制定命名规范、设计审批流程这些工程实践得自己摸。工具给你了台账得自己建。