26.5 缺失的部分：致 Claude Code 扩展性的公开信
模型: claude-opus-4-6 (anthropic/claude-opus-4-6) 生成日期: 2026-04-01 书名: Claude Code VS OpenCode：架构、设计与未来 章节: 第26章 — 设计“Oh-My-Claude-Code“ Token 消耗: ~7,600 输入 + ~1,200 输出
前几节展示了在 Claude Code 当前扩展面约束下能做到什么。这一节要直说的是：还差什么。这不是批评——Claude Code 的扩展 API 设计有其清晰的安全理由——而是一份功能请求清单，说明如果这些能力存在，开发者能用 Claude Code 构建什么级别的系统。
26.5.1 chat.message 钩子：消息到达 LLM 之前的拦截
缺失描述： 目前无法在用户消息被发送给模型之前进行处理。
这意味着什么： Oh-My-OpenCode 用 chat.message 钩子实现的一系列关键功能，在 Claude Code 上无法做到：
- 首消息变体门控——根据用户第一条消息的内容，动态选择智能体应该以什么“模式“运行。比如，检测到
fix:前缀时激活快速修复模式，检测到refactor:前缀时激活深度分析模式。 - 关键词路由——识别消息中的
@oracle或@explore提及，自动委派给对应子智能体，无需用户手动切换。 - 会话状态初始化——在第一条消息时设置会话级状态（如 boulder state），供后续钩子使用。
绕行方案的代价： 这些逻辑只能写进系统提示词，但提示词无法“解析“用户消息的结构——它只能“建议“模型按某种方式响应，而钩子可以“强制“。
26.5.2 tool.execute.before/after 的变换能力
缺失描述： PreToolUse 和 PostToolUse 钩子可以观察工具调用，可以阻止执行，但不能修改工具的输入参数或输出结果。
这意味着什么：
- 标签截断器——Oh-My-OpenCode 在
tool.execute.after中自动截断过长的工具输出，防止单次工具调用耗尽上下文窗口。Claude Code 的PostToolUse无法修改工具返回给模型的内容。 - 规则注入器——根据被操作文件的类型（
.tsx、.py、.go），自动在工具调用前注入对应的编码规范。Claude Code 的PreToolUse不能修改工具参数来附加额外上下文。 - 结果增强——在工具返回结果后附加额外信息，比如在文件读取结果后追加该文件的 Git 历史摘要。
衍生解释：工具输出截断（Tool Output Truncation）——LLM 的上下文窗口是有限的（即使是 200K token 的模型也会被大量工具输出填满）。当一个
grep操作返回了 5 万行结果时，将其全部塞入上下文是灾难性的。工具输出截断是一种防御机制：在结果返回给模型之前，自动将过长的内容压缩到安全范围内，通常附带一条提示如“结果已截断，显示了 100/50000 行，请使用更精确的查询“。
26.5.3 插件级工具注册
缺失描述： Claude Code 不提供编程式的工具注册 API。新增工具的唯一方式是通过 MCP 协议。
这意味着什么： MCP 是一个强大的标准，但它引入了额外的运行时开销——每个 MCP 服务器是一个独立进程，工具调用通过 JSON-RPC 跨进程通信。OpenCode 的插件可以直接通过 tool 钩子注册原生工具，这些工具与内建工具在同一进程中运行，零序列化开销。
对于需要紧密集成到对话引擎的工具（如 Oh-My-OpenCode 的 todowrite、session_read、call_omo_agent），MCP 的进程隔离模型增加了不必要的复杂性。一个轻量级的插件工具注册 API 可以弥合这个差距。
26.5.4 智能体级模型选择
缺失描述： Claude Code 的所有智能体（主智能体和子智能体）使用相同的模型。无法为不同智能体指定不同的模型。
这意味着什么： Oh-My-OpenCode 的一个核心优化是模型路由——为不同职责的智能体分配最合适的模型。Explore 智能体做代码搜索，不需要最强的推理模型，用 Claude Sonnet 即可；Oracle 智能体做架构分析，可以上 Claude Opus。这种分级策略既优化了成本（简单任务用便宜模型），又优化了响应速度（小模型更快）。
在 Claude Code 的商业模式下，这个限制可能是故意的——Anthropic 自然希望所有调用都使用 Claude 模型。但从纯技术角度，智能体级模型选择是多智能体系统的重要能力维度。
26.5.5 带会话续接的背景智能体
缺失描述： Claude Code 的子智能体（通过 AgentTool 或 Task 系统派遣）每次调用都是一个全新的上下文。无法让一个背景智能体在多次调用之间保留完整的对话历史。
这意味着什么： Oh-My-OpenCode 的背景智能体支持通过 session_id 续接——你可以让一个 Explore 智能体在第一次调用时分析项目结构，第二次调用时基于已有的理解做更深入的探索，第三次调用时综合前两次的发现给出结论。每次调用都建立在之前积累的完整上下文之上。
没有会话续接，每个子智能体调用都是“失忆“的。对于简单的单次任务（“在代码库中找到所有 TODO”）这不是问题；对于需要多轮交互的复杂分析（“理解这个微服务的数据流，然后找出性能瓶颈”），失忆意味着每次都要重新建立上下文，既浪费 token 又降低分析深度。
衍生解释：会话续接（Session Continuation）——指在多次交互之间保留完整对话历史的能力。这与“无状态“的 HTTP 请求模型相反。在 AI 智能体系统中，会话续接使得智能体能够在多轮交互中逐步积累理解，而不是每次都“从零开始“。这类似于人类专家在多次咨询中逐渐深入理解问题的过程。
26.5.6 呼吁：更丰富的 Plugin SDK
上述五项缺失指向一个共同的方向：Claude Code 需要一个更丰富的 Plugin SDK。
不是要求开放全部内部 API——安全约束必须保留。而是在保持安全基线的前提下，提供以下层次的扩展能力：
- 消息感知层——允许插件在消息到达 LLM 前进行只读检查（不修改内容，但可以触发副作用如日志、路由决策）
- 工具变换层——允许插件修改工具的输入参数和输出结果（在安全审计下）
- 原生工具注册——允许插件注册与内建工具同级的工具（不经过 MCP 跨进程通信）
- 智能体配置层——允许在智能体定义中指定模型偏好、温度参数、最大 token 等
- 会话管理层——允许子智能体保持有状态的会话，在多次调用间积累上下文
这些能力的组合将使 Claude Code 的插件生态从“配置和命令的扩展“升级为“对话引擎的深度定制“——正是 OpenCode 的插件系统今天已经具备的能力层次。