第8篇Agent模式与工具调用——让AI从说话到做事适用人群高阶 | 字数约25,000字 | 预计阅读时间60分钟前言截止到上一篇我们的对话式 AI的能力已经相当完整了它知道如何理解复杂的问题它能够基于丰富的上下文进行推理和回答它可以用思维链做深入分析它可以按照指定的格式输出但它有一个根本性的局限它只能说不能做。当用户问帮我订一张明天去北京的机票时模型可以写出订票的步骤是…“但无法真正执行订票操作。当用户说帮我查一下数据库中的用户数据时模型可以说查询语句是 SELECT * FROM users”但无法真正执行这个查询。Agent模式的出现解决了这个问题。它让大模型不再是会说话的图书馆而是会行动的智能体——可以调用工具、执行操作、完成任务。这是提示词工程从对话阶段进化到行动阶段的标志。第一章什么是Agent1.1 Agent的定义在 AI 领域Agent智能体是指一个能够感知环境、做出决策、采取行动的自主系统。一个典型的 AI Agent 包含三个核心组件大脑LLM负责理解、推理、决策——就是我们前7篇讨论的模型能力工具集Tool Set一组可供调用的外部能力——搜索、计算、查询数据库、发送邮件等执行循环Loop决策→行动→观察→再决策的循环过程这三者的关系可以这样理解LLM 是大脑工具是手脚执行循环是行动流程。1.2 从 LLM 到 Agent 的进化维度传统LLMAgent能力边界只能生成文本可以调用外部工具信息来源训练数据训练数据实时数据外部系统行动能力回答问题执行操作自主性被动响应主动规划与执行状态管理单次对话可维护长期状态传统 LLM 的局限知识截止于训练数据的时间点无法知道今天的新闻无法访问私有数据无法查询你的数据库无法执行真实世界的操作无法发送邮件、创建日历事件Agent 的突破可以调用搜索工具获取实时信息可以调用 API 访问外部系统可以执行真实世界的操作1.3 Agent的经典架构目前主流的 Agent 架构可以归纳为以下几种架构一ReActReasoning Acting由 Google 研究者提出的经典架构。核心思想推理和行动交替进行。1. Thought思考分析当前状态决定下一步做什么 2. Action行动调用一个工具 3. Observation观察获取工具返回的结果 4. 回到步骤1基于新信息继续思考ReAct 架构是 Agent 系统的基础目前大多数 Agent 框架LangChain、AutoGPT、BabyAGI等都在此基础上构建。架构二Plan-and-Execute规划执行先规划再执行而不是边想边做。Phase 1 - Planning: 1. 分析用户请求 2. 制定执行计划多个步骤的顺序安排 3. 确保计划可行 Phase 2 - Execution: 4. 按计划逐步执行 5. 每一步调用对应的工具 6. 遇障碍时重新规划架构三Multi-Agent多智能体多个 Agent 协作完成复杂任务每个 Agent 有专门的职责。Agent A协调者接收用户请求分配任务给其他Agent Agent B研究员负责信息检索和调查 Agent C写作者负责内容创作和编辑 Agent D审核者负责质量检查和安全审查第二章工具调用的机制2.1 工具的定义在 Agent 系统中“工具”Tool是指模型可以调用的外部函数或 API。每个工具通常包含名称工具的唯一标识描述工具的功能说明让模型知道什么时候该用这个工具参数工具需要的输入参数实现工具背后的实际代码或 API 调用工具定义的示例JSON Schema 格式{tools:[{type:function,function:{name:get_weather,description:获取指定城市的当前天气,parameters:{type:object,properties:{city:{type:string,description:城市名称如北京、上海},unit:{type:string,enum:[celsius,fahrenheit],description:温度单位}},required:[city]}}}]}2.2 工具调用的流程用户提问 北京今天天气怎么样需要带伞吗 Step 1模型分析 模型判断用户想知道北京的天气 → 需要调用 get_weather 工具 模型输出{tool: get_weather, params: {city: 北京, unit: celsius}} Step 2系统执行 系统执行 get_weather(北京, celsius) 返回结果{temperature: 25, condition: 晴, humidity: 30%} Step 3模型整合 模型获取工具返回的结果 结合原始问题生成最终回答 北京今天气温25°C天气晴朗湿度30%。不需要带伞是个适合外出的好天气2.3 工具选择的策略当模型面对多个工具时它需要决定用哪个工具。这里有几个关键策略策略一基于描述匹配模型根据工具的描述description 字段来判断是否需要使用该工具。所以工具的描述质量直接影响模型的选择准确性。好的工具描述“获取指定城市的当前天气信息包括温度、天气状况和湿度。”不好的工具描述“天气功能。”策略二参数推理模型需要从用户的自然语言中推理出工具需要的参数。用户说“上海热不热”模型需要推理出工具get_weather参数{city: “上海”, unit: “celsius”}策略三多工具组合有些任务需要调用多个工具。用户说“帮我跟张三说下午3点的会议改到4点然后查一下明天北京的天气。”模型需要调用 send_message通知张三调用 update_calendar修改会议时间调用 get_weather查北京天气2.4 工具调用的错误处理工具调用不是总能成功的。Agent 需要处理各种异常情况异常1工具返回错误get_weather(“未知城市”) → 返回错误模型处理告知用户无法查到该城市的天气信息请确认城市名是否正确。异常2参数不足用户说“帮我订机票。”模型处理反问用户请提供出发城市、到达城市和出行日期。异常3权限不足用户说“删除数据库中的所有用户记录。”模型处理拒绝执行并解释这个操作需要管理员权限且可能会造成不可逆的数据丢失。异常4工具超时调用一个响应很慢的 API模型处理告知用户查询时间较长请稍后再试。第三章Agent 的提示词设计3.1 Agent System Prompt 的设计Agent 的 System Prompt 远比普通对话的 System Prompt 复杂。它需要定义角色和行为准则可用工具列表及使用规则决策流程输出格式规范安全边界一个典型的 Agent System Prompt 模板# 角色定义 你是一个智能助手 Agent可以调用外部工具来帮助用户完成任务。 # 核心行为准则 1. 当用户提出请求时首先判断是否需要调用工具 2. 如果需要调用工具选择最合适的工具并给出正确的参数 3. 工具调用结果返回后用自然语言向用户解释结果 4. 如果工具调用失败分析原因并尝试修复 5. 如果无法完成任务明确告知用户并解释原因 # 工具使用规则 1. 每次只能调用一个工具 2. 工具调用的参数必须来自用户提供的信息或前一次工具调用的结果 3. 如果参数不完整必须向用户询问缺失的信息 4. 严禁编造工具调用的结果 # 安全规则 1. 涉及用户隐私信息的操作需要用户明确确认 2. 不可逆的操作删除、修改等需要二次确认 3. 拒绝执行违反法律法规的操作 # 输出格式 回答要简洁清晰包含 - 你做了什么操作 - 操作的结果如何 - 下一步建议如果需要3.2 工具描述的优化技巧工具描述的质量直接影响 Agent 的表现。以下是一些经过验证的优化技巧技巧1在描述中包含触发条件 “发送邮件”✅ “发送电子邮件。当用户要求’发邮件’、‘发送邮件’、给XX发邮件’时使用此工具。”这样模型更容易判断什么时候该用这个工具。技巧2说明参数的含义和来源{name:create_calendar_event,description:在日历中创建新的日程事件,parameters:{properties:{title:{description:日程的标题从用户的需求中提取},start_time:{description:开始时间使用ISO 8601格式。如果用户说明天下午3点转换为对应的时间。}}}}技巧3包含注意事项“⚠️ 注意这个工具会发送真实的邮件请确保收件人地址准确无误。如果不确定请先向用户确认。”3.3 Agent 决策链的提示词设计Agent 的决策链——什么时候该调用工具什么时候不该——需要精心设计。决策链模板当你收到用户的请求时请按以下流程决策 Step 1 - 理解意图用户真正想要的是什么 Step 2 - 评估能力这个需求是否需要调用工具 - 如果只是回答问题 → 直接回答 - 如果需要实时数据 → 调用工具获取 - 如果需要执行操作 → 调用工具执行 - 如果兼具多个需求 → 规划多步操作 Step 3 - 选择工具如果需要调用工具... - 从可用工具列表中选出最合适的工具 - 检查工具的参数是否齐全 - 如果参数不完整向用户询问 Step 4 - 处理结果 - 工具调用成功 → 用自然语言向用户呈现结果 - 工具调用失败 → 重试或向用户解释失败原因 Step 5 - 确认闭环 - 确认用户的问题是否已完全解决 - 如果未完全解决继续下一步操作 - 如果已完全解决询问用户是否还有其他需求第四章Agent 的观察-思考-行动循环4.1 ReAct 循环详解ReActReasoning Acting是 Agent 系统的核心循环。我们来详细拆解这个循环回合开始 │ ├─ 输入用户请求 系统状态 │ ├─ Thought思考 │ 模型分析当前状态决定下一步的最佳行动 │ 输出我需要先查询用户的账户信息然后才能处理退款请求 │ ├─ Action行动 │ 模型选择工具并给出参数 │ 输出{tool: get_user_info, params: {user_id: 12345}} │ ├─ Observation观察 │ 系统执行工具并返回结果 │ 输入{name: 张三, balance: 5000, status: active} │ ├─ 回到 Thought基于观察结果继续推理 │ 输出用户账户状态正常余额充足可以进行退款处理 │ ├─ Action行动 │ 输出{tool: process_refund, params: {user_id: 12345, amount: 500}} │ ├─ Observation观察 │ 输入{status: success, refund_id: RF20260519} │ ├─ Thought思考 │ 输出退款成功我可以告知用户了 │ └─ Final Answer最终回答 输出已经成功为您处理了500元的退款退款编号为RF20260519。预计3个工作日内到账。4.2 循环次数控制Agent 可能会陷入无限循环——不断调用工具但始终无法完成任务。控制策略策略一最大循环次数设置一个硬性限制如 10 次循环超过后强制输出当前结果或报错。策略二循环检测监控系统是否在重复相同的操作相同的工具相同的参数如果检测到重复操作超过 3 次中断循环并告知用户无法完成策略三带终止条件的循环提示在 System Prompt 中加入“如果你已经完成了用户的目标或者确认该目标无法完成请输出’FINAL:前缀的最终回答并结束循环。”4.3 记忆与状态管理Agent 需要维护状态——它做了什么、做到了哪一步、已经获得了什么信息。状态管理的方式方式一对话上下文最简单的方式——Agent 的所有思考和行动都记录在对话上下文中。模型通过看到之前的对话来了解当前状态。优点实现简单缺点Token消耗大长对话中注意力稀释方式二外部记忆在对话上下文之外维护一个独立的状态存储{ session_id: session_001, steps_completed: [step1, step2], intermediate_results: { user_info: {name: 张三, balance: 5000}, order_info: {id: ORD123, status: pending} }, remaining_tasks: [step3, step4] }优点减少Token消耗状态更清晰缺点实现复杂度增加方式三压缩摘要在关键节点如每5次循环后让模型对之前的对话做一次摘要然后用摘要替换完整的对话历史。优点在Token消耗和信息保留之间取得平衡缺点可能有信息丢失第五章多Agent协作5.1 为什么需要多Agent单个 Agent 虽然强大但在面对复杂任务时仍有局限角色冲突同一个 Agent 既要创意又要严谨难以兼顾上下文污染一个子任务的执行过程可能干扰对其他子任务的处理安全风险如果 Agent 出错整个任务都会受影响多 Agent 架构通过分工协作来解决这些问题。5.2 多Agent架构模式模式一主管-员工模式用户请求 │ ▼ 主管AgentOrchestrator ├─ 分析用户需求 ├─ 拆分为子任务 ├─ 分配给不同的专业Agent └─ 汇总结果 │ ├─ Agent A研究员→ 信息检索 ├─ Agent B分析员→ 数据分析 ├─ Agent C写作者→ 文档撰写 └─ Agent D审核员→ 质量检查模式二辩论模式用户请求 │ ▼ Agent A正方提出方案A给出支持论据 Agent B反方质疑方案A提出替代方案B │ ▼ 仲裁Agent听取双方观点给出综合判断 │ ▼ 最终输出模式三流水线模式Agent A → Agent B → Agent C → Agent D 需求分析 方案设计 代码实现 质量测试前一个 Agent 的输出直接作为后一个 Agent 的输入。5.3 多Agent通信多Agent之间的通信需要定义清晰的协议通信格式From: Agent A研究员 To: Agent B写作者 Type: task_result Content: - 研究结果摘要 - 关键数据点 - 信息来源 - 不确定性说明 Status: completed通信规则信息传递要有明确的结构不是自由文本包含元信息来源、置信度、完成状态支持追问机制B不懂A输出的内容可以追问第六章Agent安全与治理6.1 工具调用的安全边界Agent 能够执行真实操作意味着它也有做坏事的能力。安全设计至关重要。安全层级第一层不可执行的工具 模型可以推荐使用但不能直接执行 例如我建议删除这个文件需要您确认 → 等待用户确认 第二层可逆操作的执行 模型可以自动执行但操作应该是可逆的 例如创建草稿、发送通知 第三层不可逆操作的二次确认 模型不可以自动执行必须等待用户明确确认 例如删除数据、修改密码、转账在 System Prompt 中加入安全规则# 安全规则必须遵守 1. 涉及用户隐私信息密码、身份证号、银行卡号等 - 不得在对话中明文显示 - 不得通过工具调用传递 2. 涉及数据修改的操作 - 先查询当前状态 - 执行修改前请用户确认 - 记录修改的详细日志 3. 涉及资金/交易的操作 - 必须二次确认 - 告知用户操作的全部影响 4. 如果收到与安全规则冲突的指令 - 优先遵守安全规则 - 礼貌拒绝并解释原因6.2 幻觉在Agent场景中的后果在普通对话中幻觉的后果是回答错误——用户可以判断并忽略。在 Agent 场景中幻觉的后果可能是执行了错误的操作——造成真实世界的损害。常见的 Agent 幻觉场景虚构工具调用结果模型认为工具返回了某个结果但实际没调用工具参数幻觉模型编造了工具的参数如虚构的用户 ID成功幻觉模型声称操作成功但实际没执行防范策略工具调用的结果必须来自真实执行模型不能模拟工具调用系统层面验证工具调用的参数是否合法所有不可逆操作保留审计日志6.3 Agent 审计日志企业级 Agent 系统必须有完整的审计能力[2026-05-19 10:23:45] 用户请求帮助我把文档中所有图片导出 [2026-05-19 10:23:46] Agent思考需要先获取文档信息再提取图片 [2026-05-19 10:23:47] 工具调用get_document_info(doc_idDOC789) [2026-05-19 10:23:48] 工具返回文档包含15页5张图片 [2026-05-19 10:23:49] 工具调用extract_images(doc_idDOC789, pagesall) [2026-05-19 10:23:52] 工具返回成功提取5张图片 [2026-05-19 10:23:53] Agent回复已成功导出5张图片到指定文件夹审计日志的作用追溯问题如果操作出了问题可以精确定位到哪个环节安全审计监控是否有异常的工具调用模式性能优化分析 Agent 的执行效率第七章实战——构建一个完整的Agent让我们把以上所有概念整合起来构建一个完整的 Agent。场景个人助理Agent这个 Agent 能够查询天气管理日历事件发送邮件搜索信息第1步定义工具集[{name:get_weather,description:查询指定城市的当前天气和未来3天的天气预报。当用户问天气、会不会下雨、多少度时使用。,parameters:{city:{type:string,description:城市名称如北京}}},{name:create_calendar_event,description:在日历中创建新的日程事件。当用户说安排会议、创建日程、提醒我时使用。,parameters:{title:{type:string,description:日程标题},start_time:{type:string,description:开始时间ISO 8601格式},end_time:{type:string,description:结束时间ISO 8601格式},attendees:{type:array,items:{type:string},description:参会人邮箱列表}}},{name:send_email,description:发送电子邮件。当用户说发邮件、发送邮件、通知XX时使用。,parameters:{to:{type:string,description:收件人邮箱},subject:{type:string,description:邮件主题},body:{type:string,description:邮件正文}}},{name:web_search,description:搜索互联网获取最新信息。当用户问搜索、查一下、最新的、今天/昨天发生了什么时使用。,parameters:{query:{type:string,description:搜索关键词}}}]第2步System Prompt# 角色 你是一位智能个人助理Agent可以帮助用户完成日程管理、信息查询和沟通协作等任务。 # 可用工具 你有以下工具可以使用 1. get_weather查询天气 2. create_calendar_event创建日历事件 3. send_email发送邮件 4. web_search搜索信息 # 工作流程 当你收到用户的请求时按照以下流程工作 Step 1 - 分析需求用户想要什么这个需求是否需要调用工具 Step 2 - 选择工具 - 如果需要调用工具选择最合适的 - 确保参数完整、准确 - 不确定的参数向用户确认 Step 3 - 执行调用 - 调用工具 - 等待结果返回 Step 4 - 处理结果 - 用自然语言向用户解释结果 - 多步任务则继续下一步 Step 5 - 确认闭环 - 询问用户是否还有其他需求 # 安全规则 - 发送邮件前确认收件人地址无误 - 创建日程前确认时间和日期 - 不可执行涉及资金、密码、删除数据的操作 - 如有疑问先向用户确认第3步用户交互示例用户明天下午3点安排一个团队会议叫上张三和李四。 Agent思考 - 用户想要创建日程事件 - 需要确定标题、时间、参会人 - 时间明天2026-05-20下午3点 - 参会人张三、李四但不知道邮箱 Agent回复 好的我来安排。请问张三和李四的邮箱地址是什么另外会议的标题叫什么 用户标题叫项目进度同步会张三的邮箱是zhangcompany.com李四的是licompany.com。 Agent工具调用 create_calendar_event({ title: 项目进度同步会, start_time: 2026-05-20T15:00:00, end_time: 2026-05-20T16:00:00, attendees: [zhangcompany.com, licompany.com] }) 工具返回成功 Agent回复 已为您创建了项目进度同步会时间明天5月20日下午3点到4点已邀请张三和李四参加。还需要其他帮助吗写在最后Agent 是提示词工程的终极形态——它不只是一个会说话的 AI而是一个能行动的 AI。从提示词工程的角度看Agent 的提示词设计比普通对话要复杂得多需要定义工具和工具的使用规则需要设计决策链和行动流程需要考虑安全边界和错误处理需要管理状态和记忆但这也意味着掌握了 Agent 提示词设计你就掌握了 AI 应用开发的核心技能。回顾整个系列我们经历了这样的进化提示词 → 结构化提示词 → Few-shot/CoT → Agent (问) (规范问) (教它想) (让它做)每一步都是能力的一次跃迁。Agent 是当前提示词工程发展的前沿方向也是未来 AI 应用的核心范式。课后练习工具设计练习为你自己常用的 3 个功能如天气查询、日历管理、邮件发送设计工具定义JSON Schema。Agent决策链练习写一个完整的 Agent System Prompt包含角色定义、工具描述、决策流程和安全规则。实战练习使用你熟悉的 Agent 框架如 LangChain或手动模拟 ReAct 循环构建一个能完成查询天气→根据天气决定是否安排户外活动→创建日程的 Agent。下一篇预告《第9篇多模态提示词——文本、图像、代码协同作战》AI 的能力不再局限于文字。图像识别、代码执行、音频处理——多模态能力正在快速普及。下一篇将介绍如何编写能够利用多模态能力的提示词。Agent 把 AI 从纸上谈兵变成了真刀真枪。每一次工具调用都是一次思考到行动的跨越。