Agent 的基本架构由哪些核心组件构成

1️⃣ 考察意图

面试官想考察你对 Agent 系统架构的系统性理解，而非零散罗列组件。这是典型的系统设计类题目，刁钻点在于：多数候选人只背出“LLM + Tools + Memory”三个词，却说不清组件间的数据流和决策循环。答好了能展示：你对 Agent 从感知到行动的完整链路有工程级认知，能区分“玩具 demo”和“生产级系统”的差距，并具备设计可扩展架构的硬实力。

2️⃣ 标准答

Agent 架构的核心是感知-推理-行动循环，由 4 个必选组件和 2 个可选组件构成。下面按数据流顺序展开：

大语言模型（LLM）—— 推理与决策引擎
职责：接收当前状态（用户输入 + 记忆上下文），输出下一步行动指令（如调用工具、生成回复）。
关键点：LLM 的推理能力决定了 Agent 上限。实践中常用 GPT-4、Claude 3 或开源模型（如 Qwen2.5-72B）配合 ReAct 提示模板（Thought-Action-Observation 循环）。
工程取舍：推理速度 vs 质量。用 GPT-4 质量高但延迟大（2-3 秒/步），适合复杂任务；用 GPT-4o-mini 速度快（0.5 秒）但易出错，需配合校验机制。
工具层（Tools）—— 扩展能力边界
职责：封装外部能力，如搜索（SerpAPI）、代码执行（Python REPL）、数据库查询（SQL）、文件操作。
实现方式：每个工具定义为 JSON Schema（函数名、参数、描述），LLM 通过 function calling 选择并调用。
实际落地的坑：工具描述不清晰导致 LLM 误选。解法：为每个工具写 2-3 句自然语言描述，并加示例（如“search_web: 输入查询词，返回前 5 条搜索结果，适合找最新信息”）。
工程取舍：工具数量 vs 选择准确率。工具超过 10 个时，LLM 选择准确率下降 15-20%（【通用知识】），需用工具路由（如先分类再选子集）或分层工具树。
记忆系统（Memory）—— 状态持久化
短期记忆：对话历史（最近 N 轮），直接拼入 prompt。坑：上下文窗口溢出。解法：用 滑动窗口（保留最近 10 轮）或 摘要压缩（每 5 轮生成一次摘要）。
长期记忆：向量数据库（Chroma、Pinecone）存储关键事实、用户偏好。检索时用 BM25 + 稠密检索混合（HyDE 方法）提升召回率。
工程取舍：记忆粒度 vs 检索成本。存整段对话（粗粒度）检索快但信息噪音大；存原子化事实（细粒度）精准但存储和检索开销翻倍。生产环境常用 分层记忆：短期存原始对话，长期存摘要+关键实体。
规划模块（Planning）—— 任务分解与调度
职责：将复杂目标拆解为子任务，并决定执行顺序。常见模式：
ReAct 循环：每步“思考-行动-观察”，适合动态环境。
Plan-and-Solve：先一次性生成完整计划，再逐步执行，适合确定性任务。
实际落地的坑：计划过于抽象（如“搜索资料”），LLM 无法执行。解法：强制计划输出为可执行步骤列表（每个步骤对应一个工具调用 + 输入参数）。
执行引擎（Execution）—— 协调与反馈
职责：调度 LLM 输出，调用工具，收集结果，判断是否终止。
关键设计：循环控制——设置最大步数（默认 10 步）和超时时间（30 秒），防止死循环。错误重试：工具调用失败时，自动重试 2 次，若仍失败则回退到 LLM 重新规划。
可选组件：安全模块 & 人机交互接口
安全模块：输入输出过滤（防止 prompt 注入）、敏感操作确认（如“删除文件”需用户确认）。
人机交互接口：允许用户在关键节点打断、修改计划。生产环境必备，否则 Agent 失控风险极高。

总结：Agent 架构不是组件堆砌，而是数据流驱动的循环系统。LLM 是大脑，工具是手脚，记忆是笔记本，规划是项目经理，执行是调度员。缺少任何一个，系统都会瘫痪。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从核心组件、数据流、工程取舍三个层面回答。核心组件包括 LLM、工具、记忆、规划、执行五大块，缺一不可。数据流是：用户输入 → LLM 推理 → 规划模块拆解 → 执行引擎调用工具 → 结果反馈给 LLM → 输出。工程上最关键的取舍是推理速度 vs 质量，以及记忆粒度 vs 检索成本。总结一句：Agent 架构本质是感知-推理-行动循环的工程化实现。”

