Agentic Mesh——智能体网格注册表

从第 8 章我们了解到智能体网格（agentic mesh）的用户体验（UX）——它是让成千上万个“无界面”（headless）智能体变得可用的入口。但再强的 UX 也取决于其背后的信息质量。这就引出了界面与生态系统本身的一个关键基础要素：注册表（registry） 。智能体网格注册表是一个共享的“事实来源”（source of truth），让发现（discovery） 、信任（trust） 与协同（coordination） 成为可能。

在实践中，注册表不仅仅是为 UX 服务的存储库，它更像是整个智能体网格的“神经系统”。智能体、用户、对话与策略都会在这里被记录、关联，并对外提供。没有这样的记录，网格很快就会变得难以管理：智能体会难以被找到，它们的能力会变得含糊不清，策略也无法被一致地执行。注册表为人和软件提供了必要的“落地锚点”，让它们知道：系统里有什么、它能做什么、以及它应该如何表现。

注册表也让“自主性”变得可落地。智能体在协作前可以查询另一个智能体的定义；在采取行动前可以核对策略；也可以把一次交互的结果记录下来，以便后续审计。对话与交互不再只是转瞬即逝的消息，而是被串联起来的历史，使智能体与运营人员能够在复杂工作流中保持连续性。与此同时，工作区（workspace）成为持久的协作上下文，被定义并集中存储在同一个地方。

从治理视角看，结构化元数据是必不可少的。注册表确保每个智能体都有清晰的画像，策略与认证能够与之绑定，用户也能与其行为建立关联。由于这些信息是机器可读的，其他组件——例如市场（marketplace）或运营仪表盘（operator dashboards）——可以在不重复建设、也不靠猜测的情况下执行同一套规则。正是这种一致性，使企业级规模下的信任与监督成为可能。

最后，也值得想想如果没有这样的系统会发生什么。不一致的命名、过期的端点、以及无法验证的策略宣称，会迅速制造摩擦——不仅困扰智能体，也困扰负责管理它们的人。随着来源与问责链路消失，安全风险与运维错误都会上升。注册表通过让信息保持最新、一致、并且在整个网格中可访问，从而防止这种“漂移”。

本章将深入探讨注册表，重点聚焦其核心实体——智能体、对话、交互、工作区、策略与用户。它会展示这些元数据如何定义、为什么重要、以及它们如何同时支撑面向用户的体验与后端运维。为使概念更具体，我们会使用示例性的 YAML 定义与简单的 API 风格示例，同时也保留空间，让组织按自身环境选择最合适的格式与技术实现。

智能体网格注册表

智能体网格注册表如图 9-1 所示，它是核心的“系统记录”（system of record），把整个生态组织成一个连贯、可管理的整体。其核心在于记录智能体——它们的名称、用途、版本与能力——从而让它们能够被发现、被比较，并在使用时更有把握。它保存对话，确保智能体与人之间的交流可追踪，并在需要时可恢复或可审计。它记录交互（interactions），作为网格中工作的基本构件，捕获任务如何被发起、如何在参与者之间推进、以及如何完成。它维护工作区，将目标、任务与消息分组为持久的协作上下文，延伸到单次对话之外。它执行并跟踪策略，通过把规则与认证直接关联到智能体，使治理变得显式可见。它还管理用户，把人的身份与角色与其在网格中采取的行动绑定起来。上述要素共同构成结构化元数据，支撑整个系统的发现、信任与运维控制。

图 9-1. 智能体网格注册表

智能体（Agents）

注册表为每一个智能体存储结构化元数据，作为其定义与配置的权威记录。这些配置让用户与其他智能体能够理解：该智能体能执行哪些任务、如何通信、以及在什么约束下运行。

这些信息至少包括图 9-2 所示的内容：

• 名称（Name）
  智能体唯一且便于人读的标识符，通常遵循命名规范，用于指示其命名空间（namespace）以及该命名空间内的唯一名称。
• 版本（Version）
  表示当前迭代的具体发布编号或标签，通常采用如 SemVer（语义化版本）的命名规范。
• 用途（Purpose）
  对智能体意图做什么的简明解释，描述该智能体交付的高层结果或价值。
• 描述（Description）
  对智能体功能、上下文与运行边界的更详细说明。
• 方法（Approach）
  说明智能体为达成用途所采取的步骤。
