当AI助手能流畅回答标准问题时，团队往往误以为产品已可上线。然而用户真实场景中的状态查询、材料审核、进度追踪等复杂需求，才是智能体产品的真正考验。本文以课程咨询助手为例，复盘从“能回答”到“能解决问题”的迭代历程，揭示智能体产品设计的核心逻辑。

做智能体产品时，团队很容易被第一次演示的效果说服。

用户问“课程适合哪些人”，AI很快给出完整介绍；问“怎么报名”，它也能把流程讲清楚。产品经理、业务人员和客户都觉得，这个AI助手基本可以上线了。

但真正让用户使用后，问题才开始出现。

下面以一个课程咨询助手为例，复盘它从“能回答”走向“能解决问题”的产品迭代过程。

这个案例由智能体交付中的常见问题合并整理，不对应某个具体客户，也不使用未经验证的效果数据。

一、第一版看起来不错，实际只解决了标准问答

这家培训服务团队原来主要依靠课程顾问回答用户问题。用户经常咨询课程内容、适合人群、开课时间、报名方式和学习资料。

团队最初的产品目标很简单：把重复问题交给AI，减少顾问的基础咨询工作。

第一版产品也很直接：

• 导入课程介绍和报名流程；
• 配置一个知识问答智能体；
• 在服务入口提供聊天窗口；
• 回答不了的问题提示联系顾问。

演示阶段，团队提前准备的标准问题都能正常回答。

然而，用户的真实问题并没有按照测试题出现。

有人问：“我昨天已经报名了，现在审核到哪一步？”

有人问：“原来安排的周末班改时间了吗？”

还有人发来一张材料截图：“你帮我看看这份证明能不能用？”

更复杂的情况是，用户会说：“我之前已经跟张老师沟通过，你们怎么还在重复问我？”

第一版智能体不是完全回答错误，而是经常答非所问。

用户询问报名状态，它返回报名流程；用户询问最新时间，它引用旧课程资料；用户上传截图，它只能根据文字描述给出泛泛建议。

从模型角度看，它完成了回答；从用户角度看，事情没有解决。

二、第一次复盘：产品目标定义错了

团队最初关注的是“AI回答了多少问题”，但真正应该关注的是“用户的问题解决了多少”。

这是两种完全不同的产品目标。

如果把“返回一段文字”当作成功，智能体只要每次都有输出，数据就会很好看。但如果按照任务完成来衡量，就会发现很多回答没有推动用户进入下一步。

产品经理重新梳理用户旅程后，把咨询需求拆成四类：

1. 课程知识：课程内容、适合人群和学习方式；
2. 实时状态：报名审核、订单和服务进度；
3. 材料处理：截图、文件和报名材料检查；
4. 人工服务：退款、投诉、特殊安排和复杂咨询。

这一步很关键。

过去，所有问题都进入同一个聊天流程；调整后，智能体先判断用户要解决哪类任务，再选择相应的知识、工具或人工服务。

课程知识可以查知识库，实时状态需要查询业务系统，材料问题需要OCR或文件解析能力，涉及退款和个性化承诺的内容则转交人工。

产品不再要求一个智能体包办所有事情，而是让它成为服务入口和任务路由器。

三、第二次迭代：知识库不是上传文件，而是一项产品运营工作

解决任务分类后，团队又遇到了第二个问题：课程资料经常变化。

市场部门发布了新的招生安排，运营人员更新了课程时间，顾问手里还有一份旧版服务说明。如果这些资料同时进入知识库，智能体可能检索到相互冲突的内容。

团队开始重新设计知识体系。

一类是控制知识库，存放稳定规则：

• 什么信息可以直接回答；
• 哪些内容必须引用最新资料；
• 无法确认时如何处理；
• 哪些问题必须转人工；
• 不允许作出哪些承诺。

另一类是证据知识库，存放课程介绍、招生安排、服务说明和历史通知。

同时，团队明确了资料负责人、更新时间和版本状态。旧资料不再与新资料混在同一个有效范围内。

