Agent Model Capability Policy

用 REQUIRED、PREFERRED、OPTIONAL 区分模型能力的生产资格底线与偏好，并允许评测证据反过来修正最初的能力假设。

#type / concept #status / growing #tech / ai #tech / architecture #resource / agent

[!info] related notes

所属 MOC: agent-evals-moc、agent-moc

前置概念:

并列概念:

易混淆概念:

关系笔记: bodysense-diagnosis-model-governance-eval-loop

一句话定义

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

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

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

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

例如某个 Diagnosis 角色可能最初定义：

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

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

Model B 在当前 configuration 下表现不好

它不能直接推出：

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

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

要把 reasoning=PREFERRED 升级为 REQUIRED，需要 controlled eval 证明缺少 reasoning capability 这一类配置普遍无法满足业务 contract。

Deployment bad
→ endpoint / provider / runtime 问题

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

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

只有第三种证据才足以修改 role-level 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

先决定“谁有资格”，再在合格集合里优化成本与性能。