4️⃣ 高频追问 & 应对

追问 1：如果 Agent 在循环中卡住了（比如一直调用同一个工具），你怎么处理？

这是典型的死循环问题。应对策略：1）在执行引擎中设置最大步数限制（如 10 步）和重复动作检测（连续 3 次调用同一工具且参数相同则强制终止）。2）引入多样性惩罚：在 prompt 中要求 LLM 每次思考必须与前一步不同（如“如果上一步失败了，尝试换个工具或换个参数”）。3）生产环境加超时熔断：单步超过 10 秒则回退到 LLM 重新规划。实际项目中，我用 LangChain 的 AgentExecutor 配合 max_iterations=10 和 early_stopping_method="generate" 解决了 90% 的卡死问题。

追问 2：多个 Agent 协作时，架构怎么设计？

多 Agent 架构有 3 种模式：1）主从模式：一个 Orchestrator Agent 负责拆任务，Worker Agent 执行，适合任务可并行场景。2）辩论模式：多个 Agent 各自推理后投票，适合需要多角度分析的场景（如代码审查）。3）管道模式：Agent 按顺序传递结果，适合流水线任务（如数据清洗→分析→报告）。工程取舍：通信开销 vs 决策质量。辩论模式质量高但通信成本大（每个 Agent 需完整上下文），管道模式效率高但错误会累积。生产环境常用主从模式，用 Redis 做消息队列解耦。

追问 3：Agent 的记忆怎么保证一致性（比如用户修改了偏好，旧记忆还在）？

这是记忆冲突问题。解法：1）时间戳 + 版本号：每条记忆记录时间戳和版本，检索时按时间排序，最新优先。2）显式覆盖机制：当用户明确修改偏好时，在长期记忆中插入一条“覆盖”记录，并标记旧记录为“过期”。3）一致性校验：每次检索后，让 LLM 检查记忆是否矛盾（如“用户说喜欢咖啡，但记忆说喜欢茶”），若矛盾则触发重新写入。实际项目中，我用 Chroma 的 metadata 字段存时间戳，检索时加 filter 只取最新版本，解决了 95% 的冲突。

5️⃣ 避坑 · 常见错误答法

❌ 只罗列组件名称（“Agent 由 LLM、Tools、Memory 组成”），不解释交互 → ✅ 必须画出数据流图，说明“LLM 输出 action → 执行引擎调用工具 → 结果写回 memory → 下一轮 LLM 读取 memory 更新状态”。
❌ 把“规划”和“执行”混为一谈（“LLM 自己规划自己执行”） → ✅ 明确区分：规划模块负责任务分解（输出步骤列表），执行引擎负责调度与反馈（调用工具、收集结果、判断终止），LLM 只做推理决策。
❌ 忽略安全和人机交互（“Agent 全自动运行”） → ✅ 生产环境必须加安全模块（输入过滤、敏感操作确认）和人机交互接口（允许用户打断），否则上线即事故。

6️⃣ 简历呼应

如果你有 RAG 项目：从“记忆系统”切入，对比 RAG 的检索增强和 Agent 的长期记忆异同（RAG 是静态检索，Agent 是动态写入+检索），强调你用过 Chroma 做记忆存储，并处理过记忆冲突问题。
如果你只做过传统 NLP：用“管道架构”类比，把传统 NLP 的“分词→NER→分类”流水线映射到 Agent 的“LLM→规划→执行”循环，突出你对模块解耦和错误传播的理解。
如果你是校招无项目：聚焦“ReAct 循环”论文复现，用 LangChain 写一个 50 行 demo（搜索+计算器 Agent），展示你对 function calling 和工具调用的掌握，并指出“最大步数限制”这个工程细节。
Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models", 2022
Wang et al., "Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models", 2023
LangChain 官方文档：Agent 模块（AgentExecutor、Tool、Memory）
论文 "Toolformer: Language Models Can Teach Themselves to Use Tools", 2023
博客 "Building a Production-Ready Agent: Lessons from Deploying at Scale" by Anthropic

—— 本场面试完 ——