帮企业做 Agent 落地，我踩过最大的坑不是技术选型，是一个念头：什么活都想让 Agent 干。

老板听完 AI 的故事热血上头，回来就把工单分派、报表计算、评分卡全想交给大模型。跑了一个月，账单爆炸，结果还不稳定。回头复盘才发现，问题不在模型，在那批活本来就不该由 Agent 干。

这是《企业AI落地实战》系列第四篇。前面聊了怎么问死不该做的项目、怎么给任务配模型、底座该投哪一层，这一篇聊最实际的问题：企业里哪些活真的能交出去。

上手就想让 AI 全接管，其实该先问这活能不能写成规则

接到一个"AI 化"需求，我现在的第一句话是：这个活能不能写成明确的规则或者流程图？

能写清楚的，是确定性需求。比如"金额大于某个数走 A 审批，小于走 B"，比如"收到工单先查知识库再派单"，比如"每月一号跑报表"。这类活的答案藏在规则里，不藏在推理里。工作流引擎加传统模型，又快又稳又便宜。

写不清楚的，是不确定性需求。比如"这个客户投诉的根因到底是什么"，比如"帮我调研一下这个市场"，比如"把这段遗留代码重构了"。这类活要边做边看、走一步探一步，这才轮到 Agent 出场。

这一问的价值比想象的大。有人拿它过了一遍某企业的需求清单：30 个"AI 化"需求里，24 个其实是确定性需求，用工作流加规则就能漂亮解决，压根用不上大模型；剩下 6 个才是真 Agent 场景。

真正的省法不是把模型换小，而是把这批活从推理路径挪回规则路径。一次分诊，省下的是数量级的钱和折腾。这也是我为什么坚持在动手前先问这一句。

确定的事交给流程，不确定的事才轮到 Agent

替传统技术说句公道话，这几年它们被 AI 热潮踩得太狠了。

工作流引擎解决的是"按规执行"：输入确定、输出确定、过程可回放、每一步可审计。跑一万次结果一致，出错能定位到具体节点。这些是生产环境的硬指标，到今天也没有哪个大模型能承诺。

传统模型——不是大模型，是评分卡、树模型、时序预测那些——解决的是"精确计算"。风控评分要的是概率校准，销量预测要的是误差可控，推荐排序要的是点击率。这些活，梯度提升树跑一次几毫秒、成本趋近于零，稳定性还比大模型高。

这里有个很实际的分界：让大模型算评分，一是贵，二是同一输入两次输出可能不一样，根本过不了审。企业做的是要签字负责的业务，不是聊天。

所以顺序永远是：先问能不能用确定性方案，答"不能"，才上 Agent。Agent 是给写不出规则的问题准备的，不是给嫌写规则麻烦的人准备的。嫌麻烦想用 Agent 绕过去的项目，我见一个凉一个。说到底，决定用不用 Agent 的，不是技术偏好，而是这条活的性质。

2 分钟压到 20 秒，这套工单系统是怎么改的？

说个具体的。有个团队做客服审核场景，原来的流程是这样：操作人员拿到一个待处理工单，在 2 个系统之间来回切，逐一查看各自的 7 到 10 个模块，手动比对信息，再凭经验综合判断，最后给出处理建议。熟练坐席一单 2 到 3 分钟，而且结论高度依赖个人经验，不同的人给出的判断可能差很远。

他们把这套流程重构了，拆成四步：一次请求触发跨系统多模块并发取数；规则引擎和模型双通道评估标签；分层决策引擎输出带 Trace 的结论；模型生成自然语言总结和处理建议。

结果是 20 到 40 秒一单，关键路径提效 3 到 9 倍。另外还有个细节很聪明：数据边算边推，坐席不用等全部算完就能开始看，等待期间还能并行处理别的工单。

这套改造真正值钱的地方，不是换了更强的模型，而是把原来锁在个人经验里的判断，搬进了可审计的配置和规则。

这里面有两个工程决策值得抄。

一个是配置驱动的取数编排。跨系统十几个数据模块，每个都有自己的接口参数、依赖关系、缓存策略，硬编码一个就不可维护，新增一个数据维度就得改代码发版。他们把它抽象成配置：一个取数单元就是一个配置块，新增维度改配置就行。

