目录

• 一、背景与目标

• 二、整体方案与角色拆分

• 三、步骤一：构建知识库并开启自动总结

• 四、步骤二：基于知识库自动生成提示词模板

• 五、步骤三：智能体开发与调试实践

• 六、步骤四：MCP 工具接入与多智能体协作

• 七、评测指标与实际效果

• 八、踩坑与经验总结

一、背景与目标

在实际业务中，我所在的团队需要为教务运营构建一个「课程问答与排课助理」智能体，服务对象是一线课程顾问与学生。传统方案要么是 FAQ 检索，要么是人工整理话术，既无法覆盖复杂场景，也难以持续维护。

本次实践我选择 ModelEngine 作为落地平台，希望在一周左右完成从 0 到 1 的闭环：

• 知识库自动总结生成：自动理解课程大纲、常见问题与政策；
• 提示词自动生成与迭代：减少人工 Prompt 工程成本；
• 智能体开发与调试：可视化查看思考过程、请求链路；
• 多智能体协作：将「课程顾问」和「排课助理」解耦，通过工具与消息协作。

下面是整个过程的拆解与评测。

二、整体方案与角色拆分

我将系统拆成四类核心组件：

• 知识库层：同步 AP/A-Level 课程大纲、价格表、上课规则等文件；
• 智能体层：
  • 「课程顾问智能体」：负责自然语言对话、解释规则；
  • 「排课助理智能体」：负责调用日程系统，生成可行排课方案；
• 工具层（MCP / 内部 API）：如课表查询接口、学员信息接口；
• 观测与评测层：对话日志、覆盖率统计、人工抽查。

ModelEngine 提供了知识库管理、智能体配置、多工具集成和多智能体编排能力，使我可以在一个平台内完成闭环，而不是自己搭一套中间层。

三、步骤一：构建知识库并开启自动总结

第一步是整理知识源。我们准备了几类文档：

• 结构化表格：课程价格、上课时间、班型；
• 半结构化文档：课纲 PDF、教务流程手册；
• 历史对话导出：优秀顾问的经典问答。

在 ModelEngine 中创建知识库时，我重点做了三件事：

• 按业务纬度拆分索引：比如「AP 课程规则」「退费政策」「排课规则」，避免一锅粥；
• 开启自动总结与字段提取：让平台自动从长文档中提炼重点，并以结构化字段存储；
• 定义元数据标签：如年级、科目、校区，方便后续在提示词或路由中使用。

代码示意：

# 创建知识库并生成自动总结
kb = client.knowledge_base.create(
    name="AP_Course_KB",
    files=["ap_syllabus.pdf", "refundable_policy.docx"],
    enable_auto_summary=True,
    metadata_schema={"grade": "string", "subject": "string"}
)

summary = kb.auto_summary()  # 返回每份文档的精炼总结

自动总结的好处是显而易见的：一方面降低了提示词中引用原文的复杂度，另一方面也为后续「提示词自动生成」提供了高质量候选语料。

四、步骤二：基于知识库自动生成提示词模板

传统 Prompt 工程往往依赖个人经验，难以沉淀。ModelEngine 提供了基于知识库内容的提示词自动生成能力，大致思路是：

• 将知识库总结与文档元信息输入到系统；
• 指定「智能体角色」与「目标任务」；
• 自动生成多份不同风格的提示词候选。

我在实践中采用的方式是「机器生成 + 人工微调」：

• 机器负责骨架：包括角色设定、回答风格、引用知识库策略；
• 人工负责业务细节：例如严禁承诺不存在的优惠、回答时必须声明价格随校区波动等。

示例配置：

agent_role: "课程顾问"
goal: "根据 AP 课程知识库，准确回答学生关于课程设置、费用与退费政策的问题"
style: "专业但不过度推销，优先保证信息准确性"
constraints:
  - "不得编造未在知识库中的优惠活动"
  - "涉及费用必须提醒以校区实际报价为准"
use_knowledge_summary: true

