智能体网格（Agentic mesh）是一个企业级生态系统。在本章中，我们将从单个智能体的设计转向成千上万智能体的编排与协同，重点讨论自治智能系统如何在企业范围内彼此发现、协调行动，并在保持信任与控制的前提下运作。本章介绍网格的主要组件——注册中心（registry）、监控器（monitor）、交互服务器（interactions server）、市场（marketplace）、工作台（workbenches）以及代理（proxy）——它们共同构成连接性基础设施，使孤立的智能体变成一个连贯的网络。整体而言，这些组件为一个“智能不再集中、而是分布在大量自治实体之中”的世界，提供治理、协作与可靠性的基础。
生态系统从本质上说，是一个规模问题。参与者数量很少时，交互可以靠人工管理；参与者可以通过直接连接或共享理解来协调。但随着参与者数量增长，复杂性也随之上升——通信量倍增、依赖关系加深、协调成本呈指数级攀升。从互联网到云计算，各类生态系统之所以能够成功，是因为它们通过结构化的抽象层、发现机制与治理体系来管理规模：协议定义参与者如何通信，注册中心追踪“谁存在、能做什么”，编排层保证整体同步一致。同样的原则也适用于智能体网格：它提供标准、接口与可观测性，把单个推理系统转化为能够协同运作的集体智能。
从这个角度看，智能体网格既是一种技术架构，也是一种治理框架。它提供连接织体，使智能体——以及智能体舰队（fleets of agents）——能够彼此发现、建立信任并交互，同时确保安全、合规与透明。网格中的每一项服务，都对应着上一代分布式系统沉淀下来的经验：来自 Web 的发现服务、来自 DevOps 的遥测（telemetry）、来自安全工程的策略控制、以及来自数字生态的市场机制。通过融合这些要素，智能体网格解决了“智能规模化”的根本问题——让成千上万自治智能体的行为不至于混乱，而是像一个有组织、可观测、可信赖的企业系统那样运转。
生态系统与规模（Ecosystems and Scale）
我们从最基本的问题开始：什么是生态系统？
生态系统——无论是生物的、社会的还是技术的——其定义并不在于“部件本身”，而在于“部件之间的关系”。它是一张由交互、依赖与交换构成的网络，使系统能够呈现出“整体大于部分之和”的特性。在技术领域，当独立系统被设计为可互操作时，就会形成生态系统：参与者能够在一个共享环境中可靠地发现彼此、进行通信并开展协作。以现代互联网为例，它就是由协议、平台与应用组成的生态系统，各参与方相互依赖才能运转。类似地，服务网格（service mesh）为微服务形成一个生态系统：API 是参与者，服务发现是连接组织，而网格确保通信是安全的、可观测的、具备韧性的。
在数据网格（data mesh）中，同样的原则成立，只是参与者变成了数据产品（data products）。每个数据产品都暴露清晰定义的接口，并对质量与溯源（provenance）做出保证，使其他团队能够有信心地消费、组合与复用它。网格提供协调层——标准、契约与可观测性——让去中心化团队在没有中心瓶颈的情况下协作。最终产物不仅是“共享数据”，更是一个由治理约束的、可信信息的市场（marketplace）。
现在，把这个思路延伸到智能体。在智能体网格中，参与者是自治智能体本身——具备感知、推理与行动能力的软件实体。每个智能体既是服务、决策或洞见的消费者，也是生产者。但要让它们高效地协同，就需要一个能够执行治理、定义互操作性并内建信任的生态系统。智能体网格正是为此而生：它是运行织体（operating fabric），让智能体能够安全地彼此发现、交换上下文、围绕目标协作，甚至代表人类或机构进行“交易式”动作（transact）。
而在这里，规模成为决定性挑战。单个智能体可以推理，少量智能体可以协调，但当生态系统扩展到上千个时，复杂性就会呈现出涌现式增长（emergent complexity）。单个智能体关注的是自己的提示词（prompt）、工具与眼前任务；生态系统关注的则是调度（scheduling）、上下文传播（context propagation）、一致性（consistency）与治理（governance）。一旦智能体必须交互——转交工作、协商目标或共享记忆——系统就同时继承了分布式计算与组织行为的全部难题。缺乏结构化的协调机制、可观测性以及参与规则时，大规模智能体网络会变得嘈杂、重复且不透明。
智能体网格的存在，就是为了管理这种规模。它提供的不仅是通信能力，更是协调能力：用注册中心来发现智能体，用工作区来共享上下文，用策略来约束访问与安全，用消息流来同步决策。正如服务网格抽象掉网络通信的管道工作一样，智能体网格抽象的是推理与协作的编排“管道”。它确保成千上万智能体能够并行运作而不陷入混乱——每个智能体追求自身目标的同时，又能在整体上对集体结果做出一致、可控的贡献。
当然，尽管我们反复谈论规模，走向智能体生态的路径通常并不是从“很大”开始。大多数组织都会从小规模起步——几个面向任务的智能体，也许通过共享 API 或消息队列连接起来。但增长几乎不可避免。随着更多工作流被自动化、更多智能被分布化，协调成本会指数级上升。因而从一开始就“面向终局”设计——尽早采用可扩展的通信、治理与记忆模式——能让组织为未来做好准备。从这个意义上说，智能体网格是一个用于规模化智能的概念框架：它提供一种方式，把大量自治智能体转化为一个可治理、可适配、能够持续演进的生态系统。
智能体舰队（Agent Fleets）
智能体舰队并不只是为了方便而做的分组——它们是在规模化运行智能时的架构答案。它们提供一种方式，将成千上万智能体组织起来、协调起来并纳入治理，使其成为目标明确、行动一致的整体实体。正如舰队负责管理智能体，智能体网格（agentic mesh）则负责管理舰队，在舰队之间提供发现、路由与策略执行。两者结合，把智能体生态从松散的“推理单元网络”，转变为纪律严明、具备韧性且真正企业级的系统——一种不仅为了扩展算力，更是为了扩展“认知能力”的架构。
结构与组成（Structure and Composition）
当企业生态中的智能体数量持续增长——从几十到几百，再到几千——问题就不再是“单个智能体是否聪明”，而是“如何管理集体”。在小规模下，工程师还能直接配置、监控并逐个理解每个智能体；但在企业规模下，这种一对一的监管会变得不可持续。运维与认知负担会迅速超过人类承受能力。解决方案只能是抽象——用一种方式把很多智能体当作一个连贯的实体来对待。这个抽象就是“舰队”。
舰队是相关智能体的逻辑分组，它们围绕共同使命协同工作。在大型智能体系统中，舰队成为部署、协调与治理的基本单位。用户与管理员不再为每个狭窄任务去调用单个智能体，而是以舰队为思考对象——一个自包含的子系统，能够交付更宏观的结果，例如“客户开户引导”“欺诈检测”或“投资组合优化”。每支舰队都是一个微型生态：一组智能体共同完成感知、决策与行动。
用工厂作类比会更清晰。在制造业里，没有任何一台机器能把原材料直接变成一辆汽车；最终结果来自多个专门工位的协同活动——每个工位完成一个步骤，且严格按序衔接。舰队的工作方式也是如此：每个智能体都是一个“工位”，贡献一种专门能力，而舰队负责协调它们的集体产出。输入——数据、事件或指令——流入舰队，舰队输出可执行的结果、分析或决策。
在规模化条件下，一支舰队必须像一个单一的逻辑系统那样运作：它作为一个整体启动、暂停与停止；它的健康状况与容量按整体来衡量，尽管内部由许多可替换的智能体组成。如果仍按“逐个智能体”去管理，抽象就会失效，复杂性会重新泄漏回系统中。对用户与运维人员而言，舰队应当像一个对象：可以用一条命令完成启动、停止、扩缩容或观测。
每支舰队也有清晰的领域边界。单个智能体承担窄而专的角色——验证身份、分类文档、评估风险——而舰队把这些聚合成一个连贯的服务边界。这一设计原则把用户交互从“过程式思维”（“先调用身份智能体，再调用合规智能体”）转向“意图式推理”（“开一个账户”）。舰队把步骤编舞隐藏起来。
在企业场景中，这种抽象还提升效率。与其为相近目的创建多支舰队（比如一支用于开户、另一支用于销户），不如用一支领域更宽的“账户管理舰队”覆盖相关流程。内部可复用共享组件与模型，从而减少冗余。到这一步，舰队——而非智能体——成为主要的管理单元。
协调与运行（Coordination and Operation）
要管理大型智能体生态，需要一套新的管理平面，把舰队作为一等公民。管理平面在“舰队层”执行生命周期操作，例如启动、停止、扩缩容、观测与升级。单个智能体实例可以加入或离开舰队——比如发布智能体新版本时——但这些切换由系统自动编排，并对外不可见。这正是舰队作为规模抽象的意义：系统管理员可以通过几十到几百个舰队对象管理成千上万智能体，而不是逐个操作。
在舰队内部，协同是事件驱动的。智能体通过发布-订阅（pub/sub）架构通信，而非直接的 RPC 调用。事件沿着消息总线流动，使智能体能够异步、独立地运行。正是这种解耦让舰队可以水平扩展——新增或移除智能体实例不需要重写通信逻辑。事件总线相当于舰队的神经系统，在智能体之间传递信号与状态变化。
当一个请求进入舰队，通常会由一个编排智能体（orchestrator agent）接管：它把任务分解为子任务，并委派给专门的子智能体。子智能体并行执行，把结果写回共享工作区，并更新全局状态。其他智能体订阅这些更新并作出响应。最终形成的是一种分布式工作流：它实时演化，依据数据与上下文做出反应，而不是遵循固定脚本。
每支舰队都维护一个共享记忆与上下文层，作为协同的锚点。该层记录当前任务状态、中间结果以及历史轨迹。当新智能体实例启动时，它可以读取这些上下文，立刻在正在进行的操作中“就位”；完成任务后，它把结果追加回同一上下文，供其他智能体继续构建。规模化时，这种机制支持持续推理与顺滑交接，覆盖数百甚至数千智能体。
舰队还支持弹性扩缩容。当负载激增——例如企业同时执行一百万次信用核查——编排器可以动态拉起更多验证智能体分担负载；当高峰过去，多余容量会自动回收。这类似云基础设施的弹性，但这里扩展的不是服务器，而是推理能力。
容错是舰队运行的根本。由于通信是异步的，单个智能体故障不会阻塞舰队；消息队列会保留未处理的工作，替代实例可以从断点继续。像 NATS JetStream 或 Apache Kafka 这类提供的持久化事件流，保证每一次动作、更新或决策在需要时都能被重放。这使舰队即便在成千上万智能体启动、停止或迁移宿主机时，也能优雅恢复并保持连续性。
智能体网格把同样的协调原则扩展到“舰队之上的舰队”。大型企业可能运行数百支舰队，每支对应一个部门、职能或业务单元。网格提供更高阶的路由、发现与治理层，使舰队之间能够像舰队内的智能体那样协作。换句话说，网格以分层方式扩展协调：从智能体到舰队，再到网格。
生态系统管理平面（The Ecosystem Management Plane）
在企业规模下，“管理”与“智能”同等关键。每支舰队可能封装数十个智能体，处理受监管的数据或调用外部 API。治理规定每支舰队能做什么、能访问哪些数据、其活动如何被监控。因此，每支舰队既自治又可问责——其自治被策略、凭证与审计轨迹所约束，并由管理平面强制执行。
可观测性与可审计性不可妥协。舰队内每一条消息、每一个事件、每一次决策都必须可追踪。持久化事件流允许团队重放导致某个结果的完整交互序列，支持合规、调查与调试。这种透明度在系统层面对应 DevOps 实践，但它进一步延伸到“认知操作”；从某种意义上说，它就是智能体推理过程的审计轨迹。
在管理平面层，舰队是运维控制的基本单元。管理员可以像管理 Kubernetes 集群那样启动或停止舰队；可以观测性能指标——延迟、吞吐、成本或准确率——并在不触碰单个智能体的情况下施加策略变更。舰队屏蔽底层细节，让人类运维聚焦意图而非实现。
舰队会持续演进。新的大模型、改进的提示词或升级后的工具，会通过滚动升级策略无缝发布。单个智能体可以在不让舰队下线的情况下被替换、退役或重新部署。
智能体网格本身则是“舰队的管理层”。正如舰队管理智能体组，网格管理舰队组。它负责编排跨舰队通信、执行跨舰队策略，并优化系统级性能。这种分层设计使智能体生态在规模化时仍然可行：一种多层架构，在其中智能、协调与治理各自拥有明确的控制范围。
在这种结构里：智能体是推理的原子单元；舰队是管理的原子单元；网格是治理的原子单元。
智能体网格组件（Agentic Mesh Components）
智能体网格（agentic mesh）是把单个智能体绑定成更大生态系统的“连接织物”，如图 7-1 所示。它由若干核心服务组成：
- 注册表（Registry）
维护使智能体在网格中彼此发现（find each other）所需的元数据。 - 监控器（Monitor）
维护并发布关于网格中智能体的度量指标与运行（operational）信息。 - 交互服务器（Interactions server）
处理网格中人与智能体之间的通信。 - 市场（Marketplace）
让人们发现智能体并与智能体交互。 - 工作台（Workbenches）
让开发者创建与更新智能体。 - 代理（Proxy）
在用户界面组件（市场）与智能体网格之间中介访问（mediate access）。 - 智能体与工具（Agents and tools）
已在前几章覆盖。
图 7-1. 智能体网格生态系统（Agentic mesh ecosystem）
注册表（The Registry）
注册表是智能体网格中负责管理所有智能体元数据（metadata）的组件。在很多方面，注册表就像是智能体的中央通讯录或目录（catalog）。
由于它能访问智能体网格中所有智能体的信息，注册表在网格中居于核心位置。它提供以下能力：
- 它是驱动市场（marketplace）的数据源。
- 它让智能体能够发现其他智能体（discovery）。
- 它注册智能体与工具，使其在网格中可用。
- 它追踪智能体的生命周期，从注册到退役（decommissioning）。
注册表会追踪一个智能体从创建到退役的生命周期，具体包括：
- 注册（Registration）
在此阶段定义并公布——也就是“注册”——智能体配置，使其被智能体网格所知晓。 - 发现（Discovery）
在注册之后，智能体能够被其他智能体发现（discovered）。 - 会话历史（Conversation history）
记录用户与智能体之间、以及智能体与智能体之间的会话历史。 - 退役（Decommissioning）
将智能体从智能体网格中注销（unregistered），本质上使其“退休”。
注册（Registration）
如前几章所述，一个智能体的配置（configuration）包括如下内容：
- 核心智能体元数据（Core agent metadata）
包括（但不限于）智能体名称、目的（purpose）与描述（description）。 - 协作者与工具（Collaborators and tools）
描述该智能体允许或不允许与哪些智能体/工具对话。 - 方法（Approach）
描述该智能体如何履行请求与任务。 - 工作区（Workspaces）
用于该智能体意图以目标导向（goal-oriented）方式运行的场景。 - 安全策略（Security policies）
包括哪些角色（roles）可以在何种条件下访问该智能体。
智能体配置的定义与注册发生在创建者工作台（creator workbench） 中，它是智能体网格市场 UI 的一个组件。智能体配置完成并验证后，会被提交到注册表，使该智能体对网格中的所有其他智能体可见（known）。
当期望的配置发生变化时，这个注册信息也可以更新。因此，智能体元数据会与一个版本号（version number） 一同存储，用于追踪元数据变更，并在更新出错时允许回滚到更早状态。
除了智能体之外，工作区（workspaces） 与工具（tools） 在智能体网格中也有各自的注册流程，同样通过创建者工作台进行。其机制与智能体类似，只是所存储的元数据略有不同。
发现（Discovery）
注册表是网格中保存智能体信息的部分，并深度参与智能体发现流程——既包括人用来发现自己想使用的智能体的流程，也包括智能体发现可协作伙伴的流程。
对人来说，智能体发现通常从市场（marketplace） 开始：用户在 UI 上发起操作，市场向注册表请求可用智能体列表，并附带用户指定的过滤条件或搜索参数。注册表查找相关信息并返回给市场，再由市场把信息呈现给用户。
例如，用户可能按 namespace 过滤，只获取某个组织的智能体；也可能按认证（certification）过滤，只获取 GDPR 合规智能体。这种可搜索能力让用户更容易把满足需求的智能体“浮出水面”。尽管人（很可能是程序员）也可以直接使用注册表 API，但市场通常是更常见、更友好的发现方式。
与人不同，智能体不会通过市场作为中介，而是通过公开的 API 直接与注册表交互，以实现更细粒度且更灵活的搜索（见图 7-2）。当网格中的智能体在构建任务计划（task plans）时，需要确定能够纳入计划的、具体且精确的单个智能体。因此，智能体可以向注册表发送请求，获得网格中其他可用智能体及其元数据，从而判断哪些智能体对当前任务有用。
智能体可以利用自身配置（agent configuration）中的选项，把可见智能体集合从网格全量缩小。该配置允许指定特定智能体，或用正则表达式（regex）定义一个子集——当某个智能体执行发现时，只有该子集对它“可见”。此配置既可用于提升性能（候选更少通常更易决策），也可用于合规。如果一个智能体需要 GDPR 合规，就必须确保它在任务计划里只纳入同样 GDPR 合规的智能体。
图 7-2. 智能体发现（Agent discovery）
同样地，智能体在执行请求时也可以从注册表中检索工作区与工具的元数据。这使智能体能够决定在计划中需要纳入哪些工作区与工具，从而有效使用远程资源。用户也可以通过 API 或市场请求这些信息，以便基于可用的工具与工作区做出选择。
这一发现流程把网格从一系列彼此隔离的智能体，转变为一个统一整体：智能体现在能够彼此发现并交互，而无需被明确告知要与哪些智能体交互。
元数据存储（Metadata storage）
除上述内容外，注册表还充当智能体网格运行所需的其他元数据存储。这包括关于策略（policies）、智能体认证（agent certification）、策略信息、安全信息等，以及更多内容。只要网格运行需要某类元数据，它都会存储在注册表中，供网格的其他部分访问。
这些元数据也可以通过市场或交互 API 被网格用户访问。用户可用其了解市场状态，例如市场当前有哪些智能体或工作区可用。输出还可以按用户需求进行过滤，只返回满足用户设定标准的信息，从而在大型网格中把输出规模控制在可管理范围内。
监控器（The Monitor）
具备提交请求的能力之后，就需要能够监控并追踪历史请求；监控器正是用来收集这类信息的地方。在智能体网格（agentic mesh）中，无论发生什么——包括用户发起的请求与系统事件——都会在监控器服务里被追踪，并被记录下来以便后续查看与分析。
针对用户请求，监控器会追踪用户发起的每个请求在执行过程中的每一步。每当构建出一个计划，或执行该计划中的某一步时，该计划或执行记录都会被监控器追踪，并通过一个交互 ID（interaction ID, IID） 回溯关联到初始请求。IID 确保解决某个请求的每一个步骤都与其他步骤互相关联，这意味着无论执行流变得多么复杂，动作都能在网格中被端到端追踪。
对于任务型智能体（task-based agents） ，仅靠 IID 就足以让整个执行流保持连通。当一个智能体调用另一个智能体时，它会把与初始请求绑定的 IID 传递给被调用的智能体。此 IID 会在后续所有步骤中持续存在，确保请求无论经过多少个智能体都可被追踪。IID 也允许智能体通过从注册表（registry）中拉取信息来查看会话历史，因为 IID 使得执行过程中的所有先前步骤都能被轻松检索出来。
对于目标导向智能体（goal-oriented agents） ，工作区（workspaces）允许智能体以更自由的方式彼此协作；在单次输入触发的情况下，可能会出现多个相互独立的交互。因此，仅靠一个 IID 不足以追踪由该目标触发的全部活动。为此，会为目标本身关联一个目标 ID（goal ID, GID） ，并在工作区内追踪该 GID。由于消息始终与某个目标关联，这就把工作区中因某个目标而发生的一切活动统一串联起来。这些消息也会带有 IID，使得当智能体试图对某条消息采取行动并生成计划时，该计划能够与触发它的那条消息绑定。这个双层 ID 体系使得在一个工作区中追踪多个相互独立的执行成为可能。
监控器收集到的信息会被记录（logged）下来，以便在出现问题时进行细粒度分析；同时，这些信息还会被发送到注册表。这样一来，这些信息既可以展示给用户，也可以在未来被网格中的其他组件使用。
交互服务器（The Interactions Server）
交互服务器是网格中的组件，用于促进网格各组件之间的交互：它提供网格组件调用的 API，使它们能够与系统其余部分交互。它也提供市场（marketplace）用来向用户展示信息的一部分 API。
用户正是通过交互服务器向网格提交新请求。所有智能体处理都从这里启动，复杂的规划与智能体交互也从这里开始。该 API 允许用户选择一个智能体并向其发送消息，从而开始一次会话；系统会把该会话的 ID 返回给用户，使其之后能够追踪这次会话。
除了启动新会话之外，还有一些 API 允许用户与既有会话或既有交互进行互动。第一种方式是提供一个 API，让用户查询某个会话的信息，并返回该会话的可用信息。用户可以用它判断既有会话的状态——例如判断某个会话/交互是否已完成未决任务，或仍处于 pending 状态等待处理。此外，还有一个端点允许向既有交互或会话追加新消息，从而在执行中途提供新信息或新指令，潜在地打通智能体执行中的阻塞点。
除了与任务导向智能体使用的会话交互之外，用户还可以通过工作区 API（workplace APIs） 与目标导向智能体和仿真智能体（simulation agents）使用的工作区交互。这类交互从一个 API 开始：它允许在指定工作区内创建新的目标（goal）。该目标包含：系统生成的 ID、可选的人类可读描述、以及将被提交到工作区的第一条消息。提交后，监听该工作区的智能体会拾取（picked up）该目标/消息，并开始对消息采取行动。
与会话 API 类似，也存在用于监控工作区内容、并向其中添加新内容的 API。它们允许追踪工作区当前状态，按目标 ID 过滤出与特定目标关联的消息，并向工作区插入新消息，以向监听的智能体提供新信息或补充与问题相关的输入。
尽管所有这些 API 都可以直接使用，但预期大多数用户主要会通过更友好的市场（marketplace）来与它们交互。
市场（The Marketplace）
市场是智能体网格中提供用户界面的组件，相比监控器、注册表与交互服务器各自暴露的原始 API，它为用户提供了更友好的交互方式。它把这些端点封装成更可视化的形式，使技术与非技术用户都能更容易地与网格交互。
更友好的 API（Friendlier APIs）
虽然完全可以仅通过 API 与智能体网格交互，但对大多数用户而言，这会比使用一个引导式 UI 更困难。为此，市场提供了若干界面，为注册表、监控器与交互服务器中所有可用 API 提供 UI。这些 UI 旨在展示用户提交请求所需的信息，并帮助用户更顺畅地提供这些信息。
以注册表服务为例：创建智能体的 UI 会为 description、approach 等字段提供文本框——这些字段完全由用户填写，且不强制结构。但对于 workspaces、tools 这类有固定选项集合的字段，会提供一组可选项，并允许用户通过过滤来缩小候选集合、得到更可能合适的选项。同样，界面提供按钮用于添加新的输入参数：点击后会出现新的字段，用于描述该输入参数的名称、类型与说明。它们组合在一起，形成一个智能体创建表单，相比手写原始 YAML 配置文件，大幅简化了创建过程。
在从注册表检索信息时，可用的智能体、工具与工作区会以可筛选列表的形式进行搜索与查看。这使用户更容易在智能体网格中找到自己需要的智能体，从而获得更好的体验。
对于交互服务器而言，界面会随交互类型而变化：如果要启动新会话，用户可以写一条新消息，并依赖市场确保该消息会发送到所选智能体。之后，用户可以通过便捷的状态展示与相关交互/步骤的快速入口来追踪请求状态。如果发现智能体处于 pending 状态，还可以在同一界面提交新消息；若看起来智能体遇到错误，也可以拉起日志查看。
对于工作区，用户也可以类似地提交一个目标；随着智能体往工作区写入消息，与该目标相关的工作区内容会在屏幕上实时展示，并提供可点击按钮，用于查看智能体因工作区消息而启动的单个交互的更多信息。界面同样允许追加新消息，以实现与会话类似的“纠偏”。
告警（Alerting）
尽管用户可以手动检查请求状态，但如果用户发起大量请求，手动跟进很快会变得不切实际。因此，市场会提供一个可配置的告警系统，用于向用户高亮重要事件。通过为用户收集的告警列表，用户能够跟进与自己相关的事件，从而更容易注意到并响应网格上正在发生的事情。
告警设置由用户配置。例如，用户可以选择：当自己创建的请求进入 pending 状态、需要新输入才能继续时收到提醒；也可以配置为仅在请求完成时通知。不论哪种方式，与用户关心的请求相关的更新都可以通过市场被“浮出水面”，并提醒用户关注。
用户如何与智能体交互（How a user engages an agent）
在市场中，与智能体交互从“发现（discovery）”开始。登录后，用户进入市场主页视图，智能体会与其描述、认证（certifications）与评分（ratings）一起被列出。过滤器让用户可以轻松缩小列表——按类别、合规标准或舰队（fleet）归属过滤。用户找到适合目标的智能体后，可以打开其资料页查看细节：它做什么、由谁认证、期望哪些输入。然后，用户可以点击“Start Conversation”（用于明确任务）或“Create Goal in Workspace”（用于开放式目标）。这一步会把一条消息发送进网格，并返回一个追踪标识符，使用户能够监控进度。
请求启动后，智能体的响应流会直接在市场中展开。会话视图展示用户与智能体交换的消息，并显示智能体何时请求澄清或更多数据。用户可以输入回复、上传文件，或通过引导式提示补充上下文。对于多步骤或协作型请求，工作区视图会在贡献智能体写入消息、决策或阶段性结果时实时更新。用户始终能看到当前处于哪一步、有哪些智能体参与，但不需要管理这些细节——舰队会自动完成协同。
在整个交互过程中，告警会让用户保持知情：当请求因等待输入而暂停、成功完成或遇到错误时会出现通知。点击告警会在上下文中重新打开对应的会话或工作区。对更高级的用户而言，Monitor 面板提供更深入的执行视图：运行了哪些计划、调用了哪些智能体、以及每个步骤耗时多久。这种可见性让用户确信网格正在代表他们工作，并为合规或调试提供运维人员可用的审计轨迹（audit trail）。
工作台（Workbenches）
如果说市场（marketplace）提供的是智能体网格（agentic mesh）的用户体验，那么工作台提供的就是开发者体验。这些工作台提供一套 UI，让开发者能够快速、轻松地在智能体网格中创建并部署新的智能体，然后为它们配齐成功所需的工具。
这些工作台中最重要的是智能体创建工作台（agent creation workbench） 。它专注于创建新智能体，会引导开发者完成创建流程。智能体配置可以直接在屏幕上填写，必要的配置章节会被高亮，方便开发者操作。对于必须从固定列表中选择的选项，工作台提供下拉框，让开发者能从可用选项中轻松选取。在这个工作台里，用户还会选择诸如：哪些工具（tools）、工作区（workspaces）、以及其他智能体（agents）对正在创建的新智能体可用。一旦开发者对智能体满意，就可以将其注册到注册表（registry），使其对网格中的其他部分可用。
除了创建智能体之外，智能体工作台也是开发者修改其智能体的地方。开发者可以把智能体配置中的任意值改成新值，从而改变智能体的行为。确认无误后，可以更新智能体配置，并将版本号变更为新值，以便让所有下游使用方明确感知到这次变更。
工作区与工具也有类似的工作台。工作区工作台（workspace workbench） 同样是一个配置工具，用于为工作区配置访问该工作区所需的相关信息。**工具工作台（tool workbench）**虽然也负责配置，但它还负责提供工具的代码。通常这会通过包管理器来完成：用户指定包含该工具的包，从而让需要它的智能体能够使用该工具。
除了用于创建智能体网格中新元素的工作台之外，还有用于部署组件的工作台。这些工作台允许把新创建的智能体部署到网格上，使其运行并接收来自用户或其他智能体的请求。该工作台会引导用户完成在网格上创建部署（deployment）的过程：它允许配置资源、启动与停止智能体，并在出现问题时将智能体回滚到先前版本。
通过这一整套工作台，智能体网格确保开发者体验足够优秀、并且易于使用。
代理（The Proxy）
市场的最后一个组件是代理（proxy） 。它作为进入智能体网格后端的入口点，位于 API 与调用这些 API 的用户或市场之间。这使得智能体网格拥有一个统一的入口与出口点，同时也便于在该层强制执行安全与授权控制。代理会持有并执行安全策略，向网格告知“谁已登录”以及“谁能访问网格的哪些部分”。
代理被设计为可以对接组织内部既有的认证与授权系统，从而能够与组织的其他系统良好集成。进一步地，它还能基于该系统中定义的用户与用户组来定义自身的权限结构，使得在网格内部建立一套合适的授权方案更容易。
网格能力（Mesh Capabilities）
智能体网格（agentic mesh）的某些能力并不绑定到某一个特定组件上，而是由网格整体负责实现：每个组件都在其中扮演一部分角色，共同交付这些能力。
信任框架（Trust Framework）
网格被设计成允许智能体被许多人复用，并且这些使用场景可能差异很大。这必然意味着：人们会去使用一些并非自己创建、也从未与之交互过的智能体。在这种情况下，用户如何确信某个智能体真的会“按它宣称的那样做事”？智能体当然可以声称自己具备某些行为特征，但如果用户没有任何手段去验证这些行为确实存在，又如何信任这类信息？信任框架就是为了解决这些问题而设计的。
信任框架从把新智能体加入网格的审批流程开始：只有具备恰当权限的用户才能添加智能体到网格中——但这只是起点。信任框架真正发挥作用的地方在于认证流程（见图 7-3）。一个可信用户或组织——它以可信著称，可能是组织内部的审批团队，也可能是外部合作伙伴，或某个相关领域的专家——会定义一套行为标准。审批方希望强制执行的任何特定行为标准，都可以作为这套标准的内容；随后审批方会将其作为一项策略（policy）发布到智能体网格上。该策略对网格上的所有用户可见，使他们能够看到要满足合规所需的要求。
接下来，认为自己的智能体满足该标准的用户，可以向审批方发起认证申请。这会让审批方知道有一个智能体正在等待认证，但此时并不会把该策略写入智能体的元数据。审批方将有机会审查该智能体的行为，并审查它可能调用的其他工具和智能体。审批方还可以测试该智能体的行为，以评估它在实际运行中的合规程度。当审批方确认其行为标准已被满足时，就可以对该智能体进行认证；认证结果会展示在该智能体的元数据中，从而让未来的用户知道：这个智能体已被验证遵循某个既定标准。
图 7-3 信任认证流程
这一过程对于应对不同司法辖区的多种法律与规则尤为重要。比如在处理欧洲客户数据时，知道哪些智能体已经通过 GDPR 合规认证，会非常有价值，从而避免未来访问客户数据时出现潜在问题。类似地，在处理医疗信息时，可能会触发其他法律要求；如果没有可靠的认证作为决策依据，将会引发大量问题。信任框架使得企业层面能够相信：智能体确实会按其宣称的方式行事。
运维（Operations）
为了让网格作为一个统一整体运行，需要具备从高层视角查看网格整体信息、并对网格进行控制的能力。这既有助于网络健康与维护，也有助于确保策略合规。为此，网格具备跟踪网络内所采取动作的机制，使管理员能够更清楚地了解正在发生什么。
其中一种视图是：查看聚合统计——例如网格内每个智能体接收到多少请求、这些请求从哪里发出。这能帮助理解网格在实际使用过程中形成的“自然结构”，并在某些智能体任务过载时暴露潜在问题点；它也能揭示网络正在出现的趋势性问题。类似地，也可以查看网格整体的统计信息——总请求数、总 API 调用数等——并用这些信息来决定后续应采取什么行动。
能“看见”智能体固然有用，但能从整体层面控制网格同样能帮助保持统一性。网格内的大多数智能体会由网格本身进行管理，这使得网络管理员能够控制网格：当某个智能体进入不理想状态时可以关停或重启；当智能体难以承载负载时可以补充资源；如果问题被追溯到某次版本更新，也可以将智能体回滚到先前版本。这种控制能力有助于保持网络健康并持续运转。
智能体生命周期管理（Agent Lifecycle Management）
虽然智能体生命周期的一些环节前面已经讨论过，但智能体网格被设计为能够端到端管理完整生命周期：从创建到注册、发布、监控、认证、更新，直至最终退役，网格覆盖生命周期的全部阶段。
生命周期的起点是创建智能体，这通常从市场（marketplace）开始，如前所述。通过市场，用户可以定义智能体要做什么，并从可用的工具、工作区和其他智能体中进行选择，为智能体执行工作提供能力支持。然而，当智能体准备就绪后，还必须发布并注册。注册本身很简单，但网格还必须为实际运行该智能体分配资源与计算能力。尽管具体细节会随网格的实现而变化，这一步同样可以通过市场来完成。
一旦智能体被发布并注册，它就会开始运行，等待并响应传入请求，同时向网格发送健康检查，确保网格知道它仍处于可用状态。在与用户及其他智能体交互过程中，智能体会记录事件；这些事件会被网格聚合，并对网格管理员可见，以便他们监控智能体状态。这些事件可用于判断何时需要扩容、或何时必须解决某个问题。
当一个智能体被证明能够正常工作后，可以将其送往认证：由认证机构检查智能体是否满足认证所要求的标准与行为。如果通过，认证会被附加到该智能体上，形成一个“背书印章”，使其更容易被他人信任。
随着变更不可避免地发生，智能体可以被更新，而网格会记录智能体的不同版本。更新机制确保始终有先前状态的记录，同时也允许控制新版本的发布时机；在需要时，还可能允许不同版本的智能体同时存在（例如，为了支持遗留应用）。版本管理也确保：一旦发现当前版本存在关键错误，智能体可以回滚到先前状态。
尽管许多智能体可能长期运行，但大多数不会永久存在，因此生命周期的最后阶段是退役。退役意味着将智能体从网格中移除：退役不会删除底层配置，但会将其标记为已删除，并关闭所有正在运行的智能体实例，从而确保该智能体不再可用。图 7-4 展示了智能体生命周期。
图 7-4 智能体生命周期
总结（Summary）
本章从“单个智能体的设计”进一步走向“企业级生态”的视角，说明了一个企业级生态系统——智能体网格（agentic mesh） ——如何把分散的智能体绑定成一个安全、可观测、可信的整体。我们探讨了它的核心服务组件：注册表（registry） ，用于编目智能体、工具与工作区并支持发现；监控器（monitor） ，用于跟踪执行并通过交互 ID 与目标 ID 将各步骤串联起来；交互服务器（interactions server） ，用于发起并管理对话；市场（marketplace） ，提供带告警与“单一系统可视性”的用户友好界面；工作台（workbenches） ，简化智能体的创建与部署；以及代理层（proxy） ，负责强制执行认证与授权。我们还审视了贯穿全局的能力，例如用于认证与合规的信任框架、用于管理健康状况与性能的运维视图，以及覆盖从创建与注册到监控、认证、更新与退役的全生命周期管理。这些组件共同把一组智能体转化为一个连贯的企业平台，从而在规模化条件下实现协作、治理与可靠性。
第 8 章将把重点从架构转向体验：它会依次讲解单点登录（SSO） 以及端到端继承的角色体系、用于快速定位与上手的首页视图，以及一个双边市场——消费方发现经过审核的智能体，创作者则以版本与可见性控制的方式发布智能体。随后，它会介绍面向消费者、创作者、信任与运维人员的工作台：展示用户如何与智能体聊天或在共享工作区中协作，生产者如何发布与认证，以及运维者如何观测并控制执行，把网格的安全、治理与可靠性落到一个可实践、可扩展的 UX 之中。
