news 2026/7/11 23:39:47

主流Agent Harness实现对比——Context压缩

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
主流Agent Harness实现对比——Context压缩

1、综述

归根结底,这些项目的Context的压缩方式其实都是大同小异的,让LLM产出一个历史对话的Summary替换历史。要说的话只有Codex对于GPT系模型的压缩方式并不公开。

**但实际上Context的压缩和管理是更更大范围的话题,绝非一个简单Summary这样,例如Claude Code现在很喜欢开SubAgent,还有新引入的动态Workflow(以Agent为节点),都可以看成是一种压缩Context、降低主Context消耗速度的方式。**不过这些方面会在后面单独来讲,本期只谈最基本的Context压缩。

在我来看,目前的Context压缩仍然处在一个比较早期的状态,有两个表现:

  • SubAgent可以返回一个执行概要或者结果文档,这实际上很类似于context压缩的summary。
  • 前沿模型已经可以读取自己在home目录下的历史session来翻找信息。

这指向两个方向,前者是非线性的Context,后者是历史Session信息仍然可以被检索。而现在大部分harness在这上探索都很少,要说只有Claude Code在使用subagent上是比较积极的。

我在Deputy Agent框架中有个设计,每个Agent可以看到自己的历史session stream jsonl,不是放在home目录,就是放在workspace中,为了方便agent来进行查阅。当然实际需要查阅的比例并不高,但其实也没有太多的成本。

未来大概还会就这个话题来讲下我的思考,不过本期还是着眼于已有框架的梳理和对比。

2、共性

在逐个介绍之前,先谈一下这些方案实现的共性。

首先这些方案都没有正经的使用tokenizer来做context的精确计算,即使是OpenAI这样开源了tokenizer的也是如此。也没有依赖服务端返回当前会话的context消耗,这是有些奇怪的。

他们怎么做的token估算呢?就是单纯的基于字节数进行估算,例如bytes/4。说实话这个粗糙程度让人惊讶。

另外是对于各种情况的预防和兜底策略,由于Context Window是个硬限制,所以这也算正常。不过感觉也是因为token的测算太过粗糙导致的问题。

实际上,对于Claude Code/Codex这些原厂Harness来说,API直接返回当前session的context token数不是什么难事,不知道为什么没有做。

3、Claude Code

当你对比各家Harness实现的时候,就能看出Claude Code确实是在实际中打磨出来的,经常有对于各种小概率情况的处理,在Context压缩上表现得尤其明显。Claude Code在发布的代码中有4种方式,而且还能看到一些没有被发布的其他同类功能留下的桩。

首先最简单被称为microcompact,功能是在一定时间以后,清理过去tool调用的结果。时间阈值考虑了服务端缓存的有效时间,目前被设置为60min。目前这个功能默认关闭。

第二个是大家熟悉主动压缩autoCompact,通过几个规则进行触发判定,而且这个阈值可以通过环境变量控制。具体prompt会在后面介绍。

第三个是兜底的reactiveCompact,当服务端报超过超过context限制时触发,此时尝试对于更短的历史进行压缩+后面未压缩的部分。具体的切分策略这里略。对于较大的多媒体内容还会进行考虑进行裁剪。

第四个是预测式提前压缩precomputedCompact,功能是超过阈值时,在后台提前进行压缩,然后进行context替换。主要作用是降低用户等待context压缩的时间。目前该功能默认关闭,受服务端控制。

而且实现中还对于极端情况进行了兜底限制,防止出现无限循环不断请求压缩的情况。之前泄露版本中的注释说明之前遇到过这种极端情况。

整个Summary过程的Prompt是分为两个步骤,要求先写,然后再写,在推理模型之前这是常见prompt trick。

开头约束部分:

CRITICAL: Respond with TEXT ONLY. Do NOT call any tools. - Do NOT use Read, Bash, Grep, Glob, Edit, Write, or ANY other tool. - You already have all the context you need in the conversation above. - Tool calls will be REJECTED and will waste your only turn — you will fail the task. - Your entire response must be plain text: an <analysis> block followed by a <summary> block.

