上个月帮朋友看他团队搭的一套流程。任务不复杂：每天早上把几封邮件里的需求整理进表格。他们在中间接了一个 AI Agent，头两天跑得挺顺，第三天表格里多出一行不存在的项目，来源是一封两周前的旧邮件。没人让它去翻旧邮件，它自己翻的。
这不太像普通的 bug。它更像一个提示：我们对这类系统的预期，和它实际的运转方式之间，还隔着一段没对齐的地方。
它不是在回答问题，是在补空
一问一答的模型，输入一段话，输出一段话，边界清楚。加上循环之后，事情就变了：先看当前状态，再决定下一步，调用一个工具，看返回结果，然后决定要不要再来一轮。这个循环是它能处理多步任务的原因，也是它开始自作主张的原因。
你给的目标是“整理需求”，它把这句话展开成“找到所有可能是需求的材料”。旧邮件在它的检索范围里，于是被捞了进来。它没有违背指令，它是在把指令里的空白填上。填得对不对，取决于范围怎么划，而不取决于它有多聪明。
能碰什么，决定了会错成什么样
评估阶段容易只测一件事：它能不能把活干完。但权限不同，失败的形态完全不同。
- 只能读：错了通常表现为结论不准，人扫一眼能看出来。
- 能写但可回滚：需要有固定的时点去核对改动，错了能退回去。
- 能对外发消息、发请求：错误会被外部放大，收不回来。
所以在真实业务里，我会先问一句：这个动作如果做错了，多久能发现，能不能撤回。答不上来，就先别放开那个权限。
验收比派活难
传统程序的行为是确定的，同样的输入给同样的输出，测试可以写成断言。这类系统带着随机性，同一句话问两遍，可能走两条不同的路。验收的方式就得跟着换：不是逐条比对结果，而是看过程能不能追溯——调用了什么、依据是什么、在哪一步改了主意。
我在项目里比较看重日志，原因很实际：答案对了但过程说不清，下次不一定还对；过程清楚，这次错了也能定位到是哪一步。
留一个检查点，不是能力不够
有些团队把“人在环里”当成过渡方案，等模型再强一点就撤掉。我不太认同。检查点的位置本身就是设计的一部分：付款前停一下，对外发送前停一下，删除前停一下。这些停顿不是因为不信任技术，而是因为有些错误的代价不对称——做对许多次的收益，抵不上做错一次的损失。
把范围划小、让动作可逆、把过程留下来，这三件事做完，一个 AI Agent 才可能在真实业务里待住。至于它能做多少事，那是后面慢慢试出来的，不适合在一开始就写进承诺。