AWS Agent Registry 运行时发现将工具接线移出构建流程

AWS 于 10 月 20 日详细介绍了 AWS Agent Registry 运行时发现，展示了一种无需将每项能力硬编码到智能体中的替代方案。该方法将工具选择移至正在运行的应用中，由编排器——即协调请求的智能体——在选择连接前搜索目录。这一转变挑战了一种许多团队在工具目录开始跨部门扩展前都能轻松维护的架构。

核心竞争在于构建时接线与运行时选择。构建时接线让开发者拥有一份明确的可用能力清单。运行时选择则让这份清单能够独立变化，但也使搜索结果成为应用行为的一部分。问题随之变为：在允许能力在编排器发布周期之外演进的同时，团队能否保持执行的可预测性。

Anthropic 也曾推动按需加载工具，这让 AWS 的案例拥有了可识别的行业参照。AWS 将讨论带入企业目录管理领域，在这里，审批、归属、连接详情和访问规则与模型上下文同样重要。对开发者和企业采购方而言，重要变化在于组织层面：工具的可用性可能取决于目录治理，而不是又一次应用部署。

AWS Agent Registry 运行时发现改变了连接的选择时机

这份运行时发现演练展示了一个“发现、实例化、执行”的循环。其示例连接了订单管理服务器，以及定价和客户支持智能体。这些属于演示场景，而非来自经过独立评估的企业部署的证据。

该示例使用了 MCP，即模型上下文协议（Model Context Protocol），它标准化了应用如何向 AI 系统暴露工具和上下文。它还使用了 A2A，即智能体间通信协议。这两者被纳入同一个发现循环，使该示例的意义不止于单个功能的目录。

架构上的变化在于，编排器在收到请求后选择连接，而不是在构建过程中携带每一项连接。

这一差异值得获得比“发现”一词本身更多的关注。供开发者查阅的目录帮助人们在实施阶段选择集成。供执行时查阅的目录则有助于决定应用能够针对特定请求使用哪些集成。

这改变了新增能力的含义。在显式接线模式下，开发者通常在发布编排器之前决定集成应置于何处。在运行时选择模式下，兼容的能力可以通过目录进入候选范围。应用仍需具备解释和使用其发现内容的规则。

这种差异也改变了审查人员应当检查的对象。审查编排器源代码不再必然能揭示其完整的未来能力集合。有效的审查还必须考虑目录、发布权限、审批实践和兼容性预期。

设想一个已经能够处理订单咨询的企业助手。一个支持团队引入了专门处理保修索赔的智能体。其架构收益在于：该专用智能体可以被发现，而无需在协调应用中再添加一个具名集成。

这一收益依赖于兼容性。新发布的服务若采用不熟悉的连接方式，仍会带来集成工作。运行时发现将部分决策推迟；它并不会让所有可能的服务立即可用。

因此，重要边界在于应用支持的连接契约。开发者可以在该契约范围内允许新能力，同时继续掌控协议、访问方式和执行策略。这比“通用即插即用集成”是更狭窄也更有用的承诺。

对于评估 AWS Agent Registry 运行时发现的读者，第一个问题应是：该架构实际解耦了哪些变化。新增兼容能力，与改变能力运行规则，是两件不同的事。

平台团队将承担目录发布问题

AWS 将其受治理的能力目录描述为具有发布和审批工作流的托管发现服务。其文档区分了发布者、策展者和消费者。这些角色揭示了一个重要的组织层面后果：能力发现需要持续的归属管理。

运行时选择将协调工作从单个集成的发布，转移到目录发布、审查和维护中。

平台工程师面临最直接的压力。在构建时接线模式下，应用仓库提供了明显的协调点。面对不断变化的目录，他们需要另一种方式来界定哪些能力应归属在一起，以及哪些变化需要更广泛的审查。

能力所有者则面临不同的责任。如果消费者无法理解何时应选择一个端点，那么一个可用端点并不充分。所有者应清楚说明预期任务、重要排除项、预期输入和运行限制，使其他团队能够评估该连接。