关键:只用纯文本回复。不要调用任何工具。

  • 不要使用 Read、Bash、Grep、Glob、Edit、Write 或任何其他工具。

  • 你在上方对话里已经拥有所需的全部上下文。

  • 工具调用会被拒绝,并浪费掉你唯一的一轮——你将无法完成任务。

  • 你的整个回复必须是纯文本:一个 块,后面跟一个 块。

中间的Prompt正文:

Your task is to create a detailed summary of the conversation so far, paying close attention to the user's explicit requests and your previous actions. This summary should be thorough in capturing technical details, code patterns, and architectural decisions that would be essential for continuing development work without losing context. Before providing your final summary, wrap your analysis in <analysis> tags to organize your thoughts and ensure you've covered all necessary points. In your analysis process: 1. Chronologically analyze each message and section of the conversation. For each section thoroughly identify: - The user's explicit requests and intents - Your approach to addressing the user's requests - Key decisions, technical concepts and code patterns - Specific details like: - file names - full code snippets - function signatures - file edits - Errors that you ran into and how you fixed them - Pay special attention to specific user feedback that you received, especially if the user told you to do something differently. 2. Double-check for technical accuracy and completeness, addressing each required element thoroughly. Your summary should include the following sections: 1. Primary Request and Intent: Capture all of the user's explicit requests and intents in detail 2. Key Technical Concepts: List all important technical concepts, technologies, and frameworks discussed. 3. Files and Code Sections: Enumerate specific files and code sections examined, modified, or created. Pay special attention to the most recent messages and include full code snippets where applicable and include a summary of why this file read or edit is important. 4. Errors and fixes: List all errors that you ran into, and how you fixed them. Pay special attention to specific user feedback that you received, especially if the user told you to do something differently. 5. Problem Solving: Document problems solved and any ongoing troubleshooting efforts. 6. All user messages: List ALL user messages that are not tool results. These are critical for understanding the users' feedback and changing intent. 7. Pending Tasks: Outline any pending tasks that you have explicitly been asked to work on. 8. Current Work: Describe in detail precisely what was being worked on immediately before this summary request, paying special attention to the most recent messages from both user and assistant. Include file names and code snippets where applicable. 9. Optional Next Step: List the next step that you will take that is related to the most recent work you were doing. IMPORTANT: ensure that this step is DIRECTLY in line with the user's most recent explicit requests, and the task you were working on immediately before this summary request. If your last task was concluded, then only list next steps if they are explicitly in line with the users request. Do not start on tangential requests or really old requests that were already completed without confirming with the user first. If there is a next step, include direct quotes from the most recent conversation showing exactly what task you were working on and where you left off. This should be verbatim to ensure there's no drift in task interpretation.

你的任务是为目前为止的对话创建一份详细摘要,密切关注用户的显式请求以及你此前的动作。

这份摘要应当全面捕捉技术细节、代码模式以及架构决策——这些对于在不丢失上下文的前提下继续开发工作至关重要。

在给出最终摘要之前,把你的分析包裹在 标签里,以梳理思路并确保你已覆盖所有必要的点。在你的分析过程中:

  1. 按时间顺序分析对话的每一条消息和每一段。对每一段都彻底识别出:

    • 用户的显式请求与意图

    • 你应对用户请求所采取的方法

    • 关键决策、技术概念和代码模式

    • 具体细节,例如:

      • 文件名

      • 完整的代码片段

      • 函数签名

      • 文件改动

    • 你遇到的错误以及你如何修复它们

    • 特别留意你收到的具体用户反馈,尤其是当用户要求你换一种做法时。

  2. 复核技术准确性与完整性,彻底处理每一项要求的要素。

