Prompt学习五：从工具调用到上下文工程

发表于 分类于 Disqus：

前四篇我一直在往同一个方向推进：先把任务说清楚，再把输出收窄，再把返回结构定义清楚，再学会把复杂任务拆成流程。但继续往下学，很快就会发现一个新的问题：当模型不只是回答问题，而是要调用工具、读取上下文、访问外部知识、在多个步骤里持续动作时，Prompt 还只是“写一句话”吗？

学完 Function Calling，又继续看 AI Workflows、AI Agents、Context Engineering 和 RAG 相关内容之后，我越来越强烈地感觉到：到了这一步，Prompt 已经不只是输入设计，也不只是接口设计，而是在逐渐变成一种系统上下文设计能力。

Function Calling 不是终点，而是系统协作的起点

一开始学 Function Calling，很容易把重点放在这件事本身：

  • 模型能不能选对工具
  • 参数能不能传对
  • JSON 结构稳不稳定

这些当然都重要，但如果只停在这里，理解还是会偏浅。

因为从工程角度看，Function Calling 真正打开的，不是“模型多了个功能”，而是下面这条链路：

  1. 用户用自然语言表达意图
  2. 模型根据上下文判断是否需要外部能力
  3. 模型产出工具调用意图和参数
  4. 程序执行真实工具
  5. 工具返回结果，再进入下一步判断或回答

这意味着，从这里开始，模型已经不再只是生成文本，而是在一个更完整的系统回路里工作了。

如果换成更熟悉的软件工程语言，这一步更像是：

  • LLM 不再只是“渲染答案”
  • 它开始参与“调度动作”
  • 而 Prompt / Tool Definition / Context 则一起构成了它的运行环境

所以到这里，我会把 Function Calling 理解成：

它不是给模型加一个技巧，而是在把模型接入系统协作。

Function Call 和 Tool Call 到底有什么区别

这一部分里，我也专门停下来理了一次这个问题。因为在不同平台、不同文档里，你会同时看到 function calling 和 tool calling 两种说法，如果不主动分清楚，很容易以为它们完全等价。

我后来把这两个词的关系慢慢理成了这样：

Function Call 更像 Tool Call 的一个子集。

也就是说：

  • Function Call：通常特指模型去调用一个“函数式接口”——名字、描述、参数 schema 都比较清晰，输出也是结构化的。
  • Tool Call：是一个更大的概念，只要模型在运行过程中要借助外部能力，都可以算 tool call。

从这个角度看，天气查询、搜索、数据库查询、代码执行、网页浏览、知识检索，这些都可以叫 tool use / tool call；而其中那些以函数签名、JSON schema、参数对象形式暴露给模型的能力，通常又会被单独叫作 function call。

如果一定要再说得直白一点：

  • Function Call 强调的是“接口形态”
  • Tool Call 强调的是“系统行为”

前者更像在说：

这个外部能力是如何定义给模型看的。

后者更像在说：

模型在完成任务时，是否要借助外部能力采取动作。

为什么现在越来越多人更常说 Tool Call

这里其实有一个很自然的变化。

如果系统能力还比较简单，只有几个结构化函数，那讲 Function Calling 没问题，因为你面对的确实就是一组函数定义。

但一旦系统开始变复杂，模型能接触到的外部能力就不再只是狭义上的 function：

  • 检索工具
  • 浏览器操作
  • 代码执行环境
  • 数据库查询
  • MCP 暴露出的能力
  • 其他 agent 也可能被当成“工具”使用

这时候再全部叫 Function Calling，就会有点窄了。

因为系统关心的重点，已经不只是“有没有函数 schema”，而是：

  • 模型什么时候该调用外部能力
  • 应该调用哪一种能力
  • 调用后如何把结果回注到上下文
  • 下一步是继续调用，还是结束回答

到了这一步，用 Tool Call / Tool Use 来描述会更准确。因为它更贴近系统视角，而不是某一种接口封装方式。

那第五篇为什么还从 Function Calling 讲起

因为对学习路径来说，Function Calling 仍然是一个很好的入口。

它有几个优势：

  • 边界清楚
  • 输入输出容易结构化
  • 很适合理解参数 schema 和工具描述
  • 很适合理解 action / observation 这条基本回路

也就是说，Function Calling 很适合拿来建立第一层工程直觉：

  • 工具是怎么被定义的
  • 模型为什么会选这个工具
  • 参数为什么会填错
  • 工具结果为什么会影响下一步行为

但继续往后学，就要把视角从 Function Calling 扩展到 Tool Calling。因为真实系统里，你设计的已经不是单个函数，而是一整套外部能力如何被模型安全、准确、低成本地使用。

如果用一句话把两者关系说清楚，大概就是：

Function Calling 帮我理解了模型如何调用一个定义良好的接口；Tool Calling 则让我开始理解模型如何在系统里使用外部能力。

