《Prompt 与上下文工程（04）：上下文预算与压缩——给每一部分定配额，超了怎么办》讲了长任务上下文管理的策略：隔离 → 卸载 → 清理 → 压缩，代价递增；复述对抗漂移。这一篇看实现——这些策略在 harness 的运行时里是什么样的代码与配置：Codex 的 compact* 模块族、DeepSeek Harness 的 compaction 与 spill 包组、plan / todo / goal 三个包、Claude Code 的 auto-compact 与子 agent。然后讲隔离手段里最重要的一种——子 agent——的三种形态与它们的取舍：Claude Code 的 subagent 与 agent teams、Codex 的 multi_agents、DeepSeek Harness 的七种子 agent 后端——其中包括把 Claude Code 与 Codex 作为子 agent 拉起。

一个反复出现的数字值得先记住：Anthropic 的多 agent 研究系统报告 agent 用的 token 约是聊天的 4 倍、多 agent 系统约是聊天的 15 倍。子 agent 是隔离上下文最有效的手段，也是成本放大最快的手段——两面要一起看。

本篇要回答的核心问题是：

L2 的卸载 / 清理 / 压缩在 Codex 与 DeepSeek Harness 里各是什么模块，怎么配合？¹ plan / todo / goal 作为复述机制怎么实现？² 子 agent 有哪三种形态，各在什么情况下用、成本多少？³

一、总览

1. 策略到实现

%%{init: {"flowchart": {"wrappingWidth": 360}}}%%
%% 图：长任务上下文管理的代价阶梯：隔离 → 卸载 → 清理 → 压缩
flowchart TB
    A["<b>隔离</b>：子 agent 在自己的上下文里干活，只把摘要带回来<br/>代价几乎为零"] --> B["<b>卸载</b>：大的工具返回存到外面，上下文里留一个可取回的定位符<br/>（DeepSeek Harness 的 spill）"]
    B --> C["<b>清理</b>：读过的、过期的工具输出直接修剪掉<br/>（compaction-tool-result-pruner）"]
    C --> D["<b>压缩</b>：用一次模型调用把旧历史摘要成一段<br/>最贵、最有损、缓存全失效（Codex compact*，Claude Code auto-compact）"]
    style A fill:#eefaf0,stroke:#4d9a5c
    style D fill:#fde8e8,stroke:#c0392b

L2 的上下文策略在三个 harness 里的实现

L2 的策略	Codex	DeepSeek Harness	Claude Code
卸载（大结果出上下文留引用）	工具返回的截断与 view_image 一类按需读取	spill 包组：存储服务 + 本地后端 + 结果策略，返回带取回指引的定位符	子 agent 隔离大量读取；工具返回截断
清理（删已消费的工具返回）	会话记忆压缩优先于摘要（《Prompt 与上下文工程（04）：上下文预算与压缩——给每一部分定配额，超了怎么办》）	compaction-tool-result-pruner：压缩前先修剪超大工具输出	微压缩旧工具返回
压缩（摘要替换历史）	compact.rs、compact_remote_v2*.rs（服务端加密）、compact_token_budget.rs、compact_model_fallback.rs	compaction 包组：compaction-basic 自动 + /compact 命令 + compaction-image-offload	auto-compact 约 83.5%
复述（目标回末尾）	plan 工具处理器、get_context_remaining 让模型看剩余预算	plan（记录式规划）、todo（todo_write 工具）、goal（会话目标）	todo 工具、CLAUDE.md 重注入
隔离（子 agent）	multi_agents / multi_agents_v2 处理器、agent-roles crate	subagent 包组七种后端	subagent / agent teams

2. 本文的章节安排

第二章卸载与清理的实现；第三章压缩的实现；第四章复述；第五章子 agent 的三种形态；第六章子 agent 的成本与取舍；第七章实践建议。

二、卸载与清理

1. DeepSeek Harness 的 spill

spill/ 是一个独立包组——”把全文存到模型上下文之外，返回一个带取回指引的定位符”——分三个包：存储服务（spill）、本地文件系统后端（spill-local）、结果策略（决定什么时候溢出）。它是 《Prompt 与上下文工程（04）：上下文预算与压缩——给每一部分定配额，超了怎么办》”卸载”原则的一等实现：工具返回超过阈值不进上下文，模型看到的是”内容已存为 spill://…，共 N 行，前几行如下，用 read 取回”。作为独立包组的意义是可替换：把本地后端换成对象存储、把策略换成按工具类型的阈值，不动循环。

