1. 从五个产品各自为战到一套底座统管WorkBuddy 企业版套件化的真实动机企业级 Agent 产品做久了几乎都会撞上同一堵墙产品线越铺越宽底层能力却各写各的。WorkBuddy 企业版这次做的事情说白了就是把原本散落在五个产品里的 Agent 能力抽出来做成一套统一的底座再让五个产品像插件一样挂上去。这个决策听起来像是架构师的洁癖但真正推动它的是运维和交付团队被反复折磨出来的痛。我接触过不少做 Agent 平台的团队早期几乎都是一个产品一套 Agent 逻辑。A 产品有自己的工具调用层B 产品有自己的记忆管理C 产品又搞了一套完全不同的权限模型。表面上看每个产品都能跑但一旦客户要求把这三个能力串起来做一个工作流整个团队就得开始做集成地狱。更麻烦的是当底层模型升级、工具协议变更、安全策略收紧时你要在五个地方分别改五遍还极容易漏掉某一个。WorkBuddy 企业版套件化的核心思路可以用一句话概括把 Agent 当成操作系统把五个产品当成运行在它上面的应用。这个类比不是修辞而是实实在在的架构选择。操作系统负责进程调度、内存管理、设备驱动、权限控制应用只管自己的业务逻辑。对应到 WorkBuddy 里底座负责 Agent 的运行时、工具注册、上下文管理、安全沙箱、OpenAPI 网关五个产品只管自己的场景编排和用户界面。为什么这个选择在当下特别重要因为 Agent 这个领域变化太快了。今天流行某种工具调用协议明天可能就换成另一种今天大家用某类向量检索方案明天可能就被新的记忆机制取代。如果每个产品都把这些底层细节焊死在自己的代码里那每次技术迭代都是一次全量重构。而有了统一底座之后底层换血只需要在底座做一次五个产品几乎无感。这里有个容易被忽略的点套件化不等于简单地把代码抽成公共库。很多团队以为把重复代码抽成一个 npm 包或者内部 SDK 就叫平台化了结果发现五个产品对公共库的期望完全不同——A 产品要它轻量B 产品要它功能全C 产品要它能热更新。最后这个公共库变成了一个谁都不敢动的怪物。WorkBuddy 的做法是把它做成一个有明确边界和契约的运行时底座产品通过标准接口接入而不是直接依赖内部实现。这个区别决定了后面能不能真正解耦。从关键词里能看到不少相关线索Agent、CodeBuddy、OpenAPI、Skill、Agent 架构、Agent 开发。这些词拼在一起其实勾勒出了套件化的几个关键支柱——统一的 Agent 运行时、标准化的能力接入协议OpenAPI、可复用的技能单元Skill、以及面向开发者的扩展体系。下面我会逐个拆开讲尽量把每个决策背后的为什么说清楚。2. Agent 底座到底该管什么边界划错的代价比不做还大2.1 底座管太多会变成瓶颈管太少等于没管做统一底座最容易犯的错误是把边界划得过于宽泛。我见过一个团队他们的Agent 底座几乎接管了所有事情从模型调用、Prompt 拼装、工具执行到业务状态管理、用户会话、甚至前端渲染逻辑。结果就是底座变成了整个系统最复杂的部分任何产品想改一点东西都要动底座底座团队成了全公司的瓶颈。WorkBuddy 企业版在划边界时遵循的是一条很朴素的原则底座只负责所有 Agent 都必须有、且实现方式应该统一的能力。具体来说它管这几件事Agent 运行时Agent 的生命周期管理、任务调度、上下文窗口的分配与回收。工具与技能注册统一的工具描述格式、调用协议、执行沙箱。模型接入层多模型路由、降级策略、Token 计量。安全与权限Agent 能访问什么、能调用什么、数据边界在哪。OpenAPI 网关对外暴露标准接口让五个产品和外部系统都能接入。而它不管的事情同样重要具体业务逻辑、产品特有的交互流程、领域知识库的组织方式、前端展示形态。这些留给五个产品自己决定。这个边界不是拍脑袋定的而是根据变更频率来划分的——底层能力变更频率低但影响面大适合统一业务逻辑变更频率高但影响面小适合分散。2.2 五个产品如何共用一套运行时而不互相踩脚五个产品跑在同一套底座上最直接的风险是资源争抢和故障扩散。A 产品的一个死循环把 CPU 占满B 产品跟着卡死C 产品的一个内存泄漏把整个底座拖垮。这类问题在单体架构里很常见套件化之后如果处理不好反而会比各自为战更糟。WorkBuddy 的解法是在底座里做资源隔离和配额管理。每个产品接入时会被分配独立的运行时上下文包括独立的执行队列、内存配额、并发上限。Agent 执行任务时底座会根据产品标识做资源核算超限的任务会被排队或拒绝而不是无限制地抢占资源。这个机制听起来像是基础设施层面的事情但对 Agent 产品特别关键因为 Agent 的任务往往是不确定时长的——一次工具调用可能 100 毫秒返回也可能因为外部 API 超时卡 30 秒。另一个关键设计是故障隔离。底座里的每个产品运行在独立的沙箱中一个产品的异常不会直接传播到其他产品。底座会捕获异常、记录上下文、按策略重试或降级。这里有个实操经验降级策略一定要在产品接入时就配置好而不是等出事了再补。比如某个产品依赖的外部服务挂了底座应该返回一个明确的降级结果而不是让 Agent 无限重试把队列堵死。2.3 底座与产品的契约接口稳定性比功能丰富更重要套件化能不能长期维持取决于底座和产品之间的契约是否稳定。我见过太多平台一开始接口设计得很漂亮但随着产品需求变化底座不断加参数、改语义最后接口变成了一个谁都不敢碰的泥球。WorkBuddy 在契约设计上做了两件事值得参考。第一是版本化底座的 OpenAPI 有明确的版本号产品接入时声明自己依赖的版本底座保证同一大版本内的向后兼容。第二是能力声明式接入产品不是直接调用底座的内部函数而是通过声明自己需要哪些能力比如我需要工具调用我需要长期记忆底座根据声明来装配运行时。这样底座内部实现怎么改只要能力语义不变产品就不用动。这个设计的好处在实际运维中体现得很明显。有一次底座团队想换掉底层的向量检索实现从一种方案换成另一种。因为产品只声明了我需要记忆能力没有依赖具体实现所以这次替换对五个产品完全透明上线后没有任何产品需要改代码。如果当初产品直接调用了具体的检索 API这次替换就是五个产品的改造工程。3. OpenAPI 与 Skill 体系让五个产品说同一种语言3.1 OpenAPI 不只是接口文档而是能力契约的载体很多人把 OpenAPI 理解成给外部调用者看的接口文档但在 WorkBuddy 套件化里它的角色要重得多。它是底座和产品之间、产品和产品之间、以及外部系统和整个套件之间的统一语言。五个产品要互相调用能力、要共享工具、要串联工作流靠的就是这套 OpenAPI 定义的契约。具体来说WorkBuddy 的 OpenAPI 定义了几类核心资源Agent 实例、Skill、工具、会话、任务。每个资源都有标准的创建、查询、执行、销毁接口。产品接入时实际上是把自己的能力包装成符合这套 OpenAPI 的服务注册到底座的网关里。这样其他产品或者外部系统就能用统一的方式发现和调用它。这里有个设计细节很关键OpenAPI 的粒度。如果粒度太粗比如只暴露一个执行任务的接口那调用方就没法精细控制如果粒度太细比如把 Agent 内部每一步都暴露出来那接口会变得极其复杂且难以维护。WorkBuddy 选择的粒度是以 Skill 为单位——每个 Skill 是一个独立的能力单元有明确的输入输出定义可以单独调用也可以组合调用。这个粒度刚好匹配 Agent 的工作方式因为 Agent 本质上就是在编排一个个 Skill。3.2 Skill 的标准化从每个产品自己写工具到一次编写处处可用Skill 是这套体系里最贴近开发者的一层。在没有统一 Skill 体系之前每个产品要接入一个新工具都得自己写一遍适配代码参数怎么传、返回值怎么解析、异常怎么处理、权限怎么校验。五个产品就是五套适配代码维护成本高不说还容易出现行为不一致。WorkBuddy 的 Skill 体系把这些统一了。一个 Skill 用标准格式描述它叫什么、接受什么参数、返回什么结果、需要什么权限、在什么沙箱里执行。写好之后注册到底座五个产品都能直接调用。这带来的直接好处是能力复用——比如一个文档解析SkillA 产品用它处理合同B 产品用它处理论文C 产品用它处理工单底层是同一份实现。从关键词里能看到skill 编码skill 插件codex 常用 skill这些词说明 Skill 生态正在成为 Agent 领域的一个热点。WorkBuddy 在这方面的做法是提供一套 Skill 开发规范和一个注册中心。开发者按照规范写好 Skill提交到注册中心经过审核后就能被所有产品使用。这个模式有点像应用商店但更偏向企业内部的能力市场。3.3 五个产品如何通过 Skill 组合出各自的差异化能力统一底座和 Skill 体系会不会导致五个产品变得同质化这是很多人的担心。实际上恰恰相反——底座统一的是能力产品差异化的是编排。就像所有手机都用同样的芯片和操作系统但不同品牌的手机体验完全不同差异在于它们怎么组合这些底层能力。WorkBuddy 的五个产品各自有不同的场景定位。有的偏向代码开发对应 CodeBuddy 这类关键词有的偏向文档处理有的偏向数据分析有的偏向工作流自动化有的偏向知识管理。它们共享底座的 Agent 运行时和 Skill 库但各自编排出了不同的工作流。比如代码开发产品会重点组合代码解析、代码生成、测试执行这类 Skill文档处理产品会重点组合文档解析、摘要生成、格式转换这类 Skill。这种共享底座 差异化编排的模式让五个产品既能快速迭代因为底层能力不用重复造又能保持各自的特色因为编排逻辑是独立的。从工程角度看这是套件化最理想的状态——复用最大化耦合最小化。4. 套件化落地时最容易踩的五个坑4.1 坑一底座团队和产品团队的目标不一致套件化推进过程中最常见的组织问题是底座团队和产品团队的 KPI 不一致。底座团队想的是接口要稳定、要通用、要优雅产品团队想的是这个需求下周就要上线你能不能先给我加个特例。两边拉扯的结果往往是底座被各种特例污染慢慢失去了通用性。WorkBuddy 在推进时采取的做法是把底座当成内部产品来运营。底座团队有明确的客户——就是五个产品团队有服务等级协议有需求响应流程也有拒绝不合理需求的权力。产品团队提需求时需要说明这个需求是通用的还是个例的如果是个例底座团队会建议产品自己在编排层解决而不是改底座。这个机制听起来有点官僚但实际运行下来它保护了底座的整洁性也逼着产品团队想清楚自己真正需要什么。4.2 坑二过早追求统一把还没稳定的东西也抽象了另一个常见的坑是抽象过早。有些能力在五个产品里确实有重复但重复的部分还在快速变化这时候强行抽象成统一底座反而会把变化锁死。我见过一个团队把还在频繁调整的 Prompt 模板抽成了底座能力结果每次调 Prompt 都要走底座的发布流程产品团队怨声载道。WorkBuddy 的策略是先观察再抽象。一个能力如果在多个产品里出现且实现方式已经趋于稳定才考虑下沉到底座。判断标准很简单如果这个能力在未来三个月内不太可能大改就值得抽象如果还在快速迭代就先让各产品自己实现等稳定了再说。这个延迟抽象的原则避免了很多返工。4.3 坑三安全边界在套件化后被放大套件化之前每个产品的安全边界是独立的。A 产品的 Agent 只能访问 A 产品的数据B 产品的 Agent 只能访问 B 产品的数据。套件化之后所有产品共享一套底座如果权限模型没设计好就可能出现 A 产品的 Agent 访问到 B 产品数据的情况。这个风险在 Agent 场景下尤其严重因为 Agent 会自主调用工具一旦权限失控影响面比传统应用大得多。WorkBuddy 在底座里做了细粒度的权限模型。每个 Agent 实例在创建时会绑定一个权限上下文明确它能访问哪些数据、能调用哪些 Skill、能触达哪些外部系统。底座在执行任何操作前都会校验权限越权操作直接拒绝并记录审计日志。这里有个实操建议权限模型要在套件化设计的第一天就定好不要等出了问题再补。因为权限是横切关注点后补的话要改所有产品的接入代码成本极高。4.4 坑四可观测性没跟上出了问题不知道是谁的锅五个产品跑在同一套底座上一旦出现性能问题或者异常定位难度会比独立部署大得多。是底座的问题还是某个产品的问题是资源争抢还是代码 bug如果没有完善的可观测性排查会变成一场噩梦。WorkBuddy 在底座里内置了全链路追踪和指标采集。每个 Agent 任务从创建到完成每一步都有 trace 记录包括调用了哪个 Skill、耗时多少、消耗了多少 Token、有没有触发降级。这些数据按产品维度聚合产品团队可以随时看到自己产品的运行状况底座团队也能看到整体资源使用情况。这个能力在套件化里不是可选项而是必需品——没有可观测性套件化就是黑盒运维。4.5 坑五文档和示例滞后新接入方上手成本高套件化的价值很大程度上取决于接入的便利性。如果五个产品接入底座要花几周时间读源码、猜接口那套件化的收益就被抵消了。WorkBuddy 在这方面投入了不少精力做接入文档和示例代码每个核心能力都有可运行的示例新接入方可以照着示例快速跑通。这里有个经验文档要跟着接口版本走而不是跟着发布时间走。很多团队的文档是写一次就不管了接口改了文档没改结果文档反而成了误导。WorkBuddy 的做法是把文档生成集成到接口定义里接口改了文档自动更新保证一致性。5. 从套件化实践中沉淀出的几条硬经验5.1 底座的能力清单要定期审视该砍的砍底座做久了能力会越来越多这是自然趋势。但能力多不等于价值大有些能力可能只有一两个产品用维护成本却很高。WorkBuddy 会定期审视底座的能力清单把使用率低、维护成本高的能力标记出来要么合并要么下放给产品自己实现。这个定期瘦身的机制很重要。我见过一些平台底座能力只增不减几年下来变成了一个巨大的遗留系统新来的工程师根本不敢动。底座的健康度不在于它有多少能力而在于它的每个能力是否都被充分利用。5.2 产品接入要提供最小可用路径新产品的接入体验直接决定了套件化的推广速度。如果接入一个新产品需要理解底座的全部设计那没人愿意接。WorkBuddy 提供了最小可用路径——一个产品只需要实现几个核心接口就能跑起来一个基础 Agent然后再按需接入更多能力。这个渐进式的接入方式降低了起步门槛也让产品团队能快速看到效果。5.3 版本升级要有灰度机制底座升级影响所有产品一旦出问题就是全局故障。WorkBuddy 的底座升级采用灰度机制先在内部环境验证再选一两个产品试点确认没问题后再全量。产品也可以选择锁定版本在一段时间内不跟随底座升级给自己留出适配时间。这个机制在快速迭代的 Agent 领域特别重要因为底层变化频繁没有灰度就等于每次升级都在赌。5.4 把 Agent 安全当成底座的一等公民Agent 安全是个容易被低估的话题。传统应用的安全边界相对清晰但 Agent 会自主决策、自主调用工具攻击面大得多。WorkBuddy 把 Agent 安全做成了底座的内置能力包括输入输出过滤、工具调用白名单、敏感操作二次确认、异常行为检测等。这些能力对所有产品生效产品不需要自己实现。从关键词里能看到agent 安全这个词说明这已经是行业共识。我的建议是Agent 安全不要等到产品上线后再补要在底座设计阶段就纳入。因为安全是横切的后补的成本远高于前置设计。5.5 套件化的最终衡量标准是交付效率套件化做得好不好最终要看一个指标新能力从想法到上线的时间。如果套件化之后五个产品接入一个新 Skill 只需要几天而套件化之前需要几周那这个方向就是对的。WorkBuddy 在推进套件化的过程中一直用这个指标来校准方向——不是为了架构优雅而套件化而是为了交付效率而套件化。我在实际项目里最大的体会是套件化不是一次性的架构改造而是一个持续运营的过程。底座和产品的关系需要不断调整能力边界需要定期审视接入体验需要持续优化。把它当成一个产品来运营而不是当成一个项目来交付这套体系才能真正发挥价值。