AI Agent = LLM + 工具 + 上下文窗口？用通俗例子把这句话讲明白 1. 先说结论：Agent 不是"更会聊天的模型" 2. LLM：负责"理解"和"决定下一步"，但它本身不等于知识库或执行器 2.1 一个很简单的例子 2.2 LLM 做不了什么？ 3. 工具：让 LLM 从"会说"变成"能查、能算、能做" 3.1 查询类工具：获取外部事实 3.2 读取类工具：访问文件和数据 3.3 执行类工具：计算、运行和验证 3.4 操作类工具：改变外部系统 3.5 工具调用不是魔法 3.1 查询类工具：获取外部事实 3.2 读取类工具：访问文件和数据 3.3 执行类工具：计算、运行和验证 3.4 操作类工具：改变外部系统 4. 上下文窗口：Agent 当前能"看见"的工作材料 4.1 为什么工具结果一定要回到上下文里？ 4.2 上下文窗口不是永久记忆 4.3 RAG 和 Agent 是什么关系？ 4.1 为什么工具结果一定要回到上下文里？ 4.2 上下文窗口不是永久记忆 4.3 RAG 和 Agent 是什么关系？ 5. 把三者串起来：Agent 如何一步一步完成任务？ 6. 一个更生活化的例子：安排出差 6.1 LLM 做的事 6.2 工具做的事 6.3 上下文窗口保存什么 7. 为什么还要补上"状态、权限和安全边界"？ 7.1 状态：任务进行到哪一步了？ 7.2 权限：它能做什么，不能做什么？ 7.3 评估与兜底：工具出错怎么办？ 7.1 状态：任务进行到哪一步了？ 7.2 权限：它能做什么，不能做什么？ 7.3 评估与兜底：工具出错怎么办？ 8. 四个常见误解 8.1 误解 1：给模型接上搜索，就是 Agent 8.2 误解 2：上下文窗口越大，就不需要记忆和 RAG 8.3 误解 3：LLM 有工具以后，就一定能正确执行 8.4 误解 4：Agent 越自主越好 8.1 误解 1：给模型接上搜索，就是 Agent 8.2 误解 2：上下文窗口越大，就不需要记忆和 RAG 8.3 误解 3：LLM 有工具以后，就一定能正确执行 8.4 误解 4：Agent 越自主越好 9. 一个最小可用 Agent 的伪代码 10. 总结：把 Agent 当作"会使用工具的工作流大脑" 很多人会用一句话概括 AI Agent： AI Agent = LLM + 工具 + 上下文窗口。 这句话作为入门理解没有问题，但它还少说了几个工程上很重要的部分： 任务循环、状态/记忆、权限与安全边界 。 更准确一点，可以把它写成下面这个“心智模型”。它不是数学公式，而是一张帮助理解的地图： AI Agent ≈ LLM + Tools + Context + Control Loop + State + Guardrails \text{AI Agent} \approx \text{LLM} + \text{Tools} + \text{Context} + \text{Control Loop} + \text{State} + \text{Guardrails} AI Agent ≈ LLM + Tools + Context + Control Loop + State + Guardrails 图 1：LLM、工具、上下文窗口是 Agent 的三个基础部件；循环、状态和安全机制让它真正能稳定地完成任务。 本文不从复杂框架讲起，而是用“请一个聪明但没有手脚、也记不住所有事情的助手”为线索，解释这句话到底在说什么。 1. 先说结论：Agent 不是“更会聊天的模型” 普通聊天模型最擅长的是：读懂你的话，然后生成一段看起来合理的回答。 但现实里的任务往往不是只靠“说”就能完成。例如： “帮我查一下本周北京天气，再提醒我周三带伞”； “看看这个报错来自哪个文件，并尝试修复”； “读取销售表，找出环比下降最多的品类”； “根据公司的制度文档，帮我生成一份报销申请。” 拿到外部世界的真实信息，或者改变外部世界 ； 把当前问题、历史对话和刚查到的资料放在一起思考 。 这三种能力分别对应 LLM、工具和上下文窗口。 你可以把 Agent 想成一位新入职的助理： LLM 是他的大脑，负责理解、推理、写作和决定下一步； 工具是他的浏览器、数据库权限、终端、日历和文件柜； 上下文窗口是他的办公桌，眼下正在处理的材料都摊在桌上。 桌面上没有资料，他再聪明也无法根据公司内部文档回答；没有工具，他也无法真的查询天气、读取 Excel 或提交日历；没有大脑，工具查到一堆结果也没人能把它整理成结论。 2. LLM：负责“理解”和“决定下一步”，但它本身不等于知识库或执行器 LLM（Large Language Model，大语言模型）可以理解为 Agent 的语言与推理核心。它通常会做这些事： 把结果组织成用户能看懂的回答； 发现信息不足时，决定继续查还是向用户追问。 “帮我看看这个项目为什么启动失败。” LLM 不一定马上就知道原因，但它可以先判断：要定位“启动失败”，最好先拿到报错日志；如果日志里出现文件名，再读取对应配置或代码；如果改了代码，还要运行测试确认。 这里 LLM 的价值不在于它“背出了答案”，而在于它能形成类似这样的行动计划： 先读日志 → 定位异常 → 检查相关文件 → 修改 → 验证 \text{先读日志} \rightarrow \text{定位异常} \rightarrow \text{检查相关文件} \rightarrow \text{修改} \rightarrow \text{验证} 先读日志 → 定位异常 → 检查相关文件 → 修改 → 验证 在没有额外连接的情况下，LLM 往往不能保证： 知道今天的实时天气、价格或新闻； 真的修改代码、运行程序或发邮件； 准确记住很久以前的每一次对话。 所以，“模型回答得很像”不等于“它已经把事情做完了”。真正让它能行动的，是下一部分：工具。 3. 工具：让 LLM 从“会说”变成“能查、能算、能做” 工具（Tools）本质上是提供给模型调用的外部能力。模型不直接操作互联网、文件或数据库，而是发出一个结构化请求；工具执行后，再把结果返回给模型。 3.1 查询类工具：获取外部事实 例如：网页搜索、天气查询、地图、股票行情、企业知识库检索、数据库查询。 通俗地说：LLM 负责提出问题，工具负责把“外部世界现在是什么样”查回来。 如果没有天气工具，模型只能依据过往经验猜测；有天气工具后，Agent 可以查询实时预报，再结合用户所在日期给出回答。 3.2 读取类工具：访问文件和数据 例如：读取 PDF、Excel、Word、日志、代码仓库或内部文档。 用户： 这份月度销售表中，哪个地区下降最明显？ 一个可靠的 Agent 不应凭空编数，而应该读取表格、计算环比、说明比较口径，再给出结论。 3.3 执行类工具：计算、运行和验证 例如：Python 解释器、SQL 执行器、终端命令、测试框架、图像处理程序。 用户： 把这批图片统一缩放到 1024 像素，并检查有没有损坏文件。 LLM 负责理解规则与组织流程；脚本或图像工具负责真正处理文件；处理结果再回到 LLM，形成“成功处理多少张、失败哪几张”的报告。 3.4 操作类工具：改变外部系统 例如：创建日历日程、发送邮件、提交工单、修改数据库记录、发布文章。 这一类风险最高。因为“查天气”不会改变任何东西，而“帮我给客户发邮件”会产生真实后果。因此，成熟的 Agent 通常会要求确认、限制权限，并留下操作记录。 模型通常会生成类似下面的“工具请求意图”： 工具返回结果后，模型再解释： 下午有较高降雨概率，建议带伞。 因此，工具解决的是“获取或执行”，LLM 解决的是“为什么要调用、调用什么、结果该如何理解”。 4. 上下文窗口：Agent 当前能“看见”的工作材料 上下文窗口（Context Window）可以理解为模型本次思考时可读取的一段内容。里面可能放着： 系统规则：例如“不能泄露隐私”“回答使用中文”； 工具返回的网页、文件摘要、查询结果； 图 2：上下文窗口像当前工作台；长期记忆或知识库通常在外部，需要通过检索按需放回工作台。

