AI Agent = LLM + 工具 + 上下文窗口

Epiphany Y

272人浏览 · 2026-08-09 12:35:00

Epiphany Y · 2026-08-09 12:35:00 发布

AI Agent = LLM + 工具 + 上下文窗口？用通俗例子把这句话讲明白

📖 目录

1. 先说结论：Agent 不是"更会聊天的模型"
2. LLM：负责"理解"和"决定下一步"，但它本身不等于知识库或执行器
- 2.1 一个很简单的例子
- 2.2 LLM 做不了什么？
3. 工具：让 LLM 从"会说"变成"能查、能算、能做"
4. 上下文窗口：Agent 当前能"看见"的工作材料
5. 把三者串起来：Agent 如何一步一步完成任务？
6. 一个更生活化的例子：安排出差
7. 为什么还要补上"状态、权限和安全边界"？
8. 四个常见误解
9. 一个最小可用 Agent 的伪代码
10. 总结：把 Agent 当作"会使用工具的工作流大脑"

很多人会用一句话概括 AI Agent：

AI Agent = LLM + 工具 + 上下文窗口。

这句话作为入门理解没有问题，但它还少说了几个工程上很重要的部分：任务循环、状态/记忆、权限与安全边界。

更准确一点，可以把它写成下面这个“心智模型”。它不是数学公式，而是一张帮助理解的地图：

$\text{AI Agent} \approx \text{LLM} + \text{Tools} + \text{Context} + \text{Control Loop} + \text{State} + \text{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 做不了什么？

在没有额外连接的情况下，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% 是不是最大下降”“应该怎样解释”“还要不要继续查看原因”。

所以一个典型过程是：

$\text{LLM 发起调用} \rightarrow \text{工具执行} \rightarrow \text{结果写回上下文} \rightarrow \text{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 负责理解与权衡，工具负责获得实时航班、酒店和日历信息，上下文窗口负责保存约束与候选方案。

这里三部分分别在做什么？

LLM 做的事

提取约束：下周、上海、两天、预算 3000 元、不坐红眼航班；
判断缺的信息：出发城市、具体日期、是否需要行李额度；
制定顺序：先查航班，再查与航班时间匹配的酒店；
比较候选方案：总价、时间、转机次数、酒店距离；
把结果解释成用户能做决定的语言。

工具做的事

查询航班时刻和票价；
查询酒店的实时价格与位置；
读取日历，避开已有会议；
计算总费用；
如果用户确认，再创建行程或跳转预订页面。

上下文窗口保存什么

用户不坐红眼航班；
预算上限是 3000 元；
已经查到的三个航班候选；
每个候选对应的酒店价格；
计算出的总价和取舍理由。

如果没有上下文，模型很可能查了酒店后忘记“预算 3000 元”和“不坐红眼航班”；如果没有工具，它无法拿到实时票价；如果没有 LLM，工具查回一堆数据也不会自动变成推荐方案。

7. 为什么还要补上“状态、权限和安全边界”？

“LLM + 工具 + 上下文窗口”能解释 Agent 的核心能力，但做成稳定产品时，还必须补三块。

7.1 状态：任务进行到哪一步了？

状态（State）记录任务进度，例如：

已读取哪些文件；
哪个候选方案被淘汰；
测试是否已经通过；
用户是否已经确认执行下一步；
工作流中断后该从哪里恢复。

没有状态，Agent 在长任务中容易重复查询、遗漏步骤，或者中断后“失忆”。

7.2 权限：它能做什么，不能做什么？

工具不是给得越多越好。比如一个“整理日报”的 Agent 可能只需要读文档和写草稿，不应该默认拥有删除文件、转账或群发邮件的权限。

一个常见原则是：

读取权限可以相对宽一些；会改变外部世界的操作要更窄、更明确，并尽量要求确认。

例如：

可以先读取并展示“准备删除的文件列表”；
真正删除前，再让用户确认；
对外发送邮件前，先给出预览；
对高风险指令保留审计日志。

7.3 评估与兜底：工具出错怎么办？

现实工具可能超时、返回空结果、权限不足，甚至拿到互相矛盾的数据。一个好的 Agent 要能：

识别调用失败，而不是把失败当成功；
说明信息不足；
尝试备用路径；
对关键结果做校验；
在不确定时把决定交回用户。

这也是为什么 Agent 的质量不能只看“说话是否自然”，还要看任务成功率、工具调用成功率、错误恢复能力和安全性。

8. 四个常见误解

误解 1：给模型接上搜索，就是 Agent

不完全是。搜索只是一个工具。只有模型能够根据目标决定要不要搜索、搜索后能否继续行动、是否会根据结果调整策略，才更接近 Agent。

误解 2：上下文窗口越大，就不需要记忆和 RAG

也不对。窗口再大也不是无限的，而且把所有历史资料都塞进去会带来成本、噪声和注意力分散问题。更实用的做法是“外部保存 + 按需检索 + 关键信息摘要”。

误解 3：LLM 有工具以后，就一定能正确执行

工具调用只解决“能不能做”，不保证“该不该做、做得对不对”。目标拆分、参数检查、结果验证和权限控制仍然很重要。

误解 4：Agent 越自主越好

不一定。对于发邮件、删文件、支付、发布内容等高影响操作，合适的设计常常是“Agent 准备方案，人来确认执行”。

9. 一个最小可用 Agent 的伪代码

下面的伪代码只想说明关系，不绑定任何具体框架：

context = [系统规则, 用户目标]

while 任务尚未完成:
    next_step = LLM(context)

    if next_step 是工具调用:
        result = 调用工具(next_step)
        context.append(result)
    else:
        输出最终答案(next_step)
        break

真实系统还会加入：任务状态存储、失败重试、工具白名单、用户确认、日志、成本控制和评估等能力。