Agent 的工具集开始从“启动时一次性塞满上下文”，转向“运行中按需显露能力”。Pydantic AI 在 2026-06-02 的 v1.105.0 / v2.0.0b5 里合入 on-demand capabilities：能力有稳定 id，初始只给模型一个紧凑目录，模型需要时再调用框架管理的 load_capability，把对应 instructions、tools、model settings、hooks 暴露出来。

这不是单纯省 token。对 Agent Engineer 更重要的是，它把“能力发现”变成了可观测、可回放的状态转换：哪些能力一开始可见、哪个 turn 加载了哪个 capability、恢复会话时 loaded state 如何从 message history 还原，都可以进入 tracing 和评测。OPC 这类多流程、多工具平台如果继续把全部工具描述塞进系统提示词，会同时伤害 prompt cache、模型路由和权限边界。

工程上可以把每个业务域建成 capability：订单、合同、日程、知识库、代码执行、外部发信等。默认只暴露 id、description 和加载入口；加载后才暴露细工具。OpenAI Responses / Anthropic 这类有原生 tool search 的路径还可以保持 provider-visible function-tool array 更稳定，让 prompt-cache 前缀更容易复用；没有原生支持时退回本地 search_tools，仍能减上下文，但缓存稳定性会差一些。

常见误区是把它理解成“动态插件”。真正的设计重点是能力边界：id 必须稳定，description 要能让模型判断何时加载，native tools 的 deferral 可能破坏缓存前缀，敏感 capability 还要接审批、审计和租户权限，而不是只靠模型少看见几个工具。

如果你今天要为 OPC 设计一个 capability catalog，哪些能力应该默认可见，哪些必须按需加载，哪些加载动作本身需要留下审计事件？

Sources

• Pydantic AI v1.105.0 release: https://github.com/pydantic/pydantic-ai/releases/tag/v1.105.0
• Pydantic AI v2.0.0b5 release: https://github.com/pydantic/pydantic-ai/releases/tag/v2.0.0b5
• PR #5230: https://github.com/pydantic/pydantic-ai/pull/5230