★ FEATURED ARTICLE 1. 为什么我会把五个产品硬塞进同一个 Agent 底座先交代一下背景。我们团队本来有五个各自为战的产品内部的知识库问答助手、工单自动分类机器人、代码评审辅助工具、销售线索初筛系统还有一个给管理层看的周报自动汇总器。这五个东西听起来毫不相干但它们有个共同的痛点——每一个都长着 AI 的影子每一个都需要自己维护一套模型调用接入、一套提示词管理、一套记忆存储甚至各自有独立的上线部署流程。痛点最直观的表现是需求方说要“给问答助手加一个根据历史工单推荐解决方案的能力”按理说只需要复用销售线索系统里已经做好的语义检索模块结果实际做起来要把工单数据重新灌一遍把向量库单独部署一套再写一层权限控制。五个产品用了三套不同的向量数据库、两套不同的模型接口封装维护成本高得离谱。于是“WorkBuddy 企业版套件化”这个思路就顺理成章了不再做五个独立应用而是做一个统一的 Agent 底座把五个产品全部变成底座上的插件或者工作流实例。简单说底座管连接、管调度、管记忆、管权限产品只负责定义自己的技能和剧本。这里要先澄清一个容易混淆的概念Agent 本身不是一个产品形态而是一种执行模式。你问我“帮我查一下工单状态”我不只是调一个 API 返回结果而是会先理解意图再决定调用哪个工具、是否需要追问、拿到结果后如何组织答案。WorkBuddy 这个底座就是把这套“理解-规划-行动-记忆”的循环做成了公共设施五个产品全跑在这套循环之上。2. 底座设计的第一步先给五个产品划定边界套件化最容易踩的坑就是想着把五个产品的功能全塞进一个 Agent 里做一个“超级助手”。那个方向必死因为上下文长度有限工具一多模型就懵维护提示词的人也崩溃。我给整个套件定下的原则是底座只管通用能力产品只保留特有逻辑。具体分三层来看2.1 基础层的通用能力归底座底座负责这些事模型接入与路由不同任务用不同模型底座统一管理 API Key、模型版本、超时和重试多轮会话记忆包括短期记忆当前对话上下文和长期记忆用户偏好、历史结论工具注册与调度每个产品把自己的能力注册成工具底座统一决定调用顺序权限校验什么角色能用什么工具什么数据能看到什么字段可观测性所有 Agent 决策过程留痕方便回溯这层的核心价值是“写一遍处处用”。像权限校验这种模块五个产品都要用自己写得话每个产品一套逻辑还不够还得花钱请安全团队review五遍放到底座里只需要审计一次。2.2 产品层的技能和剧本归产品产品团队的职责变成两件事一是写技能Skill。技能是最小的能力单元比如“查询订单状态”“生成工单摘要”“提取销售线索中的关键字段”。每个技能包含工具的调用方式、输入输出的数据结构、以及一段针对性的提示词。二是编排剧本Workflow。剧本把技能串起来定义什么条件下先做A再做B什么情况下需要向用户追问。销售线索初筛系统本身就是一个剧本先调用“提取线索”技能再调用“企业画像查询”技能最后调用“评分排序”技能。2.3 连接器的边界不要把所有东西都做成 Agent有些需求天然不需要 Agent 的推理能力。比如工单自动分类它就是“读标题读描述输出分类标签”用固定提示词的一次调用就能搞定。如果非要把这种任务包装成 Agent不仅响应变慢还容易出现幻觉式的分类错误。所以套件化的边界策略是简单的任务用固定的 Skill 直连复杂的任务才编排成 Agent 工作流。底座需要同时支持这两种执行模式而不是一刀切地全走 Agent 路线。我在设计初版时犯过这个错误把工单分类也做成多步推理结果延迟从300ms涨到2s准确率反而下降了两个点。打个比方办公室里有订水服务你给前台打电话说“订两桶水”前台直接记下来就行不需要跟你确认三遍。如果你说“以后每周三上午帮我订两桶水顺便统计一下这季度水费”这时才需要判断、记忆、定期执行才轮到 Agent 出场。3. 底座的核心模块拆分五个产品共享的三个关键机制方案定了接下来是具体怎么落地。WorkBuddy 底座我拆成了三个关键机制工具调用机制、记忆机制、权限机制。这三个机制是五个产品都要跑的基础设施也是最容易出问题的部分。3.1 工具调用机制让模型学会“什么时候用什么”底座里维护了一张工具注册表每个技能就是一个工具。注册表里写清楚工具的名称和描述给模型看的要能准确描述工具的用途入参 Schema给模型看的定义需要哪些参数以及参数的格式执行端点给系统看的定义调用哪个内部服务模型每次需要调用工具时会根据当前对话内容从工具列表中选择最合适的那个生成符合 Schema 的调用参数。这个机制本身不复杂复杂的是工具一多模型容易选错。我有一次实测底座里注册了 20 个工具模型在回答“最近一周销售线索趋势”这种问题时错误调用了“查询历史工单”工具给出的回答看起来头头是道其实数据源完全不对。后来给工具描述加了明确的触发条件边界比如“本工具仅用于销售线索相关查询不适用于工单数据”错误率才降下来。所以在设计底座时要给工具描述留足空间不要惜字如金。一个好的工具描述像给新同事的交接文档说清楚自己负责什么也顺便说清楚自己不负责什么。3.2 记忆机制短期记忆和长期记忆分开存记忆分两层短期记忆是当前对话的上下文缓存存在 Redis 里每个会话一条超时自动清理。这层逻辑简单但要注意上下文长度限制。模型能处理的 token 数有限不可能把十轮对话全塞进去所以要设计摘要策略——早期的对话压缩成摘要近期的对话保留全文。长期记忆则存用户的结构化偏好和事实结论放在正式数据库里。比如销售线索系统使用过一段时间后Agent 记住某个客户所在的行业是“医疗”下次讨论到这个客户的线索时候Agent 会主动过滤掉明显不适合医疗行业的方案。长期记忆最大的坑是“记忆污染”一个用户在某次会话中随口说“我们公司最近不考虑华东区的客户”长期记忆就会把它存成一个绝对规则导致后续所有分析都避开华东区即使这个说法早就过时了。我的解决办法是分两类记忆一类是用户显式标注的偏好长期保存另一类是从对话中自动提取的结论只保留一定时效过了时限自动移除。3.3 权限机制Agent 能跑的每一个动作都要过校验五个产品共享一个底座权限模型必须精细化到什么程度答案是每个工具调用都要校验。用户可能只有“查看自己名下工单”的权限那 Agent 在调用“查询工单状态”时入参里的工单号就必须校验归属而不是等工具内部服务自己去判断。这个设计在最初被产品经理质疑过觉得绕了一圈多此一举。直到有一次测试发现代码评审辅助工具在处理一个跨团队评审请求时正确调用了评审历史接口但因为权限校验在校验 Agent 身份而非真实用户身份一个普通开发者的请求查到了另一个团队的核心代码评审意见。这个问题如果不暴露上线后就是安全事故。我把权限校验设计成两层一层在工具调度层校验用户是否有权调用这个工具另一层在工具执行层把用户身份透传到内部服务让数据查询天然按用户权限过滤。4. 实战把五个产品迁移到统一底座上的完整过程前面都是设计原则这里讲一下实际迁移的步骤。我按五个产品的共性把它们分成三批迁移避免一次性切换的爆炸半径过大。4.1 第一批工单自动分类系统和知识库问答助手这两个产品是最典型的“重工具调用”场景迁移成本最低也最适合用来验证底座的基础能力。工单分类系统的迁移步骤是把原来的固定提示词封装成一个 Skill输入是工单标题和描述输出是分类标签置信度。底座注册这个 Skill 后工单分类的调用链从“产品直接调模型”变成了“产品调底座底座识别意图后调 Skill”。这个改动看起来多了一层但获得了原来没有的收益模型调用记录被完整留存每次分类都能追到用了什么模型、什么参数、什么提示词版本。知识库问答助手迁移时多了一个记忆需求。原来的问答助手每次都是无状态调用用户问完就忘。迁移到底座后加入了短期记忆——用户在多轮对话中说“我之前问过报销流程”Agent 能从上下文里找到之前谈论的报销细节不用重新问一遍。实测一个体验上的变化迁移前用户问“上次说的报销流程再发我一下”助手只能回“我没有历史记录请重新描述需求”迁移后助手能准确调取上次会话中生成的操作步骤概述直接展示给用户。这个能力在日常使用中的好评度很高。4.2 第二批销售线索初筛系统销售线索初筛系统是五个产品中最依赖多步推理的它天然适合 Agent 工作流。这个产品原来的逻辑是三步走第一步从表单里提取线索的关键字段公司名、联系人、需求描述第二步查企业公开信息做扩充行业、规模、地区第三步基于这些综合信息给出评分和初步跟进建议。迁移到底座后这三步变成了一个 Skill 链线索提取 Skill - 企业画像 Skill - 评分 Skill。每步的输出作为下一步的输入任何一个节点失败底座会自动组织一次重试或者向用户询问缺失信息。这里重点说一下编排的注意点Skill 链里每个技能都要定义清晰的输出 Schema下游技能才能可靠地拿到上游结果。如果你上游技能输出的字段名和下游技能输入 Schema 的字段名对不上整个链路就会静默失败——Agent 以为自己调成功了实际拿到的是空值最后给你一句“分析已完成”但没有具体结果。调试这种问题时底座的日志审计功能帮了大忙。每一次工具调用的入参、出参、耗时、token 消耗全都有记录。顺着日志往前翻很快就能定位到是哪个技能的输出格式没对上。4.3 第三批代码评审辅助工具和周报自动汇总器这两个产品迁移时最大的挑战是外部系统集成。代码评审工具需要对接代码托管平台的 API周报汇总器需要对接多个内部数据源的导出权限。代码评审工具的集成思路是把对代码托管平台的查询操作封装成工具但不在底座内直接存平台 token而是通过底座的凭据管理模块统一读取。这样至少有两个好处第一代码平台的 token 不会散落各服务的环境变量里被谁拿走都不知道第二token 轮换只需要在底座里做一次不需要每个产品单独修改配置。周报汇总器相对简单它本质是一个定时任务式的 Agent每周五下午拉取这一周的工单数据、代码提交记录、项目进展文档汇总成一篇结构化周报草稿。底座给它的能力是定期触发和执行编排并且在生成草稿后交给用户确认和修改而不是直接发布。这里有个细节值得展开定时任务的执行环境。周报汇总器需要拉取数据源 A、B、C任何一个数据源临时不可用整个任务就失败。原来的实现是失败了就报错等下次触发。迁移到底座后我给汇总器增加了重试等待机制单个数据源失败自动延迟 30 秒重试最多三次。数据源恢复后任务自动继续不会因为一次性故障就错过整周的周报。4.4 迁移过程中的数据与配置迁移清单整个迁移过程我用一张表规划数据与配置迁移项原来分散在哪底座统一后放在哪注意事项模型 API Key每个产品各自的配置中心底座凭据管理模块迁移后立即在旧配置中删除 Key防止残留向量库连接串知识库、销售线索系统各自一套底座公共存储配置先跑一段时间双写确认一致后再切换提示词版本各产品代码仓库里散落的文件底座提示词管理模块带版本号每次改动提示词要在底座留版本记录用户与角色各产品独立账号体系底座的统一身份映射表先做账号映射再逐步收敛登录入口工具访问权限各产品在代码里硬编码底座的权限策略表逐条校验避免把“某产品管理员”直接映射为“底座管理员”这个清单是血泪教训换来的。最初迁移代码评审辅助工具时我只迁移了模型调用忘了同步工具访问权限结果评审工具的用户在底座上拥有超出预期的工具调用权限。还好发现得早不然数据越权问题是迟早的事。5. Skill 怎么写才够“底座友好”五个产品迁移完成后新的需求是持续新增技能追加到底座上。这时候你会发现技能写得好不好直接决定底座的稳定性和可维护性。技能写得很差底座的调度层再强也白搭。5.1 技能的最小可用结构一个标准技能长这样name: query_order_status description: 查询订单当前状态。仅当用户询问订单物流、签收、延迟等问题时使用。 如果用户询问的是工单状态请使用 query_ticket_status。 parameters: order_id: type: string description: 订单号必须为完整订单号不可从用户描述中推断 include_history: type: boolean description: 是否需要展示近30天状态变更记录 execute: endpoint: http://internal-order-service/v1/query method: POST实际写技能时最重要的反而不是代码逻辑是 description 里那句“和别的工具的区别”。模型选错工具八成原因是两个工具的 description 写得含糊边界重叠。我维护的底座现在有 30 多个工具每个工具 description 里必须有明确的“不要误用于”提示。5.2 技能版本管理与灰度发布技能上线也不是改完配置就完事。我给每个技能设计了版本号新版本发布时先在底座里标记为“候选版”只对内部测试用户路由稳定后再切为“稳定版”全量路由。切换方式是在底座的工具路由表里按技能版本加权重。这套机制应对的场景很具体销售线索评分技能换了新提示词理论上应该提高准确性但你不想让它一上线就影响全量销售团队的日常使用。灰度跑三天对比候选版和稳定版的平均置信度、用户驳回率确认没问题再全量。整个过程不用改代码在底座的管理端操作配置表即可。5.3 技能调试的常用手法调试技能时的最大痛点是不知道模型为什么调用失败。我的经验是抓住三个层面查第一层模型有没有正确选择技能。查底座日志中“意图识别”一栏看模型最终选了什么工具、备选工具有哪些。第二层入参有没有正确生成。模型选对了工具但参数生成错了常见于模型把“订单号”理解成“工单号”。这种情况需要在参数描述里加限定词和格式示例甚至提供 few-shot 示例。第三层执行结果有没有被正确解析。这看起来是服务端问题但实际经常是输出 Schema 定义得太宽泛模型拿到结果不知道如何取舍信息做回答。这三个层面按顺序排查90% 的技能故障都能定位剩下的可能是模型本身上下文遗漏可以归入需要优化长期记忆的范畴。6. 五个产品共用一个底座后的真实收益与成本很多团队会把“统一底座”理解成一味省钱实际上底座有自己的维护成本。我按三个维度整理了实测后的收益和成本方便大家做决策参考。6.1 实打实的收益模型调用成本明显下降这是最直观的。原来五个产品各自调各自的模型谁也不会用别的产品的缓存。底座统一后同样的单轮对话如果命中了缓存比如两个销售同时查同一个客户的画像摘要第二次调用就不走模型直接返回缓存结果。我跑了一个月的统计模型调用总量减少了约三成。研发效率的收益也很大。新需求如果只涉及“底座的已有技能换个编排顺序”开发周期从原来的按周计变成现在的按天计。举例管理层临时要看“各销售区域的周转化对比”原来需要数据组跑数一周现在底座上销售数据查询技能和周报汇总技能早就有了编排一个新的临时工作流当天下午就能跑出结果。运营侧的收益是故障排查效率提升。五个产品共用一套日志审计系统后出了任何问题先从底座日志看全链路不用再从五个系统的日志里拼凑完整故事。曾经一次知识库助手回答质量突然下降的排查从原来的至少半天压缩到两个小时。6.2 不能忽视的成本底座本身的维护也需要有人盯技能描述更新、上下文缓存清理、权限策略表定期复核、模型版本升级后的回归测试。这些工作不是一次性的是持续性的。我的经验是这个工作量大概需要每周投 4~8 小时对于小团队来说是一笔没法忽略的隐性成本。还有一个成本容易被忽略底座本身成了单点故障。原来五个产品各自独立一个挂了其他照常用。现在底座一旦出问题五个产品同时不可用。为了缓这个问题我至少在底座层面做了主备切换和降级预案比如底座挂掉时最核心的两个产品可以暂时绕过底座直连模型保证比如工单分类和知识库问答这种基础服务不中断。6.3 人员协作方式的变化套件化之后研发团队从按产品划分变成了按底座和技能划分。原有的“知识库组”“销售系统组”边界打破大家围绕“底座的稳定性”和“某几个技能的迭代”重新分组。这个变化初期会有阵痛。原来各产品组只管自己的需求现在都要理解底座的调度逻辑不然写出的技能在接入时会被底座的路由策略拦一道。我的做法是给每名研发做一次底座的使用培训重点讲清楚工具注册表的作用、权限策略表的规则、以及日志审计字段的含义。内容不多实操半天就能掌握。7. 套件化落地过程中的关键岔路与我的选择逻辑最后一个部分讲几个做选择的关键时刻。每个岔路都代表一种设计哲学也埋着不同的坑。7.1 岔路一底座到底是“代码框架”还是“可视化编排平台”这是个原则性选择。做代码框架意味着研发都要在代码里写技能注册、写工作流配置灵活度最高但业务人员完全没法参与。做可视化编排平台则意味着给产品经理和运营一套拖拽界面让他们自己配置技能和流程灵活度相对受限但解放了研发的重复劳动。我最后选择的是代码框架为主但技能配置面向运维开放。原因是团队规模有限没有专人维护可视化编排前端与其做一个复杂笨重的低代码前端不如把技能配置做成 YAML 文件提交进仓库配合底座的 Web 管理端查看运行状态。如果你团队有大几号人的前端配置开发投入可视化编排是长期更优的选择。但如果只是小团队自用基于代码和配置文件的方式性价比明显更高也更利于版本管理。7.2 岔路二要不要让五个产品共享同一个模型我的答案是能不共享就不共享至少不能让五个产品无条件依赖同一个模型。不同产品的任务难度差异很大工单分类和复杂销售战略分析显然不该用同一个模型。共享的是模型接入通道不是模型本身。底座在模型路由上做了分层简单分类任务走轻量快速模型复杂推理任务走强推理模型多模态任务单独走视觉理解模型。底座统一管理这些路由规则各产品只需声明自己的任务类型不需要关心底层是哪个模型。7.3 岔路三升级底座的节奏怎么把握底座升级最大的风险是影响正在跑的工作流。我的节奏是“错峰灰度”工作日只做非破坏性升级比如加技能、调指标结构性升级改调度算法、改权限模型放在周末窗口并且先在一个测试产品上完整走一遍回归验证再切到另外四个产品。别嫌这个节奏慢。我经历过一次在周中直接改底座调度逻辑的情况引发的连锁反应是销售线索系统突然不走评分 Skill直接给用户返回了原始线索数据。用户问“为什么这个客户评分没出来”排查了四个小时才发现是新版调度逻辑里一个规则的优先级写反了。自那以后底座任何结构性改动都不再走“快速上线”路线。最后再说两句实操层面的提醒WorkBuddy 企业版套件化做的这件事本质是把五个产品的共性抽出来让差异下沉为技能和编排。它不是说做就能做成的关键在于第一步能不能把边界划清楚底座和产品各管什么哪些能力必须统一哪些能力必须保留独立。边界划对了后面迁移和迭代都会顺边界划错了底座会变成一个新的集成障碍反而拖累五个产品原有的效率。我自己踩过的最深的坑是急着把五个产品的需求全往底座上放想着底座功能越全越好。现在回头看底座的定位更像插座不是电器。插座只负责提供标准化的供电接口至于连上去的是电饭煲还是电脑那是产品自己的事。如果你也在做类似的套件化改造建议从最没有争议的那个产品开始先跑通底座的完整链路再逐步把其他产品迁进来。不要一开始就追求大而全把底座做成“什么都能干但每件事都要别人喂需求”的巨兽。迁移过程中的每个选择都值得你针对自己的业务和团队情况反复权衡因为我上面列出的收益和成本在不同团队规模下差异很大。
阅读完成 · 觉得有帮助？
