OpenCode：可执行、可调试、可回滚的AI编程代理

1. OpenCode 是什么？一个真正能写代码的 AI 编程代理，不是“智能聊天框”

OpenCode 不是又一个套着 Terminal 外壳的 ChatGPT 网页版，也不是只能回答“Python 怎么读文件”的问答机器人。它是一个可执行、可调试、可回滚、可嵌入工作流的 AI 编程代理（AI Coding Agent）。我用它重构过三个中型前端项目、给遗留 Java 微服务补全了缺失的单元测试、还帮团队新人在 20 分钟内搞定了一个卡了三天的 Kafka 消费者重平衡逻辑。它的核心价值在于：把“告诉 AI 我想要什么”，变成了“让 AI 去做我想要的，并且我能随时叫停、检查、修改、重来”。

这背后是几个关键设计差异。第一，它不依赖你手动复制粘贴上下文。当你在项目根目录运行opencode，它会自动扫描整个代码库结构、依赖关系、配置文件和 Git 历史，构建出一个轻量级的“项目知识图谱”。第二，它有明确的三阶段工作流：Plan（计划）、Build（构建）、Review（审查），每个阶段都有独立的交互界面和状态机，而不是一股脑把所有提示词塞进一个大模型。第三，它原生支持原子化操作与版本控制集成——每一次代码修改都会生成一个 Git Commit，/undo和/redo命令直接操作的是 Git 的 staging area，不是内存里的临时快照。这意味着你随时可以git diff看它改了哪几行，git log查它为什么这么改，甚至git bisect定位它引入的 bug。

从使用形态看，OpenCode 提供了 TUI（终端界面）、桌面应用、VS Code 插件、JetBrains IDE 插件四种入口。但别被“多种形态”迷惑——它们底层共享同一套 Agent Runtime 引擎。TUI 是最纯粹、最可控的形态，适合深度调试；桌面版适合快速启动、离线使用；IDE 插件则无缝融入你已有的开发习惯。我自己的主力工作流是：日常开发用 VS Code 插件（Ctrl+Shift+O 唤出），复杂重构切到 TUI（opencode --tui）进行分步 Plan，关键逻辑变更前用桌面版导出一份.opencode/plan.json存档。这种组合不是为了炫技，而是因为不同场景下，对“控制粒度”和“反馈速度”的需求完全不同。

你可能会问：它和 GitHub Copilot、Tabnine、CodeWhisperer 有什么本质区别？答案很直白：Copilot 是“代码补全器”，它猜你下一行要写什么；OpenCode 是“代码执行器”，它理解你整个函数要做什么，然后自己写出完整的实现、更新测试、修改文档。举个具体例子：当我在一个 React 组件里输入// Add dark mode toggle that persists in localStorage，Copilot 可能补全一行useEffect(() => { ... })；而 OpenCode 会先问：“当前组件是否已有主题上下文？localStorage的 key 名称规范是什么？需要支持系统级暗色模式检测吗？”，等你确认后，它会生成完整的DarkModeToggle.tsx组件、更新App.tsx的 Provider 配置、添加theme.test.tsx测试用例，并在README.md里补充使用说明。这个过程不是一次性的，你可以随时按 Tab 键在 Plan 和 Build 模式间切换，像指挥一个坐在你工位旁的资深同事一样。

所以，如果你正在寻找一个能真正帮你“写代码”而不是“猜代码”的工具，OpenCode 值得你花 30 分钟认真读完这篇指南。它不适合只想点几下就生成完整网站的零基础用户，但对任何需要处理真实业务代码、有 Git 协作经验、希望 AI 成为“可信赖协作者”而非“不可控黑箱”的开发者，它可能是目前最接近理想形态的选择。

2. 安装与环境准备：避开那些让你卡在第一步的坑

安装 OpenCode 看似简单，但实际踩过的坑比想象中多得多。我见过太多人卡在“curl 命令没反应”、“npm install 报错找不到 Python”、“WSL 里权限 denied”这些环节，最后放弃。这里不讲官网那套“一键安装”的理想路径，只说真实世界里，在 Windows、macOS、Linux 三大平台下，最稳、最快、最不容易翻车的实操方案。

2.1 Windows 用户：别碰原生 CMD/PowerShell，WSL 是唯一正解

