如果你已经看过 Claude Code、Codex 这类 AI Coding Harness再打开 OpenCode很容易产生一种错觉不就是又一个可以在终端里调用大模型、读写代码、执行 Bash、接 MCP 的 Coding Agent 吗但如果从 Harness 的工程视角去看OpenCode 有一个非常鲜明的特点它把大量扩展能力直接暴露成了目录、Markdown、JSON 配置以及 TypeScript / JavaScript 扩展接口。也就是说OpenCode 不只是给你一个 Agent。它实际上提供了一整套可以被用户重新组合的 Harness 扩展面AGENTS.md ↓ Instructions commands/ ↓ User Workflow skills/ ↓ Agent Workflow agents/ ↓ Agent Definition tools/ ↓ Executable Capability MCP ↓ External Capability plugins/ ↓ Runtime Extension permission ↓ Runtime PolicyOpenCode 官方仓库将其定位为开源 Coding Agent同时强调 Provider Agnostic、LSP以及 Client/Server Architecture 等特点。但这一篇我们暂时不讨论它的 Agent Loop也不讨论 Plugin Hook 是怎么真正介入 Tool Execution 的。我们先完成一件更基础的事建立 OpenCode Harness 的静态架构地图。也就是回答OpenCode 的配置在哪里 项目规则在哪里 Agent 在哪里定义 Skill 放在哪里 Command 和 Skill 有什么区别 Tool 怎么扩展 Plugin 又是什么 MCP 从哪里进入 Runtime Permission 位于什么位置只有先把这些入口摆正后面才能继续讨论Discovery ↓ Loading ↓ Registration ↓ Routing ↓ Execution ↓ Permission ↓ Runtime一、先不要把 OpenCode 当成一个 CLI从表面看OpenCode 是一个 Coding Agent。但如果把 UI、模型供应商这些东西暂时拿掉只看它暴露出来的扩展结构会得到一个更接近 Harness 的模型OpenCode │ ┌──────────────────┼──────────────────┐ │ │ │ ↓ ↓ ↓ Instruction Agent Definition Capability │ │ │ AGENTS.md agents/ ┌─────┼─────┐ instructions ↓ ↓ ↓ Skill Tool MCP │ ↓ Runtime │ ┌────────────┼────────────┐ ↓ ↓ ↓ Permission Plugin Session │ │ └──────→ Execution这里的名字并不是说 OpenCode 源码内部一定存在InstructionRegistry CapabilityRegistry PolicyEngine PluginRuntime这些组件。它们只是为了理解架构而做的工程抽象。这一点非常重要。因为整个 Harness Marketplace 系列一直遵循同一个原则官方文档明确存在 ↓ 可以写成事实 根据行为抽象出来 ↓ 必须说明是工程抽象 内部源码没有公开确认 ↓ 不能假装知道真实类名我们此前已经将这种区分作为整个 Harness Marketplace 系列的重要写作原则。那么OpenCode 官方真正暴露出来的静态扩展入口是什么可以先记住下面几个关键词opencode.json AGENTS.md .opencode/ ├── agents/ ├── commands/ ├── skills/ ├── tools/ └── plugins/ MCP permission后面的 OpenCode 系列基本都会围绕它们展开。二、OpenCode 的第一层配置系统OpenCode 最核心的配置入口之一是opencode.json官方文档同时大量使用opencode.jsonc作为带注释的配置示例。配置中可以出现model provider agent permission mcp plugin instructions watcher share ...例如 Agent 可以直接定义在{$schema:https://opencode.ai/config.json,agent:{code-reviewer:{description:Reviews code for best practices,model:anthropic/claude-sonnet-4-5}}}而 MCP、Plugin 等能力也都可以进入同一个配置体系。所以从架构上可以先把opencode.json理解成OpenCode Runtime Configuration它不是 Prompt 文件也不是 Skill。它更接近 Harness 的总控配置。2.1 配置与能力定义不是一回事这是第一个很容易混淆的地方。比如opencode.json里面可以配置agent mcp plugin permission但这并不意味着Agent Config Plugin Config MCP Config更准确的理解应该是opencode.json │ ┌──────────┼──────────┐ ↓ ↓ ↓ Runtime Agent Plugin Config Config References │ │ │ └──────────┼──────────┘ ↓ OpenCode也就是说opencode.json是多个 Runtime 子系统的配置入口而不是这些能力本身。这和 Codex 的config.toml有些类似。只是 OpenCode 的大量扩展能力比 Codex 更直接地暴露给开发者。三、第二层AGENTS.md——长期 Instruction如果说opencode.json管的是Harness 怎么运行那么AGENTS.md主要解决的是Agent 应该遵守什么项目规则OpenCode 官方明确支持项目级project/ └── AGENTS.md以及全局~/.config/opencode/ └── AGENTS.md项目级AGENTS.md用于项目规则全局文件则适用于所有 OpenCode Session。典型内容可能包括# Project Rules ## Architecture - API code lives in packages/api - Shared models live in packages/core ## Development - Use Bun - Run lint before tests ## Code Style - TypeScript strict mode - Avoid default exports这些东西有一个共同特点它们不是一次性任务而是项目长期有效的约束。所以从 Harness 角度AGENTS.md ↓ Always-on Instruction3.1 OpenCode 还兼容 CLAUDE.md这是一个很有意思的设计。OpenCode 官方提供 Claude Code 文件约定的兼容逻辑。例如项目目录中如果没有AGENTS.md可以回退使用CLAUDE.md全局规则也支持~/.claude/CLAUDE.md作为兼容来源。因此可以抽象为Current Project │ ↓ search AGENTS.md │ ├── found │ ↓ │ use it │ └── not found ↓ CLAUDE.md这其实已经暴露出 OpenCode 一个很重要的生态策略它并不试图把所有能力都锁死在 OpenCode 自己的文件格式里。这种兼容性后面在 Skill 上会更加明显。3.2 instructions 又是什么除了AGENTS.mdOpenCode 还允许在opencode.json中配置{instructions:[CONTRIBUTING.md,docs/guidelines.md,.cursor/rules/*.md]}甚至可以使用远程 URL 作为 Instruction 来源。官方说明这些自定义 Instruction 会和AGENTS.md一起组合进入上下文。于是 OpenCode 的 Instruction Layer 实际上不是只有AGENTS.md而更接近Instruction Layer │ ┌─────────────┼─────────────┐ ↓ ↓ ↓ AGENTS.md CLAUDE.md instructions[] │ fallback │ └─────────────┼─────────────┘ ↓ Agent Context这里和 Codex 的AGENTS.md会有一个很好的对照点。后面可以单独用一篇文章研究OpenCode 如何发现 Rule 如何处理 fallback 如何向上搜索 如何加载 custom instructions 最终怎么进入 Context四、第三层.opencode/才是扩展能力真正集中的地方如果只是看到opencode.json AGENTS.md还不足以体现 OpenCode 的特色。真正重要的是.opencode/这个目录。把 OpenCode 当前公开的几种主要扩展能力组合起来可以得到一棵很典型的项目结构project/ │ ├── AGENTS.md ├── opencode.json │ └── .opencode/ │ ├── agents/ │ └── reviewer.md │ ├── commands/ │ └── test.md │ ├── skills/ │ └── git-release/ │ └── SKILL.md │ ├── tools/ │ └── project.ts │ └── plugins/ └── security.ts注意这棵树是为了把官方文档中的几个扩展入口放在一起展示的工程化汇总结构不是说 OpenCode 官方要求项目必须拥有完整的这些目录。但从 Harness 视角看这棵树非常重要。因为几乎每个目录对应一种不同的 Capability 类型路径大致职责agents/Agent Definitioncommands/User-triggered Workflowskills/Agent-triggered Reusable Instructiontools/Executable Capabilityplugins/Runtime Extension于是.opencode/其实已经非常接近Project-level Harness Extension Space五、第四层Command——用户主动触发的 WorkflowOpenCode 一个很有特色的能力是Command比如.opencode/ └── commands/ └── test.md内容可以写成--- description: Run tests with coverage agent: build model: anthropic/claude-3-5-sonnet-20241022 --- Run the full test suite with coverage report. Focus on failing tests and suggest fixes.然后用户在 TUI 中输入/test即可触发。OpenCode 官方将 Custom Command 定义为可重复任务的自定义命令它本质上包装了一个 Prompt Template并且可以指定 Agent、Model、Subtask 等选项。所以从架构角度看User ↓ /test ↓ Command ↓ Prompt Template ↓ Agent ↓ Execution这和 Skill 有明显区别。5.1 Command 可以先理解为 User-facing Workflow我们暂时可以这样抽象Command ↓ User-facing Workflow Entry为什么因为它最典型的调用方式是/test /review /release也就是用户明确告诉 Harness“我要运行这个预定义流程。”因此User ↓ Explicit Routing ↓ Command这一点后面与 Skill 对比时会非常关键。六、第五层Skill——Agent 按需加载的 WorkflowOpenCode 当前已经有第一方 Agent Skills 支持。Skill 的目录形式非常熟悉.opencode/ └── skills/ └── git-release/ └── SKILL.md同时 OpenCode 还会搜索~/.config/opencode/skills/ .claude/skills/ ~/.claude/skills/ .agents/skills/ ~/.agents/skills/这些目录。这里已经能看到一个很明显的设计思想OpenCode native Claude compatible Agent compatible6.1 Skill 不是 Always-on InstructionSkill 与AGENTS.md最大区别是AGENTS.md ↓ Always-on Skill ↓ On-demandOpenCode 官方明确说明Agent 会看到可用 Skill 的名称与描述但完整内容通过原生skillTool 在需要时加载。可以把这个过程抽象成Discover Skills ↓ Expose Metadata ↓ Agent sees: name description ↓ LLM decides ↓ skill({ name: git-release }) ↓ Load SKILL.md ↓ Inject Workflow这就是我们在 Codex 系列里一直强调的Progressive Disclosure6.2 Command 与 Skill第一次可以摆在一起了到这里我们已经有AGENTS.md Command Skill三个非常容易混淆的东西。可以先这样区分AGENTS.md ↓ 长期规则 Command ↓ 用户显式调用流程 Skill ↓ Agent 按需加载流程进一步抽象Workflow / Instruction │ ┌──────────────┼──────────────┐ ↓ ↓ ↓ AGENTS.md Command Skill │ │ │ Always-on User Routing Agent Routing这将是 OpenCode 系列第二、第三篇非常重要的主题。七、第六层Agent——执行者本身也可以被配置接下来是 Agent。OpenCode 默认包含诸如build plan这类内置 Agent同时允许创建自己的 Agent。官方仓库对build和plan的默认角色有所说明例如build面向开发工作而plan偏只读分析。自定义 Agent 可以直接写在opencode.json里。也可以使用 Markdown.opencode/agents/ ~/.config/opencode/agents/官方文档同时支持primary subagent这样的 Agent 模式。例如--- description: Reviews code for quality mode: subagent permission: edit: deny bash: ask --- Review the implementation for security, maintainability and performance.从这里已经能看出Agent并不仅仅是一段 System Prompt。它至少可以绑定Agent ├── description ├── mode ├── model ├── prompt ├── tools └── permission因此用我们的统一 Harness 抽象Agent Role Instructions Model Tool Surface Permission会比简单理解为Agent Prompt准确得多。八、第七层Tool——真正执行动作的 CapabilityAgent 有了 Workflow还需要真正操作环境。这就是ToolOpenCode 内置多个 Tool例如bash edit write read grep glob ...官方将 Tool 定义为 LLM 可以用来对代码库执行动作的能力同时支持Built-in Tool Custom Tool MCP Tool三类扩展来源。所以 Tool Layer 可以先画成Tool Surface │ ┌─────────────┼─────────────┐ ↓ ↓ ↓ Built-in Tool Custom Tool MCP │ │ │ bash project.ts external read database.ts server edit grep这已经非常像一个Capability Registry但再次强调“Capability Registry”是我们的架构抽象不代表 OpenCode 内部一定存在这个名字的类。九、Custom ToolOpenCode 最工程化的扩展入口之一OpenCode 的 Custom Tool 很值得关注。它可以直接定义在.opencode/tools/或者~/.config/opencode/tools/中。例如import{tool}fromopencode-ai/pluginexportdefaulttool({description:Get project information,args:{},asyncexecute(args,context){returnProject:${context.worktree}}})OpenCode 会向 Tool 提供 Session 上下文包括agent sessionID messageID directory worktree等信息。于是Custom Tool File ↓ tool(...) ↓ Description Arguments Schema Execute Function ↓ OpenCode Tool Surface ↓ LLM Tool Call这对理解 OpenCode 非常重要。因为这意味着OpenCode 不只是允许“接外部 MCP”它还允许开发者直接向 Harness 内部注册可执行能力。从我们自己的统一模型看Custom Tool ↓ In-process Capability而MCP ↓ External Capability Provider二者职责不同。十、第八层MCP——外部能力提供者OpenCode 同样支持 MCP。在opencode.json里可以存在{$schema:https://opencode.ai/config.json,mcp:{}}官方文档明确将 MCP Server 与 Custom Tools 一起列为扩展 Tool Surface 的方式用于数据库、API 和第三方服务等外部集成。所以MCP Server ↓ External Tools ↓ OpenCode ↓ Tool Surface ↓ Agent这和 Custom Tool 是两条不同的路径Custom Tool ↓ Local / In-process Extension MCP ↓ External Capability Provider如果按照整个 Harness Marketplace 系列的统一语义Skill → How Tool → What MCP → External Tool Provider这三个概念就开始逐渐分开了。十一、第九层Plugin——这可能才是 OpenCode 真正特殊的地方如果到 Custom Tool 为止OpenCode 还只是一个“支持代码扩展的 Coding Agent”。那么Plugin让它开始更像一个真正的Programmable Agent RuntimeOpenCode Plugin 支持两种主要加载形式。第一种.opencode/plugins/ ~/.config/opencode/plugins/直接放JavaScript TypeScript文件。第二种是在opencode.json中配置 npm 包{plugin:[opencode-wakatime,my-org/custom-plugin]}官方说明 npm Plugin 会在启动时通过 Bun 自动安装其包及依赖会被缓存在~/.cache/opencode/node_modules/中。因此可以先画一条npm Registry ↓ Plugin Package ↓ Bun Install ↓ Local Cache ↓ OpenCode Startup ↓ Plugin Load这已经出现了非常明显的Distribution Installation Runtime Loading三个阶段。11.1 但 Plugin 不只是一个 Package这也是 OpenCode 和我们前面分析其他 Harness 时最需要小心的地方。OpenCode Plugin 可以注册 Runtime Hook。例如官方展示了tool.execute.before这样的 Hook可以在 Tool 执行前读取甚至修改输入。Plugin 还可以提供shell.env tool.execute.before tool.execute.after Custom Tool ...等扩展行为。因此如果我们继续简单说Plugin Distribution Package就不够准确了。对于 OpenCode更合理的工程抽象是OpenCode Plugin │ ├── Runtime Hook │ ├── Custom Tool │ ├── Integration │ └── Programmatic Extension所以OpenCode Plugin 更接近 Runtime Extension Module而不仅仅是 Capability Distribution Package。这会是后续 OpenCode Plugin 专篇里最值得展开的问题。十二、到这里OpenCode 已经形成了四种完全不同的“扩展”现在可以做一次非常关键的整理。OpenCode 至少存在四类开发者很容易混淆的扩展Command Skill Tool Plugin但它们根本不是同一个层面的东西。可以先这样理解类型核心职责Command用户触发 WorkflowSkillAgent 按需加载 WorkflowTool执行动作Plugin扩展 Runtime换成一句更简洁的话Command → Entry Skill → Method Tool → Action Plugin → Extension进一步画出来User ↓ Command ↓ Agent │ ├──────────────→ Skill │ ↓ │ Workflow │ └──────────────→ Tool ↓ Action Plugin │ └────────────→ Runtime这可能是理解 OpenCode 最重要的一张静态图。十三、第十层Permission——能力存在不代表允许执行OpenCode 还有一个很重要的层permission当前官方 Permission 系统核心有三种结果allow ask deny例如{$schema:https://opencode.ai/config.json,permission:{edit:deny,bash:ask,webfetch:allow}}官方当前文档还支持细粒度 Pattern例如对特定 Bash 命令、MCP Tool 等配置不同规则。需要注意的是OpenCode 当前文档已经说明从v1.1.1起旧版tools布尔控制被弃用并整合进permission但旧配置仍保留兼容。这意味着研究 OpenCode 配置时不能把不同时期的文档混为一谈。13.1 Permission 的意义不是“有没有 Tool”这是一个很重要的 Harness 设计原则。假设 Runtime 中已经存在bash git database_query skill mymcp_search这只说明Capability Exists却并不说明Current Agent Can Use It真正的运行关系应该更接近Capability ↓ Discovered ↓ Available ↓ Permission Resolution ↓ allow / ask / deny ↓ Execution因此Capability Definition ≠ Permission Grant这一原则在 OpenCode 中表现得非常明显。甚至 Skill 本身也有独立 Permission。例如官方支持{permission:{skill:{*:allow,internal-*:deny,experimental-*:ask}}}被deny的 Skill 会对 Agent 隐藏并拒绝访问。于是Skill Installed ↓ Skill Discovered ↓ Permission ↓ Agent Visible? ↓ Load?这已经非常接近一个真正的 Capability Policy 系统。十四、OpenCode 的 User Scope 与 Project Scope现在再回头看目录就会发现 OpenCode 很多扩展都同时存在两种 ScopeGlobal Project比如 Agent~/.config/opencode/agents/ .opencode/agents/Custom Tool~/.config/opencode/tools/ .opencode/tools/Plugin~/.config/opencode/plugins/ .opencode/plugins/Skill~/.config/opencode/skills/ .opencode/skills/Instruction~/.config/opencode/AGENTS.md project/AGENTS.md官方文档对这些 User / Project 路径都有明确说明。所以可以画出Scope │ ┌──────────┴──────────┐ ↓ ↓ User Project │ │ ~/.config/opencode/ project/ │ │ ┌───────┼───────┐ ┌─────┼─────┐ ↓ ↓ ↓ ↓ ↓ ↓ Agent Skill Plugin Agent Skill Plugin │ │ │ Tool Rules Config这说明 OpenCode 已经不是只有“配置一个模型然后聊天”这么简单。它实际上开始出现Scope Resolution Capability Resolution Permission Resolution这样的 Harness 问题。后面的文章必须专门研究这些冲突和覆盖关系。十五、OpenCode 还体现出一个很强的兼容层思路OpenCode 静态目录里还有一个很有意思的现象它没有完全把扩展生态封闭在.opencode/中。例如 Skill 可以来自.opencode/skills/ .claude/skills/ .agents/skills/Instruction 也可以兼容CLAUDE.md官方还提供环境变量用于关闭 Claude Code Prompt 或 Skill 兼容。于是 OpenCode 的能力发现很可能越来越接近Native Convention Compatibility Convention ↓ Unified Runtime Capability从 Harness 生态角度看这非常值得关注。因为未来 Agent Harness 之间很可能不会只有产品 A 的 Skill 产品 B 的 Skill 产品 C 的 Skill而是逐渐形成Common Skill Convention Common Instruction Convention Common MCP Protocol ↓ Different Harness RuntimeOpenCode 对.claude/skills和.agents/skills的支持就是这种趋势的一个明显信号。十六、把所有东西放在一起OpenCode 的静态 Harness 地图现在终于可以把第一篇最重要的图画出来。User │ ┌───────────┴───────────┐ ↓ ↓ Natural Prompt /Command │ │ │ commands/ │ │ └───────────┬───────────┘ ↓ Agent │ agents/ / config │ ┌───────────────┼────────────────┐ │ │ │ ↓ ↓ ↓ Instructions Skill Tool │ │ │ AGENTS.md SKILL.md ┌──────┼──────┐ instructions[] │ ↓ ↓ ↓ │ │ built-in custom MCP └──────────┬─────┘ │ │ │ │ └──────┼──────┘ ↓ ↓ Context Tool Surface │ │ └─────────┬───────────┘ ↓ Permission │ allow / ask / deny │ ↓ Tool Execution │ ↓ Observation │ ↓ Agent Loop plugins/ │ ┌──────────┼──────────┐ ↓ ↓ ↓ Hooks Tools Integration │ │ │ └──────────┴──────────┘ ↓ Runtime这不是 OpenCode 官方发布的架构图。这是根据其公开目录、配置和扩展接口形成的工程抽象。但它已经能帮我们回答一个关键问题OpenCode 到底是一个什么样的 Harness十七、OpenCode 的扩展体系可以分成五个 Plane如果进一步抽象我认为 OpenCode 可以先拆成五层。1. Instruction PlaneAGENTS.md CLAUDE.md instructions[]回答Agent 应该知道什么、遵守什么。2. Workflow PlaneCommand Skill回答一项任务应该按照什么流程完成。其中Command → User-triggered Skill → Agent-triggered3. Execution PlaneBuilt-in Tool Custom Tool MCP回答Agent 真正能做什么。4. Runtime Extension PlanePlugin Hook Integration回答Harness 自己的行为怎么被扩展。5. Policy Planepermission Agent Permission Skill Permission Tool Pattern回答已经存在的能力当前是否允许执行。最终形成Instruction ↓ Workflow ↓ Agent ↓ Capability ↓ Policy ↓ Runtime这实际上已经是一套相当完整的 Harness 模型。十八、OpenCode 与 Codex 第一眼最大的不同是什么这一篇暂时不做完整横向对比。但为了给 OpenCode 定位可以先指出一个非常明显的结构差异。我们此前对 Codex 形成的静态理解大致是AGENTS.md ↓ Guidance Skill ↓ Workflow Agent ↓ Executor MCP ↓ External Capability Hook ↓ Lifecycle Policy / Sandbox ↓ Enforcement而 OpenCode 现在多了几个非常显式的编程入口Command Custom Tool TypeScript Plugin于是它的扩展面更像Markdown Extension JSON Configuration Executable Tool Programmatic Plugin也就是说OpenCode 不只是允许用户“配置 Harness”它还明显允许开发者“编程扩展 Harness”。所以现阶段我更愿意把 OpenCode 工程化地描述为Programmable Extensible Agent Runtime注意这不是 OpenCode 官方产品定义。而是为了后续比较不同 Harness 的工程抽象。十九、这套结构对自研 Harness 有什么启发如果把 OpenCode 的这些能力映射到一个自研 Harness可以得到AGENTS.md / instructions ↓ InstructionRegistry commands/ ↓ CommandRegistry skills/ ↓ SkillRegistry agents/ ↓ AgentRegistry tools/ ↓ ToolRegistry MCP ↓ ExternalCapabilityRegistry plugins/ ↓ PluginRuntime permission ↓ PolicyEngine再次强调这些Registry、Engine名字是我们为了架构理解建立的抽象并不代表 OpenCode 源码真实类型。进一步统一可以得到CapabilityDescriptor │ ┌──────────────────┼──────────────────┐ ↓ ↓ ↓ Skill Tool Agent │ ┌─────┴─────┐ ↓ ↓ Local Tool MCP但 OpenCode 又提醒我们Plugin可能不应该简单塞进CapabilityDescriptor因为 Plugin 自身可能介入Runtime Lifecycle Tool Execution Environment Integration因此自研 Harness 最好区分Capability Extension ↓ Skill / Tool / Agent Runtime Extension ↓ Plugin / Hook这是一个很重要的设计边界。二十、第一篇真正应该记住的不是目录而是职责最后再把 OpenCode 当前的静态结构压缩一次。opencode.json ↓ Runtime Configuration AGENTS.md ↓ Always-on Instructions commands/ ↓ User-triggered Workflow skills/ ↓ Agent-triggered Workflow agents/ ↓ Specialized Executor tools/ ↓ In-process Capability MCP ↓ External Capability Provider plugins/ ↓ Runtime Extension permission ↓ Capability Authorization如果再进一步压缩Instructions ↓ Workflow ↓ Agent ↓ Tool ↓ Permission ↓ Execution Plugin ↓ intercepts / extends Runtime这就是 OpenCode 第一张真正意义上的Harness 静态地图二十一、接下来真正值得拆的是Instruction 怎么进入 Context到这里我们仍然只知道文件在哪里 配置在哪里 能力在哪里但还有更重要的问题没有回答。例如当前目录有 AGENTS.md 父目录也有 AGENTS.md 全局还有 AGENTS.md 又配置了 instructions[] 同时还存在 CLAUDE.md那么 OpenCode 到底会覆盖 合并 向上搜索 取第一个 全部注入 按照什么优先级官方已经明确公开了 Rule 搜索、Fallback 以及 Custom Instructions 的部分规则。因此下一篇就应该继续进入《Harness Marketplace 剖析系列 - 之 OpenCodeAGENTS.md、Instructions 与 Context 是如何形成的》重点研究Project AGENTS.md ↓ Global AGENTS.md ↓ CLAUDE.md Compatibility ↓ instructions[] ↓ Rule Discovery ↓ Precedence ↓ Context Injection到那时我们才开始真正从Static Structure进入Runtime Resolution而再往后才会进入 OpenCode 更有意思的核心Command vs Skill Skill vs Tool Custom Tool vs MCP Plugin vs Capability Permission vs Runtime Plugin Hook vs Security Boundary这也是 OpenCode 作为一个开放 Harness真正值得深入研究的地方。
Harness Marketplace 剖析系列 - 之 OpenCode：从 `.opencode` 到 `opencode.json`，先看懂它的扩展体系
如果你已经看过 Claude Code、Codex 这类 AI Coding Harness再打开 OpenCode很容易产生一种错觉不就是又一个可以在终端里调用大模型、读写代码、执行 Bash、接 MCP 的 Coding Agent 吗但如果从 Harness 的工程视角去看OpenCode 有一个非常鲜明的特点它把大量扩展能力直接暴露成了目录、Markdown、JSON 配置以及 TypeScript / JavaScript 扩展接口。也就是说OpenCode 不只是给你一个 Agent。它实际上提供了一整套可以被用户重新组合的 Harness 扩展面AGENTS.md ↓ Instructions commands/ ↓ User Workflow skills/ ↓ Agent Workflow agents/ ↓ Agent Definition tools/ ↓ Executable Capability MCP ↓ External Capability plugins/ ↓ Runtime Extension permission ↓ Runtime PolicyOpenCode 官方仓库将其定位为开源 Coding Agent同时强调 Provider Agnostic、LSP以及 Client/Server Architecture 等特点。但这一篇我们暂时不讨论它的 Agent Loop也不讨论 Plugin Hook 是怎么真正介入 Tool Execution 的。我们先完成一件更基础的事建立 OpenCode Harness 的静态架构地图。也就是回答OpenCode 的配置在哪里 项目规则在哪里 Agent 在哪里定义 Skill 放在哪里 Command 和 Skill 有什么区别 Tool 怎么扩展 Plugin 又是什么 MCP 从哪里进入 Runtime Permission 位于什么位置只有先把这些入口摆正后面才能继续讨论Discovery ↓ Loading ↓ Registration ↓ Routing ↓ Execution ↓ Permission ↓ Runtime一、先不要把 OpenCode 当成一个 CLI从表面看OpenCode 是一个 Coding Agent。但如果把 UI、模型供应商这些东西暂时拿掉只看它暴露出来的扩展结构会得到一个更接近 Harness 的模型OpenCode │ ┌──────────────────┼──────────────────┐ │ │ │ ↓ ↓ ↓ Instruction Agent Definition Capability │ │ │ AGENTS.md agents/ ┌─────┼─────┐ instructions ↓ ↓ ↓ Skill Tool MCP │ ↓ Runtime │ ┌────────────┼────────────┐ ↓ ↓ ↓ Permission Plugin Session │ │ └──────→ Execution这里的名字并不是说 OpenCode 源码内部一定存在InstructionRegistry CapabilityRegistry PolicyEngine PluginRuntime这些组件。它们只是为了理解架构而做的工程抽象。这一点非常重要。因为整个 Harness Marketplace 系列一直遵循同一个原则官方文档明确存在 ↓ 可以写成事实 根据行为抽象出来 ↓ 必须说明是工程抽象 内部源码没有公开确认 ↓ 不能假装知道真实类名我们此前已经将这种区分作为整个 Harness Marketplace 系列的重要写作原则。那么OpenCode 官方真正暴露出来的静态扩展入口是什么可以先记住下面几个关键词opencode.json AGENTS.md .opencode/ ├── agents/ ├── commands/ ├── skills/ ├── tools/ └── plugins/ MCP permission后面的 OpenCode 系列基本都会围绕它们展开。二、OpenCode 的第一层配置系统OpenCode 最核心的配置入口之一是opencode.json官方文档同时大量使用opencode.jsonc作为带注释的配置示例。配置中可以出现model provider agent permission mcp plugin instructions watcher share ...例如 Agent 可以直接定义在{$schema:https://opencode.ai/config.json,agent:{code-reviewer:{description:Reviews code for best practices,model:anthropic/claude-sonnet-4-5}}}而 MCP、Plugin 等能力也都可以进入同一个配置体系。所以从架构上可以先把opencode.json理解成OpenCode Runtime Configuration它不是 Prompt 文件也不是 Skill。它更接近 Harness 的总控配置。2.1 配置与能力定义不是一回事这是第一个很容易混淆的地方。比如opencode.json里面可以配置agent mcp plugin permission但这并不意味着Agent Config Plugin Config MCP Config更准确的理解应该是opencode.json │ ┌──────────┼──────────┐ ↓ ↓ ↓ Runtime Agent Plugin Config Config References │ │ │ └──────────┼──────────┘ ↓ OpenCode也就是说opencode.json是多个 Runtime 子系统的配置入口而不是这些能力本身。这和 Codex 的config.toml有些类似。只是 OpenCode 的大量扩展能力比 Codex 更直接地暴露给开发者。三、第二层AGENTS.md——长期 Instruction如果说opencode.json管的是Harness 怎么运行那么AGENTS.md主要解决的是Agent 应该遵守什么项目规则OpenCode 官方明确支持项目级project/ └── AGENTS.md以及全局~/.config/opencode/ └── AGENTS.md项目级AGENTS.md用于项目规则全局文件则适用于所有 OpenCode Session。典型内容可能包括# Project Rules ## Architecture - API code lives in packages/api - Shared models live in packages/core ## Development - Use Bun - Run lint before tests ## Code Style - TypeScript strict mode - Avoid default exports这些东西有一个共同特点它们不是一次性任务而是项目长期有效的约束。所以从 Harness 角度AGENTS.md ↓ Always-on Instruction3.1 OpenCode 还兼容 CLAUDE.md这是一个很有意思的设计。OpenCode 官方提供 Claude Code 文件约定的兼容逻辑。例如项目目录中如果没有AGENTS.md可以回退使用CLAUDE.md全局规则也支持~/.claude/CLAUDE.md作为兼容来源。因此可以抽象为Current Project │ ↓ search AGENTS.md │ ├── found │ ↓ │ use it │ └── not found ↓ CLAUDE.md这其实已经暴露出 OpenCode 一个很重要的生态策略它并不试图把所有能力都锁死在 OpenCode 自己的文件格式里。这种兼容性后面在 Skill 上会更加明显。3.2 instructions 又是什么除了AGENTS.mdOpenCode 还允许在opencode.json中配置{instructions:[CONTRIBUTING.md,docs/guidelines.md,.cursor/rules/*.md]}甚至可以使用远程 URL 作为 Instruction 来源。官方说明这些自定义 Instruction 会和AGENTS.md一起组合进入上下文。于是 OpenCode 的 Instruction Layer 实际上不是只有AGENTS.md而更接近Instruction Layer │ ┌─────────────┼─────────────┐ ↓ ↓ ↓ AGENTS.md CLAUDE.md instructions[] │ fallback │ └─────────────┼─────────────┘ ↓ Agent Context这里和 Codex 的AGENTS.md会有一个很好的对照点。后面可以单独用一篇文章研究OpenCode 如何发现 Rule 如何处理 fallback 如何向上搜索 如何加载 custom instructions 最终怎么进入 Context四、第三层.opencode/才是扩展能力真正集中的地方如果只是看到opencode.json AGENTS.md还不足以体现 OpenCode 的特色。真正重要的是.opencode/这个目录。把 OpenCode 当前公开的几种主要扩展能力组合起来可以得到一棵很典型的项目结构project/ │ ├── AGENTS.md ├── opencode.json │ └── .opencode/ │ ├── agents/ │ └── reviewer.md │ ├── commands/ │ └── test.md │ ├── skills/ │ └── git-release/ │ └── SKILL.md │ ├── tools/ │ └── project.ts │ └── plugins/ └── security.ts注意这棵树是为了把官方文档中的几个扩展入口放在一起展示的工程化汇总结构不是说 OpenCode 官方要求项目必须拥有完整的这些目录。但从 Harness 视角看这棵树非常重要。因为几乎每个目录对应一种不同的 Capability 类型路径大致职责agents/Agent Definitioncommands/User-triggered Workflowskills/Agent-triggered Reusable Instructiontools/Executable Capabilityplugins/Runtime Extension于是.opencode/其实已经非常接近Project-level Harness Extension Space五、第四层Command——用户主动触发的 WorkflowOpenCode 一个很有特色的能力是Command比如.opencode/ └── commands/ └── test.md内容可以写成--- description: Run tests with coverage agent: build model: anthropic/claude-3-5-sonnet-20241022 --- Run the full test suite with coverage report. Focus on failing tests and suggest fixes.然后用户在 TUI 中输入/test即可触发。OpenCode 官方将 Custom Command 定义为可重复任务的自定义命令它本质上包装了一个 Prompt Template并且可以指定 Agent、Model、Subtask 等选项。所以从架构角度看User ↓ /test ↓ Command ↓ Prompt Template ↓ Agent ↓ Execution这和 Skill 有明显区别。5.1 Command 可以先理解为 User-facing Workflow我们暂时可以这样抽象Command ↓ User-facing Workflow Entry为什么因为它最典型的调用方式是/test /review /release也就是用户明确告诉 Harness“我要运行这个预定义流程。”因此User ↓ Explicit Routing ↓ Command这一点后面与 Skill 对比时会非常关键。六、第五层Skill——Agent 按需加载的 WorkflowOpenCode 当前已经有第一方 Agent Skills 支持。Skill 的目录形式非常熟悉.opencode/ └── skills/ └── git-release/ └── SKILL.md同时 OpenCode 还会搜索~/.config/opencode/skills/ .claude/skills/ ~/.claude/skills/ .agents/skills/ ~/.agents/skills/这些目录。这里已经能看到一个很明显的设计思想OpenCode native Claude compatible Agent compatible6.1 Skill 不是 Always-on InstructionSkill 与AGENTS.md最大区别是AGENTS.md ↓ Always-on Skill ↓ On-demandOpenCode 官方明确说明Agent 会看到可用 Skill 的名称与描述但完整内容通过原生skillTool 在需要时加载。可以把这个过程抽象成Discover Skills ↓ Expose Metadata ↓ Agent sees: name description ↓ LLM decides ↓ skill({ name: git-release }) ↓ Load SKILL.md ↓ Inject Workflow这就是我们在 Codex 系列里一直强调的Progressive Disclosure6.2 Command 与 Skill第一次可以摆在一起了到这里我们已经有AGENTS.md Command Skill三个非常容易混淆的东西。可以先这样区分AGENTS.md ↓ 长期规则 Command ↓ 用户显式调用流程 Skill ↓ Agent 按需加载流程进一步抽象Workflow / Instruction │ ┌──────────────┼──────────────┐ ↓ ↓ ↓ AGENTS.md Command Skill │ │ │ Always-on User Routing Agent Routing这将是 OpenCode 系列第二、第三篇非常重要的主题。七、第六层Agent——执行者本身也可以被配置接下来是 Agent。OpenCode 默认包含诸如build plan这类内置 Agent同时允许创建自己的 Agent。官方仓库对build和plan的默认角色有所说明例如build面向开发工作而plan偏只读分析。自定义 Agent 可以直接写在opencode.json里。也可以使用 Markdown.opencode/agents/ ~/.config/opencode/agents/官方文档同时支持primary subagent这样的 Agent 模式。例如--- description: Reviews code for quality mode: subagent permission: edit: deny bash: ask --- Review the implementation for security, maintainability and performance.从这里已经能看出Agent并不仅仅是一段 System Prompt。它至少可以绑定Agent ├── description ├── mode ├── model ├── prompt ├── tools └── permission因此用我们的统一 Harness 抽象Agent Role Instructions Model Tool Surface Permission会比简单理解为Agent Prompt准确得多。八、第七层Tool——真正执行动作的 CapabilityAgent 有了 Workflow还需要真正操作环境。这就是ToolOpenCode 内置多个 Tool例如bash edit write read grep glob ...官方将 Tool 定义为 LLM 可以用来对代码库执行动作的能力同时支持Built-in Tool Custom Tool MCP Tool三类扩展来源。所以 Tool Layer 可以先画成Tool Surface │ ┌─────────────┼─────────────┐ ↓ ↓ ↓ Built-in Tool Custom Tool MCP │ │ │ bash project.ts external read database.ts server edit grep这已经非常像一个Capability Registry但再次强调“Capability Registry”是我们的架构抽象不代表 OpenCode 内部一定存在这个名字的类。九、Custom ToolOpenCode 最工程化的扩展入口之一OpenCode 的 Custom Tool 很值得关注。它可以直接定义在.opencode/tools/或者~/.config/opencode/tools/中。例如import{tool}fromopencode-ai/pluginexportdefaulttool({description:Get project information,args:{},asyncexecute(args,context){returnProject:${context.worktree}}})OpenCode 会向 Tool 提供 Session 上下文包括agent sessionID messageID directory worktree等信息。于是Custom Tool File ↓ tool(...) ↓ Description Arguments Schema Execute Function ↓ OpenCode Tool Surface ↓ LLM Tool Call这对理解 OpenCode 非常重要。因为这意味着OpenCode 不只是允许“接外部 MCP”它还允许开发者直接向 Harness 内部注册可执行能力。从我们自己的统一模型看Custom Tool ↓ In-process Capability而MCP ↓ External Capability Provider二者职责不同。十、第八层MCP——外部能力提供者OpenCode 同样支持 MCP。在opencode.json里可以存在{$schema:https://opencode.ai/config.json,mcp:{}}官方文档明确将 MCP Server 与 Custom Tools 一起列为扩展 Tool Surface 的方式用于数据库、API 和第三方服务等外部集成。所以MCP Server ↓ External Tools ↓ OpenCode ↓ Tool Surface ↓ Agent这和 Custom Tool 是两条不同的路径Custom Tool ↓ Local / In-process Extension MCP ↓ External Capability Provider如果按照整个 Harness Marketplace 系列的统一语义Skill → How Tool → What MCP → External Tool Provider这三个概念就开始逐渐分开了。十一、第九层Plugin——这可能才是 OpenCode 真正特殊的地方如果到 Custom Tool 为止OpenCode 还只是一个“支持代码扩展的 Coding Agent”。那么Plugin让它开始更像一个真正的Programmable Agent RuntimeOpenCode Plugin 支持两种主要加载形式。第一种.opencode/plugins/ ~/.config/opencode/plugins/直接放JavaScript TypeScript文件。第二种是在opencode.json中配置 npm 包{plugin:[opencode-wakatime,my-org/custom-plugin]}官方说明 npm Plugin 会在启动时通过 Bun 自动安装其包及依赖会被缓存在~/.cache/opencode/node_modules/中。因此可以先画一条npm Registry ↓ Plugin Package ↓ Bun Install ↓ Local Cache ↓ OpenCode Startup ↓ Plugin Load这已经出现了非常明显的Distribution Installation Runtime Loading三个阶段。11.1 但 Plugin 不只是一个 Package这也是 OpenCode 和我们前面分析其他 Harness 时最需要小心的地方。OpenCode Plugin 可以注册 Runtime Hook。例如官方展示了tool.execute.before这样的 Hook可以在 Tool 执行前读取甚至修改输入。Plugin 还可以提供shell.env tool.execute.before tool.execute.after Custom Tool ...等扩展行为。因此如果我们继续简单说Plugin Distribution Package就不够准确了。对于 OpenCode更合理的工程抽象是OpenCode Plugin │ ├── Runtime Hook │ ├── Custom Tool │ ├── Integration │ └── Programmatic Extension所以OpenCode Plugin 更接近 Runtime Extension Module而不仅仅是 Capability Distribution Package。这会是后续 OpenCode Plugin 专篇里最值得展开的问题。十二、到这里OpenCode 已经形成了四种完全不同的“扩展”现在可以做一次非常关键的整理。OpenCode 至少存在四类开发者很容易混淆的扩展Command Skill Tool Plugin但它们根本不是同一个层面的东西。可以先这样理解类型核心职责Command用户触发 WorkflowSkillAgent 按需加载 WorkflowTool执行动作Plugin扩展 Runtime换成一句更简洁的话Command → Entry Skill → Method Tool → Action Plugin → Extension进一步画出来User ↓ Command ↓ Agent │ ├──────────────→ Skill │ ↓ │ Workflow │ └──────────────→ Tool ↓ Action Plugin │ └────────────→ Runtime这可能是理解 OpenCode 最重要的一张静态图。十三、第十层Permission——能力存在不代表允许执行OpenCode 还有一个很重要的层permission当前官方 Permission 系统核心有三种结果allow ask deny例如{$schema:https://opencode.ai/config.json,permission:{edit:deny,bash:ask,webfetch:allow}}官方当前文档还支持细粒度 Pattern例如对特定 Bash 命令、MCP Tool 等配置不同规则。需要注意的是OpenCode 当前文档已经说明从v1.1.1起旧版tools布尔控制被弃用并整合进permission但旧配置仍保留兼容。这意味着研究 OpenCode 配置时不能把不同时期的文档混为一谈。13.1 Permission 的意义不是“有没有 Tool”这是一个很重要的 Harness 设计原则。假设 Runtime 中已经存在bash git database_query skill mymcp_search这只说明Capability Exists却并不说明Current Agent Can Use It真正的运行关系应该更接近Capability ↓ Discovered ↓ Available ↓ Permission Resolution ↓ allow / ask / deny ↓ Execution因此Capability Definition ≠ Permission Grant这一原则在 OpenCode 中表现得非常明显。甚至 Skill 本身也有独立 Permission。例如官方支持{permission:{skill:{*:allow,internal-*:deny,experimental-*:ask}}}被deny的 Skill 会对 Agent 隐藏并拒绝访问。于是Skill Installed ↓ Skill Discovered ↓ Permission ↓ Agent Visible? ↓ Load?这已经非常接近一个真正的 Capability Policy 系统。十四、OpenCode 的 User Scope 与 Project Scope现在再回头看目录就会发现 OpenCode 很多扩展都同时存在两种 ScopeGlobal Project比如 Agent~/.config/opencode/agents/ .opencode/agents/Custom Tool~/.config/opencode/tools/ .opencode/tools/Plugin~/.config/opencode/plugins/ .opencode/plugins/Skill~/.config/opencode/skills/ .opencode/skills/Instruction~/.config/opencode/AGENTS.md project/AGENTS.md官方文档对这些 User / Project 路径都有明确说明。所以可以画出Scope │ ┌──────────┴──────────┐ ↓ ↓ User Project │ │ ~/.config/opencode/ project/ │ │ ┌───────┼───────┐ ┌─────┼─────┐ ↓ ↓ ↓ ↓ ↓ ↓ Agent Skill Plugin Agent Skill Plugin │ │ │ Tool Rules Config这说明 OpenCode 已经不是只有“配置一个模型然后聊天”这么简单。它实际上开始出现Scope Resolution Capability Resolution Permission Resolution这样的 Harness 问题。后面的文章必须专门研究这些冲突和覆盖关系。十五、OpenCode 还体现出一个很强的兼容层思路OpenCode 静态目录里还有一个很有意思的现象它没有完全把扩展生态封闭在.opencode/中。例如 Skill 可以来自.opencode/skills/ .claude/skills/ .agents/skills/Instruction 也可以兼容CLAUDE.md官方还提供环境变量用于关闭 Claude Code Prompt 或 Skill 兼容。于是 OpenCode 的能力发现很可能越来越接近Native Convention Compatibility Convention ↓ Unified Runtime Capability从 Harness 生态角度看这非常值得关注。因为未来 Agent Harness 之间很可能不会只有产品 A 的 Skill 产品 B 的 Skill 产品 C 的 Skill而是逐渐形成Common Skill Convention Common Instruction Convention Common MCP Protocol ↓ Different Harness RuntimeOpenCode 对.claude/skills和.agents/skills的支持就是这种趋势的一个明显信号。十六、把所有东西放在一起OpenCode 的静态 Harness 地图现在终于可以把第一篇最重要的图画出来。User │ ┌───────────┴───────────┐ ↓ ↓ Natural Prompt /Command │ │ │ commands/ │ │ └───────────┬───────────┘ ↓ Agent │ agents/ / config │ ┌───────────────┼────────────────┐ │ │ │ ↓ ↓ ↓ Instructions Skill Tool │ │ │ AGENTS.md SKILL.md ┌──────┼──────┐ instructions[] │ ↓ ↓ ↓ │ │ built-in custom MCP └──────────┬─────┘ │ │ │ │ └──────┼──────┘ ↓ ↓ Context Tool Surface │ │ └─────────┬───────────┘ ↓ Permission │ allow / ask / deny │ ↓ Tool Execution │ ↓ Observation │ ↓ Agent Loop plugins/ │ ┌──────────┼──────────┐ ↓ ↓ ↓ Hooks Tools Integration │ │ │ └──────────┴──────────┘ ↓ Runtime这不是 OpenCode 官方发布的架构图。这是根据其公开目录、配置和扩展接口形成的工程抽象。但它已经能帮我们回答一个关键问题OpenCode 到底是一个什么样的 Harness十七、OpenCode 的扩展体系可以分成五个 Plane如果进一步抽象我认为 OpenCode 可以先拆成五层。1. Instruction PlaneAGENTS.md CLAUDE.md instructions[]回答Agent 应该知道什么、遵守什么。2. Workflow PlaneCommand Skill回答一项任务应该按照什么流程完成。其中Command → User-triggered Skill → Agent-triggered3. Execution PlaneBuilt-in Tool Custom Tool MCP回答Agent 真正能做什么。4. Runtime Extension PlanePlugin Hook Integration回答Harness 自己的行为怎么被扩展。5. Policy Planepermission Agent Permission Skill Permission Tool Pattern回答已经存在的能力当前是否允许执行。最终形成Instruction ↓ Workflow ↓ Agent ↓ Capability ↓ Policy ↓ Runtime这实际上已经是一套相当完整的 Harness 模型。十八、OpenCode 与 Codex 第一眼最大的不同是什么这一篇暂时不做完整横向对比。但为了给 OpenCode 定位可以先指出一个非常明显的结构差异。我们此前对 Codex 形成的静态理解大致是AGENTS.md ↓ Guidance Skill ↓ Workflow Agent ↓ Executor MCP ↓ External Capability Hook ↓ Lifecycle Policy / Sandbox ↓ Enforcement而 OpenCode 现在多了几个非常显式的编程入口Command Custom Tool TypeScript Plugin于是它的扩展面更像Markdown Extension JSON Configuration Executable Tool Programmatic Plugin也就是说OpenCode 不只是允许用户“配置 Harness”它还明显允许开发者“编程扩展 Harness”。所以现阶段我更愿意把 OpenCode 工程化地描述为Programmable Extensible Agent Runtime注意这不是 OpenCode 官方产品定义。而是为了后续比较不同 Harness 的工程抽象。十九、这套结构对自研 Harness 有什么启发如果把 OpenCode 的这些能力映射到一个自研 Harness可以得到AGENTS.md / instructions ↓ InstructionRegistry commands/ ↓ CommandRegistry skills/ ↓ SkillRegistry agents/ ↓ AgentRegistry tools/ ↓ ToolRegistry MCP ↓ ExternalCapabilityRegistry plugins/ ↓ PluginRuntime permission ↓ PolicyEngine再次强调这些Registry、Engine名字是我们为了架构理解建立的抽象并不代表 OpenCode 源码真实类型。进一步统一可以得到CapabilityDescriptor │ ┌──────────────────┼──────────────────┐ ↓ ↓ ↓ Skill Tool Agent │ ┌─────┴─────┐ ↓ ↓ Local Tool MCP但 OpenCode 又提醒我们Plugin可能不应该简单塞进CapabilityDescriptor因为 Plugin 自身可能介入Runtime Lifecycle Tool Execution Environment Integration因此自研 Harness 最好区分Capability Extension ↓ Skill / Tool / Agent Runtime Extension ↓ Plugin / Hook这是一个很重要的设计边界。二十、第一篇真正应该记住的不是目录而是职责最后再把 OpenCode 当前的静态结构压缩一次。opencode.json ↓ Runtime Configuration AGENTS.md ↓ Always-on Instructions commands/ ↓ User-triggered Workflow skills/ ↓ Agent-triggered Workflow agents/ ↓ Specialized Executor tools/ ↓ In-process Capability MCP ↓ External Capability Provider plugins/ ↓ Runtime Extension permission ↓ Capability Authorization如果再进一步压缩Instructions ↓ Workflow ↓ Agent ↓ Tool ↓ Permission ↓ Execution Plugin ↓ intercepts / extends Runtime这就是 OpenCode 第一张真正意义上的Harness 静态地图二十一、接下来真正值得拆的是Instruction 怎么进入 Context到这里我们仍然只知道文件在哪里 配置在哪里 能力在哪里但还有更重要的问题没有回答。例如当前目录有 AGENTS.md 父目录也有 AGENTS.md 全局还有 AGENTS.md 又配置了 instructions[] 同时还存在 CLAUDE.md那么 OpenCode 到底会覆盖 合并 向上搜索 取第一个 全部注入 按照什么优先级官方已经明确公开了 Rule 搜索、Fallback 以及 Custom Instructions 的部分规则。因此下一篇就应该继续进入《Harness Marketplace 剖析系列 - 之 OpenCodeAGENTS.md、Instructions 与 Context 是如何形成的》重点研究Project AGENTS.md ↓ Global AGENTS.md ↓ CLAUDE.md Compatibility ↓ instructions[] ↓ Rule Discovery ↓ Precedence ↓ Context Injection到那时我们才开始真正从Static Structure进入Runtime Resolution而再往后才会进入 OpenCode 更有意思的核心Command vs Skill Skill vs Tool Custom Tool vs MCP Plugin vs Capability Permission vs Runtime Plugin Hook vs Security Boundary这也是 OpenCode 作为一个开放 Harness真正值得深入研究的地方。
)
