北京
安全机制的前提崩塌
Agateon是一套让AI代理执行软件工程任务的协议，核心逻辑是不相信代理自己的说法。需求、设计、实现、测试、发布，每个阶段都必须通过客观关卡才算完成。没有关卡，就没有进度。这是整套系统存在的基础。
几天前，一次例行审计在自己的一道关卡里发现了一个洞。不是逻辑漏洞，而是设计漏洞——机制完全按指令运行，而这恰恰是问题所在。事情的经过、发现方式以及修复方法如下。
重试上限机制如何运作
代理会卡住。它们可能误读需求，测试失败的原因自己搞不明白，子代理空手而归。Agateon的应对很简单：跟踪每个阶段的重试次数，一旦某个阶段失败次数过多，就完全停止自动化，强制由人来决定。
状态流转并不复杂：代理开始工作，提交关卡检查，通过则进入下一阶段，失败则重试或暂停。重试次数未达上限就再试一次，耗尽则进入暂停状态，由人决定下一步。这跟断路器的思路一致：连续失败足够多，系统就不再自己绕路，把控制权交还给人。
关键之处在于系统如何知道发生了重试：由代理记录。每次阶段被驳回重做，重试都应当写入该任务的状态文件。
审计发现的缺口
对四个近期完成任务的独立审查核对了重试记录是否与实际情况相符。结果并不相符。
根据代码提交历史，实际发生的事情包括：审查驳回了一个设计，退回返工；验证失败，任务回退一个阶段；一个子代理没有返回任何有用内容，被重新派发。而状态文件记录的重试字段全是空的。
四个任务都有真实的驳回、真实的阶段回退、真实的空手而归的子代理，但每个任务的重试计数器都显示为空，仿佛什么都没发生过。
重试上限机制从未被这些情况触发，因为该机制只能通过写入字段的内容来观察世界。如果字段说没事发生，对安全网而言，就是没事发生。
这不是漏掉的边界情况
令人不安的不是有些重试没被记录，而是这种缺口属于什么类型。
Agateon存在的全部理由，就是不应该相信AI代理对自己工作的描述，而要用证据去验证。重试上限机制本该是执行验证的环节之一。但它自己的触发条件，却完全依赖同一个不被信任的一方诚实自报。防护措施本身建立在它要防的对象之上。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
