最近接手了一个让我挺头疼的项目公司里陆陆续续上了五个 AI 产品有聊天助手、文档协作、数据分析、流程自动化、知识库问答都是一线团队各自选型后跑起来的。表面上看各司其职实际上问题很多。每个产品都有独立的登录入口、独立的配置后台、独立的会话记录甚至各自维护一套私有的工具配置。部门里跑一次跨产品的任务往往要手动复制粘贴上下文运维那边更是要维护五套不同的部署环境。后来我们把架构收敛成一套WorkBuddy 企业版核心思路就是标题里写的这八个字一个Agent 底座统管五个产品走套件化路线。这篇文章把我这几个月从拆需求、设计底座、迁移产品到踩坑填坑的完整过程记录下来希望能帮到正在纠结要不要做统一 Agent 平台的人。1. 五个产品各自为战的日子到底卡在哪儿先说结论企业里真正阻碍 AI 落地效率的往往不是模型能力而是产品之间的割裂。1.1 账号、上下文、权限三座大山五个产品五套账号体系。员工入职以后要开五个账号IT 要维护五份权限清单。这不只是麻烦是实打实的安全隐患——离职员工常出现这个产品销了那个没销的情况。上下文割裂更致命。用户在文档助手里的分析结论没法直接带到聊天助手继续追问知识库问答明明有答案数据分析产品却不知道这个背景。本来一套完整工作流被拆成五段孤岛。1.2 每个产品都在重复造底座轮子这个最让我心疼。五个产品虽然是不同团队选型但底层要做的事高度重合都有对话编排都要接大模型 API都要配置工具集都要管会话历史都要做敏感信息过滤。等于把 AI 应用最核心的地基重复盖了五遍。五份代码要各自升级、各自修 bug、各自适配新模型。版本都不统一更别说共用一套企业知识库。1.3 套件化要解决的不是功能合并这里要澄清一个误区套件化不是把五个产品塞进同一个壳子里当菜单项。真正的套件化是把五个产品的差异化能力留在上层把共性能力下沉到同一个 Agent 底座。听起来简单做起来难。因为下沉共性能力意味着要找到一个既能服务所有产品、又不被某个产品绑架的抽象层。这也是后面所有设计的出发点。2. 底座层的核心模块拆解一张图看懂五层能力我们把 WorkBuddy 底座拆成五层每一层的设计决策都来自一个朴素的问题这层能力是五个产品都需要的吗如果是就下沉如果不是就上浮到产品层。2.1 底座五层框架一览底座分层核心职责服务范围Agent 运行时调度 Skill、管理执行循环、处理模型调用五个产品共用一套运行时编排引擎将用户意图拆解为多步任务支持分支与回溯跨产品共同编排统一记忆层短期会话记忆、长期企业记忆、产品私有记忆共享知识 产品隔离Skill 注册中心工具的注册、鉴权、冲突消解、版本管理全局 产品命名空间安全审计与权限RBAC 鉴权、输入输出过滤、全链路审计日志底座统一收口2.2 Agent 运行时为什么它是底座而不是工具库很多人会觉得统一底座不就是封装一个 SDK 给五个产品调用吗我一开始也是这么想的后来被现实教育了。SDK 只解决代码复用管不了执行过程的统一。举个例子文档助手发起一个分析本周销售数据并生成摘要的任务实际上要经过取数 → 清洗 → 分析 → 生成摘要 → 摘要回填到文档 → 记录到企业知识库 这么一串动作。在没有统一运行时之前每一步都可能由不同产品各自实现出错之后你根本不知道在哪一环断的。统一运行时把执行一个完整任务变成底座的原生能力产品只需要描述任务的最终目标底座负责编排调用序列、记录中间状态、失败重试、上下文回溯。这才叫底座。2.3 统一记忆层企业记忆和产品记忆的边界记忆层是套件化里面最容易扯皮的部分。我们的做法是分三类存的全局记忆企业公开知识所有产品都可以调用、协作记忆用户在某条工作流里跨产品产生的上下文、产品私有记忆比如数据分析产品自己的查询偏好不该被聊天助手看到。记忆隔离这件事做不好后果很严重。一个产品把另一个产品的中间状态当成了自己的输入生成的结果会莫名其妙。后面第 3 节我会专门展开讲这个。2.4 为什么编排引擎必须放在底座里五条业务线各自都需要多步任务编排但诉求不完全一样数据分析偏重步骤的回溯修正流程自动化偏重条件分支文档协作偏重多人协同状态同步。如果每家自己实现一套编排等于重新发明五遍轮子。我们统一在底座里做了一套基于 DAG 的编排模型产品层通过声明式配置来描述自己的流程结构具体的调度、并发、异常重试都由底座承担。约定流程结构不约定流程内容这句话是我们设计编排引擎的准则。3. 套件化最难的其实是共用但不互相污染架构上的五层能力看着清晰真正让团队掉了不少头发的是下面这个问题五个产品同一个底座怎么保证它们的 Skill 不打架、记忆不串味、权限不越界3.1 产品命名空间与 Skill 冲突消解五个产品各自有工具集。比如聊天助手有一个web_search的 Skill数据分析产品也有一个同名但功能侧重点不同的 Skill。底座的做法是引入命名空间机制每个产品注册的 Skill 都自动带上产品前缀如data_analysis.web_search默认只在自己的命名空间内可见。如果某个 Skill 需要被其他产品复用必须显式声明为共享 Skill并经过管理员审核。这一步光靠约定不够底座里还得有冲突检测器。每次注册 Skill 时检查同名冲突触发冲突后不是简单拒绝而是给产品方返回一个建议改名的映射表避免产品之间的私货互相覆盖。3.2 记忆隔离策略哪些共享、哪些隔离我们踩过最大的坑就是记忆串味。上线第一周用户发现在聊天助手问了一句最近财务审批流程好慢转头去数据分析产品里查数据生成的分析报告开头居然带上了这句吐槽——因为共用了底层记忆。之后我们强制定了三条规则产品私有记忆默认隔离跨产品读取必须显式声明并经过用户授权全局记忆只收录企业级沉淀内容制度、知识库、公开指标口径不允许存临时会话协作记忆按工作流场景作用域绑定工作流结束以后自动归档为只读3.3 上下文路由与阻断机制共用底座还有一个隐蔽问题上下文上下文会膨胀。五个产品如果都往同一个上下文里塞内容一次任务 token 消耗会爆炸甚至突破上下文窗口。我们设计了一套上下文路由机制底座会根据当前任务的类型只把相关产品命名空间里的上下文片段注入模型其余片段仅在需要时通过检索方式临时加载。效果是单次任务的 token 消耗下降了大约 40%而且各产品之间的上下文不再纠缠。3.4 模型路由不同产品用不同参数套件化的另一个好处是模型策略可以统一管理。底座支持按产品配置模型路由数据分析产品默认走更强的推理模型聊天助手走低延迟模型知识库问答走检索增强链路。产品层不需要关心模型细节底座统一按配额调度。提示模型路由一定不要做成写在产品代码里的硬编码而是底座配置中心的运行时配置。不然每次调模型参数都要改代码重新发版等于回到各自为战的老路。4. 从单产品 Agent 到套件化底座迁移路径与部署实践架构设计是一回事把现有五个产品平稳迁过来是另一回事。这一章节聊聊我们实际操作下来的迁移步骤全部基于这次真实重整过程的复盘。4.1 迁移前的资产盘点与干净层抽象动工之前不要急着写代码。先做一次彻底盘点每个产品有哪些 Skill、用了哪些模型接口、依赖哪些私有数据、对外暴露哪些 API。盘点的目的是搞清楚哪些是产品真正的差异化价值哪些只是基础能力。我们当时梳理出来五个产品里有三个的对话历史存储几乎是一样的这种就是典型的、应该下沉到底座的部分。下沉之前先把底座需要的接口定义清楚再让产品改造成适配这些接口比我预想的需要更多沟通成本因为每个产品团队都觉得自己的实现是最好的。4.2 分阶段切换别搞大爆炸迁移刚开始有同事提议选一个周末全部切换被我否了。套件化迁移牵扯到数据迁移、权限重新分配、第三方系统对接一次性切换风险太高。我们分为四个阶段第一阶段底座上线承载聊天助手产品其余产品仍独立运行第二阶段知识库问答与文档助手接入底座开始验证跨产品上下文流转第三阶段数据分析和流程自动化接入启用统一编排与记忆层第四阶段清理旧系统的独立部署环境账号与配置全面收敛每阶段跑两周观察期重点看任务成功率、token 成本变化、用户反馈。4.3 部署运维的实操细节套件化之后运维对象从五个应用变成一个底座 五个扩展包部署方式变了但很多细节坑只有实际操作才知道。依赖管理要特别注意版本锁定。产品扩展包和底座之间的接口要定版本号升级底座前先跑兼容性测试。缓存目录这种小问题也得统一规划。之前每个产品各写各的缓存路径统一之后我们把缓存统一收到底座管理的目录下并且支持通过配置中心动态调整避免某个产品的缓存把磁盘占满影响其他产品。日志和监控要从单产品视角升级为全链路视角。同一个任务跨了三个产品任何一环出问题都要能在统一 trace 里看到。我们引入了一个简单的 trace ID 贯穿整条链路排查效率提升非常明显。4.4 关于运行时语言选型的一点务实话我们底座的运行时最终选择了偏底层的高性能语言体系来实现关键路径部分通用业务逻辑还是用团队更熟悉的技术栈。理由很简单底座要承载五个产品的并发请求关键路径上对资源占用和调度效率有硬要求。但对大部分团队来说没必要为了赶时髦把所有代码都用底层语言重写。底座的稳定性和可维护性远比性能数字好看重要。选型先看团队能不能长期维护再看性能。5. 企业版落地最容易翻车的三个隐性成本套件化解决了架构问题但它同时放大了三类容易被忽视的成本。这些坑如果不提前处理上线以后每天都要被反复折磨。5.1 权限模型从按产品授权到按能力授权之前五个产品各自有权限体系无非是谁能用这个产品。套件化之后底座能调用跨产品的能力这时候如果权限还是按产品划分会出现严重越权普通员工在生产工具里无意触发了数据分析产品的取数接口某个产品被封禁了但共享的全局 Skill 依然可以让用户绕过限制我们最终把权限拆成两层组织级 RBAC决定谁能用哪个产品和能力级 RBAC决定某个角色在某个产品里能调用哪些 Skill。能力级权限在底座统一收口任何跨产品调用都要经过二次鉴权。注意不要只在产品层做能力级鉴权。因为产品可能被绕过——用户在聊天助手里触发的任务链路里可能间接调用了数据分析的 Skill如果不走底座统一鉴权这就是一个巨大的权限漏洞。5.2 Token 成本共用上下文的放大器效应统一底座会让 Token 消耗模式发生变化。最典型的问题是全局记忆和跨产品上下文在每次任务里都可能被重复注入如果只按对话轮数估算成本月底账单会吓到你。我们上线后成本比预估高出约 28%排查下来有三方面原因全局记忆被无差别注入所有产品任务浪费了大量 token上下文中断后重试导致重复计费产品命名空间内积累了过多无用历史片段后来靠上下文路由前面提到的那套机制加上按产品维度的 Token 配额限制才把成本压回正常区间。做套件化的预算模型时一定要按底座统一注入 产品按需注入两种模式分开算不要按老单品的计费逻辑去估。5.3 安全审计跨产品 Chain 的可追踪性套件化之后一次用户请求可能经过聊天助手发起 → 知识库取数 → 数据分析计算 → 文档助手成稿四段链路。如果每一段的日志都各自记录真正出了安全事件复盘会变成一场灾难。我们的方案是底座强制一条审计规则一次用户请求生成一个 trace ID所有产品与 Skill 的调用记录都必须携带这个 ID。无论跨了多少个产品一条 Audit 记录就能还原整条链路里每一个决策点。同时输入输出的敏感信息过滤也统一下沉到底座。之前做敏感词过滤各做各的有些产品漏掉了文件内容里的身份证号一类信息统一之后才把这个口子堵住。5.4 遇见委派冲突时先别急着改代码最后分享一个印象深刻的排查过程。上线三周后流程自动化产品老是异常终止报错信息指向一个很隐蔽的现象两个产品的 Skill 同时声明了读当前日期能力编排引擎在选择调用哪个 Skill 时出现了歧义导致流程在无提示的情况下反复尝试。排查链路不复杂但暴露了一个关键问题同一底座上 Skill 命名与能力描述如果没有强制规范编排引擎真的会乱点鸳鸯谱。修复手段也不难强制要求每个 Skill 注册时必须写清楚能力边界描述底座再配合命名空间机制做一轮去重。这套规范现在被写进了我们所有接入产品的开发文档里。6. 最后交代几句大实话整个套件化项目走下来我个人最深的体会是把五个产品收敛到一个 Agent 底座技术上的难点始终不是写代码本身而是界定边界——哪些能力必须下沉哪些能力必须隔离哪些权限必须在底座收口这些决策每天都在和产品团队来回拉扯。如果让我重新做一次我会把三件事前置第一先做细致的资产盘点宁可多花两周也别急着写代码第二产品之间的边界规则在第一周就定下来不要等上线被问题逼着补第三给每个接入底座的团队配一份《Skill 与命名空间开发规范》越细越好。另外再分享一个小技巧底座建设别贪大。我们最开始规划了二十多个通用模块后来砍到了五层能力才真正跑起来。Agent 底座的本质是让多个产品在同一个执行语义下协作不是把所有 AI 能力统统装进一个平台里——把握好这个分寸套件化才不会变成一个新的单体巨石。