让 OpenCode 去修 bug，你可以继续在原工作区改代码

你在检出的代码里写到一半，有人报告日期解析器出了问题。你想继续编辑手里的文件，又想把另一个任务交给编程智能体。只要双方开始在同一个目录里修改，哪怕补丁很小，也很难把它与你正在做的事分开。

11 月 6 日，OpenCode 2.2.6 为脚本式命令行运行加入了工作树选项。OpenCode 是开源编程智能体，提供交互式终端界面，也有从脚本运行提示词的独立命令。新选项让脚本可以在单独的 Git 工作树中启动 OpenCode，按需命名，同时保留原工作目录供你继续使用。同一版本还加入了模型上下文协议（MCP）连接的可选共享功能，前提是配置匹配。执行前值得问两个问题。智能体能修改哪些文件？又能使用哪些服务？OpenCode v2.2.6 发布 · OpenCode CLI 文档

好用的配置会给范围明确的小任务安排一个可预期的起点，留出检查改动的地方，并给每项离开项目范围的操作设定明确权限。

OpenCode 项目的终端截图，展示界面里的补丁和会话。发布标签下的官方品牌素材用于说明终端体验，并附有 MIT 许可声明。Telli.sh 调整了截图尺寸并添加留白。

单独的目录让差异清晰可查

Git 工作树让每项任务拥有各自的工作文件和索引。Telli.sh 原创图解。

Git 工作树可以把多个工作目录关联到同一个仓库。每个关联的工作树有自己的工作文件、索引和检出位置，大部分仓库数据则是共享的。你可以保留原先的编辑，单独查看智能体的补丁。工作树也会改变智能体看到的源码。即使都属于同一个仓库，第一个工作目录中的未提交改动也不会因此自动出现在第二个目录。Git 工作树文档

OpenCode 11 月 6 日的发布说明列出了三种写法。用 opencode run -w 或 opencode run --worktree 创建新工作树，用 --worktree=<name> 为它命名。工作树选项不能与 --continue 或 --session 一起使用。一次全新运行需要新的起始上下文。如果问题已经讨论了很久，把相关复现步骤和预期结果带到新的提示词里。OpenCode v2.2.6 发布 · 工作树实现与示例

可以把单独的目录当成一个审查场所。开始前记下你希望智能体使用的分支和提交。启动后检查新工作树的提交与状态。如果测试依赖未跟踪的夹具文件，或只存在于开发者编辑器中的变更，起点不同就能解释两次运行结果的差异。补丁可能适合旧代码，却不适用于即将发布的分支。

交给智能体大任务前，先试一个小改动

从你管理的仓库和目标明确的任务开始。修一个闰日解析测试，比大范围升级更适合作为第一次试验，因为预期结果容易验证。另一个范围类似的例子是用一个路由测试修复过时的导航链接。两种任务都应该明确什么行为要变，以及改完怎么检查。

1. 记录起始状态。 在当前目录执行 git status --short 和 git rev-parse HEAD，将输出与问题报告放在一起。如果已有通过的基线测试，写下复现方法。用 opencode --version 确认版本支持新选项。OpenCode v2.2.6 发布

2. 用命名工作树交给智能体一项任务。 在提示词中写清复现步骤和目标测试。下面以虚构的日期解析器为例，假设仓库已经有针对它的测试。要求把改动保留为未提交状态，便于检查。要设置更强的边界，可以从所选权限与运行环境入手。

   Shell在终端中运行

   opencode run --worktree=date-parser "Reproduce the leap-day parsing bug in the date parser tests. Fix the narrow cause, run the targeted tests, and leave the changes uncommitted for review."
   

3. 先定位新目录，再检查结果。 在原仓库执行 git worktree list，找到显示的路径。在新目录中检查 git status --short、git diff 和 git diff --cached。如果智能体暂存了改动，最后一条命令尤其重要。未跟踪文件也要另外检查。从智能体的目录重新运行目标测试，确认既覆盖闰年的 2 月 29 日，也覆盖这个日期不合法的年份。Git 工作树文档

4. 只带回已审查的改动。 将变更保留在独立目录中，直到可以把审查过的提交或补丁应用到目标分支。再次检查原目录的状态。记下需要保留的信息，确认没有还想留下的改动，再考虑清理智能体的工作树。Git 的工作树列表能帮你把目录与任务一一对应起来。Git 工作树文档

两件互不相关的问题同时出现时，同样的方法也有用。把它们拆成两个小任务，在集成前分别查看差异。使用不同工作树，一个智能体未暂存的测试改动就不会出现在另一个目录里。合并到同一分支时，两个修复仍可能冲突，特别是同时改了共享辅助代码时。分支集成与最终回归测试仍要走正常的审查流程。

