0
从模型到外部世界：API、工具与函数调用
学完你能做到
- 复习大模型为什么不能直接碰到外部世界
- 能用自己的话解释什么是 API
- 明白"给模型接上工具"是什么意思
前面的第 0 阶段已经解释了 AI、LLM、幻觉和上下文。这一节只解决一个问题：模型如何在不直接拥有网络和数据库权限的前提下，安全地请求外部世界帮助。
一、大模型是什么
先建立直觉
想象一个读过很多书、很会组织语言的顾问。每次见面时,他只能看到你这次递给他的资料包。房间里没有窗户、电话和长期笔记本;如果应用不给他接搜索、计算器和会话记录,他就无法可靠知道外面的实时情况,也不会自动记得上一次见面。
常见误解
大模型会上网查资料,所以它知道最新的消息。
实际上
不要把产品能力直接等同于模型能力。你在某些产品里看到它引用网页,通常是产品在模型外面接了搜索工具——先替它搜,把搜到的内容塞进提示词,再让它回答。这正是本课要讲的"工具"。
二、API 是什么
先建立直觉
餐厅的菜单就是 API。你不需要知道厨房里怎么切菜、火开多大,只要按菜单上写的名字点菜,厨房就会给你出对应的菜。
菜单规定了三件事:能点什么、怎么点、会给你什么。
三、"给模型接上工具"是什么意思
先建立直觉
还是那个被关在房间里的人。你在墙上开了几个小窗口,每个窗口贴张纸条:
「窗口 A:写个城市名递进来,我给你那里的天气」
「窗口 B:写个算式递进来,我给你答案」
现在他被问"北京比上海热多少度"时,就知道该往 A 窗口递两次纸条,拿到两个温度,再往 B 窗口递一次算减法。
案例推演：天气问题如何从一句话变成一次安全工具调用
用户问“明早出门要带伞吗？”模型本身没有实时天气。应用必须把意图转成结构化参数，调用天气 API，再让模型基于真实结果解释。
本节追问：API、函数调用与模型生成各自负责哪一步？ 先不要急着看结论。沿着下面四步，逐项区分输入、决策、证据和失败信号。
| 阶段 | 本步要做的决定 | 什么算证据 | 最常见的失败 |
|---|---|---|---|
| 理解请求 | 提取地点、日期和用户真正关心的降雨风险 | 缺地点时先澄清而不是猜 | 从 IP 私自推断位置 |
| 构造调用 | 输出受 Schema 约束的地点与时间参数 | 参数类型和枚举通过校验 | 把整句自然语言直接拼入网址 |
| 执行工具 | 服务器携带密钥调用天气 API | 状态码、时间戳和原始结果可记录 | 把 API 密钥发送到浏览器或模型 |
| 解释结果 | 基于降雨概率与时段回答是否带伞 | 结论能指向工具返回字段 | 工具失败后编造晴雨 |
阅读方式：先遮住后两列自己回答，再用“证据”和“失败”两列检查理解。
常见误解
让模型直接回答实时天气
实际上
可观察症状：听起来合理，但没有当前观测依据。
更可靠的修复：没有工具结果就明确说明；工具成功后才生成结论。
案例工作坊 · 建议真正动手完成
25 分钟- 写出 weather 工具的最小输入与输出字段。
- 列举地点缺失、超时、API 限流三种失败响应。
- 说明密钥应该存在哪里，为什么。
查看参考答案
函数调用让模型提出结构化调用意图；应用验证并真正调用 API；API 返回外部事实；模型最后把事实转换为用户可理解的建议。
迁移检查：换一个场景还会不会
模型输出了合法的 weather 参数，是否等于已经查到天气？
检查一下
你问大模型"今天北京天气怎么样",它直接给了你一个温度。最可能的情况是?
下面哪个说法对"工具"的描述最准确?