从 Prompt Engineering 到 Function Calling：AI 开发范式的演变

从 Prompt Engineering 到 Function Calling：AI 开发范式的演变

引言

如果你在两年前问一个 AI 开发者："你在做什么？"，回答很可能是"我在写 prompt"。而在今天，同样的问题，你更可能听到"我在搭建 Agent"或"我在设计和编排 function call 的链路"。

这不仅仅是术语的变化，而是整个 AI 应用开发范式的根本性迁移——从「教 AI 如何回答」到「教 AI 如何行动」。本文将完整梳理这一演变的脉络、技术原理以及实际开发中的最佳实践。

一、Prompt Engineering 时代：AI 开发的 1.0 阶段

1.1 什么是 Prompt Engineering

在 GPT-3.5 和早期 GPT-4 时期，开发者和 LLM 交互的唯一通道就是自然语言提示词（prompt）。你想让模型做什么，就需要在 prompt 里把指令写清楚。这催生了一整套 prompt engineering 的方法论：

• 角色设定（Role Prompting）："你是一个资深 Python 工程师..."
• 思维链（Chain-of-Thought）："让我们一步一步思考..."
• Few-shot 示例：在 prompt 中给出 2-3 个输入输出样例
• 格式约束："请以 JSON 格式输出..."

1.2 Prompt Engineering 的局限性

虽然 prompt engineering 取得了很多成果，但它的先天缺陷很快显现出来：

我一个朋友维护了一个 3000 词的 prompt，每次 GPT 更新都要重新调试。后来他发现——还不如直接把逻辑写到代码里，让模型只做它擅长的事情。

二、Function Calling：AI 开发的 2.0 阶段

2.1 Function Calling 是什么

Function Calling（也叫 Tool Use 或 Tool Calling）是 OpenAI 在 2023 年 6 月率先推出的能力。它的核心思想很简单：让模型输出结构化的函数调用参数，而不是自由文本。

开发者预先定义好一系列「工具」（函数），LLM 根据用户输入决定调用哪个工具、传什么参数，然后系统执行工具，把结果返回给 LLM 继续推理。

2.2 与 Prompt Engineering 的本质区别

2.3 Function Calling 带来的范式转换

从「教模型回答」到「帮模型行动」：

在旧范式下，你需要精心设计 prompt 让模型输出格式化内容，然后自己写正则或 JSON 解析去提取。这中间充满了各种 edge case——模型偶尔输出多余解释、JSON 格式不对、字段名字拼错……

在新范式下，你只需要定义好函数的签名和描述，模型会自动决定何时调用哪个函数，并且返回的参数保证符合 JSON Schema（structured output 进一步保证了这一点）。

三、从工具到 Agent：Function Calling 的进阶之路

3.1 单一工具 → 工具组合

Function Calling 的真正威力不在于单个函数调用，而在于工具的组合与编排。一个典型的 Agent 工作流可能是：

1. 用户提问 → LLM 决定调用search_knowledge_base

2. 获得搜索结果 → LLM 决定调用get_product_details

3. 拿到产品数据 → LLM 决定调用compute_price（含折扣逻辑）

4. 得到最终价格 → LLM 用自然语言组织回答

这个过程被称为ReAct（Reasoning + Acting）循环。每一次函数调用结果都回到 LLM 的上下文里，让它继续推理——这正是 Agent 架构的雏形。

3.2 Multi-Agent 与分工

当工具数量超过一定阈值（比如 30+），单一 Agent 管理所有工具变得困难。于是出现了多 Agent 架构：

• Orchestrator Agent：理解用户意图，分派任务
• Specialist Agent：每个 Agent 负责一组相关工具
• Guard Agent：安全审查，防止工具被滥用

3.3 MCP 协议：工具发现的标准化

2024 年底，Anthropic 推出了MCP（Model Context Protocol），为 AI Agent 提供了一套标准化的工具发现和调用协议。这相当于 AI 世界的「USB 接口」——任何实现了 MCP server 的外部系统，Agent 都可以自动发现并使用它的能力。

MCP 对 Function Calling 的增强体现在：

• 动态发现：Agent 启动时自动获取可用工具列表，无需硬编码
• 标准化接口：所有工具统一通过 JSON-RPC 调用
• 资源管理：支持文件、数据库、API 等不同类型的资源访问

四、开发实践：如何选择范式

4.1 什么时候用 Prompt Engineering

尽管 Function Calling 更强大，但 Prompt Engineering 在以下场景依然有价值：

• 简单文本生成：翻译、摘要、润色，prompt 足够
• 快速原型验证：不需要工具交互的场景
• 需要高度定制输出风格：用 prompt 控制语气比代码更灵活

4.2 什么时候用 Function Calling

• 需要操作外部系统：查数据库、调 API、发邮件
• 结构化输出要求：需要验证参数、保证输出格式
• 多步骤推理：任务需要多步决策和工具链
• 高可靠性场景：生产环境，函数签名就是类型保障

4.3 混合范式

最实用的做法是混合使用两种范式：

先让模型判断意图，如果是纯对话场景用 prompt 就够了；如果需要操作工具的场景，用 function calling；如果先用 tool 获取信息，再用 prompt 优化表达，则两者结合使用。

五、未来展望

5.1 从 Function Calling 到 Agentic Workflow

Function Calling 是 Agent 架构的基础设施。接下来的演进方向是从「单次调用」到「持续运行的自主 Agent」：

• 模型不再是一次请求-响应，而是持续运行的工作进程
• 工具调用不再是「问一下 -> 调一下」，而是「设定目标 -> 自主规划 -> 多步执行 -> 自我纠错」
• 人机协作从「人在回路中」变为「人在回路之上」

5.2 对开发者的影响

这个范式演变对开发者提出了新要求：

• 不再是写好 prompt 就够了——你需要懂系统设计、API 设计、错误处理
• 从 prompt 工程师到 AI 系统工程师——工作重心从"怎么写"转向"怎么架构"
• AI 编程工具正在改变写代码的方式——Cursor、Claude Code 等工具让 AI 直接写代码，开发者转向审阅和架构设计

一个有趣的现象：2023 年最火的职位是 Prompt Engineer，2025-2026 年最火的是 AI Agent Engineer。这本身就很说明问题。

结语

从 Prompt Engineering 到 Function Calling 的演变，本质上是 AI 应用开发从「艺术」走向「工程」的过程。Prompt 像是一门玄学——同样的输入在不同模型、不同温度下表现天差地别。而 Function Calling 提供了接口、类型、错误处理这些软件工程的核心要素，让 AI 应用变得可测试、可维护、可演进。

当然，这并不意味着 prompt 不再重要。恰恰相反——好的 function 描述本质上也是一种 prompt，它在模型决定「要不要调用这个工具」时起着关键作用。范式变了，但核心的沟通能力不会过时。

未来已来，只是分布不均。如果你还在纯靠 prompt 做 AI 应用，现在就是切换到 Function Calling 范式的最佳时机。