Windows 原生环境对 OpenCode 的支持是“名义上存在，实际上残缺”。官方文档里提到的 Chocolatey、Scoop、NPM 安装方式，在 Win11 22H2 及以上版本中，90% 的概率会遇到glibc兼容性问题或pty终端模拟失败。我试过 7 种组合，最终结论是：必须用 WSL2。这不是妥协，而是利用 Linux 内核的稳定性来规避 Windows 底层的兼容性黑洞。

具体步骤：

1. 启用 WSL2：以管理员身份打开 PowerShell，依次执行：

   dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

   重启电脑后，从 Microsoft Store 安装 Ubuntu 22.04 LTS。
2. 配置 WSL2 为默认版本：PowerShell 中执行wsl --set-default-version 2。
3. 在 WSL 中安装 OpenCode：绝对不要用curl | bash。这个脚本在 WSL 下经常因网络超时或证书问题中断。改用 Homebrew（WSL 官方推荐）：

   # 安装 Homebrew（如果未安装） /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" # 添加 Anomaly 的 tap（这是关键！官方 brew formula 更新慢，用他们的 tap 才能拿到最新版） brew tap anomalyco/tap # 安装 OpenCode brew install opencode

   这一步耗时约 2-3 分钟，但成功率接近 100%。安装完成后，opencode --version应该返回类似v0.12.3的版本号。

提示：WSL 中的 OpenCode 默认使用 WSL 自带的ubuntu用户，但它的$HOME目录和 Windows 的C:\Users\XXX是隔离的。强烈建议将你的项目代码放在 WSL 的/home/username/projects/下，而不是挂载的/mnt/c/盘。后者会导致文件权限混乱和 Git 性能暴跌。我曾因此浪费一整天排查“为什么 OpenCode 修改的文件 Git 显示为 deleted”。

2.2 macOS 用户：Homebrew + M1/M2 芯片的专属优化

macOS 上安装最顺畅，但 M1/M2 芯片用户有个隐藏陷阱：官方brew install opencode安装的是 Intel 架构的二进制包，运行时会通过 Rosetta 2 转译，性能损失约 30%，且偶尔触发SIGILL错误。正确姿势是：

1. 确保 Homebrew 已为 ARM64 架构：在终端执行arch，输出应为arm64。如果不是，重新安装 Homebrew（官网有详细指引）。

2. 使用 Anomaly 的 tap 并指定架构：

   brew tap anomalyco/tap # 这条命令会自动下载并编译 ARM64 原生版本 brew install --build-from-source opencode

   编译过程约 5-8 分钟，但换来的是原生性能和绝对稳定。编译完成后，file $(which opencode)应显示Mach-O 64-bit executable arm64。

3. 解决终端模拟器兼容性问题：OpenCode 的 TUI 对终端渲染要求极高。iTerm2 是首选，但必须关闭“Use Unicode version of font for non-ASCII text”选项（Preferences > Profiles > Text），否则中文字符会显示为方块。Alacritty 和 Kitty 也完美支持，但 WezTerm 在 macOS 上偶发光标闪烁问题，不推荐。

2.3 Linux 用户（Ubuntu/Debian/Arch）：绕过包管理器的“版本陷阱”

Linux 发行版众多，但核心矛盾只有一个：包管理器仓库里的 OpenCode 版本永远比 GitHub Release 慢 2-3 个大版本。Ubuntu 的apt、Debian 的apt、甚至 Arch 的 AURopencode-bin，都存在这个问题。而 OpenCode 的核心功能（如 LSP 服务器集成、MCP 协议支持）迭代极快，旧版本可能根本无法连接你配置的 LLM。

我的解决方案是：跳过所有包管理器，用mise工具进行版本管理。mise是一个现代化的 runtime 版本管理器，比nvm或pyenv更轻量，且原生支持 OpenCode。

# 安装 mise（官方推荐方式） curl https://mise.run | sh # 重启终端或执行 source "$HOME/.local/share/mise/init.sh" # 安装最新版 OpenCode（自动从 GitHub Releases 下载预编译二进制） mise use -g github:anomalyco/opencode

mise的优势在于：它下载的是官方 Release 页面的opencode-vX.Y.Z-linux-x64.tar.gz，保证 100% 原汁原味；它会将二进制文件软链接到~/.local/bin/opencode，无需修改$PATH；更重要的是，当你需要降级到某个特定版本（比如 v0.11.0 来复现一个 bug）时，只需mise use -g github:anomalyco/opencode@v0.11.0，秒级切换。

注意：Docker 方式（docker run -it --rm ghcr.io/anomalyco/opencode）仅适用于快速体验，绝不能用于真实开发。容器内的文件系统是临时的，你无法保存配置、无法访问本地 Git 仓库、无法调试生成的代码。它只是一个“沙盒演示”，不是开发环境。

