自己部署使用过如codexHermes这些的大家使用过程中可能都经历过自己花钱买的api token消耗飞快就问还敢接主流模型吗我给我女朋友改论文用的Hermes哪怕买的中转接口一个月也花了20块。。。generic agent后续称ga近段时间爆火是继openclawHermes之后的又一爆火agent周末也是抽时间自己本地安装试用了一下学习了一下其中的设计原理半个月涨了 5k star登上了 GitHub trending 第一它到底做对了什么而ga号称toekn花销是其他主流agent的十分之一如果用一句话概括那就是上下文信息密度最大化。不追求上下文有多长只追求每一个 token 都在为当前决策服务本文也可当做我自己学习后的个人理解笔记和总结输出意在分享ga背后的设计哲学一、GenericAgent 的第一性原理一句话概括长期运行 Agent 面临的两大根本挑战上下文爆炸这类agent往往需要处理多轮对话其中的对话内容工具调用返回结果等信息都是海量的而上下文一大我们都知道由于注意力稀释等原因模型就会遗漏关键信息与此同时这也很消耗token经验无法有效积累与复用我们早期使用openclaw同一个问题你多轮对话解决一次如果你不主动沉淀skill下一次你依然需要那么多轮对话或者哪怕你沉淀skill了但沉淀的不够好下次还会多轮对话往复来也很消耗人力也很消耗token那ga是怎么解决的呢其实这就体现出了它的极简艺术可以说从它的原子工具集到分层记忆架构亦或是上下文截断与压缩都体现了一句话不追求上下文的长度而追求上下文的信息密度解决的都是一个问题在有限的上下文预算内最大化每一个 token 对当前决策的贡献ga通过是的四个核心机制最小原子工具集——减少先天噪声分层按需记忆——只加载当前需要的上下文截断与压缩——主动瘦身反思驱动的自我进化——让未来的上下文更精炼二、系统全貌其实如果你有研究过openclaw也好Hermes也好任何这种agent的执行流程你就会发现他们是相似的ga这里其实也大差不差这里就贴一下ga的运行流程图吧┌──────────────────────┐ │ 构建执行上下文 │ │ (记忆工具任务历史) │ └──────────┬───────────┘ │ ▼ ┌──────────────────────┐ │ LLM 推理决策 │ └──────┬───────┬───────┘ │ │ 直接输出│ │工具调用 ▼ ▼ ┌──────┐ ┌──────────────┐ │ 回复 │ │ 统一分发器 │ │ 用户 │ │ → 本地执行器 │ └──────┘ └──────┬───────┘ │ ▼ ┌──────────────┐ │ 结构化反馈 │ │ 更新系统状态 │ └──────┬───────┘ │ ▼ 继续下一轮循环ga这里有两种运行模式交互模式也就是常见的用户发起任务ga响应执行反射模式两种触发方式一个是看门狗模式监控环境变化如新文件出现、错误日志产生一旦检测到就立即触发 GA 任务另一个是定时任务模式基于时间规则在特定间隔或精确时间点生成 GA 任务他们背后的原理其实很简单一个轻量级脚本定期检查条件当规则被触发时脚本将返回的字符串作为标准任务分发给 GA CLI下面开始才是我最想讲也是我觉得最有意思的地方三、最小原子工具集——用 9 个工具覆盖完整能力环说实话一开始看到这里我就很好奇至少目前我了解到的主流agent是没有这么做的带着这份好奇我开始往下了解以下这段话我觉得很有意思想象你走进一家五金店。你需要拧一颗螺丝店员递给你一本 200 页的工具目录里面有 53种不同的螺丝刀——十字的、一字的、六角的、带棘轮的、电动的、可弯曲的……你需要先花 10 分钟翻阅目录理解每种螺丝刀的区别然后才能做出选择。而另一家店只给你一把通用螺丝刀和一个万能批头套装。你拿起来就能干活。对于 LLM Agent来说翻阅工具目录的代价远比你想象的大。因为每一轮对话中所有可用工具的定义都会被注入到上下文中。工具越多这些定义占用的 token就越多——而且这是每轮都要重复支付的固定成本那首先考虑的就是工具膨胀会带来哪些代价呢提示词层面Prompt Level的上下文预算挤占这很好理解我工具加载的越多往提示词上下文放的也就越多策略层面Policy Level的决策复杂度增长每在上下文中多加一个工具模型就要思考的更多到底要选哪个工具就可能会削弱工具使用模式的稳定性增加执行错误和不必要重试的概率这里给出教程中提供的数据对比那要我说ga采取的便是不要瑞士军刀要乐高积木通过9个最原子的工具能实现几十几百种工具的效果┌─────────────────────────────────────────────────────────┐ │ GA 原子工具集架构 │ ├──────────────┬──────────────────────────────────────────┤ │ 能力类 │ 工具 │ ├──────────────┼──────────────────────────────────────────┤ │ 文件操作 │ file_read · file_patch · file_write │ │ 代码执行 │ code_run │ │ 网页交互 │ web_scan · web_execute_js │ │ 记忆管理 │ update_working_checkpoint │ │ │ start_long_term_update │ │ 人机协作 │ ask_user │ └──────────────┴──────────────────────────────────────────┘具体这几种工具的设计和作用我这里就不展开说明了大家如果感兴趣可以自行了解其实这里面我觉得也有很多值得学习的细节所在还有一点很有意思我想当单出来说说论文指出理论上 Agent 可以仅凭 code_run 一个工具完成所有任务——通过编写自定义脚本它能复制其他每个工具的功能。因此其余 8 个工具的存在不是为了扩展 Agent 的能力边界而是作为专用快捷方式specialized shortcuts 来降低决策成本和操作开销。论文将这种设计称为工具脚手架harness——它让 Agent 专注于高效解决问题而不必为每个简单操作都从头编写代码。当任务执行失败时GA 通过一个清晰的三步渐进恢复流程来处理局部修正分析当前错误信息做小幅定向调整后重试策略切换如果失败持续放弃当前方案强制切换到全新策略或搜索环境中缺失的信息人类介入如果所有自动化尝试均失败暂停执行并请求人类干预这个结构化设计防止了 Agent 盲目重复同样的错误。通过触发渐进增强的纠正动作它确保 Agent 能够突破死胡同使长期学习保持在正确的轨道上。四、分层记忆架构其实记忆这一块几乎所有主流agent现在都是在做长期记忆短期记忆的方式短期记忆需要满足条件才能晋升为长期核心记忆保存剩下的不会消失会被存入history等角落吃灰只是内部具体实现有所不同所以研究ga也是在看它的长期记忆和短期记忆分别是怎么做的ga的长期记忆通过四层记忆架构来实现我现在这么说大家可能感觉不出来有多厉害下面看这张图的数据你是不是也会觉得夯爆了呢GA 将记忆组织为四个层次。论文明确指出在这个层级中L1 构成始终在线记忆L2 和 L3 共同构成长期记忆L4 提供持久存储用于追溯和审计。每层有明确的定位和准入标准。我们用一个图书馆的类比来帮助理解想象 GA 的记忆系统是一座图书馆L1 索引层就像图书馆的目录检索台——你不需要走进书架只需查目录就能知道你要的书在哪。它很小通常只有几百个token但能快速路由到任何需要的知识L2 事实层就像百科全书区——存放经过验证的、长期稳定的事实。比如服务器 IP 是 192.168.1.100或项目使用Python 3.11。准入门槛很高只有经过执行验证且跨任务可复用的信息才能写入L3 SOP层就像操作手册区——存放可复用的流程知识包括任务工作流、前置条件、关键执行步骤、常见故障案例及对应的调试恢复策略。比如如何从HuggingFace 下载数据集就是一条典型的 L3 SOPL4 归档层就像档案室——存放历史执行记录的压缩存档。它不用于日常注入平时大门紧闭。只有当需要追溯过往决策、审计历史操作时才会打开路由过程任务启动时GA 默认只注入元记忆和 L1索引层到上下文中。元记忆提供记忆系统的组织规则和更新边界L1提供紧凑的导航指针高频入口、关键词映射等当 LLM 在推理过程中发现需要某类知识时它沿着 L1→L2/L3 路由链通过 file_read 按需加载更深层的事实或 SOP内容加载的内容进入当前轮的上下文随着对话推进会被压缩流水线处理上文提到的元记忆可以理解为就是记录的一些规则和边界条件再就是ga的短期记忆了也就是工作记忆┌───────────────────────────────────────────────────────────┐ │ GA 记忆系统全景 │ ├───────────────┬──────────────┬────────────────────────────┤ │ 工作记忆 │ 始终在线记忆 │ 长期记忆 │ │ (草稿纸) │ (随身卡片) │ (图书馆) │ ├───────────────┼──────────────┼────────────────────────────┤ │ 轮次摘要 │ 元记忆核心 │ L2 事实 L3 SOP L4 归档 │ │ 轮次编号 │ L1 索引 │ │ │ key_info 块 │ │ │ ├───────────────┼──────────────┼────────────────────────────┤ │ 每轮注入 │ 启动时注入 │ 按需加载 │ └───────────────┴──────────────┴────────────────────────────┘论文的核心设计思路可以用一句话概括避免将所有保留的信息默认视为提示词常驻内容——只有一个小型的始终在线层保持可见更深层的记忆仅在需要时访问。典型的做法是在每次任务启动时把所有可能相关的记忆内容全部注入上下文——这就是为什么 Claude Code 和 OpenClaw 的提示词长度高达 2 万以上。而 GA 只注入一个紧凑的索引而这个L1索引并不会无限膨胀它被设计为了一个有界索引五、上下文截断与压缩许多 Agent 框架选择依赖扩展的上下文窗口高达 1Mtoken假设更多上下文意味着更好的推理。但实践表明这种做法不仅成本高昂还会引入更多幻觉。论文将当前模型在不产生幻觉的前提下能有效利用的上下文上限称为无幻觉上下文长度hallucination-free context length其量级大约比名义窗口小一个数量级。因此GA 选择了一条截然不同的路径将预算控制在 30k token 以内投资于压缩而非扩展——把高密度信息装进更小的窗口优于把稀释的内容灌入更大的窗口ga采取四阶段压缩来控制上下文Stage 1工具级截断——控制每件物品的大小第一道防线作用在每个工具的返回值上。在工具执行结果进入对话历史之前GA 会根据预设的阈值进行截断。截断策略采用对称头尾保留Symmetric Head-Tail Policy当输出超过阈值 时保留前和后字符中间部分替换为省略号。为什么保留头和尾而不是只保留头部因为在很多场景下尾部信息同样关键Stage 2Tag 级压缩——压缩旧轮次的包装Tag 级压缩大约每 5 轮执行一次以摊销计算成本。这个间隔还带来了一个额外收益未被修改的旧消息在相邻轮次之间保持不变使得约 80% 的轮次能够命中 prompt-cache显著降低了推理成本。处理方式分两类Stage 3消息驱逐——当瘦身不够时断舍离第一步更激进地重跑 Stage 2。 这次只豁免最近 4 条消息而非正常的 10 条对更多历史消息进行 Tag 级压缩。第二步FIFO 驱逐。 如果压缩后仍然超预算按先进先出顺序从最早的消息开始移除直到 降到 0.6B以下或者只剩 5 条消息。为什么目标是 0.6B而不是刚好 B 这个 60% 目标是刻意的过度修剪目的是为后续轮次预留空间。如果每次都只修剪到刚好不超预算那么下一轮新消息进来后立即又要触发驱逐导致频繁的压缩开销。60% 的目标提供了约 40% 的缓冲区。驱逐后的结构修复消息被移除后剩余的历史可能出现结构问题——比如开头是一条孤立的 tool_result 消息却没有对tool_use。GA 会进行轻量级的结构修复Stage 4工作记忆锚点——驱逐后的唯一长程记忆相当于把之前的消息清理掉但是留个指针后面模型可以通过指针找到之前发生了什么消息产生 ──→ Stage 1: 工具级截断 ──→ 进入对话历史 │ 每 ~5 轮触发 │ ▼ Stage 2: Tag 级压缩 (旧标签缩短旧快照替换) │ 超预算时触发 │ ▼ Stage 3: 消息驱逐 (激进压缩 → FIFO移除 → 结构修复) │ 每轮自动注入 │ ▼ Stage 4: 锚点注入 (20条摘要 轮次号 key_info)六、自进化这一块当初研究Hermes的时候有所了解原生openclaw不支持自进化不过龙虾强大的社区貌似最近有插件让龙虾也支持了这种能力其实这种自进化主要无外乎两种你在执行过程中发现问题反思并进化类似Reflection的思想定时反思类似于你上了一天班下班了回家总结复盘今天有哪些可以改进的地方写进小本本下次就会做的更好ga主要就是这三步Stage 1: 自然语言执行 Stage 2: SOP 蒸馏 Stage 3: 代码化执行 ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ │ 大量探索性推理 │ │ SOP 指导执行 │ │ 脚本直接执行 │ │ 大量试错分支 │ │ 少量适应性推理 │ │ 极少推理开销 │ │ 大量上下文重建 │ │ 中等上下文需求 │ │ 最小上下文需求 │ │ │ │ │ │ │ │ 信息密度: 低 │ │ 信息密度: 中 │ │ 信息密度: 高 │ │ 222k tokens │ │ 36k-66k tokens │ │ 23k tokens │ └──────────────────┘ └──────────────────┘ └──────────────────┘并非所有经验都值得保存。如果不加筛选地将所有执行记录写入长期记忆记忆库很快就会被一次性的调试信息、失败的尝试、以及过时的配置所污染。这就是垃圾进化Junk Evolution 问题。GA 通过两道守门机制来防止垃圾进化第一道门执行验证。 只有经过实际执行并验证成功的经验才能写入。“我觉得应该这样做不够——必须是我这样做了而且成功了”。第二道门跨任务可复用性。 一次性的、特定于当前任务上下文的信息不应写入长期记忆。写入的信息必须具有在未来任务中被重用的潜力。最后说一下我学完ga原理自己的感悟吧记得曾几何时在一次周会分享上我听老前辈常说一个概念少即是多传统后端设计是如此哪怕到了现在的agent许多设计思想仍然是相同的这里再借用hello-generic-agent里的一句话好的 Agent 设计不是做加法而是做减法
从generic agent中的学习——聊聊我对ga的极简agent设计哲学的理解
自己部署使用过如codexHermes这些的大家使用过程中可能都经历过自己花钱买的api token消耗飞快就问还敢接主流模型吗我给我女朋友改论文用的Hermes哪怕买的中转接口一个月也花了20块。。。generic agent后续称ga近段时间爆火是继openclawHermes之后的又一爆火agent周末也是抽时间自己本地安装试用了一下学习了一下其中的设计原理半个月涨了 5k star登上了 GitHub trending 第一它到底做对了什么而ga号称toekn花销是其他主流agent的十分之一如果用一句话概括那就是上下文信息密度最大化。不追求上下文有多长只追求每一个 token 都在为当前决策服务本文也可当做我自己学习后的个人理解笔记和总结输出意在分享ga背后的设计哲学一、GenericAgent 的第一性原理一句话概括长期运行 Agent 面临的两大根本挑战上下文爆炸这类agent往往需要处理多轮对话其中的对话内容工具调用返回结果等信息都是海量的而上下文一大我们都知道由于注意力稀释等原因模型就会遗漏关键信息与此同时这也很消耗token经验无法有效积累与复用我们早期使用openclaw同一个问题你多轮对话解决一次如果你不主动沉淀skill下一次你依然需要那么多轮对话或者哪怕你沉淀skill了但沉淀的不够好下次还会多轮对话往复来也很消耗人力也很消耗token那ga是怎么解决的呢其实这就体现出了它的极简艺术可以说从它的原子工具集到分层记忆架构亦或是上下文截断与压缩都体现了一句话不追求上下文的长度而追求上下文的信息密度解决的都是一个问题在有限的上下文预算内最大化每一个 token 对当前决策的贡献ga通过是的四个核心机制最小原子工具集——减少先天噪声分层按需记忆——只加载当前需要的上下文截断与压缩——主动瘦身反思驱动的自我进化——让未来的上下文更精炼二、系统全貌其实如果你有研究过openclaw也好Hermes也好任何这种agent的执行流程你就会发现他们是相似的ga这里其实也大差不差这里就贴一下ga的运行流程图吧┌──────────────────────┐ │ 构建执行上下文 │ │ (记忆工具任务历史) │ └──────────┬───────────┘ │ ▼ ┌──────────────────────┐ │ LLM 推理决策 │ └──────┬───────┬───────┘ │ │ 直接输出│ │工具调用 ▼ ▼ ┌──────┐ ┌──────────────┐ │ 回复 │ │ 统一分发器 │ │ 用户 │ │ → 本地执行器 │ └──────┘ └──────┬───────┘ │ ▼ ┌──────────────┐ │ 结构化反馈 │ │ 更新系统状态 │ └──────┬───────┘ │ ▼ 继续下一轮循环ga这里有两种运行模式交互模式也就是常见的用户发起任务ga响应执行反射模式两种触发方式一个是看门狗模式监控环境变化如新文件出现、错误日志产生一旦检测到就立即触发 GA 任务另一个是定时任务模式基于时间规则在特定间隔或精确时间点生成 GA 任务他们背后的原理其实很简单一个轻量级脚本定期检查条件当规则被触发时脚本将返回的字符串作为标准任务分发给 GA CLI下面开始才是我最想讲也是我觉得最有意思的地方三、最小原子工具集——用 9 个工具覆盖完整能力环说实话一开始看到这里我就很好奇至少目前我了解到的主流agent是没有这么做的带着这份好奇我开始往下了解以下这段话我觉得很有意思想象你走进一家五金店。你需要拧一颗螺丝店员递给你一本 200 页的工具目录里面有 53种不同的螺丝刀——十字的、一字的、六角的、带棘轮的、电动的、可弯曲的……你需要先花 10 分钟翻阅目录理解每种螺丝刀的区别然后才能做出选择。而另一家店只给你一把通用螺丝刀和一个万能批头套装。你拿起来就能干活。对于 LLM Agent来说翻阅工具目录的代价远比你想象的大。因为每一轮对话中所有可用工具的定义都会被注入到上下文中。工具越多这些定义占用的 token就越多——而且这是每轮都要重复支付的固定成本那首先考虑的就是工具膨胀会带来哪些代价呢提示词层面Prompt Level的上下文预算挤占这很好理解我工具加载的越多往提示词上下文放的也就越多策略层面Policy Level的决策复杂度增长每在上下文中多加一个工具模型就要思考的更多到底要选哪个工具就可能会削弱工具使用模式的稳定性增加执行错误和不必要重试的概率这里给出教程中提供的数据对比那要我说ga采取的便是不要瑞士军刀要乐高积木通过9个最原子的工具能实现几十几百种工具的效果┌─────────────────────────────────────────────────────────┐ │ GA 原子工具集架构 │ ├──────────────┬──────────────────────────────────────────┤ │ 能力类 │ 工具 │ ├──────────────┼──────────────────────────────────────────┤ │ 文件操作 │ file_read · file_patch · file_write │ │ 代码执行 │ code_run │ │ 网页交互 │ web_scan · web_execute_js │ │ 记忆管理 │ update_working_checkpoint │ │ │ start_long_term_update │ │ 人机协作 │ ask_user │ └──────────────┴──────────────────────────────────────────┘具体这几种工具的设计和作用我这里就不展开说明了大家如果感兴趣可以自行了解其实这里面我觉得也有很多值得学习的细节所在还有一点很有意思我想当单出来说说论文指出理论上 Agent 可以仅凭 code_run 一个工具完成所有任务——通过编写自定义脚本它能复制其他每个工具的功能。因此其余 8 个工具的存在不是为了扩展 Agent 的能力边界而是作为专用快捷方式specialized shortcuts 来降低决策成本和操作开销。论文将这种设计称为工具脚手架harness——它让 Agent 专注于高效解决问题而不必为每个简单操作都从头编写代码。当任务执行失败时GA 通过一个清晰的三步渐进恢复流程来处理局部修正分析当前错误信息做小幅定向调整后重试策略切换如果失败持续放弃当前方案强制切换到全新策略或搜索环境中缺失的信息人类介入如果所有自动化尝试均失败暂停执行并请求人类干预这个结构化设计防止了 Agent 盲目重复同样的错误。通过触发渐进增强的纠正动作它确保 Agent 能够突破死胡同使长期学习保持在正确的轨道上。四、分层记忆架构其实记忆这一块几乎所有主流agent现在都是在做长期记忆短期记忆的方式短期记忆需要满足条件才能晋升为长期核心记忆保存剩下的不会消失会被存入history等角落吃灰只是内部具体实现有所不同所以研究ga也是在看它的长期记忆和短期记忆分别是怎么做的ga的长期记忆通过四层记忆架构来实现我现在这么说大家可能感觉不出来有多厉害下面看这张图的数据你是不是也会觉得夯爆了呢GA 将记忆组织为四个层次。论文明确指出在这个层级中L1 构成始终在线记忆L2 和 L3 共同构成长期记忆L4 提供持久存储用于追溯和审计。每层有明确的定位和准入标准。我们用一个图书馆的类比来帮助理解想象 GA 的记忆系统是一座图书馆L1 索引层就像图书馆的目录检索台——你不需要走进书架只需查目录就能知道你要的书在哪。它很小通常只有几百个token但能快速路由到任何需要的知识L2 事实层就像百科全书区——存放经过验证的、长期稳定的事实。比如服务器 IP 是 192.168.1.100或项目使用Python 3.11。准入门槛很高只有经过执行验证且跨任务可复用的信息才能写入L3 SOP层就像操作手册区——存放可复用的流程知识包括任务工作流、前置条件、关键执行步骤、常见故障案例及对应的调试恢复策略。比如如何从HuggingFace 下载数据集就是一条典型的 L3 SOPL4 归档层就像档案室——存放历史执行记录的压缩存档。它不用于日常注入平时大门紧闭。只有当需要追溯过往决策、审计历史操作时才会打开路由过程任务启动时GA 默认只注入元记忆和 L1索引层到上下文中。元记忆提供记忆系统的组织规则和更新边界L1提供紧凑的导航指针高频入口、关键词映射等当 LLM 在推理过程中发现需要某类知识时它沿着 L1→L2/L3 路由链通过 file_read 按需加载更深层的事实或 SOP内容加载的内容进入当前轮的上下文随着对话推进会被压缩流水线处理上文提到的元记忆可以理解为就是记录的一些规则和边界条件再就是ga的短期记忆了也就是工作记忆┌───────────────────────────────────────────────────────────┐ │ GA 记忆系统全景 │ ├───────────────┬──────────────┬────────────────────────────┤ │ 工作记忆 │ 始终在线记忆 │ 长期记忆 │ │ (草稿纸) │ (随身卡片) │ (图书馆) │ ├───────────────┼──────────────┼────────────────────────────┤ │ 轮次摘要 │ 元记忆核心 │ L2 事实 L3 SOP L4 归档 │ │ 轮次编号 │ L1 索引 │ │ │ key_info 块 │ │ │ ├───────────────┼──────────────┼────────────────────────────┤ │ 每轮注入 │ 启动时注入 │ 按需加载 │ └───────────────┴──────────────┴────────────────────────────┘论文的核心设计思路可以用一句话概括避免将所有保留的信息默认视为提示词常驻内容——只有一个小型的始终在线层保持可见更深层的记忆仅在需要时访问。典型的做法是在每次任务启动时把所有可能相关的记忆内容全部注入上下文——这就是为什么 Claude Code 和 OpenClaw 的提示词长度高达 2 万以上。而 GA 只注入一个紧凑的索引而这个L1索引并不会无限膨胀它被设计为了一个有界索引五、上下文截断与压缩许多 Agent 框架选择依赖扩展的上下文窗口高达 1Mtoken假设更多上下文意味着更好的推理。但实践表明这种做法不仅成本高昂还会引入更多幻觉。论文将当前模型在不产生幻觉的前提下能有效利用的上下文上限称为无幻觉上下文长度hallucination-free context length其量级大约比名义窗口小一个数量级。因此GA 选择了一条截然不同的路径将预算控制在 30k token 以内投资于压缩而非扩展——把高密度信息装进更小的窗口优于把稀释的内容灌入更大的窗口ga采取四阶段压缩来控制上下文Stage 1工具级截断——控制每件物品的大小第一道防线作用在每个工具的返回值上。在工具执行结果进入对话历史之前GA 会根据预设的阈值进行截断。截断策略采用对称头尾保留Symmetric Head-Tail Policy当输出超过阈值 时保留前和后字符中间部分替换为省略号。为什么保留头和尾而不是只保留头部因为在很多场景下尾部信息同样关键Stage 2Tag 级压缩——压缩旧轮次的包装Tag 级压缩大约每 5 轮执行一次以摊销计算成本。这个间隔还带来了一个额外收益未被修改的旧消息在相邻轮次之间保持不变使得约 80% 的轮次能够命中 prompt-cache显著降低了推理成本。处理方式分两类Stage 3消息驱逐——当瘦身不够时断舍离第一步更激进地重跑 Stage 2。 这次只豁免最近 4 条消息而非正常的 10 条对更多历史消息进行 Tag 级压缩。第二步FIFO 驱逐。 如果压缩后仍然超预算按先进先出顺序从最早的消息开始移除直到 降到 0.6B以下或者只剩 5 条消息。为什么目标是 0.6B而不是刚好 B 这个 60% 目标是刻意的过度修剪目的是为后续轮次预留空间。如果每次都只修剪到刚好不超预算那么下一轮新消息进来后立即又要触发驱逐导致频繁的压缩开销。60% 的目标提供了约 40% 的缓冲区。驱逐后的结构修复消息被移除后剩余的历史可能出现结构问题——比如开头是一条孤立的 tool_result 消息却没有对tool_use。GA 会进行轻量级的结构修复Stage 4工作记忆锚点——驱逐后的唯一长程记忆相当于把之前的消息清理掉但是留个指针后面模型可以通过指针找到之前发生了什么消息产生 ──→ Stage 1: 工具级截断 ──→ 进入对话历史 │ 每 ~5 轮触发 │ ▼ Stage 2: Tag 级压缩 (旧标签缩短旧快照替换) │ 超预算时触发 │ ▼ Stage 3: 消息驱逐 (激进压缩 → FIFO移除 → 结构修复) │ 每轮自动注入 │ ▼ Stage 4: 锚点注入 (20条摘要 轮次号 key_info)六、自进化这一块当初研究Hermes的时候有所了解原生openclaw不支持自进化不过龙虾强大的社区貌似最近有插件让龙虾也支持了这种能力其实这种自进化主要无外乎两种你在执行过程中发现问题反思并进化类似Reflection的思想定时反思类似于你上了一天班下班了回家总结复盘今天有哪些可以改进的地方写进小本本下次就会做的更好ga主要就是这三步Stage 1: 自然语言执行 Stage 2: SOP 蒸馏 Stage 3: 代码化执行 ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ │ 大量探索性推理 │ │ SOP 指导执行 │ │ 脚本直接执行 │ │ 大量试错分支 │ │ 少量适应性推理 │ │ 极少推理开销 │ │ 大量上下文重建 │ │ 中等上下文需求 │ │ 最小上下文需求 │ │ │ │ │ │ │ │ 信息密度: 低 │ │ 信息密度: 中 │ │ 信息密度: 高 │ │ 222k tokens │ │ 36k-66k tokens │ │ 23k tokens │ └──────────────────┘ └──────────────────┘ └──────────────────┘并非所有经验都值得保存。如果不加筛选地将所有执行记录写入长期记忆记忆库很快就会被一次性的调试信息、失败的尝试、以及过时的配置所污染。这就是垃圾进化Junk Evolution 问题。GA 通过两道守门机制来防止垃圾进化第一道门执行验证。 只有经过实际执行并验证成功的经验才能写入。“我觉得应该这样做不够——必须是我这样做了而且成功了”。第二道门跨任务可复用性。 一次性的、特定于当前任务上下文的信息不应写入长期记忆。写入的信息必须具有在未来任务中被重用的潜力。最后说一下我学完ga原理自己的感悟吧记得曾几何时在一次周会分享上我听老前辈常说一个概念少即是多传统后端设计是如此哪怕到了现在的agent许多设计思想仍然是相同的这里再借用hello-generic-agent里的一句话好的 Agent 设计不是做加法而是做减法
