长上下文的真正问题
上下文越长，模型并不会线性获得更多能力。无关信息会稀释注意力，重复规则可能互相冲突，旧状态会和新状态竞争。更长的输入还会增加推理成本，使每一次工具循环都变慢。
所以“上下文工程”不是把所有资料都塞进去，而是管理进入模型工作记忆的信息预算。
一个 Coding Agent 的五类上下文
第一类是系统与开发者规则，定义身份、权限和工作方式。第二类是工具 schema，告诉模型可以怎样行动。第三类是仓库规则与项目文件，提供局部事实。第四类是对话和工具结果，记录任务推进。第五类是记忆或摘要，用较短文本保存长任务状态。
这五类信息的生命周期不同。安全规则应持续存在，大型日志只需保留结论，源代码应按需要读取，用户最新要求必须覆盖已经失效的旧计划。
压缩为什么会丢任务
上下文压缩通常把许多历史消息重写成摘要。摘要如果只记录“讨论了什么”，却没记录“哪些文件已改、哪些验证已通过、用户最后要求是什么”，Agent 就会重复劳动或把旧目标当成当前目标。
好的任务摘要至少保留：当前目标、已完成项、未完成项、关键文件、重要决定、验证结果和禁止事项。
从 Prompt 里怎么看上下文策略
阅读 Claude Code、Codex、Kimi Code 和 OpenClaw 的最新版本，搜索 memory、context、environment、session 和 project。比较这些章节在哪一层、何时读取、谁负责更新，就能看出各自的上下文模型。
可直接采用的设计原则
把稳定规则和任务数据分开；让工具只返回下一步需要的信息；长日志先结构化再摘要；压缩前写清完成状态；出现冲突时优先保留用户最新指令。上下文工程的目标不是“信息最多”，而是“下一步决策所需信号最清楚”。