3. 核心配置与初始化：让 OpenCode 真正理解你的项目

安装完成只是开始，真正的门槛在于“如何让 OpenCode 理解你的项目”。很多用户抱怨“它总是答非所问”、“生成的代码完全不符合项目规范”，问题 90% 出在配置环节。OpenCode 不是通用模型，它是一个需要“入职培训”的协作者。下面是我总结的、经过 5 个不同技术栈项目验证的标准化配置流程。

3.1 API 密钥配置：安全与可用性的平衡术

OpenCode 本身不提供大模型，它是一个调度器，需要你接入外部 LLM（如 Anthropic Claude、OpenAI GPT、Ollama 本地模型）。配置密钥看似简单，但有三个致命细节：

1. 密钥存储位置：OpenCode 默认将密钥存放在~/.config/opencode/config.yaml。绝对不要在这里明文写入你的生产 API Key。正确做法是使用环境变量：

   # 在 ~/.zshrc 或 ~/.bashrc 中添加 export OPENCODE_API_KEY="sk-xxxxxx" export OPENCODE_PROVIDER="anthropic" # 或 "openai", "ollama"

   启动 OpenCode 时，它会自动读取这些环境变量。这样既安全（密钥不在磁盘上），又便于在不同项目间切换模型。

2. Provider 选择的实战权衡：

   • Claude 3.5 Sonnet：综合能力最强，代码理解、长上下文（200K tokens）、推理能力碾压其他模型。但 API 调用成本高，且对中文注释的生成有时过于“教科书化”，缺乏工程直觉。
   • GPT-4o：响应速度最快，多模态（图片理解）是亮点。但在处理大型 monorepo 时，容易丢失跨包依赖关系，生成的 import 语句常出错。
   • Ollama + DeepSeek-Coder 33B：这是我个人主力推荐的组合。在 M2 Max 笔记本上，33B 模型的推理速度比 GPT-4o API 快 3 倍，且完全离线、100% 数据私有。配置方法：export OPENCODE_PROVIDER="ollama"，export OPENCODE_OLLAMA_MODEL="deepseek-coder:33b"。首次运行时，Ollama 会自动下载模型（约 20GB），耐心等待即可。

3. 密钥轮换与失效处理：当你的密钥因用量超限或安全策略被禁用时，OpenCode 不会友好地提示“API Key Invalid”，而是静默失败，表现为 TUI 里光标一直闪烁、无任何响应。此时，你需要手动执行/connect命令，重新触发认证流程。记住这个快捷键：Ctrl+C可强制中断当前卡死的操作，回到命令行。

3.2 项目初始化：/init命令背后的秘密

在项目根目录运行opencode后，第一件事不是提问，而是执行/init。这个命令远不止是“创建一个 AGENTS.md 文件”那么简单。它会触发一个完整的项目分析流水线：

1. 代码库结构测绘：扫描所有package.json、pom.xml、Cargo.toml、go.mod等文件，构建依赖图谱。它会识别出你的项目是 monorepo 还是单体，是前端、后端还是全栈。
2. 编码规范提取：分析.prettierrc、.eslintrc.js、.editorconfig、checkstyle.xml等配置文件，学习你的缩进风格、命名约定、空格规则。这是它后续生成代码能“看起来像你写的”的关键。
3. Git 历史摘要：读取最近 50 次 commit 的 message，提取高频关键词（如 “refactor”, “fix auth”, “add logging”），形成项目语义上下文。这解释了为什么你问“如何修复登录失败”，它能精准定位到auth.service.ts而不是泛泛而谈。

/init生成的AGENTS.md文件，就是这个分析结果的摘要。它不是给你看的，而是给 OpenCode 的 Agent Runtime 读的。务必把它提交到 Git。我见过最惨的案例：一个团队成员没提交AGENTS.md，导致他本地的 OpenCode 总是生成不符合团队规范的代码，而其他人一切正常。这就是“环境不一致”引发的协作灾难。

实操心得：对于大型项目（>10 万行代码），/init可能耗时 2-5 分钟。此时不要关闭终端，它在后台默默工作。你可以用ps aux | grep opencode查看进程，/init进程的 CPU 占用会飙升到 100%，这是正常现象。如果超过 10 分钟无响应，大概率是某处node_modules或target目录过大，需要在.opencodeignore文件中排除（语法同.gitignore）。

