Roo Code 2.2.28 更新解读基于 createFileSystemWatcher 的 提及文件建议可靠性增强【免费下载链接】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 2.2.28更新说明原文是一次以提升 -mention 文件建议可靠性为核心的 QOLQuality of Life体验优化版本。本篇文章将围绕这一改动展开先说明 -mention 在 Roo Code 中的定位与完整工作链路再深入讲解createFileSystemWatcher在仓库各模块中的底层实现形态分析旧方案为何不可靠、新方案如何修复最后补充同版本其他值得关注的体验改动与验证方式。读完你既能理解该版本改了什么也能掌握为什么这样改、底层如何实现。版本概览2.2.28 改了什么该版本的全部改动聚焦于一行要点来源 apps/docs/docs/update-notes/v2.2.28.md使用createFileSystemWatcher更可靠地更新可供 -mention 建议使用的文件列表。General and QOL Improvements通用与体验优化UsedcreateFileSystemWatcherfor more reliable updates to the list of files available for -mention suggestions.这一改动也记录在主仓库的 CHANGELOG.md 中原文为 Use createFileSystemWatcher to more reliably update list of files to -mention与文档描述完全一致。同时apps/docs/docs/update-notes/v2.2.md 的 2.2 系列汇总中也将其列为该系列的重要能力之一File Watcher for -Mentions (v2.2.28)可见这是一个值得单独展开的底层基础设施优化。什么是 -mentionRoo Code 的上下文挂载机制在深入 2.2.28 的改动之前需要先理解 -mention 在 Roo Code 中的角色。它并不是一个孤立的 UI 补全功能而是用户向 Agent 注入上下文的核心入口。支持被 的实体类型用户在聊天输入框中输入后会弹出上下文菜单context menu可选择的实体类型包括对应前端实现 webview-ui/src/components/chat/ChatTextArea.tsx 中的ContextMenuOptionType文件File把文件完整内容读入上下文目录以/结尾会生成目录列表Git 提交Git输入 7~40 位十六进制哈希可引用提交信息Git 变更git-changes引用工作区未提交变更Problemsproblems引用编辑器诊断面板中的问题列表终端terminal引用终端会话输出URLhttp/https引用网络资源斜杠命令/command引用内置或自定义命令Agent / 模式mode切换或委派给其他 Agent 模式。后端解析与内容注入链路前端输入框只是入口真正的解析与内容注入发生在后端 src/core/mentions/processUserContentMentions.ts解析通过mentionRegexGlobal正则定义于 src/shared/context-mentions.ts匹配文本中的xxx模式替换parsedText parsedText.replace(mentionRegexGlobal, ...)将file替换为file这样的干净引用同时把符号消解避免模型混淆取内容对每个提及实体如file/folder/git-commit/terminal等生成独立的内容块mention content block插入到消息上下文中特殊处理图片类提及交给 src/core/mentions/resolveImageMentions.ts 转为 data URL 附加到消息URL 提及则直接以带引号引用替换见 src/core/mentions/index.ts 中的openMention与mentionRegexGlobal解析逻辑。其中文件/目录类提及还有一个重要副作用在 src/core/mentions/index.ts 的路径解析分支中被提及的文件会被调用fileContextTracker.trackFileContext(mentionPath, file_mentioned)即每一次 文件都会登记到任务的文件上下文跟踪器中供后续折叠上下文folded context、陈旧上下文检测stale context等功能使用。这也解释了为何可被 的文件列表是否可靠直接影响到上下文管理的质量——列表一旦滞后用户就无法 到刚创建的文件上下文注入链路的第一个环节就失效了。createFileSystemWatcherVS Code 的文件系统监听 APIvscode.workspace.createFileSystemWatcher是 VS Code 扩展 API 中用于监听文件系统事件的入口其签名大致为createFileSystemWatcher( globPattern: GlobPattern | RelativePattern, ignoreCreateEvents?: boolean, ignoreChangeEvents?: boolean, ignoreDeleteEvents?: boolean, ): FileSystemWatcherglobPattern可以是绝对/相对 glob也可以是RelativePattern基目录 相对模式更适合监听工作区子目录三个布尔参数分别控制是否忽略 create / change / delete 事件返回的FileSystemWatcher暴露onDidCreate、onDidChange、onDidDelete三个事件以及用于资源释放的dispose()。在测试与无 VS Code 环境下仓库通过 shim 提供了等价实现packages/vscode-shim/src/api/WorkspaceAPI.ts 中的createFileSystemWatcher基于EventEmitter模拟三个事件并返回dispose()同时 src/mocks/vscode.js 也提供了用于单元测试的 mock。这说明createFileSystemWatcher是仓库各模块共享的标准文件监听原语。2.2.28 改动剖析为什么需要更可靠的文件列表旧方案的问题静态扫描导致建议列表滞后在 2.2.28 之前-mention 文件建议所依赖的文件列表主要基于静态/按需扫描即在用户打开上下文菜单时扫描一次目录或在消息到达时才刷新。这种方式存在两个典型的不可靠场景文件创建/删除后列表不刷新用户在编辑器里新建、重命名或删除文件若下次打开 菜单时未触发重新扫描列表中就会出现幽灵文件已删除仍被建议或缺失文件新文件不可建议扫描结果与服务端缓存不一致前端ChatTextArea通过fileSearchResults消息维护本地文件搜索结果见 webview-ui/src/components/chat/ChatTextArea.tsx如果后端数据源没有及时更新前端拿到的建议列表就是陈旧的。新方案事件驱动的实时刷新2.2.28 的核心思路是把按需扫描升级为事件驱动的推送刷新用createFileSystemWatcher在工作区挂上文件监听一旦目录中发生 create / change / delete 事件就主动更新可供 -mention 的文件列表用户在任何时刻打开 菜单看到的都是与磁盘实际状态一致的最新列表。从源码结构看仓库中有多条基于createFileSystemWatcher的成熟实践可以印证这一模式的可靠性设计这些虽然并非全部由 2.2.28 引入但正是 2.2.28 所采用的同一原语与模式src/core/context-tracking/FileContextTracker.ts为任务上下文中登记的每个文件创建独立的文件监听器通过new vscode.RelativePattern(path.dirname(fileUri.fsPath), path.basename(fileUri.fsPath))精确监听单个文件在onDidChange回调中区分Roo 自身写入recentlyEditedByRoo与用户外部修改recentlyModifiedFiles并调用trackFileContext(filePath, user_edited)登记为陈旧上下文——这正是文件被修改后 Roo 需要重新读取这一告警机制的实现基础src/core/config/CustomModesManager.ts用createFileSystemWatcher(settingsPath)监听自定义模式配置文件配置变更时热重载src/services/mcp/McpHub.ts监听项目级 MCP 配置文件实现 MCP 服务器的自动接入与移除src/services/skills/SkillsManager.ts监听 skills 目录技能文件变化后自动刷新可用技能列表src/core/ignore/RooIgnoreController.ts监听.rooignore文件变化src/integrations/workspace/WorkspaceTracker.ts以**全量模式监听整个工作区。可以看到createFileSystemWatcher是 Roo Code 内部处理外部文件状态变化的统一基础设施监听 → 事件回调 → 增量更新内存状态。2.2.28 把这一成熟模式应用到 -mention 文件建议列表上本质上是一次补课式的可靠性收口——让建议列表从静态快照变成实时镜像。事件类型覆盖建议参考 src/extension.ts 中开发模式自动重载的实现一个可靠的文件监听器应当同时挂载三类事件const relPattern new vscode.RelativePattern(vscode.Uri.file(watchPath), pattern) const watcher vscode.workspace.createFileSystemWatcher(relPattern, false, false, false) watcher.onDidChange(debouncedReload) // 内容修改 watcher.onDidCreate(debouncedReload) // 新建文件 watcher.onDidDelete(debouncedReload) // 删除文件 context.subscriptions.push(watcher) // 随扩展生命周期释放对 -mention 文件列表而言新建onDidCreate与删除onDidDelete是列表增删的关键信号修改onDidChange则可触发轻量刷新同时需要把 watcher 注册进context.subscriptions避免监听器泄漏。如何验证与体验 2.2.28 的改进手动验证路径安装/更新到 Roo Code 2.2.28打开任意工作区在聊天输入框输入新建一个文件、重命名一个文件、删除一个文件再次输入打开上下文菜单2.2.28 之前新建的文件可能需要手动触发刷新例如重新打开面板才会出现2.2.28 之后文件系统事件会驱动列表实时更新新建文件立即可 已删除文件不再出现在建议中。单元测试验证仓库对createFileSystemWatcher的 mock 与断言模式覆盖在各模块测试中可作为行为参考例如src/core/ignore/tests/RooIgnoreController.spec.ts 断言vscode.workspace.createFileSystemWatcher被以期望的 pattern 调用src/services/code-index/processors/tests/file-watcher.spec.ts 用 mock watcher 验证监听逻辑packages/vscode-shim/src/tests/WorkspaceAPI.test.ts 验证 shim 层createFileSystemWatcher的事件发射与 dispose 行为。延伸2.2.28 在 2.2 系列中的位置apps/docs/docs/update-notes/v2.2.md 将 2.2.28 的文件监听改进作为 2.2 系列的亮点之一收录。2.2 系列整体围绕上下文注入与任务执行体验持续打磨2.2.28 的改动正好处于这一主线的关键节点-mention 是上下文注入的第一环其建议列表的可靠性直接影响 Agent 能否及时感知工作区文件的变化进而影响后续的read_file、edit、折叠上下文等整条链路。可以说这是一个小改动、大影响的典型 QOL 版本。小结改了什么Roo Code 2.2.28 使用createFileSystemWatcher实时监听工作区文件变化使 -mention 建议列表与磁盘状态保持同步更新说明、CHANGELOG为什么重要-mention 是用户向 Agent 注入文件上下文的核心入口解析实现、内容块生成文件建议列表的可靠性直接决定了上下文注入第一环的可用性怎么实现复用仓库中已被广泛验证的createFileSystemWatcher事件驱动模式如 FileContextTracker、CustomModesManager、McpHub 等从静态扫描升级为事件推送刷新适用前提该改动面向 VS Code 扩展运行环境在纯 CLI 或无 VS Code 场景下由 WorkspaceAPI shim 提供等价能力。【免费下载链接】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），仅供参考