%% 图：DeepSeek Harness 的 spill 包组——工具返回先过结果策略（超阈值？按工具类型？），超了就交给存储服务写到本地文件系统后端（可换成对象存储），上下文里只进一个定位符「spill://…，共 N 行，前几行如下，用 read 取回」；策略、存储、后端三个包各自可替换，循环不动
flowchart TB
    T["工具返回：30K token 的日志"] --> P{"spill-policy<br/>结果策略：超阈值？"}
    P -->|"否"| IN["原样进上下文"]
    P -->|"是"| S["spill<br/>存储服务"]
    S --> B["spill-local<br/>本地文件系统后端<br/>（可换：对象存储）"]
    S --> LOC["上下文里只进定位符：<br/>spill://run-7/tool-12 · 共 4,210 行<br/>前 10 行预览 · 用 read 取回"]
    LOC -.->|"模型需要时 read(定位符, 范围)"| B
    classDef step fill:#fff7e0,stroke:#c98a00,color:#222
    classDef dec fill:#eef6ff,stroke:#5b8fd6,color:#222
    classDef ext fill:#f0f0f0,stroke:#888,color:#222
    classDef ok fill:#eefaf0,stroke:#4d9a5c,color:#222
    class T,S,IN step
    class P dec
    class B ext
    class LOC ok

2. Codex 的截断

Codex 没有单独的 spill 概念，工具返回在处理器里按上限截断（shell 输出的行数与字节上限），大内容（文件、图片）用专门的工具按需读取（view_image、文件读取工具的范围参数）。仓库规范里对”模型可见上下文”有硬规则：”不能有无界的项——注入模型上下文的一切都要有有界大小与硬上限；没有大于 10K token 的项；能超过 1K token 的新单项按 P0 审查。”这是”卸载”作为代码审查规则的形态。

3. 清理

DeepSeek Harness 的 compaction-tool-result-pruner 在压缩之前先修剪超大的工具输出——”这样要压缩的东西更少”，正是 《Prompt 与上下文工程（04）：上下文预算与压缩——给每一部分定配额，超了怎么办》”先清理再压缩”的顺序。Codex 的会话记忆压缩（用已结构化的任务状态替代摘要、多数情况不调模型）是另一种”压缩前的便宜一步”。Claude Code 的微压缩同理。

三、压缩

1. Codex 的模块族

core/src 下的 compact.rs（本地压缩：用模型生成摘要）、compact_remote_history.rs 与 compact_remote_v2*.rs（服务端压缩：调 Responses 的 compact 端点拿加密 item——《Prompt 与上下文工程（04）：上下文预算与压缩——给每一部分定配额，超了怎么办》；v2 有单独的尝试逻辑与图片预算）、compact_token_budget.rs（触发阈值与预算计算）、compact_model_fallback.rs（压缩用的模型不可用时的回退）。触发点在 turn loop 的边界（第一篇），压缩结果作为一条 rollout 记录进日志（第三篇）。

2. DeepSeek Harness 的 compaction 包组

包组的说明：”让长对话在接近模型上下文上限时继续工作：随 token 压力累积自动把旧历史浓缩成摘要，按需用 /compact，超大工具输出可以先修剪，图片能力不足的路由把图片换成占位符。”五个包：compaction（接缝）、compaction-basic（自动压缩）、command-compact（/compact 命令）、compaction-tool-result-pruner（修剪）、compaction-image-offload（图片卸载）。SDK 文档里提到默认组合”带显式组合的语义检查点策略”——压缩策略是配置出来的，不是写死的。压缩摘要作为一个会话事件进日志（”模型可见 ⟺ 已记录”），有独立的 token 上限。

3. 共同点

两家都把压缩做成多个可组合的步骤（修剪 / 会话记忆 → 摘要 → 回退），都把结果写进日志，都在思考链结束的边界触发（《模型作为组件（03）：API 契约（二）——推理模型：thinking、effort 与跨轮的推理状态》）。差别在摘要形态（Codex 服务端加密 vs DeepSeek Harness 可读事件）与可替换性（Codex 的模块是代码、DeepSeek Harness 的是插件）——第六篇对照。

