L3 ：从“清谈”到“实干” —— 赋予 Agent 动作执行与动态引导的能力

一、L3 的本质：一个关键的架构跨越

在整个 L1–L5 谱系中，L3 是一个重要的分水岭。系列导读中已经明确：L3 起，LLM 开始主导自身的执行路径，这才是 Agent 行为的真正起点。

这个”起点”背后的技术基础，叫做 Function Calling（在 Anthropic 的 API 文档中称为 Tool Use）。

Function Calling 的工作方式，与你向 LLM 提问并等待答案截然不同。它的流程是这样的：

1. 开发者向模型提供一组工具定义（结构化描述：工具名称、功能说明、参数 Schema）
2. 用户提出请求后，模型自主判断：当前任务是否需要调用某个工具？如果是，应该调用哪个？
3. 模型输出一个结构化的调用意图（指定工具名和参数），而非直接生成文本答案
4. 你的应用程序接收这个意图，实际执行对应的函数或 API
5. 将执行结果返回给模型，由模型生成最终的自然语言回复

这个机制的关键在第 2 步：是模型在决定做什么，而不是外部代码决定。 这与 L2 的路由逻辑有本质区别——L2 是 LLM 识别意图后触发预设脚本，执行路径被外部硬编码；L3 的 LLM 则在运行时动态决定调用路径。Anthropic 官方文档将这种能力描述为：“Claude decides when to call a tool based on the user’s request and the tool’s description.”¹

这种自主调度能力，正是 L3 成为 Agent 起点的理由。

二、运行机制：最小执行闭环

为了描述 L3 的完整运行逻辑，我们引入一个分析框架——最小执行闭环（Minimal Execution Loop）。需要说明的是，这是笔者基于工程实践归纳的描述性框架，而非行业标准术语。其学术对应物，是 Google Research 于 2022 年提出、发表于 ICLR 2023 的 ReAct 范式（Reasoning + Acting）²——它首次系统论证了将”推理轨迹”与”行动执行”交织运行的有效性。

L3 的完整闭环如下：

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

        

这个闭环有几个关键特性值得理解：

自主性体现在哪里：不是在追问，而是在”选工具”和”填参数”这两步。LLM 自主决定调用 get_sales_data 还是 get_competitor_report，以及如何从对话上下文中提取正确的参数值——这是 L3 区别于 L2 的核心。

单步 vs. 多步：L3 可以是单次工具调用（读取一条数据，生成回答），也可以是链式调用（取数→分析→生成报告）。单步调用是 L3 的基础形态；链式调用会引入”连锁错误”风险，在第八节中详述。

追问是功能，不是定义：追问（Slot Filling / Clarification）是闭环中信息不完整时的一个节点，它在 L2 中同样可以实现（通过预设的追问脚本）。将追问视为 L3 的定义特征，是对架构的误读。

三、L3 的”嘴”：动态引导与信息补全

尽管追问不是 L3 的定义特征，但 L3 在信息收集上确实具备 L2 没有的能力——基于业务上下文的动态追问。

L2 追问 vs. L3 追问的差异

L2 的追问依赖预设逻辑：当系统检测到用户意图为”销售查询”，就触发固定的追问清单。追问项目固定，顺序固定，无法根据对话内容调整。

L3 的追问则由 LLM 动态生成。当用户说”分析一下 A 药在华东区的表现”，L3 Agent 并不直接执行，而是识别出执行标准分析所需的结构性缺口：

“根据标准分析流程，我还需要确认几点：1. 时间范围是去年 Q4 还是全年？2. 是否需要对比主要竞品 B 药的同期数据？3. 分析维度是仅限销量，还是同时包含覆盖率和增长率？”

这种追问的差异在于：它不是模板，而是推断。如果用户的描述已经包含了时间范围，LLM 不会重复询问；如果发现用户提及了一个非标准的分析维度，它会额外确认而不是强行套用标准模板。

技术实现

这种动态追问的实现，通常有两种路径：

• 系统提示词路径：将 SOP 转化为结构化的引导逻辑，写入系统提示词（System Prompt），描述”在什么情况下应该追问什么”
• 工具化路径：将信息收集本身定义为一个工具（如 clarify_analysis_scope），让 LLM 在判断信息不足时主动调用

前者实现简单，后者更灵活，适合需要将追问记录纳入审计流程的场景（如医疗、金融）。

对非技术用户的业务价值

对于刚入职的市场人员，Agent 的每一次追问都是一次无声的业务规范培训——它在告诉用户，做一次完整分析需要考虑哪些维度。这将原本存在于资深员工脑子里的经验，转化为了系统性的引导逻辑。

四、L3 的”手”：受控工具执行

