很多团队将智能体上线视为终点，但用户不会按测试题提问。本文以课程咨询助手为例，复盘其从知识问答工具到持续运营服务的转变，揭示智能体产品设计的关键：任务分类、知识治理、只读连接与持续迭代。

很多团队第一次做智能体，会把“正式上线”视为项目终点。

资料已经导入，常见问题可以回答，聊天入口也能够正常访问。客户测试几个问题后觉得效果不错，项目似乎就完成了。

但智能体和传统静态页面不同。课程会调整，服务流程会变化，用户还会提出测试阶段没有考虑过的问题。

如果上线后没有持续维护，再聪明的模型也会逐渐变得“不懂业务”。

下面以一个课程咨询助手为例，复盘它从知识问答工具转变为持续运营服务的过程。

本文案例由常见智能体项目问题合并整理，不对应具体客户，也不使用虚构的效果数据。

一、第一版产品：把常见问题交给AI

一家培训服务团队平时需要回答大量重复问题：

• 课程适合哪些人；
• 什么时间开课；
• 如何报名；
• 学习资料在哪里领取；
• 报名后如何进入学员群；
• 课程结束后是否提供回放。

团队希望通过AI助手分担基础咨询，让课程顾问把时间留给复杂需求和重点客户。

第一版产品并不复杂。

团队整理了课程介绍、报名流程和常见问题，将资料导入知识库，再配置一个课程咨询智能体。

上线前准备的标准问题都能正常回答。产品团队于是把验收标准定为：

• 能回答主要课程问题；
• 输出表达自然；
• 用户能够随时咨询；
• 无法回答时提示联系工作人员。

从功能角度看，这个版本已经可用。

真正面向用户后，问题却开始出现。

二、用户不会按照测试题提问

第一类问题是知识已经变化。

课程时间从周末调整到工作日晚间，但知识库中仍然保留着旧通知。用户询问开课时间时，智能体有时引用新安排，有时又检索到旧资料。

第二类问题是用户需要实时状态，而不是知识答案。

有人问：

我昨天已经报名了，现在审核到哪一步？

智能体没有连接报名系统，只能重新介绍报名流程。

回答本身没有明显错误，却没有解决用户的问题。

第三类问题是输入形式超出了预期。

用户发来报名材料截图，询问是否符合要求。第一版产品只能处理文字，无法读取图片内容，于是给出一段通用材料说明。

第四类问题是服务需要上下文。

用户说：

我上次已经跟课程顾问沟通过了，为什么还要重新说明一遍？

智能体没有经过授权的客户服务上下文，也没有明确的记忆策略，无法理解用户之前的沟通状态。

这些问题暴露出一个关键事实：

第一版产品解决的是“回答预设问题”，用户需要的却是“完成一次服务”。

三、第一次迭代：不要把所有需求都当成问答

产品团队重新整理真实对话后，把课程咨询拆成四类任务。

1. 课程知识

包括课程内容、适合人群、授课方式和学习资料。

这类问题可以通过知识库回答，但必须带有资料版本和更新时间。

2. 业务状态

包括报名审核、订单状态、开课通知和服务进度。

这类信息不在公共知识中，需要查询报名系统或CRM。

3. 材料处理

包括截图识别、报名材料检查和文件内容提取。

这类任务需要OCR、视觉模型或文件解析Skill。

4. 人工服务

包括退款、投诉、特殊安排和个性化承诺。

这类问题不适合完全自动处理，应转交工作人员，并把已经收集的信息一并传递过去。

任务分类完成后，课程咨询助手的角色也发生了变化。

它不再负责回答所有问题，而是作为统一服务入口，判断用户需要什么，再选择知识库、Skill、MCP工具或人工服务。

四、第二次迭代：重新建设知识库

旧版本把课程介绍、历史通知、报名流程和服务说明全部放在同一个知识库里。

当资料发生变化时，新旧内容容易冲突。

团队将知识库拆成两层。

控制知识库

用于存放稳定规则：

• 哪类问题可以直接回答；
• 哪些信息必须使用最新版本；
• 哪些表述不能出现；
• 什么情况下需要人工确认；
• 哪些问题必须转人工；
• 无法找到依据时如何回复。

证据知识库

用于存放业务材料：

• 当前课程介绍；
• 最新开课安排；
• 报名流程；
• 学员服务说明；
• 经过脱敏的历史问答。

同时，每份资料增加负责人、有效状态和更新时间。

当新安排生效时，旧资料不再参与当前问答，但可以保留为历史记录。

这一步解决的并不是模型问题，而是内容运营问题。

如果企业没有明确谁负责更新知识、什么时间更新、旧版本如何处理，那么智能体出现过期回答只是迟早的事。

