从 Prompt Engineering 到 Function CallingAI 开发范式的演变引言如果你在两年前问一个 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 取得了很多成果但它的先天缺陷很快显现出来问题表现影响脆弱性改一个词导致输出质量骤降维护成本极高不可测试prompt 效果难以自动化验证每次模型升级都可能崩缺乏结构所有逻辑都塞在自然语言里无法做单元测试和版本控制上下文窗口压力复杂的 prompt 很占 token成本高、推理慢工具脱节模型只能输出文本无法操作外部系统能力天花板明显我一个朋友维护了一个 3000 词的 prompt每次 GPT 更新都要重新调试。后来他发现——还不如直接把逻辑写到代码里让模型只做它擅长的事情。二、Function CallingAI 开发的 2.0 阶段2.1 Function Calling 是什么Function Calling也叫 Tool Use 或 Tool Calling是 OpenAI 在 2023 年 6 月率先推出的能力。它的核心思想很简单让模型输出结构化的函数调用参数而不是自由文本。开发者预先定义好一系列「工具」函数LLM 根据用户输入决定调用哪个工具、传什么参数然后系统执行工具把结果返回给 LLM 继续推理。2.2 与 Prompt Engineering 的本质区别维度Prompt EngineeringFunction Calling输出形式自然语言文本结构化 JSON 调用可测试性低语义匹配高精确匹配参数工具交互不支持原生支持逻辑归属在 prompt 里在代码里鲁棒性脆弱稳定版本控制困难与代码一起 git 管理2.3 Function Calling 带来的范式转换从「教模型回答」到「帮模型行动」在旧范式下你需要精心设计 prompt 让模型输出格式化内容然后自己写正则或 JSON 解析去提取。这中间充满了各种 edge case——模型偶尔输出多余解释、JSON 格式不对、字段名字拼错……在新范式下你只需要定义好函数的签名和描述模型会自动决定何时调用哪个函数并且返回的参数保证符合 JSON Schemastructured output 进一步保证了这一点。三、从工具到 AgentFunction Calling 的进阶之路3.1 单一工具 → 工具组合Function Calling 的真正威力不在于单个函数调用而在于工具的组合与编排。一个典型的 Agent 工作流可能是1. 用户提问 → LLM 决定调用search_knowledge_base2. 获得搜索结果 → LLM 决定调用get_product_details3. 拿到产品数据 → LLM 决定调用compute_price含折扣逻辑4. 得到最终价格 → LLM 用自然语言组织回答这个过程被称为ReActReasoning Acting循环。每一次函数调用结果都回到 LLM 的上下文里让它继续推理——这正是 Agent 架构的雏形。3.2 Multi-Agent 与分工当工具数量超过一定阈值比如 30单一 Agent 管理所有工具变得困难。于是出现了多 Agent 架构Orchestrator Agent理解用户意图分派任务Specialist Agent每个 Agent 负责一组相关工具Guard Agent安全审查防止工具被滥用3.3 MCP 协议工具发现的标准化2024 年底Anthropic 推出了MCPModel 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 WorkflowFunction Calling 是 Agent 架构的基础设施。接下来的演进方向是从「单次调用」到「持续运行的自主 Agent」模型不再是一次请求-响应而是持续运行的工作进程工具调用不再是「问一下 - 调一下」而是「设定目标 - 自主规划 - 多步执行 - 自我纠错」人机协作从「人在回路中」变为「人在回路之上」5.2 对开发者的影响这个范式演变对开发者提出了新要求不再是写好 prompt 就够了——你需要懂系统设计、API 设计、错误处理从 prompt 工程师到 AI 系统工程师——工作重心从怎么写转向怎么架构AI 编程工具正在改变写代码的方式——Cursor、Claude Code 等工具让 AI 直接写代码开发者转向审阅和架构设计一个有趣的现象2023 年最火的职位是 Prompt Engineer2025-2026 年最火的是 AI Agent Engineer。这本身就很说明问题。结语从 Prompt Engineering 到 Function Calling 的演变本质上是 AI 应用开发从「艺术」走向「工程」的过程。Prompt 像是一门玄学——同样的输入在不同模型、不同温度下表现天差地别。而 Function Calling 提供了接口、类型、错误处理这些软件工程的核心要素让 AI 应用变得可测试、可维护、可演进。当然这并不意味着 prompt 不再重要。恰恰相反——好的 function 描述本质上也是一种 prompt它在模型决定「要不要调用这个工具」时起着关键作用。范式变了但核心的沟通能力不会过时。未来已来只是分布不均。如果你还在纯靠 prompt 做 AI 应用现在就是切换到 Function Calling 范式的最佳时机。