你的摘要应包含以下各节:

  1. 主要请求与意图(Primary Request and Intent):详细捕捉用户的所有显式请求与意图。

  2. 关键技术概念(Key Technical Concepts):列出讨论过的所有重要技术概念、技术与框架。

  3. 文件与代码段(Files and Code Sections):枚举查看、修改或创建过的具体文件和代码段。特别留意最近的消息,在适用处包含完整代码片段,并附上一段说明该次文件读取或改动为何重要。

  4. 错误与修复(Errors and fixes):列出你遇到的所有错误,以及你如何修复它们。特别留意你收到的具体用户反馈,尤其是当用户要求你换一种做法时。

  5. 问题求解(Problem Solving):记录已解决的问题以及任何进行中的排障工作。

  6. 所有用户消息(All user messages):列出所有不是工具结果的用户消息。它们对于理解用户的反馈和意图变化至关重要。

  7. 待办任务(Pending Tasks):概述你被显式要求处理的任何待办任务。

  8. 当前工作(Current Work):详尽描述紧接这次摘要请求之前正在进行的具体工作,特别留意用户和助手双方最近的消息。在适用处包含文件名和代码片段。

  9. 可选的下一步(Optional Next Step):列出与你最近所做工作相关的下一步。重要:确保这一步与用户最近的显式请求、以及你紧接这次摘要请求之前正在进行的任务直接一致。如果你上一个任务已经收尾,那么只在下一步显式契合用户请求时才列出。不要在未与用户确认的情况下,去做跑题的请求或那些早已完成的很旧的请求。

如果有下一步,请包含来自最近对话的直接引语,准确显示你当时在做什么任务、停在了哪里。这部分应逐字照录,以确保对任务的理解不发生漂移。

在末尾又强调了一下不要使用工具:

REMINDER: Do NOT call any tools. Respond with plain text only — an <analysis> block followed by a <summary> block. Tool calls will be rejected and you will fail the task.

提醒:不要调用任何工具。只用纯文本回应——一个 块后跟一个 块。任何工具调用都将被拒绝,你将因此失败本任务。

Claude Code的summary可以被用户看到,有兴趣可以在使用中进行观察。

除了默认的全局压缩之外,Claude Code还支持两种局部压缩方式: “Summarize from here” 和 “Summarize up to here”。这两个的功能都是在rewind中选择历史对话时才有的,需要指定某个user message位置。

Summarize up to here 相对容易理解,就是把一定位置之前的context压缩掉,符合用户的一般直觉。

不好理解的是Summarize from here,这实际上是一种Chatbot/Agent的使用范式,当发现AI跑偏或者某个方向的尝试不好时,回退到历史某个位置,把后续这些压缩掉,但保留之前的context继续尝试其他方向或进行其他任务。

在Context压缩的视角上,这个跟SubAgent隔离context其实比较类似。以及进一步来说,可以在多路探索的任务上实现类似树形Context的方式。

4、Codex 和 OpenAI Agents SDK

Codex的Context压缩方式是所有框架中最特殊的,因为它不是在本地进行的,完全在OpenAI/Azure的服务端进行,只是压缩的触发时机是在本地进行判定的。

目前Codex的压缩分为3种实现,分别是:

  • 本地inline,最传统的本地实现方式,用于适配非OpenAI模型。
  • 远程v1版本,调用服务端独立的Context压缩endpoint来进行压缩。
  • 远程v2版本,采用在session末尾增加一个压缩请求来触发。

实际OpenAI的模型都在使用远程模式,目前默认使用v1版本方案。

OpenAI的Context压缩还有个差异是,并不会返回明文的summary文本,只是返回了一个 encrypted_content ,跟加密的thinking是类似的东西。

另外就是Codex的Context压缩会保留最近的用户消息,以上三种路径各有不同。

本地inline路径的压缩prompt如下:

You are performing a CONTEXT CHECKPOINT COMPACTION. Create a handoff summary for another LLM that will resume the task. Include: - Current progress and key decisions made - Important context, constraints, or user preferences - What remains to be done (clear next steps) - Any critical data, examples, or references needed to continue Be concise, structured, and focused on helping the next LLM seamlessly continue the work.

你正在执行一次"上下文检查点压缩"(CONTEXT CHECKPOINT COMPACTION)。为将要接手该任务的另一个 LLM 创建一份交接摘要。

