30 个 Agent 背后：花椒如何建设可持续演进的企业 AI 能力？

作者 | 凌敏

今年最大的一个变化是，企业做 Agent 的门槛越来越低，但做出一个能完成任务的 Agent，与让它在业务中持续稳定运行，还存在一定的距离。因为当 Agent 数量和使用频率放大后，很多原本不显眼的问题也会跟着放大。

花椒的 Agent 实践，提供了一个观察这种变化的样本。

花椒直播 CTO、超序 AI 创始人兼 CEO 封冰清，正在同时面对企业 AI 落地的两类问题：如何让技术在真实业务中持续运行，以及如何把内部积累转化为可复用、可持续交付的产品与服务。

超序 AI 是花房集团旗下独立 AI 品牌，推动 AI 融入企业的生产与业务流程，从具体任务出发，面向细分行业沉淀可复用的解决方案和系统。花椒与花房的内部实践，为这一探索提供了技术与业务经验。

从产研自动化起步，到约 30 个 Agent 应用落地，封冰清逐渐形成了一个判断：企业需要持续积累自己的业务方法、系统连接、权限规则和验收标准，让模型与工具能够不断升级，并用实际交付结果判断投入价值。

围绕这一判断，InfoQ 与封冰清交流了花椒 Agent 平台的建设经历：为什么选择自研，为什么又不断拆分平台职责，如何处理业务与公共内核的边界，以及从单点提效走向组织协同，还需要补齐哪些工程和管理能力。

1 从产研自动化起步，Agent 平台逐渐“长”出来

今年春节后，“小龙虾”以近乎疯狂的速度在全球范围内蹿红。尽快应用 Agent，成了当时很多企业最迫切的事情。

相比多数企业，花椒显得十分冷静。“我们认为，企业不应该完全迷恋 Agent 或者 AI，企业落地 Agent 应用前，第一步是要先梳理业务的需求。”封冰清提到，花椒的 Agent 实践，起点是希望技术团队尽早“上 AI 这条船”：从产研自动化切入，希望团队能通过实际应用，真正掌握 AI 能力。按照他的设想，技术团队需要尽早掌握 AI 带来的新工作方式，通过 AI Coding 推动研发提效，并打通从产品需求、设计到开发、测试的完整流程。

但真正做起来后，团队发现，事情没有想象中那么简单。比如，要让研发环节实现自动化，上游的产品需求就必须足够清晰。产品团队要借助 Agent 完成需求编写，同样需要管理 Skill、Prompt、模型和执行环境。

此外，运行时、执行环境、权限和统计会在不同 Agent 中反复出现。如果每个应用分别建设，交付、排障和维护成本也会重复发生。团队因此开始考虑，将这些共性问题沉淀为公共能力，让业务侧集中表达自己的工作方法和任务要求。

于是，在 2026 年 3 月份左右，花椒开始调研市面上的 Agent 方案，并最终决定自研一套企业 Agent 平台。这套平台的目标很明确，把运行时、执行环境、用户权限、统计等共性能力交由平台封装，让业务侧专注在 Skill、Prompt 和模型选择上，沉淀自身的工作方法、任务要求和智能能力。这样一来，开发一个业务 Agent，就不必每次都从底层基础设施做起。“做业务 Agent 的人，不必同时成为底层基础设施专家”，封冰清说道。

从决定自研到第一个版本上线，花椒大概花了一个月的时间。第一个版本已经具备基本的 Agent 管理能力，包括应用创建、Skill 配置、执行环境管理、用户权限和聊天交互等。团队希望先验证一个最小闭环：能不能让业务人员在平台上创建应用、配置能力，并通过对话完成实际工作。

平台搭起来只是第一步，更大的挑战是如何让员工真正用起来。在企业内部，很多员工对 Agent 的接受程度并不高，一些员工听到要做 Agent，第一反应是担心自己的工作会不会被 AI 取代。花椒落地 Agent 应用的思路是，先从一线员工最迫切的需求入手，让大家看到 Agent 到底能解决什么问题。

