模型: openai/gpt-5.4 生成日期: 2026-04-01 书名: Claude Code VS OpenCode：架构、设计与未来 章节: 第8章 — 配置与可定制性 Token消耗: N/A（当前运行环境未暴露按文件统计的Token数量）
8.3 指令系统
如果说工具系统是 Coding Agent 的“手”，那么指令系统就是它的“神经系统”。今天的 system prompt 已经不再是一段简单的开场白，而是由多种来源共同组装出来的复合结构：基础身份、行为约束、工具描述、项目规则、记忆内容、权限上下文以及运行时环境。
OpenCode、Claude Code 和 OMO 的一个共同模式是：system prompt 不再是单一 prompt，而是一条 prompt assembly pipeline，也就是“提示词组装流水线”。
OpenCode：分层拼装的 Prompt 架构
OpenCode 在 session/prompt.ts 中把这种设计写得非常清楚。它会将 session/system.ts 生成的环境信息，与 session/instruction.ts 发现的 instruction 文档一起拼接，形成更完整的系统提示。
session/system.ts 负责提供模型身份、工作目录、平台、日期、是否处于 git 仓库等环境信息。这些内容看起来像元数据，但对智能体行为影响很大。知道自己是不是在 git repo、运行在哪个操作系统上、当前工作目录是什么，会直接影响它对工具和文件的判断。
session/instruction.ts 则负责收集 AGENTS.md、CLAUDE.md、以及兼容旧格式的 CONTEXT.md。它不仅会从全局目录找，还会沿项目目录向上遍历；同时还支持配置里声明的 instruction 路径与远程 URL。这意味着 OpenCode 的 system prompt 既有静态部分，也有动态发现部分。
之后的 prompt 组装还会叠加 agent prompt、项目上下文、工具 schema、MCP 能力等内容。最终效果是一个分层结构：环境层、规则层、工具层、任务层共同构成模型真正看到的 system prompt。
这是一种非常“系统工程”的做法。它不是写一大段万能模板，而是把 prompt 当成多个子系统拼出来的结果。
Claude Code：多源合成的系统提示
Claude Code 走的是类似路线，但在 memory 和 policy runtime context 上更进一步。
高层来看，Claude Code 的有效 system prompt 通常来自这些来源：
CLAUDE.md及相关规则文件- memory 文件和 memory 行为说明
- MCP prompts / commands
- tool descriptions
- permission context 与执行模式
- 额外 append 的 system prompt 片段
utils/claudemd.ts 很清楚地展示了它的层级：managed memory、user memory、project memory、local memory 会按优先级加载；同时还支持 @include 指令，让一个 memory file 引入其他文件。也就是说，Claude Code 的 instruction layer 不是扁平文本，而是可组合、可模块化的。
QueryEngine.ts 则展示了拼装动作本身：最终 system prompt 可以由默认 prompt 或 custom prompt，再加上 memory mechanics prompt，以及 appendSystemPrompt 一起组成。与此同时，其他模块还会准备 tool descriptions 和 MCP prompt 数据，让模型不仅知道“你是谁”，也知道“你能做什么”。
Claude Code 还有一个非常关键的点：permission context 也会影响提示边界。权限模式不是单纯的 UI 状态，而是智能体行为边界的一部分。一个运行在严格审批模式下的 Agent，和一个运行在更自动化模式下的 Agent，应该做出不同的规划与预判。从这个角度说，permission context 本身就是 system prompt 的一部分，因为它改变了智能体对“自己能做什么”的信念。
这也是商业 Agent 往往更稳的原因之一：它们不是只靠一段 prose identity 来约束行为，而是把运行时策略直接编码进上下文底座里。
OMO：为不同 Agent 定制 Prompt
OMO 则把指令系统继续推进到了“角色定制化”的阶段。在 dynamic-agent-prompt-builder.ts 中，prompt 不是固定文本，而是由多个模块动态拼出来的，例如 tool selection guidance、delegation table、category-and-skill rules、anti-pattern warning、hard block 等。
这一点在 Prometheus、Sisyphus 系列 Agent 上尤其明显。OMO 不会给所有 agent 一个通用人格，然后让它们自己适配；它会为每个角色生成一份量身定制的 prompt。
这些模块通常包括：
- identity 与角色定位
- 任务采访或 intake 规则
- plan generation 规则
- tool 和 agent selection table
- delegation guide
- 成本约束
- anti-pattern 与 hard blocks
换句话说，OMO 把 prompt 构造得更像在“编译岗位说明书”。它不只是问“模型总体上该成为什么样”，而是问“这个具体 agent 实例需要带着哪些明确约束、工具、分工和禁令”。
这比传统 prompt template 更进一步。本质上，OMO 在做 prompt modularization，也就是“提示模块化”。这里的模块化不是教科书中标准 AI 术语，但它和软件模块化的思想类似：把一类职责封装成可复用、可组合的 prompt 组件。
“System Prompt 即人格”只是对了一半
在 AI 讨论里，人们常说 system prompt 定义了 agent 的 personality。这句话只说对了一半。
更准确地说，system prompt 同时定义三件事。
第一，是 personality，也就是语气、主动性、协作姿态、表达方式。
第二，是 policy，也就是优先级、工作流程、规则解释方式。
第三，是 perimeter，也就是边界：哪些事情不能做、哪些场景必须申请许可、何时应该委派、哪些推理捷径属于禁止项。
OpenCode 更强调环境信息与 instruction 文件的分层拼装。Claude Code 更强调 memory、MCP、tools 和 permission 的多源合成。OMO 更强调每个 agent 的角色化 prompt 定制。
它们不是互斥的，而是在同一条架构光谱上的不同侧重点。
为什么模块化指令系统很重要
随着 Coding Agent 越来越强，指令系统正在成为新的可扩展性瓶颈。单体大 prompt 很难维护、很难排错、也很难局部覆盖。模块化组装可以同时解决几个问题。
第一，它支持 source attribution，也就是行为来源可追踪。一个行为到底来自 AGENTS.md、memory、managed policy，还是某个 agent 专属 section，可以更容易定位。
第二，它支持 selective override，也就是局部覆盖。团队规则可以覆盖个人习惯，项目上下文可以覆盖通用默认值。
第三，它支持 specialization，也就是专业化分工。不同 agent 可以共享基础层，同时在某些 section 上进行受控分叉。
如果借用计算机科学中的类比，单体 prompt 很像一个巨大且难维护的 global variable；而模块化 instruction system 更像 dependency injection：行为由多个有明确所有权边界的组件共同提供。
这个类比很重要，因为 prompt 复杂度已经大到必须用软件工程方法来治理。
未来方向：从单一 Prompt 走向 Prompt Graph
未来最可能的方向，不是继续堆砌一段越来越长的 universal system prompt，而是形成 prompt graph。
这里的 prompt graph 不是传统教材中的固定术语，可以把它理解为“按作用域、角色、工具、任务类型动态激活的提示组件网络”。有些组件总是存在，比如身份和安全边界；有些组件是条件触发的，比如项目规则、memory reminder、MCP prompt、delegation protocol。
OpenCode 通过 layered discovery 与 composition 已经隐约体现了这一点。Claude Code 通过 memory scope、permission-aware context、MCP prompt conversion 进一步逼近。OMO 则最明确，它已经在为不同 agent 生成不同的 prompt 体。
因此，本章最重要的结论是：指令系统不应该再被当作“文案”来写，而应该被当作“基础设施”来设计。
下一代优秀的 Coding Agent，决定性差异未必是那段 base prompt 更会说话，而更可能是它拥有更成熟的 instruction assembly architecture：模块化、可检查、作用域感知、角色感知，并且和工具系统、记忆系统、权限系统紧密耦合。
到那时，system prompt 就不再只是一段文字，而会成为 Agent 的“软件定义人格边界”。