模型能力注册

记录每模型及适配器可实际使用的能力和限制。

能力注册表记录的是某个模型、provider与adapter组合实际能使用什么，而不是模型名称旁的营销标签。相同模型在不同云平台、API版本或套餐下，原生搜索、缓存、输出schema和上下文限制都可能不同。Agent在调用前需要能判断哪些能力可用。

建议条目包含消息角色、并行工具、严格schema支持范围、多模态、引用、原生工具、reasoning参数、最大输入输出、compaction和缓存合同。每一项都带观察日期、文档依据和契约测试结果，区分公开支持、已在目标环境验证、未知与不支持。没有测过的能力不应填成默认通过。

运行时根据表选择合法路径。例如模型不支持某种严格输出模式，可由应用解析并验证普通结构化输出，但这是不同保证；不支持native search时可接独立检索工具；不支持跨模型压缩状态时，从事件重新组装context。降级可能增加调用和延迟，必须进入预算和质量评测。

能力表还帮助定义路由资格。高风险任务只能进入获准处理相关数据、具备所需工具和格式能力的模型集合，再比较质量和成本。不能因为备用模型价格低或服务健康，就忽略数据合同和关键能力缺失。恢复旧Run时也要确认当前端点仍满足原合同。

Pydantic AI将core与Harness capabilities分层，OpenAI SDK提供provider扩展，都说明能力可以组合，但不等于跨模型等价。企业应固定adapter版本，并测试工具schema与provider变化。

可为每次发布生成一张能力矩阵，配简短探针持续检查。探针发现变化应触发调查或降级，不能自动证明业务质量提升。注册表是执行选择的依据，不是对准确率的排行榜；支持tools仅证明协议入口存在，正确使用工具还要靠任务评测。

表中还应记录能力验证所用环境与日期，部署后端变化时重新核验。

实践重点：登记并行工具、schema、多模态、context、缓存、compaction和停止原因。

验证抓手：对每项capability保存契约测试和明确降级路径。

常见误区：统一API抹平差异，生产才发现功能不支持。

OpenAI Agents SDK：模型与provider；Pydantic AI：Harness能力边界。