1M Context 也会失忆：Coding Agent 为什么需要 Context Ledger

1M Context 也会失忆：Coding Agent 为什么需要 Context Ledger

TL;DR

• 场景：1M Context 解决容量上限，却不能自动保证 compact 后约束不丢、仓库不漂移、prompt cache 仍然可用。
• 结论：Coding Agent 应建立 Context Ledger，把 Context Window、Cache、History、Memory、Repository Snapshot、Tool Registry 分开记账，区分 provider_surface + model_id + reasoning_effort + policy_hash + repo_snapshot + tool_schema_hash + summary_hash。
• 产出：六类状态分离 + Context Ledger 四层字段 + 稳定前缀/半稳定工作状态/易变后缀三段组织 + Cache Hit ≠ Context Correct 的五类风险 + 24 任务 × 3 策略 × 5 重复的对照实验设计。

版本矩阵

维度	状态	说明
Kimi K3 发布日期	✅ 已验证	2026-07-16 / 2026-07-17（官方与第三方报道时间点略有差异）
总参数	✅ 已验证	2.8T（896 专家 / 激活 16）
上下文窗口	✅ 已验证	1,048,576 token，全窗口统一定价
默认 reasoning_effort	✅ 已验证	Open Platform kimi-k3 默认 max；Kimi Code k3 与 k3-256k 默认 high
API 模型 ID	✅ 已验证	Open Platform：kimi-k3；Kimi Code：k3、k3-256k；Claude Code 兼容：kimi-k3[1m]
输入价格（缓存命中）	✅ 已验证	$0.30 / 百万 token（发布前需重新核价）
输入价格（缓存未命中）	✅ 已验证	$3.00 / 百万 token
输出价格	✅ 已验证	$15.00 / 百万 token
cached_tokens 暴露	✅ 已验证	API 响应中可直接读取，用于账本计算
Prompt Cache 自动启用	✅ 已验证	不需要 cache ID，无 TTL 管理；>256 token 才进入前缀缓存
Kimi Code compact	✅ 已验证	支持自动压缩与手动 /compact [instruction]；新版本会把 todo 列表附加到摘要
完整权重开源	✅ 已验证	官方承诺最迟 2026-07-27 发布完整权重
1M 上下文与"窗口越大越聪明"	❌ 不成立	容量扩展不解决约束丢失、仓库漂移、缓存失效问题
cache hit 证明上下文正确	❌ 不成立	仅证明前缀计算复用，不证明摘要完整、仓库未漂移或授权有效
Kimi Code 额度与 Open Platform 美元成本直接互换	❌ 不成立	计费单位不同

发布边界：价格、会员层级、模型 ID、默认 effort、缓存与 compact 行为需在发布前复核；本文不声称已完成本地吞吐或成本实测。

摘要

1M Context 解决容量上限，却不能自动保证约束没有在 compact 中丢失、仓库没有漂移、缓存仍然有效。本文把 Context Window、Cache、History、Memory、Repository Snapshot 与 Tool Registry 分开，并提出一份可回放、可归因的 Context Ledger。

关键词

Kimi K3、Context Ledger、Context Cache、Compaction、Agent Harness

目录

