7. Agent 与工具调用层（Agents & Tool Use）

在前面的视觉、语言等能力层中，模型大多还是“被动回答”的形态——接收输入、给出输出。而在很多真实业务里，我们需要的是一个 可以主动规划、调用外部工具、串联工作流的智能体（Agent） ：它不仅能看懂/读懂/听懂，还能自己“决定下一步做什么”，比如去查资料、跑代码、读写文件、调用内部系统，然后再把结果整合、解释并反馈给用户。

这一层可以被理解为“把基础模型变成可行动系统”的关键粘合层：通过 结构化工具调用接口、工作流编排、多 Agent 协作以及人类在环机制 ，把 LLM 从一个强大的“认知内核”扩展为能够完成端到端任务的“数字员工”。

7.1 工具调用与执行（Tool Calling / Function Calling）

在只读不写、只说不做的纯文本时代，LLM 更像一个“超级对话者”：可以理解问题、给出建议、写代码、列方案，但所有“真正执行”的工作——查数据库、跑脚本、生成文件、调云服务——仍然要人工接手完成。而工具调用 / Function Calling 的出现，让模型第一次可以在安全边界内“动手”：根据自然语言自动生成结构化参数，去调用搜索引擎、数据库、计算引擎、图像/音频/视频生成服务等外部能力，再把执行结果整理返回，从而形成“理解 → 决策 → 执行”的闭环。

从产品角度看，工具调用是绝大多数 Agent 系统的“底盘能力”：OpenAI Assistants API、LangChain、LlamaIndex、AutoGen、各类云厂商的 Agent 平台，实质上都是在 LLM 之上，围绕如何定义工具、如何让模型正确选工具、如何处理出错与重试搭建一层运行时。下面同样从 场景 、原理和模型三个角度梳理这一层能力，并在后续小节中分别展开“工具调用接口设计”“工具选择与策略”“典型工具类型”三个方向。

• 场景
  • 智能问答与检索增强：模型根据用户问题自动决定是否调用检索工具（向量/关键词搜索）、查企业内部知识库或公网搜索，并将查到的文档、FAQ 整合进最终回答。
  • 数据与报表自动化：面对“帮我查这段时间的销售额并画图”“给我算一下这个投资组合的风险指标”之类请求，模型自动生成 SQL 或分析参数，调用数据库和计算引擎，返回图表与结论。
  • 文档与文件操作：自动读取 PDF/Word/Excel/数据库表，抽取和汇总关键信息，或按指令生成新文件（如报表、合同、方案），并通过工具上传/存储到指定位置。
  • 媒体生成与处理：根据文本指令调用图像/音频/视频/3D 生成服务，或对现有媒体做剪辑、压缩、转码、水印等操作，形成一键“文案 + 设计 + 导出”的内容流水线。
• 原理 工具调用的核心是： 用自然语言驱动结构化函数调用 。
  • 首先以 JSON Schema 或函数签名的形式，将外部工具的名称、说明、参数结构（类型、必填项、枚举值等）暴露给 LLM。
  • 当用户发出请求时，LLM 不仅要理解语义，还要判断“是否需要调用某个工具”“需要哪个（些）工具”“这些工具的参数应该怎么填”。
  • 一旦模型决定调用某个工具，就生成一段结构化参数（通常是 JSON），由运行时去真正执行外部 API / 程序，并把执行结果以结构化形式返回给模型，让模型基于结果继续推理或生成最终回答。
  • 为保证安全与鲁棒性，系统需要在这一过程中处理参数校验、超时、错误返回、重试与回退，并对可能涉及安全/隐私的调用做权限与审计控制。
• 模型 支撑这一能力的模型与框架主要包括三类：
  • 支持 Function Calling 的 LLM：如 GPT‑4.1 / o 系列等，原生在解码层面理解“工具签名 + JSON Schema”，能够在合适时机主动或被动地产生结构化调用参数。
  • 工具增强推理范式：如 ReAct、Toolformer，将“思考 + 工具调用”编织进同一推理链条，将工具使用视作中间步骤的一部分，而不是简单的前/后处理。
  • 工程框架与运行时：OpenAI Assistants API、LangChain、LlamaIndex、AutoGen、各云厂商 Agent 平台等，为工具定义、调用路由、状态管理、错误处理与日志审计提供基础设施，让开发者可以聚焦在“暴露哪些工具”和“抽象怎样的业务 API”上，而不必从零搭建运行时。