3.3 主题与快捷键：把 TUI 变成你的“第二大脑”

OpenCode 的 TUI 不是静态界面，而是一个高度可定制的工作台。默认的深色主题（Zen）很好看，但对长时间编码并不友好。我将它调整为“浅色底 + 深蓝文字 + 高亮色块”，护眼效果提升显著：

# ~/.config/opencode/config.yaml theme: name: "custom" colors: primary: "#1e40af" # 主色调：深蓝色 background: "#f9fafb" # 背景：极浅灰 text: "#1f2937" # 文字：深灰 highlight: "#3b82f6" # 高亮：明亮蓝

更关键的是快捷键重映射。默认的Tab切换 Plan/Build 模式很好，但Ctrl+R（重试）和Ctrl+U（撤销）太难按。我在配置里加了：

keybindings: - key: "ctrl-r" action: "retry_last_command" - key: "ctrl-u" action: "undo_last_change" - key: "ctrl-s" action: "save_current_plan" # 将当前 Plan 保存为 JSON，方便分享和复盘

这些配置让 TUI 从一个“需要学习的工具”，变成了一个“肌肉记忆就能操作的延伸器官”。当你连续工作 4 小时后，手指会本能地按下Ctrl+S保存一个关键 Plan，而不是去想“怎么导出”。

4. 实战工作流：从 Plan 到 Build，一个真实重构案例全记录

理论讲完，现在用一个真实的、我在上周完成的重构任务，带你走一遍 OpenCode 的完整工作流。这个案例能清晰展示：它如何把一个模糊的需求，拆解成可执行、可验证、可回滚的精确步骤。

4.1 任务背景：一个“简单”的需求，背后是 3 个技术债

需求原文：“用户反馈，删除笔记后无法恢复，需要增加‘软删除’和‘回收站’功能。” 表面看，这只是前端加个按钮、后端改个 SQL。但深入分析，它涉及：

• 后端：notes表需新增deleted_at字段，所有查询需过滤deleted_at IS NULL，DELETE语句需改为UPDATE SET deleted_at = NOW()。
• 前端：需新增RecycleBinScreen.vue，列表需区分“活跃笔记”和“已删除笔记”，需实现undelete和permanent delete两个 API 调用。
• 测试：所有现有测试需确保不因deleted_at字段而失败，需新增回收站相关测试用例。

这是一个典型的、需要跨多层、多仓库协作的“小需求”。手动做，至少 4 小时；用 OpenCode，我们看看实际花了多久。

4.2 Step 1：Plan 模式 —— 让 AI 先画一张施工图

在项目根目录启动opencode --tui，进入后直接按Tab键切换到Plan 模式（右下角会显示<PLAN>）。然后输入需求描述：

When a user deletes a note, we'd like to flag it as deleted in the database. Then create a screen that shows all the recently deleted notes. From this screen, the user can undelete a note or permanently delete it. The backend is a NestJS API with TypeORM, frontend is Vue 3 with Pinia.

注意，这里我提供了精确的技术栈信息（NestJS, TypeORM, Vue 3, Pinia），而不是泛泛的“Node.js”或“JavaScript”。这是 Plan 阶段成功的关键——信息越具体，Plan 越精准。

OpenCode 的响应非常专业：

1. 数据库迁移：建议使用 TypeORM Migration 生成AddDeletedAtToNotes1712345678901.ts，包含ALTER TABLE notes ADD COLUMN deleted_at TIMESTAMP NULL。
2. 后端 API：
   • 新增notes.controller.ts的undeleteNote()和permanentDeleteNote()方法。
   • 修改notes.service.ts的findAll()方法，添加where: { deleted_at: IsNull() }。
   • 新增recycle-bin.controller.ts，提供GET /recycle-bin接口。
3. 前端：
   • 新增views/RecycleBinScreen.vue，使用useNotesStore()获取数据。
   • 新增components/NoteItem.vue的isDeleted属性和对应 UI。
   • 修改router/index.ts，添加/recycle-bin路由。
4. 测试：建议在notes.e2e-spec.ts中新增should list deleted notes in recycle bin测试。

这个 Plan 不是代码，而是一份带优先级的待办清单。它没有假设任何不存在的 API，所有建议都基于它扫描到的现有代码结构。例如，它知道useNotesStore()存在，是因为它读取了src/stores/notes.ts。

关键技巧：Plan 阶段，不要急于让它开始 Build。先用/review命令，逐条检查 Plan 的每一点。我发现它漏掉了“前端需在NoteItem.vue中添加restore按钮的权限控制（只有 owner 可恢复）”。于是我追加提示：