这是 L3 架构中技术含量最高、也最容易踩坑的部分。

Function Calling 的执行边界

在讨论”让 LLM 执行什么”之前，必须先厘清一个经常被误解的问题：Function Calling 并不意味着要禁止 LLM 生成任何代码或查询语句。

Text-to-SQL（让 LLM 生成 SQL 并执行）是 Function Calling 框架下一种成熟且被广泛采用的范式，在 BI 工具、数据分析平台中已大量落地³。

真正需要谨慎的不是”LLM 能不能写 SQL”，而是在什么环境下执行、有没有审核机制。设计原则应该是：

这种设计的本质，是在 LLM 的能力与生产数据之间加入一层合适粒度的沙箱——而不是一刀切地禁止 LLM 生成查询逻辑。

工具箱设计：两个经常被忽视的原则

Function Calling 的实际效果，很大程度上取决于工具箱的设计质量。Anthropic 工程团队在《Writing Effective Tools for AI Agents》⁴ 中总结了若干经验，其中两点对业务落地最为关键：

原则一：工具描述的质量决定选择准确率。 LLM 是通过阅读工具的 description 字段来判断是否该调用它的。模糊的描述（如 get_data: 获取数据）会让模型产生歧义，在工具数量多时尤其明显。清晰的描述应该说明：这个工具做什么、适用场景是什么、不适用什么情况。Anthropic 内部测试显示，加入工具使用示例（Tool Use Examples）后，复杂参数处理的准确率从 72% 提升到 90%⁴。

原则二：工具粒度需要权衡。 细粒度工具（每个工具只做一件事）更安全，失控范围小，参数简单；但在复杂任务中需要多次调用，上下文消耗大。粗粒度工具（一个工具处理多种情况）调用次数少，但参数复杂，LLM 更容易填错。通常建议：从细粒度开始，用评估数据驱动合并决策，而非凭直觉设计工具边界。

工作流编排示例

当工具调用需要串联多个步骤时，典型的 L3 链式工作流如下：

每一步的输入都来自上一步的输出，每一步都是预定义的受控接口。LLM 的角色是调度者，而不是直接操作数据库的程序员。

五、最具商业价值的 L3 场景：激活现有 IT 资产

这是 L3 在企业落地中最容易被低估、但实际上最具战略价值的方向：让 AI 学会使用企业现有的 IT 系统，而不是替换它们。

为什么这个方向在受监管行业尤其重要

制药、金融、保险等行业普遍面临一个现实困境：现有 IT 系统（CRM、ERP、BI 平台、合规工具）经过多年验证，嵌入了核心业务流程，替换成本极高，监管认证也难以重来。在这类环境中，“引入全新 AI 系统”往往面临的阻力，远大于”让 AI 学会用现有系统”。

L3 的 Function Calling 架构天然适配这一诉求：将现有 IT 系统的 API 包装成工具，Agent 通过调用这些工具来模拟人类操作员的行为。

这意味着：

• CRM 系统不需要改造，Agent 通过已有的 API 读取客户数据
• BI 平台不需要重建，Agent 通过已有的查询接口提取报表
• 合规系统不受影响，Agent 通过合规接口的权限边界操作
• 数据的真实性和准确性，仍由成熟系统保证；AI 只负责调度逻辑

MCP：这一方向的基础设施标准

为了解决 AI 与 IT 资产集成的工程复杂度，Anthropic 于 2024 年 11 月发布了 Model Context Protocol（MCP）⁵ ——一个开放标准，旨在规范 AI 系统与外部数据源、工具的交互方式。

在 MCP 出现之前，每接入一个新系统，开发者都需要编写定制化的连接器代码。Anthropic 将这一问题称为”N×M 集成难题”——N 个数据源乘以 M 个 AI 系统，导致维护负担指数级增长。MCP 通过统一协议解决了这个问题，被称为”AI 集成领域的 USB 标准”⁶。

目前，MCP 已被 OpenAI、Google DeepMind 采纳，并在 2025 年 12 月由 Anthropic 捐赠给 Linux 基金会旗下的 Agentic AI Foundation（AAIF），成为事实上的行业标准⁷。已有针对 Google Drive、Salesforce、Slack、GitHub、Postgres 等主流企业系统的预构建 MCP 服务器。

对于制药企业来说，这意味着：Veeva（行业头部 CRM）、内部 BI 系统、医保政策数据库，都可以通过标准的 MCP 协议接入同一个 L3 Agent，无需为每个系统单独开发集成层。

对变革管理的战略意义

从推动落地的角度，“激活现有 IT 资产”这一方向的另一个优势是降低变革阻力。对于 IT 部门而言，他们面对的不是”被一套新系统取代”，而是”现有系统获得了一个更智能的使用者”。这种定位，显著降低了跨部门协作的摩擦。

