《Agent Runtime 工程化》Agent Framework 会被模型原生 Tool Use 淘汰吗？

模型 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 要越来越会'管理行动'。

这就是分工。

推荐阅读

• MCP 解决了什么，又没有解决什么？
• Agent Memory 应该放在 Runtime 还是 Application？
• Sandbox 应该属于 Harness 还是 Runtime？