把一张杯子的照片交给多模态模型，它可以准确描述陶瓷材质、圆形把手和常见用途。再让机器人把水倒进去，它却可能抓住杯口，或把杯子横过来。
最荒诞的情形是：它写出一份周密的倒水计划，然后把水稳定地倒在桌面上。
计划文档写得很好，桌子也湿得很均匀。
杯子只是一个思想实验。我在每天使用的公众号自动化中，遇到了同样的断层。
草稿保存的错误确认
旧链路在编辑器里点击“保存为草稿”后，固定等待 4 秒，再从页面地址读取 appmsgid。这个编号是公众号为草稿生成的真实标识，后续绑定封面、定位草稿都依赖它。
问题是，点击动作完成，不代表后台已经完成写入。保存后的页面重定向实际可能需要 5—15 秒。旧程序等到第 4 秒就读取地址，有时只能得到一个没有 appmsgid 的页面。此时至少有两种可能：后台仍在处理，或者后台已经拒绝写入。浏览器都没有报错，按钮也确实点过，但程序并不知道草稿是否存在。
这正是软件 Agent 最容易忽略的瞬间。它掌握的是“我执行了保存”的动作记录，不是“草稿已经进入后台”的世界状态。如果依据自己的操作日志继续运行，后续流程可能去绑定一个并不存在的草稿；如果把暂时没有编号直接判为失败，又可能在后台刚刚写入后再次保存，制造重复内容。
修复没有增加更长的提示词。我把流程改成先等待 5 秒，再轮询页面中的 appmsgid；仍然没有结果，就按标题回查草稿箱。只有两个位置都找不到 appmsgid，才确认本次保存失败。
改变看似很小：固定等待变成持续观察，点击结果变成后台证据。它却重新划定了“完成”的标准。
行动智能是否可靠，不看它怎样描述完成，而看它能否读回真实状态，并在结果不一致时修正。
从动作记录到状态回读
语言模型擅长预测下一个 token，行动系统却要面对下一个状态。下一 token 不等于下一状态。
杯子被抬起后，位置、姿态和液体会变化；接口被调用后，订单、余额、权限和草稿记录会变化。模型生成的“已完成”只是文字，外部系统发生的变化才是回执。
公众号保存链路由此自然长出一个最小闭环：“想—做—观察—校正”。先根据已知状态计划一次操作，再执行边界清楚的动作；随后读取页面、接口或数据库中的真实结果；观察与预测不一致时，更新状态，再决定等待、重试、补偿或交给人工处理。
这个闭环的关键在于，观察结果能够否决原计划。若系统无论读到什么都继续向下执行，所谓闭环仍然只是单向脚本。
因此，工具说明也不能只写函数名和参数。对于可能产生副作用的动作，系统至少要知道当前可观察什么、调用需要哪些前置条件、成功后哪些状态会改变，以及超时、部分成功和重复调用分别意味着什么。失败之后还要有明确的查询、撤销或补偿路径。
邮件发送、订单提交和删除操作都遵循同一逻辑。一次超时可能意味着请求没有送达，也可能意味着请求已经成功，只是回执丢失。可靠的 Agent 会先查询邮件 ID、订单号或资源状态，再决定是否重试，而不是把“没有看到成功”直接翻译成“再做一次”。
作者｜随机比特