• 角色（Roles）
  描述该智能体在系统中承担的职能责任。
• 策略（Policies）
  对智能体施加的治理规则、伦理约束或运行限制，可能包括访问控制、速率限制、升级/人工介入流程，或由法规与组织策略带来的约束。
• 认证（Certifications）
  证明该智能体满足既定标准的正式背书，例如安全合规、可审计性或互操作性。认证可能来自内部审查或外部机构（正如产品会有 ISO 27001 合规或 UL-AI 信任标识一样）。
• 协作者（Collaborators）
  该智能体允许协作的其他智能体列表。
• 工具（Tools）
  该智能体允许使用的工具列表。

当一个智能体发布到市场后，其元数据会被注册表摄取，用于支持可发现性并执行访问规则。

从运维角度看，把最新配置集中维护在注册表中，可以确保跨环境的一致性。任何对智能体行为的变更——例如端点更新或新增能力声明——都会被版本化，并通过注册表向下游传播。这使生命周期跟踪更清晰，支持回滚与审计流程，并为下游系统提供可靠的事实来源。对生产者而言，这消除了“哪个版本在运行、在什么条件下可被使用”的歧义。

图 9-2. 智能体定义

重要的是，智能体配置元数据是机器可读的，从而使发现引擎、仪表盘与编排工具等其他服务能够高效运行。这推动自动化，减少人工介入，并支撑系统级互操作性。由于配置元数据与访问控制及策略元数据绑定，注册表也成为一种合规执行机制：它决定谁能发现或与某个智能体交互。

最后，注册表在维护配置数据方面的作用也强化了整个生态的可靠性。如果智能体被临时暂停、被弃用（deprecated）或被替换，这些状态转换都会被记录并反映在其元数据中。这种可见性确保过期智能体不会被误用，也确保依赖它的系统能够获知其配置或状态发生的任何变化。

Conversations（对话）

注册表会捕获并存储涉及智能体的对话内容。这些对话既可能包括智能体与智能体之间的通信，也可能包括智能体与人类之间的交互。对话历史对于保持透明性、实现可追踪性，以及支撑下游分析都至关重要。对话会被建立索引，并与触发它们的智能体、用户或任务关联起来，从而确保上下文相关性。

对话由若干要素组成，如图 9-3 所示。对话要素可能包括以下内容：

• conversation_id
  对话 ID 是分配给每个对话实例的全局唯一标识符（通常是 UUID）。
• timestamp
  起始时间戳记录对话被发起的准确 UTC 时间，作为消息排序与计算持续时间的锚点。
• name and role
  这些要素指定发起对话的参与者的完全限定标识符（fully qualified identifier）及其被分配的角色（例如 agent、user、system），从而为交互提供可追踪性与上下文。
• state
state 反映对话的当前状态，例如 ACTIVE 或 INACTIVE，用以指示对话是否仍在进行、是否暂停，或是否已被正式结束。

图 9-3. Conversation definition（对话定义）

这份交互记录在需要为了合规、安全或调试而审查智能体行为的环境中尤其重要。通过维护完整的对话转录（full transcripts），系统允许内部审计人员、运维人员与开发者检查历史交互，并验证智能体是否按其被分配的策略行事。这也有助于诊断故障或非预期结果。

从产品设计角度看，对话存储支持长周期交互中的连续性。参与对话的智能体可能需要引用先前消息以延续决策、澄清意图，或在中断后恢复活动。持久化的对话历史支撑这种长期协作——无论智能体是在与单一用户交互，还是处于多智能体场景中运行。

隐私与访问控制仍然关键。对话记录必须通过细粒度权限加以保护，确保只有被授权的用户或智能体才能读取或分析历史交互。注册表通过将每条记录与身份元数据关联，并应用在信任工作台（trust workbench）中定义的策略来支持这些约束。

Interactions（交互）

交互是智能体网格（agentic mesh）中的基本工作单元。交互由若干要素组成，如图 9-4 所示。

图 9-4. Interaction definition（交互定义）

交互要素可能包括以下内容：

• interaction_id
  分配给每个交互的全局唯一标识符（通常是 UUID）。
• start_timestamp
  交互被发起的 UTC 时间，作为消息排序与计算持续时间的锚点。