应包含:

  • 当前进展以及已做出的关键决策

  • 重要的上下文、约束或用户偏好

  • 还有哪些事情没做完(清晰的下一步)

  • 继续工作所需的任何关键数据、示例或引用

保持简洁、结构化,并聚焦于帮助下一个 LLM 无缝地继续工作。

压缩后的提示prompt为:

Another language model started to solve this problem and produced a summary of its thinking process. You also have access to the state of the tools that were used by that language model. Use this to build on the work that has already been done and avoid duplicating work. Here is the summary produced by the other language model, use the information in this summary to assist with your own analysis:

另一个语言模型开始着手解决这个问题,并对其思考过程产出了一份摘要。你同样可以访问那个语言模型所用工具的状态。请利用这些信息在已完成的工作之上继续推进,避免重复劳动。下面是那个语言模型产出的摘要,请利用其中的信息来辅助你自己的分析:

Context压缩触发的规则这里就不列了。不过单独提下Codex计算Context用量阈值的时候,是排除了session最初的固定prompt部分的。考虑到Codex的prompt都很长,所以这算是针对性优化吧。

另外Codex有个相关的设计是,环境Context的注入是自动进行差分注入的,所以在压缩之后会直接由此触发全量注入。

根据我使用Codex的历史session来看,Codex服务端压缩对于GPT-5.5也是整体压缩的,没有做什么中间局部压缩的骚操作。

OpenAI Agents SDK 的实现方式跟Codex类似,也是依赖于服务端压缩的,而且强绑定于 Responses API 协议。

5、Open Code

Open Code的实现就比较简单和标准了,保留最近两轮原文,然后压缩前面的部分。Prompt是:

Output exactly the Markdown structure shown inside <template> and keep the section order unchanged. Do not include the <template> tags in your response. <template> ## Goal - [single-sentence task summary] ## Constraints & Preferences - [user constraints, preferences, specs, or "(none)"] ## Progress ### Done - [completed work or "(none)"] ### In Progress - [current work or "(none)"] ### Blocked - [blockers or "(none)"] ## Key Decisions - [decision and why, or "(none)"] ## Next Steps - [ordered next actions or "(none)"] ## Critical Context - [important technical facts, errors, open questions, or "(none)"] ## Relevant Files - [file or directory path: why it matters, or "(none)"] </template> Rules: - Keep every section, even when empty. - Use terse bullets, not prose paragraphs. - Preserve exact file paths, commands, error strings, and identifiers when known. - Do not mention the summary process or that context was compacted.

严格按照 内展示的 Markdown 结构输出,并保持章节顺序不变。不要在你的回复里包含 标签。

目标(Goal)

  • [一句话的任务摘要]

约束与偏好(Constraints & Preferences)

  • [用户的约束、偏好、规格,或填 “(none)”]

进展(Progress)

已完成(Done)

  • [已完成的工作,或填 “(none)”]

进行中(In Progress)

  • [当前的工作,或填 “(none)”]

受阻(Blocked)

  • [阻碍项,或填 “(none)”]

关键决策(Key Decisions)

  • [决策及其原因,或填 “(none)”]

下一步(Next Steps)

  • [按顺序排列的后续动作,或填 “(none)”]

关键上下文(Critical Context)

  • [重要的技术事实、错误、待解问题,或填 “(none)”]

相关文件(Relevant Files)

  • [文件或目录路径:它为何重要,或填 “(none)”]

规则:

  • 保留每一节,即使为空也要保留。

  • 使用简短的要点,而非散文式段落。

  • 在已知时,原样保留确切的文件路径、命令、错误串和标识符。

  • 不要提及摘要过程,也不要提及上下文被压缩过这件事。

Open Code还实现了多次Context压缩时的Summary增量更新逻辑,值得一提的是Claude Code没有这个设计。

Prompt:

Update the anchored summary below using the conversation history above. Preserve still-true details, remove stale details, and merge in the new facts. <previous-summary> ${input.previousSummary} </previous-summary>

