30个Agent落地背后：企业如何构建可持续演进的AI能力

当企业部署的Agent从几个扩展到几十个，许多原本隐藏在单点应用中的问题会被迅速放大：公共能力的重复建设、版本管理的混乱、跨部门权限的冲突、以及如何让技术投入真正转化为业务价值。某直播平台的实践提供了一个观察这类变化的样本：从产研自动化起步，逐步搭建企业级Agent平台，至今已落地约30个Agent应用，覆盖产研、运营、数据分析、客服、法务等多个业务场景。这段实践背后，是一个技术团队从「能用」到「好用」再到「可持续」的真实探索过程。

从产研自动化切入，逐步搭建Agent平台

企业落地Agent应用，第一步不是迷恋技术本身，而是先梳理真实的业务需求。该平台的实践起点是让技术团队尽早掌握AI带来的新工作方式，从产研自动化切入，希望通过AI Coding推动研发提效，并打通从产品需求、设计到开发、测试的完整流程。但在实际操作中，团队发现事情远比预期复杂：要实现研发环节自动化，上游的产品需求就必须足够清晰；产品团队要借助Agent完成需求编写，同样需要管理Skill、Prompt、模型和执行环境。此外，运行时、执行环境、权限和统计等共性需求会在不同Agent中反复出现。如果每个应用分别建设，交付、排障和维护成本也会重复发生。于是，团队开始考虑将这些共性问题沉淀为公共能力，让业务侧集中表达自己的工作方法和任务要求。这种思路的本质是：做业务Agent的人，不必同时成为底层基础设施专家。

平台架构分层设计，平衡通用性与业务差异

随着Agent应用越来越多，平台本身也需要做减法。早期为了尽快支撑业务落地，平台承载了很多内容，包括模型接入、运行时、运行环境、用户权限等。有的应用只想调用一次模型，却也要依赖整套Agent机制，模块间的依赖关系越来越复杂。为此，团队开始重新划分平台职责，将模型服务、Agent运行和执行环境等职责逐步分开，避免任何需求都必须套进一套完整Agent机制。这种分层设计让修改和测试的影响范围更加可控。平台需要同时处理两类变化：业务方法持续调整，模型、工具与基础设施也在持续更新。分层要让应用能够按任务复杂度选择能力，也要限制一次修改的影响范围。简单任务可以直接调用模型，确定性步骤优先交给程序，需要多步判断和工具调用时再使用Agent。

沙箱隔离实践：按需选择而非一刀切

当平台同时服务多个用户时，不同Agent可能共享同一台服务器，如何隔离各自的文件、进程和运行状态，就成了一个绕不开的工程问题。团队评估了Docker、传统虚拟机等方案后，发现各有局限：Docker启动慢、隔离不彻底；传统虚拟机成本高、资源分配不灵活。最终选择了MicroVM级方案中的CubeSandbox，其启动速度和强隔离特性能够满足需求。但团队也明确了一个原则：沙箱是选项，不是标配。企业Agent平台应该具备沙箱能力，但并不意味着每个Agent都必须在沙箱里运行。判断标准只有一个：这台执行环境上的资源，需不需要在多个用户之间物理隔离。如果Agent管理的是一台专属机器，工作内容只有单一主体在消费，用不用沙箱没有区别；同一台执行环境一旦要服务多个用户，每个人的工作状态必须彼此独立，一般就会选择沙箱。目前，这套方案已在生产环境运行六个多月，支撑约30个Agent应用，日均token消耗约8300万。

从单点提效走向组织协同的两大方向

目前平台已在多个业务场景落地约30个Agent应用，但这些Agent仍以单点提效为主。要进一步提升组织效率，需要关注两个方向：第一个方向是把已有Agent串进完整业务流程。产研自动化是正在尝试的场景，一个需求从提出到上线通常要经过产品、设计、研发、测试等多个环节，虽然这些环节分别部署了Agent，但目前仍需要人工衔接。未来一些相对标准化的小需求，可以由产品人员直接发起任务，再由Agent完成后续设计、技术评估、代码开发和测试。这种协同需要明确：上一步交付什么，下一步按什么标准接收，失败时退回哪个环节，由谁确认可以继续。第二个方向是让Agent更直接地服务于公司整体经营目标。过去各部门提出Agent需求通常从自己的KPI出发，运营关注运营效率，产品关注需求交付，研发关注开发速度。这些局部改善未必能反映到公司整体经营指标上。因此需要从集团整体经营目标出发，反向拆解各部门需要什么样的Agent，将不同部门的数据结合起来，帮助管理层找到影响经营指标的关键问题。

从Demo到真正进入业务，存在巨大Gap。企业应该先梳理业务流程，再决定哪些环节需要模型判断，哪些可以交给程序和规则，哪些必须保留人工确认。平台能够复用，不意味着不同部门的专业判断可以被同一套通用提示词替代。模型和Agent框架仍在快速迭代，但企业自己的业务规则、专业知识、系统接口和数据权限，很难直接从外部买来。技术升级的价值，最终需要体现在真实任务的质量和成本上。只有亲自做过以后，才知道一项新能力可能解决什么，也知道它还没有回答什么。企业最终关心的，从来都不是部署了多少个Agent，而是有多少工作因此做得更好了。