OpenAI 近期为其编程工具 Codex 引入了一项静默却影响深远的变更：对 AI 代理之间的内部通信实施加密。自 6 月初 起，当主代理将任务拆解并委派给子代理时，两者间传递的指令不再以明文形式记录，开发者在会话历史中只能看到一段不可读的加密字符串。这意味着，开发者彻底失去了追踪任务如何在 AI 系统内部被分解、指派和执行的能力。

随着编程工具日益向代理化系统演进，它们能够在后台自主做出决策，将复杂任务切分并分发给不同的子代理。这种自动化在提升效率的同时，也让内部流程的透明度变得至关重要。然而，Codex 的此次更新直接切断了开发者对“黑箱”内部的视线。一份发布在 GitHub 上的错误报告直接呼吁 OpenAI，应在本地存储一份可读的任务副本，与加密版本并存。

此次加密策略在不同模型上的应用力度并不一致。此前，GPT-5.5 曾一度完全不允许开发者通过专用开关关闭加密，导致可见性彻底归零，但据悉 OpenAI 已将其调回至明文路径。目前，强制加密主要施加于更大的 GPT-5.6 模型变体 Sol 和 Terra，而最小的变体 Luna 则继续使用开放的明文通信路径。

新系统在可靠性上也暴露出问题。多名开发者反馈，加密后的任务交接有时会失败，原因是内容无法被解密。在某些案例中，即便主代理和子代理运行的是同一个模型，交接依然会出错。这表明加密机制不仅影响了透明度，还可能对代理协作的稳定性构成干扰。

对于为何加密代理间通信，OpenAI 至今未给出官方解释，仅确认了变更本身。社区普遍存在两种推测。一种观点认为，OpenAI 将这些指令视为类似于原始推理轨迹的敏感数据，意图阻止竞争对手利用它们来训练自己的模型。这种担忧并非空穴来风，近期 智谱 AI 的开源模型 GLM-5.2 就被怀疑是从 GPT-5.5 和 Opus 4.8 中蒸馏而来。代理间的通信数据极具训练价值，能够帮助较弱模型向更强模型的能力靠拢，加密无疑是切断这条数据通道的直接手段。

另一种更简单的解释则指向数据隐私。OpenAI 的 API 本身就会对中间状态进行加密，以便在后续请求中转发，而无需在其服务器上以明文形式存储。将这一逻辑延伸至代理间通信，或许只是隐私保护措施的常规升级。

无论真实动机是防止模型蒸馏、强化数据隐私，还是两者兼有，Codex 的这一变化都将开发者置于一个全新的位置。他们必须在不了解内部委派逻辑的情况下，信任 AI 代理能够正确协作。对于追求精细控制和调试能力的专业开发者而言，这无疑增加了排查问题的难度，也引发了关于 AI 系统可解释性边界的新一轮讨论。