技术 · 熟练
框架还是运行壳，你选的是哪一层？
换个词，判据全变了
这一品类的自我描述，这一年从「框架（framework）」换成了「运行壳（harness）」—— 换的不是营销词，是判据。框架问的是「你愿不愿意在它的抽象里写代码」；运行壳问的是「换模型 · 换工具 · 换技能 · 换界面时，你要不要重写 agent」。迁移已经落到具体项目上：一个开源项目把「一切皆插件」做成架构主轴、星数越过老牌框架；一家 SDK 干脆改名 harness-sdk；连冻结半年多的老牌多 agent 框架，开发也迁到了统一的 Agent Framework。这一页给换词之后的三个判据 —— 先分清你在选哪一层 · 问「换一件要不要重写」· 把接口与业务逻辑分开 —— 以及一次选型自查。
方法 · 一图看懂
1
先分清你在选哪一层 — 框架 = 你的 agent 住在它里面；运行壳 = 它坐在模型上面，模型与工具是可替换件
2
问「换一件要不要重写」 — 换模型 · 换工具 · 换技能 · 换界面，各自试算一次改动面，答案就是这一层的价值
3
把接口与业务逻辑分开 — 工具调用统一走一层协议，业务规则留在你自己那侧，别让它散进每家的封装里
4
给每一层配一个验收点 — 加了一层就要能单独测它买到了什么；测不出「它在防哪种具体的坏结果」就别加
原理 · 为什么有效
词变了是因为问题变了。框架时代的默认问题是「它的抽象够不够顺手」——那决定你写代码的手感；运行壳时代的默认问题是「它把哪几样东西做成了可替换件」——那决定你明年换模型时付多少代价。这两件事在同一个项目里会指向完全不同的选择：一个抽象很顺手、但把模型名焊死在几十处配置里的框架，会在退役公告那天集中变成负债。反过来，一个插件化很彻底、但每次都要你手写编排的运行壳，会在交付速度上收你的钱。判据一句话：别问它抽象得顺不顺手，问它把哪几样东西做成了插件。配合看的是第三条 —— 官方资料里同一份弃用政策同时讲「模型层要可换」与「工具层要靠一层开放协议解耦」，因为把工具绑死在某一家的专有格式里，换模型就从「改一处路由」变成「重写每一处集成」。
适用场景
适用：要自己搭 agent、且预计会换模型或换工具的场合；以及正在两份方案之间选、又被榜单星数带着走的场合。不适用：只用官方客户端、完全不自己写编排的场景（那时你在选的是产品不是一个层）。
自测 · 5 问
能说出你选的这层「哪几样是可替换件」，而不是只说「用起来顺手」
换模型的改动面收敛到一处配置（模型标识写在配置里、并被记进日志），而不是散落在脚本里
工具调用统一走一层协议（发布一次、多个运行时可达），而不是每家 SDK 各接一遍
加这一层之前写下了它在防哪一种具体的坏结果；写不出来的一律先不加
新模型 / 新版本到来时会重测一次，而不是默认继续沿用上一代的脚手架
怎么上手 · 验证步骤
最小可行做法是三次试算，半小时：① 拿你现在的方案做一次「换模型」演练 —— 把模型标识换成另一个，数一数要改几处；② 再做一次「换工具」演练 —— 假设某个工具方的接口变了或换了一家，数一数要改几处；③ 把这两次数出来的处数写在方案旁边，作为这一层的成本基线。凡是答不上「改一处就够」的，说明真正的可替换边界不在它宣称的那一层上。
把方案的自述过一遍，凡出现「一体化」「开箱即用」「上手快」这类描述，问一句：它把哪几样东西做成了插件？答不出来就还没选完。