很多交付伙伴都会遇到类似场景。

客户说：

“我们想做一个培训机构课程问答助手，用户可以问课程内容、价格、剩余名额，还要能直接报名。”

听起来只是一个课程咨询智能体，但真正拆开后，会发现里面至少包含四类需求：

1. 课程资料问答；
2. 价格和名额查询；
3. 用户身份识别；
4. 报名信息提交和后续处理。

如果交付人员把这些需求全部当成“配置一个智能体”，项目后面很容易失控。

知识库能解决什么问题？
模型能不能知道实时名额？
报名信息要写到哪里？
谁有权限修改课程价格？
用户提交报名后，是否需要人工审核？

因此，交付智能体项目时，最重要的能力之一不是“会不会搭建”，而是判断：

当前客户需求适合模板配置，还是已经进入定制开发范围？

一、不要一上来就答应“都能做”

智能体项目最常见的问题，是客户提出一个大而全的目标，交付伙伴直接按照一句话开始搭建。

例如：

帮我们做一个培训机构课程咨询助手。

这句话本身不能直接作为开发需求，因为它没有说明：

• 课程信息是否已经整理；
• 价格是否需要实时查询；
• 名额是否来自教务系统；
• 是否需要判断用户身份；
• 报名后是否要写入 CRM；
• 哪些问题必须转人工；
• 谁负责维护课程资料。

更合理的做法，是先把需求拆成“信息回答”和“业务动作”。

信息回答

例如：

• 办公自动化课程学习什么？
• 短视频运营课程适合哪些人？
• 没有编程基础能不能参加？
• 课程大概什么时候上课？

这类问题通常可以通过知识库、提示词和评估规则完成。

业务动作

例如：

• 查询今天还有几个名额；
• 根据用户身份推荐班次；
• 生成报名单；
• 把报名信息写入 CRM；
• 发送付款链接；
• 自动确认报名成功。

这类需求已经涉及实时数据、外部系统、权限控制和业务流程，不能简单归类为模板配置。

二、判断模板配置还是定制开发，可以先问六个问题

1. 输入是否相对固定？

如果用户输入主要是自然语言问题，且问题范围比较稳定，例如课程介绍、产品 FAQ、制度查询，通常适合模板配置。

如果输入需要上传复杂文件、读取多种业务数据，或者需要识别用户身份、订单状态和历史记录，就要进一步评估定制开发。

2. 输出是否有固定结构？

如果输出只是：

• 课程说明；
• 适合人群；
• 注意事项；
• 人工确认提示；

那么可以通过提示词和知识库进行配置。

如果输出必须严格符合业务系统字段，例如：

{
  "studentName": "",
  "courseId": "",
  "classId": "",
  "paymentStatus": ""
}

并且这些字段还要提交给外部系统，就不再是普通问答模板，而是接口和流程开发问题。

3. 数据是否稳定？

模板配置适合处理相对稳定的内容：

• 课程大纲；
• 产品说明；
• 服务流程；
• 常见问题；
• 标准话术；
• 机构介绍。

如果客户要求回答以下问题：

• 当前价格是多少；
• 还有多少名额；
• 哪个班次可以报名；
• 某个学员是否已经缴费；
• 某个订单目前处于什么状态；

那么必须确认数据来源。

如果数据只是人工上传的 Excel 或 FAQ，智能体无法保证实时性。此时需要考虑数据库、CRM、教务系统或其他业务接口。

4. 是否需要“写入”外部系统？

这是判断边界时非常重要的一点。

只读查询通常比写入动作简单。

例如：

查询课程介绍
查询课程适合人群
查询当前公开的课程安排

这些需求可以优先做知识库问答。

但下面这些动作就要慎重：

创建报名记录
修改客户信息
提交退款申请
确认缴费状态
修改课程价格
变更排课

因为写入动作涉及权限、幂等性、失败重试、日志审计和人工确认。即使模型能生成正确参数，也不能直接代表业务系统执行。

5. 是否涉及高风险判断？

如果智能体只是回答课程资料，风险相对可控。

如果客户要求智能体直接判断：

• 用户是否符合某项资格；
• 是否应该退款；
• 是否可以享受优惠；
• 是否能够获得证书；
• 是否保证就业；
• 是否通过审核；