• complete_timestamp
  记录交互正式结束的 UTC 时间。
• owner
  指定发起交互的智能体、用户或系统的完全限定名称，为对话上下文中的身份与问责提供依据。
• step_id
  标识该交互在更大任务序列中所代表的具体逻辑步骤或阶段，用于支持有序执行与依赖关系跟踪。
• collaborator
  记录接收或处理该交互的智能体、用户或服务名称，从而体现协作工作流的双边或多方特性。
• state
  反映交互当前状态，为进度提供实时可见性，并便于错误处理或重试。
• prompt
  包含发起方发送的初始请求或消息内容，通常包括对协作者的提问、命令或上下文指令。
• parameters
  随 prompt 一同提供的结构化输入值或配置，用于定义协作者应如何处理请求或执行任务。
• results
  在交互结束时返回的结构化输出、消息或制品（artifact），代表协作者产生的结果或响应。

一个对话包含一个或多个交互。端到端的交互可能跨越多个步骤与多个智能体。因此，交互的唯一标识符基于 interaction_id、发起方名称（originating name）与 step_id 的组合。

交互历史也承担诊断功能。如果智能体未能完成一次交互，注册表能提供交互在何时、因何原因停滞的可见性。运维人员可以利用这些信息进行介入，而生产者（producers）则可用其识别边界情况或改进智能体逻辑。在受监管行业中，交互跟踪也进一步增强了可审计性与合规能力。

最后，注册表与策略及信任元数据的集成确保交互在获批条件下执行。它可以施加约束，例如限定在特定时间窗口内执行、只能使用特定智能体，或禁止某些数据流。此类“策略感知”（policy-aware）的控制被嵌入交互元数据中，并在执行时进行评估。

Workspaces（工作区）

工作区支持围绕已定义目标的协作式智能体交互。每个工作区可以包含一个或多个目标（goals），而工作区中的消息（messages）会与特定目标关联。这些要素如图 9-5 所示。

图 9-5. Workspaces definition（工作区定义）

工作区要素包括以下内容：

• workspace_id
  分配给每个工作区的全局唯一标识符（通常为 UUID）。
• timestamp
  工作区被打开的 UTC 时间，作为消息排序与计算持续时间的锚点。

目标（goal）要素包括以下内容：

• workspace_id
  将目标链接到其父工作区，建立作用域，并确保目标跟踪发生在适当的协作上下文中。
• goal_id
  用于区分同一工作区内或跨工作区的不同目标的全局唯一标识符，支持面向目标的跟踪与消息关联。
• timestamp
  目标被打开的 UTC 时间，作为消息排序与计算持续时间的锚点。
• name
  目标的简洁、人类可读标签，通常描述预期产出或协作关注领域。
• description
  更长形式的摘要或叙述，解释该目标相关的目的、上下文与预期。
• state
  反映目标当前生命周期状态——例如 ACTIVE 或 INACTIVE——指示其是在进行中、暂停中，还是已结束。

消息（message）要素包括以下内容：

• workspace_id
  将消息关联到特定工作区，确保通信被限定在正确的协作环境中。
• goal_id
  将消息链接到其所关联的具体目标，帮助参与者与系统围绕离散目标来组织交流。
• message_id
  全局唯一标识符，使得在“工作区-目标”上下文中能够精确跟踪与引用每条消息。
• timestamp
  记录消息发送或被记录的 UTC 时间，用于对话流的时间顺序排序与审计目的。
• participant_id
  标识消息作者（智能体、用户或系统），建立身份、问责与可追踪性。
• content
  指消息正文，可能包含自然语言、结构化提示词、响应，或与持续协作相关的任务数据。
• interaction_id
  将消息链接到特定交互（interaction），使该消息能被放置在更大任务或工作流的上下文中理解。

通过捕获这些元数据，注册表允许用户恢复会话、重新分派任务，并跟踪目标推进情况。它还会通过验证参与者凭据并确保智能体只在其被分配的权限范围内运行来强制访问规则。当共享敏感信息，或工作区参与必须满足监管边界时，这些控制尤为重要。

工作区配置模型支持可组合性（composability）。用户可以为常见目标创建模板，指定默认智能体，并定义可复用的结束条件（end conditions）。这些模板存储在注册表中，并可在需要时通过工作台或市场（marketplace）检索。这降低了重复性工作流的搭建成本，并促进目标定义方式的一致性。

