你如何定义一个基于 LLM 的智能体（Agent）？它通常由哪些核心组件构成
1️⃣ 考察意图
这道题看似是“背概念”，但面试官真正想考察的是：你是否真正理解 Agent 不是“LLM + 工具”的简单堆砌，而是有完整流程的自主系统。 刁钻点在于：很多人能背出“感知-规划-行动”的教科书定义，但说不清规划模块如何与记忆模块协同、工具调用失败后如何恢复。答好了能展示你对系统架构的工程直觉——知道哪些组件是必须的、哪些是锦上添花，以及它们之间的 trade-off。
2️⃣ 标准答
一个基于 LLM 的智能体（Agent）是一个能自主感知环境、通过 LLM 推理制定计划、调用外部工具执行动作，并根据反馈循环迭代的完整流程系统。它不是简单的“LLM + API 调用”，而是把 LLM 当作推理引擎，嵌入到一个有状态、有记忆、有纠错能力的架构中。
核心组件分为以下 5 块，缺一不可：
- LLM 推理引擎（大脑）：负责所有高层决策。不是单纯生成文本，而是输出结构化动作（如 JSON 格式的
{"action": "search", "query": "..."}）。关键取舍：用 GPT-4 级别模型做规划，用 GPT-3.5 做简单工具调用——前者推理强但成本高，后者速度快但容易出错。实际落地时，我常用 ReAct 框架（论文《ReAct: Synergizing Reasoning and Acting in Language Models》），让 LLM 在“思考-行动-观察”循环中交替输出。 - 规划模块（Planner）：把复杂任务分解成子步骤。常见方法有：
- Chain-of-Thought (CoT)：直接让 LLM 一步步推理。
- Task Decomposition：用 LLM 生成子任务列表（如 AutoGPT 的“思考-计划-执行”循环）。
- Tree-of-Thoughts (ToT)：探索多条路径，用 BFS/DFS 剪枝。实际坑：规划太细（比如 20 步）会导致 LLM 上下文爆炸，太粗（比如 2 步）又不够用。我通常限制子任务数 ≤ 5，并用 HuggingGPT 的思路把子任务分配给不同模型。
- 记忆模块（Memory）：分短期和长期。
- 短期记忆：当前对话上下文，用 Sliding Window 或 KV Cache 管理（比如只保留最近 4K tokens）。
- 长期记忆：用向量数据库（如 Chroma、Pinecone）存储历史交互的 embedding，检索时用 BM25 + Dense Retrieval 混合（BM25 处理关键词，DPR 处理语义）。工程取舍：全量检索太慢，我通常只检索最近 10 条相关记录，并给每条记录打时间戳权重。
- 工具调用接口（Tool Use）：让 LLM 能调用外部 API、执行代码、查询数据库。核心是函数调用（Function Calling）——把工具描述（name, description, parameters）作为 system prompt 传给 LLM，LLM 输出
{"function": "get_weather", "args": {"city": "北京"}}。落地坑：LLM 经常编造工具参数（比如把城市名拼错），我加了一层参数校验器（用 Pydantic 定义 schema），校验失败就重试或报错。 - 执行与反馈循环（Execution & Feedback Loop）：Agent 不是一次执行完就结束，而是迭代。每次工具调用后，把结果（成功/失败/部分结果）喂回 LLM，让它决定下一步。关键设计：用 Self-Consistency 做投票——对同一个子任务，让 LLM 生成 3 个不同计划，选出现频率最高的。如果连续 3 次失败，就触发回退机制（比如回到上一步重新规划）。
典型架构：单智能体（如 AutoGPT）适合简单任务，多智能体协作（如 ChatDev 的“程序员+测试员”角色）适合复杂软件工程。但多智能体有通信开销问题——两个 Agent 互相发消息可能死循环，我通常加一个仲裁器（Orchestrator）来限制对话轮次。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从定义、核心组件、关键设计三个层面回答。定义上，Agent 是 LLM 作为推理引擎的自主完整流程系统，不是简单堆砌。核心组件包括 LLM 引擎、规划模块（如 ReAct/CoT）、记忆模块（短期+长期）、工具调用接口（Function Calling）、执行与反馈循环。关键设计是规划与记忆的协同，以及工具调用失败后的回退机制。总结一句：Agent 的本质是让 LLM 从‘生成文本’变成‘执行动作’，核心挑战是可靠性和状态管理。”
4️⃣ 高频追问 & 应对
追问 1：如果工具调用返回的结果是错的（比如 API 返回了错误数据），Agent 怎么处理？
分三层处理。第一层：参数校验——在调用前用 Pydantic 检查参数合法性，比如城市名必须是中文且存在于数据库。第二层：结果校验——调用后检查返回格式，比如 JSON 是否合法、字段是否缺失。第三层：语义校验——用 LLM 判断结果是否合理（比如查询北京天气返回了 50°C，明显异常）。如果三层都失败，触发重试机制：最多重试 2 次，每次换不同参数（比如用拼音代替中文）。如果还失败，就回退到上一步，重新规划。实际落地时，我还会记录失败日志，用于后续微调 LLM 的 tool-use 能力。
追问 2：多智能体协作中，如何避免两个 Agent 互相矛盾或死循环？
核心是加一个仲裁器（Orchestrator）。仲裁器不是另一个 LLM，而是一个规则引擎：限制每个 Agent 的发言轮次（比如最多 3 轮），并定义优先级（比如“程序员 Agent”的输出优先级高于“测试员 Agent”）。如果出现矛盾（比如一个说用 A 方案，一个说用 B 方案），仲裁器用投票机制——让第三个 Agent 做裁判，或者直接选择置信度高的方案。另外，用 Finite State Machine 管理 Agent 状态，比如“规划中->执行中->验证中”，避免状态混乱。
追问 3：Agent 的长期记忆如何保证不污染短期决策？
关键是把长期记忆降级为“参考信息”，而不是“决策依据”。具体做法：长期记忆检索后，不直接拼进 prompt，而是先让 LLM 判断是否相关（用 Relevance Scoring，比如 cosine similarity > 0.7 才保留）。然后，把长期记忆放在 system prompt 的末尾，并加一句“以下信息仅供参考，以当前上下文为准”。这样 LLM 会优先用短期记忆做决策，长期记忆只作为辅助。如果长期记忆和短期记忆冲突（比如用户刚说“我不喜欢咖啡”，但长期记忆里记录他喜欢咖啡），我让 LLM 以短期记忆为准，并更新长期记忆。
5️⃣ 避坑 · 常见错误答法
- ❌ 把 Agent 定义为“LLM + 工具调用”，只提 Function Calling 不提规划/记忆/反馈。 → ✅ 必须强调 Agent 是完整流程系统，规划、记忆、反馈循环是区分“Agent”和“简单 API 调用”的关键。
- ❌ 说“记忆模块就是向量数据库”，不提短期记忆和长期记忆的区分。 → ✅ 要明确短期记忆是上下文窗口（Sliding Window），长期记忆是外部存储（向量 DB + 混合检索），并解释两者如何协同。
- ❌ 只讲理论（比如 ReAct 论文），不提实际落地坑（比如参数校验、重试机制）。 → ✅ 必须给出工程取舍，比如“限制子任务数 ≤ 5”或“用 Pydantic 校验参数”，展示实战经验。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“记忆模块”切入，说你用向量数据库做长期记忆时遇到了检索精度问题，然后引入了 BM25 + Dense 混合检索，并对比了不同 chunking 策略（比如 256 vs 512 tokens）对 Agent 决策的影响。
- 如果你只做过传统 NLP：用“规划模块”类比——把 CoT 比作传统 NLP 里的“pipeline 设计”，把 ReAct 比作“迭代式序列标注”，强调 Agent 的规划本质是“任务分解”，和传统 NLP 的“子任务划分”一脉相承。
- 如果你是校招无项目：聚焦 ReAct 论文复现 demo——说你用 LangChain 实现了一个天气查询 Agent，遇到了工具调用失败的问题，然后自己加了重试机制和参数校验，并评估了任务完成率（从 70% 提升到 92%）。
- 论文《ReAct: Synergizing Reasoning and Acting in Language Models》（Yao et al., 2023）
- 论文《HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in HuggingFace》（Shen et al., 2023）
- 博客《Building Effective Agents》by Anthropic（2024）
- 工具 LangChain / AutoGPT / ChatDev 的官方文档
- 论文《Tree of Thoughts: Deliberate Problem Solving with Large Language Models》（Yao et al., 2023）