2025 年 10 月，一家做城配物流的客户提了个新要求：之前给他们的智能体能查订单、能解释运费怎么算的，现在想让智能体直接干活——调度群里发一句"把明天上午 X 车队的 6 单改派给 Y 车队"，智能体直接在 TMS 里把单改了。

我们第一反应是不敢。查数据错了顶多答错一句话，改单改错了，货就真上错车了。但需求是真实存在的：他们调度组晚上只有一个人值班，改派高峰期一晚上 80 多单，人工一单要点七次屏幕。

最后是靠一套灰度方案把这事做下来的。这篇就把四个阶段、每阶段的通过标准、以及中间出过的一次事故写清楚。

阶段零：影子模式，只看不动手

智能体每次生成"我打算执行的操作"（调哪个接口、带什么参数），但只落库不执行。人工改完单之后，两边对照。

这个阶段我们跑了 14 天，攒了 142 次建议。结果比预想的好：127 次和人工改的一致；15 次不一致的，复盘下来有 11 次是智能体改得更对——比如按"3 吨以下就近车场"的规则，人工晚上忙起来是凭印象派的，智能体是真按规则算的。

剩下 4 次不一致，全是同一类问题：口语里的实体有歧义。这个后面单独说，它最终变成了一次事故。

阶段一：能动手，但只动低风险的

把它的操作按风险分了三级：

• 绿区：改备注、延长装货时间窗（±2 小时内）、补充车牌信息——错了无伤大雅，可以直接执行
• 黄区：改派、改时间窗超过 4 小时——生成操作工单，人工在工单列表里点"采纳"或"驳回"，点采纳才真正执行
• 红区：取消订单、改运价、改客户信息——不做。智能体的回复是列出操作步骤，让调度自己在系统里操作

这个分级表是跟客户的运营主管一起定的，不是我们拍脑袋。有个细节值得说：我一开始把"改时间窗"整体放进绿区，被他们否了——装货时间动 2 小时以内无所谓，动半天以上，司机第二天就排不开。风险分级必须让干活的人来定，开发觉得无关紧要的操作，在一线可能恰恰是要命的。

操作工单表怎么设计

这是整套方案里最关键的一张表，比 prompt 重要得多：

CREATE TABLE agent_action (
  id            BIGINT PRIMARY KEY,
  scene         VARCHAR(32)   COMMENT '动作类型: reassign / time_window / remark',
  params        JSON          COMMENT '拟执行参数',
  params_hash   CHAR(64)      COMMENT '参数摘要，防篡改',
  dry_run       TINYINT       COMMENT '1=影子模式仅记录',
  status        VARCHAR(16)   COMMENT 'pending/approved/executed/confirmed/rolled_back',
  evidence      JSON          COMMENT '依据：原话、命中的规则、匹配到的实体',
  result_check  JSON          COMMENT '执行后回读的库中实际状态',
  operator_id   BIGINT        COMMENT '采纳人，绿区动作=智能体账号',
  created_at    DATETIME
)

三个字段特别说一下，都是踩过才加的。

evidence：智能体不是黑盒下命令，每条工单必须带"我依据什么"。改派单要能回答"为什么派给 Y 车队"——距离最近？载重匹配？还是规则库里某条配置。出争议时这个字段就是解释的来源。

result_check：执行完接口不能就信接口返回的"成功"。我们的做法是执行后隔两秒回读订单表，把库里真实状态存下来。有一次接口返回成功但事务最终没提交，靠回读发现的，工单状态停在 executed 没到 confirmed，兜底任务告警。

params_hash：采纳和执行是两个动作，中间可能有几秒到几分钟的间隔。hash 是防"采纳时看到的参数"和"执行时的参数"不一致——执行前重算 hash 对不上就拒绝执行、通知人工。这防的是我们自己：工单生成和执行是两个服务，中间如果有人改了参数（哪怕是我们自己内部的处理逻辑），都不该静默通过。

那次事故：口语歧义，批量改派

说回影子阶段埋下的那 4 次不一致。11 月正式放开黄区操作的第 9 天，调度在群里说：“张伟明天那批都改到下午。”

"张伟"匹配到了两个司机——一个张伟在车队 A，一个张伟刚从外协转正，档案里还挂着外协公司名下。智能体按相似度取了第一个，生成了 37 单的批量改派工单。值班调度那天忙，看工单列表只扫了眼订单号没看司机名，点了采纳。

第二天上午，37 单里 19 单装错时段，司机到了仓库装不了货。损失不算大——重新排了两小时——但教训很清楚：歧义实体的"确认"，不能指望人工在忙的时候认真看。

改法是把实体消歧做成硬规则：拟执行参数里的人名、车牌、仓库编号，凡是在主数据里匹配到多于一条的，工单直接不生成，回复一条"找到 2 个张伟：A 车队张伟 / 外协张伟，你要改哪个？"等对方回答了再生成。宁可多一轮对话，不把消歧塞进点采纳的那一眼里。

另外从这次之后，批量超过 10 单的操作，采纳页强制展示司机和时间段列，不允许折叠。这也是跟客户吵了一架才定的——他们嫌麻烦，我们说那 19 单你们也嫌麻烦，最后认了。

放量节奏，以及我们慢了三个月的事

原计划是黄区跑一个月就放开第二类操作，实际跑了三个月。不是技术问题，是客户内控提了要求：每次写操作都要留痕到他们的审计系统（他们是国企背景，每年有内审）。我们最后是靠 agent_action 表加了一个同步任务，操作状态每变一次推一条到他们审计中台，才算过了内控这一关。

回头看，这三个月的等待不算浪费。智能体操作类需求里，真正卡进度的往往不是模型能力，是"谁为这次操作负责"。工单表把责任链拆开了：智能体生成、人采纳、系统执行、回读确认，每一环有记录，审计和业务方才都睡得着。

现在的状态和还没解决的问题

到 2026 年年中，绿区动作智能体全自动，黄区采纳率稳定在 92%，夜间值班那名调度的改派操作量降了一半多。红区我们至今没放，短期也不打算放。

没解决的问题是规则库的维护。智能体改派依赖"3 吨以下就近车场"这类规则，规则是运营配的，但规则一多就开始打架（就近车场 vs 老客户指定车场，谁优先？）。现在靠规则上标优先级凑合，规则库已经 60 多条，快到人工维护不动的时候了。如果后面要上"规则冲突检测"，那是另一个工程，这篇文章先不展开。

一句话总结这半年：让智能体"能动"的技术方案其实不复杂——影子模式、分级、工单化、回读，真正花时间的是把每一环的责任和证据链钉死。模型那层，反而只花了两天。