这类似于维护团队之间的共享接口。描述承载语义，而连接契约决定软件实际能做什么。两者任一薄弱，都可能造成协调智能体无法可靠解决的混乱。

审批也需要明确的目的。组织可能在接纳能力前审查其安全态势、归属、支持承诺或兼容性。这些检查回答的是不同问题，因此审批标签不应成为所有可能保证的简称。

获批服务对于特定用户请求仍可能并不适用。某个生产报表工具可能与主题相关，却不对提出请求的员工开放。某项支持能力可能能够解释政策，却没有权限更改订单。

对企业采购方而言，这意味着需要进行更具体的采购讨论：谁维护目录记录、谁批准变更，以及已发布能力不可用时由谁响应。托管发现服务本身无法分配这些内部职责。

同样的区别也适用于组织知识。团队需要一个共享场所，用于保存决策、例外情况和运行程序，并与机器可读记录并存。可搜索的知识库能够满足这种文档需求，而注册表则服务于运行时发现。

压力并不只是将一切集中化。过于宽泛的目录可能难以治理，而过度隔离的狭窄目录又可能保留发现本应减少的协调问题。团队应围绕实际的归属和使用模式选择边界。

衡量进展的一个有用指标是发布之间依赖关系的减少。如果每项新能力仍需要编排器编辑、协调审批和手动消费者更新，那么组织只是获得了一个目录，却没有实现多少架构独立性。

反过来，独立发布也不应意味着不可见的行为变化。消费者需要一种方式了解哪些能力已进入其应用的可及范围。当归属和变更沟通保持明确时，运行独立性效果最佳。

该循环将查找、连接和行动分开

当每个阶段都被视为独立决策时，AWS Agent Registry 运行时发现背后的机制会更加清晰。寻找相关能力、建立连接以及决定采取何种行动是相关任务，但它们需要不同的证据和控制措施。

AWS 记录了混合注册表搜索，它结合了基于含义的语义匹配与关键词匹配。名称、描述和协议描述符都会影响相关性。描述符是描述能力及其连接详情的结构化元数据。

搜索文档还指出，可发现结果仅限于获批记录。搜索索引是最终一致的，这意味着获批的变更不会立刻在所有位置可见。这些特性使发现既成为治理机制，也成为不断变化的运行时依赖。

搜索缩小候选集；应用仍必须建立有效连接，并选择恰当的行动。

在 AWS 的示例中，发现会返回不含调用凭证的连接元数据；调用凭证是调用能力所需的身份验证材料。应用会单独获取凭证。随后，它由发现到的能力组装一个临时内部智能体，并在请求结束后释放其客户端。

这种分离很重要，因为相关性并不能建立权限。服务可能与请求高度匹配，却仍无法被应用访问。反之，应用可能拥有某项服务的有效凭证，但该服务不应处理当前任务。

因此，应用构建相关客户端的实例化阶段，应被理解为集成边界。软件必须解释描述符、识别连接类型，并采用既定的身份验证路径。搜索结果不能替代这些检查。

执行阶段引入了另一条边界。选择某项支持能力，并不能决定应用应检索信息、提出变更建议，还是执行该变更。组织应在执行策略中定义这些区别，而不是期待检索相关性来表达它们。

一个假设性的退款请求说明了这种差异。发现可能识别出政策专员和订单信息服务。应用仍需确认客户身份、检索正确交易，并区分资格建议与获授权发放退款。

这一架构颇具吸引力，因为它可以缩小模型针对一个请求所见的范围。但它也产生上游依赖：正确能力必须在模型选择之前进入候选集。再有能力的模型，也无法选择它从未收到的集成。

这意味着应当分别评估各阶段。缺少候选项是发现问题。连接被拒是身份验证或兼容性问题。成功连接后的不当行动是执行问题。将它们合并为单一故障类别，会使改进更难聚焦。

该循环还明确了缓存——即复用先前结果——何时成为策略选择。复用发现结果可能减少重复工作，但团队应决定新鲜度和能力撤回如何影响这一选择。适当的平衡取决于应用带来的后果。

