Orkas 如何管理百万级上下文窗口？context budget 算法与分层压缩策略全解析

Orkas 如何管理百万级上下文窗口context budget 算法与分层压缩策略全解析【免费下载链接】OrkasOrkas is an open-source, local-first AI desktop app: a commander LLM directs specialist sub-agents, and runs your installed coding CLIs — Claude Code, Codex, OpenCode, OpenClaw, Hermes — as local sessions. Agents self-evolve via reflection and skill crystallization. BYO keys. macOS / Windows / Linux.项目地址: https://gitcode.com/gh_mirrors/or/OrkasOrkas 是一款开源、本地优先的 AI 桌面应用它通过 context budget上下文预算算法和三层压缩策略把长会话中的对话与工具执行结果持续压缩、折叠、归档让智能体在百万级上下文窗口的模型上也能稳定工作而不是把窗口塞爆后失忆。本文用最直白的方式拆解这套机制。先看一下 Orkas 的整体能力版图理解上下文管理在其中的位置为什么长对话会失忆LLM 的上下文窗口就像一块固定大小的白板窗口有 20 万 token你的 100 万 token 窗口同理——再大也有边界。一个编码智能体跑几个小时会产生海量的工具调用、命令输出和文件读取结果白板很快写满。写满之后粗暴的做法只有两种截断旧消息早期关键结论直接丢失一次性全部总结细节糊成一团模型反复重新读文件。Orkas 的答案是不要等白板写满才收拾而是按还能写多少动态分配预算分层、增量地压缩。这套逻辑集中在一个纯算术模块里不依赖任何 I/Ocontext-budget.ts。context budget预算是怎么算出来的先看 Orkas 的新任务界面所有长任务都从这里开始Orkas 每次调用模型前都会先做一次预算核算核心公式很简单可用空间 room 请求上限 − 固定开销系统提示词、工具定义− 常驻状态当前消息、已有摘要其中请求上限取可用输入的约 82% 作为估算余量见 context-budget.test.ts。算出的room再被切分成几块各块的比例是这套算法的灵魂预算项比例 / 数值作用工具结果规划预留1/6 的 room下限 16,000 token给两次检查之间新产生的结果留生长空间活跃任务层触发线剩余空间的 60%当前正在执行的工具步骤何时压缩历史层剩余空间的 40%已完成对话何时归档保留尾部触发线的 45%压缩时逐字保留的最近结果摘要目标触发线的 2%最低 1,200、最高 6,000 token一次滚动摘要该写多长这些常量的定义都在 context-budget.ts 第 18-67 行。两个设计亮点值得注意预算随窗口缩放而不是写死。64K 窗口 大系统提示词的模型会被收紧到比旧版 18K 常量更小200K 甚至 1M、2M 窗口的模型则自动获得更大的压缩触发线——窗口越大能忍的原始细节越多。按需借用。如果历史层还没怎么用它的闲置空间会自动借给活跃任务层做触发线activeBorrowedTokens空间永远物尽其用。小窗口保护。当可用空间小到连一次有意义的摘要都放不下时windowTooSmallOrkas 不再折腾分层压缩只保留应急层避免越压缩越费 token的抖动。这套按窗口动态推导、且默认值就是公式在锚点处的取值的策略被 contextBudget() 函数 实现。分层压缩三层防线各司其职第一层活跃任务检查点正在干的活智能体每执行一轮工具调用一轮并行调用算一个步骤组这些步骤都会累积在当前轮次里。当未折叠的活跃过程 token 数超过活跃触发线时Orkas 会发起一次检查点把步骤组交给模型写成一份滚动摘要目标长度就是预算里的summaryTargetTokens最近 45% 的尾部结果逐字保留——模型刚看过的新鲜信息不糊新摘要替换旧摘要的正文但其中的精确事实keyvalue形式的账本会被保留合并防止事实丢失。摘要生成后模型看到的是一条[Current turn checkpoint]消息加保留的尾部原始过程被折叠掉。选择在 session.ts 的 selectPendingActiveCheckpoint() 中完成检查点输入总量被 MAX_ACTIVE_CHECKPOINT_INPUT_TOKENS 150,000 兜底限制——装不下的完整组留给下一批绝不硬塞半截。第二层历史归档已经干完的活已完成的对话历史独立于活跃任务计算预算只保留最近 5 轮对话且总量不超过 min(30,000 token, 轮次开始时空闲空间的 20%)。上限常量见 session.ts 第 62 行。超出部分被归档为占位说明已折叠进当前轮检查点摘要需要精确字节时再重读源文件而不是整段删除——模型知道信息去哪找。第三层应急折叠窗口真的爆了的最后防线前两层靠模型调用压缩慢且花钱。当估算器预测本次请求会超限或模型提供商直接拒绝上下文超长报错时应急层立即触发把当前轮所有可折叠的步骤组确定性折叠不调模型纯机械操作把可归档的历史轮次归档插入一条缺口通知如实告诉模型有 N 组早期工具结果已被折叠而不是假装什么都没发生。这段逻辑在 runner.ts 的 applyDeterministicEmergencyFold()。关键设计是缺口是显式声明的模型若需要精确内容会主动重读而不是默默失忆。这套算法是怎么被验证的百万级窗口的压缩策略最怕看起来合理、实际漂移。Orkas 的做法是把预算算法当纯函数做穷举测试context-budget.test.ts 把从 8K 到 2M 的窗口 × 0 到 200K 的固定开销全部组合跑一遍验证一组不变量压缩后保留量必然低于触发线否则会立刻再次触发无限抖动两层预算全满 规划预留 固定开销总和仍不超过请求上限未知窗口、NaN、负数等异常输入一律回退到锚点默认预算绝不产生退化配置。此外每次模型调用都会附带contextBudgetDiagnostics压缩前后 token 数、尝试次数、失败次数、windowTooSmall告警等从 runner.ts 第 1878 行附近 可以看到诊断如何挂到请求元数据上——出了问题能精确复盘是哪一层失守。总结Orkas 的上下文窗口管理可以浓缩成三句话预算先行每次调用前按模型窗口动态核算还能写多少按比例切分活跃层、历史层与规划预留并支持跨层借用闲置空间分层压缩活跃任务用滚动检查点摘要 逐字尾部保留历史对话按5 轮 / 30K / 20%独立归档应急层用确定性折叠兜底诚实的缺口所有被折叠的内容都以显式通知告知模型需要时可精确重读从机制上避免静默失忆。这套机制让 Orkas 的指挥官和子智能体、以及接入的 Claude Code / Codex 等本地 CLI 会话能在超长任务里始终保持清晰的工作记忆——这正是百万级上下文从营销词变成可用能力的关键。如果你想亲手验证核心源码都摆在明处预算算法src/core-agent/src/agent/context-budget.ts会话折叠与检查点src/core-agent/src/agent/session.ts压缩触发与应急层src/core-agent/src/agent/runner.ts穷举测试src/core-agent/test/context-budget.test.ts【免费下载链接】OrkasOrkas is an open-source, local-first AI desktop app: a commander LLM directs specialist sub-agents, and runs your installed coding CLIs — Claude Code, Codex, OpenCode, OpenClaw, Hermes — as local sessions. Agents self-evolve via reflection and skill crystallization. BYO keys. macOS / Windows / Linux.项目地址: https://gitcode.com/gh_mirrors/or/Orkas创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考