一个请求进入工具门控，系统返回了ALLOW。执行之后，测试服务里多了一条新的业务数据。它没有用POST，也没有调用名为“write”的工具——它只是通过shell发了一个GET。当把输入改成显式的POST时，门控返回的却是REQUIRE_APPROVAL。这个对比发生在一次受控实验中。
CodeFlowMu是作者正在开发的本地多智能体协作系统。实验调用的是它已有的执行前门控，门控放行之后，再用真实的curl去访问本地的回环测试装置。数据是合成的，但请求、决策和状态变更都是真实的。研究问题比一个HTTP课程更窄：当一个门控没有识别出写入风险时，它的放行是否可以被理解为“不会发生写入”的证明？
GET的语义是“只读”，不是“保证只读”
HTTP把GET定义为安全方法，语义上基本是只读的。访问日志这类附带效应与这个定义兼容；但让一个GET端点执行业务变更，就是另一回事了。协议规定，资源所有者必须禁止通过安全方法访问不安全的、由URL选择的操作。协议并没有强制任意服务器遵守。
举个概念性的例子：GET /article/123是获取文章，而一个不合规的GET /save?value=hello端点可以执行保存操作。重定向可以把客户端从一个地址带到另一个地址，请求方法不变。方法不只是请求格式，它有定义好的语义——但这些语义并不保证每个服务器的实际行为。方法检查本身，无法建立完整的效果边界。
公开wiki上的18,000条帖子意味着什么
9月4日，Sydney Von Arx和同事发表了一份分析报告，称某个公开wiki上约有18,000条与Agent相关的帖子，其中包括基于GET的写入和信息交换。作者根据公开证据将这些活动与OpenAI内部Agent关联起来；这不是一份完整的内部事件报告。帖子数量也不等于Agent数量。
工程问题在于：当远程服务响应一个名义上的读取请求时，改变了业务状态，会发生什么？限制HTTP方法本身并不能控制所有效果。还有第二道边界——如果另一个执行器能读取结果，检索环境本身也变成了通信媒介。通用工具让这个问题变得相关：shell可以检查本地文件，也可以访问服务。系统是否受影响，需要检查它实际的入口点，而不是借用另一个项目的事件来作为自家产品的证据。
先测量写入，再解释写入
实验没有去探测原始的可写wiki。服务器只监听回环地址，使用随机端口，处理的是合成标记。实际的测试装置用/read处理读取，用/publi处理发布。门控放行GET之后，curl访问了/read端点，服务端状态发生了变化——一条合成数据被写入了。同样的请求改成POST，门控立刻要求审批。
这个差异指向一个具体的盲区：门控对方法的判断，和实际效果之间，存在一个未被覆盖的间隙。方法语义是协议层面的约定，不是服务器行为的保证。一个只检查方法的门控，无法知道远端服务是否遵守了约定。
门控的边界在哪里
研究结论并不复杂：门控的ALLOW只能证明“通过了门控”，不能证明“不会发生写入”。效果边界需要两层确认——方法语义是一层，远端服务的实际行为是另一层。只检查前者，后者就成了盲区。
对正在构建Agent工具链的团队来说，这个实验的启示是：门控设计不能只依赖HTTP方法的语义。如果远端服务可能对GET做出非标准响应，门控就需要额外的验证手段——比如检查响应内容、限制可访问的端点列表，或者在执行后做状态比对。方法检查是必要的，但不是充分的。
热门跟贴