以运营人员的数据查询工作为例。过去，运营人员查询主播直播数据或用户充值金额时，需要先打开电脑、连接 VPN、登录后台，有时还要在多个系统之间来回查找，最后整理信息向负责人汇报。基于这个真实痛点，花椒开发了一个 Agent，并接入办公软件。运营人员只需要在办公软件里提问，Agent 就能调用后台数据并给出结果。

这种方式得到了业务部门的认可，也让团队进一步意识到，Agent 的交互形式需要服从实际工作。开放问题适合通过对话探索；高频、规则明确的任务，则更适合提供固定入口、必要字段、任务进度和审核位置。

花椒因此将部分 Agent 从单纯的聊天交互转向工作台形态，并逐步抽象连接器、界面等通用能力。底层运行能力可以共用，业务入口则围绕各部门的任务和结果责任独立设计。

目前，花椒已经在业务侧和集团中台落地了约 30 个 Agent 应用，覆盖产研、运营、数据分析、客服、法务、行政以及 GR（政府关系）等多个场景。

在封冰清看来，企业判断一个方向是否值得落地 AI 应用，需要先想清楚最终拿什么证明它有用。“部门用了 AI”和“部门的工作变好了”，中间还有一段距离。真正值得持续投入的方向，应该是 AI 能让员工把原来的一件工作做得更好，或者让整个工作流程变得更高效。

比如，AI 生成内容的速度提高了，但审核却更慢，企业就需要缩小自动化范围；如果一个流程真正的卡点在审批等待，那么继续优化 AI 的生成速度，也无法解决实际问题。这也解释了，为什么企业 AI 最终会碰到组织问题。“技术团队可以实现功能，业务团队必须提供专业标准、参与验收。跨部门的目标、资源和责任冲突，需要我去推动，不能留给一个工程师靠调提示词解决”，封冰清提到。

2 花椒 Agent 平台背后的技术思考

业务与技术的边界，是花椒设计 Agent 平台时重点考虑的问题，随着 Agent 应用越来越多，花椒发现，平台本身也需要做减法。

早期，为了尽快支撑业务落地，Agent 平台承载了很多内容，包括模型接入的 newapi、沙箱、运行环境、用户权限等。有的应用只想调用一次模型，却也要依赖整套 Agent 机制。此外，花椒的 Agent 平台主要通过 AI Coding 开发，随着功能不断增加，模块间的依赖关系越来越复杂。一次简单的修改，可能需要 AI 理解大量上下文，团队还得反复确认是否影响了其他功能。

为此，花椒开始重新划分平台的职责，将模型服务、Agent 运行和执行环境等职责逐步分开，避免任何需求都必须套进一套完整 Agent 机制。这种分层设计，也让修改和测试的影响范围更加可控，降低平台自身的复杂度。

这段实践让团队更加明确，平台需要同时处理两类变化：业务方法持续调整，模型、工具与基础设施也在持续更新。分层要让应用能够按任务复杂度选择能力，也要限制一次修改的影响范围。简单任务可以直接调用模型，确定性步骤优先交给程序，需要多步判断和工具调用时再使用 Agent。

AI Coding 加快了代码实现，但架构边界、兼容关系和验证成本仍需要人来控制。技术负责人需要判断，每增加一项能力，会给后续修改、测试和维护带来什么长期成本。

花椒 Agent 平台架构设计

花椒将平台划分为四层职责：

• 业务入口承载任务和结果；

• 控制与治理管理身份、权限、配置、版本与用量；

• Agent Runtime 组织模型判断、工具调用和运行状态；

• 资源接入与执行环境连接企业原有系统，并提供实际执行任务的位置。

这些职责围绕同一项任务共同工作。权限与审计贯穿执行过程，Runtime 持续推进任务，运行事实再返回应用与治理层。

