企业官网建设流程全解析

Agent架构与多智能体编排 思维导图

• 总览
  • 1. Agent基础架构
  • 2. 工具调用与Function Calling
  • 3. 多Agent编排
  • 4. 记忆与会话管理
  • 5. 稳定性与可观测性

一、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是不是真string，int是不是真int
    • 范围校验：日期不能是2月30号，金额不能为负
    • 必填校验：必填参数缺失时反问用户补充
  • 参数模糊时的处理
    • “帮我查一下那个订单” → 反问“请提供订单号”
    • 不要让LLM猜，猜错成本远高于多问一句
  • 兜底：参数解析失败 → 返回明确错误信息给LLM → 让LLM修正重试
• 工具调用容错与重试
  • 超时控制：每个工具调用设独立超时（搜索3s，复杂查询10s）
  • 重试策略
    • 网络超时等瞬时错误：重试1-2次，加退避
    • 业务错误（如“订单不存在”）：不重试，直接反馈给LLM
  • 降级策略
    • 工具挂了 → 告诉LLM该工具不可用 → 让它尝试其他方案
    • 所有工具都不可用 → 降级为纯对话模式回复用户
  • 工具返回异常结果的识别
    • 返回为空/格式不对/明显不合理 → 标记失败，触发重试或降级
• 工具调用标准化 - MCP协议
  • 是什么：AI应用与外部工具/数据源之间的标准化通信协议（Model Context Protocol），类比USB统一设备连接
  • 核心原理
    • MCP Server：暴露工具和资源的服务端，定义好工具的输入输出格式
    • MCP Client：Agent端，通过标准协议调用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非空、是合法城市名
    • 真正调API：requests.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_id
    • Agent思考：当前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：所有工具不可用 → 降级为纯对话模式（话术：“抱歉，当前无法查询实时信息，我根据已有知识为您回答：……”）
    • L3：LLM也挂了 → 返回固定兜底话术 + 告警
  • 异常场景处理
    • Agent返回了错误答案 → 查trace_id → 看是哪步出错 → 工具返回错了还是LLM理解错了
    • Agent中途卡死 → 看日志最后停在哪个节点 → 超时还是工具无响应 → 针对性修复
    • 金融/敏感场景：Agent只做信息查询，不直接执行资金操作；必须人机协同，人工确认后执行
• 面试场景推演（Agent事故排查）
  • 面试官问：“线上Agent返回了错误答案，你怎么排查？”
  • 回答示范
    • 第一步：拿到这个请求的trace_id，去日志系统查全链路
    • 第二步：看Agent的每次Thought和Action，定位到具体哪一步出的问题
    • 可能原因A：工具返回了错误数据 → 检查工具是否正常、数据源是否有问题
    • 可能原因B：工具返回正确但LLM理解错了 → 优化Prompt或工具返回格式
    • 可能原因C：检索到了不相关的文档 → 调整检索策略或重排序
    • 第三步：修复后把这次case加入测试集，防止回归