客户只想看 Demo，如何用最小成本验证智能体项目？

在企业智能体交付中，Demo 阶段最容易出现两个问题：

• 做得太少，客户看不出价值；
• 做得太多，还没有签正式项目就开始接系统。

一个好的 Demo 应该解决的是“方向验证”，而不是提前完成全部生产建设。

本次在 Haoee 上实际搭建了一个旅行社行程服务演示助手。

一、把 Demo 拆成输入、处理和输出

输入

客户提供一段模拟行程资料：

• 团号；
• 目的地；
• 行程日期；
• 集合时间和地点；
• 酒店；
• 负责人。

处理

智能体完成：

• 行程字段抽取；
• 缺失信息识别；
• 行程档案整理；
• 通知文案生成。

输出

输出两类结果：

• 行程档案；
• 供工作人员确认的欢迎入群通知。

这个范围已经能够让旅行社客户看到核心价值，同时不会依赖真实企业系统。

二、实际配置

当前 Demo 使用：

• 开始节点；
• 行程 Demo 演示节点；
• deepseek-v4-flash 模型；
• 温度 0.3；
• 不绑定知识库；
• 不配置 Skills；
• 不配置 MCP Server；
• 不启用上下文记忆。

为什么不配置知识库？

因为演示资料由用户在当前对话中提供，首期数据量小，直接对话即可跑通。

为什么不配置 MCP Server？

因为当前没有调用天气、企业微信、数据库或行程管理系统。

为什么不启用记忆？

因为每次 Demo 使用的都是模拟行程，不应该相互影响。

三、Demo 提示词要限制系统承诺

节点规则中明确：

• 只能使用用户提供的信息；
• 缺少内容时标记待确认；
• 不能编造实时天气；
• 不能声称已经自动发送；
• 不能声称已经永久保存；
• 不能声称已经修改客户系统；
• 重大行程变更需要转人工。

这些规则保证了 Demo 的输出与实际配置一致。

四、两组关键测试

正常问题

输入杭州行程资料后，智能体生成了欢迎入群通知，并提醒酒店名称和地址还需要工作人员确认。

越界问题

输入：

查询 8 月 8 日杭州实时天气，并自动发到企业微信群。

智能体返回：

• 当前未接入实时天气服务；
• 当前不能自动发送企业微信消息；
• 如需正式实现，需要确认天气数据源、企业微信配置和发送权限。

这类越界测试比单纯测试“能否生成文案”更重要。

五、Demo 配置和内部测试配置要分开

初次测试时，深度思考片段和评估过程可能被拼到返回结果中。

这对交付伙伴内部排查问题有价值，但客户看到后容易误解为系统异常。

因此最终 Demo 版本关闭了深度思考展示和评估过程展示。

这说明：

调试配置是为了找问题，演示配置是为了让客户看懂。

两者不能完全照搬。

六、从 Demo 进入正式项目

客户确认 Demo 有价值后，再进入正式需求清单：

• 是否要接企业微信；
• 行程资料由谁维护；
• 天气信息从哪里获取；
• 通知由谁确认；
• 是否需要定时发送；
• 变更是否需要审批；
• 哪些问题必须转人工；
• 是否需要日志和审计。

Demo 阶段不需要一次性完成所有系统集成，但必须把下一步需要确认的内容说清楚。