自动生成后，我根据实际对话样本微调了几轮，再将最终 Prompt 固化为模板，方便团队其他成员复用。

五、步骤三：智能体开发与调试实践

有了知识库与提示词模板，可以开始搭建智能体对话流程。这里我主要关注三点：

• 对话状态管理：包括用户意图、当前课程上下文、已给出的报价；
• 工具调用时机：例如只有确认学生有意向时才查询具体班级剩余名额；
• 调试与观测：需要清晰地看到每一步的思考过程与工具调用参数。

在 ModelEngine 中配置智能体时，我采用了「对话节点 + 工具节点」结合的模式，并充分利用平台提供的调试功能：

• 在调试面板中逐轮查看：
  • 模型中间思考（如果平台支持可视化 Chain-of-Thought/Reasoning Trace）；
  • 每次知识库检索命中的文档片段；
  • 调用工具时的入参与出参。
• 使用测试用例集回放：
  • 准备 50+ 真实用户问题；
  • 每次改 Prompt 或改工具策略后，一键回放验证。

一个简单的对话处理流程可以抽象为：

def handle_message(message, state):
    intent = detect_intent(message)
    if intent == "ask_course":
        docs = kb.search(message)
        answer = llm.answer_with_context(message, docs, prompt=course_prompt)
    elif intent == "ask_schedule":
        slots = call_schedule_tool(state["student_id"])
        answer = llm.plan_schedule(message, slots)
    else:
        answer = llm.chitchat(message)
    return answer, state

通过平台的可视化界面，这段「业务逻辑」被拖拽成若干节点，调试时可以逐节点检查入参与出参，调试体验比自己搭一套链路要省心不少。

六、步骤四：MCP 工具接入与多智能体协作

为了让智能体真正落地业务，我接入了两个核心工具：

• 学员信息服务（MCP 服务示例 student-profile）：查询学生年级、已报课程等；
• 排课系统（MCP 服务示例 schedule-service）：查询空闲时段并创建预约。

多智能体协作的划分是：

• 「课程顾问智能体」专注于与用户对话和资格判断；
• 「排课助理智能体」专注于与日程系统交互与生成排课方案。

协作方式有两种：

• 显式移交：对话中，顾问确认用户有排课意向后，将上下文打包转交给排课助理；
• 隐式工具调用：顾问在内部调用排课助理暴露出的工具接口，由后者与排课系统打交道。

这种拆分让 Prompt 更加聚焦，也方便后续由不同团队维护不同智能体。

七、评测指标与实际效果

为了避免「感觉不错」这种主观判断，我设计了几类量化指标：

• 准确率：从测试集问题中抽样 100 条，人工标注是否回答正确，最终在 88% 左右；
• 覆盖率：问题是否被正确路由到相应知识域或工具，约 93%；
• 对话轮数：从提问到完成排课，平均 5～7 轮对话；
• 开发效率：
  • 传统方式：人手写话术与脚本，至少需要 2～3 周；
  • 本次实践：1 人主导，配合 1 名业务同学，约 5 个工作日搭出可用版本。

对业务方来说，最直观的感受是新人顾问的上手时间明显缩短，而且系统回答的一致性远高于人工口径。

八、踩坑与经验总结

本次实践中也踩过一些坑：

• 知识库过度碎片化：一开始拆得太细，导致检索效果反而变差，后面合并为「规则类」「价格类」「流程类」三大块；
• 自动生成的 Prompt 不可直接上生产：一定要结合真实问答样本做若干轮微调；
• 多智能体拆分要适度：拆得过多会增加协作成本，建议先从 2 个核心角色开始；
• 调试数据集要尽量真实：不要只用「理想问题」，要包含语病、口语化表达、错别字。

总体来看，ModelEngine 在知识库总结、提示词自动生成、多智能体协作和调试能力上，确实帮我将智能体从 0 到 1 的成本压到了一个可接受的水平。对中小团队而言，这是一个值得认真评估的落地选项。