长会话不是只能靠“压缩提示词”：用 Burnless 把 Agent 上下文、原始日志和成本审计拆开
AI 编码 Agent 做到第十几轮以后，问题往往不是模型突然变笨，而是会话状态开始失控：为了保留此前的决策、命令输出和失败线索，客户端反复携带越来越长的历史；为了压低输入量，又有人在 system prompt 里要求模型“简短一点”。前者会放大输入成本，后者则可能把真正需要的约束和排障细节一并丢掉。
Burnless 选择了第三条路：不把“给模型看的状态”和“留给人回查的完整记录”当成同一份数据。它是一个 MIT 许可、要求 Python 3.10+ 的 Python 工具；参考实现提供 burnless 命令，并可在 Claude Code、Codex、Gemini、Ollama 等 CLI 的外侧组织多层任务执行。它并不承诺替代这些 Agent，也不把摘要说成万能记忆；重点是把长会话的携带状态做成可追溯的磁盘对象。
先区分三种数据，而不是只谈“上下文”
Burnless 的核心结构由三类记录组成：
- Capsule（胶囊）：每一轮的紧凑语义状态，追加写入项目的
.burnless/maestro_session.jsonl。协调者后续主要读取它，而不是把整段原始对话再次发送出去。 - Worker 日志：执行子任务的 Worker 可把完整输出写入
.burnless/logs/，终端只报告简短结果。遇到异常时仍可按日志或 capsule ID 回读，不必用“摘要覆盖原始证据”。 - 执行证据：Worker 声称创建文件、运行检查或修改项目时，工具会将声明的路径、命令或日志线索与文件系统进行核对。这是它文档中称为 QTP-A 的审计环节。
这种拆分的实用之处在于：模型只需要获得下一步推理所需的决策、约束、引用和待办；开发者则保留能复盘的完整输出。它不是无损压缩。若 capsule 缺了关键细节，正确的补救是回到磁盘上的原始记录，而不是继续要求模型凭空补全。
从最小安装开始，先验证而不是直接接管项目
官方 Quickstart 给出的初始化命令很短：
pip install burnless cd your-project burnless setup burnless doctor
setup 用于检测本机 CLI 和密钥，并写入 .burnless/config.yaml；doctor 是上线前的健康检查。只有检查结果正常后，再把一个低风险任务交给指定层级：
burnless do --tier silver "梳理当前测试失败的最小复现，并把证据写入日志"
这里的 silver 不是固定模型名，而是一层命令配置。项目文档描述的默认层级为 gold、silver、bronze，可通过 burnless models set 修改全局映射，也可在单次调用覆盖。因此，层级更适合表达任务风险与成本预算：例如让较高层保留计划和最终判断，让较低层执行可验证的搜索、测试或格式化工作；不要把“便宜模型”误当成一切子任务都适用的默认答案。
若需要 MCP 支持，安装时应显式选择 extra：
pip install 'burnless[mcp]' burnless doctor
没有安装该 extra 时，文档说明 doctor 会把 MCP 项报告为警告而非其他核心流程的失败。这个边界很重要：先让基本的本地日志与 Worker 执行稳定，再把 MCP 接入加入故障面，排查会容易得多。
为什么前缀稳定性比“让模型少说话”更可控
许多提供商会对可复用的输入前缀提供缓存。Burnless 的设计是让系统前缀保持字节级稳定，把轮次变化写到追加式 capsule 中，从而避免每轮都重构一大段历史。它还将任务路由与状态管理分开：一个协调者保留计划，Worker 以子进程执行单个任务、给出结构化结果后退出。
这不等于任何工作流都会节省同样比例。项目 README 展示了作者在特定 API 运行和模拟中的测量，并明确注明基线、模型、轮数和假设；这些数据只能作为设计是否值得试验的线索，不能外推成你的成本承诺。短会话、一次性脚本，或已有成熟缓存与状态层的框架，可能几乎得不到收益，反而多了一层配置与恢复路径。
更可靠的验证方式是在自己的仓库做对照：固定一个真实但不含敏感数据的任务，记录轮次、输入 token、成功率、人工回查日志的耗时，以及 capsule 需要回读原文的次数。只有在“输入变少”没有以“定位问题更慢”作为代价时，才值得扩大使用范围。
把文件系统审计用在最容易出现假完成的地方
Agent 的常见失败不是生成不了解释，而是报告与真实工作区脱节：它说测试跑过了，但没有日志；它说文件已写入，但路径不对；它说改动完成了，实际只在计划里描述。Burnless 的 Worker 结果区分执行型与思考型：前者应携带可检查的证据，后者不应被强行当作“写文件任务”核验。
在团队实践中，可以把这一点变成简单约定：执行型任务必须返回测试命令、变更文件和日志位置；设计型任务只输出方案、风险和下一步。这样不会把架构讨论误判为失败，也能减少“Agent 说 done”被当成事实的情况。涉及部署、删除、迁移等不可逆动作时，文件存在性检查仍然不够，仍应保留 CI、代码审查和人工审批。
一次排障任务怎样落到这套结构中
假设某个编码任务在第八轮后出现测试失败。不要让协调者把八轮终端输出重新塞回提示词，也不要只留下“已尝试修复”的一句摘要。可以把当前失败的测试名、已确认的约束、下一步假设和关联日志 ID 写进 capsule；再由 Worker 只读取相关文件、运行最小测试，并把完整输出写入日志。若 Worker 返回“已修复”，审计层至少应能看到改动文件和测试证据；如果测试仍失败，协调者应携带的是失败类别与日志指针，而非重复的原始堆栈。
这种流程让状态有不同保留期限：用于下一轮推理的结论应短而明确；用于事故复盘的原始输出则应完整保留。两者不要混在一个不断增长的对话缓冲里。特别是在多个 CLI 轮流参与时，日志指针还能减少“另一个 Agent 看到过什么”的口头转述误差。
但 capsule 也需要治理。把无验证的推断写成确定结论，会让错误被高效地传播到后续轮次。建议在 capsule 中明确区分“已验证事实”“待验证假设”“阻塞项”和“回读位置”；一旦源代码、依赖版本或需求发生变化，就让旧结论失效或重新检查。压缩的是传递成本，不该压缩证据标准。
用自己的指标决定是否保留这层工具
是否采用不应只看 token 数。至少观察四项：同一类任务的成功率、每次失败恢复需要的人工时间、日志中是否能定位到证据、以及本地状态目录造成的存储与敏感数据负担。若团队已经有完善的任务队列、可观测性和会话记忆层，Burnless 可能只是重复建设；反之，若 Agent 的原始输出散落在终端历史、不同 CLI 的临时目录与聊天窗口中，这种“状态—日志—审计”分层就更有价值。
先用一个小型基线试验比较，而不是把所有仓库一夜迁移：连续选择数个相似任务，记录在启用前后的输入量、失败重试次数和回放证据耗时。只有当长期会话的成本和可复盘性同时改善，才值得把初始化与目录管理写进团队模板。
适合谁，以及先避开哪些坑
Burnless 更适合跨多轮、需要多 CLI 协作、又必须留下本地审计轨迹的工作：长时间排障、分批重构、重复的仓库调查，或需要在不同成本层级之间路由的编码任务。它的价值不在于用摘要取代事实，而在于把事实留在可查询的日志里，同时让后续模型调用只带必要状态。
开始时建议只选择一个非生产仓库、一个可回滚任务和一个明确的成功标准。不要把 .burnless/ 目录直接加入会被上传的公开构建产物，也要检查日志是否包含密钥、客户数据或命令输出中的敏感内容。会话状态落盘提高了可审计性，但也意味着本地数据治理要跟上。
相关链接