7.1.1 工具调用接口：从自然语言到结构化函数调用

一个可用的工具调用系统，首先需要一个清晰、规范、对 LLM 友好的“工具接口层”。它承担着把外部世界的 API、脚本、服务包装成模型可理解、可安全调用的“函数”的职责，让模型可以像写伪代码一样“说出”自己希望调用的工具及其参数。

• 工具定义与参数模式 在接口层，通常会用类似 JSON Schema 或函数签名的结构定义每个工具：包括名称（name）、说明（description）、参数字段（properties）、类型（string / number / boolean / array / object）、是否必填（required）、取值范围或枚举等。 这些信息一方面被用来驱动前端/SDK 的类型检查，另一方面也直接提供给 LLM，帮助模型“学会”如何正确填写参数。描述越清晰、约束越合理，模型生成的调用就越规范，出错率越低。
• LLM 生成结构化参数 当用户提出“帮我查 2024 年 Q3 的营收并画一张按地区拆分的柱状图”这类请求时，模型需要先推理出：这至少需要一个“报表查询工具”（访问数据）、可能还需要一个“图表生成工具”（画图）。对每个工具，它要从原始语言中抽取并映射结构化参数，如时间范围（start_date/end_date）、维度（region）、指标（revenue）、图表类型（bar）、输出格式等，然后以 JSON 输出交给运行时。 这个过程中，模型本质上在做“自然语言 → 任务规划 → 参数抽取 / 填充”的一体化推理，因此工具描述的自然语言提示、参数示例和 few‑shot 样例都非常关键。
• 工具执行与结果回传 运行时接收到模型产出的 JSON 调用后，会先进行参数校验与安全检查，再去真正调用后端 API 或程序。执行完成之后，将结果封装为结构化对象（如查询结果表格、文件 URL、媒体资源 ID 等）返回给模型。 随后，模型会把这些原始结果转化为用户可读的解释或进一步加工，如总结报表、生成自然语言分析、嵌入图表标注说明等。对于模型而言，工具结果只是中间信息的一部分，它仍然要负责“理解结果 + 解释结果”。

7.1.2 工具选择与策略：在多工具世界里做决策

当系统中只有一个工具时，“要不要用工具”是唯一的问题。但在现实 Agent 应用中，往往会有几十甚至上百个工具：不同数据源的检索、不同部门的业务 API、不同技术域的生成/分析能力，这就引出了一个新的挑战： 模型如何在多工具环境下做合理的选择和编排 。

• 工具选择与路由 首先，模型需要判断“当前请求是否需要调用工具”，以及“需要调用哪一个（或哪几个）工具”。这通常通过在系统提示中列出可用工具的说明，并提供典型示例，让模型学会根据用户意图选择合适工具。 对于工具数量较多、描述相似度较高的场景，很多框架会引入“工具路由器”（如基于向量检索或规则的前置筛选），先从大列表中筛出若干候选工具，再暴露给 LLM 选择，从而降低模型负担和误选概率。
• 多工具顺序与组合 复杂任务往往需要多个工具协同完成。例如“调研某行业主要上市公司，并生成一份包含财务对比图表的报告”，可能涉及搜索引擎、财报数据库、计算引擎、图表生成工具、文档导出工具等。 在这种情况下，模型需要做一个轻量级的任务规划：先用哪个工具获取列表，再对列表逐个查询详细信息，之后合并数据、做计算与可视化，最后调用导出工具生成报告。典型实践包括 ReAct/Planner‑Executor 思路，让模型在“思考（Plan）—调用（Act）—反思（Reflect）”的循环中，逐步完成工具组合调用。

7.1.3 典型工具类型：从检索到媒体生成的能力拼图

不同类型的工具，为 Agent 系统提供了不同维度的“外接大脑”。从工程实践来看，以下几类工具几乎是所有复杂应用的“标配”。

