Roo Code 3.7.2 补丁解析Claude Sonnet 3.7 集成修复、上下文窗口溢出与 Diff 编辑提示词强化【免费下载链接】Roo-CodeRoo Code gives you a whole dev team of AI agents in your code editor.项目地址: https://gitcode.com/GitHub_Trending/ro/Roo-Code本文基于 Roo Code 仓库中的 3.7.2 版本发布说明v3.7.2.md展开聚焦该补丁版本针对 Claude Sonnet 3.7 集成的三项核心修复OpenRouter 上anthropic/claude-3.7-sonnet:beta的 computer use 与 prompt caching、Sonnet 3.7 上下文窗口sliding window溢出计算以及系统提示词中对 diff 编辑方式的强化引导。读完本文你将理解这些修复背后的底层实现机制——包括 OpenRouter 模型元数据解析、Anthropic 提示词缓存协议、上下文管理中的滑动窗口截断算法以及 diff 编辑在任务流程中的落点——并知道如何升级到该版本验证修复效果。一、版本背景一次围绕 Claude Sonnet 3.7 的集中补丁Roo Code 3.7.2发布于 2025-02-24是一个 patch release发布说明将其定位为「includes fixes related to Claude Sonnet 3.7 integration and prompt adjustments」即针对 Claude Sonnet 3.7 集成与系统提示词的集中修复。当 Claude 3.7 Sonnet 发布时它带来了两个显著的新特性extended thinking扩展思考模式与computer use计算机使用能力。前者让模型在回答前进行更长的推理后者允许模型调用图形界面操作工具完成更接近真实操作的任务。这两项能力在第三方模型路由平台如 OpenRouter上的接入形态比官方 API 更复杂——模型 ID 带有:beta、:thinking等后缀变体参数支持情况也不尽相同这正是 3.7.2 需要专门打补丁的原因。二、修复一OpenRouter 上 Sonnet 3.7 Beta 的 computer use 与 prompt caching2.1 修复内容发布说明的第一条修复为Fixed computer use and prompt caching for OpenRoutersanthropic/claude-3.7-sonnet:beta.即针对 OpenRouter 平台上的anthropic/claude-3.7-sonnet:beta模型 ID修复了 computer use 与 prompt caching 两项能力不可用或异常的问题。修复来自社区贡献者 cte。2.2 底层实现OpenRouter 模型元数据解析在 Roo Code 的 API 层所有经由 OpenRouter 接入的模型都会经过parseOpenRouterModel函数统一解析为内部ModelInfo结构该函数位于 src/api/providers/fetchers/openrouter.ts。它根据 OpenRouter 返回的模型元数据context 长度、定价、支持参数等生成 Roo Code 内部使用的模型配置核心字段包括maxTokens单次请求的最大输出 token 数缺省时按context_length * 0.2估算contextWindow模型上下文窗口大小直接取自 OpenRouter 的context_lengthsupportsPromptCache是否支持提示词缓存其判定逻辑十分关键——只要模型定价中存在input_cache_read缓存读取价格字段即认为该模型支持 prompt caching见 openrouter.tsconst cacheReadsPrice model.pricing?.input_cache_read ? parseApiPrice(model.pricing?.input_cache_read) : undefined const supportsPromptCache typeof cacheReadsPrice ! undefined // some models support caching but dont charge a cacheWritesPrice, e.g. GPT-5cacheWritesPrice/cacheReadsPrice分别对应 OpenRouter 定价中的input_cache_write与input_cache_read即写入缓存与命中缓存的单价supportsReasoningBudget/supportsReasoningEffort是否支持推理预算控制与 effort 参数由 OpenRouter 的supported_parameters列表推导。上述input_cache_write/input_cache_read字段来自 OpenRouter 模型列表接口的 pricing 响应其 zod 校验 schema 同样定义在该文件顶部openrouter.ts。也就是说prompt caching 是否对某模型生效取决于 OpenRouter 是否在定价元数据中暴露缓存读写价格——3.7.2 之前对:beta变体模型的处理可能存在遗漏导致缓存支持未被正确识别该修复补齐了这一逻辑。2.3 Sonnet 3.7 的三种模型形态与参数差异从当前仓库的源码与测试可以看出Sonnet 3.7 在 OpenRouter 上存在多个模型 ID且各自配置不同。测试文件 src/api/providers/fetchers/tests/openrouter.spec.ts 中给出了清晰的对比OpenRouter 模型 IDmaxTokensanthropic/claude-3.7-sonnet8192anthropic/claude-3.7-sonnet:beta128000anthropic/claude-3.7-sonnet:thinking128000在parseOpenRouterModel中针对标准版与 thinking 版还有专门的向后兼容处理openrouter.ts// For backwards compatibility with the old model definitions we will // continue to disable extending thinking for anthropic/claude-3.7-sonnet // and force it for anthropic/claude-3.7-sonnet:thinking. if (id anthropic/claude-3.7-sonnet) { modelInfo.maxTokens anthropicModels[claude-3-7-sonnet-20250219].maxTokens modelInfo.supportsReasoningBudget false modelInfo.supportsReasoningEffort false } if (id anthropic/claude-3.7-sonnet:thinking) { modelInfo.maxTokens anthropicModels[claude-3-7-sonnet-20250219:thinking].maxTokens }即标准版claude-3.7-sonnet被显式关闭推理预算与 effort 参数避免错误地传参导致请求失败而:thinking版则使用 thinking 专用配置。maxTokens的取值以roo-code/types包中内置的anthropicModels表为准。这些细节共同说明3.7.2 针对:beta变体的修复本质上是让这一形态的模型在 Roo Code 内部获得与官方 API 一致的能力标注包括缓存支持与输出上限从而让 computer use 与 prompt caching 得以按预期工作。2.4 在 Anthropic 提供商中的缓存实现对照为了理解 prompt caching 修复的具体目标可以对照原生 Anthropic 提供商中的实现。src/api/providers/anthropic.ts 展示了官方 API 的缓存接入方式系统提示词打缓存断点system: [{ text: systemPrompt, type: text, cache_control: cacheControl }]让系统提示词成为每次请求可复用的缓存段最后两条用户消息打缓存断点倒数第二条用户消息标记为让服务端「从缓存读取」的断点最新一条用户消息标记为「写入缓存」以备下一次请求这正是缓存滑动窗口复用的标准做法附加 beta 头针对支持缓存的一系列模型含claude-3-7-sonnet-20250219请求时会附加prompt-caching-2024-07-31的anthropic-beta头。而在 OpenRouter 侧缓存能力取决于 2.2 节所述的定价元数据解析结果。3.7.2 的修复正是让 OpenRouter 路径下的 Sonnet 3.7尤其是:beta形态也能正确走通这一缓存机制。对用户而言prompt caching 直接关系到长对话场景的成本——命中的缓存段以input_cache_read单价计费远低于全价 prompt 输入。三、修复二修复 Sonnet 3.7 的滑动窗口计算导致的上下文溢出3.1 修复内容第二条修复为Fixed sliding window calculations for Sonnet 3.7 that were causing context window overflows.即修复了 Sonnet 3.7 的 sliding window滑动窗口上下文计算错误该错误曾导致请求超出模型上下文窗口而报错。同样来自贡献者 cte。3.2 为什么滑动窗口计算会溢出滑动窗口是 Roo Code 在对话接近上下文上限时采用的兜底手段当智能压缩condensation不可用或失败时通过隐藏而非删除早期消息来为后续请求腾出空间。其核心问题在于——触发截断的阈值取决于「预留 token」与上下文窗口的换算。若某个新模型如 Sonnet 3.7的上下文窗口或输出上限元数据不准确计算出的可容纳对话长度就会偏大最终请求的 token 总量超过实际窗口上限触发上下文溢出context window overflow。3.3 底层算法阈值公式与非破坏性截断上下文管理的核心实现在 src/core/context-management/index.ts。其中willManageContext用于判断是否即将触发上下文管理index.ts核心公式如下const reservedTokens maxTokens || ANTHROPIC_DEFAULT_MAX_TOKENS const prevContextTokens totalTokens lastMessageTokens const allowedTokens contextWindow * (1 - TOKEN_BUFFER_PERCENTAGE) - reservedTokensTOKEN_BUFFER_PERCENTAGE 0.1默认保留 10% 的上下文窗口作为缓冲见 index.tsreservedTokens为模型输出预留的 token 空间取该模型maxTokens缺省回退到ANTHROPIC_DEFAULT_MAX_TOKENS判定条件prevContextTokens allowedTokens即「已有 token 最后一条消息 token」超过「上下文窗口的 90% 减去输出预留」时触发上下文管理。从公式可以看出contextWindow与maxTokens两个数值任何一个不准确都会让allowedTokens虚高进而导致溢出。这正是 3.7.2 修复的切入点校正 Sonnet 3.7 在 OpenRouter 路径下的滑动窗口计算——具体到 2.3 节的元数据解析maxTokens从按context_length * 0.2的粗糙估算改为使用anthropicModels内置表中 Sonnet 3.7 的准确值如:beta形态为 128000从而让reservedTokens与实际输出上限一致。真正执行截断的是truncateConversationindex.ts它采用非破坏性滑动窗口策略计算需要隐藏的消息数量messagesToRemove floor((可见消息数 - 1) * fracToRemove)并向下取整为偶数将需要隐藏的消息标记truncationParent而不是从数组中删除在被截断消息与保留消息的交界处插入一条[Sliding window truncation: N messages hidden to reduce context]的标记消息isTruncationMarker: true记录截断位置与truncationId。之所以「非破坏性」是因为被隐藏的消息仍然保留在会话数据中——若用户将对话回退rewind到截断点之前这些消息可以被恢复。该行为有完整的测试覆盖例如 src/core/message-manager/index.spec.ts 验证了「保留截断标记」与「移除截断标记」两种场景确保 UI 上sliding_window_truncation事件与 API 消息中的截断标记保持一致。此外上下文管理还支持基于压缩阈值与模式级阈值profileThresholds范围在MIN_CONDENSE_THRESHOLD与MAX_CONDENSE_THRESHOLD之间的判定优先尝试智能压缩manageContext见 index.ts仅在压缩不可用或失败时回退到滑动窗口截断。四、修复三系统提示词中更强烈地鼓励 diff 编辑4.1 修复内容第三条修复为Encouraged diff editing more strongly in the system prompt.即增强了系统提示词中对 diff 编辑方式的引导力度。该改动来自贡献者 hannesrudolph目的是让模型在修改文件时更倾向使用基于 diff 的工具如EditTool/apply_diff而不是整文件重写或其他低效方式。4.2 diff 编辑在任务流程中的落点Roo Code 的 diff 编辑以EditTool为核心。在 src/core/tools/EditTool.ts 中一次 diff 编辑的完整流程为读取目标文件当前内容并初始化 diff 视图diffViewProvider.editType modify基于旧内容与新内容生成 unified diffformatResponse.createPrettyPatch(relPath, fileContent, newContent)对生成的 diff 做净化与统计sanitizeUnifiedDiff、computeDiffStats见 src/core/diff/stats.ts以appliedDiff工具消息的形式向模型展示 diff 内容与统计信息diffStats在用户未禁用「防止焦点干扰」的前提下打开 diff 视图让用户逐处确认改动。系统提示词的生成入口在 src/core/prompts/system.tsSYSTEM_PROMPT接受diffStrategy参数并透传给generatePrompt。提示词中的规则段落由 src/core/prompts/sections/rules.ts 提供——例如「修改代码时必须考虑代码使用上下文、遵循项目编码规范与最佳实践」等指导见 rules.ts。3.7.2 的改动正是在这类规则/目标段落中强化了对 diff 编辑的倾向性描述使模型在多种可行编辑路径中优先选择 diff 方式。当前仓库的提示词快照测试如 src/core/prompts/tests/snapshots/system-prompt/with-diff-enabled-true.snap也表明diff 是否启用会直接影响最终系统提示词的内容结构。对用户而言这条修复的意义在于diff 编辑生成的补丁更小、更精准既便于人工审阅也减少了整文件重写带来的无关改动长期来看也降低了每次编辑的 token 开销。五、升级与验证3.7.2 属于补丁版本直接更新至该版本或更新版本即可获得上述修复。升级后可按以下路径验证验证缓存生效使用 OpenRouter 的anthropic/claude-3.7-sonnet:beta发起多轮对话观察请求中是否携带缓存相关头、账单中是否出现缓存读取/写入费用对应 2.2 节的cacheReadsPrice/cacheWritesPrice验证无上下文溢出执行长对话任务逼近上下文上限观察上下文管理是否在合理阈值contextWindow * 0.9 - reservedTokens见 3.3 节公式触发压缩或滑动窗口截断而非报出超出窗口的错误观察编辑行为查看模型执行文件修改时使用的工具与生成的补丁确认其优先采用 diff 形式对应 4.2 节的appliedDiff消息。六、相关源码索引发布说明原文apps/docs/docs/update-notes/v3.7.2.mdOpenRouter 模型解析含缓存支持判定与 Sonnet 3.7 变体处理src/api/providers/fetchers/openrouter.tsOpenRouter 模型解析测试三种 Sonnet 3.7 形态的 maxTokens 断言src/api/providers/fetchers/tests/openrouter.spec.tsAnthropic 官方 API 的 prompt caching 与缓存断点实现src/api/providers/anthropic.ts上下文管理阈值公式、非破坏性滑动窗口截断src/core/context-management/index.ts截断标记行为测试src/core/message-manager/index.spec.tsdiff 编辑工具实现src/core/tools/EditTool.ts系统提示词规则段src/core/prompts/sections/rules.ts系统提示词生成入口src/core/prompts/system.ts【免费下载链接】Roo-CodeRoo Code gives you a whole dev team of AI agents in your code editor.项目地址: https://gitcode.com/GitHub_Trending/ro/Roo-Code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考