正在加载，请稍候
Agent 跑过 50 次工具调用就丢目标，问题在 harness 而非窗口。拆解卸载、压缩、todo 复述、跨会话记忆四类机制，附五家公开阈值与企业知识库 AI 的记忆分层分工。
一个做客服工单的团队把内部知识库接进 Agent，检索命中率不差，可任务跑到第 50 次工具调用时，它开始重复询问用户已经确认过的字段。多数人第一反应是换更大的窗口。但这不是窗口的问题，是 harness（模型之外那一层）没管好上下文。
本文按 MarkTechPost 2026 年 9 月 12 日那篇拆解文的线索，把四类机制逐个拆开：卸载、压缩、todo 复述、跨会话记忆，再说明为什么企业侧知识库团队要把它和检索层分开设计。
Chroma 在 2025 年 7 月发布的技术报告测了 18 个模型，覆盖 GPT-4.1、Claude 4、Gemini 2.5 与 Qwen3，结论是输入变长之后，模型在简单检索任务上的表现也会越来越不稳定（Context Rot 技术报告）。
Anthropic 的上下文工程指南给了机制层解释：n 个 token 会形成 n² 组注意力配对，每加一个 token 都在消耗有限的注意力预算。上下文是收益递减的资源，不是一个桶。
把它放回 Agent 循环里更糟。Manus 团队公开的数字是：一个典型任务约 50 次工具调用，输入与输出 token 之比接近 100 比 1。每条观察结果落进窗口就不走了，最初的指令被推向窗口中段——而中段正好是召回退化区。
所以目标丢失不是模型偶发 bug，而是在足够长的任务上，对上下文不做管理的必然结果。AWS 的自主编码 Agent 设计指南把它拆成三条：上下文溢出、被打断导致偏离目标、长时间不维护状态（MarkTechPost 对 harness 的逐条拆解）。想让模型本身解决这件事，方向就偏了，这也是为什么 harness 比模型更关键。
Deep Agents 带了两条带硬数字的卸载规则。单次工具返回超过 20,000 token 时，写进文件系统，窗口里只留一个文件路径加前 10 行预览。会话上下文超过模型窗口的 85% 时，那些正文已经在磁盘上的旧写入与编辑调用被截断成一个指针。
Claude Code 把预算提前到首个 prompt 之前：自动记忆上限 200 行或 25KB，MCP 工具描述默认只列工具名，完整 schema 按需加载。压缩之后，任何再次读取超过 5,000 token 的文件，回来的也只是路径引用而不是正文。
子 Agent 是架构级的预算。官方文档给的例子是一个研究型子 Agent 读了 6,100 token 的文件，只把 420 token 的结论交回父级；Anthropic 的观察是子 Agent 可能烧掉几万 token 去探索，但只交付 1,000 到 2,000 token 的浓缩摘要。
AgentCore 的做法更彻底：协调者并行拉起 3 个浏览器子 Agent，各自跑在独立 MicroVM 里，分析型子 Agent 只接收它们的结构化发现。AWS 报出的期望运行时间是 4 到 6 分钟，顺序处理则要长得多。
压缩就是把接近窗口上限的对话摘要化，然后开一段新上下文重新开始。目标丢失最常发生在这步：一个有损摘要可能正好丢掉那条最关键的约束。
各家的承诺不同。Claude Code 的压缩 prompt 明确保留架构决策、未解决的缺陷和实现细节，丢弃冗余的工具输出；压缩完立刻重读最近改过的至多 5 个文件，重新加载与这些文件匹配的规则，并重新注入被调用的 skill 正文，每个上限 5,000 token、总量 25,000。官方文档也直言，对话早期的详细指令可能丢失——所以长期规则要放进项目根的 CLAUDE.md，从磁盘重新注入。
Deep Agents 把目标保全做成了结构：摘要是带字段的文档，专门留了会话意图、已产出物、下一步三栏。这三栏不是拍脑袋加的，是在强制摘要实验证明它能提升表现之后才写进实现的。原始完整记录同时落盘，被摘要掉的事实还能用 read_file 捞回来。
压缩也已经下沉到 API 层。OpenAI 的 Responses API 提供 context_management 里的 compact_threshold 服务端压缩，另有独立的 /responses/compact 端点，返回一个含加密压缩项的窗口，官方要求原样传回下一次调用，Codex 就是靠它撑住长编码任务。Claude 平台上的 compact_20260112 编辑允许写自定义指令，注意自定义指令会整体替换默认 prompt——压缩 prompt 是工程资产，不是一个开关。
压缩只在摘要那一刻保护目标，todo-state 保护的是中间每一轮。Manus 的做法很直白：Agent 建一个 todo.md，每推进一步就重写一遍清单并勾掉已完成项。
重写这个动作本身就是复述——把全局计划推到窗口末尾，也就是模型近期注意力最强的地方，缓解"lost in the middle"式的漂移。不需要改架构，用自然语言偏置模型自己的注意力即可。
但证据不是一边倒。Deep Agents 到 2026 年 7 月的 v0.7 把 TodoListMiddleware 改成按需开启，理由是三类任务上的评测显示关掉 todo 后 reward 略好、成本更低。LangChain 仍然建议在长多步任务、能力较弱的模型、以及需要展示进度的界面上把它打开。
Claude Code 保留 todo 列表，并在压缩后从磁盘重新注入 plan mode 里写下的计划。Anthropic 管这个通用模式叫结构化记笔记：把 NOTES.md 写在窗口之外，重置后自己读回来。Claude Plays Pokémon 的例子靠它跨几千个游戏步维持计数。
共同点是：目标要以可重写的产物存在，而不是只作为历史里的一条消息。消息会变旧、会被摘要；一个每几轮重写一次的文件永远是最新的、够短的，而且能扛过任何重置。值不值这几百 token，取决于模型和任务长度——这正是那轮评测想量清楚的。
任务结束后留下来的东西是另一件事。Claude Code 每次压缩后从磁盘重新注入项目根 CLAUDE.md 与自动记忆；AgentCore Memory 存事件，并在后台跑配置好的抽取策略，让协调者下次运行直接调 recall 工具，而不是重新调研一遍。AWS 明确警告：一条抽取策略都不配，事件是存下来了，但没有任何东西被抽出来供检索。
记忆怎么从"口口相传"变成可复用资产，可以对照我们此前记录的一线过程：Agent Memory 在企业研发团队的落地实录。
这里的成本常被低估。ETH Zurich 今年 2 月的那项研究发现，AGENTS.md 这类仓库上下文文件普遍没有提升任务成功率，反而抬高推理开销：模型自动生成的文件在两个基准上分别增加 20% 和 23%，开发者手写的也最多增加 19%。每次会话都要重新加载的记忆，等于对注意力预算固定收税。Claude Code 的建议对得上：CLAUDE.md 控制在 200 行以内，参考资料挪进 skill 或按路径生效的规则，用到才加载。
对做知识库的团队来说，最容易犯的错是把记忆和检索混成一件事。两者回答的问题不同：检索层回答"公司里有哪些规定、文档、历史工单"，是无状态查询；记忆层回答"这个任务做到了哪一步、做过什么决定、还缺什么"，是有状态的任务变量。把任务态塞进向量库，下一轮就会召回一堆相似但已过期的判断；把企业文档塞进记忆文件，则是让静态知识变成每轮都要交税的负担。
一条可用的分界：能写成 SOP、任何人任何时间问答案都一致的内容，放检索层；随任务推进而变、且只对本次任务有效的内容，放记忆层。前者更新走知识库的发布流程，后者由 harness 在任务边界写入。
| 实现 | 卸载与预算 | 压缩触发与保留项 | 目标复述 | 跨会话记忆 |
|---|---|---|---|---|
| Deep Agents | 工具返回超 20,000 token 落盘，窗口留路径加前 10 行；会话到窗口 85% 把旧编辑调用截断为指针 | 结构化摘要，含会话意图、产出物、下一步；全量记录落盘可用 read_file 找回 | 内置 write_todos，v0.7 起改为按需开启 | 文件系统与落盘记录 |
| Claude Code | 自动记忆 200 行或 25KB；MCP schema 默认延迟加载 | 压缩后重读最多 5 个最近文件；skill 正文每个 5,000 token、总计 25,000；早期详细指令可能丢失 | 保留 todo 列表，压缩后重注入 plan | CLAUDE.md 与自动记忆从磁盘重注入 |
| Manus | 靠 todo.md 与文件系统压低窗口占用 | 官方未给固定阈值 | 每步重写 todo.md，完成一次复述 | 公开资料未涉及 |
| OpenAI Codex | 服务端 context_management 接管预算 | compact_threshold 加 /responses/compact，返回的加密压缩项需原样回传 | 未见独立机制披露 | 公开资料未涉及 |
| Amazon Bedrock AgentCore | 子 Agent 各跑独立 MicroVM，只回传结构化发现 | 官方未给固定阈值 | 未见独立机制披露 | 事件存储加后台抽取策略，需手动配置 |
表里出现的空白不是遗漏，而是取舍：能公开的都是不暴露自家模型细节的工程参数，其余属于 harness 的竞争面。做选型时，把"哪些参数公开、哪些不公开"当成一个信号看，比逐个对比数字更有用。
浅层 Agent 指的就是模型在循环里调工具。它在两类问题上崩：上下文溢出，以及被打断后偏离目标，再加上长期不维护状态——这三条是 AWS 设计指南自己点名的。
100 比 1 的输入输出比意味着，每轮工具结果都在放大窗口占用，而写入速度远高于清理速度。50 次调用是一个很低的门槛：一次工单归因、一次对账核验、一次跨三个系统的数据补齐，都很容易超过它。
把下面两条写成验收项，而不是优化项。第一，单次工具返回超过 2 万 token 必须有卸载路径，落盘并在窗口内留引用，否则长任务在第一次大结果返回时就已经注定。第二，每次压缩后必须复述目标与未完成项，复述内容落盘、下一轮读回。
测试不需要复杂框架，两个用例够用。一是人为提前触发压缩：LangChain 的做法是在窗口的 10% 到 20% 处触发摘要，而默认触发点是 85%，他们还用 Claude Sonnet 4.5 在 terminal-bench-2 上试过 25% 触发点。二是一个被摘要掉的事实用例：埋一条关键约束，压缩后通过文件系统搜索把它找回来。
要盯的失败形态是目标漂移，具体有两种表现：压缩刚结束就回头追问本已确认的澄清项，或者错误地宣告任务完成。AgentCore Evaluations 提供了 goal success rate 评估器，可以对同一批 trace 打分。
要是项目还停在部署与权限阶段，先解决这些更划算：企业知识库私有化的 6 个工程决策。
我们第一次接 AgentCore Memory 时只开了事件存储，没配抽取策略。结果下一轮 recall 拿回来的是一整条原始事件流，等于把压缩前的窗口又背了一遍，成本和效果同时变差。AWS 文档里那句警告说的就是这个场景。后来我们把抽取策略收敛成三类字段——决策、未决问题、外部依赖——recall 才真的开始省 token。
不会。RAG 解决的是"取什么事实进来"，管不了"进来之后怎么排、旧观察怎么退出去"。没有预算和复述，检索再准也挡不住第 50 次调用后的漂移。检索侧本身也有不少细节，可参考RAG 落地常见的 6 个坑。
生产默认值多在窗口的 80% 到 85%（Deep Agents 是 85%）。测试环境要故意提前到 10% 到 20%，否则等不到压缩就测完了，你永远不会知道摘要 prompt 丢掉了什么。
看任务形态。长多步、模型能力偏弱、界面需要展示进度这三类场景要开；短任务和强模型上关掉更省。把它做成可配置开关，用自家任务集跑一遍再决定。
会。每次会话重新加载的记忆都在消耗注意力预算，ETH Zurich 测到的开销增幅最高约 23%。建议只存三类字段（决策、未决问题、外部依赖），并给每条记忆设过期时间。
强制触发一次压缩，然后看它接下来是否还在朝原目标走。两种失败信号最直接：压缩后立刻追问已确认过的澄清项，或者错误宣告任务完成。这两个用例跑通，才算守住了。
如果你们正在给内部知识库接 Agent，或者已经在长任务上遇到目标漂移，把上面两条验收项和两个测试用例直接搬进需求文档就能起步。想看这类工程在真实交付里长什么样，可以翻我们的项目案例。