智能体项目一旦进入交付阶段，问题会从“能不能搭出来”转向“能不能稳定交付给多个客户”。
一个客户项目的提示词写得再好，如果没有模板、知识库、权限和版本管理，第二个客户仍然需要重新搭建。
更危险的是，直接复制之后可能发生数据串用。
本文以一个实际搭建的连锁餐饮门店案例，说明如何把一个智能体模板复制给多个客户。
一、案例目标
场景是“门店开店检查”。
目标用户是连锁餐饮品牌的店长和区域负责人。原有流程通常是店长在群里发送文字：
今天门头正常，员工到岗，后厨有积水，燃气附近有异味。
区域负责人再人工整理：
哪些项目已检查；
哪些项目异常；
哪些信息缺失；
是否需要进一步确认。
首期不做系统自动写入，只做信息整理和人工确认。
二、模板层和客户层
本次模板固定以下内容：
输入字段；
输出格式；
信息缺失时的追问规则；
异常识别规则；
高风险问题转人工规则；
评估标准。
客户层则分别保存：
门店名称；
营业准备时间；
检查项目；
客户内部用语；
客户专属注意事项。
用Haoee最终形成了两个发布对象：
xx简餐开店检查助手；
ww小馆开店检查助手。
两者使用同一个基础模型和相同的编排结构，但绑定不同知识库。
三、模型和编排设置
模型选择 deepseek-v4-pro，主要原因是该案例以中文文本理解、信息抽取和结构化输出为主。
温度设为 0，降低同一输入下输出格式波动。
编排包括：
开始节点；
开店检查整理节点；
节点评估机制。
没有单独配置 Planner，原因是首期输入结构比较简单，不需要把任务拆成多个执行阶段。
没有单独配置 MCP Server，原因是首期不操作外部系统。
没有配置 Skills，原因是当前版本不涉及复杂工具调用。
没有启用上下文记忆，原因是每次检查记录都应作为独立任务处理，避免上一家门店的信息影响下一次检查。
四、知识库导入
禾味简餐和邻里小馆分别建立独立的文本知识库。
两份演示文件内容都包含：
门店基本规则；
营业准备时间；
检查项目；
信息补齐要求；
异常处理边界；
输出格式。
每份文件导入后形成 5 个文本分片，完成解析和向量化。
这里不能把两个客户资料合并到一个知识库中再依赖提示词区分。提示词不是可靠的租户隔离机制，客户资料本身就应该独立管理。
五、复制后的测试
xx简餐测试结果：
识别 09:30 前完成准备；
能输出后厨积水和燃气异味；
能列出尚未提供的物料、公告等信息；
对危险问题进行人工确认提示。
ww小馆测试结果：
识别 10:30 前完成准备；
使用邻里小馆自己的检查项目；
被问到禾味简餐规则时，提示知识库没有相关内容。
缺少门店名称、检查日期和检查人时，两个副本都会先追问，而不是直接生成完整摘要。
六、交付时不要只复制智能体
一个完整的客户交付包，至少应该包括：
智能体结构模板；
客户知识库；
客户专属测试集；
模型和参数说明；
权限边界；
人工确认流程；
发布版本；
变更记录。
从平台能力角度看，这类更适合承载这种面向客户项目的智能体运营和持续维护，而不是只完成一次性的 Agent 创建。
七、后续扩展
后续可以增加：
门店照片输入；
结构化检查表；
工单系统连接；
区域负责人审批；
门店项目统计；
多门店运营看板。
但这些功能不应该在模板复制的第一天全部加入。
更稳妥的方式是先让模板完成“信息理解、知识检索、结构化输出和人工确认”，再逐步增加工具和系统连接。
