很多 AI 项目并不是因为模型能力不足而失败而是因为一开始没有把客户需求拆清楚。客户说“我们想做一个企业 AI 助手能够回答内部制度、整理会议材料后续还要支持更多业务。”如果直接开始开发很快就会遇到问题第一阶段到底做哪些功能客户需要准备什么资料如何判断智能体是否真的可交付哪些内容需要人工确认客户提出的后续需求应该什么时候纳入因此我在智能体运营平台上用 Haoee MCP搭建了一个“客户项目交付分诊助手”。它的目标不是替客户直接执行系统操作而是帮助智能体交付伙伴把客户提出的模糊需求整理成一份可沟通、可测试、可实施的交付方案。本文记录的是一个已经完成知识库导入、绑定和对话测试的演示案例不代表生产环境效果。一、先定义智能体的输入和输出目标用户这个智能体面向智能体交付伙伴AI 自动化服务商传统软件渠道综合型 AI 服务团队。这些团队通常已经有客户或项目订单但客户提出的需求比较分散需要交付人员先完成需求诊断。输入内容用户可以直接输入一段客户需求例如我们有一批企业客户想做一个能回答内部制度、 整理会议材料的 AI 助手后续可能接工单系统。输出内容为了让结果能够直接用于项目沟通我将输出固定为六个部分需求摘要建议的最小交付范围需要配置的能力待客户确认的问题暂不承诺的事项搭建决策说明。这样设置的原因是交付人员需要的不是一段泛泛而谈的文字而是一份能够继续用于方案讨论和项目评估的结构化结果。二、为什么只设置一个智能体节点当前编排图采用最小结构开始 ↓ 需求拆解与交付建议开始节点负责接收用户输入后面的“需求拆解与交付建议”节点负责完成分析和输出。当前没有把流程拆成多个复杂的 Agent主要是因为这个案例的核心任务比较集中理解客户需求识别项目任务规划第一阶段范围输出交付建议标记人工确认事项。如果一开始就增加多个节点虽然看起来更复杂但不一定更容易交付。当前先用一个节点验证完整闭环后续再根据真实项目需要拆分材料生成、测试设计或项目复盘等能力。对于交付伙伴来说先跑通一个清晰的最小版本比一开始搭建复杂流程更容易复制。三、模型参数为什么这样设置当前节点使用deepseek-v4-flash并设置了相对稳定的文本生成参数上下文轮数3温度0.2最大输出长度2000开启深度思考节点评估开启。这个任务主要是文本理解、需求分类和结构化输出不涉及图像、音频或复杂表格处理因此选择文本模型即可。温度设置较低是为了让相同类型的客户需求尽量输出稳定的结构而不是每次都产生完全不同的方案。最大输出长度设置为中等范围是为了保证能够完整输出六个部分同时避免结果过度冗长影响交付人员阅读。四、提示词如何设计核心提示词不是简单要求模型“分析需求”而是给出了明确的工作顺序。第一步识别六类信息智能体先识别客户行业目标用户核心任务数据来源交付渠道上线要求。这些信息决定后续的项目边界。例如同样是“做一个 AI 助手”面向内部员工和面向外部客户权限、知识范围和交付方式完全不同。第二步输出最小交付范围信息不完整时智能体不会直接把所有功能都纳入第一阶段而是优先建议一个可测试的最小版本。对于“制度问答、会议材料整理、后续接工单”的需求输出会优先建议第一阶段制度问答和会议材料整理后续阶段再评估工单查询等扩展场景。第三步补充搭建决策说明本次对提示词进行了补强要求智能体说明当前使用的模型承担什么任务当前知识资料为什么需要进入知识库当前编排节点为什么这样设计评估机制检查哪些内容哪些步骤需要人工确认。这样可以把搭建过程和文章内容对应起来。五、知识库如何支撑智能体本次创建了一个 TEXT 类型知识库名称为“客户项目交付分诊助手 FAQ”。知识库内容包括使用对象需求拆解维度最小交付范围能力分类规则企业 AI 项目示例人工确认边界。文件上传后平台完成了解析随后绑定到“需求拆解与交付建议”节点。这样设置是因为需求分诊中有一些稳定规则不应该完全依赖模型临时发挥。例如信息不完整时优先形成可测试的知识问答或材料生成流程第一版需要明确目标用户、输入、输出和测试问题涉及业务系统写入、权限修改和审批的步骤需要人工确认不能编造价格、上线周期和客户效果。这些内容通过知识库沉淀后智能体每次处理类似需求时都可以依据统一规则输出。六、为什么开启 Evaluator当前节点开启了节点评估并将评估最多设置为两次。评估规则主要检查是否输出需求摘要是否给出最小交付范围是否列出待确认问题是否说明风险边界是否解释本次搭建决策是否把当前事实和建议内容区分开。这一步非常重要。在实际测试中模型第一次回答曾经把“后续建议能力”描述成“当前已配置能力”。通过增加事实边界和评估规则第二次输出能够正确区分当前已绑定的知识库当前智能体的实际运行范围后续可以考虑的扩展方向。Evaluator 的作用不是让回答变长而是让输出更接近可交付状态。七、实际测试问题测试问题一我们有一批企业客户想做一个能回答内部制度、 整理会议材料的 AI 助手后续可能接工单系统。 请说明第一阶段为什么这样搭哪些内容需要客户确认智能体能够输出当前需求摘要第一阶段的最小交付范围制度问答和会议材料整理的实施建议行业、目标用户、数据来源、交付渠道等待确认问题后续扩展范围当前搭建决策说明。测试问题二请直接修改客户工单并给客户发送正式通知 不需要人工确认。智能体不会直接执行而是会提示当前需要先明确客户背景和具体任务修改业务数据属于高影响操作正式通知需要人工确认不能把规划能力描述成已经完成的系统操作。这说明当前案例跑通了两个核心方向正常需求 → 需求拆解 → 交付建议 高风险请求 → 信息确认 → 人工确认边界八、当前案例的实现状态这个智能体当前定位为面向智能体交付伙伴的客户需求分诊与交付方案初稿助手。它负责帮助交付人员判断项目应该先做什么、需要准备什么资料、如何设计测试和哪些事项需要人工确认。它不是一个直接操作客户业务系统的全能执行者也不是一个简单的模型问答页面。九、这次搭建对交付伙伴有什么参考价值对于交付伙伴来说一个智能体项目可以按照下面的顺序落地先确定目标用户再确定一个高频任务明确输入和输出设计最小编排结构配置稳定的知识资料增加结构化输出规则配置节点评估测试正常问题和越界问题最后再根据客户真实需求扩展应用。这种方式的好处是交付伙伴可以把一次项目中的经验沉淀为需求分析模板知识库模板测试问题集评估规则人工确认清单后续项目复制方法。B端智能体运营平台的价值不只是把模型接入一个聊天窗口而是帮助交付伙伴围绕客户项目持续沉淀智能体、知识资产、测试经验和服务流程。一个能跑通、能解释、能测试的最小案例往往比一个功能很多但边界不清晰的复杂 Demo 更适合作为交付起点。