五、第三次迭代：连接业务，但先从只读开始

用户查询报名状态时，单靠知识库无法解决。

团队通过只读MCP Server连接报名系统，让智能体在完成必要身份确认后，可以查询：

• 是否已经提交报名；
• 当前审核状态；
• 最近更新时间；
• 下一步需要准备什么。

第一阶段没有开放修改报名信息、调整课程和取消订单等操作。

原因并不是技术做不到，而是这些操作涉及业务责任、用户权益和系统权限。

产品设计采用以下原则：

• 能只读就先只读；
• 查询结果必须带更新时间；
• 接口调用失败时明确提示；
• 不使用估算数据补齐结果；
• 写入操作必须人工确认；
• 每次工具调用保留日志。

对于材料截图，则增加OCR和材料解析Skill。

智能体可以提取截图中的字段，并根据材料清单提示“可能缺少哪些内容”，但不直接给出最终审核结论。

最终审核仍由工作人员完成。

六、上线后的持续运营闭环怎么做？

改造后的课程咨询助手不再采用“上线后等待反馈”的维护方式，而是建立固定闭环。

第一步：看真实使用记录

重点关注：

• 用户最常问什么；
• 哪些问题经常重复追问；
• 哪些回答被用户纠正；
• 哪些任务经常转人工；
• 哪些工具调用容易失败。

第二步：判断问题属于哪一层

回答错误并不一定是模型不够强。

它可能来自：

• 知识库缺少资料；
• 新旧内容冲突；
• Planner路由错误；
• Skill输入格式不匹配；
• MCP接口返回异常；
• 用户没有相应权限；
• Evaluator没有发现无依据结论。

不同原因需要不同处理方式。

第三步：形成修改建议

知识缺失就补充知识库；任务分类不准就调整路由；重复出现的文档处理需求可以沉淀成Skill；需要实时数据的任务再评估是否连接MCP。

涉及线上配置和权限的改动，不由智能体自动完成，而是生成待确认建议。

第四步：加入回归测试

每一个真实失败问题，都可以转化为测试题。

例如：

• 新旧课程时间同时存在时应如何回答；
• 报名系统超时时是否停止查询；
• 用户无权查看他人报名状态时如何处理；
• 材料图片模糊时是否提示重新上传；
• 用户要求退款时是否正确转人工。

模型、知识库、Skill或MCP更新后，先重新运行测试，再决定是否发布新版本。

七、产品指标也要从“回答次数”升级

如果只统计对话数量，团队很容易高估智能体价值。

更值得关注的是四组指标。

任务理解指标

• 用户意图是否识别正确；
• 是否路由到正确能力；
• 同一个问题是否反复询问。

知识与工具指标

• 知识回答是否有来源；
• 资料是否为有效版本；
• MCP调用是否成功；
• 失败时是否正确降级。

服务结果指标

• 用户的问题是否真正解决；
• 哪些场景仍需人工接手；
• 转人工时上下文是否完整；
• 工作人员是否需要重新询问用户。

能力演进指标

• 新需求主要集中在哪些场景；
• 哪些知识需要频繁更新；
• 哪些任务适合封装为Skill；
• 哪些业务系统值得建立只读MCP。

这些数据不仅用于评价当前版本，也决定下一阶段应该建设什么。

八、从一次性交付转向持续服务

课程咨询助手上线后，需要持续处理模型变化、知识更新、工具连接、问题复盘和版本测试。

因此，智能体项目更适合被理解为持续服务，而不是交付一个固定聊天机器人。

持续服务可以包括：

• 模型调用与效果观察；
• 知识库更新和版本治理；
• 高频问题与失败案例复盘；
• Skills和MCP能力扩展；
• 权限、日志和风险检查；
• 测试集维护和版本发布；
• 用户需求与能力缺口分析。

九、这个案例带来的产品启示

课程咨询助手真正的产品升级，并不是换了一个更强模型，而是完成了五个变化：

1. 从回答问题转向完成服务；
2. 从单一聊天流程转向任务路由；
3. 从一次资料导入转向知识运营；
4. 从静态问答转向受控工具连接；
5. 从上线即结束转向持续评估和迭代。

产品经理设计智能体时，也应该先回答五个问题：

• 用户真正要完成什么任务；
• 需要哪些知识、数据和工具；
• 哪些步骤可以自动完成；
• 哪些操作必须人工确认；
• 使用结果如何进入下一轮改进。

智能体能不能长期产生价值，不取决于上线时回答得多漂亮，而取决于业务变化后，它是否仍然可维护、可追踪、可复核，也能随着真实需求持续演进。