六、角色适配：让同一份分析”见人说人话”

制药行业内部的角色差异极大，同一套分析数据对不同角色的价值截然不同。L3 的工具调用架构，使得”用一套分析逻辑生成多种交付格式”成为可能。

这是如何在技术上实现的？

角色适配的实现路径，通常是在 Function Calling 的工具定义中引入”输出角色”参数。Agent 根据用户身份标签（从权限系统或对话上下文中获取），选择调用不同的格式化工具：

# 工具定义示例（简化）
tools = [
    {
        "name": "generate_report",
        "description": "根据分析数据生成角色适配的报告。适用于将同一套 KPI 数据转化为不同格式。",
        "input_schema": {
            "kpi_data": "object",
            "target_role": {
                "type": "string",
                "enum": ["rep", "manager", "executive"],
                "description": "目标受众角色，决定输出格式和详细程度"
            }
        }
    }
]

generate_report(target_role="executive") 调用 3 页 PPT 模板；generate_report(target_role="rep") 调用移动端简报模板。同一份数据，不同的工具调用，输出完全不同的格式——无需人工重新排版。

七、UI/UX 设计要点：为非技术用户设计 L3 体验

这是 L3 落地中最容易被忽视的环节，也是决定非技术用户能否真正驾驭系统的关键。

L3 带来了 L1/L2 没有的 UI 挑战

在 L1/L2 中，用户的交互相对简单：输入问题，看到回答。但 L3 引入了一个新的复杂性：模型在幕后执行了一系列动作——选择工具、填充参数、调用 API、验证结果——用户对这些过程完全不知情。

对于技术用户，这或许不成问题。但对于非技术的业务人员（市场经理、一线代表），这种”黑盒感”会带来两个问题：一是不信任（“AI 在做什么？数字从哪来的？”），二是无法纠错（“结果不对，但我不知道哪一步出错了”）。

因此，L3 的 UI/UX 设计，核心任务是将后台的工具调用过程，以业务语言可视化地呈现给用户。

四层 UX 设计框架

根据用户在流程中不同阶段的需求，L3 的 UX 可以分为四个层次：

第一层：过程透明度（Process Transparency）——这是最重要的一层，也是 L3 最独特的设计挑战。

系统应该将工具调用过程翻译成用户能理解的语言，而不是暴露技术细节：

这种”进度可视化”设计，让用户知道 Agent 在做什么，建立对系统的信任感。它不需要用户理解 API，只需要让用户觉得”系统正在认真处理我的请求”。

第二层：参数确认界面（Parameter Review）——让用户在执行前验证 Agent 的”理解”是否正确。

当 Agent 从自然语言对话中提取参数后，应向用户展示一个轻量级的确认视图：

这个界面解决了 L3 最常见的参数幻觉问题：让用户在消耗算力之前发现参数错误，比事后看到错误报告更高效。

第三层：草稿审阅（Draft & Review）——专门针对”写操作”（会产生实际影响的操作）的确认机制。

“写操作”包括：发送邮件、推送数据到下游系统、更新 CRM 记录、生成正式报告。在这些操作执行之前，必须提供预览界面：

这是 Anthropic《Building Effective Agents》⁸ 明确建议的”Human-in-the-loop”设计原则在 UI 层的具体体现：在执行不可逆操作前，始终为人留出最后的控制权。

第四层：结果溯源（Result Attribution）——让用户知道数据从哪里来。

当 Agent 输出分析结论时，关键数据点应附带来源标注：

这不仅增加了可信度，还为数据质量问题提供了追溯路径。

针对非技术用户的额外设计建议

• 使用业务语言，隐藏技术细节：参数名称应该是”时间范围”而不是 date_range，地区选择应该是可点击的地图而不是代码输入框
• 渐进式展示：先展示”正在处理”的高层状态，允许用户点击展开查看详细步骤
• 错误信息的业务化翻译：API 超时不应告诉用户”timeout error”，而应说”CRM 系统响应较慢，正在重试…”

八、风险警示：L3 的三大失败模式

赋予 Agent 执行权，意味着错误不再只是”聊错了天”，而是实实在在的操作失误。

失败模式一：参数幻觉（Parameter Hallucination）

LLM 在提取参数时可能出错。常见情形：

• 将”去年 Q4”理解为”2023 Q4”而非”2024 Q4”（因为 LLM 的训练数据时间偏差）
• 将地区名称与错误的地区代码对应
• 在对话歧义时选择错误的默认值

应对方案：

1. 引入第二层 UI（参数确认界面）
2. 在工具调用前增加参数校验层，对超出合理范围的值自动拦截
3. 为常用查询条件建立”业务词典”，将自然语言术语映射到标准参数值

