核心观点 - 模型与运行它的“壳”之间存在紧密的耦合性，这种“模型与壳的匹配度”是影响模型性能表现的关键因素，其重要性甚至超过模型本身的权重升级[4][5][9] - 同一套模型权重，在不同的壳中运行，性能表现可以产生巨大差异，例如Claude Opus 4.6在ForgeCode壳中得分为79.8，在Capy壳中仅为75.3，相差4.5分[8] - 模型在训练后期是针对其特定壳的细节进行优化的，这些细节包括工具命名、输入模式、引用标签等，形成了模型的本能，使得模型无法在不同壳之间无缝迁移[13][57] 行业现状与现象 - 在Terminal-Bench 2.0等权威榜单上，壳对性能的提升作用显著，第三方壳ForgeCode占据了榜单前六名中的三个席位[8] - 行业中存在一个反直觉的现象：模型公司自家的旗舰模型运行在其官方壳中，其表现可能不如运行在第三方优化壳中的同一模型[12] - Cursor团队通过优化壳，使得同一模型的榜单排名从Top 30跃升至Top 5，提升了25位[4][52] 技术原理与耦合性 - 模型在训练后期阶段，其学习内容与壳的特定实现细节深度绑定，包括工具调用格式、规划协议、记忆系统架构等[13][18] - 不同壳定义了完全不同的底层通信协议，例如Codex使用类型化异步协议，Claude Code使用直接类型化对话循环，GitHub Copilot CLI使用监督者协议[16][17] - 工具集是模型“方言”的体现，不同壳提供的工具在名称、数量和调用方式上存在差异，模型被训练成使用特定格式的工具，换用其他格式会导致效率下降和错误率上升[21][22][24][25] 具体组件分析 - **技能系统**：虽然不同壳都使用类似SKILL.md的格式，但技能文件中隐含着对特定工具集的调用契约，跨壳使用时会导致技能默默失败或功能残缺[26][27][30][32] - **记忆系统**：不同壳的记忆架构（如延迟批量写、同步实时写、服务端存储）和引用机制（如特定的XML标签）差异巨大，跨壳使用会导致记忆无法被正确识别、引用和衰减，从而失效[33][34][36][43] - **引用标签**：一个具体的例子是Codex壳使用的`<oai-mem-citation>`六字符XML标签，它作为模型与壳之间关于记忆使用的契约，在其他壳中不被解析，直接导致记忆系统功能紊乱[37][38][42] 对行业参与者的启示 - **对智能体平台而言**：应将模型与壳作为一个整体产品来设计和发布，承认并管理好它们之间的强耦合关系，试图建立通用接口往往会在各个模型上导致性能损失[46][53] - **对模型实验室而言**：壳是产品战略和核心护城河的一部分，而非普通的基础设施，其设计（如记忆流水线、系统提示注入机制）是塑造模型不可替代性的关键[53] - **对用户而言**：更换模型的实际成本很高，因为这需要复刻整个工具集、引用契约、系统提示结构等配套环境，其代价接近于重新进行一次后期训练[54] 实践与成本 - 在单个会话中中途切换模型会导致对话历史分布偏移、提示缓存失效以及工具集形状改变，带来显著的性能损失和复杂性[47] - 更干净的解决方案是派遣子智能体使用新模型，而非切换主对话模型，这样可以避免上下文污染和缓存问题[49] - GitHub Copilot CLI采取了务实的“按模型路由”策略，为不同家族的模型加载其训练时使用的工具集和循环，承认了不同模型在自家壳中实为不同产品的事实[44][45][46] 发展趋势 - 模型与壳的匹配关系不是静态的，随着模型能力的演进，原先壳中用于弥补模型不足的“脚手架”可能变得多余甚至成为负担[55][56] - 前沿的设计方向是模型与壳的“成对设计”，让后期训练与运行时环境相互加强，形成正向循环[58] - 为了保持领先，在新模型发布时可能需要大幅重构甚至删除原有的壳代码，因为更强大的模型能够“消化”掉之前需要的辅助结构[59]