在更早的章节里，我们论证过：智能体的挑战，归根结底是一个规模（scale） 问题。少量智能体可以靠人工管理，就像早期服务器或微服务曾经也能手工部署一样。但当 mesh 成熟时，我们面对的将不再是几十个、甚至几百个智能体——而是成千上万，甚至数百万个。它们半自治运行，却仍被要求符合企业级的安全、治理与可靠性标准。到那时，瓶颈不再只是技术本身，而是以足够快的速度创建与维护这些智能体的过程，以满足需求。靠手工一个个构建智能体，根本无法扩展。
这也是为什么前面章节引入了“编队（fleet）”这一概念——它是对规模化问题的结构性回应。编队把智能体组织成连贯、可管理的单元，使其可以作为一个整体被启动、监控与治理。编队之于智能体，就像部门之于员工：通过把相关角色纳入共享监督与共同目的之下，让协作成为可能。但即便有了编队，还需要再上一层的可扩展性。编队让我们能高效运营大量智能体，却并没有告诉我们如何高效地创建它们。为此，我们需要工厂。
智能体工厂（agent factory） 是 agentic mesh 演进中的逻辑下一步。它提供构建智能体所需的能力与基础设施，使智能体能以快速、可靠且一致的方式被生产出来——套用同样的工业逻辑：它曾把早期的软件“手工艺”转变为现代 DevOps 与持续交付。就像软件构建流水线会自动完成编译、测试与部署，智能体工厂也会自动完成智能体的创建、配置、认证与发布（rollout）。它把云基础设施中的规模化经验，迁移到“认知基础设施”上。
本章将探讨如何设计这样的工厂：它有哪些组件、组件如何交互、以及它如何把智能体开发从手工过程变成自动化过程。我们从“智能体开发周期”开始，它把经典的软件开发生命周期（SDLC）调整到智能体的特定需求上：定义目的、设计交互 schema、配置对工具与其他智能体的访问，并验证合规与性能。随后，我们进入规模化构建智能体：用模板、自动化与认证流水线替代手工配置。
接着我们把视角扩展到编队，展示工厂如何组装能够协同工作的智能体群组，把它们作为模块化、可复用的团队来运行。编队模板与标准化编排模式，使得在极少人工介入的情况下生成整组可互操作的智能体成为可能。最后，我们讨论规模化运维：部署流水线、监控与观测型智能体、编队更新，以及最终的退役（decommissioning）。本章以对未来的展望收尾：在那个未来里，智能体会构建其他智能体，把自动化进一步延伸到创造过程之中。
综合来看，这些概念代表了智能体开发的工业化。智能体工厂把智能体从定制化作品转化为可规模化的数字产品：具备可重复流程、经认证的模板，以及内建的生命周期管理。这正是 agentic mesh 从“有前景的原型”走向“可运营的生态系统”的方式——不仅能规模化运行，还能在企业速度下持续增长、适应并产出新的智能。
智能体开发周期（Agent Development Cycle）
在早期实验阶段，开发者各自为战没问题，但要让智能体规模化，第一步是建立标准化的智能体创建流程。在复杂系统设计中，SDLC 常被用作模型，覆盖从规划到最终退役的全过程。SDLC 为形式化智能体工厂的开发方式提供了良好起点。
SDLC 从概念化阶段开始：识别需求，并做初步分析以确认解决方案是否值得实施。开发智能体时，这一阶段发生在有人识别出某个任务可以通过智能体改进，或现有流程中存在可由新智能体填补的空白。此阶段应快速判断：智能体是否适合该问题。尽管智能体用途广泛，但有些任务更适合传统程序——可能因为需要完全可重复的输出，或任务足够简单，以至于智能体的“智能”贡献很小。应尽早过滤掉这类任务，把智能体聚焦到真正关键之处。
SDLC 的下一阶段是需求分析。在这一阶段，会更深入理解问题，形成更细粒度的需求。对智能体而言，这就是定义输入、输出，以及对意外事件与意外输入的处理方式。同时，也是在这里定义智能体的成功标准，供后续评估其表现。要先设定期望，才能在后续确认智能体确实做到了你想要的事。
接下来是设计阶段：确定系统如何工作、数据如何流动。对智能体而言，这包括确定它需要访问哪些其他智能体与工具，从而定义它如何嵌入更大的 mesh。同时也必须考虑：其他智能体如何访问这个智能体。毕竟智能体应当可复用，因此明确使用该新智能体的规则非常重要。
随后是构建阶段：编写新代码，并在开发环境中实际组装被设计的系统。对智能体而言，这涉及构建智能体配置，并把它接到完成工作所需的工具与智能体上。如果需要新工具，本阶段也包含构建这些工具。还要确保不同工具与智能体能如预期协同工作。这通常是迭代过程，并且会与下一阶段存在一定重叠。
下一阶段是验收阶段，也就是测试发生的阶段。测试用于确保在需求分析与设计阶段所设定的目标，确实被构建阶段产生的系统满足。对智能体而言，这包含测试与验收标准，并特别关注智能体特有的失效模式，比如 prompt injection。自动化测试会作为本阶段的第一批测试，用尽可能多地编码验收标准。随后会由 QA 团队继续测试，以捕捉那些更难编码成测试用例的问题。如果测试结果不满意，智能体会被送回构建阶段修复，再返回到更成功的测试阶段。
部署阶段在验收之后：把通过验收的系统部署到生产环境，使客户能够访问。对智能体而言，这就是智能体离开开发与测试环境，进入 mesh 本体。它随后可以被启动，并对希望使用其功能的用户或其他智能体可用。
维护阶段涵盖为了让系统长期可用而需要的持续工作：新增特性、响应用户请求、修复 bug、发布新版本。智能体同样如此。任何长寿命智能体都会经历版本更新与 bug 修复，确保这些新版本能够及时、可靠地交付，将保证智能体在初次部署之后仍持续被使用。
SDLC 的最终阶段是退役阶段：系统被下线并以结构化方式退役。对智能体而言也一样：智能体被停用。此阶段应特别注意：向该智能体的用户提供足够的预告，并在可能时引导至替代服务，以尽量降低退役带来的服务中断。
有了这一基础的智能体开发流程，我们就可以以此为起点，进一步扩展以支持所需的智能体数量。尽管随着抽象层级提高，涉及的“工作单元”会变化，但总体流程在规模变大时依然适用。
规模化构建智能体（Building Agents at Scale）
要实现软件行业所提到的目标，我们已强调：智能体不能靠手工一个个构建。手工方式也许能产出高质量智能体，但即便开发者全职投入，也不可能满足需求，更别说还要考虑测试与部署。降低创建智能体所需的开发者工作量，是实现高质量智能体数量目标的必要条件。就像家庭作坊让位于工厂与流水线，智能体开发也必须从“造单个智能体”转向“让系统一次性组装大量智能体”。
在尝试规模化生产智能体时，首先必须改变的一点，是把焦点从生产单个智能体转向生产能够组装大量智能体的基础设施。就像作坊时代的个性化产品转向由模板装配的工厂产品一样，智能体工厂必须使用智能体模板（agent templates） ，而不是把每个智能体都视为独一无二。模板包含标准工具、标准方法与其他配置要素，并被设计为只需替换少量部分，就能以极小成本生成与模板高度相似的智能体。
关于规模化创建智能体的一个观察是：很多智能体会彼此非常相似。把自然语言问题转成面向客户数据库的 SQL、面向交易数据库的 SQL、面向员工数据库的 SQL——做的工作高度一致，主要差别只是访问哪个数据库。既然组件可以复用，就没有必要每次从零开始。
同样，如果模板允许的变化范围被清晰定义且受限，这些变化还能让大量智能体更容易获得信任认证。通过限制变更对行动类型的影响，可以对模板进行认证，从而替代对每个由该模板生成的个体智能体逐一认证的需求。例如，如果某个智能体模板能够保证无论数据源是什么，机密信息都不会暴露给 LLM，那么更换数据源就不会影响其认证。尽管并非所有场景都成立，但“可认证模板”的能力会显著加速智能体的信任认证。
前面章节讨论过工具如何在 mesh 内复用，但复用的潜力不止于工具。当工具构建完成后，开发者的工作单元会转变为“智能体配置”。有些配置很简单，但有些会非常复杂，比如包含边界情况处理方式、回应语气、或其他指导性指令。规模化下反复重写同样指令不可行；如果没有严谨体系支持，只会导致信息在文件间以临时方式复制粘贴，错误随之渗入。
因此，与其让临时且易错的机制决定信息如何在不同配置间复制，不如建立一套智能体模板系统来解决这一问题。把模板存储起来，并允许只填充差异信息就能从模板生成智能体，将显著简化并加速开发。开发者不再手工打造一个智能体，而是从模板库中取用，在搭建单个配置所需时间内就能生成十几个相似智能体。
随着 mesh 中智能体数量持续增长，这个模板库也会不断扩充。起初，这些模板很可能来源于早期 mesh 中表现成功的个体智能体：把它们的优点提炼进模板，使其更容易服务于新用途。但随着 mesh 更成熟并扩张，开发重心会逐步转向“模板的创建”，再进一步走向更高层级的规模化。
编队（Fleets）
我们已经走过技术从原始 LLM 到工作流再到智能体的演进。为什么要止步于此？当我们能从模板轻松生成新智能体时，一个问题随之出现：为什么还要创建单个智能体？当然，总得有人思考智能体应该做什么，但随着生态规模增大，智能体独立工作会越来越少；更多时候，它们会与其他智能体协同。尽管这些协作者原则上可以来自 mesh 的任何位置，但在很多用例中，会是一组在相关任务上协作、或在同一任务不同方面分工的智能体。这些智能体群组——编队——将成为 mesh 日常用户在规模越来越大时真正关心的组织单元。
工厂类比在这里依然适用。物理工厂从供应商处接收输入，把发动机、轮子、变速箱等组装成汽车这样的最终产品。同样，编队工厂会把智能体视为“供应商”。当 mesh 达到这个阶段，智能体可以被当作组件组合成最终编队，而不再是为每个具体任务定制构建的零件。
要让编队作为组织单元运作，它必须被当作抽象对象来看待，而不需要了解编队内部细节。用户不再思考要把请求提交给哪个智能体，而是思考要与哪个编队交互。
要让编队以这种方式工作，有几个条件必须成立。第一，组成编队的所有智能体必须作为一个整体启动与停止。如果智能体被刻意地彼此独立启停，编队抽象就会崩解，因为用户不得不关注每个智能体是否在运行——这正是编队试图屏蔽的内部细节。
编队还必须具备定义明确的用户输入与输出通道。它们是用户提交请求、接收回复的唯一方式。编队内的个体智能体不得以绕过这些通道的方式直接输入或输出。否则，用户又需要理解超出抽象层允许的内部细节。但如果通道被清晰定义并严格遵守，用户就不必担心请求提交后内部发生了什么，只需观察输出通道即可理解结果，从而简化与编队交互的心智负担。
编队还需要一个明确的目的或关注领域，把构成它的智能体串联起来。个体智能体的目的会定义得很清晰，但通常范围较窄。单个智能体的窄范围目的本身不足以形成整体目的，必须在更广的“编队目的”语境中组合起来。
然而，编队目的不必像个体智能体那样受限。以开立银行账户为例：开账户作为一个简单智能体的目的没问题，但更可能的是，一个编队会覆盖多个相关操作，而不仅仅是一个。例如，如果系统已具备账户交互能力，那么是否值得再启动一个非常相似的编队来处理余额查询或销户？它们会复用大量相同的工具与智能体，这将造成重复劳动。更合理的做法是让编队目的更宽：覆盖多种账户交互。这既提高工具与智能体的使用效率，也简化用户为其请求找到正确编队的过程。
要确保编队达到企业级，编队必须包含必要的可观测性与监控能力，用以确保编队内部发生的事情可被可靠监督。这包括在编队层面聚合关键指标与信号、聚合日志、跟踪并查看消息等。尽管其中很多信息已经在个体智能体层面被记录，但在编队层面聚合能保证编队保持与智能体同等程度的可观测性。
当规模足够大时，还可以进一步把“编队模板化”。此时，新编队的构建方式将类比“智能体由模板生成”：如果存在相似的编队级工作，就能从模板快速生成新编队。例如，处理欧洲数据与处理美国数据可能需要相同功能，但为遵循监管，数据必须在欧洲存储与处理。此类场景下，把编队转成模板并快速派生新编队，将帮助更快扩展既有业务流程，把规模推向更高层级。
编队组织（Fleet Organization）
大多数人会通过界面与这些编队交互，但开发者仍然必须搞清楚如何实际搭建这些编队。并且，为了让编队表现出一致且合理的行为，编队内部的智能体需要被谨慎管理。不过，组织编队内智能体有多种模式可选。哪一种最合适取决于你要用编队做什么——有些任务更适合某一种组织方式，而另一些任务则更适合另一种。
层级（Hierarchy）
第一种组织方式是层级结构。在这种组织模型中，一个“管理者智能体（manager agent）”位于层级顶端，类似于老板管理员工，或公司 CEO 管理企业。与此同时，存在更低层级的智能体，类似传统层级里的基层员工。管理者智能体是唯一能够看见整个编队全局的智能体，它控制如何处理进入编队的消息等高层决策，如图 14-1 所示。管理者可以通过成为“编队对外的第一接收者”来实现控制；或者输入先由某个“员工智能体”接收并做初步检查，然后再把消息转交给管理者。只要整个编队在管理者指派之后才对消息进行更大范围的处理，层级模式就得以维持。
图 14-1 层级式编队的结构（The structure of a hierarchical fleet）
在这样的编队中，“员工”对编队其他部分正在做什么的视野要受限得多。他们通常只能与管理者智能体沟通，或与少数几个处理紧密相关任务的同级智能体沟通。如果需要访问层级的其他部分，只能通过把信息交给管理者，由管理者促进信息在层级内的流转，才能触达其他区域。
如果编队规模足够大，还可以进一步细分，引入位于顶层管理者与基层员工之间的中层管理智能体。这样既可以避免主管理者智能体过载，也能让中层管理智能体在某些子任务上更专业化——达到高层管理者难以做到的程度。这种编队结构可以按任务规模需要扩展到任意多个层级。
这种组织方式提供了清晰的控制链条与集中式决策。因为存在单一顶层管理者，只要改变这个管理者的行为，就能容易且可预测地引导整个编队的思考与方向。所有信息都经由管理者流转，它就成为单点控制中心。层级模型适用于需要高度可预测、或必须遵循严格合规指引的编队：由于缺少大量点对点连接，可追踪的交互更少，因此更适用于关键任务系统或高度监管领域，因为集中控制更容易确保规则被严格执行。但代价是灵活性与速度：层级结构迫使一切都经由管理者，而不是直接连接。
群体（Swarm）
第二种组织方式是群体（swarm）模型。与层级不同，这里没有被定义的管理者智能体。相反，所有智能体彼此是同级（peer），并且拥有直接的通信链路，如图 14-2 所示。虽然这样的群体仍然会有明确的入口点（entry points），但一旦消息被群体中的某个智能体接收，它可能会被群体内任意数量的智能体处理。具体的处理顺序由编队中的智能体动态决定：每个智能体自行决定要联系哪些其他智能体，以及要采取哪些动作。
图 14-2 群体式编队的结构（The structure of a swarm fleet）
此外，在群体模型中，编队内部对信息的“知情”没有限制。智能体会知道其他智能体在做什么，也会阅读它们正在生成的响应。这让每个智能体都能更整体地理解任务进展，但也带来副作用：需要关注的事情更多，智能体可能难以对手头任务保持聚焦。
总体而言，这种编队强调灵活性与速度。由于没有预先设定的刚性结构，编队能按需自组织，以完成当前任务。每个智能体都能与其他智能体直接沟通，减少了层级中的“转发”瓶颈。并且因为缺少固定组织结构，网络可以为新问题寻找更优路径，而不必被迫沿着可能不匹配的预设路径工作。然而，这种灵活性以可重复性为代价：同一类消息可能在编队中走不同路径，导致即便输入非常相似也产生不同输出。对于需要高度可预测或必须严格遵守规则的应用，这一模型未必合适。
联邦（Federation）
第三种组织方式是联邦（federation）模型。联邦模型介于层级与群体之间，如图 14-3 所示。在这种模型中存在多个管理者智能体，它们彼此是同级，并以类似群体模型的方式相互协作；但每个管理者智能体各自拥有一组“员工智能体”，这些员工只与自己的管理者通信。
图 14-3 联邦式编队的结构（The structure of a federation fleet）
作为折中方案，联邦模型同时获得了前两种模型的一部分优点与一部分缺点。管理者智能体之间不受限制的互通，带来比层级更高的灵活性，但又不如纯群体那样灵活。与此同时，通过固定的“管理者—员工”组织关系，联邦模型在群体之上获得了一定程度的控制与可预测性，但又不及层级那样强控制。
在构建编队时，你需要决定编队在“控制与敏捷”的谱系上落在哪个位置。关键任务或监管要求极严格的任务通常更适合层级模型；危机响应或分布式情报收集之类的任务，更可能受益于群体模型的灵活性；而许多操作需要一定灵活性，同时也需要一定可预测性，这时联邦模型往往是最佳选择。具体采用哪种模型取决于你的场景。图 14-4 展示了这些编队结构的对比概览。
图 14-4 编队结构对比（Fleet structures compared）
构建编队（Building Fleets）
在构建编队时，第一优先考虑的是：哪一种编队组织类型适合该任务。这个决定会影响系统中的其他一切，因为不同架构需要不同类型的智能体。如果选择层级结构，就需要一个专门用于控制消息在系统不同部分之间流动的管理者智能体；而在群体中，每个智能体都必须能够独立处理自身事务，这会要求与层级“工人智能体”不同的配置方式。
一旦确定编队的组织形式，就需要确定编队的输入与输出：这个编队预期会接收什么输入？是用户的原始文本输入？是某种已知格式的合法 JSON？是来自麦克风的音频？是 PDF 或 PowerPoint 文件？你愿意接受的输入类型，会决定编队布局的某些部分——因为你必须包含能够处理该类输入的智能体，即便它们所做的工作只是把输入转换成编队中其他智能体能理解的格式。同时，这些处理输入的智能体还需要具备通向编队其他部分的通信通道。类似地，编队要产出的输出类型也会要求纳入特定智能体，并让编队最终把消息汇聚到这些输出智能体上。
在输入与输出明确之后，就需要选择应当属于该编队的智能体。选择编队智能体时，你要像管理者一样思考，而不是像开发者。管理者不会为了一个现有员工已经足够胜任的任务而再去招人；只有当团队确实无法胜任时才会新增人员。智能体也一样：如果已有某个智能体模板能胜任，就应使用该模板；只有当现有模板无法满足任务需要时，才应从零构建新的智能体。过于频繁地创建全新智能体，会消耗大量时间，从而吞噬编队抽象带来的主要收益。
提示（TIP）
先选出由组织形式与输入/输出所“必需”的智能体，然后选择承担最核心工作部分的智能体。它们会构成编队的核心基础。接下来，选择补齐支撑能力或通信通道的智能体，以让编队具备完整的核心能力。最后，持续添加必要的支撑能力，直到形成一个完整组装的编队。
大规模运行智能体（Operating Agents at Scale）
把智能体与编队以如此大的规模搭建起来绝非易事，但工作并不会因为智能体被创建出来就结束。就像你必须支付薪资、管理员工一样，你的智能体与编队也需要持续投入才能保持运转。事实上，管理这些编队甚至可能比创建它们更艰巨。你不仅要确保智能体能按需启动与停止，还要处理错误、确保更新可用、追踪整个网格（mesh）的运行、汇总数据，甚至在智能体不再有用时将其退役。要让这样的系统持续运转，远不止“搭起来”这么简单，后续维护本身就有大量工作量。
前面章节已经讨论过如何管理少量智能体，但随着网格规模扩大，问题会急剧放大。当网格大到以编队成为行动单位时，管理方式也必须随之改变：不能再以单个智能体为管理焦点。相反，运维管理的努力应聚焦在编队层级。相比单独管理数百个智能体，管理二三十个编队显然更容易理解和掌控。
部署编队（Deploying Fleets）
部署单个智能体通常相对直接；但部署整个编队会复杂得多。一个智能体基本上是自包含的，至少在让“最低可用功能”跑起来时，可以用一个简单指标判断它是否正常工作。然而，一个编队的最低要求要高得多：它不是“跑一个程序或容器”那么简单，而是要运行一组容器，并且这些容器必须一起完成配置、一起启动。
为了确保整个编队作为一个整体运行，它必须被整体管理与整体部署。随着网格规模持续增长，Docker 镜像或 Docker Compose 已不足以胜任对编队智能体的管理。若每个智能体都被单独管理，要保证所有必需智能体都持续运行，其复杂度会高到难以接受。取而代之，应使用正式的容器管理器来管理这些容器。为了便于说明，接下来本章将以 Kubernetes 作为容器管理器。
使用 Kubernetes 来管理编队，会把大量复杂性从系统管理员手中转移到 Kubernetes 系统里。管理员不必逐个操心智能体，而是可以把整个编队配置成一个 Kubernetes Pod。在这种设置下，Kubernetes 能把编队当作单一单元来管理：统一启动、统一停止所有组件。这也进一步抽象了编队内部细节，使外部观察者只需要关注“编队整体”即可，而无需理解内部结构。
以这种方式启动编队时，整个流程还必须织入零信任网络（zero-trust networking） ，以确保安全标准不被破坏。每个智能体都会从编队信任的证书颁发机构获得一个短生命周期证书，使其身份可以被交互对象验证。编队内部以及编队对外的通信也会建立双向 TLS（mTLS） ，从而让编队的安全性具备可验证的信任基础。
监控编队：编队观察者智能体（Monitoring Fleets: Fleet Observer Agents）
要让运行中的编队保持健康，就必须对其进行监控。前文讨论过对单个智能体的监控，但当网格规模扩大后，逐个查看智能体的指标与日志将不再有效——智能体数量太多，根本跟不上。即使在需要时仍能访问每个智能体的细粒度指标，但把指标在编队层级进行聚合，可以提供更容易消化的整体视图。
管理编队的人通常不需要、也不想持续盯着“编队里某个具体智能体处理了多少条内部消息”；但他们肯定想知道“这个编队处理了多少用户请求”。他们可能非常关心“有多少请求因用户错误被拒绝”，却未必关心“是哪一个具体智能体做了拒绝”，除非该拒绝本身不合理。同样，单个智能体的可用性（uptime）在多数情况下只有在调试时才有价值；而“编队是否在运行”则是更关键的统计指标。调试确实需要更细视角，但聚合指标能提供更适合“第一眼”判断的概览。
这些聚合指标也会在编队层面保留健康检查信息——覆盖编队内哪些智能体处于活跃与健康状态，以及这些智能体的健康状况如何影响编队整体健康。有些情况下，即便个别智能体不可用，编队仍能维持部分功能；而在另一些情况下，某些关键智能体的缺失会导致编队不可运行。把这类信息放在编队层面追踪，会让概览更容易，尤其对只关心“能不能把请求提交给编队”的终端用户而言更是如此。
这一点在网格继续扩张时尤为重要：一个人可能最终要管理不止一个编队——甚至是很多个。因此，编队管理者需要以可在合理时间内吸收的方式呈现信息，而不是被每个智能体的指标同时淹没。可问题在于：当信息洪流如此巨大时，如何把它压缩成一个足够小、又能让人及时采取行动的子集？答案是：编队观察者智能体（fleet observer agents） 。
编队观察者智能体会监视编队的日志与指标。它们接收日志与原始信息的“消防水带”（firehose），从中解析与筛选出对编队运维与维护真正重要的部分，然后对这些信息进行总结，并以可供用户访问的方式呈现。这样，就能把海量信息变成“可一眼扫过”的摘要，供管理编队的人快速查看。需要时原始信息仍可访问，但日常管理很可能主要依赖观察者智能体生成的摘要。
更新与退役编队（Updating and Retiring Fleets）
即便拥有健壮的编队部署流水线，确保上线的编队质量很高，最好的设备也依然需要维护并最终被替换。当出现问题或新增特性时，编队必须更新；要无缝更新，还需要额外考虑更多问题。
当需要对编队做变更时，它会走与新编队相同的 DevOps 流水线，包括与新编队一致的测试流程，以确保新版本仍符合旧版本遵循的标准。但一旦通过 DevOps 流水线，新编队会作为编队的新版本进入网格，并拥有独立的版本号。为了保留向后兼容，除非明确下线，新旧两个版本将同时可用。
虽然并没有强制要求旧版本编队必须持续运行，但很多场景下保留旧版本是明智的：它允许依赖旧版本的人继续使用旧行为；如果新版本对处理方式有显著变化，这一点尤其关键。你不希望因为强制升级而破坏依赖某个特定行为的关键应用。让两个版本并行一段时间，可以给用户留出改造其应用以适配新行为的窗口。网格也可以在必要时对同一编队的不同版本做差异化对待，因此不必担心“把人误切到错误版本”。
即便如此，旧版本编队也不可能永远运行，总有一天要停止。由 Kubernetes 管理编队时，可以把它们作为一个整体停止：所有智能体同时停止。但为了避免终止正在进行的请求，停止编队时会先暂停接受新的请求，同时允许进行中的请求完成，然后再彻底关闭编队。这能防止客户正在执行（甚至可能付费）的请求被突然中止。当然，管理员也可以立即关闭编队；但考虑到这种做法会带来强烈扰动，应限制在紧急情况，例如编队被攻破并被用于恶意目的，或作业明显卡死且长时间无望完成。
更远期的未来（A More Distant Future）
关于编队的讨论与“近期”密切相关，但智能体的数量很可能不会停在“编队足够应付”的规模。一旦规模继续增长，编队数量和其运维挑战会进一步扩大，直到需要更高层的抽象。虽然那一刻可能还需要一段时间，但仍值得提前展望一下未来可能会出现什么。
智能体构建智能体（Agents Building Agents）
随着网格增长，模板化只能带你走到一定程度。即便模板做得再好，模板体系仍然需要人来创建，而模板数量增长会让这件事变得非常耗费精力。除此之外，还会有大量人力消耗在评估、测试这些智能体，以及决定是否将它们纳入编队。由于智能体数量很可能远快于可创建它们的开发者数量、以及可测试它们的 QA 人员数量增长，必须想办法进一步加速。未来，智能体的创建需要更强的自动化。
许多自动化问题最终的答案都会是“用智能体来解决”，这里也不例外。与其让开发者手工打造智能体或智能体模板，不如让其他智能体来完成这项工作。打造这种“造智能体的智能体”并不容易——因为它们对企业太关键，必须极其可靠且经过严格测试，且其产出相比多数智能体更远离人类监督。但一旦建成，其收益将非常巨大。
早期的“智能体创建者”会把需求方提供的指南转化为可被加入 agentic mesh 的规范（specification）。这会显著减少创建智能体所需的开发开销，类似于编译器如何让编程变得更轻松。许多消耗开发者时间的低层工作将由这些智能体处理，释放员工去关注系统架构等更影响整体系统的事务，而不是纠缠于局部组件。
随着智能体更普及，它们甚至可能被赋予管理某个业务流程的一部分——乃至全部。与早期的智能体创建者相比，这些智能体拥有更大自由度，能够主动创建全新的智能体。这样的“主动性管理者（initiative managers）”会分担部分系统设计负担，使系统设计也能在更大规模上被智能体化处理。
更大的抽象（Larger Abstractions）
智能体数量最终会增长到超出仅靠编队也难以承载的地步。为了理解这条演进路径，我们可以把 agentic mesh 与人类企业作类比：在企业里，基层员工完成基础工作；在网格里，基层员工对应单个智能体——执行网格的基础操作。再往上一层，企业会在员工数量足够多、以至于管理协调困难时把员工组织成团队；在 agentic mesh 中，编队承担了类似团队的角色：把智能体组织成更易管理的单元，并提升抽象层级。但“团队之上”是什么？
在传统企业里，团队之上是组织（organization） ，如图 14-5 所示。组织拥有很多团队——甚至是多层级的“团队的团队”——从而使组织可以扩展到任意复杂的问题。为了让 agentic mesh 也具备超越编队的扩展能力，它引入智能体生态系统（agent ecosystems） ，作为“组织”的等价物。这些生态系统由多个编队组成，在明确边界内协同工作。它们像组织一样拥有对外接触点，并能够把消息路由到内部合适的编队。
图 14-5 越来越复杂的智能体组织形态（Increasingly complex agent organization）
当智能体扩展到生态系统层级，它们能完成的任务也会超出单个智能体或单个编队的能力边界。单个智能体处理一笔交易、编队完成客户入驻是可行的；但到了生态系统层面，运行整个业务板块就进入了可能范围。甚至可能出现几乎完全由智能体构成的“企业”，以填补特定经济生态位。
随着这类“组织”规模增长，是否将智能体生态系统视为法律实体的问题会浮现。智能体在经济中的重要性不断上升，似乎只是时间问题，智能体生态系统会获得法律层面的代表权。这并不意味着智能体在人的意义上“具有意识”，而更类似于公司等组织所拥有的法律人格：这种承认并不把它们当作人，但能简化许多经济交易。在这种情况下，智能体将能够签署合同、持有资产，并承担法律责任。
然后规模可能继续放大：作为法律实体的智能体组织会以更高自治程度彼此交互。它们之间会像普通公司一样达成合约与交换，建立长期关系并持续扩张，最终形成完全由智能体构成的供应链，把端到端系统串联起来，如图 14-6 所示。
图 14-6 生态系统将成长为法律实体与供应链（Ecosystems will grow into legal entities and supply chains）
总结（Summary）
随着智能体数量不断增长，为了充分发挥它们潜力所需要的抽象层级也会随之提升。正如本章所展示的，在近期到中期的未来，这将导致一个关键转变：从“智能体”作为主要工作单元，转向以“编队（fleet）”作为基础工作单元。当不同结构的编队通过智能体模板逐步搭建起来时，为了跟上这种变化，网格（mesh）也需要做出相应调整。
从更长远的视角看，编队本身还会被纳入更高层的抽象之中，例如智能体生态系统（agent ecosystems） 、智能体法律实体（agent legal entities）以及智能体供应链（agent supply chains） 。这些更高阶结构将使智能体的规模与效用进一步提升。
但面对即将到来的变化，要让组织为 agentic mesh 做好准备需要投入大量努力，而要为更远期的演进做好准备则需要更多。第 15 章将解释如何制定路线图，帮助组织迈入智能体时代。
