AI 每一步究竟看见了什么
每次判断都只看到系统当下递交的一份有限材料；理解这张“工作台”，才能解释遗忘、成本和信息遗漏。
- 能拆解一次模型调用中的上下文构成
- 能做 Token 预算与压缩取舍
- 能区分 Context Window、KV Cache 与长期 Memory
它明明刚刚读过，为什么下一步仍可能忘记？
模型不会持续看见整个项目。每次调用都像召开一次有座位上限的会议：系统规则、用户任务、历史决策、工具说明、文档片段、工具结果和待生成输出都要占位置。Harness 决定哪些内容进入这次会议。
Token 是模型处理文本的基本片段，不等同于汉字或单词。上下文窗口限制一次调用可以容纳的输入与输出总量。任务越长，历史和工具结果越多，系统越需要选择、压缩和外置状态。
KV Cache 复用模型已经计算过的序列状态，主要影响速度和成本；Memory 是产品主动保存、未来再检索的信息。二者都可能让用户感觉“记得”，但责任、生命周期和风险完全不同。
先记住这句话把上下文想成一张本次会议桌：系统指令、用户目标、历史消息、工具定义、文件片段和工具结果都在争夺有限座位。Harness 决定谁上桌、谁摘要、谁离场。
一次模型调用可以被产品经理读懂
可以把调用简化为三部分：instructions 告诉模型角色与硬规则；tools 描述可调用能力及参数；input 包含用户任务、必要历史、文件片段和先前工具结果。模型返回文字或工具调用候选。
模型只根据当前快照判断下一步。它昨天读过一份文档并不意味着今天自动可见；同一 Turn 中早期内容也可能在压缩后只剩摘要。所谓“忘记”首先是上下文与状态问题，之后才是模型能力问题。
预算不是平均分配，而是按决策价值分配
假设可用输入预算为 12k Token：硬规则和任务目标占 2k，工具说明占 2k，当前决策与未决项占 1k，候选材料还有 20k。系统不能把所有材料平均截断，而应先用目录和检索缩小范围，再把最高权威证据送入模型。
输出也需要预留。如果输入占满窗口，模型可能没有空间生成工具参数或完整交付。产品预算因此同时影响准确性、延迟和成本。
压缩要保留可恢复任务所需的骨架
好的压缩不是写一段漂亮摘要，而是保留目标、硬约束、已做决定、关键证据指针、失败尝试和未决问题。原始材料留在窗口外，需要时可以回源。
一旦摘要去掉了来源、否定条件或版本，后续模型可能沿着错误前提稳定执行。压缩策略必须进入测试，而不能被当成无害的后台优化。
Context Window、Cache 和 Memory 的边界
Context Window 是本次调用能看到的工作台；KV Cache 是推理计算的复用；Memory 是跨步骤或跨任务持久化的信息资产。工作台有限，缓存不负责真实性，Memory 需要来源、作用域、更新和删除治理。
产品界面应该解释 Agent 当前使用了哪些关键资料、哪些内容被压缩、哪些规则来自长期记忆。用户不需要看到 Token 的每个细节，但需要知道决策依据是否完整。
每次推理看到的不是整个世界，而是 Harness 临时组装的一次输入。规则、工具定义、历史、文件、Observation 和输出预留共同争夺有限窗口。
组合 instructions、tools 与 input items
生成工具调用，Harness 追加工具结果
检索、裁剪或压缩旧历史
利用缓存减少重复计算
有术语没听懂？在这里用人话再看一遍7 个词＋
- LLM API
- 应用向大语言模型提交指令、工具说明和输入，并接收文字或结构化动作的接口。
- Token
- 模型处理文字的片段单位；字符数只能粗略估算 Token 数。
- Context Window
- 一次模型调用可处理的输入和输出总容量。
- Instructions
- 告诉模型角色、目标、规则和行为边界的高优先级输入。
- KV Cache
- 复用已计算序列状态的推理优化，减少重复计算，但不是产品层长期记忆。
- Compaction
- 在长任务中把旧上下文压缩成可继续工作的摘要、状态和回源指针。
- Memory
- 由产品选择、持久化并在未来任务中检索的信息。
32k Token 的真实预算怎么花
规则 2k、工具 Schema 3k、历史 5k、检索文件 14k、输出预留 4k，只剩 4k 给新 Observation。
- 01
先用目录与接口摘要替代 14k 全文件
- 02
按当前假设读取 3 个关键文件
- 03
旧轨迹压缩为目标、决策、证据指针和未决项
上下文从“尽量塞满”变为“支持下一步决策的最小充分集合”。
本章依据与证据边界5 条结论 · 6 份原始材料＋
正文已经把关键来源放在相关概念旁边。这里保留完整核验清单：每条材料能支持什么、不能支持什么；不要求离开本站才能继续学习。
- [1]
OpenAI 的 Codex Agent Loop 文章公开描述了 instructions、tools、input、工具结果回填与长任务压缩等 Codex 案例机制。
官方事实OPUnrolling the Codex agent loop官方工程文章 · 核验 2026-07-14 - [2]
12k Token 的分配数字和会议桌比喻是本站教学示例，不是 OpenAI 推荐的固定比例。
本站推演OPUnrolling the Codex agent loop官方工程文章 · 核验 2026-07-14 - [3]
OpenAI 对 Codex Agent Loop 的公开拆解说明了上下文窗口有限、长任务需要压缩，并强调保留继续任务所需的关键信息。
官方事实OPUnrolling the Codex agent loop官方工程文章 · 核验 2026-07-14 - [4]
Hugging Face 官方说明 KV Cache 复用注意力层已经计算过的 Key/Value 状态以减少重复计算；它是推理优化，不是产品层长期记忆。
官方事实HUCaching · Transformers官方文档 · 核验 2026-07-14 - [5]
Anthropic 文档公开说明 Claude Code 的记忆/规则管理方式；这是 Claude Code 产品案例，不代表所有 Agent 的统一 Memory 实现。
官方事实ANManage Claude's memory官方文档 · 核验 2026-07-14
查看全部一手材料与源码证据 6 条
这份文档把 Claude Code 的 Agent Loop 描述为收集上下文、采取行动、验证结果三个相互交织的阶段，并说明模型与工具如何通过结果反馈持续调整。它还解释 Claude Code 作为 Harness 所承担的上下文管理、执行环境、会话、压缩、检查点和权限职责。
官方方法 · 核验 2026-07-11Effective context engineering for AI agentsAnthropic这份材料将 Context Engineering 定义为持续选择和维护推理时最合适的信息，而不只是改写一条 Prompt。它支持最小高信号上下文、按需检索、工具结果压缩、结构化笔记、Compaction 与 Subagent 隔离等长任务策略。
官方产品实现 · 核验 2026-07-11How Claude remembers your projectAnthropic这份文档区分由人维护的 CLAUDE.md 持久指令与由 Claude 写入的 Auto Memory，并描述它们的作用域、加载顺序、存储位置和容量边界。它强调这些内容会作为上下文影响模型，而不是不可绕过的技术策略，并支持用户检查、修改和删除记忆。
官方产品实现 · 核验 2026-07-11Unrolling the Codex agent loopOpenAI这份材料逐步解释 Codex Harness 如何组装 instructions、tools 与 input，通过 Responses API 在一次 Turn 内循环完成模型推理和工具调用。它还说明对话增长、上下文窗口、Prompt Caching 与 Compaction 为什么属于 Harness 的核心工程责任。
固定提交源码 · 核验 2026-07-11Hermes Agent context compression and tool runtimeNous Research这份同提交文档解释 Hermes 如何区分稳定、上下文和易变 Prompt 层，并在压力下裁剪旧工具输出、保留边界、生成结构化摘要和修复工具调用配对。它支持课程讨论上下文压缩与缓存边界，不用来证明未在该文档中展开的工具运行时。
官方产品实现 · 核验 2026-07-14Hermes Agent Context Compression and CachingNous Research当前文档公开工具结果裁剪、头尾保护、结构化摘要、重压缩和缓存策略，并说明摘要模型窗口不足时中段上下文可能在无摘要情况下被丢弃。
证据边界：Compaction 不能保证信息无损，也不是长期 Memory。