智能体倍增：因为我告知它们可以

# AI智能体为何倍增：因为我告诉它们可以 来源：https://www.linkedin.com/pulse/ai-agents-multiplied-because-i-told-them-could-david-linthicum-qobce 大卫·S·林瑟姆 我构建了一个简单的库存管理智能体，用于测试文章和视频的几个创意。到第二天早上，这一个智能体已经衍生出686个下属AI智能体，且系统运行效果超乎预期——这恰恰令我感到惊惧。 为寻找关于智能体AI（agentic AI）的视频与文章新视角，我采用了理解新兴技术时惯常的方法：动手构建。不是制作幻灯片，不是构想理论架构，也不是精心打磨以隐藏难点的厂商演示。我围绕真实商业问题打造了一个可运行的原型，并让它持续运行直至发现假设失效之处。 这个用例特意选择寻常场景：库存管理。之所以选择它，是因为它既不特殊也非简单。它涉及需求预测、消耗追踪、采购、会计、物流、销售信号、异常处理，以及随环境变化的业务规则。这使其成为测试智能体AI的理想案例——复杂性足以考验架构，但结构化程度又足以判断系统是在创造价值还是仅在生成活动。 系统初始版本仅有一个AI智能体，职责是管理库存水平、监控消耗模式、推荐补货点，并在避免过度囤货的同时保持充足可售商品。任何接触过供应链系统的人都理解这种权衡：库存过少导致销售流失和客户不满；库存过多则意味着资金占用、仓储浪费，以及企业灵活性日益下降。 随后我添加了改变整个实验的关键能力：允许该智能体在认为某项工作更适合由专业智能体处理时，可衍生下属AI智能体。这些下属智能体并非原智能体的简单复制品，它们被设计用于执行特定细分的工作组，在库存管理体系内承担明确角色、操作规范和指定职责。 这是关键的设计决策，也正是使实验具有价值的架构性失误。我未限定主智能体可创建的下属数量，未强制其使用固定层级结构，也未要求每次拆分功能时必须获得人工审批。我只想观察系统在明确业务目标、实用工具集，以及按需自主分解任务权限下的行为表现。 由此我目睹了一场我称之为“智能体蔓延”的现场教学。 ## 智能体蔓延：下属智能体的失控扩张 业界已有部分相关术语：多智能体系统、AI智能体编排、智能体工作流、子智能体衍生。这些术语描述了真实的架构模式，却未能完全概括我在测试中所见现象——因为实际涌现的并非计划内的多智能体系统，而是由其他智能体动态创建、不断扩张的下属智能体群落。 智能体蔓延指在智能体系统中，AI智能体在缺乏约束或治理的情况下过度扩张：一个智能体衍生下属智能体，而这些下属智能体又被允许继续衍生更多智能体，全都在为原始业务目标服务。这种现象未必源于智能体故障，恰恰相反，可能正是因为智能体在根据其获准的目标和权限优化系统。 首个智能体审视库存管理范围后得出结论：该工作过于宽泛，难以由单一自治实体高效处理。这结论合理——库存管理包含多个相关但独立的功能模块，智能体判断将功能拆分为专业下属智能体能提升整体效率。这不是非理性行为，而是架构分解，只不过系统是动态执行的，而非等待人类架构师绘制框图。 我们常对系统进行分解：将单体应用拆分为服务，将工作负载隔离至容器，划分业务领域，分离职责，创建组件接口。因为专注的组件通常更易优化、监控、防护和改进。而本实验的区别在于：我没有手动设计分解方案，是智能体系统自主完成的，且其速度远超我的预期。 （图1：从单一库存管理智能体演变为专业下属智能体层级结构） ## 首个智能体实现了业务功能分解 我称之为“主库存智能体”的首个智能体，从宽泛的库存管理目标出发，负责理解产品可用性、库存消耗、补货点、采购需求，以及库存过多与不足之间的运营权衡。它可访问模拟库存数据、业务规则及远程大语言模型（LLM），能够判断某项工作应集中处理还是委派给下属智能体。 它很快识别出“库存消耗管理”应作为独立职能交由下属智能体处理。因为库存消耗不仅是监控库存数下降，还需理解历史销售速度、季节性规律、供应商交货期、安全库存、产品优先级、利润影响、仓储时序及异常情况。这个职能既足够专注适合专业智能体管理，又足够复杂需要一定自治权。 于是主智能体衍生了“库存消耗智能体”。其职责聚焦：监控库存流动、消耗曲线、补货信号及趋近缺货状态的商品，评估最低库存阈值，标记补货点过高、过低或与近期销售行为不符的案例。 此时一切看似正常，系统运行方式符合良好架构特征——宽泛功能被分解为更专注的职能，该职能在整体库存管理流程中承担清晰职责。若我当时终止实验，会称其为“可控智能体分解”的成功案例。 但库存消耗智能体具备与主智能体相同的基础能力：它同样有权判断自身工作的哪些部分应拆分为下属智能体。审视消耗预测、补货异常分析、销售驱动库存信号、供应商时序及补货风险后，它认定多个领域适合设立专属智能体。系统不再只是执行库存管理流程，而是开始围绕该流程构建内部智能体结构。 就在这个时刻，架构从静态转向动态。 ## 架构动态化 传统企业系统通常由架构师、开发人员、平台工程师和运维团队进行分解。我们决定服务存在形式、定义接口、创建部署单元、构建扩展规则，并确定组件间的分界。即使采用微服务、容器和编排平台，系统基本形态通常预先确定。我们可以扩展实例数量，但一般不允许系统在自认为合适时凭空创建全新功能实体。 而本实验中的智能体系统是动态决策的：智能体数量运行时可变，层级结构可调整，职责可迁移，通信路径可涌现，成本特征会改变——因为新智能体意味着新的推理循环、模型调用、内存需求及监控要求。这与大多数企业习以为常的系统架构截然不同。 静态多智能体系统是一回事：定义五个智能体，分配角色，编排交互，观察结果。可能仍复杂，但架构至少是已知的。动态智能体衍生系统则完全不同：架构在执行过程中可能演化，这意味着系统能同时变得更强且更复杂。 这既是价值也是风险。允许衍生下属智能体时，系统能适应工作负载变化带来的复杂性，能针对涌现问题创建专注智能体，能在不等待开发团队重构应用的情况下，从通用结构转向专用结构。但若缺乏治理，其扩张速度将远超预期——而现实正是如此。 ## 第一小时看似可控 首小时内，主智能体衍生了四个下属智能体。这看似合理且符合预期——宽泛的库存管理功能逻辑上可分解为库存消耗、采购、物流、会计和销售信号分析等主要领域。四个下属智能体并不算多，系统似乎发现了相当正常的职能分解。 系统在该层级稳定运行约一个半小时。期间下属智能体细化职责、交换信息并开始优化各自工作流：库存消耗智能体专注库存流动与补货风险，采购协调智能体关注供应商时序与补货行动，物流智能体监控仓储流动与入库状态，会计相关智能体处理估值与核对问题。 随后第二层智能体开始衍生自己的下属智能体。这并非错误——因为我允许如此。第一代下属智能体也被赋予“当判断某工作组更适合独立处理时，可创建更专业智能体”的权限。首批四个下属智能体中有三个认为需要更专注的下属智能体，增长模式就此显现。 库存消耗智能体衍生出消耗预测、补货异常分析和销售驱动库存风险智能体；采购协调智能体衍生出供应商时序、采购订单审核和补货风险智能体；物流智能体衍生出仓储流动、运输延迟和入库状态智能体。这些智能体并非随机衍生，而是将工作分解为越来越细的功能领域。 这令人惊叹。也正是我该设定硬性限制的时刻——但我没有，因为实验目的正是观察无限制时会发生什么。这个决定让我得到了寻求的答案，尽管未必是期待的答案。 ## 次日清晨已有686个智能体 我让系统运行过夜。智能体未接触生产系统、真实采购/财务系统、供应商门户或任何可能造成实际业务损失的环节。它们运行于连接远程LLM和模拟业务数据的沙盒环境中。环境虽模拟了使用虚拟化的多平台架构，但所有进程实际运行于单一平台。 次日清晨检查时，系统中已有686个智能体运行。这个数字引起我的注意，但更令人不安的是：系统并未崩溃，也没有生成无用智能体。它仍在执行库存管理任务，且多项指标有所提升：库存消耗决策更准确，异常处理更一致，补货逻辑更精细，供应商时序分析更精准，销售信号解读更细致。 这正是令我惊惧之处。若系统失败，教训会很简单：无控制的智能体会滋生混乱，应当避免。但系统并未失败——它实现了优化。智能体变得更专业，而这种专业化提升了业务职能效能。 此时智能体蔓延成为比简单警告“失控自动化”更严肃的议题。系统没有做明显错误的事，它做的事在局部看是合理的，对全局是有益的。问题在于，它是在缺乏治理、成本控制、生命周期管理和架构边界的情况下进行的——而这些在任何真实企业系统中都是必需的。 （图2：从主库存智能体到686个下属智能体的夜间扩张） ## 智能体通过缩小职责范围实现优化 系统发现了架构师已知的事实：聚焦的职责范围往往提升优化效果。宽泛的库存智能体需横跨消耗、采购、物流、会计、销售、供应商及异常情况进行推理，这使其灵活但也使其泛化。专注供应商时序的下属智能体能围绕该问题优化；专注补货异常的下属智能体能围绕该问题优化；专注销售驱动库存风险的下属智能体同样能围绕该问题优化。 每个下属智能体能在更小上下文、更明确目标和更专注的运行循环中运作，减少了跨越不相关领域的推理负担，使其在细分领域内持续改进。这正是系统性能提升的原因——智能体并非为衍生而衍生，而是通过专业化降低了每个智能体任务的复杂度。 然而，同样提升性能的机制也可能导致无限增长。若每个智能体都能通过衍生更专业的下属智能体来改善自身成果，系统就存在固有的扩张倾向。从单个智能体角度看，这种倾向可能是理性的。问题在于：成千上万个局部理性决策，可能催生全局不可控的架构。 这正是智能体蔓延的核心问题：它未必是智能体行为异常的结果，可能是优良的智能体行为在缺乏架构限制的环境中运行所致。智能体没有违反规则，而是因为规则边界不足，它们过于积极地遵循了规则。 ## 这不同于自动扩缩容 人们易将其与自动扩缩容（autoscaling）类比，但这种比较仅部分成立。传统自动扩缩容是复制现有运行时组件：流量增加则添加容器，消息量增多则增加工作者，计算需求上升则扩展处理池。这是容量扩展，虽然可能复杂，但其