Synthesis Model Tiers 是一个小型约定，目的是让模型名称只出现在一个文件里，而不是散落在各处。技能、项目上下文文件、智能体记忆和常驻指令都只引用角色标签，标签在 tiers.yaml 中解析为当前的模型标识符。当供应商推出新一代模型时，只改一个文件，所有使用方就都是最新的。
三个角色
- judgment（判断）：用于判断性决策、新出现的模式、技能/脚本撰写、跨系统变更——只要出错代价高昂的场合都用它。角色特点是“你能负担得起的最强模型”。
- routine（例行）：用于按规则执行的例行工作，比如每日扫描、机械式运行、模板化程度高的工作。角色特点是“平衡的默认选择”。
- bulk（批量）：用于高量、低风险的工作，比如大规模分类、持续摘要。角色特点是“足够用且最便宜的选择”。
只有三个角色是刻意的设计，即使某个供应商的模型梯队有四到五档。角色描述的是工作本身，而不是供应商的产品目录。
如何选择角色：看诊断难度，不只看表面大小
最常见的误路由，是把听起来很小的任务派给便宜的层级。任务大小不是变量，真正的问题是：原因是否已知。
原因已知：规格已经确定，工作只是执行，比如执行重命名、跑测试套件、加一行数据、重排文件格式。这属于 routine 或 bulk。
原因未知：那么无论表面多小，工作本质上都是诊断。凡是描述为症状的说法，比如“X 不工作”“这个坏了”“它为什么这样”“文件打不开”，都是在一串候选原因里做差分排查。成本随搜索范围增长，而不随修复动作的大小增长。即使对象只是一个文件，也属于 judgment。
对诊断使用便宜的推理，并不会得到更小但正确的答案。它会抓住第一个看似合理的分支就下结论，而这种自信恰恰会让错误答案被写下来、提交并推送出去。
以下三个属性中的任意一个，都会让工作必须归入 judgment，不管请求听起来多小：
- 原因未知（即上面的规则）。
- 影响范围里包含交付物或持久记录。读取是便宜的；写入会被其他智能体、客户或未来会话依赖的内容则不便宜——无论改动多小。
- 工作在落地前不会经过独立评审。绕过现有评审关卡的工作，要自己承担那道关卡的分量。
这种不对称性让上述选择成为成本问题而非偏好问题。如果错误必须由更昂贵的流程去发现并撤销，那么便宜的那次尝试不是节省，而是一笔带利息的债务。诊断、回滚和重新验证最终都要在更高层级上支付，期间还要占用负责人的注意力。
信任依赖是最尖锐的部分。低层级智能体给出的听起来合理但错误的解释，会把全部验证负担转回给人，这反而背离了委托的初衷。如果负责人接受了自信、连贯但错误的诊断，就会在不知不觉中继承缺陷。
一个真实案例的形状：一份“这个文件打不开”的报告被路由到便宜层级。症状是一个断链——这是两端的事情——但便宜会话只检查了文件，从未检查前一条消息里的链接文本。它根据某个诊断工具的输出构建了一个看似合理的理论，重写文件去满足该工具，看到工具不再报错，然后就提交了。工具的通过是真实的，但与所报告的症状无关；症状仍未修复，而文件本身被降级了。来自错误“神谕”的绿色信号比没有信号更危险，因为它终止了调查。
为什么用这些词
这些标签命名的是你交给模型的工作，而不是模型本身——因为供应商的词汇天生不稳定。该技能 v1.x 使用 frontier/efficient/light；“frontier”在一天内就失效了，因为业界把这个词用于供应商当前整代产品（OpenAI 把三款 GPT-5.6 模型都标为“frontier”）。工作类别是供应商营销永远不会碰撞的东西：没人会发布一款叫“Routine”的模型。完整推理、选择标准、燃料等级和航空舱位类比以及所有被否决的候选词都在 references/naming-rationale.md 中。
改名后得出的借用规则：只有在你想表达与行业完全相同的含义时才借用行业词（flagship=供应商的展示模型，保留；frontier，弃用）。
解析规则
- 在 tiers.yaml 中查找 providers.<provider>.<role>。列表是有序偏好：第一项优先，后面的项是受支持的备选（出于成本或可用性）。例如，某个供应商可能偏好其最新的顶级模型，同时在同一角色中保留上一代旗舰作为成本敏感时的备选。
- 层级较少的供应商可以为每个角色只列一个模型——同一个模型可以服务两个角色。当供应商合并两档时，列表会缩短，无需改动 schema。
- 本地供应商（如 Ollama）受硬件限制：其角色列表只包含适合操作者机器的模型。产品目录可以保留更大的模型以备未来硬件——允许目录 ⊇ 角色列表；反过来则是漂移。
- clients：只在客户端 UI 与 API id 不同时携带选择器字符串。没有条目时，API id 就是选择器。
- 智能体通常不能自己切换模型——模型选择是客户端操作，由人执行（例如 Claude Code 的 /model）。当工作需要不同层级时，说明情况并等待，不要尝试变通。
- 智能体如果发现自己对当前工作而言层级过低，必须在行动前说明，而不是事后。如果任务到手时看似例行，后来发现是诊断——原因未知，或影响范围里有交付物——要指出这一点，让人来重新定级。继续执行并报告一个自信的结果，正是该技能要防止的失败模式，也是智能体事后最难以自我察觉的一种。
这个文件不是什么
- 不是能力目录。上下文窗口、定价、token 限制和思考模式属于各产品自己的配置（例如 Ragbot 的 engines.yaml）。本文件只把角色映射到 id。
- 不是第二套词汇。产品目录在每模型的 tier 字段中使用同样的三个词（judgment / routine / bulk）；本文件在每个角色内增加了跨供应商的有序偏好。一套词汇，两种职责，并用一致性测试保持它们一致（见使用方指南）。
- 不是遥测或历史。它反映当下。过去的选择保存在会话日志中（见 synthesis-context-lifecycle 中的 Agent Attribution 约定）。
更新协议
- 编辑前对照供应商官方文档核实标识符——绝不要依据智能体的训练数据，那对模型发布而言总是过时的。
- 为每个供应商记录核实日期（verified:）。
- 未知值就是字面字符串 unknown——绝不猜测。规范表里错误的模型 id 比明确的空缺更糟。
- 模型只会前进。如果列出的模型报错，问题在配置或代码，而不在模型选择。
- 编辑后要传播：重新安装技能副本，并刷新任何人类可读的镜像（例如全局智能体指令中的 Model Tier Convention 小节）。
- 如果怀疑某个角色标签与现存的供应商词汇碰撞，在把该标签写进任何新内容之前，重新运行 references/naming-rationale.md 中的碰撞检查。
使用方指南
- 在技能和项目文档中：写“使用 judgment 层级模型”或“routine 层级足够”，可选附上指针（通过 synthesis-model-tiers 解析）。
- 在智能体记忆/偏好中：存储角色规则（“日常扫描用 routine；规则未覆盖时用 judgment”），而不是模型名称。
- 在产品中：以编程方式读取 tiers.yaml，或在产品自己的目录中用同一套词汇携带每模型的 tier: 字段——并用测试来强制一致，而不是靠肉眼核对。参考实现：Ragbot 的 tests/test_engines_yaml.py（TestTierVocabulary、TestTierRoleConsistency），它校验每个目录 tier 并与已安装的 tiers.yaml 交叉核对，在技能未安装时干净跳过。
许可证与作者
CC0-1.0，属于 synthesis-skills 集合。作者：Rajiv Pant。