Agent 老出错：什么时候该改流程，什么时候该改提示词

2026-08-25

派出去的一批活交回来了，你打开其中几份，发现不对。

这时候我的第一反应总是同一个：回去改任务书里的措辞。加一句「注意不要……」，把某条要求加粗，把语气写重一点。改完再跑一遍，有时候真的就好了，有时候改了一遍又一遍，还是同一个地方错。

我在自己这条内容产线上反复经历过后面这种情况。它最难受的地方不是修不好，而是你分不清自己修的方向对不对——每一轮都要等一批跑完才知道，而每一轮都得把整批重来一遍。后来我逼自己在动手改之前先问两个问题，才把这件事从「碰运气」变成「有个说法」。

这篇写的就是这两个问题，以及它们什么时候不管用。

动手之前，先确认失败是真的

有一类「失败」根本不是失败。

我这条流水线上遇到过：编排层的汇总报告写着「0 完成」，我去磁盘上一看，文件已经好好躺在那儿了；也遇到过反方向的——汇总报着「已完成」，磁盘上什么都没有。两个方向都会发生。

所以我现在的第一步是回磁盘数文件，而不是看汇总。汇总层的状态不是事实，产物才是事实。

这一步不能省，因为它决定了你接下来判断的样本是真的还是假的。如果一半的「失败」其实是汇报错位，你后面无论怎么统计失败位置，得到的图都是花的，什么结论都推不出来。

还有一种情况也要先排掉：文件出现了，但代理还在继续改它。文件首次落盘不等于写完了。我踩过的处置是——只认任务系统给出的完成通知，不认「文件已经存在」这个观察。异步任务的完成信号必须来自任务系统，不能来自对产物的旁观。

确认了失败清单是真的，再往下走。

两个问题：能不能重现，是不是压在同一步

第一个问题：同一份任务书原样重跑一次，同一个地方还会错吗？

原样，指的是一个字都不改。我自己在这一步就常常忍不住先动手，重跑的其实是改过的版本，于是永远得不到对照。

第二个问题：把这一批所有失败的位置在工序上标一遍，是散在各处，还是压在同一处？

这两个问题交叉起来，我的用法是这样的：

散在各处、而且重跑不重现 —— 我按表达层的问题处理，也就是改措辞、补例子、把含糊的要求写具体。这类失败更像是每一次生成的随机波动，工序本身没有拦住它的位置。
反复命中同一步骤、而且重跑还重现 —— 这是工序的问题。这种情况下改提示词基本是白费力气，因为执行者不是没看懂，是这一步的输入、约束或者退路本身就有毛病。你把要求写得再重，它到那一步还是只能这么干。

第二类里最容易骗人的地方在于：失败表现出来的样子往往是「文字质量不行」，看上去特别像一个措辞问题。而它其实是上游给的条件不成立。

三个具体的落点

第一个，是我给下游的一条长度约束。

我曾经给标题定过一个字数上限，忘了扣掉标题里必须逐字包含的关键词本身占掉的长度。结果就是执行者只剩很小的余地，为了满足上限，它只能把关键搜索词砍掉。

这件事完全符合上面两条：重跑重现，而且全部压在「优化标题」这一步。我当时如果去改措辞——比如加一句「不许删除关键词」——它只会陷入两条互相冲突的硬要求里。真正的修法是把配额放宽，也就是先减掉不可压缩的固定部分，再给剩下的额度。

配额型的约束都有这个陷阱：你以为你给的是余量，实际给的是余量减去固定开销。

第二个，是把「回到哪一步」显式写进流程。

我那个写公众号文章的 Agent，流程图里有四条回退边，逐字是：V1 → U（正文没达到真人感要求，退回撰写正文）、S → I（核心依据核验不过，退回评估选题价值）、N1 → N（提纲没通过删除测试，退回生成提纲）、X1 → W（标题的承诺在正文里没有支撑，退回优化标题）。

这四条边里我想强调的是：失败发生的位置和应该退回的位置，是两件不同的事。

