长春网站建设优化排名wordpress主题调用插件

1. 序

  前段时间Manus的爆火让开发者们看到了大模型加持下的智能体操作外部工具的落地可行性，是很成功的一次尝试，很快开源版的OpenManus基本实现了Manus的大体功能，尝试了下效果不能说是惊艳，但还可以接受。后来一段时间结合项目对OpenManus进行魔改，也在Dify上进行了复现，基本达到了预期效果。
  本来想总结一下从Function Calling到MCP的技术路线，结果一拖再拖了三个月过去了，直到最近看到余总的一个小艺操作手机APP的Demo，才想起来还有个系列文章一直没有动工呢！
  《Function Callingの进化路》这个系列大概更新5~7篇博客，涉及到Function Calling、MCP、FC模型的训练及评估（论文）、GUI大模型（VLM+GUI）等，感兴趣的小伙伴们可以关注一下。

2. 前言

  在 AI 技术狂飙突进的今天，Function Calling（函数调用）已成为大模型连接现实世界的 “神经中枢”—— 它让 AI 从 “能说会道” 的对话者，变成了 “能做实事” 的行动者。但这个如今被频繁提及的技术概念，并非凭空出现。要理解它的进化，首先得回到故事的起点：当大模型第一次意识到 “自己做不到” 时，Function Calling 的种子便已埋下。

3. 大模型的 “能力天花板”：催生需求的原始动力

  2022 年前后，以 GPT-3 为代表的大语言模型（LLM）凭借惊人的对话流畅度和知识储备引发热潮，但开发者很快发现了一个致命局限：模型的 “认知” 被锁死在训练数据里。
  想象这样一个场景：当用户问 “上海今天的 PM2.5 指数是多少”，早期大模型最多能回答 “PM2.5 是衡量空气质量的指标”，却无法给出实时数据 —— 因为它的训练数据截止到某个时间点，且无法主动 “伸手” 获取外部信息。同样，当用户要求 “把最近 3 个月的订单数据生成折线图”，模型只能输出文字描述，无法调用 Excel 或数据可视化工具完成操作。
  更核心的矛盾在于：用户对 AI 的期待早已超越 “问答”。人们希望 AI 能订机票、查快递、控制智能家居，甚至调用企业内部系统处理工作流。这些需求的本质是 “让 AI 执行具体任务”，而任务的完成往往依赖外部工具（API 接口、数据库、软件插件等）。此时，大模型就像一个 “大脑发达但没有手脚” 的智者 —— 能思考，却无法行动。
  这种 “想做却做不到” 的困境，成了 Function Calling 的第一缕曙光：如果能让大模型学会 “调用工具”，不就能突破能力边界了吗？

4. 从 “手动对接” 到 “自动调用”：早期探索的蹒跚起步

  Function Calling 的雏形，始于开发者对 “工具调用” 的朴素尝试。2021 年前后，一些技术团队开始用 “硬编码” 的方式连接大模型与外部工具 —— 简单说，就是提前写好规则：当用户提问中出现 “天气” 关键词时，强制触发天气 API 调用；出现 “订单” 时，自动连接数据库查询。
  这种方式有明显的局限性：规则需要人工预设，无法应对复杂需求。比如用户问 “明天去北京出差，需要带伞吗？”，关键词里没有 “天气”，但实际需要调用天气 API 判断降水概率。硬编码规则会直接 “漏判”，导致 AI 给出无关回答。
  真正的突破，来自对 “模型自主性” 的探索。开发者意识到：与其人工定义触发条件，不如让大模型自己判断 “是否需要调用工具”以及“该调用哪个工具”。这就需要模型理解两个核心问题：​
  （1）我的现有知识能否回答这个问题？（不需要调用工具）
  （2）如果不能，需要调用哪个工具获取信息？（需要调用工具）
  2022 年底，OpenAI 在 GPT-3.5和ChatGPT 的测试中首次引入 “工具调用提示词”：通过在 Prompt 中明确告知模型 “可用工具列表及调用格式”，让模型尝试生成符合格式的调用指令。比如当用户问 “上海实时天气” 时，模型会输出类似{"name":"get_weather","parameters":{"city":"上海"}}的结构化指令 —— 这就是 Function Calling 的原始形态。
  此时的技术关键，在于自然语言到结构化指令的转化能力。早期模型经常 “词不达意”：要么生成的调用格式错误（比如少写参数），要么在不需要调用工具时强行调用（比如问 “地球自转周期” 却调用百科 API）。但这种尝试验证了一个核心逻辑：大模型可以通过学习，掌握 “调用工具” 的决策能力。

