最近接手了一个让我挺头疼的项目：公司里陆陆续续上了五个 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 能力统统装进一个平台里——把握好这个分寸，套件化才不会变成一个新的单体巨石。
