我遇到过不少来问智能体的客户，开口就是「能不能先做个 demo 给领导看看」。我一般先不问模型，先反问一句：你是想让它回答问题，还是想让它替你跑流程？
这两件事在数据准备、验收方式、投入上差得远。混在一起谈，做出来的东西演示时挺热闹，上线后没人用。
问题现象：一句话需求里混着两类东西
常见的一句话需求是这样的：把公司的制度、客服话术、订单系统都用上，做个智能助手。听着是一个产品，拆开其实是两套东西。
一类是知识库问答：把文档、制度、话术变成可查询、能给出处的问题。输入是文本，输出是答案，衡量的是答得对不对、有没有落到原文。
另一类是流程自动化：替代人工在几个系统之间搬数据、填单、走审批、发通知。输入是事件或指令，输出是系统里被改动的状态，衡量的是流程跑没跑完、出错能不能兜住。
前者交付的是一个查资料的入口，后者交付的是一条能跑通的链路。把两者放进同一张验收单，基本没法验收。
排查过程：先问两个问题，不动代码
我现在习惯让客户先回答两个问题。
一，用户拿到答案之后，还要不要自己去别的系统里操作？如果要，核心就是问答，流程那部分先往后放。
二，这件事出错一次，代价是「答得不准，人再查一遍」，还是「数据写错，要人工回滚」？前者偏问答，后者偏流程，流程类的容错设计成本高出一截。
再往下才谈数据。问答类要的是文档本身，加上一份真实问题清单；流程类要的是接口、权限、字段映射，以及异常发生时谁来接手。
我遇到过不少客户，文档给了一大堆，问题清单一条没有。这样评估出来的效果没有意义——模型答得再顺，也没人知道它答的是不是业务真正会问的那几句。
方案与关键参数：两类分开准备、分开验收
知识库问答这边，我通常要求先交一份问题清单，二三十条就够，覆盖高频问法和几个边界情况。每条写清期望落到哪份文档的哪一节，比如 {"q": "试用期请假超过3天找谁审批", "expect_doc": "考勤制度v3.pdf#第4节"}。
验收看两条：答案能不能指到具体段落；查不到时会不会说「没查到」，而不是编一段出来。分块大小、召回条数这些参数可以调，前提是问题清单来自真实咨询，不是照着文档自己出题。
流程自动化这边，先把链路画清楚：从哪个系统触发，经过哪几个节点，失败停在哪，谁来处理。参数上我盯三件事：重试次数、幂等键、超时时间。这三样不写明白，跑起来出问题只能翻日志。
投入的差别也在这。问答类前期贵在整理文档和问题清单，后面改动小；流程类前期贵在打通接口和权限，后面每加一个系统就要再谈一次对接。
踩坑：别拿演示观感当验收标准
反复出现的坑是同一个：用 demo 的效果替代验收标准。演示时问的都是准备好的问题，走的都是顺利路径，看着很顺。上线后用户问的第一句话就不在预料里。
另一个坑是把流程问题当问答做。用户问「我的报销到哪一步了」，这不是知识库能答的，得去查流程系统的状态。硬做在问答里，只能返回一段制度说明，用户看完还是不知道自己的单子在哪。
还有个边界要提前讲清楚：跨系统的流程自动化，卡住的往往不是模型，是对方系统没接口、权限不给开、字段对不上。这些事跟智能体本身没关系，但直接决定项目能不能落地。
结论
上智能体之前，先把需求分成两堆：一堆是查得到、说得出处的问答，一堆是跑得完、出错能兜住的流程。分开写数据准备清单，分开定验收标准，然后才谈模型和方案。
顺序上我的建议是先整理真实问题清单和现有文档。这两样东西哪怕后面不上智能体，对内部知识整理也有用。
适用边界：文档相对稳定、问题集中在制度与话术的，适合先做问答；流程节点固定、系统有开放接口的，适合做自动化。不适用的也直说：文档本身互相矛盾、长期没人维护的，先去修文档；流程还没定下来、隔几天就改的，先别上自动化，做完就得重做。
你们现在想做的那个「智能体」，是答问题的，还是跑流程的？如果一句话说不清，多半是两件事被混在一起了。
#智能体 #知识库问答 #流程自动化 #需求分析 #企业系统
