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 工具：
个人笔记产品：也许确认一下就能发。
企业客服系统：要走客户数据权限。
金融场景：可能必须审批、留档、限额。
医疗场景：还要考虑合规和敏感信息。
模型 API 不知道你的业务边界。
Framework 也不知道，除非你把边界写进去。
原生 Tool Use 反而会放大 Runtime 需求
这听起来反直觉，但我越来越相信这一点。
模型越会用工具，Runtime 越重要。
因为工具调用门槛降低后，Agent 会更频繁地行动：
更多工具
更多并行调用
更多动态发现
更多长任务
更多外部副作用
更多中间状态
以前模型不会调用工具，系统最多答错。
现在模型会调用工具，系统可能写错文件、删错数据、发错消息、烧掉预算、在用户不知情时访问外部服务。
能力越强，边界越要清楚。
这就是 Runtime 的价值。
不是让模型更会行动，而是让模型的行动可控。
一个具体例子：write_file
假设模型原生 tool use 返回：
{
"name": "write_file",
"arguments": {
"path": "src/config.ts",
"content": "..."
}
}
一个薄框架会做：
parse arguments
call write_file()
append tool result
continue
一个 Runtime 会多做很多事：
1. 检查 write_file 是否注册。
2. 校验 arguments 形状。
3. resolve path，确认在 workspace 内。
4. 读取旧文件，生成 diff preview。
5. 判断风险：write。
6. 查 policy：当前用户、当前模式是否允许写。
7. 非交互模式下是否自动拒绝。
8. 用户确认后保存 approval ledger。
9. 写入前保存 snapshot。
10. 执行写入。
11. 记录 sideEffects。
12. 保存 checkpoint。
13. 写 trace span。
14. 将精简 observation 回灌给模型。
你看，这里面只有第 1、2、14 步和模型 tool use 很近。
其他都是 Runtime。
再看 run_command
run_command 更明显。
模型可能生成：
{
"name": "run_command",
"arguments": {
"command": "npm test"
}
}
这看起来很安全。
但 Runtime 仍然要判断：
命令是否只读？
是否允许安装依赖？
是否访问网络？
是否修改 lockfile？
是否有 shell operator？
timeout 是多少？
stdout/stderr 最大保留多少？
exit code 如何反馈？
是否能重试？
同样是 npm test，有些项目的 test script 会启动服务、写 snapshot、访问网络、改临时文件。
'命令字符串看起来正常'不等于'动作安全'。
模型原生 tool use 不能替你理解这些项目级风险。
Provider 原生能力会改变框架形态
我觉得未来的 Agent Framework 会分化。
一类会变薄，主要做 provider 兼容和 UI integration。
比如：
把 OpenAI / Anthropic / Gemini / 本地模型统一一下
把 streaming event 接到前端
把 tool schema 转成 provider 格式
把 MCP client 接进工具列表
这类框架会越来越像 SDK。
另一类会变厚，做 Runtime / Infra。
比如：
durable execution
permission policy
sandbox
tool marketplace
trace / eval
session state
artifact store
cost control
multi-tenant governance
这类不会被模型 tool use 直接淘汰。
但它必须足够工程化，不能只是把概念写在 README 里。
不要站错战场
很多'框架会不会死'的讨论，站错了战场。
如果你的框架卖点是：
让模型调用函数更方便
那确实危险。
因为模型平台会越来越方便。
如果你的 Runtime 解决的是：
让模型行动可治理、可恢复、可审计、可评测
那需求只会变强。
企业不缺'能调用工具的 demo'。
企业缺的是'出事后能解释、能停住、能恢复、能追责'的执行系统。
我会怎么设计自己的代码
本书 demo 里，我不会把模型 SDK 的工具调用格式直接散落到业务代码里。
内部仍然保留自己的类型：
type ModelResponse =
| { kind: "final"; text: string; usage?: TokenUsage }
| { kind: "tool_calls"; calls: ToolCall[]; usage?: TokenUsage };
工具也不会只是一个函数：
type ToolDefinition = {
name: string;
version: string;
description: string;
inputSchema: ObjectSchema;
risk: RiskLevel;
parallelSafe: boolean;
source: "local" | "mcp";
outputPolicy: {
maxChars: number;
modelSummary: "full" | "head_tail" | "summary_only";
};
execute(input: unknown, context: ToolContext): Promise<ToolResult>;
};
这不是为了和官方能力对着干。
恰好相反。
只有内部边界稳定，外部 provider 才能随时换。OpenAI 的工具事件、Claude 的 client/server tools、Gemini 的 function calling、MCP 的 tools/list，都可以适配进来。
Runtime 不应该被某个 provider 字段绑死。
最后的判断
Agent Framework 会被模型原生 Tool Use 淘汰吗？
我的答案：
浅层框架会被挤压。
真正的 Runtime 不会。
模型会越来越会'提出行动'。
Runtime 要越来越会'管理行动'。
这就是分工。
