2026/9/16 19:16:22
FEATURED · 精选文章 
OpenSRE 上下文预算机制解析AI SRE 对话中低价值证据的驱逐与截断全指南【免费下载链接】opensreBuild your own AI SRE agents. The open source toolkit for the AI era.项目地址: https://gitcode.com/GitHub_Trending/op/opensreOpenSREAI SRE 开源智能体工具包的上下文预算Context Budget机制会自动检测对话上下文是否超出模型窗口上限并按驱逐低价值工具证据 → 截断超大消息两级策略把 prompt 压回安全线内让 AI SRE 排查会话永不因上下文溢出而失败。核心逻辑位于 core/context_budget.py由 ReAct 主循环 core/agent/react_loop.py 在每次调用 LLM 前强制执行。本文带你用零代码基础读懂它的设计思路。一、为什么 AI SRE 排查会话会撑爆上下文AI SRE 智能体排查问题时会一轮接一轮地调用工具拉日志、查指标、看流水线状态……每一次工具返回的结果都会进入对话上下文transcript。OpenSRE 内置了 100 工具注册表系统提示词加全部工具 Schema 本身就要占用数万 token。再加上多轮排查堆积的大块工具输出JSON、日志上下文很快逼近模型窗口上限。OpenSRE 的解法很直接预算不够时先扔掉价值最低的证据再压缩体积最大的证据而不是简单丢弃最老的消息。这正是上下文预算机制的设计哲学。二、Token 预算如何估算每轮请求前的体检1. 保守的字符换 token 估算OpenSRE 不做昂贵的精确分词而是用一个保守估算系数1 字符 ≈ 0.5 token_TOKENS_PER_CHAR见 core/context_budget.py#L36。工具返回多为 JSON 等结构化文本该估算会略高估但宁早剪、不溢出更安全。2. 每个模型都有自己的预算上限预算上限ceiling模型上下文窗口 − 响应预留模型族上下文窗口Claude 系列200kGemini 系列1MGPT-4o / GPT-4.1 / GPT-5.4 / 5.6128k ~ 1M未知模型兜底128k保守默认值其中响应预留固定为16,000 token_RESPONSE_HEADROOM_TOKENS留给模型回答本身。模型匹配采用小写子串匹配带日期快照、带 provider 前缀的模型 ID 也能正确归类查不到的模型一律按 128k 兜底——最多只是剪早一点绝不会溢出core/context_budget.py#L14-L33、#L172-L186。3. 系统提示词与工具 Schema 计入固定开销一个容易踩的坑Anthropic 对 200k 限制是messages system tools 全算。早期版本只统计 messages结果系统提示词和工具 Schema 悄悄把总量推过线。现在 estimate_message_tokens() 会一并计入固定开销热路径上还会把system_and_tools_overhead()的计算结果缓存复用避免每次迭代都重新序列化上百个工具 Schema。三、驱逐低价值证据三级驱逐优先级预算超标时OpenSRE 先做整段驱逐——把一对工具调用 工具结果完整移除而不是拆散消息破坏对话结构。移除谁按以下优先级元组排序越小越先被驱逐_eviction_prioritycore/context_budget.py#L166-L169重复结果优先牺牲 —— 被标记_opensre_duplicate_result的纯重复工具交换比如同一查询跑了两遍第二次返回的内容与第一次相同排在最前体积越大越先走 —— 非重复的交换里token 估算最大的先被移除省的空间最多位置越靠前越先走⏪ —— 体积相同时更早发生的交换先牺牲。同时有两类保护规则固定消息Pinned带_opensre_seed标记的种子消息所在交换永不参与整段驱逐保证会话初始状态不丢失标记不出门这些_opensre_*内部标记只留在内存 transcript 里供剪枝使用发往 provider 前由 strip_internal_message_markers() 统一剥离——因为 Anthropic 等严格的消息 Schema 会拒绝未知字段。四、截断超大消息驱逐用尽后的二级防线当没有可整段移除的交换或移除后仍超标时进入**截断Truncation**阶段core/context_budget.py#L358-L391从最大消息开刀按 token 估算降序遍历先动体积最大的、可压缩的消息避免被不可截断的tool_calls消息堵住后面的目标按比例压缩文本槽位对列表型 content不是把第一个文本块直接清零而是让所有content/text字段等比例缩水整条消息落在预算附近安全护栏截断预留 2,000 token 安全垫单消息至少保留 1,000 token被压缩的文本末尾会追加…[truncated to fit context budget]标记让模型知道内容不完整死循环兜底️每次成功的截断都严格减少总量保证循环必然终止若所有消息都压不动了就打警告日志、放行请求把问题交给 API 层而不是原地空转。五、ReAct 循环中的执行时机每次请求前强制过秤整套机制的触发点非常干脆在 ReAct 循环的_think()阶段每一次向 LLM 发请求之前都会对转换后的消息列表调用 enforce_context_budget()实现在 core/context_budget.py#L394-L439估算总量 → 超过 ceiling ├─ 是 → 驱逐最低价值工具交换 → 仍超→ 截断最大消息 → 仍超→ 警告放行 └─ 否 → 直接发送此外还有一层消息数维度的兄弟机制transcript_window.py 的窗口压缩会把溢出的最老消息合并进一条Session summary:摘要消息让会话早期的事实不彻底消失。二者一个管token 体积一个管消息条数共同构成 OpenSRE 的上下文卫生体系。六、关键设计小结设计点策略收益估算方式字符 × 0.5 保守上界快且宁早不溢驱逐单位整对调用结果不破坏消息结构驱逐顺序重复 大体积 更早省得最多、损失最小截断方式按比例压缩文本槽位保留消息骨架兜底行为全部压不动则警告放行永不死循环对新手来说理解这套机制的意义在于当你的 OpenSRE 排查会话出现[agent] trimmed low-value tool pair或truncated oversized message日志时不必担心出错——这是系统在替你精打细算把最不值得记住的证据先请出对话把最关键的事实留在模型的工作记忆里。 延伸阅读状态包边界说明见 core/state/README.md主循环实现见 core/agent/react_loop.py行为测试见 tests/core/test_context_budget.py。【免费下载链接】opensreBuild your own AI SRE agents. The open source toolkit for the AI era.项目地址: https://gitcode.com/GitHub_Trending/op/opensre创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
OpenSRE 上下文预算机制解析：AI SRE 对话中低价值证据的驱逐与截断全指南
OpenSRE 上下文预算机制解析AI SRE 对话中低价值证据的驱逐与截断全指南【免费下载链接】opensreBuild your own AI SRE agents. The open source toolkit for the AI era.项目地址: https://gitcode.com/GitHub_Trending/op/opensreOpenSREAI SRE 开源智能体工具包的上下文预算Context Budget机制会自动检测对话上下文是否超出模型窗口上限并按驱逐低价值工具证据 → 截断超大消息两级策略把 prompt 压回安全线内让 AI SRE 排查会话永不因上下文溢出而失败。核心逻辑位于 core/context_budget.py由 ReAct 主循环 core/agent/react_loop.py 在每次调用 LLM 前强制执行。本文带你用零代码基础读懂它的设计思路。一、为什么 AI SRE 排查会话会撑爆上下文AI SRE 智能体排查问题时会一轮接一轮地调用工具拉日志、查指标、看流水线状态……每一次工具返回的结果都会进入对话上下文transcript。OpenSRE 内置了 100 工具注册表系统提示词加全部工具 Schema 本身就要占用数万 token。再加上多轮排查堆积的大块工具输出JSON、日志上下文很快逼近模型窗口上限。OpenSRE 的解法很直接预算不够时先扔掉价值最低的证据再压缩体积最大的证据而不是简单丢弃最老的消息。这正是上下文预算机制的设计哲学。二、Token 预算如何估算每轮请求前的体检1. 保守的字符换 token 估算OpenSRE 不做昂贵的精确分词而是用一个保守估算系数1 字符 ≈ 0.5 token_TOKENS_PER_CHAR见 core/context_budget.py#L36。工具返回多为 JSON 等结构化文本该估算会略高估但宁早剪、不溢出更安全。2. 每个模型都有自己的预算上限预算上限ceiling模型上下文窗口 − 响应预留模型族上下文窗口Claude 系列200kGemini 系列1MGPT-4o / GPT-4.1 / GPT-5.4 / 5.6128k ~ 1M未知模型兜底128k保守默认值其中响应预留固定为16,000 token_RESPONSE_HEADROOM_TOKENS留给模型回答本身。模型匹配采用小写子串匹配带日期快照、带 provider 前缀的模型 ID 也能正确归类查不到的模型一律按 128k 兜底——最多只是剪早一点绝不会溢出core/context_budget.py#L14-L33、#L172-L186。3. 系统提示词与工具 Schema 计入固定开销一个容易踩的坑Anthropic 对 200k 限制是messages system tools 全算。早期版本只统计 messages结果系统提示词和工具 Schema 悄悄把总量推过线。现在 estimate_message_tokens() 会一并计入固定开销热路径上还会把system_and_tools_overhead()的计算结果缓存复用避免每次迭代都重新序列化上百个工具 Schema。三、驱逐低价值证据三级驱逐优先级预算超标时OpenSRE 先做整段驱逐——把一对工具调用 工具结果完整移除而不是拆散消息破坏对话结构。移除谁按以下优先级元组排序越小越先被驱逐_eviction_prioritycore/context_budget.py#L166-L169重复结果优先牺牲 —— 被标记_opensre_duplicate_result的纯重复工具交换比如同一查询跑了两遍第二次返回的内容与第一次相同排在最前体积越大越先走 —— 非重复的交换里token 估算最大的先被移除省的空间最多位置越靠前越先走⏪ —— 体积相同时更早发生的交换先牺牲。同时有两类保护规则固定消息Pinned带_opensre_seed标记的种子消息所在交换永不参与整段驱逐保证会话初始状态不丢失标记不出门这些_opensre_*内部标记只留在内存 transcript 里供剪枝使用发往 provider 前由 strip_internal_message_markers() 统一剥离——因为 Anthropic 等严格的消息 Schema 会拒绝未知字段。四、截断超大消息驱逐用尽后的二级防线当没有可整段移除的交换或移除后仍超标时进入**截断Truncation**阶段core/context_budget.py#L358-L391从最大消息开刀按 token 估算降序遍历先动体积最大的、可压缩的消息避免被不可截断的tool_calls消息堵住后面的目标按比例压缩文本槽位对列表型 content不是把第一个文本块直接清零而是让所有content/text字段等比例缩水整条消息落在预算附近安全护栏截断预留 2,000 token 安全垫单消息至少保留 1,000 token被压缩的文本末尾会追加…[truncated to fit context budget]标记让模型知道内容不完整死循环兜底️每次成功的截断都严格减少总量保证循环必然终止若所有消息都压不动了就打警告日志、放行请求把问题交给 API 层而不是原地空转。五、ReAct 循环中的执行时机每次请求前强制过秤整套机制的触发点非常干脆在 ReAct 循环的_think()阶段每一次向 LLM 发请求之前都会对转换后的消息列表调用 enforce_context_budget()实现在 core/context_budget.py#L394-L439估算总量 → 超过 ceiling ├─ 是 → 驱逐最低价值工具交换 → 仍超→ 截断最大消息 → 仍超→ 警告放行 └─ 否 → 直接发送此外还有一层消息数维度的兄弟机制transcript_window.py 的窗口压缩会把溢出的最老消息合并进一条Session summary:摘要消息让会话早期的事实不彻底消失。二者一个管token 体积一个管消息条数共同构成 OpenSRE 的上下文卫生体系。六、关键设计小结设计点策略收益估算方式字符 × 0.5 保守上界快且宁早不溢驱逐单位整对调用结果不破坏消息结构驱逐顺序重复 大体积 更早省得最多、损失最小截断方式按比例压缩文本槽位保留消息骨架兜底行为全部压不动则警告放行永不死循环对新手来说理解这套机制的意义在于当你的 OpenSRE 排查会话出现[agent] trimmed low-value tool pair或truncated oversized message日志时不必担心出错——这是系统在替你精打细算把最不值得记住的证据先请出对话把最关键的事实留在模型的工作记忆里。 延伸阅读状态包边界说明见 core/state/README.md主循环实现见 core/agent/react_loop.py行为测试见 tests/core/test_context_budget.py。【免费下载链接】opensreBuild your own AI SRE agents. The open source toolkit for the AI era.项目地址: https://gitcode.com/GitHub_Trending/op/opensre创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
