行业领袖最近关于新兴智能体生态的表态相当激进，或许也带着一点理想化：黄仁勋认为，企业将拥有“数以亿计的数字智能体、智能智能体”。萨提亚·纳德拉则表示，“智能体将取代所有软件”。安迪·贾西更进一步：“会有数十亿这样的智能体，遍布每家公司，覆盖所有能想象到的领域。”
尽管如此，这些说法确实捕捉到了一个在早期企业落地中已清晰可见的事实：智能体时代已经开启。然而，愿景固然宏大，大多数组织内部的现实却要朴素得多——原型、概念验证和小规模试点层出不穷，但很少真正进入生产环境。问题不在于缺乏创造力或人才，而在于许多早期智能体项目仍停留在“科学实验”阶段：它们展示了技术潜力，却缺少企业应用所必需的品质——安全性、可扩展性、可观测性与可运维性。没有这些能力，即便再有前景的智能体，也往往走不出实验室，无法在真实世界的生产环境中部署。
本章将直接弥补这一鸿沟。我们将探讨智能体何谓“企业级”——也就是足够稳健，能够在现代组织复杂、受监管且任务关键的环境中可靠运作。为此，我们引入“微智能体”（microagent）的概念：建立在微服务基础之上的智能体。这一转变把企业软件几十年的运维智慧带了进来：模块化、容器化、持续部署与容错能力。随后，本章将沿着若干“生产就绪”的关键维度展开——安全性、可靠性、可解释性、可扩展性、可发现性、可观测性与可运维性——并说明为什么这些能力必须在设计之初就内嵌进去，而不是事后再“外挂”。
之所以这些主题如此重要，是因为从“实验型”走向“企业级”并不只是技术架构的升级，更关乎组织层面的可信度：一个在生产环境中失败的智能体，会削弱人们对整个概念的信任；而一个稳定可靠运行的智能体，则会成为更广泛自动化与智能化的可复用积木。本章提供的材料，就是完成这次跃迁的实用蓝图：如何设计让企业能够放心部署、能够安全集成、并能在规模化场景下有效治理的智能体。
归根结底，本章的目标是弥合“发明”与“落地实施”之间的裂缝。只要把智能体的设计扎根在几十年来指导企业系统的同一套原则上——安全、可观测、可解释与运维纪律——我们就能把今天那些充满希望的原型，转化为真正的生产就绪智能体。如此一来，我们也就迈出了通往黄仁勋、纳德拉与贾西所描绘世界的第一步：在那个世界里，数以百万计的智能、自主智能体，将成为企业日常运行中可靠、可依赖的一部分。
微智能体（Microservice Agents）
当下的 AI 工作流往往是单体式的，通常表现为一个单独的 Python 程序，以一个操作系统进程的形式运行。这意味着大语言模型（LLM）在同一环境里包揽了从输入解析、处理逻辑到最终输出的全部环节——灵活性受限，也难以与单体边界之外的外部服务或系统顺畅集成。
这种单体式 AI 工作流的根本缺陷在于：它无法在自身边界之外“原生协作”。由于这个单一的 Python 程序就代表了整个工作流，任何新功能——无论是一个专门化服务，还是某个领域工具——都必须直接塞进同一份代码库。久而久之，设计会变得脆弱、难以扩展、难以维护，也阻碍了把任务分发给不同专长组件的能力。
与之相对，智能体（工具也类似，但这里先聚焦智能体）是基于智能体生态中的一个“量子”——也就是最小的、仍然有意义的基本单元。一个智能体通常结合三类核心要素，才能有效完成任务：
- 大语言模型（“大脑”）
- 一组工具（“四肢”）
- 执行框架（用于任务规划与执行）
这三者的组合，使智能体能够解析传入请求、规划完成路径，并通过内部工具、协作智能体或外部服务来编排所需动作。借助这种方式，智能体可以应对那些会让单体式 AI 难以承受的复杂任务。
每个智能体都被打包成一个可部署单元，把其 LLM、工具与执行逻辑捆绑在一起。这种打包方式让智能体能够被独立管理、独立扩缩容、独立更新。基于现有流行框架部署智能体有多种路径，其中也包括面向分布式执行与资源管理的微服务式方案，例如 Ray 和 Dask 等。虽然 Ray 与 Dask 更偏向大规模分析计算的专门化场景，但微服务的优势在于：它在几乎所有企业环境中都已成熟普及，因此对许多组织来说是非常自然的落点。
微服务之所以是一个强有力的实现选择，是因为它背后沉淀了几十年的运维经验。为了把“基于微服务的智能体”与当前的单体式架构区分开来，我们引入一个新术语：微智能体（microagent） 。
如图 6-1 所示，微智能体通常以容器形式打包，并可通过 Kubernetes 或现代云平台在分布式环境中编排运行。这种模型让每个智能体都能独立运行、水平扩展，并在失败时优雅重启——这些特性与构建稳健 AI 生态的需求高度契合。
图 6-1 微智能体
通过采用微服务，组织还能复用既有的部署流水线、监控与日志最佳实践。换句话说，智能体应当只是更大基础设施中的“另一类微服务”，直接受益于那些成熟的韧性、负载均衡与容错模式。这不仅简化了智能体部署的技术难度，也能加快上市速度，因为团队可以继续使用熟悉的工具链与流程。
微服务的另一项关键优势，是其成熟的安全生态。几十年的实践已经沉淀出行业标准机制，比如用于服务间安全通信的双向传输层安全（mTLS），以及用于委托授权的 OAuth2。这些协议可以直接迁移到自主智能体之上，确保它们能够安全地彼此通信、并访问外部资源，而无需“重新发明轮子”。
除部署之外，一个智能体生态——我们称之为 agentic mesh（智能体网格） ——还能提供更高层次的发现与协作框架。智能体会在共享注册中心中登记自身能力与可用性，使其他智能体能够动态发现并调用它们。这种结构让生态扩展与更新变得容易：新增智能体后，注册中心会立刻反映其能力。agentic mesh 以及大多数生态能力将在第 7 章详细解释。
由于每个智能体都是自包含的，系统也就更容易持续迭代：开发者可以升级某个智能体的 LLM，或扩展其工具集，而不必扰动整个生态。并且，当某个智能体发生错误时，它不会拖垮全局；排障也能被局部化到责任组件上。
更重要的是，这种多智能体方式能促成单体式方案难以实现的协作：当任务需要专门技能或领域知识时，一个智能体可以把子任务直接委派给为该角色专门设计的另一个智能体。结果就是一种更灵活、更可扩展、也更易维护的 AI 驱动流程架构。
最后——尤其是对企业运维管理者而言——以微服务为基础的微智能体，使企业能够沿用成熟的 DevSecOps 实践：持续集成、容器编排、自动化安全检查等，从而确保系统运行平滑且安全。
智能体安全
企业系统——以及由此延伸的企业级智能体——都需要成熟的安全能力：认证（authentication） 、授权（authorization） 、身份管理（identity management）与安全通信（secure communications） 。这些能力是任何运行在敏感、受监管或高价值环境中的系统的基础。
然而，许多现有的智能体框架忽视了这些关键要素。对 mTLS、OAuth2 等标准的支持，以及与企业 Identity Book of Record（IBOR） 系统的集成，要么很少见，要么干脆不存在。不幸的是，开发者往往只能把各种临时方案“拼”在一起，这会带来实现不一致、重复劳动，以及潜在的高危漏洞。
缺少一致的身份生命周期管理、可强制执行的访问控制，或智能体之间加密传输，会带来实质性风险：允许冒充、数据泄露、或未经授权的工具调用。要解决这些问题，就需要采用那些已在分布式企业架构中被证明有效的安全框架。
建立在微服务之上的微智能体（microagents），为构建安全的智能体系统提供了成熟的基础。本节将讨论微智能体可用的若干安全维度：
- 微服务基础安全
- 容器安全
- Kubernetes 安全
微服务基础安全
mTLS 是一种通信协议，用于在客户端与服务器之间强制实施双向认证。在智能体场景中，mTLS 通过数字证书确保交互双方能够相互验证身份。握手完成后，所有通信都会端到端加密。这对智能体与智能体之间的通信至关重要，尤其当智能体跨网络分布运行时更是如此。mTLS 能防止中间人攻击与未授权的服务调用，为敏感、实时的智能体协同提供一种稳健的默认安全姿态。
OAuth2 是被广泛采用的授权框架，用于基于既定的权限与 scope 来控制对资源的访问。它把“身份”（认证）与“访问权限”（授权）分离开来，非常适合管理复杂的多智能体交互。通过 OAuth2，智能体可以在不暴露密码或长期凭据的前提下，请求或授予对工具或数据的访问权限。访问令牌可以是短时有效且带 scope 的，从而缩小攻击面，并对某个智能体代表另一项服务或用户所能执行的动作实施细粒度治理。
与 IBOR 系统的集成，对落实企业级身份控制至关重要。IBOR 维护一个权威身份注册表，覆盖用户、服务与设备，并管理它们从开通、变更到停用的全生命周期。当智能体与工具或其他智能体交互时，其身份必须在该系统中被验证。这样企业就能把对智能体的治理，按照同样的方式应用到人类用户或后端服务上，确保符合合规与审计标准。
密钥/机密（secrets）管理也是安全运行的关键要求。智能体往往需要访问 API、数据库或其他需要凭据或 API key 的工具。把这些值硬编码进代码或环境变量是不安全的。一个 secrets 管理系统（云原生、商业或开源方案都很成熟）可以按需签发、轮换与吊销凭据。每个微智能体都可以被配置为在运行时安全拉取 secrets，确保凭据不会被暴露或泄漏。
审计日志与可观测性同样必不可少。在分布式智能体系统中，弄清楚“谁在什么时候做了什么、为什么这么做”，对合规与取证调查至关重要。每个智能体微服务都应记录访问尝试、工具调用、认证事件与错误。集中式日志系统可以在跨智能体维度关联这些事件，并对异常行为发出告警。没有这些能力，未授权行为可能长期不被发现。
安全策略还必须考虑动态信任边界。智能体可能需要跨租户、跨虚拟网络或跨云区域运行。网络分段、零信任策略、以及基于上下文的访问控制（例如基于 IP、地理位置或设备）都会成为重要的控制手段。
容器安全
尤其值得注意的是：以微服务作为微智能体的底座，使得通过诸如 Docker 等常见工具实现容器化，不仅可行，而且相对容易。借助容器，每个智能体都可以被隔离，并拥有自己的安全边界。这种设计确保智能体不仅在逻辑上分离，也在运行时与网络层面实现技术隔离。容器化提供资源限制与进程隔离，使得某个智能体的被攻破或故障不太可能扩散影响到其他智能体，从而提升系统整体的容错性与安全性。
这种隔离也简化了安全策略的应用。每个容器都可以配置独立的网络策略、存储加密与运行时安全配置。例如，可以禁止容器以 root 身份运行、限制特定系统调用，或用常见的企业级入侵检测工具进行监控。由于这些策略是按容器施加的，它们允许根据每个智能体的功能与敏感度，制定差异化、且非常细粒度的安全姿态。
容器边界还促进持续部署与补丁更新，而这对保持安全环境至关重要。由于微智能体可独立部署，安全更新可以滚动发布到单个组件，而无需系统级停机。这种模块化也与 DevSecOps 实践高度契合——把安全直接集成进开发与发布流水线。
通过把每个智能体视作一个隔离的、受策略约束的微服务，微智能体模型让企业级安全不仅“做得到”，而且在运维上“管得住”。
Kubernetes 安全
Kubernetes 是用于大规模运行与管理容器的编排系统，因此也是容器化微智能体的理想运行时环境。
Kubernetes 原生支持证书轮换、身份注入、secrets 挂载、以及基于 sidecar 代理的安全通信。这种模块化让团队可以独立施加安全更新并定制策略，而不影响更大范围的系统。
Kubernetes 通过多项内建能力强化智能体安全，并把关键控制标准化、自动化。RBAC（基于角色的访问控制） 在 API Server 层面强制执行，允许对用户、服务与智能体进行细粒度权限分配。Kubernetes 的 service account 为 pod 提供身份，而策略定义每个 pod 在集群内能够访问哪些资源。这样可以确保智能体只访问管理员明确授权的资源，降低系统内部横向移动的风险。
另一项关键能力是 Kubernetes 的 secrets 管理。Kubernetes 允许在容器中通过挂载卷或环境变量安全使用 API token、密码与加密密钥等 secrets。secrets 存储在 etcd 中，对其访问由 RBAC 管控。尽管 Kubernetes 原生 secrets 管理通常会与外部系统集成以获得更强的加密能力，但即使仅使用原生能力，也能提供一种基础机制：把凭据安全分发给智能体，而无需把 secrets 写入代码或镜像。
Kubernetes 还支持网络安全策略与 pod 级隔离（pod 是 Kubernetes 的基本调度单元，容器运行在 pod 内）。网络策略可以限制智能体之间的通信路径，确保只有被明确允许的服务才能互通，从而降低未授权的智能体到智能体通信风险。此外，在 Kubernetes 上引入像 Istio 这样的 service mesh，可以在服务间启用 mTLS、进行流量加密、采集遥测数据并执行策略。这些能力能在无需大量自研的情况下显著强化每个智能体的安全态势。
采用微智能体并不仅仅是工程上的便利。相反，我们认为它是构建稳健、可扩展、可审计的智能体生态安全能力的先决条件。只要智能体遵循微服务模型，企业安全领域数十年的最佳实践就能直接迁移到智能体上。这使得智能体适用于受监管行业、公共部门部署，以及任何必须具备更高安全等级的场景。
智能体可靠性（Agent Reliability）
经验表明，随着大语言模型（LLM）能力提升，用户期望也会随之膨胀，希望充分利用这些新能力。但在我们一路狂奔的同时，总有一种持续的平衡关系存在：每一代新 LLM 都会带来一定的可靠性提升（例如更少的不准确与幻觉），可我们也立刻提出更高要求——结果不出所料，可靠性又会下降。至少在今天，一个基本事实是：尽管进步惊人，当前这一批 LLM 仍不足以处理复杂工作负载，更不用说那些对准确率要求极高的负载。实际上，这使得 LLM 被“降格”到更简单的工作负载上，限制了它在面向客户场景的使用，并进一步限制其在金融服务、医疗健康等强监管行业中的应用。
有没有更好的办法？
我们的看法是：今天用户对 LLM 的要求实在太多了。我们刚拿到一个更好的新 LLM，转头就让它做更多事，而我们又一次面对错误与不准确。正如常说的那样：周而复始（rinse and repeat）。
前面章节我们已经触及过可靠性，但现在我们再深入一点。问题的核心在这里：LLM 是概率系统，而概率会相乘并累积——有时甚至是灾难性的累积。因此，当让它做“小事情”时，LLM 往往极其可靠且准确；但让它做“大事情”时，微小错误就会级联，变成指数级增长的错误。从某种意义上说，小即是好（small is better）。
可靠性问题（The Reliability Problem）
任何用过 LLM 的人都知道，它们会生成不准的信息与幻觉。对于简单、简短的任务，这种倾向看起来是可控的——模型的回答通常可靠、可重复、也更准确；但当你要求（或提供）更多内容时，这种倾向会显著恶化。
以 LLM 驱动的软件开发为例，这恰好是当下最常见、也最实用的应用场景之一。用过这些模型的开发者会发现：短程序或单函数脚本往往可以较可靠地产出（例如无需人工修改就能运行），错误也较少。然而，一旦让模型生成更复杂的东西——比如一个多文件的软件项目，或一个更大、更复杂的组件——它的可靠性与准确性就会急剧下降。很多情况下，这些更长的代码输出要么第一次就跑不起来，要么需要人工重构、修补。
这种性能鸿沟使得大规模部署变得不切实际，甚至在某些情况下对那些要求高度正确性的项目而言根本不可接受。强监管行业尤其困难。金融、医疗、保险等行业受严格规范约束，几乎没有空间容忍 LLM 带来的事实性疏漏或语义错误。
一项 2024 年研究观察到了当时 LLM 能力存在的问题，强调更长、更“上下文密集”的输入会超出大多数模型的处理能力，从而把早期的不准确进一步放大。尽管更新的进展改善了一些情况，这些困难仍然是重大隐忧。当前 LLM 在处理和理解长、上下文丰富序列方面仍存在“显著缺口”，而“长上下文理解与推理对现有 LLM 仍然是个具有挑战性的任务”。
这进一步说明：尽管 LLM 很有前景，但在精度要求极高或复杂度很高的场景中，它们仍可能力有不逮。不难理解，组织机构在意识到错误可能带来高昂成本与法律后果后，往往不愿把一种在复杂需求下表现出不可预测性的技术深度集成进关键业务。遗憾的是，如果这些短板无法被解决，一些最具吸引力的市场机会仍将触不可及，尤其是在需要严格合规的行业，如银行、医疗与政府。
可靠性问题的根因（The Reliability Problem Root Cause）
如前所述，LLM 依赖概率方法而非固定规则（也就是说，它们是非确定性的），这解释了它们为何有时会生成错误或自相矛盾的回答。每个输出 token 都是在前一个 token 的基础上、结合从海量训练数据中学到的概率分布被选出来的，因此无法保证最终序列完全无错。更棘手的是，即使输入与环境条件完全相同，多次运行的输出也可能不同。相比之下，确定性系统在给定输入下会每次都产生准确（或至少可验证准确）且一致的输出。
这种行为的根因，我们称之为选择的组合爆炸（combinatorial explosion of choice） 。当模型处理短提示时，从开始到结束的路径很短，偏离正轨的概率也较低；但处理更长、更复杂的提示时，会出现更多分支可能。选择越多，出错概率越高；而错误会相乘、级联，因此会指数级增长。
简单来说，由于每个 token 都依赖上一个 token，一个很小的错误（尤其是发生在早期的错误）就可能在后续文本中不断放大，导致潜在的灾难性结果——至少也是不可靠、不可重复且不准确的结果。
图 6-2 展示了错误率如何级联。真实 LLM 的错误率当然远低于这里的示意。为简化数学说明，我们假设每个 token 的准确率是 99%，用来解释组合爆炸背后的数学直觉：
- 100 个 token：37% 准确率（0.99^100 约等于 0.37）
- 1,000 个 token：0.004% 准确率（0.99^1000 约等于 0.00004）
- 10,000 个 token：准确率极低、极低
图 6-2：选择的组合爆炸（Combinatorial explosion of choice）
这种情况或许解释了：一些最令人向往的 LLM 机会——需要大规模输出或复杂推理的那些——反而带来最大的错误风险。今天，这种权衡在决定把 LLM 用到哪里时，已经是一个实质性的考量。
潜在方案（Potential Solutions）
一些实践者试图通过迭代改写/精修来弥补准确性与可靠性的差距：先让模型给出第一版，再审查其中不一致之处并反馈给模型。这种方法对较小输出（例如短代码片段或简短叙述）效果不错。通过承认模型初稿的缺陷并系统纠正，开发者往往能得到更好的最终结果。
另一个相近思路是提示模型（如图 6-3 所示）逐步阐述其推理逻辑，有时被称为链式思维（chain-of-thought）推理。该方法试图通过强制 LLM 展示从问题到答案之间的中间步骤，减少不准确与幻觉。这可以防止模型在复杂推理场景中过早跳到缺乏支撑的结论，并已被证明能降低跑偏或无关输出的数量。然而，当回答变长时，它并不能消除“错误会复利式累积”的根本问题。
图 6-3：潜在方案（Potential solutions）
警告（WARNING）
归根结底是这样：当项目规模或复杂度扩大时，LLM 预测机制会导致不准确不断复利式叠加，从而限制了即便最好的提示或精修技术的效果。
那更好的 LLM 呢？用户常把更新、更先进的 LLM 当作解决准确性与可靠性挑战的直接药方。近期发布的模型在规模、训练数据与复杂度上不断突破，使它们能够处理更长输入并生成更复杂答案，而不至于立刻撞上“错误阈值”导致不可用。能力的提升确实把“错误开始显著影响可用性”的阈值往后推了——也就是说，在质量明显下滑之前，用户可以要求更高的细节或更广的覆盖范围。
但这种改善只是把不可避免的事情延后。一旦组织采用这些更高容量的模型，他们很快会发现：对更大输出的胃口也会同步增长。比如，团队在中等复杂任务上获得早期成功后，往往会推动更长、更细腻的交付物。最终，同样的指数级错误增长——“选择组合爆炸”问题——会再次出现，让我们回到使用更小模型时面对的同一循环（只是规模更大而已）。
例如，ChatGPT 的 GPT-3.5 发布时，用户对其自然语言交互惊叹不已，但不准确与可靠性问题很快就暴露出来。不久 GPT-4 推出，修复了一部分错误，于是我们又发现：在到达错误阈值之前，能做的事变多了。可我们仍然要求更多；后来更新模型又加入音频与视频能力，而我们依旧发现错误存在。
根本问题在于：企业——尤其是依赖高度准确结果的强监管行业——有时会发现，即便 LLM 的能力被放大，需求一旦超过某个范围，它仍然不够用。尽管可靠性能覆盖的窗口变宽了，但每增加一个 token 都会把出错概率进一步乘上去；概率本质并没有改变，所以当任务超过这个“有所提升但仍有限”的容量边界时，同样的错误级联会再次发生。
不幸的是，这凸显了仅靠“模型变大变强”并不足以解决问题。即便模型更好，选择的组合爆炸及其带来的问题依然挥之不去。
任务分解（Task Decomposition）
另一种方法是使用一个编排器 LLM（orchestrator LLM） 来解析并理解最初的请求。这个编排器可以是通用型 LLM（也可以是专门擅长任务规划的 LLM），它会判断需要做什么——也就是生成一个包含多个步骤的任务计划——然后去“盘点”现有可用 LLM 的清单，并把具体的任务步骤分配给最适合执行这些步骤的专用模型。
通过把一个更大的请求拆解为一系列更小、更离散的步骤——也就是任务分解（task decomposition） ——编排器能让每一步的提示词与范围保持短小且定义清晰。这些专用 LLM 彼此独立地工作，通常不需要超过其特定职能所必需的上下文。编排器负责协调这些 LLM 的执行、收集最终输出，并把它们组装成一个连贯的结果。
这种设计带来了任务的独立性。而正是这种任务独立性——也就是任务规划与任务执行由不同 LLM 分别独立处理——会降低整体错误率。某个领域中的错误不会在整个解决方案中级联扩散，因为每一步都有自己的边界，并不需要依赖单一执行线程里逐 token 推进的路径。
专业化还有一个有趣的副作用：它还能把 LLM 所需的数据范围收缩到仅为完成该任务所必需的数据。组织无需把每一份数据都交给通用型 LLM，而是可以把访问权限限制在那些被明确授权、可处理特定类型信息的专用模型上。比如，处理交易数据的金融 LLM 可以与撰写营销文案的模型相互隔离，从而降低不必要的数据暴露风险。
同时，这类编排方式也提供了相当可观的部署灵活性。团队可以按需接入新的专用模型——当它们被训练出来或变得可用时——并淘汰那些已经过时的旧模型。一切都围绕编排器“为每种情境挑选最佳资源”的能力展开，从而形成一个能够持续演进的动态环境，而无需对端到端架构进行彻底重构。
确定性执行（Deterministic Execution）
一旦计划建立，智能体就切换到执行角色，调用相关工具或其他智能体，让它们各自独立完成自己那部分工作。如图 6-4 所示，每个组件以最小重叠运行，以保持可靠性并降低错误跨任务迁移的概率。
图 6-4：确定性执行（Deterministic execution）
在这种方法中，智能体首先查询可用 LLM 与工具的清单。接着它决定由哪种资源来处理计划中的每一步——可能是专用（也许是领域特定）模型，也可能是通用模型。智能体把请求拆解为小而清晰的动作，确保任何单一阶段都不会变得失控或容易出错。每一步结束后，智能体会聚合输出，并依据约束或验收标准对其进行校验。如有需要，它可以要求某个工具或模型重试某个动作，或在进入下一阶段前先纠正错误。
这种基于智能体的方法也可以与企业基础设施结合，以一系列微服务的形式落地。每个微服务都能按组织要求进行加固、监控与扩缩容。运维人员会受益于更稳定的运行环境，因为这种架构限制了单次故障的影响范围，并避免了单一 LLM 试图端到端处理全部细节时出现的“组合爆炸”。微服务模式同样简化了发现与部署：更容易在不扰动整体流水线的情况下，发布带有专用 LLM 的新智能体。
专业化（Specialization）
LLM 的不断成熟与能力提升，已经被其成本的惊人下降所匹配——甚至可能被超越。这为更专业化的应用创造了机会：不必依赖单个包罗万象的模型。企业无需等待一个通用系统慢慢进化，如今已经“用得起”部署多个更小的模型，并针对特定任务进行调优与优化，如图 6-5 所示。事实上，走向专用 LLM 的趋势似乎不仅在加速，而且几乎不可避免。
这种专业化与其他行业中观察到的趋势相呼应。在半导体制造业里，公司曾尝试自己完成整颗芯片的全部制造，但很快意识到外包专门组件更高效。随着时间推移，高度专业化的晶圆厂出现，降低成本并提高质量。供应链网络中也有类似模式：每个参与者发展自身专长。逻辑很直接：当各方都聚焦于自己最擅长的部分，整个系统就会受益。
经济学家有时称之为比较优势理论（theory of comparative advantage） ：如果每一方都专注于自己具有独特优势的活动，整体生产率就会上升。把这一点应用到 LLM 上，意味着不会有某一个模型能统治所有用例。相反，会有多个专用模型繁荣发展，每个都针对更窄的领域进行训练。
图 6-5：LLM 专业化（来源：IBM Investor Day）
在实践中，专业化意味着用户不必依赖一个庞大的 LLM。他们可以立刻部署更小、更专用的 LLM，覆盖不同领域，并且不必牺牲性能。
一些组织已经开始编排多个语言模型，将一个通用 LLM 与一个或多个专用模型组合起来。每个 LLM 处理复杂任务中的不同部分，确保没有任何单个模型被迫承载整个问题。目标是：既利用通用模型的多面性，又利用更小、更聚焦的专用 LLM 在窄领域里的深度能力。
可靠智能体的未来（A Future with Reliable Agents）
LLM 会持续变得更好，但其非确定性设计以及由此带来的“选择组合爆炸”问题，意味着用户仍然会受到 LLM 错误、不准确与幻觉的影响。
与其等待下一代 LLM，还有其他选择。能力增强与成本下降正在推动专业化，而新的编排技术让我们能把更大的问题拆成更小、更可处理的问题，同时减少错误与不准确。当这些技术被实现为一种智能体架构——尤其是构建在微服务之上的架构——系统就能借力数十年来在安全性、可观测性与可运维性方面的经验，来应对这种新方法所带来的挑战。
而正是这种新方法，把一个“永恒问题”——非确定性 LLM 与选择组合爆炸——转化为一个分解问题：在一套可解、长期研究且被充分理解的解决方案基础上，通过分解来降低错误与不准确。
智能体可解释性（Agent Explainability）
智能体要想被广泛采用，前提只能是：我们信任它们。但“信任一个智能体”到底意味着什么？最简单地说，信任就是相信一个智能体会去做它本该做的事。
这就引出了当下智能体面临的一个紧迫挑战：智能体由 LLM 驱动，而 LLM 同时具有非确定性与不透明性。这带来两个重大影响：第一，驱动智能体的 LLM 有时会产出不可靠、不一致、且容易出错的输出；第二，当它们确实造成错误时，我们往往无法弄清楚它们为什么会那样做。
智能体可解释性正是为弥补这一缺口而来：让智能体的任务计划变得可见、可度量、可理解，开始打开智能体 LLM 的“黑盒”，并把信任引入整个过程。
信任鸿沟（The Trust Gap）
在人际关系中，信任是通过长期的可观察行为、一致的行动，以及共同理解逐步建立起来的。我们信任别人，不仅因为他们做了什么，更因为我们理解他们为什么这么做——我们通常能推断动机、判断一致性、形成预期。而当信任被打破时，我们会寻求解释。
但智能体并不具备人类那种直觉式的可理解性。因此，我们用来信任智能体的标准，必须更强调透明性与解释行为的能力。这之所以重要，是因为看起来我们很快就会把更多——而且更关键——的责任交给智能体。随着智能体更深地嵌入业务运营，错误发生的机会与错误影响都会随之扩大。
问题来源于两个相互关联的挑战：
- 驱动智能体的 LLM 是非确定性的——它们会犯错。
- LLM 是黑盒，无法看到其内部逻辑——当它们犯错时，我们弄不清原因。
不透明意味着：当智能体做对时，我们不知道它如何、为何得出结论；当智能体失败时，我们也缺少诊断失败原因所需的信息。对智能体决策过程缺乏洞察，是规模化信任智能体的根本障碍。
可解释性：来自现实世界的启示（Explainability: Real-World Lessons）
信任很少是“默认给”的；它通常是通过透明、监控，以及诊断失败的能力“挣来”的。换句话说，信任以可解释性为前提（见图 6-6），而在现实世界中，我们到处都在使用可解释性。
图 6-6：现实世界中的可解释性（Real-world explainability）
在航空领域，每架商用飞机都配备飞行数据记录器与座舱语音记录器——统称为“黑盒”。这些系统在后台静默运行，记录空速、高度、操纵输入、飞行员对话等关键数据。一旦发生事故，调查人员依赖这些数据重建事件经过、定位根因，并制定纠正措施。黑盒并不能阻止失败，但它确保调查人员能够理解并解释失败——而这种可解释性反过来推动系统性改进，并促成航空运输的长期信任。
在现代工厂里，“黑盒”以嵌入式传感器与监控系统的形式存在。工厂设备可以跟踪温度、振动、压力等诊断信息，几乎所有监控运行与早期故障迹象所需的指标都能被记录。解释设备为何故障——甚至更进一步，通过持续洞察来提前预防——已经成为现代制造的重要组成部分。
关键在于，这些黑盒其实并不“黑”；它们本质上是伪装起来的可解释性系统。它们真实地留下了可被检查、验证、解释的运行行为证据链。
这正是我们对智能体应有的期待。如果要把越来越复杂的任务交给智能体，它们需要做的不仅是给出输出。我们需要的智能体，应当像航空与工业里的对应系统一样，留下数据轨迹——一份可解释的记录：它打算做什么、它如何做、以及为什么结果会变成那样。
解释“可解释性”（Explaining Explainability）
智能体可解释性的核心是一个很简单的想法：把任务计划（task plans）当作一等公民的制品（first-class artifacts） 。在实践中，它由多个步骤构成，每一步都会产生自己的可解释性制品（如图 6-7 所示）：
- 任务计划（Task plan）
这包括智能体打算采取步骤的详细结构化表示。重要的是，由于智能体可以与其他智能体交互，这意味着要递归地捕获任务计划：任务计划/执行树中每个智能体在动态创建计划时，都要把其计划记录下来。 - 协作智能体与工具（Collaborating agents and tools）
这些信息用于标识并解释智能体打算与谁交互、或预期使用哪些工具。 - 参数替换日志（Parameter substitution log）
这解释输入（输入也会被记录）如何被分解为参数，并传递给协作智能体或工具。 - 任务执行日志（Task execution log）
这包括用于生成任务计划的指令，以及形成任务计划时所用的任何额外信息。
截至本文写作时，AI 工作流（区别于智能体）通常让 LLM 驱动端到端过程：它生成一个内部且不透明的计划，用隐藏逻辑摄入提示词与输入，使用不可见的执行能力，最后在任务完成后把计划丢弃。这样的计划是短暂的（ephemeral）。
图 6-7：任务可解释性（Task explainability）
在一个可解释的智能体框架里，任务计划会被捕获、持久化，并作为不可变的历史制品对外可见。但“制定计划”不等于“遵循计划”。因此，可解释性还要求把智能体的实际执行与其声明的计划进行对照监控。这包括追踪执行度量：任务进度、分支决策、意外条件、以及错误处理行为等，如图 6-8 所示。
这些执行追踪与任务计划历史结合起来，就构成了工程师、审计人员与监督系统进行诊断检查的基础。当行为看起来异常或不正确时，这些记录能让工作人员（治理人员、工程师等）重建端到端的任务计划与执行路径，判断智能体是否偏离指令，并评估这种偏离是否合理。
图 6-8：任务计划与任务执行可见性（Task plan and task execution visibility）
迈向可解释智能体（Toward Explainable Agents）
可解释性常被当作一种诊断工具。但在智能体生态中，可解释性必须被视为一种基础能力——是治理、合规与保障（assurance）的前置条件。随着智能体承担越来越复杂、越来越关键的任务，相关方不仅要知道智能体做了什么，还要知道它为什么选择那条行动路径。这在金融、医疗、关键基础设施等受监管行业尤其关键，因为透明不是可选项。没有将决策回溯到意图与计划的机制，智能体就无法被验证、审计或追责——信任也就无从建立。
可解释性也为认证与监督提供路径。正如传统软件在进入高风险环境前要经历严格的质量保障，智能体也必须证明自己能在预期边界内可靠运行。透明的任务计划——结合用于跟踪执行一致性的度量——为认证智能体行为提供了基础。不论是第三方审查、内部治理审计，还是监管申报，可解释性都让我们能够以可重复、以证据为基础的方式验证智能体将如何行动。缺少这一点，智能体仍是不可预测的——而不可预测必然导致不信任。
最后，可解释性支撑持续改进与可运维性。它提供对中间状态、决策过程与偏离计划行为的可见性；它支持更强的调试、适应性再训练，以及智能体能力的安全演进。在规模化场景下，这一点更关键：当成千上万甚至数百万智能体自主交互时，可信赖性必须以可解释设计为前提。
智能体生态必须把可解释性当作核心设计原则，而不是可选功能或事后补丁。为此，可解释性必须从一开始就被纳入设计：智能体必须从底层就具备透明的任务规划、可追踪的执行过程，以及可观测的度量指标。
挑战很明确：不透明的智能体必然会侵蚀信任。解决方案同样明确：我们必须设计能解释自身的智能体。
智能体可扩展性（Agent Scalability）
在一个可能拥有数千、甚至数百万智能体的生态系统中，有一个绝对明确的硬性要求：必须确保正在形成的智能体生态能够扩展。它不仅要能扩展到承载运行负载，还必须能扩展到让我们能够快速、高效地构建智能体；并且还要在运维层面可扩展，使我们能够有效管理规模巨大的智能体生态系统。
先把视角落到当下常见的实践：AI 工作流（AI workflows） 。我们不打算重新讨论 AI 工作流的设计，而是要强调：在企业从 AI 工作流全面迁移到智能体架构之前，几乎所有企业都会遇到的扩展性挑战。AI 工作流在支撑更大规模部署时，至少会遇到以下几个基本问题：
- 从执行角度无法扩展。
它们通常以单个 Python 主程序构建（即便通过 import 模块可以做一些“模块化”），只运行在单一操作系统进程中，显然无法扩展到超出简单执行负载的场景。 - 从研发角度无法扩展。
AI 工作流使用预定义的执行路径，这要求对端到端执行过程及各种边界情况都有完整认知；并且 AI 工作流只能与静态程序里显式定义的组件协作——这意味着，一旦要往程序里不断加入更多组件，很快就会变得不现实。显然，这种方式无法支撑规模化构建智能体。 - 从运维角度无法扩展。
虽然也可以把日志、告警、可追踪性、可解释性等运维“挂钩”加进 AI 工作流里，但如果缺乏通用模式与工具（通常应由工具包内建提供），这种做法在运维上是不可扩展的。
根因正如我们前面强调的：今天我们提出的要求实在太高——不仅对 LLM，也对当前的 AI 工作流架构本身。最终，这会导致一种被“妥协”的架构——无论在开发、运行时还是运维维度，都无法扩展。
可扩展性问题（The Scalability Problem）
当下智能体实现的核心问题在于：它们本质上只是一个单一的 Python 主函数，编排了整个执行流的每一步。这个方案用于演示或小规模任务尚可，但它天生缺乏支撑企业级大规模用例所需的灵活性与健壮性。正如前面提到的，开发者仍然可以把这种单体设计做得更“模块化”（通过导入与辅助函数），但中心逻辑依然会被汇聚到单一进程中，从而形成性能瓶颈并限制并发能力（图 6-9）。
图 6-9：AI 工作流与智能体的设计（引用材料来源：Anthropic）
从工程角度看，单进程模型也会带来性能限制：如果一个智能体需要解析大量数据、理解用户请求并快速连续生成响应，单一进程就可能成为吞吐瓶颈。与此同时，在多智能体设定中（不同智能体专注不同任务），把它们都绑在同一个操作系统进程上，会进一步放大崩溃、内存泄漏或阻塞式 I/O 调用的风险。一次单点失败就可能拖垮整个流水线，损害可靠性。相对地，分布式架构允许每个智能体运行在自己的环境中，避免局部故障演变为系统级故障。图 6-10 总结了 AI 工作流在规模化方面的挑战。
图 6-10：AI 工作流挑战
此外，大型企业要求健全的设计原则，例如容错、负载均衡、版本管理。而单体智能体框架通常缺少内建机制来处理这些问题；事后补丁式引入往往像“打补丁拼凑”，而不是一套连贯架构。相反，智能体需要一种自带成熟设计模式的架构：服务发现、流量路由、高可用等，这些在真实生产环境中都至关重要。
同样地，单体 AI 工作流（至少是当前多数智能体工具包里常见的那类）通常也缺乏有意义的自诊断或分析能力。智能体遇到未知故障时，可能抛出异常或记录错误，但恢复路径往往需要人来修代码。规模化运行智能体要求单个服务能检测错误、自主重启或改道，并持续运行。这对大规模企业环境尤为关键，因为要尽量减少停机，并满足 7×24 可用性要求。
到目前为止，我们讨论的是运行时扩展性问题，但这种单体设计同样引入了构建阶段（研发阶段）的扩展性挑战。依赖预定义工作流，迫使开发者必须预判智能体可能遇到的每个执行分支或边界情况，并手写回退逻辑。这在相对简单的任务上还勉强可行；但随着复杂度上升，可能的状态与转移路径会迅速变得不可管理。
更麻烦的是，这些单体 AI 工作流往往是“孤岛式”运作，协作对象（如果有）也仅限于同一代码库里显式定义的智能体。于是，添加功能的唯一方式就是把更多智能体不断塞进这份单体代码库。这不仅耗时，也削弱了“自治”的概念。真正可扩展的系统应该允许智能体彼此动态发现并进行协作——这是分布式计算中很熟悉的原则。
这里还存在一个哲学层面的落差：以 AI 工作流为主的单体智能体设计，与“自治智能体”之间并不一致。真正的自治意味着动态任务规划，以及对新障碍的优雅处理能力。单体 AI 工作流设计不支持规模化自治，因为它的自适应能力受限于预定义流程。
综合来看，这些约束说明了：为什么当代这代 AI 工作流——以单个 Python 主程序封装、并受预定义流程约束——难以扩展。要走向真正自治且可扩展的智能体，我们需要一次架构级重构。正如你所见，微服务为分布式部署提供了蓝图，能够承载许多专业化智能体，每个智能体都有自己的逻辑与资源。通过动态发现、灵活编排与健壮容错，企业级方案终于可以突破单体智能体范式的性能与扩展性天花板。企业需要这种转变，才能释放 AI 自动化与决策的全部潜力，尤其当目标是让成百上千个智能体协作完成复杂任务时。
我们如何解决这些问题？这正是接下来几个小节要回答的。
分布式架构（Distributed Architectures）
分布式智能体架构——在我们的微智能体（microagent）架构下变得可行——利用常见技术，实现智能体的规模化执行。
回顾一下：今天的智能体构建在单程序/单进程架构固有的瓶颈与约束之上。分布式架构通过把工作负载分散到多个计算节点或环境中，解决单进程瓶颈，使得大量智能体可以并行运行。与其把所有任务都灌进一个 Python 主程序，每个智能体都可以、也应该独立运行，管理自己的任务与资源。这会显著提升吞吐，尤其在需要摄取并处理海量数据的高负载用例中。图 6-11 展示了智能体规模化的若干优势。
图 6-11：智能体规模化优势
分布式架构也为动态扩展打开大门——这是支撑大型智能体生态的关键要求。按设计，这类架构允许按需拉起新的节点或进程。这种弹性有助于应对尖峰负载（算力需求可能剧烈波动）。在大型组织里，这也意味着不同部门可以维护独立的智能体集群，规模与各自业务需求匹配；同时在需要时仍可无缝通信，而不是在单一、单体环境里争抢资源。
除了纯粹的扩展能力，分布式还提升了智能体之间的部署灵活性。假设每个智能体都可针对特定领域专门化，但仍通过定义良好的通信协议与其他智能体交互。在这种设定下，团队可以新增专门化智能体或下线过时智能体，而无需重部署整个代码库。当企业出现新任务或新服务时，架构可以通过引入对应智能体来扩展，而不是重构一条单体工作流。组织想高频发布新功能、做安全隔离的实验，这种模块化都至关重要。
最后，分布式方法还便于在规模化场景下做集中式监控与分析——如果我们真要面对“百万级智能体”，这就是基础要求。把智能体作为离散实体运行后，工程师可以追踪每个智能体的健康指标（如 CPU、内存使用、错误率），并将日志汇聚到集中仪表盘。这种可见性不仅对故障排查关键，也对战略规划关键：如果某类智能体持续过载，企业就能据此增加资源配置。分布式系统里成熟的行业标准工具——例如分布式追踪、事件日志聚合器、监控 agent——早已存在，并且可以直接集成。
通用协作技术（Common Collaboration Techniques）
通用协作技术通过统一智能体与工具交互的方式提供一致性，从而支撑执行、研发与运维三个维度的规模化。
通用协作技术为智能体如何交换信息、如何协调任务提供统一框架，解决了单体智能体设计的最大限制之一。正如前面提到的，这一领域发展很快，像 Anthropic 提出的 Model Context Protocol（MCP） 等规范正在引领方向（见图 6-12）。但 MCP 如何与智能体集成？
图 6-12：MCP 与智能体
Anthropic 将 MCP 定位为：“一种开放协议，用于标准化应用如何向 LLM 提供上下文。”Anthropic 进一步解释：“把 MCP 想象成 AI 应用的 USB-C 接口。正如 USB-C 提供了连接设备与各种外设配件的标准方式，MCP 提供了连接 AI 模型与不同数据源、工具的标准方式。”
这听起来很棒，但如果把这个类比继续推下去，我们得到的只是 USB-C 的线缆标准；而我们真正需要的是：线缆之上到底传什么、怎么传的既定标准。因此，显然还有更多工作要做。
我们建议：智能体演进的下一阶段，应当解决运行在 MCP 之上的标准方法或协议。无论最终是 MCP 还是其他被广泛接受的标准，我们设想的方向与 MCP 的思路相近：
- 消息标准（Messaging standards）
先定义清晰、轻量的消息协议，基于 JSON、XML、Protocol Buffers 等广泛认可的格式，让分布式智能体彼此通信。 - 交互标准（Interaction standards）
让智能体以连贯一致的方式互相沟通以完成任务。 - 协作标准（Collaboration standards）
让智能体围绕相关主题、在长时间跨度内通过“对话（conversations）”进行交互（我们认为这与人类互动类比恰当；从技术角度也可视为 sessions）。
一个定义良好的协作（或对话）标准，通常不仅覆盖数据格式，还包括消息如何路由、确认机制如何工作，以及交互所需的安全与认证。它还应覆盖更高层的构造，例如：请求任务履约、信息交换、查询任务状态、或与人交互等。
采用一致的协作标准会让整个智能体生态更具韧性、也更易维护。工程师不必再调试一团硬编码集成的乱麻，而是可以在任何智能体都遵循的、定义明确的通道里诊断与修复问题。当系统扩展到数百或数千智能体时，这一点尤为重要：每个智能体专注自己擅长的领域，同时仍需要把任务或信息交接给其他智能体。协作摩擦降低，就意味着系统能更快、更安全地演进。
协作标准不仅简化即时交互，也使更高层的模式成为可能，例如事件驱动架构与发布-订阅消息，让智能体可以“监听”相关事件并实时响应。这为更高级能力打开大门——例如涌现行为与更动态的任务分配，因为智能体可以通过订阅其他智能体产生的事件，自发组成新的工作流。归根结底，协作标准是关键使能因素：它能把单体 AI 工作流转化为真正自治、网络化的智能体，使其能够随着组织需求变化而灵活扩展与适应。
对话/状态管理（Conversation/State Management）
对话与状态管理让智能体能够以可靠的方式管理长时运行的交互，从而提供运维层面的规模化能力。
对话管理使智能体可以在较长时间跨度内维持上下文。对于简单任务，一次性或短暂的对话可能就足够了；但更复杂的企业工作流可能会持续数分钟、数小时、数天，甚至更久。一个健壮的对话管理层能够确保每个智能体保留每次交换中相关的上下文，使智能体可以回看先前步骤、纳入新的进展，并在出现偏离时进行处理，而不必完全重新编写一套新的工作流脚本。该方法如图 6-13 所示，支持流畅的多轮交互，并能适应目标变化与不可预见的障碍。
图 6-13：长时对话与状态管理
现在，如果智能体对话可以跨越更长时间，相应地，智能体失败的概率或潜在风险就会上升——那么很显然，智能体必须能够在失败后优雅恢复。这正是状态管理的用武之地：它让智能体能够记住自己做过什么、与谁交互过、交互中发生了什么——我们称之为对话状态（conversational state） ——并利用这些信息从失败中恢复。
然而，如果智能体采用天真或简单的技术（例如把状态存放在本地环境变量中），那么一次崩溃或重启就可能把之前的一切信息都清空。相反，在健壮的状态管理下，智能体的“记忆”可以跨越崩溃与重启而保留下来，智能体也就能够从中断点精确续跑。这使得更高级的工作流成为可能：任务可以被中断、重新排程，或在必要时移交给另一个智能体。它也意味着意外故障不再需要整个流程从零开始重跑——这在大规模部署中价值巨大，因为每一分钟的停机都可能带来高昂成本。
除了持久化，良好设计的状态管理还包括并发控制、版本管理与回滚机制。在并发环境中运行的智能体，如果没有防护措施，就可能意外制造冲突或不一致状态。诸如事务式更新或乐观并发检查等技术，能够确保多个智能体可以安全地更新共享状态。如果发生冲突或错误，健壮的版本化与回滚机制可以把状态恢复到一个已知良好的版本，防止小问题演变为系统级故障。
最后，一致的状态管理方式还能简化监控、日志与审计。当所有带状态的智能体交互都通过同一接口（例如 API）路由时，就更容易追踪变更、生成有意义的日志，并审计某次更新是由谁、或由什么触发的。把状态管理内建到智能体核心设计中，组织就能缓解单体、纯内存工作流的局限，构建真正可扩展、具韧性的智能体生态系统。
将状态与对话管理视为智能体设计的核心组件，有助于开发者避免那种“拼拼凑凑”的方案——随着能力不断增加，这类方案会变得越来越难以驾驭。与其为每个边界情况或对话路径都编写定制代码，不如让智能体依赖标准化的方式来存储状态与管理多轮对话。通过消除“每新增一个智能体/工作流都要补装一套对话/状态追踪逻辑”的需求，组织可以大幅降低研发开销，并确保从第一天起，所有智能体都以可预测、可治理的方式运行。
企业级智能体能力（Enterprise-Grade Agent Capabilities）
企业级智能体能力让企业能够快速构建智能体、以规模化方式运行智能体生态，并且高效且有效地管理大型智能体生态系统。它们同时提供执行、开发与运维层面的规模化能力。
首先，如何做到“快速构建智能体”？起点是标准化智能体的开发方式——使用模板、编码规范与指南，确保整个组织的一致性。就像传统软件开发中的框架与代码风格指南一样，这些模板为新智能体提供了一份可遵循的蓝图，降低团队学习成本；同时也能抑制那种“每个智能体都临时写一套脚本与模块”带来的杂乱拼贴式结果。
通过一开始就采用文档完善的标准与最佳实践，企业可以建立一套连贯的基线，使得几十、几百、甚至上千个智能体都能在不反复造轮子的前提下部署。同样地，开发模板通常会定义：智能体如何通信、如何处理错误、如何记录日志、以及如何对用户或其他智能体做认证。因此，当每个智能体都遵循同一蓝图时，创建智能体并把它们集成进生态系统会变得更容易、更快、成本更低。
除了研发一致性，企业级能力还会高度关注运行时议题，例如安全性、可发现性与可观测性。一个健壮的安全模型——覆盖从传输加密到基于角色的访问控制——确保每个智能体只执行被授权的动作，并以负责任的方式处理数据。可发现性机制（如服务注册表或智能体目录）让新智能体或新服务能够动态发现彼此，避免把端点硬编码而导致的脆弱性。可观测性工具——从日志聚合到分布式智能体对话追踪——为运维团队提供网络级的实时可见性，使其能够诊断问题并衡量整个智能体网络的性能。
可靠性也是企业级智能体设计的另一根基础支柱。目标是让每个智能体都能抵御故障（例如网络中断、硬件崩溃、或数据处理中出现的瞬态错误）。诸如自动重试、熔断与负载均衡等技术，应当成为默认工具箱的一部分，而不是可选的事后补丁。
在运维与治理层面，可解释性与可追溯性变得至关重要。许多行业——尤其是医疗、金融、政府等受监管行业——必须遵守规则与政策，要求对自动化系统执行的所有动作提供清晰的审计轨迹。因此，能够记录“谁请求了某个动作、何时完成、为何做出某个决策”的智能体，与监管与合规要求天然契合。用于捕获与存储这些元数据的机制，应当成为智能体架构的内建部分，以确保即便系统横跨数百个互联智能体，问责与合规检查仍然可行。
最后，“认证”或“资质认可”的概念建立在上述能力之上——研发标准、安全、可发现性、可观测性、可靠性与可追溯性——从而为“智能体满足企业环境的严苛要求”提供保证。无论是达成内部质量基准，还是应对外部审计，智能体都必须证明自己适用于大规模、任务关键型运营。如果从设计之初就把这些能力内建进去，认证流程就会变得不那么繁琐。
因此，尽管某些企业级能力直接影响运行时扩展性并使你能够运行大型智能体生态系统，但同样重要的是：还有一些能力让你能够规模化构建智能体，另一些能力则让你能够有效管理大型智能体生态系统。最终结果是：一个由大量智能体组成的生态系统——构建速度快、能承载高吞吐任务，并且具备现代企业在大规模部署智能智能体时所要求的治理、可见性与可信保证。
作为复用“量子”的智能体（Agents as the Quantum of Reuse）
智能体是新的、更细粒度且可复用的企业组件，提供开发层面的规模化能力。
当把智能体视作复用的核心单位——或者说“量子（quantum）”——组织就能开发一次、在不同场景中多次复用，而无需反复造轮子。需要指出的是，这并不是“智能体特有”的东西，而是把过去几十年的软件最佳实践应用到了新的对象上。
然而，复用智能体会以一种深刻的方式改变“复用单位”。过去，复用单位可能是函数，通常来自某个库。随着标准通信方式（HTTP/REST、gRPC 等）的演进，API 封装了更高层的业务能力，从而提供了更有价值的复用单位。
而到了智能体时代，我们不仅能够封装更高层的抽象，并且还能以更简单的方式交互；同时还可以引入“智能”能力（通过嵌入在智能体中、或由智能体可调用的 LLM），去处理更复杂的业务逻辑。换句话说，智能体成为复用演进的自然下一步。
这种复用能力有助于解决开发扩展性挑战——这是构建大型智能体生态系统时最紧迫的障碍之一。如果团队每次都被迫从零开始，那么每个新智能体的爬坡成本会非常高，并行项目也会面临重复劳动的风险。相反，复用智能体可以加速项目时间线：它把重心从“搭基础功能”转向更高价值的能力，例如定制化、领域智能与面向用户的改进。更重要的是，它通过鼓励一致的开发实践而不是让一次性方案泛滥，来抑制技术债务的增长。
关键在于：智能体生态越大，复用的激励与可能性就越强。随着注册表或市场里填充了越来越多的专用智能体，团队越来越容易发现：自己需要的东西其实已经有人做过——无论是语言翻译智能体、欺诈检测智能体，还是物流规划智能体。每个智能体都像是一块乐高积木，可以嵌入一个由大量可互锁服务组成的巨大系统。这个正反馈循环会加速创新：通过降低新增功能的门槛，组织可以快速原型化并部署由现有智能体组合而成的解决方案，以应对突发的业务需求或市场变化。
从商业影响看，这种复用范式能够带来显著的成本节约与更短的交付周期。通过复用既有智能体，开发团队可以把精力聚焦在战略目标上——例如优化用户体验或提升模型准确性——而不是重新开发通用能力。在竞争激烈的行业中，上市速度往往决定领先或落后。因此，采用“智能体作为复用量子”的思维方式，能确保每个新项目不仅建立在稳固基础之上，也会反过来贡献给更广泛的生态系统，从而推动长期增长并带来更高、更快的投资回报。
扩展 LLM 基座（Scaling the LLM Foundation）
在扩展智能体时，除了智能体本身的设计之外，最直接的挑战之一，可能就是语言模型推理的原始成本——而推理成本提供了智能体进行任务规划与决策所需的基础能力。每一个会推理、会规划、会对话的智能体，本质上都在运行一次大型模型查询，而且往往为了完成哪怕单个任务，也需要多次调用。在小规模时，这类成本还能被试点项目或特定场景消化。但当一个组织设想要同时运行成千上万——甚至数百万——个并发智能体时，经济账会发生剧烈变化：在小规模下每次交互可能只要几分钱，但一旦乘以交互的规模、频率与持续时间，这个成本就可能迅速膨胀为数百万美元的运维支出。
因此，企业必须面对的不仅是推理成本本身，还包括编排、缓存、微调与专用硬件等次级成本。诸如批量处理请求、用更小的模型处理日常决策，或在边缘侧部署经过微调的轻量化智能体等策略，会成为“规模化可行”的关键。落到实践上，这意味着要构建一种分层架构：并不是每一次智能体调用都需要动用一个“满血 LLM”。否则，推理成本就会成为限制增长与创新的闸门因素。
但即使采用了各种优化策略，成本扩展仍然与计算与能源的物理现实密不可分。为了支撑数百万智能体的运行，企业与云服务商都在大规模投入建设下一代数据中心，配备专用 GPU、AI 加速器与高带宽互连。这些设施需要巨量电力与制冷能力，从而形成对全球能源供应链与区域基础设施的新依赖。从某种意义上说，大规模智能体生态的未来，受限程度可能会和算法一样多地受限于千瓦与兆瓦。这个未来能否长期成立，不仅取决于聪明的软件架构，也取决于数据中心规模与电网是否能以足够快的速度扩张，从而为一个遍布各处的 AI 智能体世界供能。
智能体发现（Agent Discovery）
要让智能体发现机制真正跑起来，首先需要一个元数据仓库，用来编目记录智能体信息（见图 6-14）。就像数据目录（data catalog）一样，智能体注册表（agent registry）是更大智能体生态系统里，关于智能体（以及智能体工具）信息的可搜索“权威记录库（book of record）”。智能体会查询注册表来获取其他智能体的信息；而人则会搜索智能体市场（agent marketplace）——也就是注册表之上的一个用户界面——去找到他们希望交互的智能体。
其次，你需要一个智能体生态的“织物层”（fabric）——一个智能体网格（agentic mesh）——它不仅提供智能体交互与协作的平台，也提供智能体自注册、并最终实现彼此发现的能力。
图 6-14：智能体发现的组成组件
最后，你需要让智能体知道生态织物层与注册表服务的存在，并使用这些服务去找到其他智能体。
不只是一个搜索问题（Beyond a Search Problem）
把智能体发现理解为一个搜索问题，很容易让人产生误解。搜索问题的典型目标，是从成千上万潜在协作者里找出 Top 10–100 个结果。但在智能体生态里，我们要的不是 Top 10–100 个智能体，而是能够在正确的时间为正确的任务找到唯一正确的那个智能体。
所以，我们并不需要“搜索”本身，而是需要相关性发现（relevant discovery） ——一种能够在智能体生态中精准“滤信号、去噪声”的方法（见图 6-15）。
图 6-15：智能体发现——在噪声中找到信号
这就引入了一个微妙的设计问题：什么才是“最相关”的智能体？智能体需要找到的，不只是技术上“能做这件事”的协作智能体，还必须找到一个与具体目标与约束对齐，并且遵守该任务所要求政策的智能体。换句话说，“正确的智能体”不一定是能力最强的那个，而是在当前上下文中最合适的那个。
找到正确的智能体（Finding the Right Agent）
实际问题在于：如何从庞大的智能体生态里筛选并找到那个恰好正确、且满足某个特定需求的单一相关协作智能体。我们建议两类过滤方式（见图 6-16），称为发现范围规则（discovery scoping rules） ：
- 可见性范围（Visibility scope）
粗粒度过滤：显式限制可被纳入协作候选的智能体集合。 - 特征范围（Characteristics scope）
细粒度过滤：在候选集合中进一步锁定具备“满足请求所需精确属性”的智能体列表。
图 6-16：智能体发现——可见性与特征范围规则
本质上，这些发现范围规则先为智能体提供“如何识别满足特定任务需求的协作者”的指导，然后给出“找到那个唯一正确智能体”所需的属性集合。一个最小的属性集合至少应包括：
- 目的（Purpose）
智能体的主要目的。 - 描述（Description）
更详细地说明智能体做什么、为什么做、以及它解决什么问题。 - 政策（Policies）
智能体所遵循的一组规则（企业、监管或其他规则）。
可见性范围与特征范围可以用两种主要方式实现：
- 严格命名（Strict naming）
把协作者列表限制在一组非常具体且有限的智能体之内；这在需要确定性选择与使用的场景中效果很好（例如受监管行业）。 - 灵活命名（Flexible naming）
使用正则表达式来指定协作者列表；这允许智能体创建者基于一些标准来指定协作者，例如智能体命名空间（“该命名空间下的所有智能体都是有效协作者”）。
我们的基本观点是：随着智能体数量增长，智能体发现——也就是在正确的时间为正确的任务找到唯一正确智能体的能力——将成为智能体生态系统的决定性能力之一。希望本节能让你理解一种应对这一基础需求的方法。
Agent Observability and Traceability（智能体可观测性与可追踪性）
企业需要对智能体的性能、资源使用情况以及错误状态保持持续可见——这些要求与任何其他企业系统并无二致。这种可见性通常用“可观测性（observability） ”来概括。在现代分布式系统中，可观测性指的是：基于系统产生的数据——日志（logs） 、指标（metrics） 、追踪（traces） ——来衡量系统内部状态的能力。它让运维人员和开发者能够监控系统健康状况、检测异常并诊断问题。缺乏可观测性时，系统就会变成难以排障、难以扩展、也难以信任的黑盒。
同样的挑战也适用于智能体，而且往往更为尖锐。智能体并不是简单的请求-响应应用；它们经常维护长时对话、调用工具、在多个参与方之间协调，并持续演化内部状态。一旦出现问题——比如意外的工具失败、对指令的误读、或协作方无响应——要定位问题源头，就必须能看到智能体的决策过程、对话状态以及运行指标。这在受监管或安全关键环境中尤为重要，因为这些场景通常强制要求审计轨迹与事后复盘。
可追踪性（traceability） 建立在可观测性之上，它使我们能够把更大范围的多智能体（或多工具）对话中的离散事件关联起来。在智能体生态里，这意味着要把每一次动作——一次工具调用、一条智能体消息、一次数据库写入——都绑定到某个追踪或任务标识符（trace/task identifier）上。这个标识符让系统管理员与开发者能够沿着智能体与工具链路，追踪单个请求从开始到结束的生命周期。没有可追踪性，调试分布式故障或理解级联行为就会变得极其困难，甚至难以承受。
基于微服务的智能体（即 microagents）为内建可观测性与可追踪性提供了可行的基础。企业系统多年来一直在精炼用于观测微服务的技术，例如服务网格、分布式追踪平台与指标聚合工具（例如 Prometheus 和 Grafana）。微智能体可以直接受益于这些实践：每个智能体服务都能用标准库做埋点、暴露健康检查端点，并通过 HTTP 头或消息元数据传播追踪上下文（trace context）。这些都是成熟、文档完善、并在多语言多平台上广泛支持的既有技术。
一个“可观测性优先（observability-first） ”的智能体框架，应当确保所有智能体默认就具备采集运行指标的能力。这些指标可能包括 CPU 与内存使用率、请求延迟、错误率，以及工具调用成功/失败计数。除了一般指标外，智能体还应暴露状态迁移、对话深度、以及待处理请求队列等信息。这类数据让监控与容量规划真正有意义。关键在于：这些埋点能力应当内置在框架里，而不是事后补丁，或交由每个开发者各自实现。
Agent Operability（智能体可运维性）
对企业系统而言，在线率、可扩展性与韧性通常被视为基线预期。满足这些要求需要对“可运维性（operability） ”进行严格投入——它是一组确保系统可以被可靠监控、维护与支持的实践集合。可运维性涵盖可用性监控、故障检测、系统告警、事件响应流程，以及结构化的部署工作流。缺少这些，即使最先进的系统也可能变成负担：故障不可预测、支持成本高昂。
智能体把可运维性带入了新的复杂度。与响应离散请求的传统服务不同，智能体往往进行长时、状态化的交互；这些交互可能涉及多个工具、跨越多个系统，并且会随着“学习到的行为”而演化。因此，必须确保智能体能够发出健康信号、响应存活探针（liveness probes），并在出现异常或故障时产生告警。同样重要的是，要与现有企业运维工具打通，以便问题出现时能及时诊断与介入。
有效的可运维性还要求对日志与审计进行谨慎设计，尤其考虑到智能体可能处理的敏感数据。与人或金融系统交互的智能体可能接触到个人可识别信息（PII）、健康记录或支付数据。日志实践必须遵守隐私与监管标准，例如《通用数据保护条例》（GDPR）或 PCI DSS（支付卡行业数据安全标准）。这意味着日志应对敏感内容做脱敏或匿名化，使用访问控制的存储，并避免记录过量细节，以免日后被外泄或滥用。安全的审计轨迹既是内部治理所需，也是外部合规所需。
微智能体为高可运维的智能体系统提供了一条务实路径。它们天然契合 DevOps（或 DevSecOps，即包含安全的 DevOps）模型，把开发、安全与运维整合为连续生命周期。企业在微服务管理方面积累的数十年经验可以直接迁移：容器健康检查、服务监控、通过 CI/CD 管道进行自动化部署，以及蓝绿发布或金丝雀发布等发布策略。微智能体可以复用既有的工具生态与标准协议，用于可观测性、告警与回滚，使运维管理变得可控且可靠。
为了把这些实践制度化，我们建议引入一门专门学科：AgentOps。AgentOps 继承 DevSecOps 与 LLMOps，但针对智能体的独特生命周期需求做了扩展。它强调强开发者体验，确保智能体是模块化、可组合、可测试的；它支持把智能体从开发阶段受控迁移到生产环境，提供健壮的版本策略，以及在不同智能体版本之间进行动态路由。通过 AgentOps，企业可以确保智能体系统在负载下依然可运维、在设计上默认安全，并能在需求持续演进时保持敏捷。
Agent Testing（智能体测试）
测试智能体与测试传统软件在根本上不同。在传统系统里，输入与输出遵循确定性模式：相同输入应当总是产生相同输出，因此开发者可以使用断言、回归测试以及固定的对比逻辑。但智能体运行在概率空间中。它们的推理由大语言模型（LLM）与上下文向量嵌入驱动，而不是由固定规则集驱动。结果就是，那些确定性的测试框架——依赖字符串匹配或固定断言的框架——会变得脆弱且具有误导性。相反，智能体测试必须评估响应的语义保真度，关注的是“智能体是否正确完成了意图”，而不是“它是否返回了一模一样的词”。
Testing LLMs（测试大语言模型）
测试 LLM 面临一个众所周知的挑战：非确定性（nondeterminism） 。即便在完全相同的条件下，同一个提示词在不同运行中也可能产生略有差异的答案。这源于温度采样、概率式 token 生成以及持续变化的上下文嵌入。传统的“精确匹配”断言很容易被打破。为了解决这一点，业界采用了多种技术。一种常见方法是语义相似度评分，使用余弦相似度或基于 embedding 的距离度量，判断两段回答是否表达了等价含义，即使措辞不同。另一种是无参考评估（reference-free evaluation） ：由辅助模型依据任务特定标准（如准确性、连贯性或完整性）对输出打分。
第二类技术关注统计稳健性。测试不再只评估一次输出，而是多次执行测试并聚合结果。模型的可靠性以分布形式表达：它产生可接受回答的频率如何、推理一致性如何、性能是否随时间漂移。这种概率式方法用置信区间与期望波动范围取代了简单的“通过/失败”判断。
最后，对抗性与场景化测试与语义、统计方法互补，用于探索边界情况。测试者会刻意扰动提示词、改变表述、或注入不完整数据，以检查模型是否仍能保持稳定、准确与一致。综合而言，这些技术——语义评分、统计验证与对抗性变体——构成了 LLM 测试实践的基础，使开发者能够面对天生非确定但仍可度量的系统。
Extending to Agent Testing（扩展到智能体测试）
智能体测试直接建立在 LLM 测试实践之上，但它把问题扩展到了更广、更复杂的领域。智能体不只是一个 LLM——它还是对推理、工具与协作的编排器。这意味着测试不仅要验证回答在语义上是否正确，还要验证其在多步骤、多轮交互与多次工具调用中的行为是否连贯、是否忠实于目标。智能体通常会规划、推理、委派并在长序列中响应；每一个阶段都会引入潜在故障点，而这些故障点无法用单轮的 LLM 测试覆盖。
当多个智能体协作时，复杂度进一步放大。单个 LLM 的输出还能围绕意图对齐进行评估，但当多个智能体相互交互——每个都在解释上下文、轮流回应并独立决策——测试挑战就会呈现组合爆炸。多智能体评估必须考虑集体意图（collective intent） ：这组智能体是否完成了被交付的目标？它们的消息是否连贯、相关且一致？是否出现了反馈回路或相互冲突的推理？随着智能体数量增长，测试空间维度也随之上升，使穷举式评估变得不可行。于是测试框架通常依赖分层评分（hierarchical scoring） ：评估局部（逐智能体）保真度、全局任务完成度，以及智能体间协作质量。
因此，测试逐渐变成对涌现式正确性（emergent correctness） 的研究。问题不再是每个智能体是否输出了与以前完全相同的内容，而是整个对话是否收敛到正确且符合上下文的结果。对这类涌现行为的评估往往需要元智能体或评估器——由其他模型读取交互日志，用语义而非句法的方式对性能进行打分。
Testing Microagents: Determinism Within the Probabilistic（测试微智能体：概率之上的确定性）
好消息是：由于企业场景中的智能体往往以微智能体（microagents） 形式实现——把智能体与 LLM 封装在微服务中——传统软件工程中的许多确定性测试技术仍然适用。智能体的概率式推理可能难以用固定输出测试，但其外围基础设施完全可以用常规方法测试，包括：验证通信接口（确保消息符合 schema 与协议）、安全与认证（验证 mTLS 握手、token 交换与基于角色的权限）、以及可观测性钩子（确认指标、追踪与日志按预期发出）。
此外，性能、容错与恢复测试依然是确定且可度量的。工程师可以模拟消息丢失、高延迟或容器重启，并确认微智能体在压力下仍能以可预测方式运行。集成测试可以验证智能体是否正确向生态注册中心注册、订阅正确的事件流，并能从瞬态故障中优雅恢复。这些微服务级检查确保：即便智能体的“推理结果”会有变化，它的系统性行为——安全通信、可靠运行与可观测——仍然稳定且可测试。
实践中，有效的智能体测试因此结合两门互补学科：对语义与行为正确性的概率式评估，以及对系统机制的确定性验证。前者承认推理的不确定性；后者约束基础设施的确定性。两者结合，形成一种平衡方法，使微智能体能够智能演进，同时不牺牲企业级系统所要求的运维严谨性。
AgentOps: DevOps for Agents（AgentOps：面向智能体的 DevOps）
智能体可运维性与 AgentOps 处在同一条连续谱上：前者定义生产级智能体必须达到的状态——高在线率、韧性、可观测性与合规；后者定义在多智能体、多团队、多环境下持续维持该状态所需的实践。换言之，可运维性描述“要达成什么”，而 AgentOps 描述“如何达成”。可运维性确保单个智能体运行良好；AgentOps 确保整个智能体生态能够被可靠地构建、部署并在规模化条件下持续演进。两者共同构成企业级智能体管理的基础。
AgentOps 建立在一系列运维学科的谱系之上。DevOps 通过自动化、持续交付与快速迭代统一了软件开发与 IT 运维；LLMOps 把这些实践扩展到 LLM 生命周期——训练、评估、部署与监控。AgentOps 继承二者，但增加了一个新维度：它要管理能够自主运行、持续演化、并彼此动态交互的智能推理实体。它把 DevOps 的流程纪律与 LLMOps 的模型治理融合起来，并扩展到自治智能体这一复杂、非确定的领域。
在核心层面，AgentOps 提供一套框架来管理智能体的全生命周期——从创建与测试到部署、监控、反馈与最终退役。它承认智能体不是静态软件工件，而是会随着推理模型、上下文与策略变化而改变行为的演化系统。管理这种演化需要行为版本化、回滚、可解释性监控与持续验证。简而言之，AgentOps 将“智能”运维化，使智能体在生产环境中的行为变得可预测、可追踪、可问责。
与主要关注确定性代码与基础设施的 DevOps、或治理模型训练与服务的 LLMOps 不同，AgentOps 必须管理“运动中的智能行为”。它既处理 LLM 的非确定性，也处理多智能体协同：跟踪的不仅是延迟或在线率，还包括推理质量、语义正确性与行为漂移。它把安全、合规与伦理审查直接嵌入 CI/CD 工作流，形成治理感知的发布流水线——确保每次更新在上线前都被验证。
AgentOps 还把“舰队级”（关于智能体舰队将在第 7 章深入讨论）可观测性与语义评估带入日常运维。在大规模生态中，只监控单个智能体是不够的；AgentOps 会在网络层面聚合行为指标——跟踪准确性、协作健康度以及智能体之间的涌现交互。它利用这些洞察检测异常、回放对话，并将决策追溯到根因。这种系统级可见性把调试从传统的故障排查提升为行为分析，让团队清晰看到智能如何在 mesh 中传播。
从很多方面看，AgentOps 是让智能系统复杂性“有序化”的运维学科。它融合 DevOps 的自动化、LLMOps 的模型治理与企业 IT 的可靠性标准，并把它们扩展到推理与协作成为核心操作的领域。它确保智能体不仅能运行，还能安全地演进——随着规模与影响力增长，依然保持可靠、可解释且对齐。由此，AgentOps 把自治从研究问题转化为可重复、可治理的企业实践。
Summary（总结）
本章以 Jensen Huang 与 Satya Nadella 对“未来数百万智能体改变企业工作方式”的大胆愿景开篇。我们相信这个未来正在到来，而为其做准备并非可选项。
企业级智能体不是锦上添花，而是后续一切工作的必要基础。这正是微智能体（microagents）登场之处。建立在微服务久经验证的优势之上，微智能体把可靠性、可扩展性与韧性带入智能体世界，同时也具备安全、可发现、可观测与可运维能力。从各个意义上说，它们都是企业级的。更重要的是，它们在今天就已经准备好承载明天最雄心勃勃的智能体愿景。
到目前为止，我们已经走完了从理解智能体本质到定义其企业级标准的路径。现在，是时候迈出下一步：在第 7 章中，我们将看到这些企业级智能体如何在企业级生态中汇合。同时，第 7 章也将引入 agentic mesh——那条让智能体在企业内外得以生长、协调并规模化的“连接组织”。