• 检索工具：向量与关键词搜索 检索工具负责把“记忆”扩展到外部世界：
  • 关键词搜索适合结构化较好、字段清晰的传统文档和业务数据库。
  • 向量搜索则通过嵌入（embedding）为非结构化文本、代码、对话记录、甚至多模态数据建立语义索引，支持“模糊但语义相关”的检索。 在 RAG 场景中，LLM 通过检索工具拉取与用户问题相关的上下文，再在此基础上进行推理与生成，大幅提升回答的时效性和准确性。
• 代码执行与计算引擎 代码执行类工具（如 Python/JS 沙箱、Notebook 执行器）让 LLM 可以“写一段代码并立即跑起来”，解决复杂计算、数据处理、数值模拟、可视化等问题。 模型负责产出代码与输入参数，执行环境负责安全隔离、资源限制与结果收集。这类工具在数据分析、量化研究、自动化报表、科学计算以及 Agent 自我验证（模型生成答案后用代码校验）等场景中非常关键。
• 文件与数据源访问 文件读写工具负责将外部文件系统和数据源引入到 Agent 视野中：读取 PDF/Word/Excel、访问数据库表、调用内部业务 API 等。模型通过这些工具获取真实业务数据，再进行归纳、对比和报告生成。 与之配套的还有文件写入与管理工具：将生成的报告、图表、PPT、代码等持久化存储，并返回链接或 ID，方便用户后续访问与集成。
• 媒体生成与处理工具 媒体生成工具则为 Agent 增添了“创作”和“设计”的手臂：
  • 图像/视频生成与编辑：根据文案自动生成配图、海报、分镜，或对已有媒体进行裁剪、上字幕、加水印等。
  • 音频生成与处理：TTS、配音、音乐生成、音频增强与剪辑。
  • 3D / 工程类工具：生成简单 3D 场景、CAD 草图、UI 原型等。 在内容生产、营销设计、教育培训、游戏与多媒体应用中，这类工具让“从想法到成品”更接近一条自动化流水线。

综合来看，工具调用与执行把 LLM 从“语言模型”扩展为“具备行动接口的通用控制器”：模型通过语言理解需求与环境，通过工具执行真实操作，通过反馈不断修正策略。搭配合适的工作流编排与多 Agent 协作（见 7.2），就构成了新一代智能应用的基础架构。

7.2 工作流编排与多 Agent 协作（Workflow & Orchestration）

有了工具调用能力，LLM 不再只是一个“回答问题的人”，而可以成为面向具体任务的“执行单元”。但现实业务往往远比单次对话复杂：一个完整的诉讼分析、一次市场调研、一轮 A/B 实验配置、一次端到端运维处理流程，通常都需要多步操作、多种工具、甚至多方角色长期参与。这时，单一 LLM + 工具的模式就显得吃力，需要进一步的 工作流编排与多 Agent 协作 。

从系统视角看，这一层的职责是： 把一个复杂的、多步骤、多参与方的业务流程，抽象成可被 LLM 理解与操控的工作流图 ，然后在这个图上调度一个或多个 Agent，配合人类干预，共同完成任务。典型实现包括 Planner‑Executor 型 Agent 架构、具备反思 / 自我修正能力的 Agent、以及基于图结构的 Workflow Orchestrator；相应的产品形态则是各类自动报告生成与运营自动化平台、低代码工作流 + LLM 集成、复杂业务流程机器人、自动运维系统等。

• 场景
  • 报告与内容流水线：从“接收需求 → 检索与数据拉取 → 分析和可视化 → 撰写报告 → 审核修改 → 导出与分发”，将多步内容生产流程自动化或半自动化。
  • 业务流程自动化：如电商运营中的“商品分析 → 竞品监控 → 活动策略生成 → 落地配置”，运维场景中的“监控告警 → 根因分析 → 缓解措施执行 → 复盘报告”等。
  • 跨角色协作：让不同领域 Agent（法律、财务、技术、运营）围绕一个复杂项目协同工作，例如并购尽调、投融资材料准备、大型项目标书编制。
