上下文也需要预算

一段对话越积越长时，最容易丢掉的未必是信息，而是信息之间的轻重关系。用户刚刚修正的约束，可能被埋在几十次工具输出后；一份已经过期的计划，可能因为写得完整而继续占据中心。

这篇笔记设计一个小练习：让资料助手连续整理一批文档，并在中途接受一次目标修正。我们观察它是否保留了真正重要的状态，而不追求把所有历史都塞进下一次请求。

先给信息安排去处

上下文工程的一手讨论关注的是推理时可用信息的组织与维护。本文进一步把一个自用助手的信息分为任务状态、证据索引和临时材料，这是为了便于实现而采用的分类。

任务状态应该短而明确：用户要什么、哪些约束刚被修改、现在停在哪里。证据索引保存可重新获取的信息地址。临时材料则包括本轮检索结果、长日志和尚未验证的推测。

{
  "goal": "整理公开的 Agent 阅读资料",
  "constraints": ["保留原始来源", "不自动发布"],
  "completed": ["去重", "主题初分"],
  "next": "检查版本与引用",
  "evidenceIds": ["source-01", "source-07"]
}

状态文件里的“完成”应当指向可检查的结果。例如，写“引用已核对”，同时保存被核对的地址与记录。只保留一句自我总结，下一轮就很难判断它是否仍然成立。

摘要也需要检查

把长历史压缩成短摘要时，可能会把试过但失败的方法写成已经完成的动作，也可能把用户最新的修正省略掉。我会给摘要设置三项检查：最新约束是否仍在、未解决问题是否仍在、证据是否能够重新定位。

这三项检查可以先人工做。等积累了几次具体错误，再考虑增加程序化规则。过早设计一个万能“记忆分数”，往往会掩盖真正需要观察的内容。

给预算留一点余量

一个可操作的实验是：固定每轮可用上下文预算，先放目标与约束，再放当前任务所需证据，最后才放辅助背景。预算不足时，优先移走可按地址重新获取的大段材料，而不是删掉关键约束。

这些选择取决于项目，并不是固定的行业比例。一个调试助手和一个阅读助手，对日志细节的需求就可能很不一样。

用一次目标修正验收

让助手先按主题整理资料，完成一半后，把要求改成“只保留有可运行示例的资料”。观察它是否重新检查已经处理的部分，还是只让后半段遵守新规则。

如果旧结果需要重新分类，应当记录这是目标变化带来的工作，而不是伪装成系统从一开始就做对了。这样的状态记录，会让一次长任务变得更诚实，也更容易继续。

可以把最终状态打印成一页短卡：目标、有效约束、已验证结果、待处理问题、证据入口。让人接得住这张卡，比让它看起来像一个无所不知的记忆系统更有价值。