6 月 5 日，Codex CLI 的多代理协作功能 MultiAgentV2 合入一个加密补丁。spawn_agent、send_message、followup_task 三个工具的消息内容全部加密。子代理照常收到任务、正常执行。
问题出在人类这一侧。6 月 13 日，一位开发者在 issue #28058 里发现：本地 rollout、trace、日志里，这些任务内容也变成了密文。想回头看“我到底让它干了什么”，打开的是一串看不懂的字符串。
发生了什么：字段被清空，不是传输出了问题
问题出在 InterAgentCommunication 结构体。加密开启后，content 字段被直接清空，任务文本只写进 encrypted_content。
| 位置 | 加密前 | 加密后 |
|---|---|---|
| content 字段 | 明文任务文本 | 空 |
| encrypted_content | 无 | 密文 |
| rollout / trace / 通信日志 | 可读 | 仅密文 |
受影响范围很直接：
| 项目 | 内容 |
|---|---|
| 受影响工具 | spawn_agent、send_message、followup_task |
| 受影响版本 | 0.137.0 之后、开启 MultiAgentV2 |
| 不受影响的环节 | 子代理解密、正常执行任务 |
| 缺失的环节 | 父侧 rollout/trace/日志的明文留存 |
issue 里贴的源码显示，加密分支下 to_model_input_item() 压根不会写回可读文本，日志的兜底逻辑也是“content 为空就打印密文”。不是漏了一处，是整条链路都按这个假设写的。
加密没错，错的是把审计权也一起锁死了
issue 作者说得很清楚：这不是要 OpenAI 撤回加密，而是加密投递和本地审计本该是两件事。
加密该护的是传输链路，不该护住的是自己人的眼睛
他给出的修复思路也朴素：保留 encrypted_content 发给子模型，另加一个必填的明文字段（如 task_message），只存在父侧的 rollout、trace、日志里，两边互不干扰。issue 里还贴了一个原型实现的 commit，spawn_agent 那部分已经跑通——这说明不是无解的架构难题，只是当初合并加密改动时漏掉了这一块。
民航强制装黑匣子，不是因为不信任飞行员，而是出事之后总要有办法倒查“当时到底发生了什么”。多代理系统里，父代理给子代理派任务，也是一次决策委托。委托内容一旦全链路加密到父侧也读不到，出事时能确认的只剩“调用发生过”，具体让它干了什么，没人说得清。
谁受影响，现在能做什么
最直接受影响的是用 Codex CLI 跑多代理工作流、且开了 MultiAgentV2 的开发者和团队。审计、复盘、调试子代理任务，是他们的日常操作，不是边缘场景。
现在能做的事不多，但很具体：
- 检查自己的版本号，确认是否在 0.137.0 之后、是否开启了 MultiAgentV2
- 回看 rollout 或 trace，看子代理任务这一段是否已经是密文——是的话就已经中招
- 如果本地审计和调试是刚需，可以考虑暂时关闭 MultiAgentV2，等修复合入再开
接下来最该盯的是两件事：issue #28058 是否被官方标记为 confirmed，以及“加密投递 + 父侧明文字段”这套修复思路会不会被采纳。目前 issue 仍是 open 状态，只有社区的代码分析和一个跑通的原型 commit，还谈不上官方确认或修复承诺。
这类回归容易被当成细节 bug 放过评审——补丁的名义是安全加固，没人会专门去问“审计怎么办”。但 Agent 系统越自动化，父代理到子代理的每一次任务分发，就越接近一次决策委托。委托可以加密传递，委托记录不该跟着一起消失。