📚 系列：[大模型入门：从原理到实践，技术人的认知升级指南]
一个助理和一个执行者的区别
想象两种场景。
场景一：你让同事帮你整理一份竞品分析报告。他回来问你："你想让我分析哪几家公司？格式要什么样？数据从哪里找？要不要包含财务数据？"------每一步都在等你决策，每一步都要你介入。
场景二：你让另一位同事做同样的事。他直接去搜索竞品信息，发现某家公司的官网数据不够详细，就去找第三方报告补充，写完初稿发现结构不合理，自己重新整理一遍，最后把成品发给你。你只在开头说了一句话，结果自动完成了。
前者是大模型的基本使用方式------你主导每一步，模型执行单步任务。
后者是 Agent 的工作方式------你给出目标，模型自主规划、执行、反馈、调整，直到任务完成。
这个区别，就是 Agent 和普通大模型调用的本质差异。
Agent 的核心：推理 + 工具 + 循环
要理解 Agent，需要拆解三个核心要素。
第一个要素：推理（Reasoning）
Agent 的基础仍然是大语言模型，但它不只是"回答问题"，而是在回答一个更复杂的问题：接下来我应该做什么？
面对一个多步骤任务，Agent 会先把任务拆解成子步骤，判断每一步需要什么信息，决定用什么方式获取这些信息，然后执行，再根据结果决定下一步。这个"想清楚再行动"的能力，来自大模型本身的语言推理能力。
第二个要素：工具（Tools）
光靠语言生成，Agent 能做的事情非常有限。真正让 Agent 变得强大的，是它能调用工具------搜索引擎、代码执行器、数据库查询、API 接口、文件读写......
工具把 Agent 从一个"只会说话的模型"变成了一个"能采取行动的执行者"。
第三个要素：循环（Loop）
单次执行往往不够。Agent 的真正运作方式是一个循环：思考 → 行动 → 观察 → 再思考 → 再行动...... 直到任务完成或遇到无法继续的障碍。
未完成
完成
收到目标任务
思考
这个任务需要哪些步骤？
当前知道什么，缺什么？
行动
调用合适的工具
（搜索 / 执行 / 查询 / 写入）
观察
工具返回了什么结果？
是否达到预期？
任务完成了吗？
输出最终结果
图 8-1：Agent 的核心运作循环：思考 → 行动 → 观察，反复迭代直到任务完成。这个循环让 Agent 能处理单次调用无法完成的复杂多步骤任务。
一个具体的执行过程
抽象的循环不如一个具体例子直观。
假设你让 Agent 完成这样一个任务："查一下近三个月 A 公司的新闻动态，总结可能影响我们竞品策略的关键信息。"
Agent 的执行过程大致是这样的：
写作能力 搜索工具 Agent（大模型） 写作能力 搜索工具 Agent（大模型） 用户 查询A公司近三个月新闻，总结竞品影响 分析任务：需要搜索 → 筛选 → 总结 搜索"A公司 2025年 新闻" 返回20条搜索结果 筛选：哪些与竞品策略相关？ 搜索"A公司 产品发布 2025" 返回更多相关结果 整合信息，判断关键事件 生成结构化总结报告 草稿完成 检查：是否覆盖了关键竞品维度？ 输出最终竞品分析摘要 用户
图 8-2：Agent 处理一个竞品分析任务的完整执行序列。注意它不是"一问一答"，而是多次调用工具、多次自我检查的迭代过程。这个过程用户全程不需要介入。
整个过程中，用户只说了一句话。Agent 自主完成了任务拆解、多次搜索、信息筛选、内容生成和质量自检。
工具箱：Agent 能调用什么
Agent 的能力边界很大程度上由它的"工具箱"决定。常见的工具类型有：
🤖 Agent
大模型推理核心
🔍 搜索引擎
获取实时信息
💻 代码执行器
精确计算与自动化
📁 文件读写
处理本地数据
🗄️ 数据库查询
结构化数据检索
🌐 API 接口
调用外部服务
📧 邮件通知
与人异步交互
📅 日历管理
时间与任务调度
图 8-3：Agent 可调用的工具类型全景。工具箱决定了 Agent 的能力边界------有搜索工具才能获取实时信息，有代码执行器才能做精确计算，有文件读写能力才能处理本地数据。
不同的 Agent 系统，工具箱的构成差别很大。一个专注于代码开发的 Agent，可能只需要代码执行器和文件读写；一个研究助理 Agent，需要搜索引擎、文档解析、摘要生成；一个业务流程 Agent，可能要连接 CRM 系统、邮件、日历......
工具箱越丰富，Agent 能完成的任务越复杂，但同时需要处理的"出错点"也越多。
多 Agent：让专家们协作
当任务足够复杂，单个 Agent 也会力不从心------就像一个全能员工处理复杂项目，不如专业团队协作来得高效和可靠。
多 Agent 系统的思路是：把复杂任务拆分给多个专门的 Agent，每个 Agent 专注于自己擅长的部分，由一个"协调者 Agent"负责任务分发和结果汇总。
比如做一份行业研究报告：
- 信息收集 Agent：负责搜索和抓取原始资料
- 数据分析 Agent：负责处理数字和图表
- 写作 Agent：负责把素材组织成报告
- 校对 Agent：负责检查事实和格式
这种结构让每个 Agent 的任务边界清晰，也让整体系统更容易排查和修复问题。
现实中 Agent 的局限------踩坑提前知道
Agent 听起来非常强大，但它目前还处于早期阶段，有几个现实中必须正视的局限：
错误会级联放大
单步任务出错影响有限，但 Agent 的多步骤执行让错误有机会在每一步叠加。第一步搜索结果有偏差，第二步基于偏差内容做判断，第三步基于错误判断执行......最终结果可能和预期差很远，而且很难追踪是在哪一步出了问题。
长任务的稳定性差
Agent 在短任务（3-5步）上表现尚可，但随着任务步骤增加，模型的推理一致性会下降，容易在中途"忘记"原始目标，开始按照自己的理解走偏。这个问题还没有根本解决方案，目前主要靠任务拆解和人工检查点来缓解。
工具调用的可靠性问题
模型有时会在不该调用工具的时候调用，或者参数传错，或者无法正确解析工具返回的结果。工具越多，这类问题出现的概率越高。
不知道"什么时候该停下来"
当任务进入死循环或遇到无法解决的障碍，Agent 有时不能优雅地停止和报告问题，而是继续尝试，消耗大量资源甚至造成意外影响。
渲染错误: Mermaid 渲染失败: Lexical error on line 3. Unrecognized text. ... 任务适用性评估 x-axis 任务步骤少 --> 任务步骤多 ----------------------^
图 8-4：Agent 任务适用性评估象限。右下角（步骤多 + 容错空间低）是当前 Agent 技术的高风险区，应避免在没有人工监督的情况下完全自动化。左上角（步骤少 + 容错空间高）是当前最成熟的应用区间。
Agent 的正确使用姿势
根据以上局限，目前阶段最合理的 Agent 使用原则是：
人在环路（Human-in-the-Loop）：对于关键步骤或高风险操作，在 Agent 执行前加入人工确认节点，而不是完全放手让它跑。
任务范围要小：一个聚焦的、边界清晰的任务，比一个模糊的大任务更适合 Agent。"帮我整理这十份会议纪要，提取行动项"比"帮我管理所有项目"要合适得多。
结果要可验证：能让人快速检查输出是否正确的任务，比无法验证的任务风险更低。
保留撤销能力：Agent 执行的操作，尽量选择可以撤销的。发邮件前先生成草稿、操作数据库前先备份、修改代码前保留原始版本。
本章小结
- Agent = 大模型 + 工具调用能力 + 思考→行动→观察的自主循环；
- 与普通调用的区别：用户给目标，Agent 自主规划并执行多步骤任务；
- 三要素：推理 （任务拆解和判断）、工具 （扩展行动能力）、循环（迭代直到完成）；
- 多 Agent 系统把复杂任务分配给多个专门 Agent 协作完成；
- 当前主要局限：错误级联放大、长任务稳定性差、工具调用可靠性不足、不知何时停止；
- 现阶段最佳实践：人在环路、任务范围聚焦、结果可验证、操作可撤销。