以生成一个 H5 页面为例，用户在业务入口提交需求后，平台先检查身份和授权，再由 Agent Runtime 创建任务、固定配置版本、组织材料并调用模型。模型可能需要读取文件或执行构建命令，这些操作会被交给相应的执行环境，工具返回结果后，Agent Runtime 再决定下一步做什么，直到任务结束。此外，执行过程中的事件会持续记录，应用据此展示进度和产物。这套架构背后，花椒有一条比较明确的原则：公共运行内核不承载部门专属业务逻辑，业务差异通过 Skill、Prompt、工具接口和配置表达。花椒希望守住的边界是：新增或调整一个部门的业务能力，尽量不需要修改所有 Agent 共用的运行内核。这样，不同业务可以复用公共运行能力，新增场景主要围绕业务方法、工具接口和配置展开，减少重复建设。

封冰清用一个十分形象的比喻来解释这种关系：Agent 平台相当于操作系统，Agent 是运行在上面的应用，Skill 相当于各类开发框架和 SDK。平台负责提供通用能力，具体业务该怎么做，由业务部门自己决定。

以设计部门为例。为了让 Agent 掌握设计师的工作方法，花椒技术团队会先与设计师交流，将他们的专业经验整理成 Skill，再放到 Agent 中测试和迭代。“这些东西是他们沉淀的，我们更多是引导。业务方法进入 Skill 以后，仍然需要专业负责人持续维护，并通过真实任务验证。技术团队负责运行与治理机制，业务部门负责专业规则和结果标准。平台能够复用，不意味着不同部门的专业判断可以被同一套通用提示词替代。”封冰清说道。

当越来越多的 Agent 进入业务，花椒还需要解决一个问题：这些 Agent 由谁管理，如何保证它们按照预期运行？

为此，花椒在平台中设计了专门的控制与治理层，统一管理企业内部的应用、Agent、Skill、执行环境和用户权限。按照花椒的设计，面向用户的是应用，一个应用可以关联多个 Agent，每个 Agent 又可以调用不同的 Skill，并绑定相应的执行环境和知识库权限。这些能力都被纳入同一套管理体系。

版本管理是其中重要的一环。比如，用户发起一次对话，平台需要明确当前调用的是哪个版本的 Agent、对应哪些版本的 Skill，以及任务运行在本地环境还是沙箱中。即便后续 Agent 或 Skill 发生更新，也能明确每次任务实际使用的配置。此外，这套治理体系还与企业原有的用户体系关联，统一管理不同用户能够使用哪些 Agent、访问哪些知识库和执行环境，避免 Agent 成为绕过企业权限管理的新入口。

再往下一层，是负责具体执行的 Agent Runtime。与上层的应用管理不同，这一层不关心具体业务规则，而是负责 Agent 的运行循环：根据任务目标、指定的模型和可用工具，驱动 Agent 一步步完成任务。花椒还在 Runtime 中引入了事件化机制，记录 Agent 每一步的执行状态，让任务运行过程能够被追踪和管理。

最底层则是资源接入与执行环境。资源接入决定 Agent 能访问哪些知识、数据和业务系统，执行环境则负责承接实际的工具调用与任务执行。

与上层的 Agent Runtime 不同，执行环境需要直接处理文件读写、命令执行等操作。这些操作最终都要落到具体的计算资源上。当平台同时服务多个用户时，不同 Agent 可能共享同一台服务器，如何隔离各自的文件、进程和运行状态，就成了一个绕不开的工程问题。

沙箱正是解决这类问题的一种方式。但花椒并没有选择让所有 Agent 都运行在沙箱中。“沙箱是选项，不是标配”，这是花椒在搭建 Agent 平台时形成的判断。

在封冰清看来，企业 Agent 平台应该具备沙箱能力，但并不意味着每个 Agent 都必须在沙箱里运行。至于什么场景才要上沙箱，花椒的思路是按 Agent 的定位来判断。判断的核心只有一个：这台执行环境上的资源，需不需要在多个用户之间物理隔离。如果 Agent 管理的是一台专属机器，工作内容只有单一主体在消费，用不用沙箱没有区别；同一台执行环境一旦要服务多个用户，每个人的工作状态必须彼此独立，一般就会选择沙箱。

