Agent架构与多智能体编排 思维导图总览Agent基础架构工具调用与Function Calling多Agent编排记忆与会话管理稳定性与可观测性一、Agent基础架构Agent四大核心模块规划模块Planner职责接收用户任务拆解成可执行的子步骤实现方式ReAct推理 / 思维树 / 计划-执行分离面试点能说出“先规划再执行”和“边想边做”两种模式的适用场景记忆模块Memory短期记忆当前对话上下文存在内存或Redis长期记忆跨会话的用户偏好/历史事实存向量库或数据库工具模块Tools职责封装外部能力搜索/计算/API调用/数据库查询面试点工具描述写得好不好直接影响调用准确率执行模块Executor职责根据规划调用工具把结果反馈给规划模块循环思考→行动→观察→再思考直到任务完成ReAct框架全称Reasoning Acting工作流程Thought思考我现在该做什么需要什么信息Action行动调用哪个工具传什么参数Observation观察工具返回了什么结果循环直到得出最终答案举例面试现场推演用户问“帮我查下深圳今天天气如果下雨就提醒我带伞”Thought需要先查天气Action调用天气API城市深圳日期今天Observation返回“小雨22-25℃”Thought天气是小雨需要提醒用户带伞Final Answer“深圳今天小雨22-25℃建议带伞出门”和传统LLM的区别传统LLM用户问→模型直接答只能依赖训练数据Agent用户问→思考→调工具→观察→再思考→答能获取实时信息Agent vs RAG的区别RAG检索文档→拼到Prompt→生成答案单向流水线适合知识问答Agent自主规划→调用工具→获取信息→循环决策多步推理外部行动适合复杂任务计划模式先规划后执行一次性拆完所有步骤再逐步执行优点全局最优步骤清晰缺点中间出错不好调整边执行边规划ReAct模式走一步看一步优点灵活能根据中间结果调整缺点可能走弯路效率低二、工具调用与Function Calling工具定义与描述工具描述三要素名称简洁明确动词名词如“get_weather”功能描述一句话说清楚工具干什么什么时候该用它反面案例“查询信息” → 正面“根据城市名称查询当天天气”参数定义参数名、类型、是否必填、取值范围、示例示例city: string, 必填, 中文城市名, 如“深圳”面试点工具描述写得好调用准确率能差30%以上Function Calling流程步骤一用户提问 → LLM分析意图步骤二LLM判断需要调哪个工具生成参数返回JSON步骤三你的代码真正执行工具调用查数据库/调API/算数步骤四工具返回结果拼回对话上下文步骤五LLM根据结果决定继续调工具还是直接回复参数抽取与校验LLM生成的参数不可信必须后端校验类型校验string是不是真stringint是不是真int范围校验日期不能是2月30号金额不能为负必填校验必填参数缺失时反问用户补充参数模糊时的处理“帮我查一下那个订单” → 反问“请提供订单号”不要让LLM猜猜错成本远高于多问一句兜底参数解析失败 → 返回明确错误信息给LLM → 让LLM修正重试工具调用容错与重试超时控制每个工具调用设独立超时搜索3s复杂查询10s重试策略网络超时等瞬时错误重试1-2次加退避业务错误如“订单不存在”不重试直接反馈给LLM降级策略工具挂了 → 告诉LLM该工具不可用 → 让它尝试其他方案所有工具都不可用 → 降级为纯对话模式回复用户工具返回异常结果的识别返回为空/格式不对/明显不合理 → 标记失败触发重试或降级工具调用标准化 - MCP协议是什么AI应用与外部工具/数据源之间的标准化通信协议Model Context Protocol类比USB统一设备连接核心原理MCP Server暴露工具和资源的服务端定义好工具的输入输出格式MCP ClientAgent端通过标准协议调用Server暴露的工具通信方式JSON-RPC over HTTP/SSE 或 stdio为什么需要MCP以前每个Agent框架有自己工具定义方式换框架要重写现在MCP统一标准后写一次工具定义多个框架都能用开发步骤能说出大概步骤一用Python/TS实现MCP Server注册工具和资源步骤二启动Server暴露HTTP或stdio接口步骤三Agent端通过MCP Client连接Server自动发现可用工具面试场景推演面试官问“用户说‘帮我查深圳天气’怎么设计工具调用”回答示范工具定义get_weather(city: string, date?: string)LLM输出{“tool”: “get_weather”, “params”: {“city”: “深圳”}}后端校验city非空、是合法城市名真正调APIrequests.get(天气API, params{“city”: “深圳”})返回结果{“temperature”: “22-25℃”, “condition”: “小雨”}LLM二次处理把JSON转成自然语言回复用户三、多Agent编排什么时候需要多Agent单Agent就够了的情况任务边界清晰单一工具链能完成举例查天气、搜文档、简单问答必须上多Agent的情况不同子任务需要不同专业能力一个懂合同一个懂财务子任务之间需要并行处理再汇总需要多个独立角色协作如一个写代码一个做代码审查面试点能一句话说清“多Agent解决的是任务异构性和并行协作问题”三种主流编排模式顺序编排Chain流程A做完→B接着做→C收尾适用场景流水线任务数据清洗→分析→生成报告工具LangChain的Chain/SequentialChain局限性不支持循环和条件分支复杂任务不够灵活图编排Graph流程节点通过边连接支持循环和条件路由适用场景需要回溯、自我反思、多分支决策的复杂Agent工具LangGraph面试点图编排是LangGraph的核心原生支持循环和状态管理协作编排Orchestration流程主Agent分发任务给多个子Agent子Agent并行执行主Agent汇总适用场景多角色协作如一个Agent查资料一个Agent写初稿一个Agent审核实现方式主控Agent 子Agent池通过消息队列或直接调用通信LangGraph图编排详解核心概念State状态图中流转的共享数据所有节点都能读写Node节点一个处理单元可以是LLM调用、工具调用、判断逻辑Edge边节点间的连接分普通边和条件边条件路由根据上一步结果决定走哪条分支如检索相关走生成不相关走改写循环与回溯传统Chain是单向DAG不能回头LangGraph可以设计回路生成不满意→回到检索→再生成和LangChain的关系简单任务用Chain需要循环/条件/多Agent协作换LangGraph多Agent状态共享与通信状态共享方案共享State所有Agent共用一份状态对象适合紧密协作场景LangGraph的State模式消息传递Agent之间通过消息队列通信适合松耦合场景每个Agent独立运行通过Redis或MQ通信黑板模式Agent往公共区域写结果其他Agent按需读取面试点能说清什么时候用共享状态简单什么时候用消息传递复杂解耦多Agent常见问题与解决死循环两个Agent互相等待对方结果 → 设全局最大步数限制超时强行终止结果冲突两个子Agent给出矛盾结论 → 主Agent做仲裁或按优先级/置信度选一个成本失控多Agent来回调用token消耗翻倍 → 限制最大步数、缓存中间结果、能用单Agent别上多Agent四、记忆与会话管理短期记忆会话上下文是什么当前对话轮次内的所有消息存储方式直接拼在Prompt里把最近N轮对话的user/assistant消息传给LLM存在Redis/内存按session_id存取每次请求读出来拼Prompt窗口管理问题对话长了之后消息太多加上工具返回结果直接爆token解决策略滑动窗口只保留最近N轮一般3-5轮旧的直接丢弃摘要压缩超过N轮后用LLM把旧对话压缩成一段摘要重要信息提取把用户关键信息名字/偏好/任务目标单独存旧对话可以丢面试点能讲清“滑动窗口实现简单但丢信息摘要压缩保信息但多一次LLM调用”长期记忆跨会话持久化是什么跨不同会话仍需要记住的用户信息举例用户偏好“我只看Python相关的内容”、历史事实“上次你帮我查过那个bug”存储方案结构化存储用户画像存关系型数据库用户ID、偏好标签、常用功能适合明确的属性型信息非结构化存储记忆片段存向量数据库Embedding后存起来新问题来时同时检索知识库和用户记忆库适合对话片段、模糊偏好记忆更新策略对话结束时批量提取关键信息写入记忆相同信息覆盖旧的冲突信息做标记面试点长期记忆的本质就是给用户建一个私人小知识库上下文组装流程步骤一用户发来消息步骤二读短期记忆最近N轮对话步骤三检索长期记忆从向量库搜相关历史片段步骤四检索外部知识RAG知识库步骤五按优先级拼Prompt拼接顺序System Prompt → 长期记忆 → 知识库检索结果 → 近期对话 → 当前问题步骤六控制总Token数超出则从优先级最低的开始裁多轮对话常见问题话题切换上一轮聊天气这一轮突然问代码Agent还带着天气的上下文跑偏 → 检测话题变化后自动清理或降权旧上下文指代消解用户说“刚才那个方案有什么缺点”Agent不知道“那个”指什么 → 保留最近对话时确保被指代实体在窗口内或用查询改写补全指代词Token消耗失控每轮都把全部历史拼进去第10轮时Prompt比第1轮长10倍 → 固定窗口摘要压缩重要信息提取三层组合五、稳定性与可观测性可观测性体系全链路追踪每次请求生成唯一trace_id贯穿所有节点链路示例用户提问→Agent思考→调工具A→失败→重试→调工具B→成功→生成回复关键日志节点用户输入原始问题 session_id trace_idAgent思考当前Thought内容 决定调哪个工具工具调用工具名 入参 返回结果 耗时 是否成功最终回复回复内容 总耗时 总步数 token消耗核心监控指标业务指标任务成功率、用户满意度、平均完成步数性能指标端到端延迟P50/P99、首Token延迟、每步平均耗时成本指标单次任务平均token消耗、工具调用次数、LLM调用次数告警规则任务失败率 10% → 立即告警P99延迟超过阈值如30s→ 告警单次任务步数 20 → 疑似死循环告警LLM API连续失败 → 紧急告警超时与熔断超时控制整体任务超时一个Agent任务最多跑60秒超时终止单步超时每次LLM调用设15-30秒工具调用设3-10秒超时处理终止当前步骤尝试降级方案记录日志最大步数限制Agent思考-行动循环设上限如15步超过强制终止熔断机制触发条件某个工具连续失败5次 / LLM API连续超时熔断动作暂停调用该工具N秒期间直接跳过或用备用方案恢复机制半开探测成功一次后恢复正常调用面试点Agent比RAG更容易死循环必须有步数限制和超时降级与兜底分级降级链路L1工具A超时 → 换工具B备用工具L2所有工具不可用 → 降级为纯对话模式话术“抱歉当前无法查询实时信息我根据已有知识为您回答……”L3LLM也挂了 → 返回固定兜底话术 告警异常场景处理Agent返回了错误答案 → 查trace_id → 看是哪步出错 → 工具返回错了还是LLM理解错了Agent中途卡死 → 看日志最后停在哪个节点 → 超时还是工具无响应 → 针对性修复金融/敏感场景Agent只做信息查询不直接执行资金操作必须人机协同人工确认后执行面试场景推演Agent事故排查面试官问“线上Agent返回了错误答案你怎么排查”回答示范第一步拿到这个请求的trace_id去日志系统查全链路第二步看Agent的每次Thought和Action定位到具体哪一步出的问题可能原因A工具返回了错误数据 → 检查工具是否正常、数据源是否有问题可能原因B工具返回正确但LLM理解错了 → 优化Prompt或工具返回格式可能原因C检索到了不相关的文档 → 调整检索策略或重排序第三步修复后把这次case加入测试集防止回归
思维导图笔记： Agent架构与多智能体编排
发布时间：2026/5/27 3:08:37
Agent架构与多智能体编排 思维导图总览Agent基础架构工具调用与Function Calling多Agent编排记忆与会话管理稳定性与可观测性一、Agent基础架构Agent四大核心模块规划模块Planner职责接收用户任务拆解成可执行的子步骤实现方式ReAct推理 / 思维树 / 计划-执行分离面试点能说出“先规划再执行”和“边想边做”两种模式的适用场景记忆模块Memory短期记忆当前对话上下文存在内存或Redis长期记忆跨会话的用户偏好/历史事实存向量库或数据库工具模块Tools职责封装外部能力搜索/计算/API调用/数据库查询面试点工具描述写得好不好直接影响调用准确率执行模块Executor职责根据规划调用工具把结果反馈给规划模块循环思考→行动→观察→再思考直到任务完成ReAct框架全称Reasoning Acting工作流程Thought思考我现在该做什么需要什么信息Action行动调用哪个工具传什么参数Observation观察工具返回了什么结果循环直到得出最终答案举例面试现场推演用户问“帮我查下深圳今天天气如果下雨就提醒我带伞”Thought需要先查天气Action调用天气API城市深圳日期今天Observation返回“小雨22-25℃”Thought天气是小雨需要提醒用户带伞Final Answer“深圳今天小雨22-25℃建议带伞出门”和传统LLM的区别传统LLM用户问→模型直接答只能依赖训练数据Agent用户问→思考→调工具→观察→再思考→答能获取实时信息Agent vs RAG的区别RAG检索文档→拼到Prompt→生成答案单向流水线适合知识问答Agent自主规划→调用工具→获取信息→循环决策多步推理外部行动适合复杂任务计划模式先规划后执行一次性拆完所有步骤再逐步执行优点全局最优步骤清晰缺点中间出错不好调整边执行边规划ReAct模式走一步看一步优点灵活能根据中间结果调整缺点可能走弯路效率低二、工具调用与Function Calling工具定义与描述工具描述三要素名称简洁明确动词名词如“get_weather”功能描述一句话说清楚工具干什么什么时候该用它反面案例“查询信息” → 正面“根据城市名称查询当天天气”参数定义参数名、类型、是否必填、取值范围、示例示例city: string, 必填, 中文城市名, 如“深圳”面试点工具描述写得好调用准确率能差30%以上Function Calling流程步骤一用户提问 → LLM分析意图步骤二LLM判断需要调哪个工具生成参数返回JSON步骤三你的代码真正执行工具调用查数据库/调API/算数步骤四工具返回结果拼回对话上下文步骤五LLM根据结果决定继续调工具还是直接回复参数抽取与校验LLM生成的参数不可信必须后端校验类型校验string是不是真stringint是不是真int范围校验日期不能是2月30号金额不能为负必填校验必填参数缺失时反问用户补充参数模糊时的处理“帮我查一下那个订单” → 反问“请提供订单号”不要让LLM猜猜错成本远高于多问一句兜底参数解析失败 → 返回明确错误信息给LLM → 让LLM修正重试工具调用容错与重试超时控制每个工具调用设独立超时搜索3s复杂查询10s重试策略网络超时等瞬时错误重试1-2次加退避业务错误如“订单不存在”不重试直接反馈给LLM降级策略工具挂了 → 告诉LLM该工具不可用 → 让它尝试其他方案所有工具都不可用 → 降级为纯对话模式回复用户工具返回异常结果的识别返回为空/格式不对/明显不合理 → 标记失败触发重试或降级工具调用标准化 - MCP协议是什么AI应用与外部工具/数据源之间的标准化通信协议Model Context Protocol类比USB统一设备连接核心原理MCP Server暴露工具和资源的服务端定义好工具的输入输出格式MCP ClientAgent端通过标准协议调用Server暴露的工具通信方式JSON-RPC over HTTP/SSE 或 stdio为什么需要MCP以前每个Agent框架有自己工具定义方式换框架要重写现在MCP统一标准后写一次工具定义多个框架都能用开发步骤能说出大概步骤一用Python/TS实现MCP Server注册工具和资源步骤二启动Server暴露HTTP或stdio接口步骤三Agent端通过MCP Client连接Server自动发现可用工具面试场景推演面试官问“用户说‘帮我查深圳天气’怎么设计工具调用”回答示范工具定义get_weather(city: string, date?: string)LLM输出{“tool”: “get_weather”, “params”: {“city”: “深圳”}}后端校验city非空、是合法城市名真正调APIrequests.get(天气API, params{“city”: “深圳”})返回结果{“temperature”: “22-25℃”, “condition”: “小雨”}LLM二次处理把JSON转成自然语言回复用户三、多Agent编排什么时候需要多Agent单Agent就够了的情况任务边界清晰单一工具链能完成举例查天气、搜文档、简单问答必须上多Agent的情况不同子任务需要不同专业能力一个懂合同一个懂财务子任务之间需要并行处理再汇总需要多个独立角色协作如一个写代码一个做代码审查面试点能一句话说清“多Agent解决的是任务异构性和并行协作问题”三种主流编排模式顺序编排Chain流程A做完→B接着做→C收尾适用场景流水线任务数据清洗→分析→生成报告工具LangChain的Chain/SequentialChain局限性不支持循环和条件分支复杂任务不够灵活图编排Graph流程节点通过边连接支持循环和条件路由适用场景需要回溯、自我反思、多分支决策的复杂Agent工具LangGraph面试点图编排是LangGraph的核心原生支持循环和状态管理协作编排Orchestration流程主Agent分发任务给多个子Agent子Agent并行执行主Agent汇总适用场景多角色协作如一个Agent查资料一个Agent写初稿一个Agent审核实现方式主控Agent 子Agent池通过消息队列或直接调用通信LangGraph图编排详解核心概念State状态图中流转的共享数据所有节点都能读写Node节点一个处理单元可以是LLM调用、工具调用、判断逻辑Edge边节点间的连接分普通边和条件边条件路由根据上一步结果决定走哪条分支如检索相关走生成不相关走改写循环与回溯传统Chain是单向DAG不能回头LangGraph可以设计回路生成不满意→回到检索→再生成和LangChain的关系简单任务用Chain需要循环/条件/多Agent协作换LangGraph多Agent状态共享与通信状态共享方案共享State所有Agent共用一份状态对象适合紧密协作场景LangGraph的State模式消息传递Agent之间通过消息队列通信适合松耦合场景每个Agent独立运行通过Redis或MQ通信黑板模式Agent往公共区域写结果其他Agent按需读取面试点能说清什么时候用共享状态简单什么时候用消息传递复杂解耦多Agent常见问题与解决死循环两个Agent互相等待对方结果 → 设全局最大步数限制超时强行终止结果冲突两个子Agent给出矛盾结论 → 主Agent做仲裁或按优先级/置信度选一个成本失控多Agent来回调用token消耗翻倍 → 限制最大步数、缓存中间结果、能用单Agent别上多Agent四、记忆与会话管理短期记忆会话上下文是什么当前对话轮次内的所有消息存储方式直接拼在Prompt里把最近N轮对话的user/assistant消息传给LLM存在Redis/内存按session_id存取每次请求读出来拼Prompt窗口管理问题对话长了之后消息太多加上工具返回结果直接爆token解决策略滑动窗口只保留最近N轮一般3-5轮旧的直接丢弃摘要压缩超过N轮后用LLM把旧对话压缩成一段摘要重要信息提取把用户关键信息名字/偏好/任务目标单独存旧对话可以丢面试点能讲清“滑动窗口实现简单但丢信息摘要压缩保信息但多一次LLM调用”长期记忆跨会话持久化是什么跨不同会话仍需要记住的用户信息举例用户偏好“我只看Python相关的内容”、历史事实“上次你帮我查过那个bug”存储方案结构化存储用户画像存关系型数据库用户ID、偏好标签、常用功能适合明确的属性型信息非结构化存储记忆片段存向量数据库Embedding后存起来新问题来时同时检索知识库和用户记忆库适合对话片段、模糊偏好记忆更新策略对话结束时批量提取关键信息写入记忆相同信息覆盖旧的冲突信息做标记面试点长期记忆的本质就是给用户建一个私人小知识库上下文组装流程步骤一用户发来消息步骤二读短期记忆最近N轮对话步骤三检索长期记忆从向量库搜相关历史片段步骤四检索外部知识RAG知识库步骤五按优先级拼Prompt拼接顺序System Prompt → 长期记忆 → 知识库检索结果 → 近期对话 → 当前问题步骤六控制总Token数超出则从优先级最低的开始裁多轮对话常见问题话题切换上一轮聊天气这一轮突然问代码Agent还带着天气的上下文跑偏 → 检测话题变化后自动清理或降权旧上下文指代消解用户说“刚才那个方案有什么缺点”Agent不知道“那个”指什么 → 保留最近对话时确保被指代实体在窗口内或用查询改写补全指代词Token消耗失控每轮都把全部历史拼进去第10轮时Prompt比第1轮长10倍 → 固定窗口摘要压缩重要信息提取三层组合五、稳定性与可观测性可观测性体系全链路追踪每次请求生成唯一trace_id贯穿所有节点链路示例用户提问→Agent思考→调工具A→失败→重试→调工具B→成功→生成回复关键日志节点用户输入原始问题 session_id trace_idAgent思考当前Thought内容 决定调哪个工具工具调用工具名 入参 返回结果 耗时 是否成功最终回复回复内容 总耗时 总步数 token消耗核心监控指标业务指标任务成功率、用户满意度、平均完成步数性能指标端到端延迟P50/P99、首Token延迟、每步平均耗时成本指标单次任务平均token消耗、工具调用次数、LLM调用次数告警规则任务失败率 10% → 立即告警P99延迟超过阈值如30s→ 告警单次任务步数 20 → 疑似死循环告警LLM API连续失败 → 紧急告警超时与熔断超时控制整体任务超时一个Agent任务最多跑60秒超时终止单步超时每次LLM调用设15-30秒工具调用设3-10秒超时处理终止当前步骤尝试降级方案记录日志最大步数限制Agent思考-行动循环设上限如15步超过强制终止熔断机制触发条件某个工具连续失败5次 / LLM API连续超时熔断动作暂停调用该工具N秒期间直接跳过或用备用方案恢复机制半开探测成功一次后恢复正常调用面试点Agent比RAG更容易死循环必须有步数限制和超时降级与兜底分级降级链路L1工具A超时 → 换工具B备用工具L2所有工具不可用 → 降级为纯对话模式话术“抱歉当前无法查询实时信息我根据已有知识为您回答……”L3LLM也挂了 → 返回固定兜底话术 告警异常场景处理Agent返回了错误答案 → 查trace_id → 看是哪步出错 → 工具返回错了还是LLM理解错了Agent中途卡死 → 看日志最后停在哪个节点 → 超时还是工具无响应 → 针对性修复金融/敏感场景Agent只做信息查询不直接执行资金操作必须人机协同人工确认后执行面试场景推演Agent事故排查面试官问“线上Agent返回了错误答案你怎么排查”回答示范第一步拿到这个请求的trace_id去日志系统查全链路第二步看Agent的每次Thought和Action定位到具体哪一步出的问题可能原因A工具返回了错误数据 → 检查工具是否正常、数据源是否有问题可能原因B工具返回正确但LLM理解错了 → 优化Prompt或工具返回格式可能原因C检索到了不相关的文档 → 调整检索策略或重排序第三步修复后把这次case加入测试集防止回归
