从一个 add 函数理解 Function Calling：模型并不负责执行代码

最早给自己定的目标很小

旧笔记的原句是：

写一个自己的 add 函数，让 codex 调用

看起来只是两个数字相加，但它帮我区分了两件此前容易混淆的事：模型返回工具调用的意图，以及自己控制的运行时真正执行函数。

当时让 AI 给出了一份 add 函数与调用示例，并按流程模拟一段会话：应用先提交消息与可用工具定义，模型返回函数名和参数，应用执行函数，再把结果交还模型，由模型生成最终回复。

这次只是用一个 add 函数模拟 Function Calling 的完整调用链，并不是部署一套 Agent 服务。但通过这个小例子，我开始明白模型负责提出工具调用，应用才负责实际执行。

真正的理解发生在“谁来执行”这里

我从示例中记下的结论是：Function Calling 需要一层自己控制的 Runtime。它不一定要是一个大型 Agent 框架，也可能只是几十行 Python 或 Node 代码。

同样的思想放到查询天气：模型可以提出需要调用天气工具并提供参数，但请求是由应用执行；最终结果仍由应用接收后再回传给模型。

模型会选择，不等于模型已经替我在机器上运行。 尤其涉及文件、网络或有副作用的工具时，实际授权、校验和执行责任仍然属于应用运行时。

工具越来越多怎么办

最初还问了一个问题：如果聊天应用有成百上千个工具，是否每轮都要把所有 Function 定义交给模型？

旧笔记给出的思考方向是先按领域分层、按需暴露相关工具，再引入工具注册表或 MCP 等能力入口。具体 API 与模型能力会随着平台更新，但“不要默认把全部工具平铺进每轮上下文”这一工程判断仍值得保留。

这篇记录的是学习和概念转折，不是声称已经完成大规模工具注册系统。