别再让 LLM 硬猜实时数据了，给它配上“手”才是正解
很多开发者在做 AI 应用时会陷入一个误区：试图通过提示词让模型记住一切。但实际上，无论模型参数量多大，它本质上只是个“大脑”，没有实时联网能力，更没法算准复杂的数学题。
下一篇
GPT 5.6 的逻辑变了：从追求“单体天才”转向“智能体集群” →
我在研究生产环境下的 RAG 和 Tool Use 时发现，一个成熟的系统架构逻辑应该是：LLM 负责推理和构造参数，而你的业务代码负责执行。
这就是所谓的 Function Calling（工具调用）。模型本身并不执行代码，它只负责输出一个结构化的 JSON 请求。比如用户问“东京现在多少度”，模型识别到意图后，会输出类似下面的指令，剩下的脏活累活交给你的后端去跑。
具体的工具定义 Schema 逻辑大致如下：
{
"name": "get_weather",
"description": "获取指定城市的实时天气数据",
"parameters": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "城市名称，例如 Tokyo"
}
},
"required": ["city"]
}
}核心逻辑在于这个闭环：
1. 你把工具的描述（Name + Description + Schema）喂给模型。
2. 模型判断是否需要调用，并生成 tool_use 消息。
3. 你的应用拦截到这个 JSON，去调 API 或数据库。
4. 把 API 返回的真实结果再喂回给模型。
如果你在做 10M 级别文档的 RAG 系统，单纯靠向量检索（Dense Retrieval）是不够的，必须引入 Hybrid Search（混合检索）和 Reranking（重排序）环节，否则检索质量会直接拖垮整个推理链路。对于追求工程效率的开发者来说，理解这种“模型决策 + 代码执行”的分工，比研究怎么写更长的 Prompt 要重要得多。
promptcube3.com
