完整题目
请描述一个典型的大语言模型Agent系统通常由哪些核心组件构成，并说明每个组件的主要功能。
答案要点
- 核心组件完整列举（规划、记忆、工具、执行）
- 各组件功能边界清晰
- 组件间协作流程说明
- 提及主流范式（ReAct/CoT）
- 结合实际框架（LangChain/LlamaIndex等）
一个典型的大模型Agent系统通常包含四大核心组件：
1. 规划模块（Planning）
- 负责将复杂任务拆解为可执行的子步骤
- 主流范式：CoT（链式思考）、ReAct（推理+行动交替）、ToT（树状搜索）
- 输出：执行计划或下一步Action
2. 记忆模块（Memory）
- 短期记忆：当前对话上下文、多轮交互历史
- 长期记忆：向量数据库存储的知识、用户画像、过往经验
- 作用：打破上下文长度限制，实现个性化服务
3. 工具模块（Tools）
- 外部能力接口：搜索引擎、代码解释器、数据库、API等
- 通过Function Calling或Tool Learning实现标准化调用
- 关键：工具描述（description）要清晰，让模型知道何时调用哪个
4. 执行与反馈模块（Action/Execution）
- 执行工具调用，获取Observation（观察结果）
- 将结果反馈给LLM，进入下一轮推理循环
- 终止条件判断：任务完成或达到最大迭代次数
典型协作流程：
用户输入 → 规划拆解 → 选择工具 → 执行获取结果 → 记忆更新 → 判断完成/继续循环实际框架如LangChain、AutoGPT、MetaGPT都是围绕这套架构做的工程封装。设计时的关键权衡是：规划粒度（细粒度易控制但慢）、工具数量（多工具提升能力但增加选择难度）、记忆召回精度。
换一种问法，检查是否真正理解
场景切入
假设你在做一个智能客服Agent，用户问“帮我查一下订单”，系统先查了物流，然后又问“那能退款吗”，这个流程里，Agent内部是怎么一步步决定要查什么、怎么回答的？你觉得它由哪些核心模块组成？
层层追问
你理解的Agent系统一般是怎么工作的？……比如用户提一个复杂请求，它怎么决定先做什么后做什么？……那它怎么记住前面聊过什么？……这些逻辑背后，你觉得有哪些固定的组件？
直球架构
请直接描述一个典型的大模型Agent系统由哪些核心组件构成，每个组件负责什么功能？比如规划、记忆、工具这些，它们之间怎么协作？
练习口述回答 · 约4分钟
- 本质是任务分解与执行闭环
- 规划模块的拆解策略与场景选择
- 记忆模块的短长期分工与落地坑
- 工具模块的接口标准化与模型选择
- 执行反馈的循环与终止判断
这道题其实问的是，当大模型不再只是对话，而是要主动完成一个任务时，系统该怎么搭。核心就四个东西：规划、记忆、工具、执行。但我觉得更重要的是理解它们怎么串成闭环，以及落地时哪些地方容易出问题。
先说规划模块。它的本质是把用户一个模糊的意图，比如“帮我分析一下这批订单的异常情况”，拆成模型自己能一步步执行的子任务。主流做法有 [[Chain-of-Thought]]、[[ReAct]] 和 [[Tree-of-Thoughts]]。实际业务里，CoT 适合步骤明确、逻辑链固定的场景，比如客服退款流程；ReAct 更适合需要外部信息实时反馈的，比如查库存、调价格；ToT 在需要搜索多条路径时用，但成本很高。真正落地时我一般会混合，比如先用 CoT 做粗拆分，再对不确定的步骤用 ReAct 去查外部数据。这里有个前提：模型本身得有足够强的推理能力，否则拆出来的步骤要么太粗、要么逻辑跳步，后面全崩。
再一个是记忆模块。很多人以为记忆就是存对话历史，其实分短期和长期。短期就是当前会话上下文，靠 [[Sliding Window]] 或 [[KV Cache]] 控制长度；长期用来跨会话复用知识，比如用户偏好、历史工单，通常用 [[Vector Database]] 存。但落地时有个常见坑：长期记忆的召回精度不够。如果只靠向量相似度，经常召不回真正关键的信息。我一般会结合关键词和结构化标签做 [[Hybrid Search]]，先过滤再排序。另外，记忆更新时机也很关键，是每次对话结束都写，还是等用户确认？写错了反而污染。
工具模块，说白了就是给模型配的“手脚”。搜索引擎、数据库、代码解释器、API 都算。关键是把接口标准化，让模型知道什么时候该调哪个。这里有个设计原则：工具描述要足够清晰，包括参数、返回值、典型使用场景。模型是靠描述来选工具的，描述模糊它就乱选。比如一个“查询订单状态”的 API，描述里得写清楚“输入订单号，返回状态码和预计时间”，最好再给个 few-shot 例子。
最后是执行与反馈。模型调完工具拿到结果，得判断要不要继续。常见失败场景是模型进入死循环，比如查一次没查到就反复查，或者结果不对也不反思。我会设置最大迭代次数，并在每次循环前让模型先总结一下当前进展，再决定下一步。终止条件不能只靠模型自己判断，得结合业务规则，比如退款金额超过阈值就强制转人工。
说到这个，其实还有一个有意思的方向：当多个 [[Agent]] 协作时，规划是怎么拆的。比如一个 Agent 拆完任务，分给其他 Agent 执行，它们之间怎么同步状态？这涉及 [[Multi-Agent]] 的通信和共识机制，我觉得比单 Agent 更难控制。
所以整体上，我会把 Agent 系统看作一个“规划-执行-反思”的闭环，而不是四个独立模块。上线前我会特别关注规划粒度和工具选择的容错性，因为模型一次选错工具，后面可能全错。