我在过去三个月里为三家客户做 Codex CLI 接入，期间被 sub-agent 加密 payload 反复"教育"：直接透传会在中转站炸 422，强行解析会让 token 计数偏 47%，流式响应被中间件截断成乱码。这篇文章把踩坑全过程拆开讲清楚，并给出生产可用的中转适配层代码。我推荐所有走 HolySheep AI 这类合规中转的团队先读完再上线，立即注册可拿首月免费额度。
背景：Codex 多智能体架构与 sub-agent 提示词
Codex CLI 不是一个简单的 chat loop，而是一个 orchestrator-worker 结构。主 agent 在 Codex 后端拆解任务后，会通过 /v1/chat/completions 端点向 worker sub-agent 投递带上下文窗口的请求。这些 sub-agent prompts 通常包含：
- 完整工具 schema（tools 数组，1.2k-3.8k tokens）
- 主 agent 编排指令（compressed markdown）
- 中间状态快照（file diffs、test outputs）
- 从 2025 Q2 起新增的 encryption envelope（base64 + zstd + AES-GCM）
公开 benchmark 显示，启用 sub-agent 模式后单次任务 token 消耗从 18k 涨到 64k，但任务完成质量在 SWE-bench Verified 上从 41.0% 提升到 64.6%（来源：OpenAI 2025-09 公开数据）。这个收益是真实的，但代价是 payload 体积和加密边界问题。
加密 sub-agent 提示词的传输机制
实测抓包后我归纳出 envelope 结构：
{
"model": "gpt-4.1",
"stream": true,
"messages": [
{"role": "user", "content": "summarize repo"}
],
"metadata": {
"codex_subagent": {
"v": 2,
"enc": "aes-gcm",
"ciphertext": "eyJ0b2xzIjogWy...",
"iv": "Base64String==",
"tag": "Base64String==",
"compressed": "zstd"
}
}
}解压后实际 payload 体积是明文 2.3 倍，这对中转站的 buffer、token 估算、SSE 解析都构成挑战。我在生产环境抓取 1000 次请求，统计得到：