%% 图：三个 harness 的压缩链都是「便宜的一步 → 摘要 → 回退」——Codex：会话记忆压缩（结构化任务状态，多数不调模型）→ compact.rs 本地摘要或 compact_remote_v2 服务端加密 item → compact_model_fallback；DeepSeek Harness：tool-result-pruner 修剪 → compaction-basic 自动摘要 / 命令 → 可读事件进日志；Claude Code：微压缩旧工具返回 → 83.5% 处 auto-compact → CLAUDE.md 重注入；都在思考链边界触发、结果都写进日志
flowchart LR
    subgraph CX["Codex"]
        direction TB
        C1["会话记忆压缩<br/>结构化任务状态替代摘要，多数不调模型"] --> C2["compact.rs 本地摘要<br/>或 compact_remote_v2：服务端加密 item"] --> C3["compact_model_fallback<br/>压缩模型不可用时回退"]
    end
    subgraph DS["DeepSeek Harness"]
        direction TB
        D1["compaction-tool-result-pruner<br/>先修剪超大工具输出"] --> D2["compaction-basic 自动 / command-compact<br/>可读摘要事件进日志，有独立 token 上限"] --> D3["compaction-image-offload<br/>图片换占位符"]
    end
    subgraph CC["Claude Code"]
        direction TB
        K1["微压缩旧工具返回"] --> K2["83.5% 处 auto-compact<br/>结构化摘要替换历史"] --> K3["CLAUDE.md · 自动记忆从磁盘重注入"]
    end
    CX ~~~ DS ~~~ CC
    N["共同点：多步可组合 · 结果进日志 · 在思考链边界触发（《[模型作为组件（03）：API 契约（二）——推理模型：thinking、effort 与跨轮的推理状态](/reasoning-models-as-components-thinking-effort-and-state.html)》）"]
    classDef cheap fill:#eefaf0,stroke:#4d9a5c,color:#222
    classDef sum fill:#fff7e0,stroke:#c98a00,color:#222
    classDef fb fill:#f0f0f0,stroke:#888,color:#222
    classDef n fill:#eef6ff,stroke:#5b8fd6,color:#222
    class C1,D1,K1 cheap
    class C2,D2,K2 sum
    class C3,D3,K3 fb
    class N n

四、复述

1. 三个包

DeepSeek Harness 把 Manus 的 todo.md（《Prompt 与上下文工程（04）：上下文预算与压缩——给每一部分定配额，超了怎么办》）做成三个一等功能：plan/（”记录式规划”——计划作为事件进日志）、todo/（todo_write 工具——模型维护任务列表）、goal/（”会话目标”——整个会话的目标，与 schedule 的定时跟进配合）。它们的共同作用是把目标与进度作为结构化事件保持在模型可见的近端，对抗 《Prompt 与上下文工程（01）：上下文的解剖——一次请求里模型看到的一切》讲的漂移；同时是压缩的现成材料（摘要里直接带任务状态）。

2. Codex 的 plan 与 get_context_remaining

tools/handlers/plan.rs 让模型写与更新计划；get_context_remaining.rs 让模型看到自己还剩多少上下文预算——这是一个有意思的设计：把预算变成模型的输入，让它自己决定何时收敛、何时卸载。Codex 的会话记忆压缩靠的就是这些结构化的任务状态。

3. Claude Code

todo 工具与压缩后从磁盘重注入的 CLAUDE.md（《Prompt 与上下文工程（01）：上下文的解剖——一次请求里模型看到的一切》）：项目级的常驻目标靠重注入，任务级的进度靠 todo。

五、子 agent 的三种形态

1. 为什么

三个理由：上下文隔离（探索性搜索读几十个文件，主窗口只要摘要——《Prompt 与上下文工程（01）：上下文的解剖——一次请求里模型看到的一切》的 Claude Code 时间线）、并行（几个独立子任务同时跑）、专业化（不同的系统提示、工具集、权限、甚至模型）。没有这三个理由之一就不要用——第六章讲代价。

2. Claude Code：subagent 与 agent teams