注册表层面的持久化也支持分析（analytics）。可以查询工作区配置与产出，以衡量智能体有效性、任务解决耗时或策略遵循率。这些指标为开发者、运维人员与治理团队提供反馈，帮助改进智能体行为并使其与组织目标对齐。

Policies（策略）

策略（policies）用于治理智能体行为，是 agentic mesh 信任与治理框架的关键组成部分，而注册表作为存储与管理这些策略的权威来源。策略如图 9-6 所示，是一份规则与约束的正式声明，用于定义智能体必须如何行为、如何被访问，以及在何种条件下可以被认证或部署。策略会在注册或认证时被附加到智能体上。

图 9-6. Policy and certification definitions（策略与认证定义）

策略要素（如图 9-6 所示）包括以下内容：

• policy_id
  全局唯一标识符，用于在 agentic mesh 内明确代表某一特定策略，确保引用无歧义并支持版本控制。
• name
  简短、人类可读标签，用于标识该策略并与注册表中的其他策略区分，通常反映其主题范围或执行域。
• purpose
  解释策略的预期作用——例如访问控制、伦理合规或运行安全——明确其存在原因与治理对象。
• description
  更详细地阐述策略内容，包括其对智能体强制执行的规则、条件或行为，以及任何上下文假设。

认证（certification）要素包括以下内容：

• certification_id
  全局唯一标识符，将一次具体认证事件与某个策略、智能体或实体关联起来，从而支持完整可审计性与认证历史跟踪。
• username
  颁发或验证认证的身份（通常是系统或人类管理员），建立问责与可追踪性。
• state
  记录认证当前状态——例如 ACTIVE、REVOKED 或 EXPIRED——指示该认证是否仍然有效且可被执行。
• timestamp
  记录认证被授予的 UTC 时间，为合规与生命周期管理提供权威记录。

每条策略可以定义对数据处理、认证鉴权、运行边界或第三方验证的要求。例如，一条策略可能要求：与金融记录交互的智能体必须通过安全扫描，并且只能在私有网络内运行。注册表存储这些策略定义并将其链接到受影响的智能体，使其他系统（如 marketplace 或执行引擎）能够在运行时评估其合规性。

策略也用于智能体认证流程。当某个智能体声明符合特定策略时，它必须经历一个证明（attestation）工作流：注册表会跟踪每项认证声明的状态、由谁签发、做了哪些测试或评估，以及该认证何时过期或需要续期。这些认证会成为智能体元数据的一部分，并在 marketplace 中作为信任信号（trust signals）可见，帮助消费者判断智能体的可靠性与治理状态。

由于策略会随时间演进，注册表支持对每个策略定义的版本化（versioning）与生命周期管理。这使治理团队能够废弃过期规则、引入新要求，并在发生变更时强制再认证（recertification）。注册表提供所需基础设施，以确保信任不是静态的，而是在整个智能体生态中被持续评估与执行。由此，注册表成为维持自治运行安全性、可问责性与信心的基础。

Users（用户）

注册表为所有与智能体生态交互的人类用户维护与身份绑定的元数据。每个用户都关联一个唯一身份，通常来自企业身份提供方，如图 9-7 所示。

图 9-7. User definition（用户定义）

用户信息至少可能包括以下要素：

• user_id
  全局唯一标识符，代表 agentic mesh 中的某个特定用户，支持在工作区、交互与审计日志中一致引用。
• name
  用户的完整人类可读姓名，用于展示，并在协作环境中提供上下文身份信息。
• email
  用户邮箱地址，既可作为通信渠道，也可作为认证与通知的潜在登录凭据。
• state
  指示用户账户的当前状态——例如 ACTIVE、SUSPENDED 或 DEACTIVATED——影响其参与对话或访问智能体服务的能力。

通过存储用户注册信息，注册表支持在 agentic mesh 的所有服务之间实现一致的访问管理。注意：注册表中只存储“注册信息”（registrations），因为每个企业都会在其身份管理系统中维护用户的“登记册系统”（book of record）。每个用户注册会在需要时与企业的身份登记册系统进行同步。

