Reddit上那篇"买了40头大蒜"的OpenClaw帖子，笑点只持续10秒。然后你会发现，这是生产环境中代理工作流失效最清晰的案例之一。
一名用户让购物代理每周自动运行，持续了3个月。绑定了支付卡，一切正常。直到某次运行，代理在商品页面选错了计量单位，购物车最终塞进了约2公斤大蒜。
这不是"AI叛变"的故事。这是工作流设计的故事。
核心问题甚至不是大蒜本身。而是连续三个月的成功，让人类养成了不再仔细核对的习惯。一旦代理从"辅助工具"变成"交易执行者"，这种模式就会反复出现。
真正崩坏的不是幻觉，不是模型造反，也不是什么戏剧性的技术故障。是一个单位错配。
大多数 grocery 界面本身就很容易踩坑：按个卖还是按重量卖、奇怪的默认设置、零售商特有的数量选择器、长得差不多的商品变体。如果工作流要的是"2头大蒜"，而页面默认是"2公斤"，代理从自己的逻辑出发，依然能"正确"完成任务。
这就是人们在讨论代理可靠性时经常忽略的一点：很多失败不是推理失败，是边界失败。
真正的bug是信任。三个月的成功运行足以在脑子里重新分类一项自动化。它从"我得仔细审一遍"变成"那个工作流一直很稳"。这个心理切换，就是昂贵bug的温床。
如果你在用OpenClaw、n8n、Make、Zapier或自研代理栈，这场景应该很眼熟。前50次成功运行，不能证明第51次安全。它们通常只是说服你不再去看。
帖子里最到位的回复来自一位自建H-E-B工作流的用户。他的设计是：拉取每周食谱、提取食材、加入购物车，然后在结账前停下。理由是：支付环节我也可以自动化，但我宁愿审一遍，免得大蒜买成吨。
这才是正确的设计。让代理干烦人的活，别让代理把界面误操作悄悄变成真金白银的扣款。
关键的设计问题是：你在哪里强制人工审核？对大多数生产工作流来说，"付款前审核"完胜。不是因为OpenClaw不行，不是因为GPT-5或Claude Opus不行。而是因为结账是一个承诺边界。一旦钱动了，可靠性标准就变了。
这条规则不止适用于买菜：
采购订单、发票生成、CRM更新、仓库操作、服务器变更、客户邮件——只要工作流从"起草"跨入"提交"，就在那里设一道闸门。
这本质上不是大模型智能问题。人们总爱问GPT-5、Claude Opus、Qwen或Llama哪个更聪明，但单位错配不会因为你换了个更贵的模型就消失。
热门跟贴