Codex 开始加密子代理提示词
OpenAI 的 Codex 编码代理已经开始对从主代理发送给子代理的提示词进行加密，因此只有 OpenAI 的服务器能看到明文指令，而用户和本地日志看到的是密文。支持者认为这有助于保护专有的提示编排并阻碍黑市转售商和模型蒸馏者，但许多开发者认为这削弱了透明度、可审计性和信任，尤其是在子代理能够对本地代码库或系统采取行动时。这一变化也引发了人们对更强厂商锁定以及更广泛的、走向不透明“黑箱” AI 工具的担忧，促使一些人转向更简单的 API、替代 harness，或本地/开源模型。
技术上发生了什么变化
- Codex 现在会加密某些子代理提示词：主/编排代理发给子代理的初始消息会以密文形式存储和传递，只有 OpenAI 后端能够解密。
- 这主要适用于
multi_agent_v2，尤其是在 GPT-5.6 Sol/Terra 和“Ultra”推理模式下；据报道 Luna 和本地模型不受影响。 - 推理本身仍然在服务器端以明文进行；只有部分代理间消息被加密。
- 会话日志和子代理输出仍然是明文；被隐藏的是子代理的初始提示词。
讨论中的动机
- 保护“护城河”/知识产权：编排逻辑、子代理提示方案，以及可能经过 RL 优化或隐式表示的内容，被视为非常有价值，一旦可见就很容易被蒸馏。
- 反滥用：被视为对黑市转售商和蒸馏方的反制手段，这些方会代理流量并训练竞争模型，包括一些被提到的中国服务。
- 有人认为这符合现有趋势：多个提供商已经在隐藏或加密推理轨迹和“思考”过程。
对开发者和用户的影响
- 主要抱怨：失去可观测性和可审计性。
- 更难调试为什么子代理行为异常、浪费 token，或者做出危险操作（例如破坏性的 shell 命令）。
- 多代理工作流或计费也没有清晰的审计轨迹。
- 有人认为，这会让 Codex 的多代理功能在严肃工作中变得不可用，尤其是在安全敏感或高成本环境中。
- 提到的变通方法：
- 通过本地目录覆盖强制使用
multi_agent_v1。 - 避免使用 Codex 子代理，改用自定义工具/技能或自己的 harness。
- 坚持使用 chat completions 或本地模型，在这些方案中提示词完全可见。
- 通过本地目录覆盖强制使用
比较与更广泛的担忧
- 与 Claude 的加密“thinking”相比较；几位发帖者都不喜欢这两者，认为隐藏推理会削弱对代理式编码的信任。
- 也有人把内部轨迹看作正常的专有实现细节，类似闭源软件内部机制。
- 有人担心这会加剧锁定效应、带来不透明的“黑箱”行为，并推动 AI 设备化，用户只能看到产物和账单。
- 也有人认为这会推动更多人转向开放或更便宜的非美国模型以及本地方案，而另一些人则认为最先进模型仍然值得这种权衡。