见过一个内部工具：让 AI Agent 读工单、归类、起草回复，然后把结果放进待审队列。演示时很顺，几步连着走完；上线三个月，使用率停在最初那个数字。原因不复杂——最后一步永远需要有人点“确认”。点一次不费事，点一百次就成了负担，于是它退化成“帮我写个初稿”的输入框。
这个细节比大多数讨论都更接近问题本身。模型能不能完成任务，和任务能不能被交付出去，是两件事。
确认框是怎么长出来的
没人一开始就想加确认。加，是因为出过事：一封措辞不对的邮件发了出去，一条本该退回的工单被关掉，一个字段填错导致下游对不上账。这些错误的共同点是，收拾起来比重新做一遍还费时间。
于是团队做了一个理性选择：把不可逆的动作挡在人后面。挡完之后，自动化就只剩前半段。这不是技术退步，而是成本核算——当出错后的修复成本高于人工复核成本，确认框就是划算的。
所以要问的不是“怎么让它更聪明”，而是“怎么让它的动作变得便宜地错”。可撤销、可抽样检查、出错只影响一小块，这些条件具备了，确认框才敢拆。
它和把流程写死有什么不同
传统自动化把分支穷举出来，路径是确定的，异常交给人工。AI Agent 的差别在于，下一步由它自己判断。这让它能够应对没被写进规则的情况，也把不确定性带了进来。
运营岗位的人通常不太关心模型多强，关心的是另一组问题：它为什么这么做？出了偏差能定位到哪一步？能不能只撤掉那一个动作，而不是把整条流程回滚？这些问题的答案，决定了它被当作同事还是被当作一个不太可靠的插件。
把黑箱感压下去的三处工程
观察那些跑得比较稳的实现，通常在三个地方做了额外工作，且都不是模型层面的：
- 调用留痕。输入、用到的工具、参数、返回结果都记下来。不只是为了调试，更是出事时能划清影响范围。
- 动作切分。把长链拆成可撤销的小单元，每个单元有明确的边界和副作用说明，避免一次性提交一大坨改动。
- 随时可中断。人在中途看见不对能立刻叫停，而不是等它跑完再看结果。
这些事听起来不性感，但它们直接决定了人愿不愿意把确认框去掉。反过来，如果这些都没有，再强的推理能力也只能停在草稿阶段。
有些活暂时不该交出去
也有必要说清楚不适用的部分。错误代价高且不可逆的场景，规则本身没想明白的场景，以及没有人愿意为结果负责的场景，把 AI Agent 放进去往往只是把责任摊薄，而不是把事做完。判断标准其实朴素：结果能不能被快速验证，错了能不能只影响局部。
所以推进顺序也许应该反过来。不是先挑最复杂的任务来证明能力，而是先找那些重复、可核对、错了也容易收拾的环节，让它在低风险区跑出稳定记录，再一点点把人的复核频率降下来。
回到开头那个工具。真正需要回答的问题不是“这个 agent 能不能做”，而是“哪一步交给它之后，人不必再回头看一眼”。找到那个点，自动化才算开始；找不到，它就只是一个更贵的输入法。