用户信息也在治理与问责中发挥关键作用。系统中的所有动作——无论是查看某个智能体、发起任务，还是修改元数据——都会带上身份归因记录。这构成审计追踪的基础，可用于重建“谁在何时做了什么以及为什么”。在受监管环境或事件调查期间，这些记录尤其重要，因为需要可追踪性与监督能力。

在共享工作区等协作场景中，用户元数据用于定义参与者列表、分配职责并控制可见性。可以基于角色或项目关联为用户授予读、写或管理权限，从而对智能体与人类的交互方式进行细粒度控制，确保敏感数据与敏感操作只对授权参与者可见。由此，注册表不仅支撑技术层面的强制执行，也支撑多用户场景下的组织协同与对齐。

Implementation Considerations（实现考量）

有若干实现层面的议题值得纳入考虑，但超出了本书的讨论范围。总体而言，这些议题与可扩展性（scaling） 、**可运维性（operability）与治理（governance）**相关——而这三者在任何生产级实现中都至关重要，尤其是在注册表（registry）在 agentic mesh 中处于核心地位的前提下：

• Schema management（Schema 管理）
  智能体元数据 schema 如何随时间进行版本化、校验与演进，以确保向后兼容，并在引入新字段或新结构时，对智能体属性保持一致解释。
• Eventing and notifications（事件与通知）
  注册表中的变更——例如新智能体注册、更新或退役（decommission）——如何通过事件总线或发布-订阅机制触发通知，从而提醒依赖方（相关智能体、fleet 或监控服务）。
• Audit logging and access tracing（审计日志与访问追踪）
  所有对注册表的访问与修改动作如何被记录到不可变日志中，以支持合规审查、入侵检测，以及对复杂智能体行为的调试。
• Conflict resolution and concurrency control（冲突解决与并发控制）
  来自不同用户或服务的并发更新如何通过乐观锁或悲观锁、版本检查或事务重试来处理，以维护数据完整性。
• Soft deletes and archival（软删除与归档）
  已退役或被删除的实体如何处理——是为满足合规而以归档状态保留（即软删除但可恢复），还是在保留期（retention periods）结束后永久删除——并为历史记录制定清晰的访问策略。
• Change management and versioning（变更管理与版本控制）
  新的注册表条目（如智能体或策略）如何通过分阶段审批、回滚机制与版本晋级（version promotion）工作流引入，从而支持可控发布。
• Integration with external systems（与外部系统集成）
  注册表如何连接企业系统，例如身份与访问管理（IAM）、集中式日志系统、外部数据目录（data catalogs）或联邦注册表（federated registries），以维持跨域互操作性。
• Security and encryption model（安全与加密模型）
  注册表数据如何通过静态加密（encryption at rest）与传输加密（in transit）、细粒度访问控制与基于 token 的认证来保护，从而保障敏感的智能体元数据与配置。
• Scalability and performance characteristics（可扩展性与性能特征）
  注册表如何被工程化以在企业规模下实现高吞吐、低延迟，支撑数百万智能体与用户，同时保持稳定一致的查询性能。
• Usage metrics and analytics（使用指标与分析）
  如何提取聚合指标——例如智能体受欢迎程度、版本采用情况、未使用的配置等——以指导优化、容量规划与产品改进。
• Backup and disaster recovery（备份与灾难恢复）
  注册表数据如何被定期备份、跨区域复制，并在基础设施故障或数据损坏时进行恢复，以确保连续性与韧性（resilience）。

Summary（小结）

在本章中，我们解释了注册表如何作为“系统登记册（system of record）”，把一组智能体转变为一个可运作（operable）的生态系统：我们描述了其核心实体（agents、conversations、interactions、workspaces、policies、users）；展示了机器可读的元数据如何支撑发现（discovery）、访问控制与认证（certification）；并说明对话与交互历史如何在工作流中提供连续性、可观测性与可审计性。我们还把注册表与更广泛的平台关联起来——它为 marketplace 提供动力、为 monitor 提供信息、并执行治理——最后用一组实用的实现考量（schema 演进、事件机制、安全、扩展与恢复）为企业落地提供指引。

在第 10 章，我们将转向交互管理（interaction management） ：探讨智能体与人类如何通过事件、消息与共享上下文进行沟通；对话与交互如何保持连续性与意图一致；以及 mesh 的事件驱动织体如何提供可靠性、可观测性与规模能力，以支持数千个自治参与者的实时协作。