• 一、先停止把六种东西都叫"记忆"
• [二、K3 的 1M、自动缓存和产品入口必须分开解释](#二、K3 的 1M、自动缓存和产品入口必须分开解释 "#%E4%BA%8Ck3-%E7%9A%84-1m%E8%87%AA%E5%8A%A8%E7%BC%93%E5%AD%98%E5%92%8C%E4%BA%A7%E5%93%81%E5%85%A5%E5%8F%A3%E5%BF%85%E9%A1%BB%E5%88%86%E5%BC%80%E8%A7%A3%E9%87%8A")
• [三、Context Ledger 应记录什么](#三、Context Ledger 应记录什么 "#%E4%B8%89context-ledger-%E5%BA%94%E8%AE%B0%E5%BD%95%E4%BB%80%E4%B9%88")
• 四、把请求组织成稳定前缀、半稳定工作状态和易变后缀
• [五、为什么 cache hit 不能证明上下文正确](#五、为什么 cache hit 不能证明上下文正确 "#%E4%BA%94%E4%B8%BA%E4%BB%80%E4%B9%88-cache-hit-%E4%B8%8D%E8%83%BD%E8%AF%81%E6%98%8E%E4%B8%8A%E4%B8%8B%E6%96%87%E6%AD%A3%E7%A1%AE")
• 六、怎样做一组不虚构结果的对照实验
• 七、最后把选择写成工程规则

先看一种由多个官方机制组合而成的合成故障链。它用于说明风险，不代表已经发生的客户事故或本文完成了本地实测。

一个 Agent 已经在同一仓库里工作了几十轮。它读过架构说明、测试约束、禁止修改的目录，也完成了第一批代码改动。当前会话接近 256K，操作者为了节省 Kimi Code 额度，把模型从 k3 切到 k3-256k。由于上下文已经超过 256K，客户端先做 compact，把此前消息压成一段摘要。摘要保留了"继续完成支付模块重构"，却漏掉了"不得修改数据库迁移文件"和"必须复用已有幂等键"的约束。与此同时，模型切换使原有 prompt cache 失效，长前缀需要重新 prefill。新模型拿到的是一份更短、但不完整的历史；它发现缺少局部代码证据，于是再次读取仓库，随后生成了一个能通过部分测试、却违反原始约束的补丁。账单或额度曲线在这一轮突然抬升，端到端延迟也变长。

这不是"1M 上下文不够长"，而是系统没有回答四个更基本的问题：这一轮上下文到底由什么组成？哪些内容是原文，哪些是摘要？当前仓库还是不是模型曾经读过的那个版本？一次 cache hit 或 cache miss 应该归因于什么变化？

Kimi 官方文档说明，Open Platform 的 kimi-k3 支持最多 1M token，上下文缓存会自动尝试复用重复的初始前缀；Kimi Code 则提供 k3 和 k3-256k 两个不同模型 ID，并明确提示模型或 reasoning effort 的切换可能使缓存失效，1M 降到 256K 时还可能由工具侧触发 compact。（S1、S3、S5、S8、S9）这些能力解决的是容量、推理计算复用和客户端会话管理，不等于生产状态已经被正确管理。

真正需要建立的是一份 Context Ledger：上下文账本。它不是再造一套聊天记录，而是把每次请求所依赖的状态、状态版本、压缩边界、缓存结果和任务结果放进同一条可追溯链路。上下文窗口只是容量上限；账本才负责说明这个容量里装了什么、为什么可信、何时失效，以及失效造成了多少成本。

一、先停止把六种东西都叫"记忆"

生产系统最常见的概念错误，是把 Context Window、Context Cache、Agent Memory、Conversation History、Repository Snapshot 和 Tool Registry 全部归入"模型记忆"。它们实际上回答六个不同问题。

Context Window 是一次推理允许容纳的最大 token 总量。Kimi Open Platform 文档把 kimi-k3 的窗口写为 1M token，模型参数表给出的精确上限是 1,048,576；输入与输出共同占用这个预算。（S1、S6）它回答"最多能放多少"，不回答"应该放什么"，也不保证长上下文中的约束一定被正确使用。

Context Cache 是对重复初始前缀的计算复用。Kimi API 自动启用缓存，不要求调用方创建 cache ID，也不提供需要自行管理的 TTL；当系统识别到重复的 system prompt、文档或工具定义时，可能复用已计算的前缀。官方还说明，前一请求的 prompt 超过 256 token 才可能进入前缀缓存，并通过响应中的 cached_tokens 暴露命中量。（S5、S7）它回答"哪些输入 token 不必重新 prefill"，不是长期业务记忆，更不是事实新鲜度证明。

Agent Memory 应由 Harness 管理，是跨轮次乃至跨 Session 保存的结构化状态，例如用户确认过的决策、任务约束、失败经验、实体关系或可检索笔记。它需要来源、更新时间、作用域和撤销机制。API 是否命中缓存，与这类记忆是否存在没有必然关系。

Conversation History 是本轮请求重放给模型的消息序列。Kimi API 本身是无状态的，不保存多轮历史；调用方必须把此前 assistant 消息和工具结果重新加入 messages。Kimi Code CLI 则会把 Session 的事件流持久化到本地，用于恢复和回放。（S7、S10）历史是事件记录，不等于已经提炼好的工作状态。

Repository Snapshot 是 Agent 所依据的代码世界版本。至少要能定位 commit 或 tree hash、branch、dirty diff、submodule、依赖锁文件和生成物状态。模型读过 payment/service.go，只说明它见过某一时刻的文件内容；如果人类、另一个 Agent 或格式化工具随后改了文件，旧阅读结果就已经过期。

Tool Registry 是当前可调用工具的契约集合，包括工具名、JSON Schema、版本、权限、端点、超时和副作用级别。只有工具名相同，不代表工具语义相同。参数从 path 改成 paths、默认分支从只读改成写入、MCP Server 升级或权限策略变化，都会让旧上下文中的调用计划失效。

把六者分开后，故障定位才有可能成立：约束丢失是 compaction 问题，重复读仓库可能是 Repository Snapshot 未复用，成本突增可能是缓存失效，错误工具调用可能是 Tool Registry 漂移。它们不能再被笼统归因成"模型忘了"。

二、K3 的 1M、自动缓存和产品入口必须分开解释

Kimi 的官方页面存在三个容易被混写的产品入口：Open Platform API、Kimi Code，以及包含 Kimi Code 权益的会员产品。三者的 Key、余额或权益和计费方式并不通用。（S1、S3）因此，Context Ledger 首先要记录 provider_surface，再记录 model_id，不能只写一个"K3"。

在 Open Platform API 中，直接调用使用 kimi-k3。该模型最多支持 1M token，reasoning_effort 可取 low、high、max，默认是 max。API 按 token 计费；截至本次访问，K3 每 100 万 token 的缓存命中输入、缓存未命中输入和输出价格分别为 0.30、3.00 和 15.00 美元，未含适用税费。（S4、S6）响应提供 prompt_tokens、completion_tokens、cached_tokens，因此账本可以计算：

cache_hit_tokens = cached_tokens

cache_miss_tokens = prompt_tokens - cached_tokens

request_cost = hit_tokens × 0.30 / 1,000,000 + miss_tokens × 3.00 / 1,000,000 + output_tokens × 15.00 / 1,000,000

这只是当前官方价格下的计算式，发布前必须重新核价，并单独计入 Web Search 等附加能力的费用。

在 Kimi Code 中，模型 ID 是 k3 与 k3-256k。文档写明两者默认 reasoning effort 都是 high；k3-256k 固定为 256K，k3 的最高 1M 能力取决于会员等级。Kimi Code 采用会员额度语境，官方称 1M 的 k3 大约消耗 k3-256k 两倍额度，这不能直接换算成 Open Platform 的美元价格。（S8）

模型 ID 的差异也不只是命名问题。Kimi 的故障排查页面指出，Open Platform 直接 API 与 Codex 集成使用 kimi-k3，Claude Code 的兼容路径可能使用 kimi-k3[1m]；Kimi Code 自己的兼容端点又使用 k3 或 k3-256k。（S3、S8）如果 Harness 在不同适配器之间只保存"K3"，就无法知道一次恢复究竟回到了哪个产品、哪个上下文上限和哪个默认 effort。

官方文档还给出一个值得保留原貌的版本化差异：Kimi Code 的通用说明和发布日志都说，切换模型 ID 或 effort 会使已有 prompt cache 失效，建议新建 Session；但同一模型配置页又对"当前版本从 k3-256k 升到 k3"给出限定说明，称该方向目前不影响缓存。（S8、S9）这不是应该由文章替官方消除的矛盾，而是账本必须记录 client_version、切换方向和实际 cached_tokens 的理由。生产规则应以观测结果为准，不能把某一版客户端的例外写成永久协议。

三、Context Ledger 应记录什么

一份可用的账本至少分成任务、上下文、请求和结果四层。下面是一条最小记录的示意，字段名可以落入数据库、Trace Span 或 JSONL：

{
  "task_id": "TASK-8421",
  "session_id": "sess-17",
  "attempt_id": "a3",
  "provider_surface": "kimi_open_platform",
  "model_id": "kimi-k3",
  "model_version": "unknown_alias_resolution",
  "reasoning_effort": "high",
  "policy_hash": "sha256:...",
  "repo_snapshot": "git:4f8c...+dirty:9a1b...",
  "tool_schema_hash": "sha256:...",
  "history_range": "event:120-188",
  "summary_hash": "sha256:...",
  "cache_hit_tokens": 184320,
  "cache_miss_tokens": 17342,
  "compaction_event": {
    "occurred": true,
    "reason": "model_window_downshift",
    "source_range": "event:1-119",
    "preserve_manifest_hash": "sha256:...",
    "validator": "constraint-check-v2"
  }
}

任务层必须有 task_id，并区分 Session 与 Attempt。一次任务失败后新建 Session 重试，仍应归到同一任务，否则"每 Session 成本下降"可能只是把失败成本藏到了别处。

模型层至少记录 model_id、model_version、reasoning_effort 和客户端或适配器版本。若供应商只暴露滚动别名，model_version 应明确写成未知或别名解析时间，而不是伪造一个精确版本。Kimi API 的响应 model 字段、Kimi Code 的运行状态和客户端版本都应原样保存。

上下文层记录 policy_hash、repo_snapshot、tool_schema_hash、history_range 与 summary_hash。哈希之前必须先做确定性序列化：统一字段顺序、换行、编码和路径规范，否则只是无意义地制造 miss。除总哈希外，还应保存可解释的 manifest，例如策略文件列表、工具版本表、仓库 commit 与 dirty 文件清单。

压缩层不能只有 compacted=true。compaction_event 还要记录触发者、触发原因、压缩前 token、源历史范围、摘要生成模型、保留指令、摘要哈希、被删除的原文位置，以及压缩后的约束校验结果。Kimi Code 支持自动压缩和手动 /compact [instruction]；发布日志还提到新版会把 todo 列表附加到摘要中。（S9、S10、S11）这说明 compact 本身就是一次有损状态迁移，应像数据库迁移一样审计，而不是当作普通聊天清理。

请求层记录 prompt_tokens、cache_hit_tokens、cache_miss_tokens、输出 token、TTFT、端到端耗时、工具调用次数、重复读取字节数和请求 ID。结果层记录功能测试、约束测试、人工验收、错误类型和是否回滚。只有把成本与成功结果连接起来，才有"每个成功任务成本"，而不只是便宜但失败的请求均价。

账本还应生成一个可比较的 context_identity，例如由 provider_surface + model_id + reasoning_effort + policy_hash + repo_snapshot + tool_schema_hash + summary_hash 组合后再做哈希。它不是供应商缓存键，而是 Harness 自己的上下文身份。两个请求即使都显示 80% cache hit，只要 context_identity 不同，就不能被当作同一实验条件；反过来，如果身份相同却出现命中率骤降，就可以进一步检查消息排序、客户端升级、隐式工具注入或供应商侧缓存波动。对每次 compact，还应保存压缩前后的身份映射，使团队能够从一个错误补丁反查到它究竟继承了哪份摘要。

四、把请求组织成稳定前缀、半稳定工作状态和易变后缀

自动前缀缓存要求重复的初始上下文尽量稳定。一个适合 Coding Agent 的组织方法，是把每次请求拆成三层，但每层都必须版本化。

第一层是 稳定前缀 ：组织策略、权限边界、输出协议、长期不变的项目约束，以及本轮确实启用的工具 Schema。它应采用固定排序和固定序列化，末尾附上 policy_hash 与 tool_schema_hash。失效条件包括策略变更、工具参数或权限变化、模型 ID 变化、reasoning effort 变化，以及适配器改变消息排列。Kimi 官方明确把 system prompt、知识文档和工具定义列为适合稳定前缀的内容，并提醒修改前缀会降低命中率。（S3、S5）

第二层是 半稳定工作状态 ：当前目标、已确认决策、执行计划、仓库快照、相关文件摘要、测试基线、尚未解决的阻塞项。它不应随着每条工具输出都整体重写，而应按 epoch 更新。例如完成一次提交、切换 branch、依赖锁文件变化或用户改变验收标准时，生成新的 work_state_version。其失效条件是 repo_snapshot 改变、摘要被重算、计划被批准或撤销、检索索引落后于仓库。

第三层是 易变后缀：当前用户指令、最近几轮对话、刚返回的工具结果、当前 diff 和错误日志。它天然每轮变化，不应为了追求 cache hit 被强行塞入稳定区。后缀的目标是小、近、可丢弃；真正需要跨轮保存的结论，应先通过验证，再晋升到半稳定工作状态。

这种分层的价值不只在缓存。当 Agent 重复读取仓库时，Harness 可以检查：相同 repo_snapshot 下，这个文件是否已经有内容哈希和可信摘要；当工具升级时，可以只使 Tool Registry 相关前缀失效；当用户修改策略时，可以强制重建第一层，而不是继续复用一个高命中但过期的前缀。

五、为什么 cache hit 不能证明上下文正确

缓存命中只说明请求前缀与某个可复用计算相匹配。它不证明前缀中的内容仍然适用于当前任务，也不证明上下文完整。

第一种风险是 过期策略 。旧 policy_hash 对应的前缀可以获得很高命中率，但如果安全团队已经禁止网络访问，继续复用旧规则反而稳定地产生错误行为。

第二种风险是 工具版本漂移。工具名和大部分 Schema 未变，缓存仍可能命中，但后端语义、权限或副作用已经变化。账本必须把工具版本、端点和权限纳入 manifest，而不能只哈希展示给模型的名称。

第三种风险是 错误摘要 。一次 compact 把"不允许修改 migrations"漏掉后，这份摘要可以在后续多轮被稳定复用。缓存越好，错误传播得越便宜、越快。summary_hash 只能证明摘要没变，不能证明摘要正确；还需要约束清单校验、来源回链和必要时的原文抽查。

第四种风险是 仓库已变化 。模型对旧文件内容的前缀命中，不代表当前 working tree 仍相同。只有 repo_snapshot 一致，历史阅读结果才有资格复用。

第五种风险是 跨模型状态不兼容。不同模型或 effort 可能要求不同的 reasoning 字段、工具消息结构和压缩策略。Kimi 官方明确要求多轮 K3 请求回传完整 assistant message，并记录模型或 effort 切换的缓存失效风险。（S6、S8、S9）因此，恢复 Session 前必须执行兼容性检查，而不是把上一模型的历史盲目塞给下一模型。

生产看板至少要同时展示两组指标：计算复用指标与语义正确指标。前者包括 hit tokens、miss tokens、hit ratio、TTFT 和输入成本；后者包括策略版本一致率、仓库快照一致率、摘要约束召回率、工具 Schema 一致率和任务成功率。只有两组都通过，缓存才是优化，而不是把错误加速。

六、怎样做一组不虚构结果的对照实验

可以用同一批冻结仓库与验收测试，对比三种上下文策略：A 组"全历史"，每轮携带完整消息；B 组"稳定前缀加增量"，组合稳定前缀、版本化工作状态和增量后缀；C 组"检索加短历史"，只保留稳定策略与短历史，其余代码证据通过检索按需注入。

任务集建议包含 24 个任务：8 个单文件或小功能任务、8 个跨模块修改、8 个长链路任务。每组都要包含显式约束陷阱，例如禁止改某目录、必须复用既有接口、只能调用只读工具。每个任务固定 commit、依赖、测试命令和验收脚本；每种策略独立运行 5 次，共 360 条任务轨迹。由于 K3 的采样参数并非都可自由设为零，应通过重复、随机化运行顺序和相同时间窗降低偶然性，而不是拿一次结果下结论。（S6）

一次成功必须同时满足：目标测试通过；无禁止文件改动；工具权限与副作用合规；补丁能够从干净快照复现；任务没有依赖人工补写被遗漏的原始约束。错误分类至少包括约束丢失、仓库状态过期、摘要遗漏、工具契约不匹配、上下文溢出或 compact 失败、重复读取或循环、功能失败。

每条轨迹记录端到端耗时和 TTFT 的 P50/P95、输入与输出 token、cached_tokens、计算得到的 miss tokens、缓存命中率、总成本、每成功任务成本、重复文件读取字节数、工具调用次数、compact 次数和失败恢复次数。A/B/C 三组必须使用同一 Open Platform 模型 ID 与 effort，不能把 kimi-k3 的美元成本和 Kimi Code 会员额度混在一张表里。

另做一组 Kimi Code 故障注入：在固定 Session 中分别执行 effort 切换、k3→k3-256k、k3-256k→k3、自动 compact 和手动 compact。记录客户端版本、切换方向、压缩前后约束召回和实际额度变化，用来验证当前文档中的通用规则与限定例外。这里同样只报告实测，不预填"B 组一定最好"之类结论。

七、最后把选择写成工程规则

优先使用 256K ：当经过检索后的有效工作集、短历史和预留输出空间稳定落在 256K 内，任务是日常问答、补全、常规功能开发或少量文件修改时，256K 应是默认档。Kimi Code 官方也把 k3-256k 定位在这些场景，并提醒其不支持视频输入。（S8）

升级到 1M ：当跨模块迁移、长测试证据、大量相互依赖文件或无法安全压缩的决策链确实超过 256K 时，再升级到 1M。升级依据应是账本里的 working-set 估算和历史失败证据，而不是"窗口越大越聪明"。接近 256K 且压缩可能丢失关键证据时，Kimi Code 文档允许直接从 k3-256k 升到 k3；但仍要记录客户端版本并验证实际缓存结果。（S8）

新建 Session ：模型 ID 或 effort 要改变、任务目标已经切换、策略版本改变、仓库基线大幅变化，或者现有摘要无法通过约束校验时，应新建 Session。Kimi Code 对模型与 effort 切换也明确建议 /new，以避免旧缓存失效后的额外消耗。（S8、S9）

执行 compact：同一任务、同一模型下，早期历史大多已收敛且可被结构化状态替代时可以 compact；从 1M 降到 256K 前，若会话超限，也应先显式 compact。压缩前必须生成保留清单，压缩后运行约束、计划、未完成 todo 和关键证据的自动校验。没有校验的摘要不能成为新的事实源。

重新构建上下文 ：只要 policy_hash、repo_snapshot、tool_schema_hash 或 summary_hash 与预期不符；检索索引落后；工具语义升级；跨模型历史结构不兼容；或者 cache hit 很高但正确性 canary 失败，就应放弃复用，按权威来源重新构建三层上下文。

最终，Context Ledger 的目标不是追求最高缓存命中率，也不是让每个 Session 尽可能长。它要让团队能回答：一次任务为什么成功或失败，哪段状态被压缩或过期，哪次切换导致 re-prefill，重复读取浪费了多少，扩大窗口是否真正改善了每成功任务成本。

1M Context 给了 Agent 更大的工作台，但不会替你整理工作台。只有把模型、策略、仓库、工具、历史、摘要、缓存与结果统一记账，长上下文才从一个容量卖点，变成可以复现、比较和治理的生产能力。

FAQ

Context Ledger 是另一份聊天记录吗？

不是。它记录请求依赖的状态版本、哈希、压缩边界、缓存与结果，用于重放和归因。

Cache Hit 为什么不能证明上下文正确？

它只证明前缀计算被复用，无法证明摘要完整、仓库未漂移或任务授权仍有效。

先上 1M 还是先做账本？

二者解决不同问题；即使使用 1M，也应先有最小账本，否则错误与成本都难以解释。

---

错误速查卡

症状	根因	定位	修复
cache hit 80% 但答案明显违反原始约束	摘要遗漏了不可违反的约束，缓存越高效传播越快	检查 summary_hash 对应摘要的约束清单是否完整，定位 compact 前的源历史	摘要生成后跑约束/计划/todo 校验；未通过则不作为新的事实源；账本记录 validator 失败原因
切换 k3 → k3-256k 后长前缀被重新 prefill，账单突增	客户端升级、模型 ID 或 effort 改变使 prompt cache 失效	查账本 model_id / reasoning_effort / client_version 与 cached_tokens 跳变点	跨档切换按官方建议先 /new；记录切换方向；把 hit 骤降归因为"代际切换"而不是"缓存策略错"
同一仓库不同 Session 下行为不一致	repo_snapshot 没绑定历史阅读结果，模型读到的是过期文件	账本 repo_snapshot 字段是否记录 commit + dirty diff + 依赖锁文件	Harness 在 commit 变化或 dirty 文件变化时强制重建上下文；不允许裸 path 引用
调用工具时收到"参数不匹配"或"权限拒绝"	Tool Schema 漂移，旧上下文还在用旧参数 / 旧权限	比对账本 tool_schema_hash 与 Tool Registry 当前 manifest	工具版本/端点/权限变化时只重建第一层稳定前缀；并把变化记入 manifest
1M 上下文里模型显得"很聪明"但仍违反本地约束	容量扩展 ≠ 状态管理；约束在 compact 中被丢弃	查账本 compact_event 链：哪一次压缩、什么触发、保留清单、校验结果	压缩前生成 preserve_manifest；压缩后跑约束校验；校验失败强制从原文重建
每 Session 成本下降，但每个成功任务成本没变	失败成本被新 Session 隐藏，没有以 task_id 归并	账本是否在 task 层把同一 task 的多次 attempt 关联	任务层强制 task_id + attempt_id；按 task 归并而非按 Session 归并
团队复盘时无法回答"哪次切换导致 re-prefill"	账本只记 hit/miss，没记代际 / 客户端 / 切换方向	查账本是否记录 client_version、model_id 切换、effort 切换与方向	增加 context_identity = hash(provider_surface + model_id + effort + policy + repo + tool + summary)；identity 改变即重建账本
摘要说"已完成支付模块重构"，模型以为当前任务就是这个	compact 时把"当前目标"误晋升为"已完成事实"	查 history_range 与 summary_hash，定位摘要生成时刻的状态	摘要里区分"目标"与"完成事实"；前者必须经约束/测试/人工确认才晋升为"完成事实"
检索到的代码片段命中但引用了已删除文件	Repository Snapshot 落后于仓库，repo_snapshot 与 working tree 不一致	检索前强制 rebase 到当前 repo_snapshot；检索索引落后时拒绝检索	每次 commit、dirty 文件变化或依赖锁文件变化都刷新 snapshot；旧摘要标注 stale，禁止直接喂给模型
Kimi Code 会员额度与 Open Platform 美元成本混算	两个产品入口的 Key/余额/计费方式不通用	查账本 provider_surface 是否正确区分	Context Ledger 强制先记 provider_surface 再记 model_id；成本按 surface 分表计算
8 个跨模块任务中频繁超时、TTFT 抖动大	1M 上下文做 prefill 拖慢首 token；任务实际不需要 1M	查账本 working-set 估算：有效工作集是否真的超过 256K	优先用 256K + 检索注入；只有账本显示 working-set 超过 256K 才升 1M
同一约束在 5 轮 compact 后被悄悄抹掉	compact 是有损状态迁移，但日志只记 compacted=true	查 compaction_event 是否记录触发者 / 原因 / 源历史 / 保留清单 / 校验结果	compact 必须像数据库迁移一样审计；保留清单 + 校验 + 摘要哈希全部进账本
Harness 在不同适配器之间把 K3 都记成同一个	模型 ID 在不同产品入口命名不同（kimi-k3 / k3 / k3-256k / kimi-k3[1m]）	查账本 provider_surface 与 model_id 是否成对保存	账本字段必须成对；恢复 Session 前做兼容性检查，不盲塞上一模型历史
一次任务失败后新建 Session 重试，审计上看不到关联	Session 与 Attempt 都被当成独立事件	查账本是否以 task_id 归并 attempt	任务层强制 task_id + attempt_id；同一 task 的所有 attempt 共享 task 级成本与结果指标

---

作者：武子康的个人博客