失败模式二：链式错误传播（Error Propagation in Chained Calls）

当 L3 执行多步链式工具调用时，第一步的偏差会被后续步骤放大。第一步取错数据区间，第二步的增长率计算基于错误基准，最终 PPT 里的结论可能完全背离事实——而且每一步单独看起来都是”正确”的。

需要特别说明：这个问题主要出现在链式调用场景，而非 L3 的所有应用。单次工具调用（读取一条数据并回答）不存在这个风险。

应对方案：

1. 在链式调用的关键节点增加中间结果验证（如：取数后先展示数据摘要，确认无误再继续计算）
2. 设计”幂等”的工具——相同输入始终产生相同输出，便于问题复现和调试
3. 记录完整的工具调用链日志，便于事后审计

失败模式三：权限越界（Permission Escalation）

如果工具接口的权限设计过宽，或者工具描述不够精确，Agent 可能被诱导（无论是无意的 Prompt 歧义还是恶意的 Prompt Injection）去调用它不该访问的数据或执行不该执行的操作。

应对方案：

1. 工具权限遵循最小权限原则——每个工具只开放完成其功能所必需的权限
2. 将只读工具和写操作工具严格分离，写操作工具必须经过独立的审核层
3. 在 MCP 层面实施访问控制，而不只是在应用层控制
4. 对工具调用建立审计日志，满足合规要求

Human-in-the-Loop：高监管行业的标配

对于制药、金融、保险等行业，上述风险的代价往往超出技术范畴（监管合规、患者安全、资金损失）。因此，“人在回路”（Human-in-the-Loop）不是补丁，而是架构设计的一部分。

具体实施层面，建议区分两类操作：

• 只读操作（读数据、生成分析）：可以允许 Agent 自主执行，事后可复查
• 写操作（发送通讯、更新记录、推送数据）：必须经过 Draft & Review 界面，人工确认后才能执行

九、L3 的边界：它做不到什么

理解一个架构的边界，与理解它的能力同等重要。以下是 L3 单 Agent 架构的结构性局限，而非可以通过优化解决的工程问题：

局限一：无法自主协调跨系统的并行任务

当一个业务请求需要同时调用多个独立系统并将结果汇总时，L3 单 Agent 面临效率瓶颈。

以”处理一个异常退款案例”为例：如果需要同时核查财务流水（财务系统）、确认物流状态（物流系统）、验证客户历史（CRM），L3 只能串行处理——先查财务，等结果，再查物流，等结果，再查 CRM。响应时间随任务数量线性增长。

这种场景更适合 L4 的多 Agent 并行编排架构。

局限二：无法处理执行路径无法预先枚举的任务

L3 的工具调用依赖预定义的工具箱。这意味着，如果面对一个全新的、工具箱中没有对应工具的业务场景，Agent 无法临时”发明”新的执行路径。

换句话说：L3 擅长在已知边界内灵活组合，但无法在未知边界中自主探索。当业务需要 Agent 面对从未见过的问题类型并自主找到解决方案时，L3 力不从心。

局限三：角色与任务的协调复杂度受限

当一个复杂任务需要不同专业角色的分工协作时（例如：一个医学信息 Agent 负责数据，一个合规 Agent 负责审核，一个格式化 Agent 负责输出），L3 的单 Agent 架构难以承载这种职责分工的内在张力。把所有逻辑塞进一个 Agent，会导致工具箱膨胀、系统提示词失控、调试困难。

这三个局限共同指向同一个问题：当任务的复杂度超出了”单个 Agent 在预定义工具箱内自主调度”的范围时，我们需要一种新的架构——让多个专业化的 Agent 分工协作，由一个编排层统一协调。这正是 L4 协同编排架构要解决的问题，将在下一篇文章中展开。

十、结语

L3 标志着 Agent 从”只会聊天的百科全书”进化为”能够在受控边界内办成事的数字助理”。但这种进步必须建立在对风险和边界的清醒认知之上。

在本文描述的场景中，能够长期稳定运行的 L3 系统，往往不是设计得最”智能”的那个，而是那些工具箱边界清晰、过程对用户透明、在高风险操作前始终保留人工确认、且与现有 IT 资产无缝整合的系统。

正如 Anthropic 工程团队在《Building Effective Agents》中所总结的：成功的 LLM 应用，不在于构建最复杂的系统，而在于构建适合当前需求的正确系统。⁸

当你的业务需求超出了”单 Agent 在预定义工具中调度”的能力范围——当任务开始需要多角色并行协作、需要跨系统的动态协调——你就到达了 L3 的边界，也就站到了 L4 的门口。

参考文献