先判断你的流程属于哪一类
把控制流从提示词搬进代码确实能提成功率，但只对一部分任务成立。判据很简单：步骤固定、依赖清楚的流程可以编译；需要大量临场判断的开放式任务，编译完只会更难用。先分类，再动手。
- 可编译：步骤顺序固定，每一步都有明确的进入条件与完成判据
- 不该编译：走哪一步取决于内容本身，写死之后遇到新情况只能报错
- 边界情况：步骤固定但参数需要模型判断——这类只把「顺序」写进状态机，参数仍交给模型
找出真正在出问题的那几步
不要凭印象改。把最近几次失败的完整执行记录摊开，逐条标注失败类型：跳过了某步、顺序做反、参数用错，还是步骤没错但判断错了。分不清的不要硬归类，那部分留着继续观察。
- 按出现次数排序，先改高频的
- 检查每个高频出错步骤有没有明确的完成判据——没有判据的步骤被跳过是常态
- 检查上一步的结果有没有显式传给下一步，靠模型「记得」的传递一定会丢
论文给出的量化结果：在 4 个基准、4 种执行器上，平均成功率比 Skill + ReAct 高 16.1 个百分点；换用 Qwen3.8-27B 时执行 token 减少 38.4% 到 88.9%。
改完必须能回放验证
状态机最容易出的问题是「改了这头坏了那头」。做法是每次改动都先过静态检查，再把当前和之前所有已接受的执行记录重新回放一遍，全部通过才合入。没有历史记录就先补记录，否则你永远分不清「改好了」和「这次刚好没踩到」。
- 留一批固定的历史执行记录当回归集，不要每次换新样本
- 同时记录改动前后的成功率与 token 消耗两个指标，只看一个会误判
- 把「不许跳过某步」做成可拦截的前置条件，而不是写在提示词里的请求