一、什么是 Function Calling（一句话版）

Function Calling 是一种机制：

让大模型不直接输出自然语言答案，而是结构化地“决定是否调用某个函数 + 给出函数参数”，再由外部程序真正执行这个函数。

👉 本质：
LLM 负责“理解与决策”，程序负责“执行与落地”。

二、为什么需要 Function Calling？（没有它的问题）

如果没有 function calling，大模型只能：

输出 文本

靠你用正则 / prompt 去解析

不可靠、不稳定、不可控

例如你问：

“帮我在这个场景里加一棵 5 米高、随风摆动的树”

❌ 纯文本模型只能输出描述
✅ 你真正想要的是：

{
“action”: “add_object”,
“type”: “tree”,
“height”: 5,
“dynamic”: “wind”
}

👉 Function Calling 就是为了解决：
“从语言 → 可执行结构”这一步。

三、Function Calling 的核心思想（非常重要）
🔑 核心不是“调用函数”

而是：

把“工具接口”变成大模型的“可选动作空间”

而MCP是系统层的协议

作用是使得工具被“标准化地”暴露给模1型

---

一句话结论（先记住这个）

Function Calling 是“模型层的能力”
MCP（Model Context Protocol）是“系统层的协议”

它们是上下游关系，不是竞争关系。

---

一张“认知地图”（先在脑子里放好）

┌────────────┐
│   LLM      │
│ (Reasoning)│
└─────┬──────┘
      │  ← Function Calling（模型如何“表达要用什么工具”）
      ▼
┌────────────┐
│ Tool Call  │   ← 结构化 JSON
└─────┬──────┘
      │  ← MCP（工具如何“被发现 / 被描述 / 被调用”）
      ▼
┌────────────┐
│ Tools /    │
│ World APIs │
└────────────┘

---

二、先把 Function Calling 定位清楚

Function Calling 解决的核心问题是：

模型如何“决定 + 表达”一次工具调用

它关注的是：

• 模型输出什么格式？
• 如何从自然语言 → 结构化 action？
• 如何保证参数是可解析的？

👉 它是“认知层 / 决策层”的问题

---

三、那 MCP 到底解决什么问题？

MCP（Model Context Protocol）解决的是另一个维度：

工具如何被“标准化地”暴露给模型

它关注的是：

• 工具有哪些？
• 工具怎么被发现？
• 参数 schema 是什么？
• 返回结果怎么组织？
• 多工具、多进程、跨语言怎么统一？

👉 它是“系统工程层 / 基础设施层”的问题

---

四、一个非常直观的类比（强烈推荐）

用“人 + API 文档”来类比

❌ 没有 MCP 的世界

• 你每个项目都要：

  • 手写 prompt
  • 手写函数描述
  • 手写 JSON schema
  • 手写 tool routing

Function Calling 用得很痛苦。

---

✅ 有 MCP 的世界

• MCP Server = 自动生成、维护、暴露工具接口

• MCP Client = 把工具信息注入给模型

• 模型只管：

  • 理解意图
  • 选择工具
  • 生成参数

👉 MCP = “工具的 USB-C 接口标准”

---

五、两者的关系，用一句工程化的话说

Function Calling 是“语法”
MCP 是“协议 + 运行时”

维度	Function Calling	MCP
层级	模型输出层	系统集成层
关注点	怎么“表示一次调用”	怎么“组织和管理工具”
是否执行	❌ 不执行	✅ 负责执行
是否标准化	模型相关	跨模型 / 跨工具
是否可扩展	有限	强

---

六、放到 Agent / 世界模型框架里看（重要）

你现在做的是：

• 世界模型
• 场景编辑
• 动态物体
• 闭环仿真

没 MCP，你的系统会变成这样：

LLM
 ├─ if user says A → call tool A
 ├─ if user says B → call tool B
 ├─ if tool changes → 改 prompt

👉 强耦合，几乎不可维护

---

有 MCP 之后（这才是正确姿势）

World Editor MCP Server
  ├─ add_tree
  ├─ edit_terrain
  ├─ set_wind_field
  ├─ simulate_water
  └─ query_scene_state

LLM Agent
  └─ 通过 MCP 自动“看到”这些能力

模型根本不关心：

• 工具是 Python / C++ / ROS / Unity
• 场景是 3DGS / NeRF / Diffusion
• 是街景还是非结构化环境

👉 这正是你想要的 unified abstraction

---

七、一个非常关键、但很多人没意识到的点

Function Calling 可以没有 MCP
但 MCP 的“认知接口”几乎一定依赖 Function Calling

原因很简单：

• MCP 需要模型：

  • 理解工具
  • 选择工具
  • 生成参数

👉 这一步唯一成熟、稳定的方式，就是 Function Calling

---

八、用一句“架构级”的总结送给你

Function Calling = LLM 的 Action Head
MCP = 世界模型的 Action Space 定义

这和你在研究的：

• 动态占比
• 不同场景的可编辑性
• 世界模型的控制接口

是完全同构的问题。

---

九、如果你愿意，下一步我可以直接帮你做一件“实事”

比如：

• 给你设计一个 World Model 的 MCP Server

• 定义一套：

  • 静态结构
  • 动态物体
  • 非结构化要素（树 / 草 / 水 / 泥）

• 并明确：

  • 哪些能力暴露给 LLM
  • 哪些只留在底层 simulator