面试题 · Agent
搜索「并行」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
请阐述设计一个智能Agent框架的核心思路，包括其关键组件（如规划、记忆、工具调用、执行等）以及各模块之间的协作机制。
智能Agent的本质是**"观察-思考-行动"的闭环系统**，我将其拆解为四个核心模块：
按学习路线查看教程、项目和面试题。
分层设计解决不同时间尺度的信息需求：
| 类型 | 存储内容 | 技术方案 |
|---|---|---|
| 短期记忆 | 当前对话上下文 | 滑动窗口 + 摘要压缩 |
| 工作记忆 | 中间执行结果 | 结构化缓存（如Redis） |
| 长期记忆 | 历史经验、用户画像 | 向量数据库 + 实体关系图 |
负责状态机管理：
待执行 → 工具调用 → 结果观察 → 判断完成？
↑___________________________|数据流：用户输入 → 记忆检索（相关背景）→ 规划生成 → 工具选择 → 并行/串行执行 → 结果整合 → 记忆更新 → 响应输出
关键循环：执行结果反馈到规划模块，支持动态重规划（如工具结果不符合预期时调整策略）。
场景切入
我看你做过智能客服。假设用户说'帮我查一下上个月的订单'，Agent 需要先查用户信息，再查订单，如果订单多还得筛选。你怎么设计这个流程，让 Agent 能一步步拆解并调用不同工具？
层层追问
你设计过 Agent 吗？大概有哪些模块？……那规划和执行怎么配合？如果中间某步工具调用失败，整个流程怎么处理？
直球架构
设计一个智能 Agent 框架，核心组件包括规划、记忆、工具调用和执行。你讲讲每个组件的职责，以及它们之间怎么协作完成一个任务？
面试官问[[Agent]]框架，我觉得本质上是在问一个问题：你打算怎么把大模型的思考能力，落地成一个能真正干活的闭环系统。不是简单调个API，而是让LLM能自主观察、推理、行动，并且承担后果。
我一般会把Agent拆成四个模块：规划、记忆、工具调用、执行引擎。先说规划。规划的核心是拆解任务，但这里有个边界划分：Plan-and-Solve 和 [[ReAct]] 两种模式，到底选哪个？Plan-and-Solve适合任务步骤明确、环境稳定，比如帮用户生成一份周报，先列提纲再逐段写；ReAct更适合动态环境，比如客服场景，用户中途改需求，你得边想边做。真正落地的时候，我很少只用一种，通常是先让模型用 [[Chain-of-Thought]] 快速生成一个粗计划，然后进入ReAct循环，每一步执行完都检查是否要调整计划。说白了，规划不是一次性的，它要能动态重规划。
再说记忆。记忆分三层：短期记忆、工作记忆、长期记忆。短期记忆就是当前对话的上下文，我会用[[滑动窗口]]加摘要压缩来管理，窗口大小要调，太大浪费token，太小丢失信息。工作记忆存中间结果，比如工具返回的临时数据，我一般用结构化缓存比如Redis，方便快速查询。长期记忆存用户画像、历史经验，用[[Vector Database]]加实体关系图。这里有个坑：长期记忆的检索如果太慢，会拖死整个Agent。所以上线前我会特别关注检索延迟和召回率，通常用[[Hybrid Search]]把关键词和向量结合起来，不然纯向量检索在冷门实体上容易丢。
工具调用和执行引擎我放一起说。工具这块，关键是统一接口，所有工具按OpenAPI规范描述，description要写精准，因为LLM靠它选工具，写模糊了就会乱调。执行引擎是个状态机，从待执行到工具调用到结果观察，再判断是否继续。举个例子，在电商客服场景里，用户问'我的退款怎么还没到'。Agent先规划：查订单状态、查退款进度、查支付渠道。然后并行调用工具：订单查询、退款查询、支付系统接口。如果退款查询超时了，执行引擎要能自动重试或走备选方案，比如直接调支付渠道的接口。这个异常处理是上线最容易被忽视的，工具调用失败是常态，不处理好Agent就卡死了。
说到重规划，这里有个延伸点：当工具返回的结果和预期偏差很大时，是让模型重新规划好，还是直接回退到人工？我倾向于设定一个置信度阈值，低于阈值就主动请求确认。这个阈值怎么定，需要根据业务场景调，比如金融风控场景阈值设得很高，宁可多问一次。
所以整体来看，我更倾向于把Agent看成一个有容错能力的半自主系统，不是全自动。前提是你得把每个模块的失败场景都想到，不然上线就是灾难。