你在用AI，还是在伺候AI？

搭一套 AI 工作流，很容易走进一个循环：

出一次错，加一条规则；再出一次错，加一个检查；任务变多了，再派几个 Agent。

每一步看起来都合理。最后却发现，原本想省下来的时间，花在了维护这套流程上。

最近搭多平台内容管线时，这个问题变得很具体：文章已经写好了，浏览器一断，任务却又像要从头开始；按钮已经点过了，工具没有返回结果，就不知道该不该再点一次。

这些问题，未必需要一个更聪明的模型。有时，需要的是少一点混在一起的东西。

不是把所有东西都交给一个更强的 Agent

Anthropic 在一场 Managed Agents 工作坊里，分享过一次架构调整。

最初，他们把会话记录、控制模型工作的程序，以及模型执行代码的环境放在同一个容器里。这样做很直接，但容器一出问题，整个任务都会受到影响。

后来，他们把三件事拆开：工作记录独立保存，模型和控制程序负责决策，沙箱与工具负责执行。

对个人使用来说，不必照搬他们的云端基础设施。但其中的道理很好理解：浏览器是工具，不应该是唯一记得任务做到哪一步的地方。

文章已经确认，就应该留在正文文件里。图片已经做完，就应该能按顺序找到。某个平台发到了哪一步，也应该有自己的记录。

浏览器坏了，需要修的是浏览器，不是重新写一遍文章。

拆开职责的意义，不是把步骤变多，而是让一个地方出问题时，其他已经做好的东西还在。

这在发布内容时尤其重要。

点击发布以后，网络可能断，浏览器控制也可能超时。但平台可能已经收到了请求。

如果把工具报错直接理解成发布失败，再点一次，就可能重复发布。

所以这里要问的，不是“刚才那个调用成功了吗”，而是“平台上到底发生了什么”。

先去内容管理页查，再看账号主页和对应作品。确认没有发生，才考虑重试。

提交成功、后台已发布、读者能够公开访问，也不是同一件事。缺了哪一层证据，就保留哪一层不确定性，不需要把结果硬凑成一个“全部完成”。

可靠的自动化，不只是能不断往前跑，也包括不知道结果时，能够停下来查清楚。

工作坊还演示了另一种做法：先明确成果应该是什么样，再让一个使用独立上下文的检查者评估，不合格就继续修改。

这比只让执行者说“我完成了”更有帮助。但检查者仍然是模型，并不会因为换了一个角色，就自动变成事实。

“文章写得不错”很难验证；“原文里的关键限定有没有保留”，可以回到来源逐项核对。

“图片应该没问题”不够具体；“手机上能否读清、有没有截字、正文有没有漏段”，可以直接看产物。

“发布成功了”也不能只靠评分；需要打开对应页面，确认内容和链接。

能直接检查的事情，就直接检查。只有确实需要另一种视角时，再增加一个检查者，而不是每一步都安排一次模型互评。

视频里另一个容易被讲得很神奇的概念，是 Dreaming。

它做的事更接近整理笔记：回看多次任务的记录，合并重复内容，发现缺口，整理出可供后续任务使用的记忆。它不等于重新训练模型，也不保证整理之后一定更好。

这和不断往 skill 里加经验，是同一个问题：记住了很多，不代表每一条都还适用。

一次网页故障，不一定值得变成永久流程。一次高赞，也不能直接总结成通用的标题公式。旧模型需要的补丁，换了模型以后，也可能已经成了负担。

尤其要分清两种情况：规则里没有写，和规则已经写了、执行时却没有遵守。

如果是后者，再加一段意思相同的提醒，只会让文档更长，并没有修好真正的问题。

判断一次流程改动有没有用，不妨回到几件真实发生过的事。

已经确认的文章，还会不会被擅自重写？

发布超时以后，还会不会不查状态就重新提交？

只修改一个平台的封面，会不会把其他已经完成的平台也重新跑一遍？

这些旧问题有没有减少，比新增了多少条规则、多少个 Agent，更能说明工作流有没有进步。

这并不是说越简单越好。授权、隐私和不可逆操作的边界仍然需要保留。该省掉的，是没有证据证明有用的重复步骤，而不是必要的保护。

模型越来越强，我们应该有机会把一些架子拆掉，而不只是不断往上搭。

好的工作流，不是看起来像一个庞大的系统。

而是事情顺利时不打扰，出错时知道停在哪里，恢复时不用重来。