花椒的 CubeSandbox 实践

在沙箱选型之前，花椒采用的是最原始的方案：单服务器目录隔离。其间遇到了一系列问题：缺乏隔离能力，用户 A 理论上可以通过 Agent 操作到用户 B 的文件。评估几类方案后，团队发现都不匹配：Docker 启动慢、隔离不彻底、性能低；传统虚拟机成本高，资源分配也不灵活。MicroVM 级的方案层面，团队调研、测试对比了启动速度后，发现 CubeSandbox 最快，特性和性能也符合预期，尤其是强隔离这一条，经过实验确认能满足需求。因此，花椒最终选择接入腾讯云开源项目 CubeSandbox。（Cube Sandbox 源码：https://github.com/tencentcloud/CubeSandbox）

选型确定之后，还有一个问题需要解决：用户的数据放在哪里？沙箱可以随时销毁，但用户的文件和工作成果必须保留下来。花椒最初将数据存放在独立数据盘上，后来为了支持故障切换，改用了 NFS 方案。用户的持久化数据全部写到 NFS 目录，云服务器故障后，可以由新机器重新挂载 NFS 上的持久化文件；运行中的进程和任务能否继续，需要另行处理。

据介绍，这套方案接进 Cube 靠的是host-mount 机制：部署在云服务器上的执行环境守护进程，把不同目录映射到沙盒内部，沙盒内部无法做权限逃逸，守护进程只关注最小粒度的会话，一个会话对应一个沙盒。

除了使用 Cube 原有的能力，花椒还在其上自研了一套名为 agentd 的终端协议，用来和 Agent 平台的执行环境服务对接，与 Cube 模版里自带的 envd 并存分工，并在制作沙盒模版时默认启动。

开发 agentd 的原因很简单。其一，花椒需要一套自己定义、能够长期独立演进的终端协议，而不是把 Runtime 的会话模型直接绑定在 Cube 或 E2B 的外部 API 语义上；其二，花椒需要一个能直接验证“挂载后的技能和工件是否真的在 Sandbox 内可见”的接口（StatFiles），并且需要一套自己可控的 bearer-token 认证边界；其三，花椒在早期实现时曾遇到过一个具体的缺陷——Cube API 没有把创建 Sandbox 时设置的环境变量传递到 CubeMaster，导致团队原计划给每个 Sandbox 注入一个随机 AGENTD_TOKEN 的方案无法成立，后来改成模板和 Worker 共享一个固定 token。更准确的说法是：agentd 补的是花椒本身需要的契约、可控性和故障语义，不是在补 envd 缺失的通用执行能力。

目前，Cube 已经在花椒生产环境运行了 6 个多月。支撑了花椒和花房两个实例的大约 30 个 Agent 应用，日均 token 消耗约 8300 万。封冰清表示，目前已经验证了沙箱的隔离能力，评估沙箱的成本价值，不能只看启动速度，还要综合考虑完成一项任务的资源消耗、日常维护成本、资源闲置率以及故障对其他任务的影响。（关于花椒 Agent 平台的架构思考与 Cube 实践更多内容可点击文章详细了解：）

3 30 个 Agent 落地后，如何从单点提效走向组织协同？

这种按需选择基础设施的思路，也延续到了跨组织部署上。花椒在平台设计之初，就考虑过未来向集团其他部门复用的可能性。后来，花房集团中台开始建设自己的 Agent 应用，正好成为检验这套架构通用性的一次机会。

真正落地第二套平台时，团队还是发现了一些问题。比如，原先围绕花椒业务设计的用户体系，并不能直接适用于集团中台，需要进一步调整。此外，两套平台虽然复用同一套代码，但各自有不同的业务需求，后续的代码维护、版本发布和升级也需要兼顾双方。