真正难的地方，不是“会不会调工具”，而是“上下文给得对不对”

如果只看最简单的天气查询例子，Function Calling 好像很好理解：用户问天气，模型调用天气工具，结果返回给用户。

但真实场景一复杂，问题就不在“能不能调用工具”，而在：

  • 模型知不知道什么时候该用哪个工具
  • 它拿到的当前上下文够不够做决策
  • 哪些历史信息应该保留，哪些应该丢掉
  • 工具描述是不是足够清楚
  • 工具结果回来之后，要不要继续下一步动作

也就是说，Function Calling 背后真正难的，不是调用动作本身，而是：

你到底给了模型什么信息，让它有能力在当前这一步做出合理决策。

这也是我开始真正理解“上下文工程”为什么重要的地方。

因为很多时候，系统表现不好，并不是模型不会，也不是工具不行，而是上下文设计出了问题：

  • 规则太少，模型自由发挥过度
  • 规则太多，模型变得僵硬
  • 该给的背景没给
  • 不该塞进去的噪声塞太多
  • 历史状态混乱，导致模型每一步都在错误前提上继续推理

所以学到这里之后，我对 Prompt 的理解又往前推进了一步：

Prompt 不只是“怎么说”，而是“给模型看什么、在什么时候给、给多少、给到哪一层”。

什么叫上下文工程

如果用一句最朴素的话概括，上下文工程就是：

为了让模型在当前任务里表现更稳定、更准确、更可控，去主动设计和管理它能看到的全部信息。

这里的“上下文”已经不只是 system prompt 里那一段规则文字了。它通常包括：

  • system prompt
  • 当前任务指令
  • 用户输入
  • few-shot 示例
  • 工具定义
  • 工具返回结果
  • 历史状态
  • 外部检索得到的知识
  • 当前日期、角色、环境约束等动态信息

也就是说，从这一步开始，Prompt 已经升级成了一个更大的问题：

  • 什么信息应该常驻？
  • 什么信息只在这一轮注入？
  • 什么信息应该通过工具获取，而不是直接塞进 Prompt？
  • 什么信息应该结构化表达？
  • 什么信息如果继续保留，只会污染模型判断？

这也是为什么我会觉得“上下文工程”这个词很贴切。它强调的已经不是一句 Prompt 的写法，而是整套信息架构。

这时，Workflow 和 AI Agent 的区别才真正变得重要

在前一篇里，我已经写过 Prompt Chaining，也就是把复杂任务拆成多个步骤。继续往后学的时候，一个特别重要的变化就是：

你开始不只是在拆 Prompt，而是在选择系统应该做成 Workflow，还是做成 Agent。

我现在会把两者的区别理解成这样：

Workflow

Workflow 的特点是：

  • 路径是预先定义好的
  • 哪一步先做、哪一步后做，基本由代码决定
  • 模型只负责完成某个局部任务
  • 系统整体更可控、更稳定、更容易调试

比如：

  1. 先分类用户请求
  2. 再路由到对应处理链路
  3. 再生成结构化输出
  4. 最后经过校验后返回

这类系统更像“固定流程”。

AI Agent

AI Agent 的特点是：

  • 步骤不一定提前写死
  • 模型自己决定要不要调用工具、调用哪个工具、下一步做什么
  • 系统更灵活，但也更难预测
  • 对上下文质量、工具设计和可观测性要求更高

比如用户说：

帮我整理最近 OpenAI 的开发动态，并给出可能影响前端工程师的点。

这时 Agent 可能会自己决定：

  • 先做 web search
  • 再整理结果
  • 再判断哪些信息和前端工程师有关
  • 再输出摘要

也就是说，Workflow 和 Agent 的差别，不只是“是不是更高级”，而是：

决策权更多掌握在代码里，还是更多交给模型。

我现在会怎么判断：用 Workflow，还是用 Agent

这块内容里最有帮助的一点，不是记住定义，而是开始有判断标准。

我现在会先问下面几个问题：

  1. 任务步骤是否清楚、稳定、可预定义？
  2. 任务是否需要高可控性和高可调试性？
  3. 如果模型自由发挥过多，业务风险大不大？
  4. 这个任务是否经常出现开放式路径和动态选择？
  5. 工具调用顺序是否很难提前写死？

如果前面几个问题的答案偏向“是”，那更适合做 Workflow。

如果后面几个问题的答案偏向“是”，那才更适合做 Agent。

所以我越来越觉得，很多团队一开始就想做 Agent，其实有点像还没把流程设计清楚，就急着把控制权交给模型。

从工程角度看，更稳妥的路径通常是：

先把能 Workflow 化的部分 Workflow 化，再把真的需要动态决策的部分交给 Agent。

这其实也是一种上下文工程思想。因为你本质上是在决定：模型应该在哪些边界内拥有自由度。

RAG 不只是知识库问答，而是上下文供给方式

