花椒直播落地约 30 个 Agent：企业为什么最终选择自研平台

InfoQ 中文 2026-10-26T21:53:57.530172

企业接入 Agent 的门槛正在快速降低，但让 Agent 在真实业务中稳定运行、持续演进，仍是另一回事。花椒直播从产研自动化切入，用约一个月搭起自研 Agent 平台，把运行时、权限、统计等共性能力收进平台，业务侧只负责 Skill、Prompt 和模型选择。目前已有约 30 个 Agent 应用落地。

今年企业做 Agent 最大的变化是门槛变低，但“做出一个能完成任务的 Agent”和“让它在业务中持续稳定运行”之间仍有距离。Agent 数量和使用频率一旦放大，原本不显眼的问题也会跟着放大。

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

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

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

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

先梳理业务，再谈 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 到底能解决什么问题。

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

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

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

约 30 个 Agent 落地，如何判断值不值得做

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

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

关键要点

AI 让内容生成变快了，但审核、审批未必同步提速。如果流程真正的瓶颈在等待审批，继续优化生成速度也解决不了问题；如果审核跟不上生成，企业反而要缩小自动化范围。这也是企业 AI 最终会撞上组织问题的原因。封冰清说，技术团队可以把功能做出来，但专业标准、验收必须由业务团队参与；跨部门的目标、资源和责任冲突，需要管理者推动，不能指望工程师靠调提示词解决。

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

业务和技术的边界，是花椒设计 Agent 平台时的核心问题。Agent 应用越来越多之后，团队发现平台本身也需要做减法。

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

于是花椒重新划分平台职责，把模型服务、Agent 运行、执行环境等逐步拆开，避免任何需求都套进完整 Agent 机制。分层之后，修改和测试的影响范围更可控，平台自身的复杂度也降了下来。

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

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

花椒 Agent 平台架构设计

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

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

以生成一个 H5 页面为例：用户在业务入口提交需求，平台先检查身份和授权，再由 Agent Runtime 创建任务、固定配置版本、组织材料并调用模型。模型可能需要读取文件或执行构建命令，这些操作交给相应的执行环境；工具返回结果后，Agent Runtime 再决定下一步，直到任务结束。执行过程中的事件会持续记录，应用据此展示进度和产物。

这套架构背后有一条明确原则：公共运行内核不承载部门专属业务逻辑，业务差异通过 Skill（技能包）、Prompt、工具接口和配置表达。花椒要守住的边界是：新增或调整一个部门的业务能力，尽量不需要修改所有 Agent 共用的运行内核。这样，不同业务可以复用公共运行能力，新增场景主要围绕业务方法、工具接口和配置展开，减少重复建设。

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

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

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

控制与治理：Agent 也要被管理

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

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

执行环境层：沙箱是选项，不是标配

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

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

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

沙箱是解决这类问题的常见方式，但花椒没有让所有 Agent 都跑在沙箱里。“沙箱是选项，不是标配”，这是花椒搭建 Agent 平台时形成的判断。

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

对正在搭建 Agent 平台的团队来说，这套分层的价值不在于多一层抽象，而在于把“谁管业务规则、谁管进程与文件隔离”分清楚了。

沙箱选型：为什么是 CubeSandbox

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

数据放在哪：NFS 与 host-mount

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

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

自研 agentd：补的是自己的契约

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

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

更准确的说法是：agentd 补的是花椒自身需要的契约、可控性和故障语义，而不是补 envd 缺失的通用执行能力。

生产运行六个月

目前 Cube 已在花椒生产环境运行 6 个多月，支撑花椒和花房两个实例约 30 个 Agent 应用，日均 token 消耗约 8300 万。封冰清表示，沙箱的隔离能力已经得到验证；评估沙箱的成本价值不能只看启动速度，还要综合考虑完成一项任务的资源消耗、日常维护成本、资源闲置率，以及故障对其他任务的影响。

（关于花椒 Agent 平台的架构思考与 Cube 实践更多内容可点击文章详细了解：https://mp.weixin.qq.com/s/_IFmCQvEp5-QPuoRM02z9Q）

从单点提效走向组织协同

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

一套代码复用到第二套平台，难点在哪

真正落地第二套平台时，团队还是遇到了一些问题。原先围绕花椒业务设计的用户体系，并不能直接套用到集团中台，需要进一步调整；两套平台虽然复用同一份代码，业务需求却各不相同，后续的代码维护、版本发布和升级也得同时照顾两边。

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

第二次组织检验关注的不只是同一套代码能否跑起来，还包括用户体系能否适配、公共版本能否持续维护，以及升级会不会破坏各自的业务。复用必须同时压住“下一次接入成本”和“后续维护成本”，这是平台从内部能力走向产品化绕不开的一关。

30 个 Agent 之后：从单点提效走向流程协同

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

要进一步提升组织效率，花椒接下来重点关注两个方向。

方向一：把已有 Agent 串进完整业务流程。

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

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

方向二：让 Agent 更直接地服务于公司整体经营目标。

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

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

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

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

一次昂贵的教训：哪些工作不该交给 AI

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

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

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

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

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

自研与采购：用同一批真实任务算账

封冰清认为，企业自建 Agent 平台要同时做两件事：一边持续建设必要的底层能力，一边持续比较外部方案。成熟产品如果已经能更经济地解决问题，就应该考虑替换。评估时，用同一批真实任务做对比，既看结果，也算上接入、复核、维护和迁移的成本。模型或工具变了，原有的业务规则、权限和验收样本尽量保留下来，团队才不必每次都从头摸索。

换句话说，具体模型、框架和工具都可以替换，但已经积累的业务规则、权限映射、系统连接和验收样本应尽量保留。技术升级的价值，最终要体现在真实任务的质量和成本上。

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

写在最后

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

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

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

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

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

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

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

查看原文