最终，花椒采用了“统一公共代码，分开组织配置”的方式，并把版本升级作为复用能力的一部分：花椒与花房复用同一套 Agent Runtime 代码，但分别部署独立实例，账号体系、业务数据、执行环境和控制面彼此隔离，各自管理业务配置和运行环境。

第二个组织检验的，不只是同一套代码能否运行，还包括用户体系能否适配、公共版本能否持续维护，以及升级是否会破坏各自的业务。复用需要同时控制下一次接入成本和后续维护成本，这也是平台从内部能力走向产品化时必须面对的问题。

目前，花椒已在业务侧和集团中台落地约 30 个 Agent 应用，但这些 Agent 仍以单点提效为主。比如，产品人员可以通过 Agent 编写需求，运营人员可以通过对话查询数据，法务部门也有自己的工作台。这些应用解决了一部分实际问题，但大多仍围绕某个岗位或部门展开。

为了进一步提升组织效率，花椒接下来会重点关注两个方向：

第一个方向，是把已有的 Agent 串进完整业务流程。

产研自动化是花椒正在尝试的场景。一个需求从提出到上线，通常要经过产品、设计、研发、测试等多个环节。花椒虽然已经在这些环节分别部署了 Agent，但目前仍需要人工衔接。封冰清希望，未来一些相对标准化的小需求，可以由产品人员直接发起任务，再由 Agent 完成后续设计、技术评估、代码开发和测试，最后交给相关人员验收。目前，团队已经开始在部分小需求上进行尝试。

这类协同需要进一步明确：上一步交付什么，下一步按什么标准接收，失败时退回哪个环节，由谁确认可以继续。平台需要保存任务状态、配置版本和交付证据，业务负责人则需要确定验收标准和最终责任。多个 Agent 能够依次运行，只是流程协同的起点。

第二个方向，是让 Agent 更直接地服务于公司的整体经营目标。

过去，各部门提出 Agent 需求，通常从自己的 KPI 出发。运营关注运营效率，产品关注需求交付，研发关注开发速度。每个部门都可能通过 Agent 获得提升，但这些局部改善，未必能反映到公司的整体经营指标上。因此，部门局部提效并不能直接证明公司的整体经营结果得到改善，还需要检查这些变化是否共同作用于核心经营目标。

对此，花椒开始尝试从集团整体经营目标出发，反过来拆解各部门需要什么样的 Agent。例如，用户活跃、进房率、直播间转化等指标，往往同时涉及产品、运营和主播管理等多个环节。花椒希望通过经营分析类 Agent，将不同部门的数据结合起来，帮助管理层找到影响经营指标的关键问题，再明确由相关部门采取行动。

行动之后，还需要回看结果：问题是否得到改善，原先的判断是否成立，下一步是否需要调整。经营分析的价值，要沿着数据、判断、行动和结果形成完整的验证过程。

“如果要做经营分析，或者把整个组织流程串起来，数据一定要打通。”封冰清说道。这里的数据打通，是在授权范围内统一必要口径、关联业务数据，并不意味着集中搬迁所有数据或扩大访问权限。跨部门分析还需要继续沿用原系统的授权边界。经营分析往往涉及多个部门的大量业务数据，不同岗位能够访问的数据范围也不一样。封冰清认为，企业没必要为 Agent 重新建设一套权限系统，成本太高。更合理的做法，是沿用现有业务系统的权限体系，让 Agent 在原有授权范围内访问数据、调用工具。

平台搭起来之后，还需要在业务里验证价值。为了不错过这波 AI 热潮，很多企业选择什么都做。但正如前文所说，花椒对 AI 落地的态度是“企业不应该完全迷恋 Agent 或者 AI”，因为从 Demo 到真正进入业务，还存在巨大的 Gap。

封冰清对此有过一次印象深刻的教训。此前，花椒曾尝试用 Agent 帮助结算部门处理对账和数据分析。Demo 阶段效果不错，但真正进入生产后，团队发现，如果将表格汇总、数据处理等环节全部交给 Agent，不仅执行过程复杂，成本也远超预期。

