模型能力越强，你给 Agent 设的流程护栏就越像绊脚绳

最近在复盘一次编码 Agent 的“拒批事故”时，我意识到一个很诡异的现象：随着模型能力的迭代，原本为了保证质量而设计的 Agent 工作流，反而成了导致任务失败的元凶。简单来说，模型越可靠，它就越能精准地执行那些“死板”的流程指令，从而在细节上把事情搞砸。

这次事故的起因极其低级。我的编码 Agent 拿到了一份已经通过审核的实施计划，文档里清晰地写着 ## WorkPlan Review - Status: approved (2026-08-02)。任何人类开发者看一眼就知道这活儿能开工了，模型也确实看懂了这行字，但它在执行时却直接触发了“拒批”逻辑。原因竟然是因为我的工作流模板里定义的字段名是 Implementation Approval.Status，模型发现文档里的标签和模板对不上，于是判定为“未获审批”，直接停工。

这套工作流是我花了好几个月时间一点点堆出来的。为了防止模型翻车，我设置了极其严苛的状态字段、交接契约、评审门禁和重试规则。在模型能力较弱的阶段，这些护栏起到了正向作用，因为那时候模型容易“走着走着就丢了目标”。但现在模型不丢目标了，反而被我的流程给“丢”了。

我意识到自己之前混淆了两种完全不同的约束：边界约束和工作生成约束。

边界约束是用来压缩解空间的，它告诉 Agent 绝对不能越过哪条线。比如：公共 API 契约绝对不能变动、未经授权禁止执行不可逆的外部操作、非目标需求严禁进入实现范围。这种约束是刚性的，无论模型多强，都应该严格遵守。

而工作生成约束则是给 Agent “找活干”的清单。比如：每个功能必须配套产出单元测试和集成测试、每个风险点必须对应负责人和回滚方案、某个可选字段如果缺失就必须停下来询问。

这两种约束在形式上很像，但在执行逻辑上完全不同。当模型能力提升到一定程度后，它会将“工作生成约束”直接当成必须完成的“待办需求”。这意味着，如果你在流程里写得太细，模型会以极高的可靠性去产出那些多余的工件、抽象层或停止条件。如果你的流程设计得过于死板，模型强到能 100% 执行指令时，“执行力”本身就成了一个风险放大器。

这让我想到了 FixedBench 在 2026 年 5 月做过的一次测试。他们用五个主流模型跑了 200 个已被修复的 issue，结果发现 35%-65% 的案例中，Agent 依然做了多余的改动。虽然这在当时被视为一种“行动偏差”，但在现在的环境下，这种偏差其实是模型在过度执行那些不必要的流程指令。

现在的 Agent 已经进入了一个新阶段。根据 Anthropic 对 40 万次编码会话的分析，分工已经发生了偏移：人类在做规划决策，而 Agent 在做执行决策。这意味着，如果我们在执行层的流程中塞入了过多的“提醒式”字段，其实是在用一种低效的方式干扰一个已经具备高执行力的 Agent。

这次复盘给我最大的启发是：在设计 Agent 工作流时，必须区分“证据”和“路径”。你应该对边界和证据保持绝对严格，但对路径中间的执行过程保持灵活。

下次在写 Prompt 或设计工作流时，建议问自己一个问题：我的 Agent 是否已经强到不再需要这些冗余字段来提醒它怎么干活？如果答案是肯定的，那么请立刻删掉那些所谓的“流程护栏”，否则你只是在给一个高效的执行者制造障碍。