企业官网建设流程全解析

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 迁移过程中的数据与配置迁移清单

整个迁移过程我用一张表规划数据与配置：

这个清单是血泪教训换来的。最初迁移代码评审辅助工具时，我只迁移了模型调用，忘了同步工具访问权限，结果评审工具的用户在底座上拥有超出预期的工具调用权限。还好发现得早，不然数据越权问题是迟早的事。

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 企业版套件化做的这件事，本质是把五个产品的共性抽出来，让差异下沉为技能和编排。它不是说做就能做成的，关键在于第一步能不能把边界划清楚：底座和产品各管什么，哪些能力必须统一，哪些能力必须保留独立。边界划对了，后面迁移和迭代都会顺；边界划错了，底座会变成一个新的集成障碍，反而拖累五个产品原有的效率。

我自己踩过的最深的坑是急着把五个产品的需求全往底座上放，想着底座功能越全越好。现在回头看，底座的定位更像插座，不是电器。插座只负责提供标准化的供电接口，至于连上去的是电饭煲还是电脑，那是产品自己的事。

如果你也在做类似的套件化改造，建议从最没有争议的那个产品开始，先跑通底座的完整链路，再逐步把其他产品迁进来。不要一开始就追求大而全，把底座做成“什么都能干，但每件事都要别人喂需求”的巨兽。迁移过程中的每个选择，都值得你针对自己的业务和团队情况反复权衡，因为我上面列出的收益和成本，在不同团队规模下差异很大。