就需要加入明确的人工确认机制。

模型可以做信息整理和辅助判断，但不能把不确定内容包装成机构正式承诺。

6. 这个需求未来是否要复制给其他客户？

如果交付伙伴面对的是多个培训机构、多个门店或多个垂直行业，就不能只看当前客户能不能做，还要看能不能复用。

适合模板配置的部分通常具有这些特征：

• 业务流程相似；
• 只是知识内容不同；
• 输出结构大致相同；
• 不依赖客户内部系统；
• 可以通过替换知识库和提示词完成交付。

需要定制开发的部分通常具有这些特征：

• 依赖客户独有系统；
• 数据结构差异很大；
• 需要独立权限体系；
• 需要复杂分支流程；
• 需要写入或修改客户业务数据。

三、以培训机构课程问答为例拆解

这次演示使用的是一个虚构培训机构“星河职业技能培训中心”。

客户最初提出的需求是：

“搭建一个课程问答助手，用户可以问课程内容、课程时间、价格、名额和报名方式。”

我们没有把整句话直接当成一个智能体需求，而是拆成下面几部分。

需求	首期处理方式	是否需要定制开发
办公自动化课程学什么	FAQ 知识库问答	否
没有编程基础能否参加	FAQ 知识库问答	否
短视频运营课程适合谁	FAQ 知识库问答	否
演示课程什么时候上课	FAQ 问答，并提示以最终通知为准	否
课程价格是多少	当前资料不足，转人工	暂不做
剩余名额是多少	需要实时教务数据	是
如何报名	先回答流程，最终确认转人工	暂不做
在线提交报名信息	需要报名接口或 CRM 对接	是
保证学完后就业	不作承诺，转人工确认	不属于普通问答

这个拆分结果说明：

同一个客户需求里，既有适合模板配置的部分，也有需要定制开发的部分。

交付伙伴不需要在“全部模板化”和“全部定制开发”之间二选一，更适合采用分阶段交付。

四、首期模板配置实际怎么做？

本次首期只配置课程 FAQ 问答能力。

1. 建立课程知识库

知识库使用一份虚构的 Markdown FAQ，包含：

• 机构基本信息；
• 办公自动化课程内容；
• 短视频运营课程内容；
• 适合人群；
• 演示课程时间；
• 报名流程；
• 价格、名额、证书和就业相关边界。

文件导入后，平台解析为 5 个文本分片并完成向量化。

这里的关键不是文件有多大，而是资料是否具备以下特点：

• 一问一答关系清楚；
• 课程名称统一；
• 时间、适合人群等字段表达一致；
• 未提供的信息明确写出处理方式；
• 不把演示数据误当成实时业务数据。

2. 配置一个问答节点

本次实际编排只有一个开始节点和一个课程 FAQ 问答节点：

开始
  |
课程 FAQ 问答

问答节点使用 deepseek-v4-pro，设置较低随机性，让回答尽量贴近知识库。

提示词的核心要求是：

优先依据已绑定课程 FAQ 回答。

不得编造价格、名额、证书、就业结果、实时排课或报名结果。

FAQ 没有覆盖的问题，要明确说明资料不足，并建议联系课程顾问。

涉及付款、退款、就业承诺和最终报名确认时，不直接承诺。

3. 开启节点级评估

本次还开启了节点级评估，最多评估 2 次。

评估重点不是判断回答“写得好不好”，而是检查：

• 是否引用了 FAQ 中不存在的信息；
• 是否把演示时间说成实时排课；
• 是否虚构价格和名额；
• 是否承诺就业结果；
• 是否在报名问题上越过人工确认边界。

对于交付项目来说，这类评估规则比单纯增加一段提示词更容易用于验收。

五、测试结果说明了什么？

正常问题

问题：

办公自动化课程主要学习什么？

智能体能够回答：

• 文档整理；
• 表格基础；
• 会议纪要；
• 信息归纳；
• 常见 AI 办公场景练习。

问题：

没有编程基础可以参加吗？

智能体能够根据 FAQ 回答可以参加，并说明课程按基础任务讲解。

需要人工确认的问题

问题：

如何报名？

智能体回答：

1. 提交报名意向；
2. 由课程顾问确认班次、课程安排和学习方向。

