尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

Roo Code 在大项目中如何管理上下文窗口并组织拆分任务

Roo Code 在大项目中如何管理上下文窗口并组织拆分任务 Roo Code 在大项目中如何管理上下文窗口并组织拆分任务【免费下载链接】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 里处理大型代码库时最常见的两个问题是一次请求塞进太多文件导致上下文窗口超限以及把设计、编码、文档等不同类型的活儿堆在同一个会话里越聊越乱。Roo Code 针对这两点提供了两条配套机制Intelligent Context Condensing智能上下文压缩负责在窗口接近上限时摘要压缩历史对话new_task工具Boomerang Tasks / Orchestrator 模式负责把大任务拆成各自独立上下文的子任务。本文按“控住上下文 → 拆分任务 → 验证”的顺序给出可照做的操作路径适用于已安装并配置好 API 提供商的 Roo Code 用户。先搞清楚上下文窗口里装了什么在动手之前需要知道哪些内容在消耗 token。按 大项目文档 的说明上下文窗口包括系统提示词Roo Code 的指令对话历史你用提及的文件内容Roo Code 执行的工具或命令输出。窗口装不下时模型可能无法理解请求或生成不准确的结果。文档同时说明Roo Code 默认会保留 30% 的上下文窗口20% 留给模型输出10% 作为安全缓冲只留 70% 给对话历史且可被模型特定设置覆盖见 Intelligent Context Condensing 的技术实现部分。控制上下文Intelligent Context Condensing 的配置与验证Intelligent Context Condensing 默认启用。当对话接近底层模型的上下文窗口上限时它会用 AI 模型把较早的对话压缩成摘要保留关键信息避免重要内容被直接丢弃。注意一点压缩摘要所用的 LLM 调用会产生费用费用会计入 UI 中显示的 context condensing metrics。配置入口和可调项打开 Roo Code 设置Roo Code 面板右上角齿轮图标。进入Context Management设置区以及 Context 设置可调整Automatically trigger intelligent context condensing默认开启控制是否自动压缩Threshold to trigger intelligent context condensing百分比滑杆默认 100%决定上下文窗口用到多少时触发压缩。文档举例可以把阈值设为 80%即对话达到容量的 80% 时自动尝试压缩Custom Context Condensing Prompt自定义压缩时使用的提示词。如果默认压缩丢失了你工作流中的关键信息可以在 Custom Context Condensing Prompt 编辑器里写入必须保留的内容。文档给的调试场景示例指令包括“Always preserve error messages and stack traces in full”“Maintain all variable names and their last known values”“Keep track of all attempted solutions and their outcomes”。除自动触发外任务顶部context bar 右侧有一个Condense Context按钮可以随时手动触发压缩。压缩发生后如何验证发生了、发生了什么变化聊天界面会出现可展开的压缩记录行展示压缩前后的上下文 token 数、这次压缩调用的费用以及压缩内容的摘要压缩进行中聊天界面显示 “Condensing context...” 进度指示任务头部也会显示当前压缩状态ContextWindowProgress进度条给出 token 分布的可视化当前用量、为 AI 输出预留的空间、可用空间和原始 token 数。还有一层兜底当 API 返回上下文窗口超限错误时支持 OpenAI、Anthropic 等多个提供商Roo Code 会自动把上下文缩减 25% 并重试不超过内置重试次数无需手动干预。两点边界要记住压缩始终使用当前会话的 provider/model不能换成别的模型文档解释原因是避免不同模型对工具调用等结构化内容的“翻译”错误原始消息不会丢——用 Checkpoints 回退时仍能看到原消息但后续 LLM 调用用的是摘要版本。控制上下文用 Context Mentions 只喂必要的文件压缩机制之外更根本的做法是从源头减少塞进窗口的内容。Context Mentions 文档给出的格式和限制提及类型格式说明限制文件/path/to/file.ts从工作区根目录开始把文件内容带行号注入上下文超大文件可能被截断不支持二进制目录/path/to/folder/结尾斜杠必填包含目录内所有直接文件内容不递归文档提醒提及大目录时注意上下文窗口限制Problemsproblems注入 VS Code Problems 面板的诊断按文件分组Terminalterminal最近一条命令及完整输出仅限终端缓冲区可见内容Git 提交a1b2c3d提交信息、作者、日期和完整 diff仅限 Git 仓库Git 变更git-changesgit status输出和未提交变更的 diff仅限 Git 仓库配合 大项目文档 的策略用具体文件路径和函数名代替“主文件”这类模糊指代要引用大段代码时考虑在提示词里写摘要而不是贴入整个文件。拆分任务Orchestrator 模式与new_task子任务当任务本身很大比如一个功能要经过设计、实现、文档三个阶段把每个阶段放到独立上下文里比压缩更有效。这就是 Boomerang Tasks 的机制在 Orchestrator模式下Roo 分析复杂任务并建议拆成子任务父任务Orchestrator暂停子任务在另一个专用模式如 Code、️ Architect、 Debug中开始子任务达成目标后Roo 发出完成信号父任务恢复且只拿到子任务的摘要而不是子任务的完整执行过程代码 diff、文件分析结果等不会污染父上下文。Orchestrator 模式内置无需再自建 Boomerang 自定义模式。它在默认配置下没有直接读写文件、跑命令的工具权限——这是有意设计防止文件读取内容占满编排上下文导致 context poisoning。如果你确实需要给它读取能力可以走 Custom Modes 的 Edit Global Modes 流程添加read组但文档明确提醒要谨慎因为默认的能力限制正是为了保持编排焦点。new_task工具的参数见 new_task 文档mode必填子任务启动的模式 slug如code、ask、architectmessage必填子任务的初始指令。子任务不自动继承父任务上下文向下传递的信息只能通过这里todos可选markdown checklist 格式的初始 todo 列表用于把结构化计划传给子任务。调用示例文档原文new_task modearchitect/mode messageDesign the database schema and system architecture for our new e-commerce platform./message /new_task带初始 todo 列表的示例文档原文new_task modecode/mode messageBuild a REST API for user management/message todos [ ] Set up Express server [ ] Create user model [ ] Implement CRUD endpoints [ ] Add authentication middleware [ ] Write API tests /todos /new_task两个必须知道的行为约束审批默认每个子任务的创建和完成都需要你批准可通过 Auto-Approving Actions 设置自动化信息只靠摘要回传子任务结束时只有它通过attempt_completion提交的 summary 回到父任务。所以下发指令时要把子任务完成工作所需的全部上下文写进message并明确要求子任务在 summary 中给出关键结论。拆分任务的配套设置在 VS Codesettings.jsonCtrl/Cmd Shift P→ Preferences: Open User Settings (JSON)中Task Todo List 提供两个与子任务拆分直接相关的开关{ roo-cline.newTaskRequireTodos: true }newTaskRequireTodos布尔默认false开启后通过 boomerang/子任务委派创建的新任务必须携带 todo 列表强制结构化规划。{ roo-cline.preventCompletionWithOpenTodos: true }preventCompletionWithOpenTodos布尔默认false开启后todo 列表还有未完成项时不允许把任务标记为完成。此外new_task文档提到 VS Code 设置里还有 New Task Require Todos 开关可选地强制所有新子任务必须带 todo 列表不带配置时该功能开箱即用。端到端走一遍在大文件重构中组合使用把前面的机制组合成一条可验证的操作路径以 大项目文档 的重构大 TypeScript 文件为例示例中的路径来自文档先概览不直接动手。在聊天框输入文档原文示例/src/components/MyComponent.tsx List the functions and classes in this file.只提及目标文件本身让 Roo 列出函数和类避免一次性把整个目录进来。按函数逐个下指令。例如/src/components/MyComponent.tsx Refactor the processData function to use async/await instead of Promises.小步增量修改每步审阅批准。验证方式每一步 Roo 的编辑请求都会经过你的审批界面且每次交互的输入/输出 token 数和估算费用显示在聊天历史中见 Rate Limits and Costs。多阶段工作才动用 Orchestrator。切到 Orchestrator 模式下拉菜单、/orchestrator斜杠命令或快捷键Ctrl/⌘ .循环切换见 Using Modes让 Roo 拆解任务。父任务暂停、子任务在️ Architect或 Code模式运行的过程在 UI 中有明确的任务层级展示可以在活跃与暂停任务间导航子任务完成后父任务带着摘要恢复。验证方式检查父任务恢复后拿到的是 summary 而非完整执行细节且各子任务在任务层级树中各自拥有独立的对话历史。长对话监控窗口占用。盯着任务头部的ContextWindowProgress条接近阈值时看是否出现 “Condensing context...” 指示和压缩记录行。如果压缩频率过高优先回头收紧提及范围或把下一阶段工作拆成新任务而不是继续拉长当前会话。限制与边界子任务深度嵌套时任务界面会变复杂在深层嵌套任务间切换可能需要重建上下文new_task文档列出的限制Orchestrator 默认不能直接读写文件和执行命令要修改需按 Custom Modes 的配置优先级显式添加read等工具组压缩触发阈值默认 100%即窗口用满才自动压缩想要更早压缩需在 Context 设置里调低百分比滑杆上下文超限的自动恢复会一次性缩减 25% 的上下文再重试缩减部分的信息不会找回所以依赖早期细节时应先用 Checkpoints 保存或提前压缩成本提示token 优化文档Rate Limits and Costs建议只提及直接相关的文件、按任务拆分、按需选择更小的模型并且不用 MCP 时在 MCP 设置中禁用它以缩小系统提示词——这些与本文的拆分策略是同一方向可作为可选的进一步降开销手段。【免费下载链接】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),仅供参考
返回列表