[控场AI]
· 5 分钟阅读· 2,625 字

为并行AI代理自建VS Code扩展:Stack体验

为并行AI代理自建VS Code扩展:Stack体验

开发者自建开源 VS Code 扩展 Stack,用 git worktree 并行运行真实 AI 代理并保留 IDE 能力。

文章介绍了一位开发者打造的开源 VS Code 扩展 Stack。针对现有并行代理工具内存占用高、把开发者拉出编辑器的问题,Stack 为每个任务创建独立的 git worktree,在其中运行真实的 Claude Code、Codex CLI 或 opencode,并由 tmux 托管以保证重载窗口不中断任务。侧边栏集中显示各任务状态与待处理提问,快捷键可跳转到等待最久的任务。Stack 保留了 VS Code 的代码导航、独立调试端口、带逐行评论的 diff 审查以及独立 docker 环境。文章也说明了平台限制、未上架 Marketplace、Codex hook 默认禁用等注意事项,并提到作者用并行代理改进该工具本身,项目以 MIT 协议开源。

为并行AI代理自建VS Code扩展:Stack体验

当多个AI编码代理同时工作时,开发者往往被迫离开熟悉的IDE,在聊天窗口和终端之间来回切换。一位开发者为此打造了开源VS Code扩展Stack,让Claude Code、Codex CLI等代理在独立git worktree中并行运行,同时保留完整的代码导航和调试能力。

Stack扩展界面示意

为什么现有工具不够用

作者尝试了多款并行代理工具,但都不太符合自己的工作流。Superset在他的机器上内存占用过高;Warp作为终端很出色,但在阅读和浏览代码、文档时显得力不从心。更普遍的问题是,大多数工具会把开发者拉出编辑器,提供一个聊天或终端窗口,代码反而成了次要内容。

这些工具本身并不差,只是与"始终回到VS Code阅读代理产出"的习惯不匹配。作者的需求很明确:保留VS Code的导航、扩展、调试器和搜索,只在其上补充并行代理所需的能力。

Superset 是早期出现的并行 AI 代理编排工具之一,主打在单一界面中同时运行多个编码代理并统一管理它们的输出。它通常以独立应用或终端多路复用方案的形式存在,内置了代理会话调度、状态聚合等能力。不过这类工具往往把代理的聊天界面和编排逻辑作为核心,资源开销相对较高——尤其是同时拉起多个代理进程时,每个会话的内存与 CPU 占用会叠加。对于习惯在 IDE 内完成阅读、搜索与调试的开发者,Superset 更偏向“代理控制台”而非“编码环境”,这也是作者反馈其内存占用过高、与自身工作流不契合的原因。

Stack的核心设计

Stack是一款MIT协议的开源VS Code扩展。每个任务拥有独立的git worktree——即带有独立分支的仓库工作副本,内部运行真实的代理:Claude Code、Codex CLI或opencode。代理运行在tmux中,因此即使重新加载VS Code窗口,任务也不会中断。

侧边栏会为每个任务显示状态:谁在工作、谁需要你介入、哪些已准备好审查。当代理提问时,问题直接显示在对应行上。快捷键Cmd+Alt+J可跳转到等待最久的任务。

git worktree 是 Git 自 2.5 版起提供的原生命令,允许在同一个仓库上挂载多个工作目录,每个目录检出不同的分支,而共享同一份 .git 对象库与历史。与复制仓库或重新 clone 相比,worktree 几乎不额外占用磁盘,分支切换也不会互相干扰。对并行代理场景而言,这意味着每个任务可以拥有独立的分支、独立的工作区文件和独立的未提交改动,代理之间的提交、暂存、甚至冲突修复都彼此隔离;同时开发者仍能用同一套 Git 工具在各 worktree 间审阅变更。需要注意的是,同一分支不能同时被两个 worktree 检出,任务结束后应及时清理不再使用的 worktree。

留在编辑器内的五个理由

真实地阅读和导航代码:每个worktree作为文件夹在编辑器中打开,搜索和快速打开仅限于当前worktree,五个代理的工作不会混入搜索结果。

真实的调试能力:每个worktree拥有独立的调试端口和launch.json,可以在一个任务中停在断点,同时另一个任务继续运行。默认配置Node,可改为VS Code支持的任何调试器。

不离开编辑器完成审查:提供带逐行评论的diff面板,评论直接发送给代理,无需经过PR流程。

独立的任务环境:每个worktree可拥有自己的docker compose,端口自动生成避免冲突,并在代理启动前运行安装脚本(依赖、.env)。

使用真实的CLI:调用的是你自己的claude或codex,带着你的配置和订阅,而非重新实现。

MCP(Model Context Protocol) 是 Anthropic 提出并开源的协议,用于让 AI 模型以统一方式连接外部工具与数据源,例如工单系统、数据库、文件系统或本地服务。MCP 服务器暴露一组标准化的工具和资源,客户端(如 Claude Code)按需调用,从而把模型的推理能力与真实系统的读写能力结合起来。Stack 内置 MCP 服务器后,Claude Code 面板不只是对话界面,而可以充当任务管理器:通过 /stack-task 指令并借助 Jira MCP 读取工单内容,再据此创建 Stack 任务、分配 worktree 并启动代理,把“从工单到编码”的流程串成一条链路。

典型工作流

在New task中写下任务,Stack创建分支和worktree、准备环境并启动代理。代理工作期间,开发者在编辑器中阅读和导航代码,需要介入时在对应行看到提问。在编辑器中审查diff、评论并回传给代理;若发现问题,就地调试。

作者最近开始使用的新功能是Stack内置的MCP服务器,将Claude Code面板作为管理器:输入/stack-task并附上工单,它通过Jira MCP读取工单并建立任务。

使用前需要了解的限制

Stack目前支持macOS和Linux,依赖tmux;Windows仅限WSL,原生通知仅限macOS。尚未上架VS Code Marketplace,需通过.vsix文件安装,版本为0.1.0。

为了显示实时状态,Stack会在每个代理中注册hook。在Claude Code中会写入~/.claude/settings.json,首次修改配置文件时会保留.stack-backup备份。Codex的hook属于实验性功能且默认禁用,需在配置中手动启用,在此之前其会话不会在侧边栏改变状态。Codex还会要求先信任这些hook。

用代理改进代理工具

作者用并行代理改进Stack本身:一些按区域审查代码,一些修复bug,各自在独立worktree中工作,随后完成重新设计。目前项目有2102个测试,对所测量的代码达到100%覆盖率(React视图作为界面未纳入测量)。

代理写代码,但理解代码的仍是人——这正是作者选择留在编辑器里的原因。代码已在GitHub以MIT协议开源。

分享:

相关推荐