Anthropic 的工具搜索展现了更广泛的架构转变

AWS 正在解决一个超出云目录管理范畴的问题。Anthropic 的按需工具搜索描述了一种做法：将工具定义延迟到真正相关时才加载。其核心思路是避免将完整的能力库放入模型上下文，也就是生成过程中可用的信息中。

Anthropic 公开的方法会将选定定义标记为延迟加载。Claude 随后可搜索相关工具，并在需要时接收其定义。这有助于理解 AWS 的方向，但不应将两种方法视为可互换的产品。

二者共同的设计原则是选择性暴露，但集成责任仍取决于各自的系统。

这一比较有助于将底层架构选择与厂商定位区分开来。团队可以认同预先加载所有工具会造成浪费，同时仍倾向于为最重要的工作流保留明确连接。选择性暴露并不意味着必须让每个应用决策都动态化。

这一比较也避免了夸大其新颖性的说法。运行时发现属于管理不断扩张的能力库这一更广泛努力的一部分。AWS 的示例提供了一种具体的企业模式，而非表明行业直到现在才发现这一问题。

对于平台团队而言，关键问题是目录决策应归属何处。有些应用需要一个集中治理的目录，以覆盖由不同团队维护的能力；另一些应用主要需要防止既有工具库压垮模型可用的上下文。

这些需求有所重叠，但并不相同。更小的提示词并不会自动带来审批工作流。受治理的目录也不会自动确定某个特定模型或任务的最佳选择策略。

支持显式连接的最有力论点也值得被公平看待。当一个工作流具有稳定的顺序和有限的能力集合时，开发者可以直接检查预期连接。运行时检索必须带来清晰收益，才足以证明增加一个决策点是合理的。

一个假设中的定时对账流程便说明了这种情况。如果应用始终获取记录、进行比较并写入经批准的报告，那么每次都搜索相同能力的价值可能有限。该顺序本身已经表达了业务要求。

通用助手则面临不同情形。它的请求可能涵盖彼此无关的任务，而可用能力可能归属于独立变动的团队。当维护一份完整、显式的清单会持续带来协调工作时，运行时选择就更具吸引力。

这提出了一条实用的评估原则：应针对相同任务和变更场景比较架构。应纳入常规执行、能力新增、故障和恢复。一个有说服力的演示应展示动态选择在哪些场景下有帮助，而不是假定灵活性天然具有价值。

买方也不应仅凭目录规模判断架构。更有意义的问题是：随着目录变化，有用能力是否仍然可被发现并得到正确应用。当普通请求仍需人工路由时，再令人印象深刻的清单价值也有限。

发现质量需要独立的生产证据

最重要的不确定性在于演示之外的行为。AWS 的演示说明了这一循环，但并未证明某个特定企业目录将如何表现。生产环境中的主张应依赖具有代表性的评估，而非架构图。

发现 API会返回按相关性排序的匹配元数据，并支持结构化筛选。这使候选集成为可观察的应用输出。团队可以先检查发现环节返回了什么，再调查模型下一步做了什么。

生产评估应衡量发现机制是否提供了必要能力，包括本不应使用任何能力的请求。

首先要区分“看似合理”和“足以完成任务”的结果。一名账单专家对于订单问题或许听起来相关，却可能缺少作答所需的配送信息。评估人员应识别完成任务所需的能力，而不是接受任何描述相关的结果。

模糊请求尤其值得关注。用户要求“修复我的订单”，可能是指更改地址、纠正收费，或报告货物损坏。安全的应用应识别何时需要澄清，而不是将强搜索匹配解读为意图已确定。

负面案例同样重要。有些请求不应产生任何连接，因为目录中不存在合适能力。另一些请求应停止处理，因为用户没有权限，或所请求的操作超出应用范围。

目录增长应成为明确的测试条件。团队可以在新增重叠能力、修订描述或淘汰服务后重复同一评估。这将揭示日常维护变更是否会改变请求路由，即便编排器源代码保持不变。