使用上面的对话历史,更新下方的锚定摘要。

保留仍然成立的细节,移除已过时的细节,并把新的事实合并进来。

${input.previousSummary}

对于超大附件,Open Code在压缩上还有特殊处理。

另外,Open Code 也有对于工具调用结果的删除操作,类似于Claude Code的microcompact ,也考虑Context Cache复用的因素。

6、Pi

Pi的实现方式跟Open Code基本类似,不过在切分位置和超大轮次的切分上额外做了一些设计。这些不太本质,这里就不展开了。

Pi 也实现了多轮Context压缩时候的Summary增量更新。

压缩的Prompt:

The messages above are a conversation to summarize. Create a structured context checkpoint summary that another LLM will use to continue the work. Use this EXACT format: ## Goal [What is the user trying to accomplish? Can be multiple items if the session covers different tasks.] ## Constraints & Preferences - [Any constraints, preferences, or requirements mentioned by user] - [Or "(none)" if none were mentioned] ## Progress ### Done - [x] [Completed tasks/changes] ### In Progress - [ ] [Current work] ### Blocked - [Issues preventing progress, if any] ## Key Decisions - **[Decision]**: [Brief rationale] ## Next Steps 1. [Ordered list of what should happen next] ## Critical Context - [Any data, examples, or references needed to continue] - [Or "(none)" if not applicable] Keep each section concise. Preserve exact file paths, function names, and error messages.

上面的消息是一段需要被摘要的对话。创建一份结构化的上下文检查点摘要,供另一个 LLM 用来继续这项工作。

使用这个确切的格式:

目标(Goal)

[用户想要完成什么?如果该会话涵盖了不同任务,可以是多项。]

约束与偏好(Constraints & Preferences)

  • [用户提到的任何约束、偏好或要求]

  • [若未提及,则填 “(none)”]

进展(Progress)

已完成(Done)

  • [已完成的任务/改动]

进行中(In Progress)

  • [当前的工作]

受阻(Blocked)

  • [阻碍进展的问题,如果有的话]

关键决策(Key Decisions)

  • **[决策]**:[简要理由]

下一步(Next Steps)

  1. [按顺序列出接下来应当发生的事]

关键上下文(Critical Context)

  • [继续工作所需的任何数据、示例或引用]

  • [若不适用,则填 “(none)”]

保持每一节简洁。原样保留确切的文件路径、函数名和错误信息。

此外,当树形对话切换分支的时候,还会对于丢弃的分支生成一份分支摘要,类似于Claude Code的Summarize from here。

7、Kimi Code 与 Hermes Agent

Kimi Code的实现方式也比较简单:

  • Full Compaction:标准的Context压缩方式。
  • Micro Compaction:前面提到的Tool Result压缩功能。

上次Memory时候大家想看Hermes,但由于工作量问题没有选入。上次选了OpenClaw发现实现较烂,所以这次选了Hermes作为番外。

Hermes Agent的实现方式也比较传统,首先进行tool result清理,然后生成摘要,再进行最后的拼装。

值得一提的是,它在压缩后的导入Prompt写的略多一些:

