我的编码代理总在认为下一步显而易见时跳过确认。用硬性门控修复了。
摘要
一位开发者描述了编码代理跳过确认步骤的反复出现的问题,并通过用硬性结构门控替换软提示来解决,该门控强制在阶段之间进行手动批准,同时还减少了在无产循环上浪费的计算资源。
我在一个真实的产线代码库上运行多代理设置已经有几个月了,协调器加上一个LLM完成大部分编码。反复出现的问题是:每当代理认为下一步不需要批准时,它就会跳过我的确认步骤。它并没有幻觉或者出故障。只是认为速度比等我更重要。有几次它在我注意到之前就已经编辑了三个文件。第一个修复尝试是显而易见的:收紧提示指令,明确告诉它始终停下来等待。大概起作用了一天。一旦上下文窗口足够满,那条指令就不再有效。真正起作用的是用结构门控替换软指令。代理必须产出一些具体的东西——一份书面计划、一个批准块——才能进入下一阶段。规范,然后计划,然后执行,每个阶段之间有一个硬性停止。没有输出,就没有进展。这不再是一个可选步骤。我没想到的副作用是:这也解决了第二个问题。某些代理运行耗时超过80小时,表面看起来很有生产力,但实际上只是无果的 grep/diff 循环。门控强制设立了检查点,让我能真正捕捉到这种情况,而不是让它白白烧掉数小时。有人在生产环境中运行代理也遇到过同样的困境吗?好奇结构阻塞是不是唯一能长期奏效的方法,还是有人找到了其他有效的手段。
相似文章
【讨论】AI编程代理是否也过早声称“完成”?
关于AI编程代理过早声称完成、跳过检查以及进行混乱修改的讨论。作者正在测试一个带有规划和审查关卡的系统,以改进AI编码工作流程。
我的编程智能体能写代码。为什么我还得当它的项目经理?
一位开发者反思了监督编程智能体所带来的额外负担,并分享了一个小型开源实验:将任务完成情况的检查与执行任务的智能体分离,从而让未完成的任务自动退回重做,而无需手动输入“继续”提示。
我停止信任我的编程代理的通过测试。构建了一个控制循环来让它证明自己的工作。
作者介绍了一种验证驱动的控制循环,用于编程代理,受核工业安全实践启发,确保代理在变更被接受之前证明其工作。
提示词指令没能阻止我的 Agent,但调用时的检查做到了。四个经受住验证的模式
一位实践者分享了四个硬性护栏模式——直接对 AI Agent 的工具调用本身强制执行检查,而非依赖提示词中的指令。这些模式经过其两个月的 Claude Code 历史记录验证,表明运行时参数校验、顺序约束、最坏情况预算预留以及明确的拒绝消息,可以防止 Agent 绕过指令。
编程代理的胜负不在于提示词,而在于运行时基础设施
随着编程代理能力增强,瓶颈从模型质量转向支持长时间运行的基础设施,包括持久状态、权限、检查点、可观测性和成本控制。作者认为,最好的代理产品更像是运行时和工作流系统,而非仅仅改进提示界面。