看第二条。核验不过是在「检索和核验资料」这一步发现的，但退回的目标是「评估选题价值」——因为核心依据拿不到，说明这个选题的角度就不该这么定，退回去重写资料检索是没有意义的。同理，标题的承诺没有正文支撑，是在校验环节发现的，退回的却是标题优化本身。

这就是「集中在同一步」这个判据的用处：它告诉你要动工序，但动哪一步得单独想。哪一步反复出问题，和哪一步是根子，经常不是同一步。

顺带说一个我需要说清的边界：这四条回退边里，没有任何一条以「确认写作方向」为退回目标。方向那一处是人工确认的位置，也是产出物形态发生变化的位置，但我没有把它做成回退目标的记录。至于当初为什么没做，我手上没有留下记录，就不往回编了。

第三个，是改完之后必须回写。

我的规格文档在版本历史里被反复修订过，每一次修订都对应一次真实的翻车：某个字段该怎么取舍、面向的读者是谁、通用约束抽到哪里去。我现在把给 Agent 的任务书当代码维护——有版本、有修订理由，每一条约束背后都对应一次实际失败。

从零把规格想全是不可能的。但每次翻车必须回写进规格，否则同一个坑会踩第二次，而且第二次你还是会先去改措辞。

这件事还有一个附带收益是我没预料到的：把共性约束抽成一份独立的简报之后，每次派活的提示可以大幅精简。单次任务只描述差异。这反过来又压缩了「在提示词里反复加补丁」的空间——共性的东西不在提示词里，你想在那儿改也改不着。

什么情况下这两个判据不管用

这一段不能省，因为我自己被它坑过。

第一，样本太少的时候判不出来。 只跑过一两次，「是不是集中在同一步」这个问题根本没有统计意义。这时候我的做法是先原样多跑几次把样本补上，而不是急着动工序——动了之后你连对照都没有了。补样本的方式我后来也改过：不按成功跑了多少次去累计，而是按会出岔子的分支去凑——链接读不到、素材之间互相打架、外部能力临时挂掉，每种都撞一次，才看得出失败到底压在哪儿。只按顺利跑完的次数攒样本，攒得再多，也只是把同一条正常路径走了很多遍。

第二，失败其实出在检查环节自己身上。 我遇到过一次机械检查，首轮报出来的问题全部是误报：命中的是模板自带的合规声明、规范里强制要求写的否定句、以及代码示例里的数字。这些「失败」高度集中在同一类位置上，完全符合第二条判据的形状，但要改的既不是工序也不是提示词，是检查器的判据宽窄。

这类情况的识别方法是：先把命中的每一条拿去看上下文，确认它到底是不是真的错了，再决定改什么。误报的代价不是多花时间，是让执行者开始整体忽略这道门——门一旦被忽略，就等于不存在。

顺着这条还有一句：脚本能查字数、死链、格式、孤儿页，查不出事实错误。客观体检和事实级复核不能互相替代，别把「脚本全绿」当成「查过了」。

第三，问题出在素材源本身。 我这条线上发生过：评审阶段发现事实卡里某个数值有误，导致已经写好的好几篇同时出错。表面上看，这是最标准的「集中在同一步」——全部错在引用那个数值的位置。但改工序没用，改提示词更没用，得回去改卡，并且把整批已经写完的都重新检查一遍。

所以第二条判据成立之后，还要再往上追一层：这一步的输入是不是错的。如果输入错了，工序再顺也只是把错误更整齐地复制出去。

第四，并发导致的失败不在这套判据的适用范围里。 多个会话同时在一个仓库里干活时，构建会崩在别人写到一半的文件上，共享的输出目录会互相覆盖。这类失败看起来随机、重跑还未必重现，很容易被归到第一类去改措辞，但它跟任务书一点关系都没有。我这条产线上的处置是把有副作用的动作收归单点串行，各自的输出目录隔离开。

判据不是万能钥匙。它的价值是在你伸手去改措辞之前，先拦你一下，问一句：你确定错的是它的表达，不是你给它的路吗？

这篇的判据来自我自己带 Agent 干活的实践，样本有限。它更像一份可以拿去验证的假设，而不是一份可以照抄的规范。