决定在仓库以外允许哪些操作

两个工作树可能运行在同一操作系统账户下，也可能能读取同样的环境变量、凭据助手和网络。工作树选项决定运行从哪里开始，并隔开常规文件改动。任务需要更强的边界时，可以单独限制运行环境或账户。权限提示只约束遵循该规则的工具，进程最终能访问哪里取决于操作系统或执行环境。

把改动位置、工具审批和运行时访问范围分别确认。Telli.sh 原创图解。

OpenCode V2 的权限文档介绍了针对单项操作按顺序匹配的规则。结果包括 allow、ask 和 deny，以最后一条匹配规则为准。一个官方示例会在执行 shell 命令前要求确认，随后允许常见的查看命令，并拒绝推送。如果计划在无人审批时运行，先测试 ask 规则在该工作流中的表现，再放进周期任务。把禁止项写进配置，只向作业真正需要的服务提供短期且范围明确的凭据。OpenCode 权限文档

只改文档的任务能简单地测试这些层次。允许智能体修改示例项目中的一个段落。给它获准使用的服务提供方，不提供生产凭据。运行脚本，检查补丁是否只涉及预期文件。将来需要访问远程仓库或工单工具时，分别说明每项能力的用途，并逐项验证权限。

只在项目已有共同访问边界时共享连接

MCP 让智能体能调用其他程序提供的工具，例如文档搜索或问题跟踪器。11 月 6 日版本中，设置 pool: true 后，同一 OpenCode 服务器服务的多个目录可以在相关配置匹配时复用连接。官方 V2 文档明确指出，连接池适用于 2026-07-28 版协议。服务器若协商了较旧版本，就会维持独立连接。匹配也不只是让两个项目指向同一地址。远程配置和完成认证的账户必须相同。对本地服务器，还会比较命令、环境和工作目录。OpenCode v2.2.6 发布 · OpenCode MCP 连接共享文档

例如，两个工作树用同一账户查询公司内部文档。服务支持相应协议版本时，共享可以减少重复建立连接的开销。先确认两个目录本来就该访问相同资料，而且集成只提供它们需要的能力。一个工作树只需要公开文档，而另一个能创建内部工单时，分开连接更容易看清边界。

本地服务器也可能依赖当前工作目录。即使命令文字完全相同，从不同项目目录启动的进程也可能拥有不同的本地上下文。OpenCode 文档称，要跨项目复用本地连接，需要固定的工作目录，而且共享连接没有 roots。可以先从资源范围本身就明确的只读服务开始。如果工具行为依赖调用它的仓库，改用共享连接前先测清楚会变什么。OpenCode MCP 连接共享文档

脚本运行也需要结束条件

OpenCode 2.2.6 还加入了 --archived，使脚本或 CI 会话在启动时就归档，从常规会话列表中隐藏。这改变的是会话的展示方式。应将作业结果、工作树路径和测试结果放在审查者找得到的地方。等到即使日常列表为空，也有可靠方式定位相关补丁时，再使用这个选项。11 月 6 日发布说明称，--continue 会跳过归档会话。OpenCode v2.2.6 发布

同一版本还改了脚本运行的退出时机。它会等提示词启动的后台命令、子智能体和图像作业结束后再退出。发布说明称，等待没有内部超时，开发服务器或文件监听器可能让运行一直挂着。自动测试适合用检查完成就会退出的命令，并为外层 CI 步骤设定时间上限。把主动取消、测试失败和智能体报告成功区分开。运行超时时，重新执行或集成之前，先检查实际生成的改动处于什么状态。OpenCode v2.2.6 发布

试验跑通后，判断能否省时间时，可以看智能体的完成消息以外的指标。准备一次全新运行要多久？审查者看懂改动并验证要多久？修复无关改动或排查卡住的工具出现得多频繁？挑几项规模相近的任务，比较时把准备和审查时间也算进去。单独的工作树最有价值的时候，是它能让补丁小到由一个人清楚地负责。

起点清晰，责任也更清楚

工作树选项给审查者一个明确的起点。一个人可以看到基线、查看改动并重跑测试，另一位开发者同时继续自己的工作。连接共享和执行权限也值得如此明确。最容易交接的是小补丁，它本身就能说明从哪里开始、改了什么，以及依据什么可以合并。

来源

• OpenCode 官方终端截图与仓库许可证

• OpenCode v2.2.6 发布，2026 年 11 月 6 日

• OpenCode CLI 文档

• OpenCode V2 权限

• OpenCode MCP 连接共享

• Git 工作树手册

---

想把工作背后的决定和试验存成可搜索的记录，可以创建 Telli.sh 账户。