5. 标准化与场景落地：Function Calling 的 “破圈” 时刻

  2023 年，随着 GPT-4 的发布，Function Calling 迎来了标准化转折点。OpenAI 在 2023 年 6 月 13 日的 gpt-3.5-turbo-0613 和 gpt-4-0613 更新中，正式引入了 Function Calling 能力，将Function Calling纳入 API 接口，提供统一的调用规范：模型输出的工具调用指令将以固定 JSON 格式返回，开发者无需再手动解析自然语言，直接对接即可。

  整个流程分为3步，以“现在波士顿的天气”为例：

• Step 1：在调用模型时，需要在functions字段中定义函数，以告诉大模型有哪些函数可以调用，这个函数的功能是什么，有哪些参数等等。

curl https://api.openai.com/v1/chat/completions -u :$OPENAI_API_KEY -H 'Content-Type: application/json' -d '{"model": "gpt-3.5-turbo-0613","messages": [{"role": "user", "content": "What is the weather like in Boston?"}],"functions": [{"name": "get_current_weather","description": "Get the current weather in a given location","parameters": {"type": "object","properties": {"location": {"type": "string","description": "The city and state, e.g. San Francisco, CA"},"unit": {"type": "string","enum": ["celsius", "fahrenheit"]}},"required": ["location"]}}]
}'

  大模型的调用结果放在function_call字段中：

{"id": "chatcmpl-123",..."choices": [{"index": 0,"message": {"role": "assistant","content": null,"function_call": {"name": "get_current_weather","arguments": "{ \"location\": \"Boston, MA\"}"}},"finish_reason": "function_call"}]
}

• Step 2：根据大模型返回的函数名及参数来调用该函数，比如，在get_current_weather函数中可以调用第三方的天气查询服务：

# Request
curl https://weatherapi.com?city={location}...# Response
{ "temperature": 22, "unit": "celsius", "description": "Sunny" }

• Step 3：将函数调用的结果在传入给大模型，大模型会根据上下文信息做出准确的回复：

# Request
curl https://api.openai.com/v1/chat/completions -u :$OPENAI_API_KEY -H 'Content-Type: application/json' -d '{"model": "gpt-3.5-turbo-0613","messages": [{"role": "user", "content": "What is the weather like in Boston?"},{"role": "assistant", "content": null, "function_call": {"name": "get_current_weather", "arguments": "{ \"location\": \"Boston, MA\"}"}},{"role": "function", "name": "get_current_weather", "content": "{\"temperature\": "22", \"unit\": \"celsius\", \"description\": \"Sunny\"}"}],"functions": [{"name": "get_current_weather","description": "Get the current weather in a given location","parameters": {"type": "object","properties": {"location": {"type": "string","description": "The city and state, e.g. San Francisco, CA"},"unit": {"type": "string","enum": ["celsius", "fahrenheit"]}},"required": ["location"]}}]
}'# Response
{"id": "chatcmpl-123",..."choices": [{"index": 0,"message": {"role": "assistant","content": "The weather in Boston is currently sunny with a temperature of 22 degrees Celsius.",},"finish_reason": "stop"}]
}

  OpenAI这次模型的更新彻底降低了技术门槛，很快，一批场景开始落地：​
  （1）生活服务：ChatGPT 插件支持调用外卖平台 API，用户说 “今晚想吃川菜，帮我点一份微辣的”，模型会自动调用接口完成下单；
  （2）办公效率：Notion AI 通过 Function Calling 连接企业邮箱，用户指令 “把上周的客户邮件整理成表格” 可直接触发邮件获取与格式转换；
  （3）工业场景：某制造业 AI 系统调用设备传感器 API，当用户问 “生产线 3 号机床的运行温度” 时，实时返回监测数据。
  这些场景的共性，在于让 AI 从 “信息传递者” 变成 “流程执行者”。而支撑这一转变的，是模型能力的提升：GPT-4 对 “工具必要性” 的判断准确率从早期的 60% 提升至 85% 以上，对复杂工具（如需要多参数的支付 API）的调用错误率大幅下降。
  值得注意的是，Function Calling 的源起并非单一技术的突破，而是需求、模型能力、工程落地三者的共振：用户需要 AI 解决实际问题（需求），大模型具备理解与决策能力（基础），标准化接口降低开发成本（落地）。这三个条件凑齐的那一刻，Function Calling 才算真正 “诞生”。

6. 结束语

  如今再看 Function Calling 的源起，本质是大模型发展的必然 —— 当对话能力走到极致，“行动能力” 就成了下一个突破口。而早期的局限、探索与标准化，共同构成了这条进化路的第一块基石。
  接下来，Function Calling 将走向何方？是更智能的多工具协同？还是与多模态模型的深度融合？在 “源起篇” 之后，我们将继续追踪它的进化轨迹。但无论未来如何，回望 2022-2023 年那段从0到1的探索，或许能更清晰地理解：每一项技术的爆发，都始于对 “不完美” 的突破。

---

相关文章：Function calling and other API updates