前四篇一直沿着同一条主线推进：先把任务说清楚，再把输出收窄，再把返回结构定义清楚，再学会把复杂任务拆成流程。继续往下，会遇到一个新的问题：当模型不只是回答问题，而是要调用工具、读取上下文、访问外部知识、在多个步骤里持续动作时，Prompt 还只是“写一句话”吗？
在 Function Calling、AI Workflows、AI Agents、Context Engineering 和 RAG 这些内容中，可以看到：Prompt 已经不只是输入设计，也不只是接口设计，而是在逐渐变成一种系统上下文设计能力。
Table of contents
Open Table of contents
- Function Calling 不是终点，而是系统协作的起点
- Function Call 和 Tool Call 到底有什么区别
- 为什么现在越来越多人更常说 Tool Call
- 那第五篇为什么还从 Function Calling 讲起
- 真正难的地方，不是“会不会调工具”，而是“上下文给得对不对”
- 什么叫上下文工程
- 这时，Workflow 和 AI Agent 的区别才真正变得重要
- 如何判断：用 Workflow，还是用 Agent
- RAG 不只是知识库问答，而是上下文供给方式
- 把 RAG 放进 Workflow 和 Agent 里，会看到更清楚的区别
- 一个越来越清楚的主线：Prompt 正在升级成“上下文操作系统”
- 这类系统设计可以怎样验收
- 本篇结论
- 参考文档
Function Calling 不是终点，而是系统协作的起点
Function Calling 容易让注意力停留在调用行为本身：
- 模型能不能选对工具
- 参数能不能传对
- JSON 结构稳不稳定
这些当然都重要，但如果只停在这里，理解还是会偏浅。
因为从工程角度看，Function Calling 真正打开的，不是“模型多了个功能”，而是下面这条链路：
- 用户用自然语言表达意图
- 模型根据上下文判断是否需要外部能力
- 模型产出工具调用意图和参数
- 程序执行真实工具
- 工具返回结果，再进入下一步判断或回答
这意味着，从这里开始，模型已经不再只是生成文本，而是在一个更完整的系统回路里工作了。
如果换成更熟悉的软件工程语言，这一步更像是：
- 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 的特点是：
- 路径是预先定义好的
- 哪一步先做、哪一步后做，基本由代码决定
- 模型只负责完成某个局部任务
- 系统整体更可控、更稳定、更容易调试
比如：
- 先分类用户请求
- 再路由到对应处理链路
- 再生成结构化输出
- 最后经过校验后返回
这类系统更像“固定流程”。
AI Agent
AI Agent 的特点是：
- 步骤不一定提前写死
- 模型自己决定要不要调用工具、调用哪个工具、下一步做什么
- 系统更灵活，但也更难预测
- 对上下文质量、工具设计和可观测性要求更高
比如用户说：
帮我整理最近 OpenAI 的开发动态，并给出可能影响前端工程师的点。
这时 Agent 可能会自己决定：
- 先做 web search
- 再整理结果
- 再判断哪些信息和前端工程师有关
- 再输出摘要
也就是说，Workflow 和 Agent 的差别，不只是“是不是更高级”，而是：
决策权更多掌握在代码里，还是更多交给模型。
如何判断：用 Workflow，还是用 Agent
这部分最有帮助的地方，不是记住定义，而是建立判断标准。
判断时可以先问下面几个问题：
- 任务步骤是否清楚、稳定、可预定义？
- 任务是否需要高可控性和高可调试性？
- 如果模型自由发挥过多，业务风险大不大？
- 这个任务是否经常出现开放式路径和动态选择？
- 工具调用顺序是否很难提前写死？
如果前面几个问题的答案偏向“是”，那更适合做 Workflow。
如果后面几个问题的答案偏向“是”，那才更适合做 Agent。
很多团队一开始就想做 Agent，但从工程角度看，这往往意味着流程设计尚未清楚，就先把控制权交给了模型。
从工程角度看，更稳妥的路径通常是：
先把能 Workflow 化的部分 Workflow 化，再把真的需要动态决策的部分交给 Agent。
这也是一种上下文工程思想。因为本质上是在决定：模型应该在哪些边界内拥有自由度。
RAG 不只是知识库问答，而是上下文供给方式
如果只把 RAG 理解成“做个知识库问答”，往往会低估它在系统里的位置。
把 RAG 放在上下文工程里理解，会更顺畅：
RAG 的本质，不只是检索，而是在运行时为模型补充当前任务真正需要的外部知识。
这个理解很关键。
因为模型的参数知识是静态的，而很多任务需要的却是：
- 最新信息
- 私有文档
- 业务规则
- 历史记录
- 项目上下文
这时候，如果把所有资料都硬塞进 Prompt，不仅放不下，而且噪声会越来越大。RAG 的价值就在这里：
- 先根据问题检索相关内容
- 再把这部分内容作为上下文送给模型
- 让模型基于“当前最相关的信息”来回答或行动
所以 RAG 在系统里真正解决的，不是“让模型变聪明”，而是：
让模型在当前这一步，看到它真正需要看到的信息。
从这个角度看，RAG 本质上也是上下文工程的一部分。
把 RAG 放进 Workflow 和 Agent 里，会看到更清楚的区别
RAG 放在不同系统里，角色其实不一样。
在 Workflow 里
RAG 更像一个固定步骤：
- 接收问题
- 检索相关文档
- 拼接上下文
- 基于上下文生成回答
这个流程清楚、稳定、容易评估。很适合：
- 文档问答
- 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 的安全、测试与维护问题，重点讨论 Prompt Injection、测试集、回归比较和版本化迭代。
参考文档
- 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)