今年最大的一个变化是，企业做 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 应用的思路是，先从一线员工最迫切的需求入手，让大家看到 Agent 到底能解决什么问题。
以运营人员的数据查询工作为例。过去，运营人员查询主播直播数据或用户充值金额时，需要先打开电脑、连接 VPN、登录后台，有时还要在多个系统之间来回查找，最后整理信息向负责人汇报。基于这个真实痛点，花椒开发了一个 Agent，并接入办公软件。运营人员只需要在办公软件里提问，Agent 就能调用后台数据并给出结果。
这种方式得到了业务部门的认可，也让团队进一步意识到，Agent 的交互形式需要服从实际工作。开放问题适合通过对话探索；高频、规则明确的任务，则更适合提供固定入口、必要字段、任务进度和审核位置。
花椒因此将部分 Agent 从单纯的聊天交互转向工作台形态，并逐步抽象连接器、界面等通用能力。底层运行能力可以共用，业务入口则围绕各部门的任务和结果责任独立设计。
目前，花椒已经在业务侧和集团中台落地了约 30 个 Agent 应用，覆盖产研、运营、数据分析、客服、法务、行政以及 GR（政府关系）等多个场景。
在封冰清看来，企业判断一个方向是否值得落地 AI 应用，需要先想清楚最终拿什么证明它有用。“部门用了 AI”和“部门的工作变好了”，中间还有一段距离。真正值得持续投入的方向，应该是 AI 能让员工把原来的一件工作做得更好，或者让整个工作流程变得更高效。
比如，AI 生成内容的速度提高了，但审核却更慢，企业就需要缩小自动化范围；如果一个流程真正的卡点在审批等待，那么继续优化 AI 的生成速度，也无法解决实际问题。这也解释了，为什么企业 AI 最终会碰到组织问题。“技术团队可以实现功能，业务团队必须提供专业标准、参与验收。跨部门的目标、资源和责任冲突，需要我去推动，不能留给一个工程师靠调提示词解决”，封冰清提到。
花椒 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 实践更多内容可点击文章详细了解：https://mp.weixin.qq.com/s/_IFmCQvEp5-QPuoRM02z9Q）
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 的价值，也在于让这种判断和落地能力留在团队里，未来无论技术如何变化，都有能力继续往前走。
写在最后
半年多时间，从产研自动化起步，到落地约 30 个 Agent 应用，花椒已经验证了 Agent 在多个业务场景中的可行性，也搭出了一套能够跨组织复用的平台。
这套平台还在不断调整，如果重新做一次，封冰清希望更早区分模型调用、Agent 运行和命令执行的职责，让应用按需组合，避免过早将所有功能集中到一套系统中。同时，身份权限、版本管理和任务记录等基础能力，也需要更早建立明确的边界和验收标准。
不过，封冰清并不后悔早期的自研投入。在他看来，企业技术团队有必要亲自研究和尝试 Agent 的底层技术。只有真正做过，才能判断开源方案和商业产品各自适合解决什么问题。“如果商业化版本越来越好了，越来越便宜了，我们觉得没必要再自研，就可以果断放弃。”封冰清说道。
这种开放态度，也会延续到花椒下一阶段的平台建设中。技术上，团队将继续降低 Runtime 与其他模块的耦合，完善长任务的恢复能力，以及跨组织部署和版本升级的验证机制。业务上，则希望进一步接入外部工具和企业系统，让 Agent 能够参与更多完整的工作流程。
对于企业 Agent 的未来，封冰清有两个判断：一是底层能力会越来越开放，企业可以根据具体需求组合模型、工具和执行环境；二是 Agent 会从个人助手逐渐进入组织流程，承担更长时间、跨多个系统的工作。这意味着，企业需要积累的能力可能会发生变化。模型和 Agent 框架仍在快速迭代，但企业自己的业务规则、专业知识、系统接口和数据权限，很难直接从外部买来。
这些关于业务积累和持续交付的思考，也延伸到了超序 AI 的产品化探索中。封冰清希望基于花椒和花房的内部实践，从具体业务问题切入，逐步沉淀能够服务同类企业的解决方案和系统，并在外部市场继续验证交付成本与业务价值。
对花椒来说，30 个 Agent 已经证明，这套技术能在不少具体工作中发挥作用。下一步要回答的，是当这些 Agent 开始共同完成一件事时，能否真正改善业务结果。毕竟，企业最终关心的，从来都不是部署了多少个 Agent，而是有多少工作因此做得更好了。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
One of the biggest changes this year is that the threshold for an enterprise to be an Agent is getting lower, but there is still a distance between having an Agent that can accomplish its tasks and keeping it stable in its operations. Because when the number of Agents and the frequency of their use is amplified, many of the problems that were not visible are magnified.
The Agent practice provides a sample to observe this change.
The live CTO, the founder of the SuperSequent AI and CEO Ice Clear is facing two kinds of problems at the same time: how to keep technology running in real business, and how to turn internal accumulation into renewable, sustainable delivery of products and services.
Oversequence AI is an independent AI brand under the umbrella of the Cabrera Group, which promotes the integration of AI into the enterprise ' s production and business processes, targeting, from a mission-specific point of view, reusable solutions and systems for subdivided industries. The in-house practice of peppers and flowers provides technical and operational experience in this exploration.
From the automation of ISPs to the landing of about 30 Agent applications, the freezing of ice has developed a judgement that enterprises need to accumulate their own business methods, systems connections, permission rules and acceptance criteria on a continuous basis to enable models and tools to upgrade and value inputs with actual delivery results.
In this judgement, InfoQ shared the experience of the construction of the pepper Agent platform with Ice Clear: why self-study is chosen and why split has continued its responsibilities, how to deal with the boundaries between operations and the public nuclear system, and what engineering and management capacity needs to be filled from single point of effectiveness to organizational synergy.
Starting with the automation of production research, the Agent platform gradually grows.
After the spring festival, the "crawfish" was red at a near-crazy rate worldwide. Application of Agent as soon as possible became the most urgent thing for many businesses at the time.
The peppers seem calmer than most companies. “In our view, business should not be completely obsessed with Agent, or AI, before it landes, the first step is to combe business needs.” The point is that the starting point for the Agent practice is to hope that the technical team will “go to the AI ship” as soon as possible: by automating from production studies, the team will truly have the AI capability through practical application. As he envisaged, the technical team needed to master the new ways of working with AI as early as possible, to promote research and development through AI Coding, and to facilitate a complete process from product demand, design to development, testing.
But when it did, the team found out that things were not as simple as they thought. For example, to automate the R & D chain, upstream product demand must be sufficiently clear. The product team also needs to manage Skill, Prompt, models and the implementation environment to complete the requirements with Agent.
In addition, running time, implementation environment, permission and statistics are repeated in different Agents. If each application is built separately, the costs of delivery, drainage and maintenance will be repeated. The team has therefore begun to consider the deposition of these cross-cutting issues into a public capacity that allows the operational side to focus on its working methods and mandate requirements.
So, around March 2026, the peppers began researching the Agent program on the market and eventually decided to develop a corporate Agent platform. The objectives of the platform are clear, with common capabilities, such as running time, implementing environment, user permission, statistics, etc., being placed under the cover of the platform, with the operational side focusing on Skill, Prompt and model selections, and immersing its own working methods, mission requirements and intelligence capabilities. As a result, the development of a business, Agent, does not have to start from the base infrastructure every time. “Agent does not need to be a bottom infrastructure expert at the same time”, ice clears up.
It took about a month to get to the first version. The first version already has basic Agent management capabilities, including application creation, Skill configuration, implementation of environmental management, user permission and chat interaction. The team would like to verify a minimum closure: whether operational staff can create applications, equip capacity on the platform and do their work through dialogue.
The platform was only the first step, and the greater challenge was how to put staff to real use. Within the enterprise, the acceptance of Agent is not high among many employees, some of whom hear to do it, and the first reaction is to fear that their work will be replaced by AI. The idea for the grounding of peppers is to start with the most urgent needs of front-line employees and show you exactly what Agent can do.
Take, for example, data queries from operators. In the past, operators had had to turn on computers, connect VPNs, log-in backstages and, in some cases, search back and forth between multiple systems when searching for live feed data or user top up amounts, and then finalize the information and report back to the person in charge. Based on this real pain, peppers have developed an Agent and access to office software. Just ask questions in the office software, and Agent can call backstage data and give results.
This approach has been endorsed by the business sector and has raised the awareness of the team that the interactive form of Agent needs to be subordinated to actual work. Openness is appropriate for exploration through dialogue; high frequency, well-defined mandates are better suited to provide fixed access, necessary field, mission progress and clearance positions.
The peppers thus shift part of Agent from a simple chat to a working table pattern and gradually abstract universal capabilities such as connectors, interfaces, etc. Bottom operating capabilities can be shared, while the business portal is designed independently around the tasks and results responsibilities of the departments.
At present, there are about 30 Agent applications on the side of the business and in the middle of the group, covering multiple scenarios such as production research, operation, data analysis, customer service, legal affairs, administration and GR (government relations).
From the point of view of the ice freeze, the firm determines whether a direction is worth landing in AI applications, and needs to figure out what ultimately will prove to be useful. There is still a distance between “sector uses AI” and “sector work is getting better”. What really deserves to be sustained is that AI can get employees to do the original job better or make the entire Q52 Z process more efficient.
For example, the speed at which AI produces content has increased, but the review has been slower, and the enterprise needs to reduce automation; if a true process card point is waiting for approval, then continue to optimize the speed at which AI is generated and cannot solve the real problems. And that explains why the company AI eventually had organizational problems. “Technology teams can function, and business teams must provide professional standards and participate in acceptance check. Cross-sectoral conflicts of objectives, resources and responsibilities need to be driven by me, and cannot be left to an engineer to work with prompt, referred to in the freeze.
The technological thinking behind the peppers, Agent.
The boundary between business and technology is a key consideration in the design of the Agent platform, which, with the increasing use of Agent, found that the flat Z89Z body also needed to be reduced.
Early on, in order to support business landings as quickly as possible, the Agent platform carried a number of elements, including newapi, sandboxes, operating environment, user permission, etc., that were accessed by models. Some applications only want to call a model once, but rely on the entire Agent mechanism. In addition, the Agent platform for peppers is developed mainly through AI Coding, and the dependence between modules is becoming more complex as functions grow. A simple change may require AI to understand a large number of contexts, and the team has to check repeatedly whether other functions have been affected.
To this end, peppers began to redefine the Platform ' s responsibilities, gradually separating functions such as modelling services, Agent operation and implementation environment, and avoiding any need for a complete Agent mechanism. This layered design also makes the scope of the impacts of modifications and tests more manageable and reduces the complexity of the platform itself.
This practice makes the team clearer and the platform needs to address two types of changes simultaneously: the continuous adaptation of business methods and the continuous updating of models, tools and infrastructure. The hierarchy allows applications to select their capabilities according to the complexity of the mission, and limits the scope of the impact of one modification. Simple tasks can be called directly to the model, determining steps are given priority in the program and require multi-step judgement and tool call before using Agent.
AI Coding has accelerated code realization, but the costs of structure boundaries, compatibility and validation still require control. The technical officer needs to judge what the long-term costs of subsequent modifications, testing and maintenance would be for each additional capacity.
Plant Agent platform architecture design
Pepper divides the platform into four layers of responsibility:
- Operations portal carrying tasks and results;
- Control and governance management identity, permission, configuration, version and usage;
- Agent Runte organizational model judgement, tool call and operational status;
- Access to resources to connect the enterprise ' s original system to the implementation environment and provide the location for actual mission assignments.
These responsibilities revolve around the same mandate. permission goes through the implementation process with the audit, Runtme continues to carry out tasks and runs facts back to the application and governance levels.
As an example of generating an H5 page, after users submit their needs at the business entry, the platform first checks the identity and authorization, then the Agent Runtime creates tasks, fixed configuration versions, organises materials and calls models. Models may need to read files or execute build commands, and these operations will be assigned to the corresponding execution environment, and after the tool returns the result, Agent Runtime decides what next step does until the end of the mission. In addition, incidents in the course of implementation will be recorded on an ongoing basis and will be used to demonstrate progress and products.
Behind this architecture is a relatively clear principle: the exclusive business logic of the non-maintained sector in public operations, with operational differences expressed through Skill, Prompt, tool interfaces and configurations. The boundary that the peppers want to hold is to add or adjust the operational capacity of a department without, to the extent possible, the need to modify all operational cores shared by Agent. In this way, different operations can revert to public operating capacity, with new scenes being built around business methods, tool interfaces and configurations to reduce duplication.
This relationship is explained by a very visual metaphor: the Agent platform is equivalent to an operating system, and Agent is an application that operates on it, and Skill is equivalent to various development frameworks and SDKs. It is the responsibility of the Platform to provide generic capacity, and it is up to the operational departments to decide what to do with the specific business.
Take the design department, for example. In order to get Agent to master the designer's working methods, the flores technologist team will first communicate with the designer, organize their professional experience into Skill, then test and integrator in Agent. "These things are deposited, we are more guided. Once the business methodology has entered Skill, it will continue to require continuous maintenance by professional managers and validation through real task. The technical team is responsible for operational and governance mechanisms and the operational unit is responsible for professional rules and outcome standards. The re-use of the platform does not mean that the professional judgement of the different sectors can be replaced by the same set of generic prompts.” The ice-freeze narrative.
As Agent gets into business more and more, pepper needs to solve a problem: Who's running these Agents, and how do you make sure they work as expected?
To this end, peppers have been designed within the platform as a specific layer of control and governance to manage enterprise-wide applications, Agent, Skyll, the implementing environment and user permission. According to the design of the pepper, the user-oriented application is one that can connect multiple Agents, each Agent can call different Skills and bind the corresponding implementation environment and knowledge base permission. These competencies are integrated into the same management system.
Version management is an important link. For example, a user initiates a dialogue, and the platform needs to clarify which version of Agent is currently on call, which version of Skill is on call, and whether the task is running in the local environment or in sandboxes. Even if the following Agent or Skill are updated, the configuration actually used for each task will be clear. In addition, the governance system is linked to the enterprise ' s original user system, which centrally manages which Agents are available to different users, which knowledge banks and the implementation environment are visited, and which does not allow Agent to become a new entry point around the management of the enterprise permission.
Agent Runtme is responsible for implementation. Unlike the application management at the upper level, this layer is not concerned with specific business rules but is responsible for the running cycle of Agent: Drives Agent to complete the task step by step according to mission objectives, specified models and available tools. The peppers also introduce eventization mechanisms in Runtme to record the status of each step of Agent 's execution, so that the task run can be tracked and managed.
The bottom line is the environment for resource access and implementation. Resource access determines which knowledge, data and operating systems Agent has access to, while the implementing environment is responsible for the actual tool call and mission execution.
Unlike Agent Runtme, the execution environment requires direct processing of document reading and writing, command execution, etc. These operations ultimately fall on specific computing resources. When the platform serves multiple users at the same time, different Agents may share the same server and how to isolate their respective files, processes and operational status becomes an indissociable engineering issue.
Sandboxes are one way to solve such problems. But the pepper didn't choose to let all Agent run in the sandbox. "The sandbox is an option, not a match," which is the judgement that the pepper formed when building the Agent platform.
From the perspective of ice-freezing, the business Agent platform should have sandbox capacity, but that does not mean that every Agent must operate in sandboxes. And as for what's going on in the sandbox, the idea of peppers is to be judged by the position of Agent. There is only one centre of judgement: the environmental resource for implementation needs to be physically isolated between multiple users. If Agent manages an exclusive machine, the work is consumed only by a single subject, and the use of sandboxes does not make any difference; when there are multiple users served in the same implementation environment, each person must be independent of the other and usually chooses the sandbox.
CubeSandbox Practice for Pepper
Before the sandbox selection, peppers were the most primitive: single server catalogue segregation. A series of problems were encountered: lack of isolation, user A could theoretically use Agent to access user B files. After assessing several types of programmes, the team found that there was no match: the Docker launch was slow, incomplete and low performance; the traditional virtual machines were costly and the allocation of resources was not flexible. At the programme level of MicroVM, team research and testing compared start-up speeds, it was found that CubeSandbox was the fastest, with characteristics and performance meeting expectations, particularly the strong isolation, which was demonstrated to meet demand. As a result, peppers eventually chose to access the Tencent Cloud Open Source project CubeSandbox. (Cube Sandbox Source: https://github.com/tencentcloud/CubeSandbox)
Once the selection has been determined, there is another question that needs to be addressed: where are the user data? Sandboxes can be destroyed at any time, but user documents and work results must be preserved. Plant pepper initially stored the data on a stand-alone data disk, and was subsequently converted to the NFS programme to support the failure switch. Users ' durability data are all written to the NFS directory, and when the cloud server fails, the new machine can remount the durable files on the NFS; whether or not the running process and task will continue requires separate processing.
It was described that the package was integrated into Cube through a host-mount mechanism: the implementation of environmental daemons deployed on cloud servers, the mapping of different directories inside sandboxes, where permission could not escape, the dæmon focused only on the minimum particle size session, and one session corresponded to a sandbox.
In addition to using Cube's original capabilities, it has developed a set of terminal protocols, known as angentd, for docking with the Agent platform's executive environmental services, with the envd attached to the Cube template, and started by default when making the sandbox template.
The reason for developing an object is simple. First, pepper requires a self-defined, stand-alone terminal protocol, rather than a direct binding of the Runte session model to the external API syntax of Cube or E2B; second, pepper requires an interface (StatFiles) that can directly verify whether “post-mounted skills and works are actually visible in Sandbox” and requires a controlable bearer-token authentication boundary; and third, it encountered a specific defect in its early realization - Cube API did not transfer the environmental variables set up when Sandbox was created to CubeMaster, which resulted in the team planning to inject a random AGENTD TOKEN program into each Sandbox, which could not be set up and was later converted to a template and Worker shared a fixed token. To be more precise, it is the contract, controllability and malfunctioning semantics required by the peppers themselves, rather than the missing generic implementation capability of envd.
So far, Cube has been operating in the pepper production environment for over six months. Some 30 Agent applications, average daily token consumed about 83 million. The freeze indicates that the containment capacity of sandboxes has now been validated to assess the cost value of sandboxes, not only for start-up speed, but also for a combination of resource consumption, daily maintenance costs, resource idle rates and the impact of malfunctions on other missions.
(More details on the structure thinking and Cube practice on the pepper Agent platform can be found by clicking on the article: https://mp.weixin.qq.com/s/ IFmCQvEp5-QPuoRM02z9Q)
How can we move from a single point of effectiveness to organizational synergy when 30 Agents land?
This need-based choice of infrastructure also continues to be applied across organizations. At the outset of the platform ' s design, the possibility of future reuse to other parts of the group was considered. The construction of its own Agent application in the center of the florist group later became an opportunity to test the interoperability of the architecture.
The team found some problems when it actually landed on the second platform. For example, the user system originally designed around the business of peppers is not directly applicable in the middle of the group and needs further adaptation. In addition, while the two platforms revert to the same set of codes, they have different business needs, and subsequent code maintenance, version publish and upgrades need to be balanced.
Ultimately, the peppers were “Unified public code, separate organizational configuration” and upgraded as part of their reuse capacity: The peppers and the florist are reused with the same set of Agent Runtme codes, but are deployed in separate instances, with separate account systems, operational data, implementation environments and controls separated from each other, each managing its operational configuration and operating environment.
The second organizational test is not only whether the same code works, but also whether the user system is fit, whether the public version is maintained on a continuous basis, and whether the upgrade will undermine their respective operations. Reuse requires simultaneous control of the next access and subsequent maintenance costs, which is also a problem for the platform as it moves from internal capacity to productization.
At present, the peppers have been applied to about 30 Agents on the side of operations and mid-groups, but these Agents remain focused on single points. For example, producers can prepare their needs through Agent, operators can access data through dialogue and legal authorities have their own workstations. These applications solve some of the practical problems, but they are mostly organized around a particular post or department.
In order to further improve organizational efficiency, peppers focus next on two directions:
The first direction is to link the existing Agent into a full business process.
Automation of production and research is the scene where peppers are trying. A demand, from the point of view to the point of view, usually follows multiple stages of product, design, development, testing, etc. While Agent has been deployed separately at these stages, manual connection is still required. It is hoped that, in the future, some of the relatively standardized small needs can be directly initiated by the producer, followed by the following design, technical assessment, code development and testing by Agent, and finally handed over to the person concerned, acceptance check. Currently, the team has begun to try out some of the small needs.
Such synergies need to be further clarified: what was delivered in the previous step, what criteria next step received, which chain was returned in case of failure and who confirmed that it could continue. The platform will need to preserve mission status, configuration versions and delivery evidence, while the head of operations will need to determine acceptance criteria and ultimate responsibility. Multiple Agents can run sequentially, but only as a starting point for process synergy.
The second direction is to make Agent more directly serve the corporate business objectives.
In the past, departments raised the Agent needs, usually from their own KPI. Operations focus on operational efficiency, product focus on demand delivery and R & D on speed of development. Each sector may be upgraded through Agent, but these partial improvements do not necessarily reflect corporate performance indicators. Thus, partial sectoral efficiency does not directly support improved corporate performance, and there is also a need to check whether these changes contribute to core business objectives.
In response, the peppers began to attempt to start with the corporate business objectives of the group and, in turn, to break down what Agent was needed in the various sectors. For example, indicators such as active users, occupancy rates, and live-time conversion often involve multiple links, such as product, operation and anchor management. It is hoped that the data from different sectors will be combined through the business analysis category Agent to help management identify the key issues affecting the performance indicators and to clarify actions by the relevant departments.
After the operation, there was also a need to look back at the results: whether the problem had improved, whether the original judgement had been established and whether next step needed to be adjusted. The value of business analysis is to form a complete validation process along data, judgement, actions and results.
“If business analysis is to be done, or if the whole organizational process is to be linked, the data must be made available.” The ice-free zone says. Data penetration here is the harmonization of required calibre, associated operational data within the mandate and does not mean a centralized relocation of all data or expanded access to permission. Cross-sectoral analysis also needs to continue to follow the mandated boundaries of the original system. Business analyses often involve a large amount of business data from multiple sectors, and the range of data available to different jobs varies. According to Ice Clear, there is no need for businesses to re-establish a permission system for Agent, which is too expensive. A more rational approach would be to follow the permission system of the existing operating system and allow Agent to access data and access tools within the original mandate.
Once the platform has been installed, it will also be necessary to validate value in the business. In order not to miss this wave of AI heat, many firms choose to do anything. But, as we said before, the attitude of peppers to AI landings is that "businesses should not be completely obsessed with Agent or AI," because there is a huge Gap from Demo to real business.
An impressive lesson has been learned. Previously, the peppers had tried to assist the settlement department with reconciliation and data analysis using Agent. The Demo phase worked well, but when it actually entered production, the team found that it would not only be complex to implement, but would also be far more costly than expected if all the forms, data processing, etc. were submitted to Agent.
According to his recollection, one scene was running for days and individual users spent $230,000. It makes him rethink what really needs AI. In his view, an enterprise should first comb the business process before deciding which elements would require model judgement, which could be referred to procedures and rules and which would have to retain human confirmation.
It also affects the way in which the peppers evaluate the value of Agent. The Platform has supported statistics on usage, number of users and estimated costs, and the quality and overall cost evaluation of the complete mission is still well developed. The team is concerned with the total cost of completing a qualified job, which includes model calls, manual review, back-to-work and ongoing maintenance.
The definitive aggregation and calculation of data should prioritize the use of verifiable procedures; the parts that need to be understood and judged are then handed over to the model; and the links involving significant operational responsibilities are retained in human confirmation. The choice of technical pathways requires a return to the quality, cost and risk of the same task.
According to Ice Clear, the establishment of the Agent platform by an enterprise requires both the building of the necessary bottom capacity and the continuous comparison of external programmes. The replacement of mature products should be considered if they are already more economical. The assessment compares the same batch of real tasks with both the results and the costs of access, review, maintenance and relocation. Models or tools have changed and the original operating rules, permission and acceptance checkZ111Z have been kept as far as possible so that teams do not have to search each time. Specific models, frameworks and tools could be replaced, and the accumulated business rules, permission mapping, system connectivity and acceptance checksample should be retained to the extent possible. The value of technological upgrading will ultimately need to be reflected in the quality and cost of real task.
That is also the meaning of “on board”. It is only when it has been done in person that it knows what a new capability can solve and what it has not answered. For peppers, the value of continuous input to AI also lies in keeping this judgement and landing capability in the team, capable of moving forward in the future regardless of technological changes.
At the end.
Over a period of more than six months, from automating production research to about 30 Agent applications, the peppers have validated the viability of Agent in a variety of business scenarios and set up a platform that can be used across organizational boundaries.
The platform is constantly being adjusted and, if re-made, the freezer hopes to distinguish the functions of the model call earlier, the Agent operation and the command execution, to allow applications to be combined on a needs basis and to avoid the premature concentration of all functions into a system. At the same time, basic capabilities, such as identity permission, version management and mission records, also require the early establishment of clear borders and acceptance criteria.
However, the freeze does not regret early self-study inputs. In his view, it would be necessary for the enterprise technical team to personally study and try the bottom-up technology of Agent. Only if it is actually done will it be possible to judge what is appropriate for open source programmes and commercial products. "If the commercial version is getting better and cheaper, we don't think it's necessary to study ourselves again, so we can give it up." The ice cap says.
This openness will also continue into the next stage of the building of the platform. Technically, the team will continue to reduce the alignment of Runtume with other modules, refine the recovery capacity for long missions and the validation mechanism for cross-organizational deployment and upgrade of versions. Operationally, it is hoped that further access to external tools and enterprise systems will enable Agent to participate in more complete workflow courses.
For the future of the enterprise Agent, the freezer is judged by two judgements: first, that the bottom capacity will be increasingly open and that the enterprise will be able to combine models, tools and implementation environments based on specific needs; and second, that Agent will gradually move from personal helpers to organizational processes that will take on longer, multi-system jobs. This means that the capabilities that enterprises need to accumulate may change. Models and Agent frameworks continue to evolve quickly, but it is difficult for enterprises to buy their own business rules, expertise, systems interfaces and data permission directly from outside.
These reflections on business accumulation and continuous delivery have also extended to the productization exploration of over-order AI. The freezing of hopes is based on the internal practices of peppers and flower houses, cutting in from specific business issues, gradually sequestering solutions and systems that serve similar enterprises and continuing to validate delivery costs and business values in external markets.
For pepper, 30 Agents have proven that this technology works in a number of specific jobs. The answer to next step is whether real improvements in business results can be achieved when these Agents begin to do one thing together. After all, it is never how many Agents have been deployed, but how many jobs have done better.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.