Also, add permission check in NoteItem.vue: only the note owner can see the 'Restore' button.

它立刻修正了 Plan，增加了这一条。这个“Plan -> Review -> Refine”的循环，是保证质量的核心。

4.3 Step 2：Build 模式 —— 让 AI 执行，你来监督

确认 Plan 无误后，再次按Tab键，切换到Build 模式（右下角变为<BUILD>）。此时，OpenCode 会按照 Plan 的顺序，一项一项地执行。

它首先生成数据库迁移文件，并询问：

I will now create the migration file. Should I proceed? (y/n)

输入y，它立即在src/migrations/下创建了文件，并自动git add。

接着，它开始修改notes.service.ts。这时，TUI 左侧会显示它将要修改的原始代码片段，右侧显示它计划生成的新代码，中间用---分隔。你可以像git diff一样，逐行审查。当它修改findAll()方法时，我注意到它错误地将where: { deleted_at: IsNull() }写成了where: { deleted_at: null }。我立刻按Ctrl+C中断，然后输入/undo，它瞬间回滚了这次修改，并回到了上一步。

这就是 OpenCode 的强大之处：Build 不是“黑箱执行”，而是“透明化协作”。你不是旁观者，而是实时的 Code Reviewer。我最终花了 12 分钟，完成了全部 Build 步骤，期间手动干预了 3 次（2 次修正类型错误，1 次调整 CSS 类名）。

4.4 Step 3：验证与收尾 —— 用 Git 和 Jest 做最终审判

Build 完成后，TUI 会提示：

All changes have been applied. Please review and commit.

此时，绝对不要直接git commit。正确的验证流程是：

1. 运行git status：检查所有被修改的文件是否都在预期列表中。我这次看到src/migrations/...ts,src/controllers/notes.controller.ts,src/views/RecycleBinScreen.vue等 7 个文件，和 Plan 完全一致。
2. 运行git diff：重点检查数据库迁移和 API 控制器，确保 SQL 和 HTTP 方法（@Delete()vs@Patch()）正确。
3. 运行npm run test：所有 Jest 测试必须 100% 通过。OpenCode 生成的测试用例通常很基础，你需要自己补充边界条件（如“恢复一个已被永久删除的笔记”）。
4. 手动测试：启动前端和后端，点击删除一个笔记，确认它出现在回收站，点击恢复，确认它回到主列表。

整个验证过程花了我 8 分钟。最终，我执行了git commit -m "feat(notes): add soft delete and recycle bin"，并推送到远程。从启动 OpenCode 到 PR 创建，总耗时 32 分钟。而我估算，纯手工完成，至少需要 3.5 小时。

5. 常见问题与避坑指南：那些官方文档不会告诉你的真相

在超过 200 小时的实际使用中，我整理了一份“血泪教训”清单。这些问题，要么是官方文档一笔带过，要么是社区讨论里零散提及，要么是只有在特定场景下才会爆发的幽灵 Bug。它们不是“故障”，而是 OpenCode 设计哲学与现实世界碰撞出的必然产物。

5.1 问题速查表：症状、原因、解决方案

5.2 独家避坑技巧：来自一线战场的经验

技巧 1：用--dry-run模式做“沙盒演练”在对生产代码进行任何重大修改前，务必先用--dry-run参数。例如：

opencode --dry-run --plan "Refactor UserService to use Repository pattern"

它会输出一个完整的 Plan Markdown 文件，但绝不修改任何一行代码。你可以把这个文件发给团队评审，或者用diff工具对比它和现有代码，提前发现潜在风险。这是我上线前必做的一步，避免了 3 次可能的线上事故。

技巧 2：为 OpenCode 创建专属的 Git 用户OpenCode 生成的每次 commit，默认使用你系统的 Git 用户名和邮箱。这会导致你的个人提交记录里混入大量chore(opencode): auto-generated code。解决方案是：在项目根目录的.git/config中，为 OpenCode 单独配置：

[includeIf "gitdir:/path/to/your/project/"] path = .gitconfig-opencode

然后创建.gitconfig-opencode：

[user] name = OpenCode Bot email = opencode@localhost

这样，所有 OpenCode 的提交都清晰标记为机器生成，不影响你的个人贡献统计。

技巧 3：当 Plan 失败时，用@符号进行“文件级聚焦”有时 OpenCode 的 Plan 会过于宽泛，因为它“看”到了整个项目。这时，用@符号精准指定文件，能极大提升 Plan 质量。例如：

