上周有人来问：“你们智能体定制用哪个模型？”
我没有直接回答，先问了一句：这个任务现在谁在做，一天做几次，卡在哪一步。
对方愣了一下。他说，模型是技术选型，流程是业务部门的事。
这其实是很多定制项目一开始就埋下的问题。模型当然重要，但它排在任务、知识和系统后面。顺序反了，演示通常很好看，上线后却没人用。
先看任务怎么流动
不要先打开模型列表，先画一遍现在的流程。
一个任务至少要问清楚四件事：
- 输入从哪里来，是表格、聊天记录、邮件，还是某个系统里的数据；
- 中间要做哪些判断，哪些有明确规则，哪些靠经验；
- 输出交给谁，是人看，还是直接写回系统；
- 出现例外时，现在由谁处理。
这四件事没答清楚，模型能力再强也只能做演示。
比如“整理客户询盘”听起来简单。实际可能包含识别产品、判断地区、查库存、分级线索、分配给销售五个动作。每个动作的规则不同，出错代价也不同。把它们混成一个“智能体”，最后往往是谁都不满意。
知识在哪里，决定要不要做知识库
流程看清后，再看知识。
产品资料、报价规则、售后政策、历史工单，这些内容如果分散在网盘、群聊和个人电脑里，第一步不是接模型，而是整理。
但也不是所有任务都需要 RAG。答案如果来自结构化数据，比如订单状态、库存数量、工单进度，优先查接口。答案如果来自文档和经验，才考虑知识库。
知识库也不是把文件一股脑传上去。要标明来源、更新时间、适用范围和负责人。否则模型回答得越流畅，错误越难发现。
系统能不能接，决定上线后的样子
很多智能体在演示环境里很聪明，一接真实系统就变笨。原因通常不是模型，而是权限和接口。
先区分两类动作：
- 读：查订单、查库存、查客户记录、查工单；
- 写：改状态、发消息、建工单、提交审批。
读操作可以先做，风险相对低。写操作要谨慎，至少要有确认、日志和回滚。涉及付款、合同、对外承诺的动作，不应该由智能体单独完成。
如果现有系统没有接口，也不要硬上。可以先做导出、人工上传，再逐步减少手工步骤。能稳定跑起来，比接口看起来先进更重要。
模型排在这些之后
到了模型选型，反而简单一些。
不要只看排行榜，用自己业务的测试集跑一遍。看四件事：
- 在真实问题上答对的次数；
- 遇到不知道的问题，会不会停下来；
- 调用工具和读写数据是否稳定；
- 延迟和成本能不能接受。
同一个任务，不同模型的表现可能差很多。有人擅长长文档，有人擅长工具调用，有人对中文口语更稳。用二十条真实问题测，比看十篇评测文章有用。
定制不是把流程全交出去
智能体定制经常被理解成“把整个人替换掉”。实际更常见的是人机分工。
哪些步骤交给系统，哪些必须留给人，要在设计时就写清楚。比如：
- 资料检索、初步分类、草稿生成，可以交给系统；
- 价格例外、合同条款、对外承诺，保留人工确认；
- 系统拿不准时，要能转人工，而不是继续猜。
一个能停下来问人的智能体，通常比一个什么都敢答的智能体更可靠。
先定验收，不然没法判断好坏
智能体定制的验收，不是“感觉挺聪明”。
至少要写清楚：哪些问题必须答对，哪些问题必须转人工，哪些数据不能碰，响应时间能接受多久，出错后怎么回滚。
验收样本最好从真实业务里抽，不要用供应商准备的演示题。二十到五十条就够，覆盖常见问题、边界问题和异常问题。
如果验收标准写不出来，说明场景还没想清楚。这时候继续写代码，通常只是把不确定性往后拖。
一个可执行的顺序
我们的做法通常是这样：
先做任务盘点，选一个频率高、规则相对清楚、出错代价可控的场景。再把知识和数据来源列出来，确认哪些能接、哪些要补。然后定验收样本和人工接管方式，最后才选模型和供应商。
第一版不要追求功能多。能稳定完成一个任务，比十个半成品功能更有用。
跑两周，看使用率、返工率和未解决问题，再决定要不要扩到第二个场景。
什么情况下先别做
不是所有任务都适合智能体定制。
频率很低、每次都要重新判断、数据拿不到、出错代价很高，这几种情况先放一放。还有一种更常见：流程本身就没理顺，指望 AI 来补救。这样做的结果，通常是把原来的混乱自动化一遍。
智能体定制的价值，不是用了哪个模型，而是把任务、知识、系统和人的分工接起来。顺序对了，模型才有意义。