也应评估描述质量，同时避免鼓励宣传性语言。发布者有动力让自己的能力更容易被发现。审查者应优先重视准确的适用范围与排除项，而非声称服务能够处理所有相邻任务的描述。

发现与认证的分离带来了有价值的故障案例可供测试。某项相关能力可能拥有过期凭证、不可用端点，或不兼容的响应。应用应解释限制，而不是悄然替换为不太合适的操作。

恢复同样值得严格审视。重试一次信息查询，与重试一次会更改业务记录的请求不同。团队应在允许自动恢复再次发起操作前，确认该操作是否可安全重复。

运营证据应将请求、所选能力和最终结果联系起来。否则，流畅的回答可能掩盖查询失败、意外回退，或从未完成的操作。审查者既需要执行证据，也需要响应质量证据。

当评估失败时，还存在责任归属问题。责任方可能是能力发布者、目录维护者或应用团队。及早明确这些责任，将使运行时选择更容易在跨部门环境中运行。

对于 AWS Agent Registry 运行时发现，其可辩护的承诺是在既定边界内提供架构灵活性。更高准确率、更低运营开销和更易维护仍是每次部署都应证明的结果。

关注迁移、目录增长与独立发布

眼下的观察点很具体。AWS 的注册表迁移指南称，专用的 agent-registry 命名空间于 2026 年 8 月 6 日推出。命名空间是跨接口与配置使用的服务标识符。对预览版 bedrock-agentcore 注册表命名空间的支持将于 10 月 30 日结束。

该指南说明了会影响服务端点、权限、客户端、资源标识符及相关配置的变更。它表示，其他 AgentCore 产品不受这次注册表命名空间变更影响。因此，对现有预览版用户而言，迁移是一项近期运营关注事项。

接下来的证据应展示迁移完成情况、目录增长下稳定的发现能力，以及无需不必要编排器变更的能力新增。

首先，应关注预览版用户是否完成迁移并验证其发现路径。成功的配置更新之后，应有证据表明目标应用仍可找到并调用获批准的能力。这将增强对运营连续性的信心。

迁移失败本身并不能否定运行时选择。但它会暴露依赖不断变化的托管接口所带来的维护需求。团队应将服务迁移问题与搜索或执行设计中的弱点区分开来。

其次，应关注在请求集合保持稳定的情况下扩展目录的评估。真正有价值的信号是：尽管重叠和歧义增加，系统仍能持续发现必要能力。仅报告成功示例，无法解决核心的扩展性问题。

选择能力变差的证据会削弱在缺少额外控制措施时广泛部署的理由。这将表明描述标准、目录边界、筛选机制或评估实践需要修订。目录扩展应被视为值得测试的行为变更。

第三，应关注独立团队能否在无需常规修改编排器的情况下发布兼容能力。这正是将连接从构建流程中移出的组织收益。最有力的证据应涵盖接入、认证设置、责任归属和撤回，而不仅仅是发布本身。

如果新增能力反复需要协调应用进行特殊处理，那么该架构提供的独立性将低于其图示所暗示的程度。如果团队能够在维持可预测行为的同时新增能力，运行时发现便实现了可衡量的发布协调变化。

这些信号比关于自主智能体的宏大预测更重要。它们将设计与可观察的工程结果联系起来：迁移期间的连续性、增长期间可靠的选择，以及能力变化时更少的协调工作。

对于初始评估，应选择一个能力所有权已跨越多个团队的有限工作流。在引入 AWS Agent Registry 运行时发现之前，先建立当前发布依赖关系和故障行为。明确保留具有代表性的请求、预期能力和不可接受的操作。比较常规请求与模糊问题、缺失服务和访问被拒的情形。然后引入一项兼容能力，并检查发布、审批、认证、发现和执行环节究竟发生了什么变化。将发现与技术决策一同保存，以便未来维护者理解其中边界。在扩展目录前，询问应用是否在保持对其行为负责者可理解的同时，变得更容易扩展。