按照他的回忆，当时一个场景运行几天，单个用户就消耗了两三万元。这让他重新思考，哪些工作真的需要 AI。在他看来，企业应该先梳理业务流程，再决定哪些环节需要模型判断，哪些可以交给程序和规则，哪些必须保留人工确认。

这也影响了花椒评价 Agent 价值的方式。平台已经支持用量、使用人数和预估费用等统计，完整任务的质量与总成本评价仍在完善。团队关注的是完成一件合格工作的总成本，其中包括模型调用、人工复核、返工和持续维护。

确定性的数据汇总与计算，应优先使用可以验证的程序；需要理解和判断的部分再交给模型；涉及重要业务责任的环节保留人工确认。技术路径的选择，需要回到同一项任务的质量、成本与风险。

封冰清认为，企业自建 Agent 平台既要持续建设必要的底层能力，也要持续比较外部方案。成熟产品已经能更经济地解决问题，就应该考虑替换。评估时拿同一批真实任务比较，既看结果，也看接入、复核、维护和迁移成本。模型或工具变了，原有业务规则、权限和验收样本尽量保留下来，团队才不必每次从头摸索。具体模型、框架和工具可以替换，已经积累的业务规则、权限映射、系统连接和验收样本应尽量保留。技术升级的价值，最终需要体现在真实任务的质量和成本上。

这也是“在船上”的意义。只有亲自做过以后，才知道一项新能力可能解决什么，也知道它还没有回答什么。对于花椒而言，持续投入 AI 的价值，也在于让这种判断和落地能力留在团队里，未来无论技术如何变化，都有能力继续往前走。

4 写在最后

半年多时间，从产研自动化起步，到落地约 30 个 Agent 应用，花椒已经验证了 Agent 在多个业务场景中的可行性，也搭出了一套能够跨组织复用的平台。

这套平台还在不断调整，如果重新做一次，封冰清希望更早区分模型调用、Agent 运行和命令执行的职责，让应用按需组合，避免过早将所有功能集中到一套系统中。同时，身份权限、版本管理和任务记录等基础能力，也需要更早建立明确的边界和验收标准。

不过，封冰清并不后悔早期的自研投入。在他看来，企业技术团队有必要亲自研究和尝试 Agent 的底层技术。只有真正做过，才能判断开源方案和商业产品各自适合解决什么问题。“如果商业化版本越来越好了，越来越便宜了，我们觉得没必要再自研，就可以果断放弃。”封冰清说道。

这种开放态度，也会延续到花椒下一阶段的平台建设中。技术上，团队将继续降低 Runtime 与其他模块的耦合，完善长任务的恢复能力，以及跨组织部署和版本升级的验证机制。业务上，则希望进一步接入外部工具和企业系统，让 Agent 能够参与更多完整的工作流程。

对于企业 Agent 的未来，封冰清有两个判断：一是底层能力会越来越开放，企业可以根据具体需求组合模型、工具和执行环境；二是 Agent 会从个人助手逐渐进入组织流程，承担更长时间、跨多个系统的工作。这意味着，企业需要积累的能力可能会发生变化。模型和 Agent 框架仍在快速迭代，但企业自己的业务规则、专业知识、系统接口和数据权限，很难直接从外部买来。

这些关于业务积累和持续交付的思考，也延伸到了超序 AI 的产品化探索中。封冰清希望基于花椒和花房的内部实践，从具体业务问题切入，逐步沉淀能够服务同类企业的解决方案和系统，并在外部市场继续验证交付成本与业务价值。

对花椒来说，30 个 Agent 已经证明，这套技术能在不少具体工作中发挥作用。下一步要回答的，是当这些 Agent 开始共同完成一件事时，能否真正改善业务结果。毕竟，企业最终关心的，从来都不是部署了多少个 Agent，而是有多少工作因此做得更好了。