高速减少上下文腐烂的Codex子代理实践

背景

2026年7月，OpenAI 发布 GPT-5.6 Sol 后，用户反馈普遍负面，尤其集中在新推出的 Ultra 模式上——该模式被抱怨“思考时间极长、额度消耗巨大、任务完成效率低下”。社区发现，问题并不全在模型本身：官方在发布当天下午已将 Sol 的“juice 值”（控制模型最大思考长度的内部参数）回滚至初始版本（后续可能再次调整）。用户观察到的 Ultra 模式消耗额度极高（官方标准：Ultra 内部为 max 思考强度，外加多代理脚手架，juice 值达 960；而最高级的 max 也为 960，但无额外脚手架），且 Sol 完成任务缓慢的原因更多出在编排而非思考深度。

核心内容

Ultra 并不是新模型，而是一个编排开关

在 Codex 及 Claude Code 生态中，Ultra 的实现方式是在用户输入特定关键词（如 ultracode）时，向当前请求注入一段多代理提示词，通知模型进入“多代理编排”状态。Codex 的 Ultra 直接在模型上采用 max 级别的思考强度，但额外增加了一段英文提示：

“多代理模式已启用。主代理可以主动派生子代理，不必等用户明确要求。但只应在任务可以拆成独立工作流，并且并行处理能明显提升速度或质量时使用。主代理最终负责综合和验证结果。”

类似地，Claude Code 的 ultracode 实现会注入两条 system-reminder：

• 用户输入 ultracode 关键词，本轮选择多代理编排——请用 Workflow 工具完成。
• Ultracode is on：优化到最详尽、最正确的答案，而不是最快最省；每个实质性任务都用 Workflow 工具；token 成本不是约束。

因此，Ultra 本身既不是快也不是慢，而是一个“编排放大器”。配置良好时，小模型承担探索工作，Sol 只接收压缩后的结论，总成本可能下降；配置不当则会导致子代理套娃（子代理再去派生更多 Sol），消耗大量额度、任务极慢甚至失败。

子代理与上下文腐烂

随着会话增长，大型项目中的需求、决策、代码片段、搜索结果、日志、失败路径被塞入同一上下文。有效信息并未消失，但开始与大量低价值信息竞争注意力——这被称为“上下文腐烂”。真正有价值的是结论和决策，但产生它们需要大量中间工作（如 grep 几百行结果、读十几个文件、走两条死路）。这些原始证据一旦留在主上下文中，就从“工作过”变成“污染物”。

子代理的核心作用之一：将无用的污染隔离在一个用完即弃的上下文中，只让蒸馏后的结论回流主上下文。

MultiAgent V2

GPT-5.6 发布后，MultiAgent V2 成为 Sol 的默认多代理协议。配置字段从 V1 的 [agents] 变为 V2 的 [features.multi_agent_v2]。当前 Codex 模型目录中：

• GPT-5.6 Sol / Terra → multi_agent_version: "v2"
• GPT-5.6 Luna → multi_agent_version: "v1"

V2 是未来方向，但当前存在混乱状态（Luna 仍为 V1）。文章以 V2 统一组织配置，V1/V2 的完整差异将在系列第三篇展开。

三份配置文件

整套配置最终落于三个文件：

1. ~/.codex/AGENTS.md：规定主代理何时派发子代理、如何派发、如何验证。
2. ~/.codex/config.toml：规定并发数量、协议形态及等待边界。
3. ~/.codex/agents/default.toml：规定子代理选用什么模型、以什么身份工作。

AGENTS.md 核心提示词（可直接复制）

主代理提示词强调子代理用于探索（“探子”），用于“宽而重”的读取。必须遵守：

• 更激进、更频繁地调用子代理，避免上下文腐烂。
• 明确哪些情况直接处理（小文件、即将修改的代码、成本高于自读的任务、奠基性文档等），哪些情况派发子代理（巨型文件、跨文件检索、并行探索、长任务中重新确认、外围材料阅读）。
• 委派任务必须自包含，指定检索范围、具体问题和期望输出。精度重要时要求返回 file:line、符号名及关键原文。
• 子代理结果只是线索，复核仅需抽查出处，而非重读全部材料。唯二需要主代理亲自完整读原文的是：即将修改的确切代码、奠基性文档。
• 子代理默认只做探索/检索/核验，不改动代码，不负责方案取舍或最终验证。
• 派发机制：主代理自主决定是否派发，系统允许最大并行 7 个会话进程（即最多 6 个子代理并行）。子代理一律使用默认配置（agent_role = "default" 或 agent_type = "default"），禁用 explorer/worker 等其他角色。派生时必须显式 fork_turns = "none" 以保持子代理干净。多个子代理应在同一轮并发派发，派发后主代理立即 wait_agent 停止其他活动直至全部返回。收到每个子代理结果后，若提供了 close_agent 则立即关闭，不复用不追派。

config.toml 子代理相关配置（可直接复制）

[features.multi_agent_v2]
enabled = true
hide_spawn_agent_metadata = false
tool_namespace = "agents"
max_concurrent_threads_per_session = 7
min_wait_timeout_ms = 10000
default_wait_timeout_ms = 30000
max_wait_timeout_ms = 900000

需要移除 V1 的 [agents] 块（如 max_threads、max_depth 等）。参数说明：

• max_concurrent_threads_per_session = 7：允许同时 7 个活跃线程（1 主 + 6 子）。
• wait_timeout 参数控制 wait_agent 调用可请求的等待区间，并非子代理生存期限。超时仅将控制权返回主代理，不自动终止子代理。
• hide_spawn_agent_metadata = false：控制主代理在 spawn_agent 中可见的参数。设为 true 时主代理仅能看到 task_name、message、fork_turns；设为 false 额外暴露 agent_type、model、reasoning_effort、service_tier。在本文实践中，建议设为 true 以隐藏这些字段，让模型无法控制子代理类型和思考强度，实现“泛型调用”。

default.toml（固定子代理为 Luna low）

name = "default"
description = "General-purpose subagent locked to gpt-5.6-luna with low reasoning."
model = "gpt-5.6-luna"
model_reasoning_effort = "low"
developer_instructions = """
你是通用子代理，是主代理派出去的探子。你只做探索、检索、核验：不改动任何东西，不做方案取舍或者最终判断——那些是主代理的事。
不要派生、调用或者请求新的子代理；任务若是需要进一步拆分，把拆分的建议返回给主代理。

你交回给主代理的东西：
- 你的产出直接喂给主代理、是它据以行动的数据，并非给人看的。密而不水，不寒暄、不复述过程、不下客套结论。
- 给证据，不
"""

建议选用更快更轻量化的模型（如 Luna low）作为子代理，以降低额度消耗。开发者也可以自行更改 model 和 model_reasoning_effort。

编写型 vs 探针型子代理

文章主线使用“探针型”子代理（只探索、检索、核验，不改动），另一种用法是让主代理作为编排者，子代理实际参与代码