Agent Framework 会被模型原生 Tool Use 淘汰吗?
会。
但只会淘汰一部分。
更准确地说:模型原生 Tool Use 会淘汰很多薄薄的 Agent Framework 胶水代码。
它淘汰不了 Runtime 责任。
这两件事要分开看。
先承认模型真的变强了
现在的模型 tool use 已经不是两年前那种'让模型输出一段 JSON,再祈祷它格式正确'的阶段。
OpenAI 的 function calling 文档把 tool calling 定义成让模型连接外部系统和你应用提供的数据、动作。Anthropic 的工具使用文档也明确区分 client tools 和 server tools:模型决定何时调用工具,应用或平台执行工具。Gemini 的 function calling 也走类似路线:你声明函数,模型返回函数名和参数。
更进一步,模型平台正在提供内置工具、远程 MCP、动态工具发现、代码执行、programmatic tool calling。
所以很多旧式框架的卖点确实会变弱。
比如:
帮你拼 prompt
帮你把 JSON parse 出来
帮你循环调用工具
帮你把 tool result 塞回 messages
帮你做一个简单 memory
这些能力会越来越像 SDK 基础能力。
如果一个 Agent Framework 只是在模型 API 外面包一层薄薄的链式调用,那它的空间会被压缩。
这个判断不激进。只是现实。
但 Tool Use 不是 Tool Runtime
模型原生 tool use 解决的是:
模型如何知道有哪些工具
模型如何选择工具
模型如何生成结构化参数
模型如何接收工具结果继续推理
生产级 Tool Runtime 解决的是:
这个工具是否真实存在
参数是否符合 schema
参数是否符合本地 policy
路径是否越界
命令是否危险
联网域名是否允许
用户是否批准
工具是否幂等
失败能否重试
输出是否过大
副作用是否已发生
trace 是否留下证据
checkpoint 是否能恢复
前者是模型能力。
后者是系统责任。
你不能因为模型能返回 {"name":"create_order","arguments":{...}},就认为订单创建流程已经安全了。
Tool call 只是行动计划。
执行权仍然在 Runtime。
框架会被吃掉的部分
我觉得会被模型和官方 SDK 吃掉的,是这些浅层能力:
单模型调用封装
简单 prompt template
普通 function calling adapter
基础 JSON schema 转换
最小 tool loop
简单 retry 包装
普通 streaming event 封装
以前这些东西可以单独撑起一个框架的主要价值。
现在不行了。
模型供应商会直接提供更贴近模型行为的接口。官方 SDK 会比第三方框架更早支持新能力。比如并行工具、内置工具、远程 MCP、结构化输出、代码执行、动态工具检索,这些能力通常会先在平台侧出现。
如果框架只是把新字段转一遍名字,它迟早会变成兼容层。
兼容层有价值,但不该被误认为 Runtime。
框架吃不掉的部分
真正难的是这些:
跨 provider 的稳定中间表示
Tool Registry 和版本管理
工具风险分类
权限审批和审计
Sandbox 边界
Context Budget
Tool output policy
Checkpoint / Resume / Rollback
Trace / Replay / Eval
成本预算和 quota
多租户权限
上线事故归因
这些东西不只和模型有关。
它们还和你的产品、组织、数据、权限、基础设施有关。
比如同一个 send_email 工具:
个人笔记产品:也许确认一下就能发。
企业客服系统:要走客户数据权限。
金融场景:可能必须审批、留档、限额。
医疗场景:还要考虑合规和敏感信息。

