[!info] related notes

• 所属 MOC: agent-evals-moc、agent-moc
• 配置与评测: agent-configuration-bundle、agent-configuration-interaction-effects
• 关系笔记: bodysense-diagnosis-model-governance-eval-loop

Agent Model Capability Policy

一句话定义

Agent Model Capability Policy 是把模型能力分成 REQUIRED / PREFERRED / OPTIONAL，从而区分“没有就不能承担这个角色”的资格条件与“有更好但不是硬门槛”的偏好条件。

三种级别

REQUIRED
→ 缺失即不进入该角色的候选集

PREFERRED
→ 缺失允许降级或降低优先级，但需要被记录和评测

OPTIONAL
→ 有无通常不影响生产资格

例如某个 Diagnosis 角色可能最初定义以下假设；这不是某个已部署系统的能力清单：

structured output = REQUIRED
tool calling       = REQUIRED
reasoning          = PREFERRED
prompt cache       = OPTIONAL

这里的 reasoning 应定义为具体可检验的模型模式或接口能力，不能把未提供专用 reasoning 开关等同于“模型不会推理”。structured output 也需区分保证 JSON 语法与按指定 schema 约束输出。

为什么不能把“表现差”直接升级成 Capability REQUIRED

如果 Model B 缺少 reasoning 并出现回归，只能先说明：

Model B 在当前 configuration 下表现不好

它不能直接推出：

所有没有 reasoning 的模型都不合格

若另一个同样没有 reasoning 的 Model C 稳定通过关键门槛，更合理的行动是淘汰/降级 Model B，而不是扩大 role-level hard requirement。

要把性能偏好升级为 REQUIRED，应在目标任务、候选模型和配置范围内做 controlled eval，记录对照、样本限制与风险依据。有限模型的结果不能证明所有缺少该能力的模型永远不合格；资格规则应限定适用范围并随新证据复核。

三种问题不要混在一起

Deployment bad
→ endpoint / provider / runtime 问题

Model bad
→ 某个具体模型不适合该业务角色

Capability class insufficient
→ 缺少某种能力的配置普遍不能满足 contract

第三类支持的是能力级资格调整，前两类通常先处理更窄的边界。另有一些 REQUIRED 来自明确的协议兼容、访问权限或业务约束，本就不依赖“其他模型都表现差”的归纳证明。

Capability Policy 是可被证伪的假设

策略最初来自工程判断，但生产 telemetry 与 eval 可以反过来修改它：

production signal
→ hypothesis
→ targeted eval
→ evidence
→ update capability policy

因此 REQUIRED 不应该被理解成永恒真理，而是一个必须有证据支持、版本化管理的生产资格规则。

与路由的关系

推荐顺序：

Eligibility
→ REQUIRED capability filter

Preference
→ PREFERRED capability / quality tier

Routing objective
→ cost / latency / capacity

先决定“谁有资格”，再在合格集合里优化成本与性能。能力元数据只是初筛，还需验证实际 provider/adapter 支持、工具约束与 configuration-level eval；不能用供应商声明代替运行资格。

常见误解

• 能力越多越安全：能力只是潜力，最终资格仍需 configuration-level eval。
• PREFERRED 可忽略：它仍应进入评测、路由偏好和 degradation trace。
• 某个模型失败就应收紧所有模型的规则：先修最窄的错误边界，再判断是否存在 capability-class 级证据。