完整题目
请系统阐述大模型智能体（Agent）的基本工作原理，详细说明其核心组成部分（如规划、记忆、工具调用、行动执行与反馈机制），并结合具体示例解释各模块如何协同工作以完成复杂任务。
本文目录
Agent核心架构：感知-规划-行动-反馈的闭环
大模型Agent的本质是以LLM为"大脑"的自主决策系统，通过环境交互完成复杂任务。核心模块协同如下：
1. 规划模块（Planning）
- 作用：将复杂目标拆解为可执行的子任务
- 关键范式：
- CoT（思维链）：逐步推理，适合数学/逻辑题
- ReAct：推理（Reasoning）+ 行动（Acting）交替，"我想→我做→我观察"循环
- ToT（思维树）：多路径探索，保留最优解
2. 记忆模块（Memory）
| 类型 | 功能 | 典型实现 |
|---|---|---|
| 短期记忆 | 当前对话上下文、任务状态 | 滑动窗口、摘要压缩 |
| 长期记忆 | 用户偏好、历史经验、领域知识 | 向量数据库（如Milvus）、知识图谱 |
3. 工具调用（Tool Use）
- 流程：LLM生成结构化调用指令 → 解析执行外部API → 结果回填上下文
- 关键：Function Calling机制让模型学会"何时调用、传什么参数"
4. 执行与反馈（Action & Reflection）
- 执行工具后，观察结果，判断任务是否完成
- 反思机制：失败时回溯原因，重新规划（如Reflexion框架）
协同示例：查询"北京明天天气并提醒我带伞"
[规划] 拆解：查天气 → 判断降雨 → 生成提醒
↓
[记忆] 读取用户位置"北京"、偏好"微信提醒"
↓
[工具] 调用天气API，参数：location="北京", date="明天"
↓
[反馈] 结果：降雨概率80% → 确认需提醒 → 调用微信通知接口
↓
[反思] 若API超时 → 重试或切换备用源关键洞察：Agent不是单次LLM调用，而是多轮决策循环，每轮根据环境反馈动态调整策略，这才是"智能"所在。
学习建议
建议从经典Agent架构（如ReAct、Reflexion）入手，理解感知-思考-行动循环，结合RAG与工具调用案例加深对模块协作的理解。
换一种问法，检查是否真正理解
场景切入
假设我们要做一个智能客服Agent，用户问“帮我查一下上周的订单”，然后又说“把那个订单取消掉”。Agent需要先查订单、再调取消接口。你想想，从接收问题到执行动作，中间要经过哪些模块？它们怎么配合才能完成这个任务？
层层追问
大模型Agent要实现自主完成任务，你觉得核心需要哪几块能力？……比如面对一个复杂目标，它怎么拆解步骤？……如果中间需要查数据库或者调API，模型怎么知道该调哪个？……调用后结果怎么影响下一步？
直球架构
请系统讲一下大模型Agent的工作原理，包括规划、记忆、工具调用、执行和反馈这几个核心模块。它们各自负责什么，怎么协同？最好结合一个具体例子说明整个闭环过程。
练习口述回答 · 约4分钟
- 一句话点题：Agent本质是LLM驱动的自主决策循环
- 规划模块：CoT、ReAct、ToT的适用场景与取舍
- 记忆与工具调用：短期记忆 vs 长期记忆，Function Calling的工程前提
- 协同示例：天气查询任务串起全流程
- 落地风险与反思机制：失败场景、回溯、我的倾向
这道题问的是大模型[[智能体]]怎么工作，说白了，就是怎么让LLM不只是一个聊天机器人，而是能自己规划、调用工具、根据反馈调整，最后完成一个复杂任务。它的本质是一个感知-规划-行动-反馈的闭环，LLM是大脑，其他模块是手和脚。
先说规划模块。这里最核心的是怎么把一个大目标拆成可执行的子任务。我常用的几个范式：[[Chain-of-Thought]]就是一步一步推理，适合数学题或者逻辑题，比如算个折扣，模型一步步算，不容易出错。[[ReAct]]呢，是推理和行动交替，模型想一步，做一步，观察结果再想下一步，适合需要跟外部交互的场景，比如查完天气再决定要不要提醒。还有[[Tree-of-Thoughts]]，它会同时探索多条路径，最后选最优的，适合开放式的规划问题，比如写一个旅行计划，但代价也大。实际落地，我一般不会只用一种，而是根据任务复杂度混合着来。简单任务CoT就够了，复杂一点用ReAct，如果任务容错率低，比如金融交易，我会考虑ToT，但得控制分支数，不然延迟受不了。
再一个，记忆和工具调用。记忆分短期和长期。短期就是当前对话上下文，用[[Sliding Window]]或者摘要压缩，保证模型知道刚才说了什么。长期记忆存用户偏好、历史经验，我一般用[[向量数据库]]，比如Milvus，把用户画像、常见问题都[[embedding]]进去，需要的时候检索出来。工具调用这块，关键是[[Function Calling]]机制，模型得学会什么时候调用、传什么参数。这里有个常见失败场景：模型乱调用，比如用户问“今天天气怎么样”，它去调了订外卖的API。所以上线我会特别关注两点，一是给工具的description写清楚，二是加一层校验，检查参数合法性，不然很容易翻车。
举个例子，用户说“查一下北京明天天气，如果下雨提醒我带伞”。模型先规划，拆成查天气、判断降雨、生成提醒三步。从短期记忆里知道用户在北京，长期记忆可能存了用户偏好微信提醒。然后调天气API，参数传北京和明天日期。API返回降雨概率80%，模型判断需要提醒，再调微信通知接口。如果API超时了，反思机制就触发，重试或者换备用源。这就是一个完整的闭环。
落地时有个关键点：Agent不是单次调用，而是多轮决策循环。每轮根据环境反馈调整策略，这才是智能所在。但这里有个风险：循环次数多了，累积错误和延迟都会上升。我一般会设最大轮数，比如5轮，超过就报错。另外，我会特别关注[[Reflexion]]框架，让模型在失败时回溯原因，重新规划，而不是硬着头皮继续。
还有一个有意思的点是，如果任务涉及多个工具协同，比如先查天气再订外卖，工具调用的顺序和依赖怎么管理。我倾向用有向无环图来建模工具流，而不是让模型自由发挥，这样可控性更高。
所以，我更愿意把Agent看作一个带反馈的决策系统，而不是单纯的LLM调用链。核心是规划、记忆、工具、反思四个模块的协作，但落地时一定要考虑失败场景和边界，比如乱调用、超时、累积错误，这些才是真正考验工程能力的地方。