• 原理 工作流与多 Agent 协作的核心，是在 LLM 之上再加一层 结构化控制与状态管理 ：
  • 将复杂任务拆分为若干有依赖关系的子任务，用 DAG / 状态机 / 有向图等结构表示，并为每个节点配置触发条件、输入输出和所需 Agent/工具。
  • 由 Planner 型 Agent 或上层 orchestrator 决定何时触发哪个节点、用哪个 Agent 或工具，并根据执行结果动态调整后续路径（条件分支、循环、错误回退）。
  • 在关键环节引入人类在环（Human‑in‑the‑loop），对高风险决策和关键输出进行人工确认与编辑，并将人类反馈回流到系统，用于更新策略或微调模型。
• 模型 支撑这一层的主要技术方向包括：
  • Planner‑Executor 型 Agent 架构：由一个“规划 Agent”负责任务分解与路径设计，一个或多个“执行 Agent”负责具体步骤的落地实施。
  • 反思 / 自我修正 Agent：在执行过程中不断回顾自己的表现，对不合理的中间结果进行反思和修正，减少“自信错误”的静默扩散。
  • Graph‑based Workflow Orchestrator：将整个任务流程建模为图结构，引入节点状态、边条件、并行/串行控制等机制，使 LLM 调用变成图中的一个或多个节点，而不是唯一的控制中心。

7.2.1 任务分解与规划：从“一句话需求”到可执行流程

用户给 Agent 的通常是一句高度压缩的自然语言需求，例如“帮我做一个关于新能源车行业的市场调研并输出 PPT”，背后实际包含了检索、筛选、分析、可视化、排版、多轮修改等大量步骤。如何从这句话出发，自动构建一条清晰、可执行的工作流，是工作流编排的第一步。

• 从自然语言到子任务图 Planner 型 Agent 首先需要把需求“展开”：结合内置模板、历史案例、以及工具清单，识别出关键阶段（如信息收集、数据分析、结构设计、内容撰写、审校与导出），并进一步细化为可执行子任务（如“检索 5 篇近一年权威行业报告”“拉取近 3 年销量数据并按车型细分”“生成 3 张对比图表”等）。 这些子任务之间的依赖关系和调度逻辑，会被显式表示为一张图或一个状态机：哪些可以并行、哪些必须顺序执行、在哪些节点需要人工确认、在什么条件下需要回退或重试。
• 条件分支、循环与异常路径 真实流程往往并不是线性流水线，而是包含 条件分支 （如“如果检索不到足够高质量报告则换关键词或换数据源”）、 循环 （如“持续尝试改写和压缩，直到报告长度满足限制”）和 异常路径 （如“某个数据源不可达时，切换到备选源或采用估算方法”）。 这要求工作流编排层能够在图结构上表达 if/else、while/for、try/catch 等控制流语义，并允许 Planner Agent 或上层 orchestrator 在运行过程中根据实时结果做决策，而不仅仅在开始时一次性规划好所有步骤。
• 与工具调用的衔接 任务分解与规划与 7.1 中的工具调用是紧密相连的：Planner 在生成子任务时，往往会同时指定“该任务需要用到哪些工具/Agent”和“该节点的输入输出格式”，为后续自动参数填充和工具执行打基础。 一些系统会采用“Plan + Execute”显式两阶段：先由 Planner 输出一个机器可读的计划（如 JSON 工作流描述），再由 Executor 严格按计划调用工具与 Agent；也有系统采用 ReAct 风格，将“思考–工具调用–观察–再思考”编织在同一对话中，以获得更灵活的自适应执行。

7.2.2 多 Agent 协作：让“虚拟团队”各司其职

单个大模型固然强大，但在复杂业务场景中，不同领域往往需要不同的知识结构、风格偏好和安全策略。多 Agent 协作的思路，是把一个“大而全”的智能拆解为多个“专而精”的角色：有人负责规划，有人负责执行，有人负责审校，有人负责领域专业判断，形成一个由 Agent + 工具 + 人类共同组成的虚拟团队。