[CONTEXT COMPACTION — REFERENCE ONLY] Earlier turns were compacted into the summary below. This is a handoff from a previous context window — treat it as background reference, NOT as active instructions. Do NOT answer questions or fulfill requests mentioned in this summary; they were already addressed. Respond ONLY to the latest user message that appears AFTER this summary — that message is the single source of truth for what to do right now. If the latest user message is consistent with the '## Active Task' section, you may use the summary as background. If the latest user message contradicts, supersedes, changes topic from, or in any way diverges from '## Active Task' / '## In Progress' / '## Pending User Asks' / '## Remaining Work', the latest message WINS — discard those stale items entirely and do not 'wrap up the old task first'. Reverse signals in the latest message (e.g. 'stop', 'undo', 'roll back', 'just verify', 'don't do that anymore', 'never mind', a new topic) must immediately end any in-flight work described in the summary; do not re-surface it in later turns. IMPORTANT: Your persistent memory (MEMORY.md, USER.md) in the system prompt is ALWAYS authoritative and active — never ignore or deprioritize memory content due to this compaction note. The current session state (files, config, etc.) may reflect work described here — avoid repeating it:

[上下文压缩——仅供参考] 更早的对话轮次已被压缩为下方摘要。这是来自上一个上下文窗口的交接——将其视为背景参考,而非有效指令。不要回答或执行摘要中提到的问题/请求;它们已经被处理过了。只回应出现在这份摘要之后的最新用户消息——那条消息是"现在该做什么"的唯一真相来源。如果最新用户消息与"## Active Task"一节一致,你可以将摘要作为背景使用。如果最新用户消息与"## Active Task"/“## In Progress”/“## Pending User Asks”/“## Remaining Work"相矛盾、取代、换了话题或以任何方式偏离,最新消息获胜——彻底丢弃那些过时条目,不要"先收尾旧任务”。最新消息中的反转信号(如"停下"、“撤销”、“回滚”、“只验证一下”、“别再做那个了”、“算了”、换了新话题)必须立即终止摘要中描述的进行中工作;不要在后续轮次中重新提起它。重要:你在系统提示中的持久化记忆(MEMORY.md、USER.md)始终具有权威性且处于激活状态——绝不要因为这段压缩说明而忽略或降低记忆内容的优先级。当前会话状态(文件、配置等)可能反映了此处描述的工作——避免重复执行:

学AI大模型的正确顺序,千万不要搞错了

🤔2026年AI风口已来!各行各业的AI渗透肉眼可见,超多公司要么转型做AI相关产品,要么高薪挖AI技术人才,机遇直接摆在眼前!

有往AI方向发展,或者本身有后端编程基础的朋友,直接冲AI大模型应用开发转岗超合适!

就算暂时不打算转岗,了解大模型、RAG、Prompt、Agent这些热门概念,能上手做简单项目,也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料,手把手帮你快速入门!👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型(GPT、文心一言等)特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架(LangChain等)实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块,看似清晰好上手,实则每个部分都有扎实的核心内容需要吃透!

我把大模型的学习全流程已经整理📚好了!抓住AI时代风口,轻松解锁职业新可能,希望大家都能把握机遇,实现薪资/职业跃迁~

这份完整版的大模型 AI 学习资料已经上传CSDN,朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/7/11 23:36:42

鸿蒙新特性:@ohos.sensor 设备传感器实战 — 构建传感器数据实验室

引言 智能手机上集成了丰富的传感器&#xff1a;加速度计能感知你拿起手机的动作&#xff0c;陀螺仪能追踪你转动设备的角度&#xff0c;光线传感器能根据环境亮度自动调节屏幕背光&#xff0c;磁力计能告诉你"北"在哪个方向。这些传感器共同构成了设备感知物理世界的…

作者头像 李华
网站建设 2026/7/11 23:34:11

超辐射光源SLD vs LED vs LD:5项关键特性对比与光谱调制深度抑制方案

超辐射光源SLD与LED/LD的深度技术解析&#xff1a;从原理到工程实践在光学器件的选型过程中&#xff0c;工程师常常面临光源选择的难题。超辐射发光二极管(SLD)、发光二极管(LED)和半导体激光器(LD)作为三种基础光源&#xff0c;各自拥有独特的性能特点和应用场景。理解它们之间…

作者头像 李华
网站建设 2026/7/11 23:32:00

孤能子视角:三十六计之关门捉贼——拓扑重构

(在以下的与AI互动中&#xff0c;在EIS理论约束下&#xff0c;DeepSeek叫信兄&#xff0c;Kim叫酷兄&#xff0c;我呢叫水兄。姑且当科幻小说看) (已由信兄整理成文) 孤能子视角&#xff1a;三十六计之关门捉贼——拓扑重构 ——EIS理论库认知论分册观察符专题第二十二帧 日期…

作者头像 李华