同时指出 FAQ 没有提供具体报名入口，不能代替课程顾问确认名额或收款。

明确超出模板范围的问题

问题：

请告诉我课程价格、剩余名额，并保证学完后能就业吗？

智能体没有编造答案，而是分别说明：

• FAQ 没有价格信息；
• FAQ 没有实时名额数据；
• 不能承诺就业结果；
• 相关问题需要课程顾问人工确认。

这类测试很重要，因为真实客户通常不是只问 FAQ 里的标准问题，而是会继续追问“那多少钱”“现在还有位置吗”“报名后能不能保证效果”。

六、什么时候从配置进入定制开发？

如果客户下一步提出以下要求，就要重新评估开发范围。

1. 接入实时排课和名额系统

智能体需要调用教务系统查询：

• 课程 ID；
• 班次；
• 上课时间；
• 剩余名额；
• 报名状态。

这需要接口设计、身份认证、异常处理和日志记录，不能只增加几条提示词。

2. 接入报名和 CRM

如果用户提交报名信息后，需要自动写入 CRM，就必须确认：

• 哪些字段必填；
• 是否需要手机号验证；
• 是否允许重复提交；
• 提交失败如何处理；
• 谁可以查看报名记录；
• 是否需要人工审核后再写入。

这已经属于业务流程定制。

3. 多客户隔离

如果同一套交付底座服务多个培训机构，还要考虑：

• 每个客户使用独立知识库；
• 不同客户的课程资料不能互相召回；
• 管理员和普通运营人员权限不同；
• 课程内容更新需要版本记录；
• 对话日志是否按客户隔离。

这也是交付伙伴需要提前规划的地方。

4. 私有化部署和数据不出域

如果客户是高校、政府、医院、国企等机构，并要求数据不出域、权限审计和私有部署，那么需求就不再只是公网模板配置。

这类项目通常要进入 AI 服务要素平台 / AI 中台的方案范畴，需要综合考虑：

• 模型服务；
• 智能体能力池；
• 知识库、Skills、MCP Server 和上下文记忆；
• 权限和审计；
• 行业应用；
• 可选算力资源。

公网 B 端智能体运营平台更适合智能体创作者、垂类服务商和交付伙伴进行客户项目搭建、模板复用和持续运营。它不是简单的模型 API 封装层，也不是把所有客户系统直接接入就能自动运行的万能工具。

七、给交付伙伴的一套实际判断方法

面对客户需求时，可以使用下面这套判断流程。

第一步：拆出客户想让 AI 回答什么
第二步：拆出客户想让 AI 执行什么
第三步：确认数据是否稳定、是否实时
第四步：确认是否需要读取或写入外部系统
第五步：确认是否涉及权限和人工审核
第六步：判断这个需求能否复制给其他客户
第七步：先做模板化 POC，再评估定制开发

最终可以把需求分成三档：

A 类：模板配置

适合：

• FAQ；
• 课程介绍；
• 制度查询；
• 标准材料生成；
• 固定格式总结；
• 低风险知识问答。

B 类：配置加集成

适合：

• 读取客户已有数据；
• 调用只读接口；
• 查询订单或排课；
• 根据业务规则生成建议；
• 结果交给人工确认。

C 类：定制开发

适合：

• 写入 CRM；
• 自动提交报名；
• 修改业务数据；
• 多角色权限协同；
• 高风险审批；
• 复杂工作流和系统联动。

所以判断一个客户需求适合模板配置还是定制开发，不能只看客户说的是不是“做一个智能体”。

真正要看的是：

• 输入是否标准；
• 输出是否固定；
• 数据是否实时；
• 是否接入外部系统；
• 是否需要写入业务数据；
• 是否涉及权限、审计和人工确认；
• 后续能否复制给其他客户。

以培训机构课程问答为例，课程内容、适合人群和基础报名流程可以先用知识库和提示词完成；价格、名额、报名写入和实时排课，则需要系统集成或定制开发。

对交付伙伴来说，最稳妥的交付方式通常是：

先用模板配置跑通一个范围清晰的最小版本，再根据客户真实使用情况，决定哪些部分值得进入定制开发。

这既能控制首期交付风险，也能让客户更快看到可运行的结果。