模型: openai/gpt-5.4
生成日期: 2026-04-01
书名: Claude Code VS OpenCode：架构、设计与未来
章节: 第22章 — 可扩展性设计
Token用量: 约 5,900 input + 1,900 output
22.1 三层内容类型
很多智能体平台在做可扩展性设计时，犯的第一个错误就是：把所有扩展内容都当成同一种东西。其实不是。一个成熟系统至少要区分三类内容：reference content（参考内容）、task content（任务内容）、executable tools（可执行工具）。这三类东西不只是格式不同，更重要的是它们面向的执行者不同。一旦不区分执行者，扩展系统最后就很容易退化成一大团 prompt 汤。
第一类是 reference content。顾名思义，它是给 LLM 阅读、理解、吸收的背景材料，而不是要求模型逐条照做的操作脚本。比如 API 文档、架构说明、编码规范、产品需求、术语表、设计缘由、过去的决策记录，这些都属于参考内容。它们的作用是扩展模型对“当前世界”的理解边界。换句话说，它是在告诉模型：你现在应该理解哪些事实和背景。
参考内容之所以重要，是因为 LLM 的表现极大取决于当前上下文里有哪些有效信息。但它也最容易被滥用。很多系统会把大量文档一股脑塞进上下文，结果模型花了大量注意力预算去读背景，真正用来解决眼前任务的空间反而不够了。因此，参考内容的关键，不只是“有没有”，而是“什么时候、以什么粒度、在什么条件下被取出来”。这就是为什么好的系统会需要检索、优先级、条件注入，而不是机械全塞。
第二类是 task content。这类内容不是简单让模型知道，而是让模型跟着做。它往往以流程、步骤、检查表、评分 rubric（评价准则）、操作 runbook（运行手册）、模板等形式出现。一个 skill 文件如果写的是“当用户要求 X 时，先检查 Y，再输出 Z”，那它主要就是任务内容。命令定义、工作流模板、某类固定故障排查流程，也都属于这一类。任务内容的本质，是给模型一套行为程序，而不是一堆世界知识。
这和参考内容的边界非常重要。一个代码风格说明，更偏参考内容；一个发布检查表，更偏任务内容。一个术语表是参考内容；一个数据库迁移步骤是任务内容。如果系统不区分两者，模型就会出现两种反常行为：要么把本该严格执行的流程只当成背景建议，要么把本该灵活参考的背景材料误当成硬规则。两边都会出错。
第三类是 executable tools。这类东西最根本的区别在于，它的主要执行者不是 LLM，而是计算机运行时。比如读文件、改代码、运行测试、调用 GitHub、查询 LSP、访问 MCP server、连接外部 API，这些都属于工具层。模型也许会决定何时调用工具，但真正产生外部效果的是宿主环境和工具实现。因此，工具设计不只是 prompt 设计问题，更是接口设计、安全设计、权限设计、异常处理设计问题。
这三类内容一旦区分清楚，就会自然导出一条非常关键的路由原则：
- 参考内容 应该被有选择地路由给 LLM，作为背景上下文。
- 任务内容 应该被路由给 LLM，作为程序化指导。
- 可执行工具 应该被路由给 runtime，作为可调用能力。
很多扩展架构之所以难用，就是因为它们把这三类东西都塞进 prompt。文档、步骤、工具说明混在一起，系统指望模型自己理解哪些该读、哪些该遵守、哪些该调用。这种做法在小规模实验里勉强能跑，但一旦内容变多，prompt entropy（提示词熵，也就是混乱度）会迅速上升，审计和维护也会越来越难。
OMO 在这方面提供了一个很好的例子。它的 skills 既可能包含参考知识，也可能包含明确流程，甚至还可能嵌入 MCP 能力指引。但这些部分在系统中扮演的角色并不相同。OpenCode 保持工具、命令、配置相对分离，也能受益于这种内容分类。Claude Code 的 plugin、skill、command 分层同样说明：不是所有扩展内容都应该被视为“给模型的一段文字”。
这件事为什么这么重要？因为不同内容如果被送给了错误执行者，失败模式会完全不同。参考内容如果被误当成任务内容，模型会变得过度拘谨；任务内容如果被误当成参考内容，关键步骤就会被跳过；工具如果只以文字描述存在，而没有暴露为可执行接口，模型就只能“假装完成动作”，而不能真的完成动作。这三类错误根本不是一个层级的问题。
此外，内容分类还有维护层面的好处。参考内容常常由领域专家维护，任务内容可能由流程设计者维护，而工具则由工程师实现和更新。把这三层拆开，团队就能在不互相污染的前提下分别演进它们。组织越大，这种分工越重要。
可以用一个很稳定的三元组来记这件事：参考内容解决 knowledge（知道什么），任务内容解决 procedure（怎么做），工具解决 capability（实际能做什么）。这三个词不是新的理论发明，但非常适合做智能体扩展架构的基本骨架。
所以，扩展系统真正成熟的标志，不是它能塞进去多少内容，而是它能否明确判断：某个扩展工件到底是该被“阅读”、被“遵循”，还是被“执行”。如果宿主系统连这件事都分不清，可扩展性迟早会坍缩成不可维护的 prompt 混合体。