用大模型和知识库搭建一个课程咨询Agent并不复杂。

最小版本通常只有三步：

1. 导入课程资料；
2. 配置检索增强生成；
3. 将模型回答发布到Web或其他入口。

在标准测试问题中，这种方案往往表现不错。但进入生产环境后，团队会逐渐遇到知识过期、实时数据缺失、工具调用不稳定和问题无法追踪等情况。

下面以一个常见课程咨询场景为例，拆解Agent从Demo走向生产需要增加哪些能力。

一、Demo架构为什么不够？

基础流程通常是：

用户问题 → 知识库检索 → 大模型生成 → 返回答案

这套流程能够处理“课程适合谁”“如何报名”等静态问题，却无法处理“我的报名审核到哪一步了”这类实时业务问题。

同时，它还存在三个隐患：

• 知识库中出现冲突资料时，模型不知道应该相信哪一份；
• 检索没有命中时，模型可能利用通用知识补全答案；
• 更换模型或提示词后，缺少回归测试来验证效果。

因此，生产版本至少需要对知识、模型、工具和评估进行拆分。

二、把知识库拆成控制层和证据层

控制知识库用于存放：

• 标准回答口径；
• 允许与禁止回答的内容；
• 转人工规则；
• 资料优先级；
• 输出格式和引用要求。

证据知识库用于存放：

• 课程介绍；
• 报名流程；
• 服务手册；
• 售后规则；
• 历史通知。

执行时先读取控制规则，再检索业务证据。如果资料冲突，以控制规则确定处理方式；如果缺少可靠证据，则返回“需要人工确认”，而不是补写答案。

三、为不同任务配置模型路由

课程助手可能遇到多种输入：

• 普通文本问题；
• 长文档；
• 表格；
• 报名材料截图；
• 语音咨询。

这些任务不一定由同一个模型处理。

可以在Planner节点中先判断任务类型，再选择语言模型、OCR、视觉模型或相应Skill。模型版本发生变化后，使用固定测试集重新验证，不要直接替换生产配置。

四、通过MCP连接实时业务系统

查询报名状态时，可以通过MCP Server连接报名系统。

一个完整的工具定义至少要明确：

工具名称：query_enrollment_status
输入：用户身份标识、报名编号
输出：当前状态、更新时间、下一步说明
权限：只读
失败处理：返回人工查询入口
日志：记录调用时间、调用结果和异常信息

一期建议只开放查询类工具。

修改报名资料、取消订单等写操作，应增加人工确认节点，并沿用客户原系统权限，不能因为接入智能体而扩大访问范围。

五、用P/G/E拆分复杂流程

可以把课程咨询Agent改造为：

用户输入
  ↓
Planner：识别意图和权限
  ↓
Generator：检索知识库或调用MCP/Skill
  ↓
Evaluator：检查引用、完整性和风险
  ↓
返回结果或转人工

Planner负责决定走知识问答、系统查询还是人工处理；Generator执行检索和工具调用；Evaluator检查答案是否有来源、是否遗漏信息、是否包含高风险操作。

这种结构比单个超长提示词更容易调试。

六、上线前建立回归测试集

测试问题至少覆盖：

1. 正常知识命中；
2. 同义和模糊表达；
3. 新旧资料冲突；
4. 知识库无答案；
5. 无权限查询；
6. MCP调用超时；
7. 模型返回格式错误；
8. 高风险写操作；
9. 需要转人工的情况。

每次更新模型、知识库、Skill或MCP后，重新运行测试集。

七、发布后形成反馈闭环

上线后需要记录：

• 高频问题；
• 无法回答的问题；
• 用户纠正；
• 工具调用失败；
• 转人工原因；
• 不同版本的效果变化。

这些数据可以用于补充知识库、优化路由、增加Skill或调整评估规则。

好易的智能体创作者和交付团队，支持围绕模型、知识库、Skills、MCP、智能体编排、发布和统计组织项目。具体项目仍需要结合客户数据、接口和权限进行配置。

Agent生产化不是简单增加几个节点，而是让系统具备可维护、可测试、可追踪和可迭代的能力。

Demo的目标是跑通正确路径，生产系统还必须处理错误路径。