Claude Code 的 subagent 与 agent teams

	subagent	agent teams（实验，v2.1.178+）
上下文	自己的窗口；结果回调用者	自己的窗口；完全独立
通信	只向主 agent 报告结果	队友之间直接通信
协调	主 agent 管全部工作	共享任务列表，自协调
适合	只要结果的聚焦任务	需要讨论与协作的复杂工作
token	较低：结果摘要回主上下文	较高：每个队友是独立的 Claude 实例

subagent 的定义有三种方式：程序化（Agent SDK 的 agents 参数）、文件（.claude/agents/*.md，前置元数据 description / tools / model / permissionMode）、内置（general-purpose、Explore、Plan）；主 agent 按每个 subagent 的 description 决定是否派发——又是”描述是 prompt”。subagent 继承父会话的权限，多数内置的用受限工具集。agent teams 默认关闭（CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1），文档明写”在会话恢复、任务协调、关闭行为上有已知限制”——第七篇讲多 agent 时再回来。

3. Codex：multi_agents

tools/handlers/multi_agents*.rs（含 v2）是 Codex 的子 agent 工具处理器，agent-roles crate 定义角色，agent-graph-store 存 agent 之间的关系图；GPT-5.6 的 ultra 模式与 Responses 的 multi-agent beta（”一次请求内运行并发子 agent 并综合”）是它在 API 层的对应（《模型作为组件（03）：API 契约（二）——推理模型：thinking、effort 与跨轮的推理状态》）。

4. DeepSeek Harness：七种后端

subagent/ 包组把”委派”做成一个接缝加多种后端：

DeepSeek Harness 的七种 subagent 后端

后端	含义
subagent-spawn-in-process	进程内全新的子 agent（隔离的上下文）
subagent-fork-in-process	进程内继承历史的子 agent（带着父会话的上下文分叉——事件溯源让 fork 成为复制前缀）
subagent-in-process-driver	进程内驱动
subagent-dsh-sdk	通过 SDK 起一个进程外的 dsh
subagent-acp	通过 ACP（自动化协议）起外部 agent
subagent-claude-code	把 Claude Code 作为子 agent 拉起
subagent-codex	把 Codex 作为子 agent 拉起

最后两个值得停一下：一个 harness 可以把另外两家的 harness 作为自己的子 agent——委派一个子任务给 Claude Code 或 Codex，拿回结果。hooks/ 包组还有 Claude Code / Codex 的 hooks 桥接。这说明 2026 年 harness 之间的互操作已经是事实：它们共享 MCP、共享 SKILL.md、共享 AGENTS.md（《Prompt 与上下文工程（06）：prompt 当代码管——版本、评测、A/B，以及上下文 vs 检索》），现在还能互相调用。”该用哪个 harness”的问题正在变成”该怎么组合”。

%% 图：子 agent 的三种形态与 DeepSeek Harness 的七种后端——spawn 从零开始隔离的上下文（适合独立探索），fork 复制父会话的事件前缀继承历史（适合接着当前状态并行做一件事，事件溯源让它只是复制前缀），进程外经 SDK / ACP 起外部 agent，甚至把 Claude Code 或 Codex 拉起当子 agent；主 agent 拿回的只有摘要
flowchart TB
    M["主 agent<br/>会话日志：事件 1…k"] -->|"派发指令：任务 · 边界 · 返回格式"| SUB
    subgraph SUB["subagent 接缝：七种后端"]
        direction LR
        S1["spawn-in-process<br/>全新上下文，从零开始"] ~~~ S2["fork-in-process<br/>复制事件 1…k 再追加<br/>继承历史"] ~~~ S3["dsh-sdk / acp<br/>进程外起一个 dsh 或外部 agent"] ~~~ S4["claude-code / codex<br/>把另一家 harness 拉起当子 agent"]
    end
    SUB -->|"返回：一段结构化摘要（主 agent 拿到的全部）"| M
    SUB -.- N["每个子 agent：自己的预算 · 卫士 · 权限（如只读）<br/>完整轨迹可从父会话追到（trace 是树）"]
    classDef m fill:#eef6ff,stroke:#5b8fd6,color:#222
    classDef s fill:#fff7e0,stroke:#c98a00,color:#222
    classDef x fill:#eefaf0,stroke:#4d9a5c,color:#222
    classDef n fill:#f0f0f0,stroke:#888,color:#222
    class M m
    class S1,S2,S3 s
    class S4 x
    class N n

5. 子 agent 的上下文设计

无论哪种形态，子 agent 的效果取决于两段文本：派发指令（任务、边界、期望的返回格式——”返回文件路径列表与每处一句话说明，不要贴代码”）与返回的摘要（主 agent 拿到的全部）。子 agent 自己也是一个 agent：有自己的预算、卫士、权限（Claude Code 的 subagent 可以指定 permissionMode 与工具子集——一个只读的 code-reviewer 是常见配置）。fork 型子 agent 继承历史所以启动时上下文就大，适合”接着当前状态并行做一件事”；spawn 型从零开始，适合”独立探索”。

六、子 agent 的成本与取舍

1. 15 倍

Anthropic 的数字：agent 约 4 倍于聊天、多 agent 约 15 倍。原因：每个子 agent 有自己的系统提示、工具定义、读取的内容（都是输入 token），并行的子 agent 之间无法共享缓存前缀（各自的历史不同），主 agent 还要读所有摘要。子 agent 的 token 不因”结果只回摘要”而消失——它只是不进主窗口，账单上都在。

%% 图：同一任务三种形态的 token 量级（Anthropic 的倍数：聊天 1、单 agent 约 4、多 agent 约 15）——子 agent 的 token 不进主窗口，但每个子 agent 有自己的系统提示、工具定义、读取内容，并行的子 agent 之间无法共享缓存前缀，主 agent 还要读所有摘要；账单上都在
%%{init: {"xyChart": {"width": 760, "height": 340, "plotReservedSpacePercent": 60}, "themeVariables": {"xyChart": {"plotColorPalette": "#c0392b, #5b8fd6, #4d9a5c"}}}}%%
xychart-beta
    title "相对 token 用量（聊天 = 1）"
    x-axis ["聊天", "单 agent", "多 agent（子 agent 并行）"]
    y-axis "倍数" 0 --> 16
    bar [1, 4, 15]

2. 什么时候值得

委派子 agent 在不同情形下是否值得

情形	值得吗
探索性搜索（读几十个文件找线索）	值得：主窗口省下几万 token 的噪声
几个真正独立的子任务	值得：并行省墙钟时间
需要不同权限 / 工具 / 模型的角色（只读审查、危险操作隔离）	值得：安全边界
串行的、每步依赖上一步的任务	不值得：没有并行收益，多出派发与摘要的开销
结果需要完整过程（不是摘要）	不值得：摘要丢信息
为了”看起来像团队”	不值得

3. 调试

子 agent 让 trace 变成一棵树（会话 → 子会话 → 步骤——第九篇、L5），失败可能发生在子 agent 里而主 agent 只看到”任务失败”或一个误导性的摘要。每个子 agent 的完整轨迹要能从日志追到（DeepSeek Harness 的”发现每个创建的子 agent”是 subagent 接缝的一部分）。

七、实践建议

1. 给运行时接 L2 的三条线：卸载阈值（spill 或截断 + 定位符）、清理（压缩前修剪）、压缩（在思考链边界、写进日志、有回退模型）。
2. 让模型看到预算：提供一个 get_context_remaining 类工具或在系统提示里注入剩余预算，观察模型是否更早收敛。
3. 把目标做成事件：plan / todo / goal 进日志、每步可见，作为压缩的材料。
4. 子 agent 先做只读的探索型：spawn、受限工具、返回结构化摘要；比较主窗口 token 与端到端成本。
5. 每个子 agent 有自己的预算与卫士，轨迹可从父会话追到。
6. 试一次跨 harness 委派：用 DeepSeek Harness 的 subagent-claude-code 或自己的 ACP 桥接，把一个子任务交给另一家 harness，看结果格式与成本。

八、本文小结

• 策略到实现：卸载——DeepSeek Harness 的 spill 包组（存储 + 后端 + 策略，返回定位符）、Codex 的截断与”无大于 10K token 的项”规则；清理——compaction-tool-result-pruner、Codex 会话记忆压缩、Claude Code 微压缩；压缩——Codex compact* 模块族（本地 / 远程加密 v2 / 预算 / 回退）、DeepSeek Harness compaction 五个包（自动 / 命令 / 修剪 / 图片卸载）、Claude Code 83.5%；都是多步可组合、写进日志、在思考链边界触发。
• 复述：DeepSeek Harness 的 plan / todo / goal 三个包把目标与进度做成模型近端的事件；Codex 的 plan 与 get_context_remaining（让模型看到剩余预算）；Claude Code 的 todo 与 CLAUDE.md 重注入。
• 子 agent 三种形态：Claude Code 的 subagent（结果回主 agent、token 低）与 agent teams（独立、互通、共享任务列表、token 高、实验）；Codex 的 multi_agents / agent-roles 与 GPT-5.6 ultra；DeepSeek Harness 七种后端——spawn / fork（继承历史）/ 驱动 / SDK / ACP / Claude Code / Codex——harness 互操作已是事实。
• 成本：多 agent 约 15 倍 token；只在隔离、并行、专业化三个理由之一成立时用；子 agent 的效果取决于派发指令与返回摘要；trace 是树。

九、自测

1. 一个 agent 的工具经常返回 30K token 的日志。Codex 的”无大于 10K token 的项”规则与 DeepSeek Harness 的 spill 各会怎么处理？

   答案

   Codex：处理器按上限截断输出（行数 / 字节），超出部分不进上下文，模型需要时用范围参数或专门工具再读——规则是代码审查层面的硬约束。DeepSeek Harness：spill 的结果策略判断超阈值，存储服务把全文存到本地后端，上下文里只留带取回指引的定位符（spill://…、行数、预览），模型用读取工具按需取回；后端与策略可替换。两者都是 L2 的”卸载”。详见第二章。

2. 为什么 compaction-tool-result-pruner 要在压缩之前运行？这对应 L2 的哪条原则？

   答案

   先修剪超大的、已被消费的工具输出，要压缩的历史就少，摘要调用更便宜、损失更小；且修剪是可恢复的（内容可再取）而摘要是有损的。对应 《Prompt 与上下文工程（04）：上下文预算与压缩——给每一部分定配额，超了怎么办》”代价递增：清理在压缩之前”。详见第二章、第三章。

3. Codex 的 get_context_remaining 工具把什么变成了模型的输入？预期效果是什么？

   答案

   把剩余的上下文预算变成模型可查的信息，让模型自己决定何时收敛、何时卸载或总结，而不是被运行时在阈值处强制压缩。预期是模型在预算紧张时主动写计划 / 缩短输出，压缩发生得更少、更可控——把一部分上下文管理从运行时交给了模型。详见第四章。

4. 一个任务：把 12 个微服务的 README 各总结成三句话并汇总。用 subagent 还是 agent teams？spawn 还是 fork？为什么？

   答案

   subagent（结果只需摘要回主 agent，不需要子任务之间讨论），spawn（每个子任务独立、不需要父会话的历史，从零开始上下文最小）；12 个并行，主 agent 汇总 12 条三句话摘要。agent teams 与 fork 都会多花 token 而没有收益。详见第五章、第六章。

5. DeepSeek Harness 能把 Claude Code 与 Codex 作为子 agent 拉起。这依赖哪些已有的互操作基础？对”选哪个 harness”这个问题意味着什么？

   答案

   依赖：三家都是 MCP client（共享工具）、都读 SKILL.md（共享技能）、都读项目指令文件（AGENTS.md / CLAUDE.md）、Claude Code 与 Codex 都有可脚本化的无头 / SDK 入口与 hooks（hooks/ 包组有两家的桥接）、ACP 一类自动化协议。意味着 harness 之间不是互斥的选择——可以用一个作为运行时与日志中心、把子任务委派给另一个更擅长的；问题从”选哪个”变成”怎么组合”。详见第五章。

---

• 上一篇
  工具、Agent 与 harness（03）：agent 运行时——会话、持久化与 durable execution

COMMENTS

评论存放在 GitHub Discussions， 用 GitHub 账号登录即可发表，支持 Markdown。 想针对正文某句话说？选中那段文字，点浮出的「评论」即可划线评论；觉得哪里写错了，发表时勾上「同时提交 Issue」。 有人回复你时 GitHub 会按你的通知设置发邮件，不用守在这里。