How should I modify @src/services/auth.service.ts to add JWT refresh logic?

@后面的路径必须是 OpenCode 扫描到的、存在于AGENTS.md中的文件。它会忽略所有其他文件，只分析这个文件的上下文，Plan 的准确率会从 60% 提升到 95% 以上。

技巧 4：自定义 Prompt 模板，固化团队最佳实践OpenCode 支持在~/.config/opencode/prompts/下放置自定义 prompt。我创建了一个vue-component.md：

You are an expert Vue 3 developer using Composition API and Pinia. Always use <script setup> syntax. Always define props with defineProps<{...}>. Always use defineEmits<[...]> for events. Never use Options API.

然后在提问时引用它：

Create a new component for user profile using @prompts/vue-component.md

这确保了 AI 生成的 Vue 代码，100% 符合团队的编码规范，省去了大量后期格式化工作。

6. 进阶玩法：超越基础功能的生产力倍增器

当你熟练掌握核心工作流后，OpenCode 的真正威力才开始显现。它不是一个“功能固定”的工具，而是一个可以被深度编程、与你现有技术栈无缝融合的“智能胶水”。以下是我挖掘出的、能将日常开发效率提升 2-3 倍的进阶用法。

6.1 创建自定义命令：把重复劳动变成一键操作

OpenCode 允许你通过~/.config/opencode/commands/目录下的 YAML 文件，定义自己的命令。例如，我们团队每天都要执行“清理所有console.log，替换为logger.debug”，这是一个枯燥且易出错的手动任务。我创建了cleanup-logs.yaml：

name: cleanup-logs description: Replace all console.log with logger.debug and add file context trigger: "/cleanup-logs" steps: - type: "find-and-replace" files: ["src/**/*.ts", "src/**/*.js"] find: "console\.log\((.*)\);" replace: "logger.debug('[{{file}}] $1');" - type: "git-commit" message: "chore: cleanup console.log, replace with logger.debug"

现在，只要在 TUI 里输入/cleanup-logs，它就会自动扫描所有 TypeScript/JavaScript 文件，执行正则替换，并生成一个干净的 commit。这个命令我每周调用 15 次以上，累计节省了超过 10 小时的机械劳动时间。

6.2 集成 LSP 服务器：让 AI 理解你的代码，不只是“看到”

OpenCode 原生支持 Language Server Protocol (LSP)。这意味着，它不仅能读取你的代码文件，还能像 VS Code 一样，理解符号定义、跳转到定义、查找所有引用。要启用它，只需在config.yaml中添加：

lsp: enabled: true server: "typescript-language-server" args: ["--stdio"]

启用后，当你在 Plan 阶段提问 “Where is thecalculateTaxfunction defined?”，它不再只是文本搜索，而是会调用 TypeScript 的语言服务器，精准定位到src/utils/tax-calculator.ts的第 42 行。这使得它在处理大型、复杂的代码库时，Plan 的准确性提升了 40%。我强烈建议所有使用 TypeScript 或 Python（配合pylsp）的团队开启此功能。

6.3 构建 MCP（Model Context Protocol）服务：让多个 AI 协同工作

MCP 是 OpenCode 的一个前沿特性，允许你将不同的 AI 模型“串联”起来，各司其职。例如，我可以构建一个“代码审查流水线”：

• Step 1 (Claude)：负责整体架构和逻辑 Plan。
• Step 2 (GPT-4o)：负责生成符合 ESLint 规则的、格式完美的代码。
• Step 3 (本地 Ollama)：负责运行单元测试，并根据失败的测试用例，生成修复建议。

这需要编写一个简单的 MCP 服务（用 Python 的fastapi即可），然后在 OpenCode 配置中指向它。虽然搭建需要 2-3 小时，但它带来的收益是：一次提问，得到的不再是“可能正确”的代码，而是“经过多层验证、高概率正确”的代码。这是我目前在探索的最高阶用法，也是 OpenCode 区别于所有竞品的终极壁垒。

我个人在实际操作中的体会是：OpenCode 不是一个“替代开发者”的工具，而是一个“指数级放大开发者能力”的杠杆。它无法教会你什么是 SOLID 原则，但它能让你在 5 分钟内，把一个遵循 SOLID 原则的设计，变成可运行、可测试、可部署的代码。它的学习曲线比 Copilot 陡峭，但一旦越过那个临界点，你获得的生产力回报，是线性的、可持续的、且难以被其他工具取代的。