你正在用 Codex 的 Multi-Agent 功能做一件复杂的事：父 Agent 负责整体规划，派生子 Agent 去执行具体的代码修改。一切运行正常，子 Agent 完成任务后返回结果。

然后你打开 Rollout 历史，想看看当时给子 Agent 下达了什么具体指令。你看到的是一串 <ciphertext>。

这就是 Codex 社区正在经历的真实困境。一个本意是增强安全性的改动，却意外地让多智能体系统变成了开发者无法审计的「黑箱」。

发生了什么？#

2026 年 6 月 5 日，OpenAI 合并了 PR #26210：「加密多智能体 V2 消息负载」。这个改动的动机很清晰：在多智能体通信链路中，父 Agent 发出的任务文本原本以明文形式存储在历史记录、Rollout 和遥测数据中。加密之后，这些消息在 Agent 之间传递时只有加密后的密文，接收端通过 OpenAI 的 API 内部解密后交给目标模型。

改动范围包括三个核心操作：spawn_agent（派生子 Agent）、send_message（发送消息）、followup_task（跟进任务）。在加密路径下，父 Agent 的工具调用变成这样：

{
  "name": "spawn_agent",
  "arguments": {
    "task_name": "worker",
    "message": "<ciphertext>"
  }
}

而 Codex 内部存储的跨 Agent 通信记录变成了：

{
  "author": "/root",
  "recipient": "/root/worker",
  "content": "",
  "encrypted_content": "<ciphertext>",
  "trigger_turn": true
}

注意 content 字段是空的。原本的可读任务描述消失了。

安全进步，还是审计倒退？#

从安全角度看，这个改动确实有道理。明文任务文本在多个 Agent 之间传递时，任何能接触到历史文件或日志的人都能看到完整的操作指令。在企业环境中，这让安全团队不安。

但问题在于，加密的范围超出了必要。这个改动把 message 参数标记为「对模型加密」，意味着连本地存储的 Rollout 历史中也不保留可读副本。开发者想要回答以下问题时，系统不再提供任何线索：

  • 我给子 Agent 分配了什么任务？
  • 子 Agent 之间互相发送了什么消息？
  • 事后复盘时，这个子线程为什么存在？

正如社区用户 ignatremizov 在 Issue #28058 中所说：「我们不想造出天网，然后发现自己无法审计它在做什么。」

这句话戳中了问题的核心。AI Agent 系统的可靠性不仅建立在模型能力上，更建立在可观测性上。当 Agent 的行为变得无法追溯，开发者的信任也会随之瓦解。

GPT-5.5 用户被「强制」走加密路径#

事情在 Codex 0.142.5 版本中变得更复杂了。

社区用户 Alek2077 发现了一个令人困惑的行为：即便你在配置文件中明确设置 features.multi_agent_v2 = false，GPT-5.5 模型仍然会强制使用 V2 加密路径。用 features list 命令查看，系统告诉你 V2 已禁用，但实际上 spawn_agent 暴露的仍然是 V2 的任务模式。而同样配置下的 GPT-5.4 线程则正常工作。

这意味着什么？如果你使用的是当前最强的前沿模型 GPT-5.5，你就无法选择可读的 V1 委托路径。加密不是可选项，是唯一选项。

这不只是一个技术细节。这是产品哲学的选择：OpenAI 默认假设用户更需要安全而非透明。但对于每天用 Codex 做实际开发的工程师来说，透明性本身就是一种安全保障，你能看到 Agent 的行为，才敢让它做更多事。

社区的回应：正在修，但能修好吗？#

OpenAI 团队并非没有意识到这个问题。bolinfest 和 rka-oai 分别提交了 PR #30867 和 #30872，为多智能体通信添加了结构化的生命周期日志。这些改动统一了消息发送路径，为后续的可观测性工作打下了基础。

但正如 ignatremizov 所指出的，这些 PR 解决的是「运维级可观测性」问题，而不是「本地可审计性」问题。新的日志路径在 content 为空时仍然只能记录 encrypted_content，开发者在本地 Rollout 中看到的仍然是密文。

根本性的修复方案在 Issue #28058 中其实已经提出：保留加密的 message 字段用于模型间传递，同时增加一个独立的、非加密的审计字段，用于存储可读的任务文本。这个审计字段应该持久化到 Rollout、历史和追踪元数据中，让用户和开发者能够检查 Agent 的委托行为。

更深层的思考：Agent 系统的「观察者困境」#

这件事引发了一个更广泛的问题：当我们构建越来越复杂的多智能体系统时，如何在安全性和可观测性之间找到平衡？

传统软件工程中，日志和审计跟踪是理所当然的基础设施。你不会因为担心日志被泄露就停止记录日志。你会做的是：记录日志 + 控制访问权限 + 加密传输和存储。

Agent 系统的加密应该遵循同样的思路。加密 Agent 间的通信通道是好事，但加密本地审计记录是一种过度反应。两者的安全需求不同，解决方式也应该不同。

换个角度想：如果连创建 Agent 的开发者都看不到 Agent 的行为，那么谁来做这件事？只有 OpenAI 的 API 服务端能够解密。这种「只有提供商能审计」的架构，正在将我们推向一个奇怪的方向：个人开发者和中小企业可能被排除在高级 Agent 功能之外，因为这些功能缺乏基本的可调试性。

接下来会怎样？#

目前 Issue #28058 仍然处于 Open 状态，社区的关注度在持续上升。OpenAI 团队的态度是积极的，他们已经在做通信生命周期日志的基础工作，但距离真正的本地可审计性还有一段路要走。

对于 Codex 的日常用户，这里有几点建议：

  1. 如果你依赖多智能体功能做关键任务，考虑暂时使用 GPT-5.4 而非 GPT-5.5，后者仍然可以使用 V1 路径保留审计记录
  2. 关注 #28058 和 #30867 的进展，这两个是解决方向的关键 Issue/PR
  3. 在团队中建立额外的日志习惯，比如在 Prompt 中要求 Agent 在完成任务后以特定格式汇报其接收到的子任务，用应用层日志弥补系统层审计的缺失

加密和透明不是非此即彼的选择。一个好的 Agent 系统应该两者兼具：加密保护通信安全，透明保证人类可控。Codex 团队显然正在朝这个方向努力，但在修好之前，开发者需要明白，他们正在一个自己无法完全看见的系统上工作。

参考来源：