• 角色分工：规划、执行与审校 在一个典型的多 Agent 流程中，常见角色包括：
  • 规划 Agent：负责理解用户需求、设计整体计划、拆分子任务，并在执行过程中根据结果动态调整路径。
  • 执行 Agent：围绕某些工具或子领域进行深度优化（如检索 Agent、数据分析 Agent、内容撰写 Agent），按规划要求完成具体步骤。
  • 审校 Agent：从结构性、逻辑性、风格一致性和风险控制等角度，对中间和最终产出进行检查和修订，类似“虚拟编辑/Reviewer”。
• 领域专家 Agent 协同 对于法律、金融、技术、运营等专业性极强的领域，可以进一步细分出领域专家 Agent：如“法律顾问 Agent”“投研分析 Agent”“云原生运维 Agent”“广告投放优化 Agent”等。 它们可以基于领域专用知识库、工具、甚至专门微调模型，参与项目式协作：例如在一份投融资材料中，由技术 Agent 负责技术可行性部分，财务 Agent 负责财务模型与估值，法律 Agent 负责合规与风险披露，运营 Agent 负责市场与增长策略，再由总控 Agent 汇总和统一风格。
• 协作协议与消息路由 多 Agent 协作的关键，还在于“谁在什么时候跟谁说话”。系统需要一个消息路由与协调机制：
  • 决定某条用户请求或中间结果应当被哪个 Agent 处理。
  • 维护共享上下文与各自的私有记忆。
  • 控制并行与串行执行，以及冲突解决（如不同 Agent 提出相互矛盾的建议时如何仲裁）。 这类能力通常由上层 orchestrator 或“管理 Agent”提供，而 LangChain、AutoGen 等框架则在工程层面提供了对话路由、多 Agent 会话、角色设定等基础设施。

7.2.3 人类在环（Human‑in‑the‑loop）：把风险关口握在手里

即便工作流与多 Agent 协作再智能，真实业务中仍然无法完全脱离人类判断，尤其在高风险、高成本、高敏感度的场景下，如法律合规、金融决策、医疗建议、大规模生产变更、舆情响应等。人类在环（Human‑in‑the‑loop） 的设计，正是要在自动化与可控性之间找到平衡：该自动的自动，该人工确认的一定要停下来让人看一眼。

• 关键步骤人工确认 在工作流图中，通常会显式标记若干“人工审批/确认节点”：
  • 例如在自动生成合同时，在签发前需要法务和业务负责人双重确认；
  • 在自动运维系统中，对涉及生产环境变更、批量重启、配置修改的操作，必须有值班工程师点击确认；
  • 在内容生成场景中，对大量公开发布或品牌敏感的内容，需要人工审稿。 Orchestrator 会在这些节点暂停自动执行，将中间结果发送给对应人类角色，并在收到反馈后再继续后续流程。
• 反馈驱动的策略更新 人类不仅在某一时刻“按下通过或驳回”，更重要的是反馈的内容可以被系统吸收：
  • 将人工修改后的版本与原始输出对比，作为“正负样例”记录下来，用于后续的提示优化或模型微调。
  • 基于统计分析，识别出哪些类型的任务/步骤最容易被人工反复修改，进而优化对应 Agent 的提示词、工具组合或工作流设计。
  • 在极端或异常案例中，人工可以添加“黑名单 / 白名单 / 特殊规则”，直接影响系统在类似情况中的策略选择。
• 风险分级与可观测性 最后，人类在环还需要一套清晰的风险分级和可观测性机制：
  • 根据任务类型、影响面、金额规模、涉及的敏感信息等维度，将流程分为不同风险等级，对应不同强度的人类介入（如只读审阅、强制审批、多级审批）。
  • 通过日志、审计、可视化看板等方式，让运营/管理人员能够随时追踪哪些任务在跑、跑到哪一步了、哪些地方触发了人工介入、历史上出现过哪些失败与人工修正。 这些能力不仅提高了系统在企业内的可接受度，也为后续的合规审查和责任划分提供了基础。

综合来看，工具调用与执行（7.1）解决的是“单步行动”的问题，而工作流编排与多 Agent 协作（7.2）则试图回答“如何把很多步串起来，让不同角色长期协作并可控运行”。两者叠加，再加上人类在环与良好的工程实践，构成了面向真实业务场景的新一代智能应用底座。