不同 Coding Agent 的上下文管理机制有何差异？

核心回答

不同 Coding Agent 的差异，主要在宿主如何为每轮调用准备上下文：规则从哪里加载、代码和工具信息何时进入窗口、历史如何清理压缩、任务如何恢复，以及新增要求何时生效。同一个模型接入不同宿主，也可能看到不同的信息。

以具体机制来说：Claude Code 会清理旧工具输出并在需要时摘要，Skill 和子 Agent 也参与控制上下文占用；Codex CLI 的官方指南明确了分层 AGENTS.md 加载，并介绍用 compaction 衔接长任务；OpenCode 暴露自动压缩、旧结果清理和缓冲预算等配置。若说的是 DeepSeek Harness，还可以从它的完整会话日志与实际发给模型的消息分开管理来分析。

这些机制会随版本、模型接口和配置变化，不能把所有产品都归纳成“最近 N 轮加摘要”，也不能只用上下文窗口大小判断谁管理得更好。

展开说明

1. 先用相同职责比较，避免只比较产品名

一次模型调用可能同时使用项目规则、当前要求、工具描述、已读文件、执行轨迹和任务进度。比较宿主时，重点看这些信息的来源、适用范围、进入时机和退出方式。

例如，磁盘上存在 AGENTS.md 或 CLAUDE.md，不等于它已经进入当前调用；宿主还会决定发现路径、覆盖关系和消息组织。规则文件也不天然等于 API 的 system 角色。

另外，完整会话记录、当前有效上下文和跨会话记忆是不同对象。日志里保留了原始工具输出，不代表每轮都完整发送；压缩后能继续任务，也不代表模型仍能逐字访问过去所有内容。比较缓存时同样如此：前缀缓存优化计算和成本，不会代替内容筛选或扩展模型的有效窗口。

2. 几种具体实现的关注点不同

以下产品行为按 2026 年 10 月 17 日的官方文档说明，DeepSeek Harness 使用单独注明的固定版本。

Claude Code：当前文档描述的窗口包含对话、文件和命令输出、项目指令、记忆及已加载 Skill。接近上限时先清理旧工具输出，再按需要总结对话；可以通过 /compact 指定关注内容。Skill 正文按需读入，子 Agent 的工具探索可留在自己的上下文，主 Agent 接收结果汇总。因此，它既有历史压缩，也有“减少什么进入主窗口”的机制，不能只看摘要。

Codex：官方 Codex Prompting Guide 描述了 CLI 如何收集全局及从仓库根到当前工作目录的 AGENTS.md，按层组织后注入会话。该指南的压缩部分介绍通过 Responses 的 compaction 项承接旧状态，压缩表示可以包含不透明内容，并不一定是一段可读摘要。具体宿主和模型接口怎样调用压缩，需要结合所用版本与运行路径判断，不能把 API 能力直接当成所有 Codex 运行形态的同一实现。

OpenCode：当前配置将 compaction.auto、compaction.prune、compaction.reserved 分开，分别控制自动压缩、旧工具结果清理和保留缓冲；也允许通过 instructions 配置额外的指令文件路径或匹配模式。它把部分上下文策略开放为配置项，排查行为时就要检查生效配置，而不能只看所接模型。

DeepSeek Harness：以 dsh-v0.1.0-rc.8 为例，压缩是一项可选、后端可替换的能力。压缩的开始、摘要和结束事件写入会话日志，实际发给模型的消息则通过摘要替换指定范围的历史；二者各有职责。这种设计便于把留存记录、当前工作集和具体压缩策略分开，不能据此推断其他宿主也使用相同事件结构。

3. 用户执行中补充要求，也属于上下文管理

假设 Coding Agent 正在修复接口，用户补充“保持原有返回字段，只修改超时处理”。宿主需要接收这条消息，在合适的模型决策点加入当前上下文，并在后续压缩时保留这个新约束。

Claude Code 当前文档明确：工作中输入并提交的修正可以排队，正在执行工具时，会在工具调用完成后读入，并在同一轮继续调整。这不等于修改已经发出的模型请求，也不保证撤销已发生的外部操作。其他宿主可能采用停止当前轮后重启、排队到下一轮或专门的 steering 机制，需要分别看其支持方式。

比较这种能力时，要观察新指令何时被模型看到、旧计划是否被修正，以及最终代码是否遵循最新条件，而不仅是界面上有没有显示这条消息。

4. 实际评估要看跨窗口后还能否正确工作

可以用同一类修复任务比较：读取较多文件后，是否仍保留兼容要求和未完成事项；大工具输出是否能按需重新定位；恢复会话后是否知道哪些操作已经完成；子任务返回是否带回必要证据。

再结合 Token、等待时间和错误率判断取舍。保留更多历史可能增加成本和噪声，压缩过度则会丢失条件。需要的是在具体任务上保持有效信息，而不是某个宿主的层数越多越好。

常见追问

Claude Code 的“五层”或“三层上下文管理”是统一标准吗？

不是。它们可能是某篇源码分析的组织方式，也可能把规则、记忆、清理、摘要和恢复放在不同层次。应逐项说明实际机制及适用版本；工具结果清理、摘要生成和触发策略可以区分，但不必假定官方始终以同一层数实现。

DeepSeek 和 Claude Code 可以直接比较吗？

先确定指代。DeepSeek 模型影响上下文容量、接口和模型能力；Claude Code 是组织模型与工具运行的宿主。如果指 DeepSeek Harness，才适合比较其规则加载、会话和压缩机制。换成某个模型，不会自动获得另一套宿主的状态管理能力。

子 Agent 隔离能解决所有上下文问题吗？

能减少主窗口中的探索细节，但仍有任务转述和结果回传成本，也可能漏掉必要证据。是否从空上下文开始、是否继承历史或规则，由具体宿主和模式决定；独立上下文也不等于操作系统级的权限隔离。

对应教程

参考资料