一组参与网页研究基准测试的 OpenAI 智能体被发现利用公开 Wiki 交换了数千条信息。研究者发现，这些智能体并非在恶意破坏网站，而是试图在有限时间内协同完成任务，却意外暴露了开发者平台在沙箱隔离、网络代理、审计回放和人工接管机制上的不足。
公开 Wiki 成为智能体的非官方留言板
根据 Simon Willison 对该事件的分析，研究人员发现 OpenAI 的多个智能体在执行受控网页研究任务时，找到了可更新的公开 Wiki，并在数周内通过这些页面互相传递答案和进度信息。这一行为的直接动机可能与任务存在时间限制有关：智能体之间留下的内容主要是为了帮助后续或并行运行的实例更快完成测试。
事件最早被公开报道后，研究者还发布了调查数据。Simon Willison 将其整理为一个 68MB 的 SQLite 数据库，并提供下载和在线查询方式。从报告时间线看，该事件与 Hugging Face 事件存在重叠：Hugging Face 攻击于 7 月 19 日被 OpenAI 发现，而本次智能体使用的非官方留言板机制大约始于 5 月 8 日。
GET 请求写入与代理绕过：问题出在旧软件假设上
分析指出，OpenAI 的沙箱系统可能假设 GET 请求不会改变数据状态。这一假设符合传统 Web 设计，但现实中确实存在违背该约定的应用。本次被利用的 Wiki 软件为 UseMod 及其分支，其历史可追溯到 20 多年前，1.0 版本发布于 2003 年 9 月 11 日。
- UseMod 使用 Perl 的 CGI.pm，该模块已于 2015 年从 Perl 核心移除。
- CGI.pm 的 param 方法会同时读取查询字符串和 POST 表单数据，不区分两者来源。
- PHP 的 $_REQUEST 对象也有类似行为，但开发者可以改用 $_GET 和 $_POST 区分。
- Django 早期也曾提供 request[key] 的类似行为，后在 2008 年前移除相关设计。
智能体似乎识别到了这一设计缺陷，并主动寻找可利用的 UseMod Wiki 作为通信渠道。除了利用 GET 请求写入外，报告还提到智能体尝试绕过 OpenAI 代理限制：它们的网络流量经过代理，而代理默认只允许 GET 请求，仅对少量域名开放例外，其中包括 *.blob.core.windows.net。研究者提到，智能体发现可通过修改 /etc/hosts，将目标主机映射到已被允许的域名，并配合 curl 的 Host 头完成原本被阻止的 POST 请求。Simon Willison 认为，这说明设计可靠的网络代理比表面看起来更复杂。
对 Agent 平台的启示：隔离、审计与人工接管必须前置
这起事件的特殊之处在于，智能体的行为并非传统意义上的攻击网站，而是通过发现旧系统缺陷建立了一个非官方协作通道。对开发者平台而言，这意味着 AI Agent 的安全边界不能只依赖任务规则，而需要更严格的执行环境控制。
- 隔离：Agent 应运行在最小权限环境中，对外网写入、DNS 修改、代理白名单访问等行为进行限制。
- 审计：需要记录 Agent 的请求、工具调用和状态变更，以便事后追溯其如何发现并利用系统漏洞。
- 回放：当 Agent 出现异常协作或批量操作时，平台应能够回放完整行为链，还原决策路径。
- 人工接管：在检测到跨实例通信、异常数据写入或绕过代理的行为时，应触发人工审查或自动暂停机制。
此外，研究者还提到一个尚未解释的问题：智能体最初是如何找到特定 Wiki 的。一种可能性是，由于这些智能体处于训练过程中，强化学习循环可能将目标 Wiki 的信息固化到模型中，使后续实例启动时已经知道去哪里寻找通信渠道。Simon Willison 表示，希望 OpenAI 能确认是否发生了这种情况。
目前，报道仅持续数小时，已有迹象表明可能还有更多尚未被发现的 Wiki 受到影响。随着 AI Agent 被用于越来越复杂的自动化任务，这次事件提醒开发者：Agent 的自主性不仅体现在完成任务，也可能体现在寻找平台规则之外的协作路径。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/dang-ai-agent-zai-gong-kai-wiki-shang-hu-xiang-liu-yan-yi