这次调整带来的启发是：知识库不是项目上线前的一次性准备，而是产品内容体系的一部分。

没有明确的更新责任，再强的模型也只能依据过期资料生成更流畅的错误答案。

四、第三次迭代：让AI连接业务，但不要急着开放执行权限

用户查询报名状态时，知识库无法提供实时答案。

产品团队因此增加了只读查询能力，通过MCP Server连接报名系统，让智能体可以在用户身份得到确认后查询当前状态。

这里没有直接开放修改权限。

查询报名进度属于低风险只读操作，可以由智能体辅助完成；修改手机号、取消报名、调整班次等操作则继续保留人工确认。

材料截图则交给OCR和材料解析Skill处理。智能体先提取图片中的信息，再根据材料清单提示用户可能缺少哪些内容。

但输出被定义为“材料准备提示”，不是最终审核结论。正式审核仍由工作人员完成。

这一阶段，产品经理需要关注的不是“能不能连接更多工具”，而是四个问题：

• 用户是否有权调用这个工具；
• 工具可以读取或修改什么；
• 调用失败时如何提示；
• 哪些结果必须由人确认。

智能体接入业务系统以后，产品设计就不再只是对话体验，还包括权限、失败状态、日志和责任边界。

五、评估方式也要从“回答质量”升级为“服务闭环”

经过三轮调整，团队不再只统计对话次数，而是建立了更接近业务的指标体系。

任务理解指标：

• 用户意图是否识别正确；
• 是否被路由到正确的知识、工具或人工服务；
• 同一个问题是否被反复询问。

执行过程指标：

• 知识库是否正确命中；
• 工具调用是否成功；
• 失败时是否进入降级流程；
• 是否出现无依据回答。

业务结果指标：

• 用户是否完成下一步操作；
• 哪些问题仍然需要人工处理；
• 顾问接手时是否已经获得完整上下文；
• 人工需要修改多少AI生成内容。

产品运营指标：

• 哪些问题增长最快；
• 哪些资料经常缺失；
• 哪些能力被频繁请求但尚未建设；
• 哪些智能体功能几乎无人使用。

这些指标的价值，不是证明AI“多聪明”，而是帮助团队决定下一轮应该补知识库、增加Skill、连接MCP，还是重新设计用户流程。

六、从一个AI问答框，变成持续运营的服务产品

复盘这个案例可以发现，真正有效的智能体产品并不是在聊天框里增加更多功能。

更合理的产品结构是：

前台用AI助手承接用户需求，判断任务类型；后台由模型、智能体和数据与能力集合共同完成服务。

其中，数据与能力集合包括知识库、Skills、MCP Server和必要的上下文记忆。

记忆也需要边界。它可以保留用户已经确认的偏好、历史任务和纠错反馈，但不能把每次对话都无差别写入长期记忆，更不能自动修改线上知识和工具配置。

Haoee、dify这类智能体运营平台，更适合智能体创作者、培训咨询团队和AI服务商运营自己的服务入口、客户关系和智能体服务闭环。

对于高校、政府、医院和国企等需要数据不出域、权限审计和复杂系统集成的机构，则应采用私有化AI服务要素平台的建设方式。二者共享智能体工程和能力沉淀思路，但不是同一种交付形态。

七、产品经理真正需要设计的，不是“AI能做什么”

回到最初的问题：为什么AI助手回答得不错，用户还是不用？

因为用户不是来欣赏AI回答的，而是来解决事情的。

产品经理不能只设计一个聊天入口，还需要设计：

• 用户为什么来；
• 系统如何判断任务；
• 需要调用什么知识和工具；
• 失败时怎么办；
• 哪些动作需要人工确认；
• 使用反馈如何进入下一轮迭代。

智能体产品的真正飞轮，不是生成更多回答，而是不断发现没有解决的问题，把这些问题转化为新的知识、Skills、MCP能力和流程改进，再通过评测确认是否真的变好。

当一个AI助手能够准确找到能力、正确路由任务、在风险处停下来，并把每一次失败转化为产品改进依据时，它才从“会聊天的功能”变成了可以持续运营的服务产品。