上篇发完之后后台留言最多的问题几乎都集中在同一类追问上内置工具到底怎么用、某个报错是模型厂商的问题还是订阅配置的问题、装好之后除了聊代码还能不能接入正经工作流。这篇就把这些尾巴全部收干净重点拆四个东西——工具、服务面、外壳、实战集成。这四个词不是营销包装而是你真正拿 opencode 替代日常编辑器时绕不开的四级台阶工具层决定它能多主动地碰文件系统服务面决定你手里一堆模型额度和订阅放哪边、怎么完全不浪费外壳决定你每天和它交互的姿势集成决定它能不能落进团队工程流程而不是角落里的玩具。延续上篇的节奏这篇依然用我自己实测过的配置和命令来讲版本相关的细节以你安装时的文档为准但整体思路上保证稳定。1. 工具层把“聊天窗口”变成表达的车间1.1 内置工具清单比你想的更能干活第一次用 opencode 的很多人会把它当成一个高级聊天框问一句答一句。实际上它真正值钱的地方在于那套内置工具。我日常高频用到的工具大致有七类工具干什么用的我实际用它的场景list列出目录结构刚接手一个不熟的仓库先让它列一遍根目录和 src 下的结构确认模块划分read读取文件内容定位到具体文件后让 Agent 把文件真正读进上下文而不是光靠文件名猜grep搜文本内容找函数定义、找某个配置项在哪些文件里被引用glob匹配文件路径快速找出所有 *test.ts、所有 *.config.js 归档bash执行命令跑测试、装依赖、看 git 状态、执行构建所有要出真实结果的动作都走这里edit以补丁方式改源码改完代码后由它直接落盘而不是让 Agent 只在回复里给一段代码让你手动复制task起一个子代理单独跑一件事大任务拆成子任务并行比如一个代理去查文档另一个代理留下来改主逻辑这七个工具加在一起拼出了一个完整的“观察—定位—修改—验证”闭环。观察靠 list 和 read定位靠 grep 和 glob修改靠 edit验证靠 bash。缺任何一个环Agent 的表现都会打明显折扣。我印象最深的一次是排查一个非门面仓库的构建超时问题。仓库不大但 Dockerfile 里有好几层 COPYopencode 先用 glob 找到了 Dockerfile 和相关 entrypoint 脚本read 看完层级关系又用 grep 在代码里搜出所有依赖本地缓存目录的位置最后 bash 跑了一遍docker build --progressplain把日志拉出来。整个排查过程我基本只负责看结论它在终端里自己完成了文件系统的读写遍历。1.2 自定义工具:把项目脚本变成 Agent 的双手内置工具再强也无法覆盖每个项目自己的那些“土脚本”。比如我想让 Agent 在改完代码后自动跑 TypeScript 类型检查、自动整理 import 顺序这就不属于内置工具的范畴得自己注册。opencode 里加自定义工具的路径不算复杂核心是往配置文件里挂一段可执行的命令。我这里给一个示意配置放在 opencode.json 的 tools 字段下面{ tools: { check_types: { command: bash, args: [-c, pnpm exec tsc --noEmit], description: 运行 TypeScript 类型检查确认没有类型错误 }, format_lint: { command: bash, args: [-c, pnpm exec eslint --fix .], description: 自动修复 lint 问题并在修复后重新检查 } } }这样配置之后Agent 在执行任务的过程中如果项目规则手册里写了“改完代码必须做类型检查”它就会把 check_types 当成一次可用的“手”来调用而不只是嘴上说“建议你跑一下 tsc”。这一步很关键——工具授权的本质是把 Agent 从“只会给建议”变成“能真正动手”。有一点要注意自定义工具的描述信息尽量写清“什么时候用、用了会有什么副作用”。模型本身是靠描述来决定调不调用工具的描述模糊它就基本不用。你写的 description 越具体越口语化工具的被调用率就越高。我刚开始把自定义工具描述写成正式文档风格Agent 几乎从来不碰它;后来改成“改完代码之后用这个检查类型错误失败就修到通过”使用频率立刻上来了。1.3 权限模型别在终端里裸奔工具强大的另一面是权限风险。opencode 默认会在触达敏感操作时进行确认比如跑高风险命令、大范围批量改文件。这个确认机制不是用来烦你的它是防线。我的习惯是日常开发保持默认权限模式让每一步深层操作都有个确认节点;只有在一次性的批量重构场景里才会对整个 session 放开权限并且放开前确保这个 session 不会再接任何未知脚本、不会再打开陌生目录。放权的命令长这样谨慎使用opencode --dangerously-skip-permissions这名字本身就带着警告味跳过权限后Agent 做什么都不会再问你了。它删文件、改~/.ssh、跑rm -rf都只凭模型判断。所以这个选项只建议用在封闭环境、克隆出来的临时目录里跑一次性任务别在你日常办公目录里开着。提示如果你用了企鹅会议里那种团队共享机器千万别把这个选项写进启动脚本里。权限确认慢几秒真出事的时候代价是成倍的。2. 服务面到底是谁的额度、谁的订阅2.1 从 auth login 说起在 opencode 里“服务面”这个概念说白了就是模型提供商的接入层。你用什么模型、走哪个渠道的配额、API Key 放在哪全部由这一层决定。最基础的登录动作是opencode auth login它会列出当前支持的提供商列表选一个后输入或粘贴 API Key。登录完可以用下面这条命令核对当前环境里挂了哪些账号opencode auth list这相当于一个轻量的密钥管理器不用每次都在配置文件里手填 Key。团队协作时新同事拉下仓库只需要opencode auth login选择自己的 Provider 就行配置文件里不需要出现任何私密信息。2.2 那个常见报错是怎么回事社区里问得特别多的一个报错长这样error from provider (console): opencodes free tier can only be used from within opencode很多人在别的地方见到这个提示就一头雾水以为是网络不通或者 Key 没配对。实际含义非常直白opencode 内置了一个免费档额度但这个额度只允许在 opencode 自己的客户端环境里使用。你把它的模型标识拿到自定义脚本、第三方集成工具或者别的前端里去调就会收到这句话。所以见到这个报错优先检查两件事一是确认你没有把它内置模型挂到外部链路上二是如果你真的想走这个免费档就老老实实回到 opencode 环境内用。解决办法不是去绕校验而是选对使用路径。这和市面上常见的“订阅切刀”工具逻辑还不一样。有些工具允许你把配置切到不同模型账户然后统一调起来;opencode 的模型配置则更强调“上下文完整”——它不仅喂模型一段提示词还会带上项目结构、工具权限、代码规则这些元信息。脱离 opencode 环境等于把这些上下文全扔了。2.3 opencode go 和额度的理解方式opencode 官方提供的套餐服务——opencode go 是很多人关注的焦点特别是关心“它的额度是按模型分开计算还是合并计算”的用户。按我实际使用的体感解题思路别套用传统“每种模型各给一个独立池子”的思路它的计费更像一个统一账户余额跑不同模型按各自单价扣减。这意味着你不需要在 Anthropic、OpenAI、Google 三家分别充值,一个订阅就能在不同模型之间来回切换。对重度使用者来说,这解决了“账户爆炸”的问题——不用因为换了个模型就得重新绑卡。如果你平时就是这么折腾多模型的,那建议在 opencode.json 里把 model 字段和 small_model 字段分开:{ model: anthropic/claude-sonnet-4-20250514, small_model: opencode/llama-3.3-70b }model 负责长篇代码改动、复杂架构分析,small_model 负责标题生成、会话摘要、简单分类这些轻活。两边各自做擅长的事,轻活走便宜档,重活走高能力档,花钱的效率就上来了。2.4 供应商配置的迁移体验我从老工具迁移到 opencode 时最担心的就是既有账号能不能继续用。实际上 opencode 允许你在配置里直接声明 provider 的 alias 指向自定义 BaseURL,这个设计对本土服务和自建服务都很友好。配置文件里大致是这样的形状:{ provider: { my_custom_provider: { npm: ai-sdk/custom-provider, name: 自建网关, options: { baseURL: https://your-gateway.example.com/v1 }, models: { some-model: { name: 某个负责推理的模型 } } } } }我之前就是通过这种方式把一个内部网关服务接入进来,从旧工具迁到 opencode 只花了不到十分钟,而且旧工具里写的所有自定义提示词规则,在 opencode 这边用 AGENTS.md 重写一遍之后反而更清晰了。这块实操性强,照着上面形状改 Key、改地址就能跑通,不用在这个上面太久。3. 外壳TUI、AGENTS.md 和命令行模式3.1 真正的外壳体验在终端里如果说服务面是“发动机”,那外壳就是“驾驶舱”。opencode 的默认驾驶舱是一个 TUI,带完整的交互界面:上方是会话内容,下方是输入框,底栏会提示当前会话用的模型。用熟了之后配合自己写的规则文件,整个驾驶舱会越来越人话化。我最认同的是它的主代理机制:你当前正在交互的这个 Agent 是一个主入口,它可以根据任务再把子任务扩散出去。遇到一段代码需要同时对比两种实现方案时,主代理负责整体协调,task 工具把具体调研拆给子代理,子代理的结果再收回来。这时候终端里的体验就很像“你在指挥一个小团队”,而不再是你跟单个模型一问一答。会话管理在我看来是外壳里最重要的能力。隔天继续昨天的思路时,一个是重新打开终端直接回到历史会话,一个是新开会话让它读一遍仓库里的状态记录,两个都试下来,历史会话这个效率明显更高。外壳配置方面,opencode 的主题、模型参数、Agent 定义都集中在 config 文件里。主题我常年用默认,但模型参数值得根据项目调:代码生成类项目把 temperature 调低一点稳定性强,文案生成类可以拉高一些增加变化。配置文件里大概长这样:{ $schema: https://opencode.ai/config.json, theme: opencode, model: anthropic/claude-sonnet-4-20250514, small_model: opencode/llama-3.3-70b, agents: { build: { prompt: 你是一个构建运维代理,负责跑测试、修构建错误、整理日志 } } }3.2 AGENTS.md 是项目级的“规则手册”AGENTS.md 是 opencode 生态里承前启后的一个约定。它解决的核心问题只有一句话:每个项目都有自己的规矩,怎么把这些规矩一次性告诉 Agent?我的做法是在仓库根目录放一个 AGENTS.md,写清哪些目录不能碰、代码风格是什么、提交前必须做什么检查。示例:## 代码风格 - 缩进统一 4 个空格 - 禁止提交 console.log 调试代码 - 组件文件名一律 kebab-case ## 测试 - 每次改动后必须跑 pnpm test - 新增功能必须补测试用例 ## 安全红线 - 不得修改数据库迁移文件 - 不得删除 docs/ 下的历史文档这个文件不写还好,一写你会发现同一个 Agent 的工作质量瞬间提升一个档次。因为它把散落在各处的隐性约束集中到了同一个地方,Agent 每次行动前都会上一层规则判据。opencode 会沿路径向上递归查找 AGENTS.md,也会读取全局配置目录里的规则文件。所以我的个人全局约束放在~/.config/opencode/AGENTS.md,公司项目约束放仓库根目录,个人习惯和团队规范各归各,互不污染。3.3 命令行模式把 Agent 变成可脚本化的进程TUI 适合人坐在终端前慢慢聊,但自动化场景没法每次都手动开界面。opencode 提供的非交互模式opencode run就是为了这个:opencode run 解释 docs/arch.md 里这个架构的核心设计思路 opencode run 为 packages/core/src/index.test.ts 补充两个异常用例 --model anthropic/claude-sonnet-4-20250514 opencode run 跑一遍全部测试把失败信息汇总出来 --format jsonl这个命令在 shell 脚本里可以直接用,输出可以重定向到文件、管道给别的命令继续处理,也可以配定时任务自动执行。我常用的姿势是写一个快速 review 脚本,把 git diff 导出来,交给opencode run分析潜在问题,结果直接落到 review.txt,读完再往里补人工意见。对你来说最大的受益点在于:任何原来耗人工的重复性判断,现在都可以通过opencode run挂进 CI、挂进钩子、挂进调度任务,agent 的思考结果直接变成可消费的数据流。4. 实战集成从个人玩具变成工程基建4.1 把 skill 迁移到 opencode 的 Agent 体系里很多从 meoo 一类工具迁过来的朋友,第一反应是找“技能商店”,找不到就很慌。其实 opencode 里所谓技能,本质上就是一个个轻量 Agent。你把一段经过验证的高频任务提示词做成独立的 Agent 目录,它就变成了可复用的技能。比如你以前有一个“SQL 优化器”技能,那在 opencode 这边的做法就是新增一个名为 sql-optimizer 的 Agent,配一段 prompt:{ agents: { sql-optimizer: { prompt: 你是 SQL 优化专家。收到慢查询后先看执行计划,再给出索引或重写建议,并解释收益 } } }这个 Agent 可以在主会话里被调用,也可以直接单独启动。对比下来,这个模型比一个封闭的“技能包”还要干净,因为规则、工具、行为都能自由组合,迁移成本实际低于想象。4.2 VS Code 集成不吃掉编辑器只做侧翼opencode 对 VS Code 的支持,是很多习惯了图形界面的人关注的接入点。官方把扩展定位成“IDE 里的一个入口”,不是让你抛弃编辑器的窗口布局,而是让你在合适的时候把 Agent 拉出来干活。我在实践中常用的姿势是:代码的跳转、重构、diff 查看继续留在 VS Code 里;遇到“跨文件改动、搜索全局定义、批量重命名”这类杂活,直接把终端拉出来切到 opencode。两者互补,效率反而比老式的一键跳转工具更高。配好之后,VS Code 右下角面板可以固定一个 opencode 入口,文件路径和当前代码上下文能直接传给 Agent,不用手动复制粘贴路径。4.3 把它挂进 CI自动化评审的真实收益把 opencode 接进 CI,是我认为这个工具从“省时”走向“提效”的最大分水岭。我在一个维护了三年的中型仓库里加了一个 review 步骤:每次 PR 触发时,脚本会抓取到这个 PR 的全部 diff,然后执行一条命令:opencode run 请审查这个 diff,重点看类型安全、边界条件、兼容性,输出问题清单 --format jsonl review-result.jsonl这条命令跑完,后方解析 JSONL,把问题清单自动贴到 PR 评论里。刚开始效果不算惊艳,但把 AGENTS.md 里的项目规则喂给它之后,它的意见越来越贴近团队原则,很多时候列出的检查项甚至能补充人类 reviewer 遗漏的边缘情况。这里我劝你一句:自动化评审阶段别一上来就全自动合并。我的做法是“先提示、后人工裁定”,机器意见只做辅助提醒,Panel 上仍然由人拍板。逐步信任比一步到位稳妥得多。4.4 与周边工具协同别局限于一个客户端最后的集成点是生态协同。opencode 支持通过配置切换不同模型服务商,所以在目录和配置层面,它天然能和市面上常见的模型配置管理工具共存——你可以把“哪个项目用哪个 provider”的决策交回配置文件控制,而不必每换一次模型就去改全局环境变量。同时,本地已有的 CLI 工具都能通过 bash 工具被 Agent 调用。我在项目里让 Agent 直接驱动git、docker、kubectl、curl这些命令,它和周边生态不是替代关系,而是指挥关系。把这层打通之后,opencode 不再只是一个“聊代码的 AI”,而是你本机开发指令的集散中心。有一个集成陷阱我要特别提醒:在一个仓库里同时挂多个 Agent 和多个配置文件时,很容易出现规则互相打架的情况。我的解决方法是按目录隔离——每个子项目一个独立配置,全局只保留最基础的默认设置。这样 Agent 在哪个目录启动就自动加载哪个目录的规则,不会发生“A 项目的规范被 B 项目的 Agent 错误应用”的混乱。这几层配置捋下来你会发现,工具、服务面、外壳、集成本质上不是四个独立零件,它们共享同一套配置文件,互相咬合。工具决定 Agent 能做什么,服务面决定它用什么成本做,外壳决定你怎么指挥它,集成决定它长在哪条生产链路上。我实际用下来的体会是:花一个下午把这几块认真整理好,后面能省下无数个分散抱怨“大模型又不听指挥”的下午。很多看起来很智能的 AI 编程表现,其实是背后配置和规则认真铺出来的。