继续往后看时，我越来越觉得，如果只把 RAG 单独理解成“做个知识库问答”，其实会低估它在系统里的位置。

在我看来，把 RAG 放在上下文工程里理解会更顺：

RAG 的本质，不只是检索，而是在运行时为模型补充当前任务真正需要的外部知识。

这个理解很关键。

因为模型的参数知识是静态的，而很多任务需要的却是：

  • 最新信息
  • 私有文档
  • 业务规则
  • 历史记录
  • 项目上下文

这时候，如果把所有资料都硬塞进 Prompt，不仅放不下，而且噪声会越来越大。RAG 的价值就在这里：

  • 先根据问题检索相关内容
  • 再把这部分内容作为上下文送给模型
  • 让模型基于“当前最相关的信息”来回答或行动

所以 RAG 在系统里真正解决的，不是“让模型变聪明”，而是：

让模型在当前这一步，看到它真正需要看到的信息。

从这个角度看，RAG 本质上也是上下文工程的一部分。

把 RAG 放进 Workflow 和 Agent 里，会看到更清楚的区别

RAG 放在不同系统里，角色其实不一样。

在 Workflow 里

RAG 更像一个固定步骤：

  1. 接收问题
  2. 检索相关文档
  3. 拼接上下文
  4. 基于上下文生成回答

这个流程清楚、稳定、容易评估。很适合：

  • 文档问答
  • FAQ
  • 内部知识检索
  • 有固定输入输出边界的场景

在 Agent 里

RAG 更像一个“可选工具”：

  • 模型自己判断是否需要检索
  • 检索一次不够，可能继续检索第二次
  • 也可能先调用别的工具，再回来补检索

这时候，RAG 不再只是一个固定节点，而是系统动作链的一部分。

这种设计更灵活，但也更难：

  • 工具描述要清楚
  • 何时检索要清楚
  • 检索结果怎么回到上下文要清楚
  • 如果检索失败或证据不足，行为边界也要清楚

也就是说，把 RAG 放进 Agent 之后，问题就不再只是“召回准不准”，而是整个上下文回路是否健康。

一个越来越清楚的主线：Prompt 正在升级成“上下文操作系统”

把这些内容串起来之后，我最大的体感是：

  • 第一阶段前面几篇更像在学“怎么写 Prompt”
  • 到了这一篇，开始真正进入“怎么组织模型工作的环境”

Function Calling 让模型可以接触外部能力；
Workflow 帮你把稳定流程写死；
Agent 让模型拥有有限度的动态决策权；
RAG 让系统在运行时补充外部知识；
而 Context Engineering 则在更高一层上，决定这一切该怎样组合。

如果一定要给这一块找一个核心问题，我会把它写成：

当模型已经不只是回答，而是在一个系统里持续决策、持续调用、持续读取上下文时，你怎么设计它所处的整个信息环境？

这就是我理解的这一阶段真正主题。

我现在会怎么验收这类系统设计

学完这部分之后，我判断一个方案是否靠谱，关注点已经不只是 Prompt 写得好不好，而会变成这些问题：

  • 工具定义是否真的足够清楚？
  • 模型是否知道什么时候该调用工具，什么时候不该？
  • 上下文是越堆越多，还是按需注入？
  • 历史状态和当前任务有没有混淆？
  • 这个场景究竟更适合 Workflow 还是 Agent？
  • RAG 注入的信息，是否真的和当前任务相关？
  • 如果系统出错，我能不能定位是 Prompt、工具、检索还是上下文拼装的问题？

这些问题一旦问出来，你就会发现：

AI 应用开发到了这里，已经越来越像系统工程，而不是 Prompt 小技巧。

结语

第一篇我把 Prompt 理解成结构化表达，第二篇开始理解输出稳定性，第三篇开始定义接口，第四篇开始拆流程。到了第五篇，我真正开始意识到：

当模型开始调用工具、访问知识、管理状态并在多步链路里行动时，你真正设计的，已经不只是 Prompt，而是上下文本身。

Function Calling 只是入口，Context Engineering 才是更大的主题；Workflow 和 Agent 不是谁更高级，而是谁更适合当前问题；RAG 也不只是知识库问答，而是给模型补充高相关上下文的一种系统手段。

如果说前四篇还主要在建立“如何跟模型协作”，那这一篇开始真正进入“如何围绕模型设计系统环境”。这也是我现在越来越强烈的一种感受：Prompt 的下一步，不是更会写，而是更会组织上下文。

参考文档

  • Prompt Engineering Guide - Function Calling
  • Prompt Engineering Guide - Function Calling in AI Agents
  • Prompt Engineering Guide - Context Engineering for AI Agents
  • Prompt Engineering Guide - Context Engineering Guide
  • Prompt Engineering Guide - AI Workflows vs AI Agents
  • Prompt Engineering Guide - 检索增强生成 (RAG)