L3下一步让模型来定，但每一步都要让人看得见

一位刚入职的运营问：“上个月大促，空气炸锅卖得怎么样？”

L2 会把这句话归到“销售查询”，按固定脚本问三个问题。L3 会先看对方已经说了什么，只问缺的那一个，再自己决定去订单系统还是 BI 取数。两者的差别不在会不会追问，而在谁决定下一步。

上一篇讲到，问题要拆成几步、下一步取决于上一步的结果时，L1 和 L2 的固定流程就接不住了。这一篇讲 L3：下一步交给模型来定，以及这样做之后，要给人留下哪些看得见、拦得住的地方。

从这一层起，模型决定下一步

L3 背后的技术叫 Function Calling，Anthropic 的文档里叫 Tool Use。它的流程是这样的：

1. 开发者给模型一份工具清单：每个工具叫什么、做什么、要哪些参数。
2. 用户提出请求，模型判断要不要用工具、用哪个。
3. 模型输出一个结构化的调用请求（工具名和参数），不直接写答案。
4. 应用程序照这个请求真正去执行。
5. 执行结果交回模型，由它写出最后的回答。

分水岭在第 2 步：用哪个工具、什么时候用，由模型决定，不再由代码写死。 Anthropic 的文档原话是：“Claude determines when to call a tool based on the user’s request and the tool’s description.”¹ L2 也能识别意图，但识别之后走哪条路，是事先写好的。

严格地说，只调用一次工具的 L3，更接近 Anthropic 所说的“增强型 LLM”；在循环里根据结果反复调用工具，才是他们定义的 Agent。这一点导读里也说过。

一个最小的闭环

我用“最小执行闭环”来描述 L3 一次完整的运行。这是我基于工程实践归纳的描述性框架，不是行业标准术语。学术上和它最接近的，是普林斯顿大学与 Google Research 的研究者 2022 年提出的 ReAct：让模型把推理和行动交替进行。²

flowchart LR
  A[理解意图] --> B[识别信息缺口]
  B --> C["[追问补全]"]
  C --> D[选择工具]
  D --> E[填充参数]
  E --> F[执行调用]
  F --> G[验证结果]
  G --> H[生成交付物]
  G -- "如结果异常则反馈" --> B

这个闭环里，模型自己做主的是“选工具”和“填参数”两步：去订单系统查还是去 BI 拉报表，时间范围该从对话里的哪句话里取。追问只是信息不全时的一个节点，L2 用预设脚本也能追问，所以它算不上 L3 的定义。

L3 可以只调用一次工具（查一条数据就回答），也可以连着调用好几次（取数、算指标、写报告）。连着调用会带来连锁错误，后面再说。

会追问的系统

追问不是 L3 的定义，但 L3 的追问和 L2 不一样。L2 的追问是一张固定清单：检测到“销售查询”，就按顺序问时间、渠道、品类。L3 的追问是推断出来的。回到开头那位运营，L3 可能这样问：

“还需要确认两点：只看自营，还是连第三方店铺一起看？要不要和去年同一场大促比？”

时间范围对方已经说了，它就不再问；对方提到一个平时不用的分析口径，它会多确认一句，不会硬套标准模板。

实现上有两条路：把操作规范写进系统提示词，说明什么情况下该追问什么；或者把“澄清分析范围”本身做成一个工具，让模型在信息不够时主动调用。后一种更灵活，追问的记录也能留下来备查。

对刚入职的人，这些追问还有一个用处：每一次追问，都在告诉他做一次完整的分析要考虑哪些维度。原来只在资深员工脑子里的经验，变成了系统里的引导。

让模型调用工具，边界放在哪

先澄清一个常见的误解：用 Function Calling，并不等于禁止模型自己写查询。Text-to-SQL（让模型生成 SQL 并执行）就是 Function Calling 框架下的一种常见范式。要小心的是在什么环境下执行、有没有人审核：

工具本身怎么设计，影响也很大。Anthropic 工程团队总结过一些经验，³ 我觉得对业务落地最要紧的有两条。

第一，工具的说明写得好不好，决定模型选得准不准。模型是读工具的说明来决定用不用它的。“get_data：获取数据”这种说明会让模型犹豫，工具一多就更明显。好的说明要写清楚：这个工具做什么、什么时候用、什么时候不该用。Anthropic 另一篇文章提到，在工具定义里附上调用示例后，他们内部测试中复杂参数的准确率从 72% 提高到 90%。⁴

第二，围绕工作流设计少量工具，不要每个接口包一层。必要时把几步操作合进一个工具，再用评估数据检验效果。Anthropic 举的例子是：与其分别提供 list_users、list_events、create_event，不如提供一个 schedule_event，由它自己查空档、再把日程约上。³

最被低估的用法：让 AI 用好现有的系统

我觉得 L3 在企业里最被低估的方向，是让 AI 学会使用现有的系统，不去替换它们。

一家做了很多年的电商平台，订单、物流、客服工单、会员、BI，每一套系统都用了很多年，背后连着真实的业务流程，换掉的代价极高。在这种环境里，“上一套全新的 AI 系统”遇到的阻力，远大于“让 AI 学会用现有的系统”。

L3 正好适合这件事：把现有系统的接口包成工具，Agent 调用这些工具，像一个熟练的操作员那样工作。系统不用改造，数据的准确性仍然由成熟的系统保证，AI 只负责调度。对 IT 部门来说，这等于现有系统多了一个更聪明的使用者，推动起来阻力小得多。