4.1 为什么工具结果一定要回到上下文里？ 假设 Agent 调用了数据库，查到了“华东区环比下降 12%”。 如果这个结果没有返回给 LLM，LLM 就不知道工具查到了什么，自然无法继续判断“12% 是不是最大下降”“应该怎样解释”“还要不要继续查看原因”。 LLM 发起调用 → 工具执行 → 结果写回上下文 → LLM 继续决策 \text{LLM 发起调用} \rightarrow \text{工具执行} \rightarrow \text{结果写回上下文} \rightarrow \text{LLM 继续决策} LLM 发起调用 → 工具执行 → 结果写回上下文 → LLM 继续决策 4.2 上下文窗口不是永久记忆 上下文窗口有容量限制。对话很长、文件很大、工具返回内容太多时，系统不能把所有信息永久原样放进去。常见做法是： 把项目资料存在文档库或向量数据库； 需要时用检索（RAG）找回相关片段； 保存明确的用户偏好或项目状态； 只把当前任务最相关的材料放回上下文。 可以把它类比为考试：桌面上只能摊开有限数量的参考资料；剩余资料在书架上。需要哪一页，就先去书架检索，再拿到桌上阅读。 4.3 RAG 和 Agent 是什么关系？ RAG（检索增强生成）并不等于 Agent。RAG 更像一种“查资料”能力：先从知识库找相关内容，再交给 LLM 回答。 而 Agent 更像一个完成任务的工作流程：它可以决定是否检索、是否运行代码、是否读表格、是否继续查证，甚至在授权后执行外部操作。 RAG 重点解决“回答前去哪里找资料”；Agent 重点解决“为了完成目标，下一步该做什么”。 5. 把三者串起来：Agent 如何一步一步完成任务？ 很多人以为 Agent 是“一次很长的 Prompt”。实际上，更典型的结构是一个循环。 图 3：Agent 的核心不是一次生成，而是依据工具观察结果持续调整行动。 以“排查项目启动失败”为例，完整过程可能是： 用户提出目标：项目启动失败，想知道原因。 LLM 先判断：不能直接猜，应该读日志。 Agent 调用读取工具，获得错误栈。 错误栈进入上下文窗口，LLM 发现问题指向配置文件。 Agent 再读取配置文件，并和项目依赖版本对比。 如果用户允许修改，Agent 编辑配置。 Agent 调用执行工具重新启动或运行测试。 LLM 判断问题是否解决，最后给出原因、改动和验证结果。 这就是 Agent 的关键： 它不是先想完所有步骤再一口气执行，而是在每一次观察到新信息后重新判断。 目标 → 规划 → 行动 → 观察 → 更新状态 → 下一步 \text{目标} \rightarrow \text{规划} \rightarrow \text{行动} \rightarrow \text{观察} \rightarrow \text{更新状态} \rightarrow \text{下一步} 目标 → 规划 → 行动 → 观察 → 更新状态 → 下一步 6. 一个更生活化的例子：安排出差 “下周去上海两天，帮我找合适航班、酒店，预算 3000 元以内；我不坐红眼航班。” 图 4：一次出差规划中，LLM 负责理解与权衡，工具负责获得实时航班、酒店和日历信息，上下文窗口负责保存约束与候选方案。 提取约束：下周、上海、两天、预算 3000 元、不坐红眼航班； 判断缺的信息：出发城市、具体日期、是否需要行李额度； 制定顺序：先查航班，再查与航班时间匹配的酒店； 比较候选方案：总价、时间、转机次数、酒店距离； 把结果解释成用户能做决定的语言。 如果用户确认，再创建行程或跳转预订页面。 如果没有上下文，模型很可能查了酒店后忘记“预算 3000 元”和“不坐红眼航班”；如果没有工具，它无法拿到实时票价；如果没有 LLM，工具查回一堆数据也不会自动变成推荐方案。 7. 为什么还要补上“状态、权限和安全边界”？ “LLM + 工具 + 上下文窗口”能解释 Agent 的核心能力，但做成稳定产品时，还必须补三块。 7.1 状态：任务进行到哪一步了？ 状态（State）记录任务进度，例如： 没有状态，Agent 在长任务中容易重复查询、遗漏步骤，或者中断后“失忆”。 7.2 权限：它能做什么，不能做什么？ 工具不是给得越多越好。比如一个“整理日报”的 Agent 可能只需要读文档和写草稿，不应该默认拥有删除文件、转账或群发邮件的权限。 读取权限可以相对宽一些；会改变外部世界的操作要更窄、更明确，并尽量要求确认。 可以先读取并展示“准备删除的文件列表”； 7.3 评估与兜底：工具出错怎么办？ 现实工具可能超时、返回空结果、权限不足，甚至拿到互相矛盾的数据。一个好的 Agent 要能： 识别调用失败，而不是把失败当成功； 这也是为什么 Agent 的质量不能只看“说话是否自然”，还要看任务成功率、工具调用成功率、错误恢复能力和安全性。 误解 1：给模型接上搜索，就是 Agent 不完全是。搜索只是一个工具。只有模型能够根据目标决定要不要搜索、搜索后能否继续行动、是否会根据结果调整策略，才更接近 Agent。 误解 2：上下文窗口越大，就不需要记忆和 RAG 也不对。窗口再大也不是无限的，而且把所有历史资料都塞进去会带来成本、噪声和注意力分散问题。更实用的做法是“外部保存 + 按需检索 + 关键信息摘要”。 误解 3：LLM 有工具以后，就一定能正确执行 工具调用只解决“能不能做”，不保证“该不该做、做得对不对”。目标拆分、参数检查、结果验证和权限控制仍然很重要。 误解 4：Agent 越自主越好 不一定。对于发邮件、删文件、支付、发布内容等高影响操作，合适的设计常常是“Agent 准备方案，人来确认执行”。 9. 一个最小可用 Agent 的伪代码 下面的伪代码只想说明关系，不绑定任何具体框架： 真实系统还会加入：任务状态存储、失败重试、工具白名单、用户确认、日志、成本控制和评估等能力。 10. 总结：把 Agent 当作“会使用工具的工作流大脑” AI Agent = LLM + 工具 + 上下文窗口。 LLM ：负责理解、计划、判断和表达； 工具 ：负责查询、读取、计算和执行； 上下文窗口 ：负责把当前任务需要的材料放到模型眼前； 任务循环 ：负责根据新观察不断走下一步； 状态/记忆 ：负责让长任务可持续、可恢复； 权限与安全 ：负责让 Agent 不越界。 LLM 是大脑，工具是手脚和感官，上下文窗口是办公桌；而循环、状态和权限，是让这位助理能长期、可靠、合规地工作的流程制度。 当你再看到一个 AI 产品声称“我们有 Agent”时，可以用这几个问题快速判断它到底做到了哪一步： 工具结果会不会参与下一步判断？ 它如何保存任务状态和长期知识？ 工具失败或信息不足时，它会如何处理？ 能把这些问题讲清楚的，通常才不只是“给聊天模型接了一个按钮”，而是一个真正开始具备任务执行能力的 Agent。 openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构 · [操作系统]操作系统CPU调度：概念、算法与设计权衡 · Point-and-Grasp：ZED视觉+Kinova双臂落地验证，助力MR共享控制如何构建数据闭环 · Linux操作系统:进程(1) [操作系统]操作系统CPU调度：概念、算法与设计权衡 Point-and-Grasp：ZED视觉+Kinova双臂落地验证，助力MR共享控制如何构建数据闭环 Linux操作系统:进程(1) 为遵守国家网络实名制规定，未绑定将限制内容发布与互动