另一个是并发与依赖的处理。全部串行太慢，等待时间是所有接口耗时之和；全部并发的也不行，有些接口要拿上游返回的字段当入参，并发启动会拿到空参数。这两个极端都不对，得按依赖编排。

让机器给结论，还要让它说清为什么

这个案例里我最想拿出来讲的一点，是他们对"可解释"的态度。

机器给出的结论如果只有"通过"或者"拒绝"，操作人员没法理解为什么，更没法在结论有争议的时候提供依据。时间一长，人就会绕过系统、凭自己经验办，系统就白建了。

他们的做法是让每一步决策都留 Trace，而且必须是人能读的：每条标签都能说明"基于哪个数据得出"。

可解释不是锦上添花，而是人机协作的基础。这句话放在企业场景里尤其成立——只要有一个环节让人说"我看不懂它凭什么这么判"，整套自动化的信任就塌了。而且处理这类风险的活，往往还带着合规要求：结论要留痕，判断要能复现。

别把大模型当计算器用

工单系统这套架构里还有个分层，我认为是企业 Agent 落地最值钱的姿势：大模型做规划和推理，小模型做计算，工作流负责落地。

举个投诉处理的例子。大模型读一遍投诉原文，理解情绪和诉求，判断"这是物流问题还是产品质量问题"，拆出要查的三个数据点；小模型和查询规则把三个数据点算出来回传；大模型综合这三份数据给出处理建议；最后工作流把方案送进审批流走完赔付。

全程大模型只调用两次。算账的是小模型，落地的是工作流。这套结构跑下来，成本只有全大模型方案的十分之一，速度还更快。

反向的坑是让大模型"顺手"干小模型的活。比如让它从投诉文本里提取订单号——看起来省事，实际上一次调用几毛钱，还不保证提对。一个正则，或者一个小模型，零成本，百分之百稳定。

我自己的原则是两句：能用便宜的绝不用贵的，能确定的绝不用概率的。

准备、执行、验证，缺一段就不算完成

上面讲的是怎么选、怎么分层。最后讲一个最容易翻车的环节：怎么确认活真的干完了。

我的做法是把执行拆成三段：准备、执行、验证。准备阶段确认输入和权限，执行阶段调用工具完成动作，验证阶段重新读取实际结果。每一段都要有停止点——权限不足或者参数不清楚，不要跳到下一步。

这里最常见的误区，是把工具返回的"成功"当成任务完成。接口接受了请求，只能说明动作被接收；真正的验收要回读目标页面、文件、草稿或者任务状态，确认结果确实落地了。

我做内容这套流水线就是这么定的规矩：文章存进草稿箱，必须回读草稿箱确认标题在里面、图片确实嵌进去了；改了标题，必须重新打开看一眼是不是真的改了。完成的标准不是动作发出去了，而是结果被回读到了。草稿成功不等于内容可用，这两件事经常被混在一起。

高风险动作还要单独留一道确认。搜索、整理、生成草稿这类可以自动跑；删除、覆盖、对外发送、修改正式数据，就得先把影响范围摆出来：对象是谁、多少条、在哪个位置、最终内容长什么样，等人点头再动。

哪些活必须留在人手里？

讲了这么多能自动干的，说说不能的。

需要承担责任的决定、需要创意和审美的判断、需要临场博弈的谈判——这些交给 AI，出事的代价远大于省下的时间。审批这件事尤其微妙：Agent 可以替人去核对、去计算、去准备材料，但签字这件事必须有人。一笔赔付、一份合同、一次放行，最后那个"同意"背后是人家的职业责任，不是模型的一次生成。

合理的分工是这样：人负责事实确认、优先级判断和最后决定，Agent 负责整理、调用工具和重复检查。分工越清楚，越不容易出现自动化做过头、或者人工反复搬运的情况。

至于 ROI 怎么算，省下来的人工时间只是分子的一半——分母里要加上搭建成本、维护成本和每次验收的时间。这笔账怎么算清楚，是下一篇的事，也是企业 AI 项目最容易露馅的地方。