这件事的基础设施，是 Anthropic 在 2024 年 11 月发布的 Model Context Protocol（MCP）：⁵ 一个开放标准，规定 AI 应用怎么连接外部的数据和工具。在它之前，每接一个系统都要写一段定制的连接代码；N 个系统、M 个 AI 应用，要维护的连接器数量是两者的乘积。MCP 用一个统一的协议解决这个问题，官方文档把它比作“AI 应用的 USB-C 接口”。⁶ 到 2025 年 12 月，ChatGPT、Gemini、Microsoft Copilot 等主流 AI 产品都已支持 MCP，Anthropic 也在这时把它捐给了 Linux 基金会旗下新成立的 Agentic AI Foundation。⁷

放到电商平台上，就是订单、物流、客服工单和会员这几套系统，都可以通过同一套协议接到同一个 L3 Agent 上，不用为每个系统单独开发一层集成。

让用户看得见、拦得住

L1 和 L2 的交互很简单：输入问题，看到回答。L3 多了一层：模型在背后做了一连串动作，选工具、填参数、调接口、验结果，用户却完全看不到。对不写代码的业务人员，这会带来两个问题：不信任（“它在干什么？数字从哪来的？”），以及没法纠错（“结果不对，但我不知道哪一步错了”）。

所以 L3 的界面要做的，是把后台的工具调用，用业务语言摆到用户面前。 我会分四层来做。

第一层是过程透明：不显示接口和参数，而是说“正在从订单系统调取上个月大促期间空气炸锅的销量……”。用户不需要懂接口，只需要知道系统在认真处理。

第二层是参数确认：模型从对话里提取出参数后，执行之前先给用户看一眼。

用户在花掉算力之前就能发现参数错了，比事后看到一份错的报告省事得多。

第三层是草稿审阅，专门用于写操作：发邮件、往下游系统推数据、改会员记录、生成正式报告。执行之前，先给人看预览。

这呼应了 Anthropic《Building Effective Agents》的建议：Agent 可以在检查点暂停，等人反馈。⁸ 放到界面上，就是在不可逆的操作之前，永远给人留最后一道确认。

第四层是结果溯源：关键数字旁边标出来源和时间，比如“大促期间空气炸锅销量同比增长 18%（来源：订单系统，截至 9 月 15 日）”。这让人放心，也给数据出错时留了一条追查的路。

同一份结果，还可以按读者换格式：给店铺运营的是手机上一屏能看完的简报，给品类负责人的是带对比图的报告。做法是在报告工具上加一个“给谁看”的参数，由模型按用户身份选择。

三种常见的失败

给了 Agent 动手的权力，错误就从“说错话”变成了真的操作失误。

• 参数幻觉：模型提取参数时出错，比如把“去年第四季度”对到错误的年份，或者把地区名对到错的编码上。最有效的对策是上面的第二层：执行前让人确认参数。
• 连锁错误：连着调用几个工具时，第一步取错了数据区间，后面的增长率就建立在错误的基准上，最后报告里的结论可能完全偏离事实，而每一步单独看都“没错”。对策是在要紧的节点停一下，先给人看中间结果，确认无误再往下走。只调用一次工具不会有这个问题。
• 权限越界：工具的权限开得太宽，或者说明写得太含糊，Agent 就可能被诱导（无意的歧义，或者恶意的提示词注入）去碰不该碰的数据。对策是最小权限：每个工具只开放它必需的权限，只读工具和写操作工具分开，写操作必须过独立的审核。

在这些对策之上，我的原则很简单：读数据、做分析，可以让 Agent 自己来，事后可查；发消息、改记录、推数据，必须先出草稿，人确认之后再执行。

L3 做不到什么

局限一：所有中间结果挤在同一个上下文里

当一个请求需要同时查几个彼此独立的系统时，L3 单 Agent 可以在同一轮里发出多个工具调用，由应用并发执行。截至 2026 年 10 月，Claude 和 OpenAI 的 API 默认都允许这样做。⁹ 所以“只能串行”并不是 L3 的瓶颈。

L3 真正的瓶颈，是所有中间结果都挤在同一个上下文里。以“处理一个异常退款案例”为例：核查财务流水、确认物流状态、翻看客户历史，如果每一条都要多步探索、各自判断，上下文会迅速膨胀，几条线索之间也会互相干扰。

这时才更适合 L4 的做法：让子 Agent 在各自独立的上下文里推进，再由编排层汇总。Anthropic 自己做多 Agent 研究系统，理由之一就是让子 Agent 带着各自的上下文窗口并行工作。¹⁰

局限二：执行路径没法事先列出来的任务

L3 的工具都是事先准备好的。遇到一个全新的、工具箱里没有对应工具的情况，Agent 没法临时“发明”一条新的执行路径。它擅长在已知的边界里灵活组合，不擅长在未知的地方自己探索。

局限三：目标互相冲突时，没有人制衡，也没有人裁决

当一个任务里有几个互相冲突的目标时（比如一个大促商品页：市场想把卖点写得更有力，法务要删掉一切绝对化的说法），单个 Agent 只能在一个提示词里同时替两方说话。冲突被它自己悄悄消化掉，你看不到哪一方让了步、为什么让步。

局限二是 L5 的话题。局限一和局限三指向 L4：让几个 Agent 在各自的上下文里推进、各自代表一个目标，由编排层汇总，最后由规则或人来裁决。下一篇展开。

结语

回到开头那位刚入职的运营。L3 替他问了缺的那一个问题，自己去订单系统和 BI 取了数，写好了简报，但在发出去之前，停下来给他看了一眼。

L3 好不好用，往往看三件事：工具的边界清不清楚，过程看不看得见，写操作之前有没有留给人确认。Anthropic 在《Building Effective Agents》里的建议也是这个意思：先找能解决问题的最简方案，只在真正需要时才增加复杂度。⁸

当一个任务里出现几个互相冲突的目标，需要不同视角互相制衡、最后有人裁决时，你就到了 L3 的边界，站在 L4 的门口。只是要并行调用、跨几个系统，L3 还能接着做。