第一期:当 AI 开始做事 · 谁来管住执行过程

结果看起来完整，过程却断了——怎么办？

这个项目的起点，其实是年初的一件烦心事。

那天我用命令行跑一个多步骤的 Agent 任务，中途一不小心把终端窗口关了——整个会话记录瞬间蒸发。上下文没了，进度没了，Agent 做到哪一步更没人知道。重开一个会话，只能从头再来：重新收集材料、重新分析，之前烧掉的 Token 全部白烧。

烦完之后我开始想：能不能写这么一个东西，把执行历史独立于会话记下来？窗口关了记录还在，重开后能直接查进度、从断点继续；某一步做砸了，还能跳回那一步重新生成，而不是整个任务推倒重来。

顺着这个想法往下想，又撞上了第二个关切：安全。Agent 在执行过程中会调用各种资料、访问各种服务，但我作为使用者，只能在它主动展示的部分里看到一鳞半爪——它到底读了哪些文件？调了哪些接口？有没有把什么东西悄悄传到了云端？这些信息散落在上下文里，随着会话一起消失，事后想查都没有地方查。

上一篇《AI减速之争：谁喊停，谁踩油门》聊的是行业层面的刹车：模型能力冲得这么快，要不要有人踩一脚。这次把镜头拉近到你我桌面上的一个具体任务——假设 Agent 要完成「收集材料 → 分析 → 复核 → 出具报告」四步工作，它交上来一份格式漂亮的报告，你却没有任何证据判断：中间那步「复核」，它真的做了吗？

这就是这篇文章想讨论的问题：当 AI 从「回答问题」走向「执行流程」，仅保存最终答案，还够不够？

先讲清楚风险到底是什么。用对话式的方式让 Agent 做多步任务，你可能遇到过这几种情况：

注意，这里讨论的只是流程层面的问题：步骤做没做、顺序对不对、进度在哪。至于最终内容在专业上对不对——报告里的数字算得准不准、结论专不专业——那是另一层验证，本文的工具也管不了，后面第四节我会专门把这条边界划出来。

为了回答开头那个问题，我写了一个小工具： workflow-sm ——一个基于 MCP 的有状态工作流控制器。一句话解释它的分工：

• 你用 YAML 文件定义流程有哪些步骤、什么顺序、哪些可以并行；
• Agent 在执行过程中通过 MCP 调用它：先问「当前该做哪步」，做完再「提交这一步的结果」；
• workflow-sm 在服务端维护每一次运行的实时状态，并负责把关——Agent 想报告一个尚未激活、已经完成、或者根本不存在的步骤，会被直接拒绝。

FLOW

workflow-sm 执行循环

关键区别：状态不在 Agent 的上下文里，而在服务端。Agent 哪怕「忘了」，流程记录也在；Agent 想「抢跑」，校验会拦住它。

与其堆功能名称，不如用一个贯穿的演示来说话。我给 Agent 布置了一个四步任务（收集材料 → 分析 → 复核 → 报告），过程中故意做了三件事：

围绕这个演示，目前具备的能力可以归纳为：

这一节其实是全文最重要的部分。把项目说得天花乱坠很容易，把边界讲清楚才有价值。

我想的解法是做一个 Runner——由程序领取步骤、调用 Agent 执行、再自动提交结果，把「汇报」从 Agent 的自觉变成程序的责任。这个实验的下场如何，下一篇文章见分晓。

在它后面还排着几个问题：多客户端（Claude、Codex、ZCode）体验是否一致；这些记录能否从「复盘材料」变成「可核验的证据」；以及最根本的——谁真的需要它。都会在后续文章里逐个验证。

另外，无论验证哪一项，我都会同时记录执行耗时和 Token 消耗。流程控制不是免费的，多一次校验就多一轮交互；收益和成本的账，每一期都算给读者看。

这一篇先到这里——工具是什么、能拦住什么、拦不住什么，都说清楚了。接下来的每一篇，我都会带着一个具体问题去实验，把结果（包括失败）原样写出来。先从最简单的问题开始：

YOUR STORY

欢迎在评论区讲讲你的经历，最好带上具体场景。你留下的每个案例，都可能成为这个系列后面某一期实验的素材。

如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见。

评论区聊聊：你的 Agent 跳过哪一步？

THANKS FOR READING