- [什么是Agent？](https://dkblog.guosgbin.cn/article/llm-agent-question#什么是-agent) - [Agent的核心组件构成](https://dkblog.guosgbin.cn/article/llm-agent-question#agent-的核心组件构成) - [Workflow，Agent，Tools的概念和区别？](https://dkblog.guosgbin.cn/article/llm-agent-question#workflowagenttools-的概念和区别) - [Agent设计范式？Agent和Workflow是什么？](https://dkblog.guosgbin.cn/article/llm-agent-question#agent-设计范式agent-和-workflow是什么) - [ReAct、Plan-and-Execute、Reflection有什么区别？如何选型？](https://dkblog.guosgbin.cn/article/llm-agent-question#reactplan-and-executereflection-有什么区别如何选型) - [复杂任务的拆分？如何提升效果？](https://dkblog.guosgbin.cn/article/llm-agent-question#复杂任务的拆分如何提升效果) - [记忆机制，如何设计记忆模块？](https://dkblog.guosgbin.cn/article/llm-agent-question#记忆机制如何设计记忆模块) - [记忆模块主流开源记忆框架对比](https://dkblog.guosgbin.cn/article/llm-agent-question#记忆模块主流开源记忆框架对比) - [Agent的长短期记忆？怎么存？粒度？怎么用？](https://dkblog.guosgbin.cn/article/llm-agent-question#agent-的长短期记忆怎么存粒度怎么用) - [什么是Multi-Agent？](https://dkblog.guosgbin.cn/article/llm-agent-question#什么是-multi-agent) - [Single-Agent和Multi-Agent设计方案？](https://dkblog.guosgbin.cn/article/llm-agent-question#single-agent-和-multi-agent-设计方案) - [Agent记忆压缩？](https://dkblog.guosgbin.cn/article/llm-agent-question#agent-记忆压缩) - [PromptCaching是什么](https://dkblog.guosgbin.cn/article/llm-agent-question#prompt-caching-是什么) - [手搓Agentvs使用Agent框架](https://dkblog.guosgbin.cn/article/llm-agent-question#手搓-agent-vs-使用-agent-框架) - [如何赋予LLM规划能力？](https://dkblog.guosgbin.cn/article/llm-agent-question#如何赋予-llm-规划能力) - [Agent的反思机制？为什么用？怎么实现？](https://dkblog.guosgbin.cn/article/llm-agent-question#agent-的反思机制为什么用怎么实现) - [多Agent的协作与动态切换机制？](https://dkblog.guosgbin.cn/article/llm-agent-question#多-agent-的协作与动态切换机制) - [什么是FunctionCalling](https://dkblog.guosgbin.cn/article/llm-agent-question#什么是-function-calling) - [LLM是如何学会调用外部工具的？](https://dkblog.guosgbin.cn/article/llm-agent-question#llm-是如何学会调用外部工具的) - [什么是MCP](https://dkblog.guosgbin.cn/article/llm-agent-question#什么是-mcp) - [Skill是什么](https://dkblog.guosgbin.cn/article/llm-agent-question#skill-是什么) - [A2A协议？和MCP区别是什么？](https://dkblog.guosgbin.cn/article/llm-agent-question#a2a-协议和-mcp-区别是什么) - [MCP协议的通信方式？](https://dkblog.guosgbin.cn/article/llm-agent-question#mcp-协议的通信方式) - [WebSocket和SSE的区别及局限性？](https://dkblog.guosgbin.cn/article/llm-agent-question#websocket-和-sse-的区别及局限性) - [WebRTC协议？和WebSocket在AI对话流中的差异？](https://dkblog.guosgbin.cn/article/llm-agent-question#webrtc-协议和-websocket-在-ai-对话流中的差异) - [大模型的网关框架？网关层解决了什么问题？](https://dkblog.guosgbin.cn/article/llm-agent-question#大模型的网关框架网关层解决了什么问题) ## 什么是 Agent？

Agent 本质上是**以大模型为大脑、能自主执行目标的 AI 系统**。和裸大模型最核心区别：**具备执行闭环，能够行动**。 - 裸大模型是被动响应：你提问，它输出文字，思考停留在文本里，不会实际做事； - Agent 在大模型思考之外，增加循环：收到目标后，利用模型做规划拆解，调用工具、读取记忆、和环境交互，一步步落地执行，直到任务结束。它不止输出文字，还能把想法变成实际动作。

**一、裸大模型的三大固有局限** 1. **知识冻结**：仅依靠训练数据，没有途径主动获取外部实时信息。 2. **无法行动**：只是文本生成器，只能输出怎么做的文字，不会真正执行操作； 3. **无外置持续状态**：模型本身不存储记忆。多轮对话的上下文，完全靠调用方手动传入；调用结束状态就消失，不会自己保存历史、偏好。 --- **二、Agent 是什么，核心闭环** 闭环：**接收目标 → 规划 → 行动 → 获取执行结果反馈 → 循环迭代** Agent 三大核心支柱： 1. **工具调用** 模型只输出调用哪个工具、填什么参数的结构化决策，**真正执行由外部代码完成，决策与执行分离**。通过工具突破知识冻结、不能行动的局限。 2. **记忆机制** - 短期记忆：保存当前任务中间过程，维持单任务连贯性； - 长期记忆：跨任务保存用户偏好、历史记录，一般借助向量检索。 3. **多步推理 + 自我纠错** 遇到失败可以分析、重试、调整计划；区别于硬编码固定流程的脚本。本质差异： - LLM：只生成文字，思考停留在文本； - Agent：以大模型作为大脑，搭配循环、记忆、工具，把思考转化成实际任务执行。 --- **三、Agent 生态两个关键协议，定位互补** 1. **MCP** Agent 和外部工具 / 资源之间的标准协议。工具实现 MCP‑Server，Agent 通过 MCP‑Client 即可直接使用，消除每个框架各自写适配代码的成本。三层角色：Host（上层应用）、Client、Server（提供工具）。 2. **A2A** 解决 Agent 和 Agent 之间互相协作通信。依靠 Agent Card（Agent 名片）描述自身能力、输入输出，让不同实现的 Agent 可以互相发现、分派任务、传递结果。 > MCP 管 Agent ↔ 工具；A2A 管 Agent ↔ Agent。 ## Agent 的核心组件构成

Agent 的基本架构有四个核心组件：LLM、工具、记忆、规划模块。 - **LLM** 是整个系统的大脑，负责理解任务、做出决策； - **工具**是和外部世界交互的入口，完成搜索、执行代码、调用 API，模型只输出调用决策，由外部程序真正执行； - **记忆**分为**短期记忆**保存当前任务状态、**长期记忆做跨任务持久存储**，保证执行过程不会失忆； - **规划模块依托 LLM 推理**，负责把复杂目标拆解成可执行步骤，支持全局预先规划或者执行中动态重规划。这四个组件配合 Agent 主循环一起，才让 Agent 具备自主完成复杂任务的能力。

Agent 由四大核心组件构成：**LLM、工具系统、记忆系统、规划模块**，依靠 Agent 主循环驱动组件协同运行。 **一、LLM（大脑）** 1. **负责理解用户指令、工具返回结果、检索出来的记忆信息，**完成任务决策，判断下一步行为：**继续思考、调用工具、输出最终答案**。 2. **System Prompt**：输入配置，定义 Agent 角色、行为边界、输出格式，约束 Agent 行为表现。 3. 模型选型评估维度 - **推理能力**：决定任务拆解、工具选择的正确性；推理优化模型更适合 Agent 决策，代价为更高延迟与 token 消耗。工程可大小模型搭配，**大模型负责核心决策，小模型处理简单任务。** - **上下文窗口**：复杂多步任务会持续占用上下文，窗口不足会丢失历史信息。 - **成本与延迟**，需要综合权衡。 --- **二、工具系统** 1. Agent 与外部世界交互的唯一入口，**弥补大模型无法访问外部环境的局限**。 2. 工具定义仅包含：**工具名称、功能描述、入参 Schema**，**不含执行逻辑**。 3. 分工：LLM 输出工具调用的决策与参数；宿主程序负责实际执行工具，执行结果回传给 LLM。**工具描述的清晰度直接影响工具调用准确率。** 4. **MCP 协议**：标准化协议，统一定义三类能力：Tools、Resources（只读数据源）、Prompts（预定义提示模板）。 - 角色分层：Host（上层应用）、Client（管理连接）、Server（提供实际能力）。 - 价值：工具实现 MCP‑Server 后，支持 MCP 的 Agent 可直接发现调用，消除重复适配开发。 --- **三、记忆系统** **短期记忆** - **对应模型上下文窗口**，保存当前任务全部中间执行状态，维持单任务连贯性；容量存在上限，任务结束即清空。 - **上下文压缩**：多步执行极易占满上下文，**解决方案为摘要压缩、滑动窗口**，两种方式均会存在信息丢失。 **长期记忆** - 一般基于向量数据库实现，信息向量化存储，通过语义检索读取；支持跨会话、跨任务持久保存信息。 - 类比认知科学分为三类 - **语义记忆**：存储事实类信息 - **情景记忆**：存储过往具体事件经历 - **程序性记忆**：存储处理任务的流程、方法论 --- **四、规划模块** > 规划能力底层依赖 LLM 推理；不一定是独立代码模块，ReAct 模式下规划逻辑内嵌在每一轮模型推理中。 1. 作用：将复杂目标拆解为可执行的子步骤。 2. 推理技术 - **CoT 思维链**：让模型输出完整中间思考过程，线性逐步推理。 - **ToT 思维树**：生成多条推理分支，评估筛选最优路径；效果好，但计算开销大。 3. 两种主流运行范式 - **Plan‑and‑Execute（先规划后执行）**：预先生成完整任务步骤列表再执行；便于人工审核；缺点是无法适配执行过程中的意外变化，需要支持重规划。 - **ReAct（边执行边规划）**：不预先产出完整计划，每一步依据当前上下文动态决策下一步动作；灵活性强；缺点是容易陷入局部最优，偏离整体目标。 - 工程实践：两种模式经常混合使用，先产出粗略方向，执行中动态调整。 --- **五、Agent 主循环工作逻辑** 简化流程：**接收用户目标 → 规划拆解任务 → LLM 结合历史记忆做出动作决策 → 调用工具执行（若需要） → 将执行结果写入短期记忆，检索相关长期记忆 → 循环迭代，**直到模型判定任务完成，输出最终答案。 ## Workflow，Agent，Tools 的概念和区别？

- **Tools**：最小能力单元，函数 / API，**只执行，无决策**。 - **Agent**：智能单元，大模型 + 记忆 + 规划 + Tools，**运行时自主做业务决策**，自主选工具、判断循环终止。 - Workflow：编排容器，组织 Tools / 大模型 / Agent。 - 可完全预定义（流程写死）； - 也可只定义流转路径，把业务决策交给内部 Agent。 **一句话核心区分：Tools 只管干活；Agent 自己做业务决策；Workflow 负责编排组装，决策可预定义也可交给内部 Agent。**

**一、Tools** 1. 本质：给大模型调用的函数，由两部分组成 - **Schema 说明书**：name、description、parameters，供大模型理解怎么调用； - **实际执行代码**，和 schema 完全分离。 2. 工具设计四大工程原则 - **一个工具只做一件事**； - **description 描述必须精确**，直接影响模型会不会误用 / 漏用工具； - **失败返回人类可读错误，方便 LLM 修正重试，不要只抛错误码**； - 参数尽量精简，能给默认就给默认，参数越多越容易格式出错。 3. **MCP**：工具标准化协议，统一 Tools / Resources / Prompts，实现跨框架工具互通。 --- **二、Agent** 1. 核心循环：Thought → Action → Observation，循环往复。 - 由大模型在运行时自主做全部业务决策：**调用哪个工具、要不要继续、什么时候结束任务**。 2. 工程强制约束：**必须配置多层停止条件，防止无限循环** - LLM 自己判断任务完成； - 最大执行轮次； - Token 消耗预算上限； - 整体执行超时。 --- **三、Workflow** Workflow 是编排容器，用来组装 LLM、Tools、Agent。分两类： 1. **确定性 Workflow：“下一步走哪个分支” 全部由开发者代码写死，不是大模型决定。** - 优点：行为确定、可复现、易调试、成本延迟可控； - 缺点：遇到预料之外输入容易失效，灵活性差。 2. Agentic Workflow： - Workflow 锁住整体骨架、流转路径、并行、重试、异常； - 在**需要灵活处理的局部节点嵌入 Agent，把业务决策下沉给 Agent；** - 同时拿到 Workflow 的可控性和 Agent 的灵活性，规避两者原生缺陷。 --- **四、5 种标准编排范式（Agentic Workflow 内部常用）** 1. **Prompt Chaining 提示链**：流水线，上一步输出作为下一步输入。 2. **Routing 路由**：LLM 做分类，分发请求到不同处理分支。 3. **Parallelization 并行**：多个子任务并行执行，之后聚合结果。 4. **Orchestrator‑Workers 编排者‑工人**：总控模块拆分分配子任务，多个 worker 执行，最后汇总。 5. **Evaluator‑Optimizer 评估‑优化**：生成模块产出内容，评估模块打分校验，不达标就回退重新生成，循环至通过 / 达到重试上限；评估标准必须明确，不能完全交给模型自由评判。 --- **五、三者关系重点（容易理解错）** 1. 包含关系： - Agent 内部会调用 Tools； - Workflow 可以包含 Agent、Tools； - Agent**不必须放在 Workflow 里面，可以独立跑**。 2. 判断核心标尺：**「下一步去哪里」这个流转决策是谁做出的** - Tools：完全不做流转决策； - Agent：运行时大模型做流转决策； - 确定性 Workflow：开发者预定义写死流转； - Agentic Workflow：大框架流转由编排控制，局部业务决策交给内部 Agent。 --- **六、对比表** | 维度 | Tools | Agent | 确定性 Workflow | | -------- | -------------------- | ------------------------------- | ---------------------------- | | 决策能力 | 无，仅执行 | LLM 运行时动态做业务 & 流转决策 | 开发者预定义全部流转 | | 执行方式 | 被动等待调用 | 自主循环直到停止条件触发 | 按预设拓扑顺序 / 分支执行 | | 确定性 | 高，输入固定输出固定 | 低，路径存在随机性 | 高，行为可预测复现 | | 灵活性 | 只能完成单一固定能力 | 高，能处理事先无法预判的场景 | 低，未知输入容易失败 | | 调试难度 | 简单，普通函数 | 困难，路径不确定，依赖日志 | 简单，链路清晰可断点追踪 | | 适用场景 | 封装原子能力 | 路径未知的复杂任务探索 | 场景收敛、要求稳定可控的业务 | ## Agent 设计范式？Agent 和 Workflow是什么？

Agent 与 Workflow 最核心区别：**谁决定下一步流转**。 - **Workflow：开发者预先定义流程路径**；确定性高、可控易调试，但应对未知场景弱。 - **Agent：由大模型运行时自主决定下一步动作；**灵活性强，但行为存在不确定性，生产很少裸用。 Agent 内部常见执行范式： - **ReAct**：边执行边思考，无前置完整计划； - **Plan‑and‑Execute**：先生成整体计划，再执行，支持中途重规划； - **Reflection**（反思）：增加自我复盘校验，迭代修正输出。主流采用 **Agentic Workflow**：整体大骨架用 Workflow 固定，在需要灵活处理的节点嵌入 Agent；兼顾全局可控与局部智能灵活。

**一、Workflow 与 Agent 本质差异** **Workflow** **控制流由开发者硬编码预先定义**：明确每一步执行什么、失败走哪个分支。**大模型无权决定流程走向**。 - 优点：行为确定、可复现、易于单元测试、故障定位简单，token 与延迟可控。 - 缺点：灵活性弱，只能处理预先设想的场景；遇到未预料输入容易失败。 **Agent** **把「下一步做什么」的流转决策权交给大模型**。开发者仅输入业务目标，由模型运行时自主判断：调用哪个工具、调用几次、是否继续、何时终止。开发者只设置安全限制。 - 优点：可以处理事先无法预判的场景，灵活性强。 - 缺点：行为具备概率随机性；相同输入可能走出不同路径；问题难以复现；token、延迟不可控，调试依赖完整执行日志。 --- **二、Agent 主流设计范式** **① ReAct（Reason + Acting）**：核心循环：`Thought → Action → Observation` - Thought：LLM 显式输出推理思考过程； - Action：基于思考选择工具与入参； - Observation：工具返回结果，回传给模型，进入下一轮循环。显式输出思考，避免冲动调用工具；思考过程可观测，方便调试。 - 适用：步骤少、子任务相对独立。 - 短板：走一步看一步，每一步追求局部最优；**长链路复杂任务容易丢失全局目标，出现打转、无效调用**。 **② Plan‑and‑Execute**：规划与执行逻辑解耦：专门规划先生成完整步骤列表，再交由执行模块分步执行。 > ⚠️关键点：简陋 Demo 只执行原始计划；**工程可用版本必须具备动态重规划**。每执行完一步，结合返回结果评估现状：判断原有计划是否还适用，按需修改、插入、**删减后续步骤**。允许人工审核初始计划。 - 适用：步骤多、步骤之间强依赖、需要全局视角的复杂任务。 - 短板：多次 LLM 调用，延迟、token 成本上升；**如果初始规划方向错误，后续再调整也很难挽回结果**。 **③ Reflection / Reflexion质量增强机制**： 1. Reflection：单步或全任务结束后，评估模型校验输出质量；不满足标准就触发重试。 2. Reflexion：不只简单重试，还生成**失败反思总结（错题本）**，把错误原因、改进建议作为上下文带入下一轮尝试，显著提升效果，同时带来更多 token 消耗。 > 混合使用示例：外层 Plan‑and‑Execute 做全局规划，每个子步骤内部跑 ReAct，关键节点叠加 Reflection 校验输出。 **选型逻辑** 1. 步骤简单独立 → ReAct 2. 复杂长链路、强依赖、需要全局统筹 → Plan‑and‑Execute（务必带重规划） 3. 质量要求高，允许成本上升 → 在已有范式上叠加 Reflection / Reflexion --- **三、工程架构决策原则（Anthropic 工程实践）** > **能用 Workflow 解决，就不要使用 Agent。优先确定性，按需引入智能。** 1. 纯裸 Agent 很少直接上线生产：概率性行为、测试覆盖困难、成本不可控。 2. 纯 Workflow：适合场景收敛、输入可穷举的业务；遇到未知输入就会失效。 3. Agentic Workflow（生产主流） - **整体主流程骨架由 Workflow 固定，管控节点顺序、分支、并行、异常、重试；** - 只有那些确实无法写死、需要灵活决策的局部节点，嵌入 Agent； - 整体可控可观测，局部保留 Agent 的灵活能力。 ## ReAct、Plan-and-Execute、Reflection 有什么区别？如何选型？

ReAct 和 Plan‑and‑Execute 是两套完整 Agent 执行范式，Reflection 是质量增强组件，不能独立运行。 - **ReAct 采用 Thought‑Action‑Observation 循环，规划和执行耦合在一起，走一步看一步**，灵活简单，适合探索类任务；缺点长任务容易目标漂移、错误传播，上下文完整携带会造成 token 持续上涨，需要配置最大步数等防护。、 - **Plan‑and‑Execute 将规划与执行解耦，先由规划器输出全局任务计划，再交给执行器执行，子任务内部还可以嵌套 ReAct。**工程可用版本必须实现动态重规划，应对计划外的意外情况；还可以采用大模型做规划、小模型执行的分层策略降低成本。它解决 ReAct 漂移的问题，但如果初始规划方向错误，后续很难挽回，同时需要手动做摘要才能抑制 token 膨胀，整体实现更复杂，适合长链路复杂任务。 - **Reflection 在原有流程上增加生成‑评估‑修正闭环，减少幻觉逻辑错误**；**Reflexion 更进一步，会把失败原因保存为经验记忆，避免后续重犯同类错误**。两者都会增加 token 和延迟，要限制最大反思轮次，适合对输出正确性要求高的场景。项目选型上优先用 ReAct 做原型验证；长任务容易跑偏就升级 Plan‑and‑Execute 搭配动态 Replan；输出质量不够再叠加 Reflection；需要沉淀失败经验再引入 Reflexion。生产常用混合架构：外层全局规划，子步骤内部 ReAct，最后做反思校验，避免过度堆砌组件。

**一、ReAct（Reason+Acting）** `Thought → Action → Observation`循环，**规划和执行耦合在一起**。每一轮 Thought 里面可以做局部小规划，但是**没有独立阶段输出一份全局完整任务清单**；边执行边思考下一步，走一步看一步。循环由**外部业务代码驱动**，不是 LLM 内部自动循环。 **优点** - 实现简单，原型开发快；推理过程全透明，Thought 日志方便调试。 - 灵活性极强，遇到突发情况可以即时调整策略，不需要改动前置计划。 - 适合边界不确定、探索式任务。 **❗缺陷** - **目标漂移：长任务上下文越来越长，历史信息干扰注意力，慢慢遗忘原始用户目标。 - **错误传播**：无条件信任 Observation 工具返回结果，没有内置校验。早期一步错，后续整条推理链全部跑偏。 - **Token 线性膨胀**：每一轮都携带**全部完整历史上下文**，步骤越多输入 token 越高，成本上涨明显。 - **容易无效循环打转**：反复调用一模一样的工具，得不到有效信息，原地绕圈。 - 模型单一：每一轮思考 + 工具决策都用同一个模型，无法做规划 / 执行模型分离，成本不好优化。 > 防护手段：必须配置最大循环步数、总 token 上限、超时时间三重终止条件。 **适用场景**：信息检索、多跳问答、简单客服，步骤不多、任务边界模糊的探索类任务。 --- **二、Plan-and-Execute（规划-执行范式）** Plan-and-Execute 是针对 ReAct「长任务容易跑偏」的痛点，做的针对性优化，**ReAct 是「走一步看一步，边想边干」；Plan-and-Execute 是「先把完整计划定好，再按计划一步步干」** **规划与执行解耦，分成两个独立阶段** - Planner 规划阶段：LLM 只做任务拆解，**不调用任何工具**，输出全局结构化分步计划，理清步骤依赖。 - Executor 执行阶段：按计划逐个执行子任务；**单个子任务内部可以跑 ReAct 循环**。 **✅优点** - 拥有全局目标约束，大幅缓解 ReAct 的目标漂移问题。 - 支持**大小模型分层**：强能力大模型做规划；廉价小模型负责子步骤工具执行，大幅降低成本（70%‑90%），ReAct 原生很难做到这点。 - 识别无依赖子步骤可以做并行执行，减少整体耗时。 - 可以人工审核、编辑初始计划，适合人机协同。 **❗缺陷** - **规划器本身会犯错**：如果最开始全局计划方向就错了，即便开启动态 Replan，也很难挽回整体结果。Planner 的质量直接决定整套系统上限。 - 灵活性弱于 ReAct：面对完全未知的突发场景，固定的计划拆解思维容易卡住。 - token 开销来源： - 规划本身多一次（或多次 Replan）LLM 调用。 - **节省 token 不是框架自带能力**：需要业务代码手动做「执行结果摘要」，用摘要替代完整历史传给后续步骤；如果不做摘要，Plan‑and‑Execute 同样会发生上下文膨胀。 - 系统复杂度上升：需要维护 Planner、Executor、计划解析、动态重规划逻辑，bug 点变多。 **适用场景**：长链路复杂任务、竞品报告、行业调研、多工具数据分析、项目拆解，目标明确、步骤多、子任务有依赖。 --- **三、Reflection & Reflexion（反思增强组件）** 两种使用位置：① 每一步子任务结束后单步反思；② 全部任务跑完之后全局反思校验。 **① Reflection** 循环：`生成输出 → 评估输出是否达标 → 不达标就修正/重试` 评估器可以是 LLM，也可以是外部可执行反馈（代码运行报错、单元测试结果）。 - 优点：修正逻辑漏洞、事实错误、幻觉，提升输出严谨度。 - 缺点：每一次反思至少额外一次 LLM 调用；token、延迟上升 30%~100%；不加轮次上限会无限重试死循环。 - 工程约束：一般限制最大反思轮次 2‑3 轮，搭配超时、token 上限。 **② Reflexion（Reflection 的进阶变种）** 在 “检查 + 重试” 之上，增加**失败经验记忆（错题本）** - 任务失败后，LLM 总结失败根因、改进建议。 - 将经验存入记忆；后续同类任务，把历史教训喂给模型，避免犯同样错误。额外代价：需要记忆存储管理；记忆过多会污染上下文，要做记忆筛选、截断。 **适用场景**：对正确性要求极高：代码生成、商业报告、法律文书，错误会带来实际损失的业务。 --- **四、配套：动态 Replan** 属于 Plan‑and‑Execute 的补丁，不是独立范式。动态 Replan 的做法是在**每个步骤执行完之后，把当前结果和剩余计划一起交给规划模块**，让它判断「原来的计划还合理吗，需不需要调整」。如果需要，就生成一份新的剩余步骤计划，替换掉原来的。 - 代价：每执行一步，多一次评估 + 可选重规划的 LLM 调用，增加 token 消耗。 - 注意：不要每一步都无脑 Replan；可以设置触发条件，只有结果明显异常时才触发重规划，减少开销。 ## 复杂任务的拆分？如何提升效果？

LLM 处理复杂任务出错，**本质是上下文窗口有限，中间状态太多导致子目标追踪失效**。任务拆分把大任务切分成独立子步骤，可以降低单步上下文负担、实现故障隔离、支持自动化校验重试。拆分分为**静态拆分和动态拆分**。**静态是人工写死工作流，稳定可控，适合确定业务；动态拆分就是 Plan‑and‑Execute 范式**，由 LLM 规划器输出全局计划，灵活性高，但规划器本身会出错，需要校验计划质量。 **拆分要遵循原子粒度**，还可以采用自适应递归拆分：先尝试执行，做不好再递归细分，同时要限制递归深度防止爆炸。拆完分析依赖构建 DAG，无依赖步骤并行，优化关键路径耗时。运行时**使用条件触发 Replan 动态重规划**，注意 Replan 不能修复已经执行完的历史结果。判断拆分好坏看三点：**完备性、独立性、可验证性。** **工程选型：稳定业务优先静态流程；复杂开放任务用动态规划，也可以静态骨架搭配动态细节，拒绝过度工程。**

**一、为什么要做任务拆分** > 底层根源：LLM 上下文窗口有限，复杂任务中间状态多，大量信息混杂，模型无法稳定追踪多个子目标（子目标遗忘、信息混淆）。拆分带来三层核心收益： 1. **降低单步上下文负担**，每个子任务只聚焦单一目标，提升单步正确率； 2. **故障域隔离**：某一步出错仅重试当前子任务，不需要全任务从头执行； 3. **可观测可校验**：每个步骤有独立输出，可以做监控、断言校验、自动重试，便于定位问题。 --- **二、两种基础拆分模式** **① 静态拆分（固定 Workflow）** 人工预先写死全部步骤、执行顺序。 - ✅优点：行为稳定、可回归、易调试，无规划器随机错误； - ❌缺点：灵活性差，遇到未预设场景容易卡住； - 📌适用：业务场景确定、输入可控的业务。 **② 动态拆分（Plan‑and‑Execute 核心）** 交给 LLM 规划器做全局拆解，输出步骤清单 / 有向无环图（DAG），分三阶段： **规划阶段**：只拆解任务，不执行工具，输出完整计划； **执行阶段**：按计划执行子任务，单个子任务内部还可以嵌套 ReAct 循环； **汇总阶段**：整合各子任务输出，做衔接、合并得到最终结果。 - ✅优点：灵活性高，适配开放、多变的复杂任务；支持依赖分析、并行执行；可以采用**强模型规划，小模型执行**降低成本； - ❌缺点：规划器本身会出错：欠拆分（步骤太粗）、过拆分（步骤过碎）；规划错了，后续全部执行都受影响； - 📌适用：开放多变、长链路复杂任务（调研报告、竞品分析）。 > 工业界折中方案：**静态骨架 + 动态填充细节**，顶层流程人工固定，子任务交给 LLM 动态拆分，兼顾稳定性和灵活性。 --- **三、拆分后优化：DAG 依赖分析与并行执行** 拆完步骤后分析依赖，构建**有向无环图 DAG**： - 有依赖：必须等待前置节点完成； - 无依赖：可以并发执行。 ⚠️生产坑： - 需要中间存储保存子任务输出，解决并发节点数据传递； - 需要并发池限流，避免 API 触发速率限制； - 逻辑无依赖，但存在资源竞争的步骤不能真正并行。 --- **四、任务粒度 & 自适应递归拆分** **原子步骤判定标准** 一个步骤只做一件独立事情，边界清晰，输入输出明确，可以写出清晰函数签名。 **自适应递归拆分** 先尝试执行，做不好再拆；简单任务直接执行，复杂任务递归拆成子任务，形成任务树。 - 尝试执行当前任务； - 如果输出不达标 / 执行失败，交给规划器继续拆成更小的子任务； - 对子任务重复该逻辑。 ⚠️必须增加保护：最大递归深度、最小原子粒度、总步骤上限，**防止无限递归爆炸**。 --- **五、执行过程：Replan 动态重规划** 计划不是一成不变，现实执行结果会让原有计划失效。 - 逻辑：每步执行完毕，评估剩余计划是否依然合理；不合理则更新**未执行的后续步骤**。 - 工程策略：**不每一步无脑 Replan**，条件触发：执行失败、输出与预期严重偏离才调用，控制 token 开销。 > ⚠️重要误区：Replan**只能修改未来任务，不能修复已经执行完成的历史错误**；历史错误依靠步骤内校验 + 重试。 --- **六、衡量拆分质量三大验收标准** 每个子任务拆分完成，要同时满足，每个步骤附带验收断言（类似单元测试）： 1. **完备性**：全部子步骤合并，完整覆盖原始用户需求，无遗漏； 2. **独立性**：步骤职责边界清晰，无重叠、无重复劳动； 3. **可验证性**：执行完成后有明确验收条件，可以自动判断是否合格，支持自动重试。 --- **七、完整选型决策** 1. 业务场景固定、输入可控：优先**静态 Workflow**； 2. 开放多变、长链路复杂任务：使用**动态拆分 Plan‑and‑Execute**；对规划输出执行完备性 / 独立性 / 可验证性校验； 3. 任务难度波动大：叠加**自适应递归拆分**，配置递归保护上限； 4. 执行环境充满意外：开启**条件触发 Replan**； 5. 追求更高吞吐：做 DAG 依赖分析，对无依赖子任务并行执行； 6. 输出要求高：在子任务或者任务结尾挂载 Reflection 反思校验； 7. 原型优先简单实现，不要一上来把规划、递归拆分、Replan、反思全部堆砌，避免过度工程。 ## 记忆机制，如何设计记忆模块？

Agent 记忆用来维持多步任务状态、跨会话沉淀经验，分为四层：**感知记忆、短期记忆、长期记忆、实体记忆。** - **感知记忆**是单次调用原始输入； - **短期记忆**就是上下文窗口，受 token 限制，可以用滑动窗口、摘要压缩、信息卸载做治理。 - **长期记忆**持久化存储，细分为情节、语义、程序记忆，分别保存历史案例、抽象知识、复用 SOP； - **实体记忆**是结构化事实，属于长期记忆子集，用关系库精确查询。设计记忆模块核心解决三个工程问题：**存什么、怎么存、什么时候取**。 - 存什么要做记忆过滤，只保留对未来任务有用信息； - 怎么存采用混合存储架构，结构化走数据库，非结构化用向量库，实体关系搭配知识图谱。 - 什么时候取分为会话启动的主动检索，和执行阶段的被动工具检索，线上建议两者结合，避免模型忘记调用工具。长期记忆需要后台异步做记忆整合：**去重、冲突消解，把情节记忆蒸馏成语义记忆**，同时警惕记忆污染。完整流程形成读‑用‑写闭环：任务开始读取记忆，执行阶段使用短期记忆并按需检索，任务结束过滤校验后回写持久存储。开源可以参考 Mem0、Letta，生产环境要处理摘要信息衰减、检索失效、图谱抽取错误等问题，很多项目选择借鉴思想自研。

记忆是 Agent 实现多步连贯任务、跨会话积累经验的核心；没有记忆，Agent 每次都是全新会话，丢失用户偏好、任务状态、历史经验。 --- **一、四层记忆分层** | 记忆层级 | 本质载体 | 生命周期 | 访问方式 | 核心作用 | | -------- | --------------------------------------- | ----------------- | -------- | ------------------------------------------------------------ | | 感知记忆 | 单次调用原始输入 | 仅本次调用 | 即时读取 | 接收原始外部信息，处理完即丢弃 | | 短期记忆 | LLM Context‑Window（messages 消息列表） | 当前会话 / 任务内 | 直接读取 | 保存当前任务全部状态：用户提问、模型思考、工具入参返回结果；受 Token 上限限制 | | 长期记忆 | 向量库、KV 库、数据库 | 跨会话持久保存 | 语义检索 | 保存跨任务历史；内部再分为 3 个子类：
1. 情节记忆：历史任务经历、事件案例；当 Agent 遇到类似的新任务时，参考上次是怎么解决的，避免重复踩坑
2. 语义记忆：从多次经历提炼出的抽象知识、规律；
3. 程序记忆：可复用 SOP 操作流程 | | 实体记忆 | 关系型数据库结构化字段 | 持久保存 | 精确查询 | 提取对话中关键事实：用户偏好、实体属性、时间、预算；类似病历卡，高信息密度，避免大文本检索 | > 补充两种增强存储 > > - **向量数据库**：擅长非结构化文本**语义模糊召回**；不知道关键词，靠语义相似度检索。 > - **知识图谱（三元组：主语‑关系‑宾语）**：解决向量检索做不好的**实体关系、多跳推理**；和向量库互补，而不是互相替代。 --- **二、设计记忆模块的三大核心工程问题** 不要把记忆等同于向量数据库 RAG；真正难点：**存什么、怎么存、什么时候取** **① 存什么：记忆过滤** 判断标准：**这条信息在未来任务，是否对 Agent 有帮助** - ✅应该存储：用户偏好习惯、任务关键决策结论、业务案例、SOP 流程、外部文档知识 - ❌不要存储：闲聊对话、临时中间推理、工具原始返回日志，避免噪音污染向量库，降低检索信噪比 **② 怎么存：混合存储，拒绝一刀切全部丢向量库** - **结构化事实、用户配置、实体属性** → MySQL / PostgreSQL，精确查询，性能高 - **非结构化文本、案例、文档摘要** → 向量数据库，语义检索 - **实体之间关联关系** → 知识图谱，做多跳关系推理 **③ 什么时候取出来使用，两种检索策略，生产建议组合使用** - **主动检索**：会话 / 任务启动阶段，提前检索用户画像、历史背景，注入 System Prompt。 - 优点：不需要模型做决策，一上来就带上历史信息； - 缺点：检索结果占用 Prompt Token，要限制召回条数。 - **被动检索（Tool 工具**）：把 “查询记忆” 封装成工具，推理过程由 Agent 按需调用。 - 优点：灵活，只在需要的时候加载记忆； - 重大坑：模型经常忘记调用记忆工具，直接幻觉作答。 > 生产最佳实践：**主动加载基础画像 + 被动按需检索补充知识，双保险**。 --- **三、短期记忆（Context‑Window）治理方案** 上下文存在 Token 上限，任务变长会发生 “失忆”，三种方案，各有取舍： 1. **滑动窗口**：保留最近 N 轮对话，更早直接丢弃。实现最简单；缺陷：早期重要约束会被滑出窗口。 2. **摘要压缩**：历史接近上限，调用 LLM 把早期长对话压缩成简短摘要。节省 Token；代价：额外 LLM 开销，多次压缩会发生**信息衰减丢失细节**。 3. **信息卸载**：当前暂时不用、未来可能用到的信息，写入长期记忆，从上下文移出；需要时再检索召回。风险：**一旦检索没命中，等同于记忆丢失**。 > 工程策略组合：保留最近若干轮完整消息；久远历史做摘要；**全局硬性约束放到实体记忆保护，永远不被压缩滑动丢掉**。 --- **四、长期记忆维护：记忆整合** 长期记忆随运行会积累碎片、重复、过时、互相矛盾的记忆，需要后台异步做记忆整合，**不能放在主请求链路，避免拖慢响应**。 1. **去重**：语义相似多条记忆合并为一条； 2. **冲突消解**：依靠时间戳，区分新旧事实；不是简单新覆盖旧，部分场景需要保留多条版本； 3. **抽象蒸馏**：把大量情节记忆（具体案例）提炼成语义记忆（通用规律），提升知识密度。 --- **五、记忆完整工作闭环：读‑用‑写** - **任务开始：读记忆** 主动检索实体记忆（用户结构化信息）+ 长期记忆语义检索，把相关背景注入 System Prompt。 - 任务执行：用记忆 - 短期记忆持续追加全部对话、工具调用，维持当前任务完整状态； - 遇到需要历史知识时，调用记忆 Tool 做被动检索，临时注入上下文使用。 - **任务结束：写记忆** 通过记忆过滤器筛选有效信息，更新实体记忆、写入长期记忆向量库；短期记忆清空，等待下一轮任务。 ## 记忆模块主流开源记忆框架对比 ### Mem0 - 普通 RAG 直接存储原始对话文本，存在大量噪音、无法处理动态变化的用户偏好，记忆更新、冲突处理需要业务自己写逻辑。 Mem0 核心思路：**不存储完整原始对话，从对话中提炼精炼事实记忆条目**，模仿人类选择性记忆，只保留有价值信息，过滤闲聊与临时中间过程，降低 token 消耗，提升召回准确率。 - 核心流水线：**提取 (Extraction) → 更新冲突消解 (Update) → 混合存储 → 多信号检索** - 底层是可插拔多存储引擎，**上层统一记忆 API**，底层存储可自由切换（FAISS、Qdrant、pgvector、Milvus 等），上层接口完全不变Mem0。 - **写流水线：** - **记忆提取**：传入本轮对话 + 最近 N 轮历史 + 会话摘要，调用 LLM 从对话提取候选记忆（用户偏好、事实、决策、需求，过滤闲聊），输出简短事实条目，不是原文复制。 - **冲突检测与消解**：拿候选记忆对比该用户已有的历史记忆；识别矛盾、重复事实。两层去重：**hash 精确去重（文本完全相同）+ LLM 语义去重（语义相同措辞不同）** - **批量 Embedding、装配元数据**：时间戳、hash、实体信息、作用域元数据。 - **持久化写入**：同时写入向量库、KV 库；开启图谱则执行实体抽取、实体链接，构建三元组存入图存储。 - **检索流程**：多信号混合检索，不是单纯向量相似度 - 同时从向量库（语义）、图数据库（实体关系）检索候选记忆； - 打分层综合三个维度：**语义相关性、重要度、时间远近**； - 过滤、截断，返回少量精炼记忆条目； - 业务把返回的记忆拼接进 System Prompt，注入 Agent 上下文。 --- ### Letta Letta 是**完整 Agent 运行时**，记忆管理是 Agent 内部工具循环的一部分，**由大模型自己决定什么时候写、什么时候查、什么时候把数据换入 / 换出上下文窗口**GitHub 核心设计哲学：LLM 作为操作系统，类比计算机 OS 虚拟内存机制 | 操作系统组件 | Letta 对应 | 说明 | | ------------ | ------------------------------- | ------------------------------------------------------------ | | CPU | LLM 大模型 | 负责推理、决策、调用内存工具 | | RAM（内存） | Context‑Window 上下文窗口 | 速度快，Token 容量有限；只有在上下文内的数据，模型才能直接看见 | | 磁盘（硬盘） | 外部持久存储（Recall+Archival） | 容量无限，但模型不能直接访问；**必须主动调用工具加载进上下文，才能被使用** | | 内核 Kernel | Agent 本身（大模型） | 模型自己充当内存管理器，执行 page‑in/page‑out（换入换出） | > 传统 RAG/Mem0：**业务代码驱动记忆读写**，会话开始前业务主动检索，把记忆塞给 prompt。 > > Letta 范式：**Agent 模型驱动记忆读写**，没有外部代码自动注入记忆；模型思考过程中，自己判断：我要不要查历史？要不要把重要信息写到 Core Memory？要不要把不重要数据归档？三层记忆层级（核心） **① Core Memory 核心内存（主存 RAM，永远驻留在上下文）** 始终放在 System Prompt 内部，**每一轮 LLM 调用都可见，不会被挤出上下文窗口**；由多个命名可编辑 Block 组成，最常见两个 block： - `persona`：Agent 自身身份、性格、系统设定 - `human`：记录用户关键事实、偏好、目标 ✅作用：存放最高优先级、时时刻刻都需要的关键信息，类似我们前面讲的**实体记忆**，保证不会因为上下文压缩、滑动窗口丢失关键约束。 ❌限制：受 token 限制，不能存大量历史案例。 **② Recall Memory 召回记忆（缓存，原始会话日志）** 保存完整原始对话历史，持久化存入数据库；**默认不会自动塞进上下文窗口**。 Agent 通过工具 `conversation_search(keyword)`，按关键词、时间检索历史原始对话片段，检索结果才会临时加载进上下文。 > 相当于完整聊天日志存档；不做摘要，保留原始交互记录。 **③ Archival Memory 归档记忆（磁盘，无限容量长期存储）** 真正大容量长期冷存储，向量数据库做语义检索。用来存放：长文档、深度反思总结、过往任务结论、不常用但未来可能需要的知识。 > 与 Recall 区别： > > - Recall：原始对话，关键词 / 时间检索； > - Archival：提炼后的笔记、文档、总结，向量语义检索。 ### 对比 - **Mem0：可插拔独立记忆层**。只负责记忆提取、存储、检索；**业务代码驱动记忆读写**，可以嵌入任意 Agent 框架（LangGraph、CrewAI、自研 Agent），不接管 Agent 执行循环。 - **Letta：完整 Agent 运行时**。记忆是 Agent 内部能力；**大模型 Agent 自己调用工具管理内存**（虚拟内存范式）；整套 Agent 要跑在 Letta runtime 内部。 ## Agent 的长短期记忆？怎么存？粒度？怎么用？

Agent 记忆分为**短期记忆**和**长期记忆**两部分。 **短期记忆就是工作记忆**，底层就是 LLM 的 messages 消息列表，保存用户输入、模型思考、工具返回结果，用来维护**单次任务内部的执行状态**。它的问题是受上下文窗口限制，对话变长会被截断遗忘。工程上一般用滑动窗口、滚动摘要，或者虚拟内存卸载冷数据来解决溢出问题，也可以用结构化 State 做结构化工作记忆，让任务状态更清晰。 **长期记忆负责跨会话、跨任务持久保存信息**，底层依靠 Embedding 加向量数据库。存储时把文本转成向量入库；任务开始时把用户请求向量化做语义检索，拿到相关记忆注入 System Prompt；任务结束后，由 LLM 识别关键信息，再沉淀回向量库。工程上要关注几个点：记忆粒度要适中，避免碎片化或者噪音过多；还要处理记忆冲突、内容过期，检索阶段要注意召回失败、记忆污染、token 超限，通常配合元数据、Reranker 重排序做优化。实现分两种范式：一种是**业务代码驱动**，像 Mem0、Zep，由业务主动调用存和查，可控性好，适合生产环境；另一种是**Agent 自主驱动**，代表是 Letta，把记忆封装成工具交给模型自己调用，可以做虚拟内存，但高度依赖模型能力，存在模型忘记调用工具的风险。整体流程就是：任务启动检索长期记忆，短期记忆跑 Agent 循环，任务完成再沉淀关键信息。

无记忆 Agent 的缺陷：Agent 没有持久记忆，每次交互上下文独立，无法跨会话、跨任务留存用户偏好、历史约定与业务经验，只能处理单次独立问答，多轮持续任务缺少连贯性。记忆系统目标：使 Agent 在单次任务内维持执行状态，同时跨任务持久沉淀关键信息。分为**短期记忆**、**长期记忆**两层；行业存在两种实现范式：**业务代码驱动**、**Agent 模型自主驱动**。 --- **一、短期记忆（工作记忆）** **短期记忆即传入 LLM 的 messages 消息列表**，作为任务执行的工作区，保存当前任务全部上下文：用户指令、模型思考、工具调用、中间执行状态。LLM 依靠该上下文获知任务目标、执行进度、中间结论。特征：任务执行全程有效，任务结束后清空；messages 持续追加会消耗上下文窗口，窗口占满后早期内容被截断，发生遗忘。 **应对上下文溢出的工程方案：** 1. 滑动窗口：保留最近 N 条消息，丢弃早期原始内容 2. 滚动摘要：对历史对话做摘要压缩，替换原始消息 3. 虚拟内存卸载：将冷数据移出上下文，持久化至外部存储，需要时再加载（Letta 方案） **结构化工作记忆** 原生短期记忆为消息列表，所有信息直接追加，结构无序。结构化工作记忆将工作区划分为固定字段：任务目标、已确认结论、待验证假设等。执行过程中更新对应字段，替换过时内容。本质对应 LangGraph 等框架中的 State 结构化状态，保证长任务下上下文信息准确简洁。 --- **二、长期记忆** 作用：跨会话、跨任务持久存储信息，弥补短期记忆生命周期短、容量有限的问题。基础组件：**Embedding 嵌入模型 + 向量数据库**。 Embedding：将文本转换为高维向量，语义相近文本向量空间距离近，一般使用余弦相似度衡量距离。向量数据库：存储文本、向量、元数据；基于 ANN 索引（HNSW/IVF）实现高效语义相似度检索，根据查询向量返回语义匹配的记录。 **长期记忆三类分类**（认知科学分类） 1. **语义记忆**：存储事实性静态知识，如用户身份、业务约束。 2. **情节记忆**：存储事件经历，携带时间、因果信息，记录历史交互事件。 3. **程序记忆**：存储流程、方法论，记录处理任务的行为模式。 > 工程实现：不需要物理拆分三套向量库。通常使用同一个存储集合，依靠 metadata 的`memory_type`字段做逻辑区分与过滤。 **记忆粒度** - 粒度过细：单条只存碎片化事实，检索容易召回部分片段，信息不完整。 - 粒度过粗：大段完整对话作为单条记忆，命中后携带大量无关噪音。 - 合理粒度：**以独立事实、完整知识点、一次交互摘要为单位存储**；中间过程临时数据保留在短期记忆，不写入长期记忆。 **两种存储流派** 1. **事实短句**：一条记忆对应一件事实，检索精准，需要做去重、冲突消解（Mem0）。 2. **对话摘要**：保存片段摘要，信息完整，易引入无关内容。 **记忆衰减与冲突** 1. **记忆衰减**：向量检索本身不处理时间，业务层在检索后做二次重排序，结合时间戳施加新鲜度权重；也可定期调用 LLM 扫描记忆库，标记过时内容。 2. **记忆冲突**：用户信息发生变更会产生矛盾记忆。需要做语义去重、冲突检测，对旧记忆标记失效，避免多条矛盾记忆同时被召回。 **检索注入链路风险** 1. 召回失败：记忆已存储，但检索没有命中。 2. 记忆污染：过时、冲突记忆被检索出来直接注入 prompt，产生错误输出。 3. Token 过载：返回记忆总量过大，耗尽上下文窗口。工程对策：引入 Reranker 重排序、过滤无效记忆、限制记忆总 token 上限。 **两种记忆驱动范式** 1. **业务代码驱动（Mem0、Zep）** 业务代码在任务前后主动调用存储、检索接口，记忆注入由业务控制。优点可控性强，适合线上生产；缺点记忆策略由外部代码定义，Agent 不能自主决定记忆操作。 2. **Agent 模型自主驱动（Letta/MemGPT）** 记忆读写、归档、检索封装为 Tool 工具，由大模型自主调用执行。可实现虚拟内存机制；缺点依赖模型能力，模型可能忘记调用记忆工具，可靠性下降。 ## 什么是 Multi-Agent？

Multi‑Agent 就是将复杂任务拆解，交给多个不同角色的 Agent 分工协作，用来解决单 Agent 上下文受限、职责混杂专业度不足的问题。常见协作模式有流水线串行、并行扇出、辩论评审模式。组织架构分为中心化和去中心化，**工程大多使用中心化架构，由 Orchestrator 调度器完成任务拆解、分发、结果校验**，调试维护更方便；去中心化多用于科研原型。优势是 Agent 上下文隔离，角色专一，部分子任务可以并行提升效率。但也存在不少问题：会带来更高的 token 开销与延迟，任务拆分粒度不好把握，Agent 间通信容易信息失真，幻觉还会层层放大。主流工具：CrewAI 开箱即用；LangGraph 是底层状态编排框架，灵活度高；

**一、单 Agent 存在两处核心限制** 1. **上下文窗口上限约束**：全部指令、推理、工具返回、对话历史都占用上下文，任务复杂时 token 快速打满，早期信息被截断丢失，发生遗忘。 2. **专业度不足**：单个 Agent 承担多种职责，任务混杂，输出质量下降；故障无隔离，问题排查困难。 Multi‑Agent 核心思想：**将复杂大任务拆解，交由多个角色专一的 Agent 分工协作，替代单个 Agent 完成全部工作**。 --- **二、Multi‑Agent 三种协作模式** 1. **顺序流水线（Sequential Pipeline）**：Agent 按依赖顺序依次执行，上一个 Agent 输出作为下一个 Agent 输入。 2. **并行扇出（Fan‑out）**：调度节点把互相无依赖的子任务分发给多个 Worker Agent 并行执行，全部完成后统一收集结果做聚合。 3. **辩论 / 评审模式（Debate/Review）**：多个 Agent 独立对同一问题产出方案，互相评审或由裁判 Agent 做筛选，用于对输出质量要求高的场景，如代码评审、方案选型。 --- **三、Multi‑Agent 两种组织架构** 1. **中心化架构（工程主流）** 存在统一调度器 Orchestrator，负责**大任务拆解、子任务分发、依赖关系判断、结果收集校验、异常重试、终止条件判断**，Worker Agent 只负责执行子任务。优点：逻辑清晰，便于调试定位问题；缺点：调度节点存在单点。 2. **去中心化架构** Agent 之间直接通信、自主协商完成任务，没有统一总指挥。多用于科研原型，生产环境落地很少，通信与管控复杂度高。 --- **四、Multi‑Agent 的收益与工程痛点** 收益 - 职责拆分，每个 Agent 角色单一，输出专业度更高。 - Agent 上下文隔离，避免大量无关信息挤占上下文窗口。 - 无依赖子任务支持并行执行，提升整体执行效率。 - 故障隔离，便于定位任务链路中的问题环节。痛点（非银弹） - LLM 调用次数变多，Token 成本、接口延迟显著上升。 - 任务拆分粒度难以把控：拆分过细产生大量琐碎子任务；拆分过粗退化为单 Agent 模式。 - Agent 之间通信存在风险：消息传递出现信息丢失、畸变；上游输出格式异常直接导致下游执行失败。 - 幻觉传递放大：子 Agent 产生的错误，会随多轮信息传递层层放大。 > 注意：Multi‑Agent 不等于一定并行，流水线模式下全部 Agent 串行执行。 ## Single-Agent 和 Multi-Agent 设计方案？

**Single‑Agent 是 LLM 加工具决策循环，架构简单可控，调试方便。但在上下文溢出、需要多专业角色、大量独立子任务的场景会遇到瓶颈。** Multi‑Agent **分为中心化和去中心化**。生产主要使用中心化架构，O**rchestrator 负责任务拆解、分发、结果聚合，Worker 负责具体执行。Orchestrator 分为静态路由、动态规划、自适应编排三种。**去中心化没有总调度，Agent 自主协商，存在任务重复、故障无法感知、无法判定任务结束等问题，多用于学术，很少上生产。选型优先 Single‑Agent，出现明确瓶颈再引入多 Agent，采用渐进式演进，避免过度设计。同时多 Agent 会带来 Token 成本上涨、调度器单点、任务拆分依赖模型能力等问题。A2A 是 Agent 的跨框架通信标准。

**一、Single‑Agent** **核心原理**：单个 LLM 搭配工具集合，执行决策循环：模型判断下一步动作，调用工具，接收工具返回结果，迭代循环直到任务完成。 **优势**：架构简单，任务链路集中可控；故障链路短，便于排查；不存在 Agent 间通信开销。 **能力瓶颈**：出现以下场景，Single‑Agent 会达到能力边界： - 任务数据量大、步骤长，上下文窗口耗尽，发生信息遗忘； - 需要多种完全不同的专业能力，全部在同一个 Agent 内处理，输出质量下降； - 存在大量互相独立的子任务，需要并行处理。 **适用原则**：任务流程明确、复杂度适中，优先使用 Single‑Agent，不应当为了技术噱头引入 Multi‑Agent。 --- **二、Multi‑Agent 中心化方案（生产主流）** **核心原理**：设置统一调度角色 **Orchestrator（总调度器）**，不执行业务逻辑，核心职责：理解用户目标、拆解子任务；将子任务分发给 Worker；收集、聚合 Worker 的输出，生成最终结果。 **Orchestrator 三种实现** 1. **静态路由**：任务拆分、分发规则硬编码，不依赖 LLM 规划。逻辑确定可预测，适合业务场景固定。 2. **动态规划**：Orchestrator 依靠 LLM 根据输入动态生成任务计划，执行过程支持有限调整，绝大多数业务项目采用该模式。 3. **自适应编排**：在动态规划基础上，增加子任务输出结果校验；依据 Worker 返回质量动态追加、重试子任务；能力更强，调试复杂度显著升高。 **Worker Agent**：仅执行分配给自己的子任务，不感知全局任务与其他 Agent；上下文只保留自身任务相关信息，执行完成返回结果。 **中心化优缺点** - 优点：任务分配、执行顺序、故障感知、任务终止均由调度器管控；执行链路可追踪，便于定位问题。 - 缺点：Orchestrator 存在单点风险；整体 Token 开销上升；Worker 之间不能直接通信，依赖调度器中转；任务拆分质量受调度侧 LLM 能力制约。 --- **三、Multi‑Agent 去中心化方案** **核心原理**：不存在统一调度节点，各个 Agent 通过消息队列或共享状态空间自主协商、直接通信。 **工程痛点** - 缺少全局协调，容易出现任务重复执行； - 没有统一等待逻辑，无法判断全部子任务执行完毕； - Agent 故障无统一感知，部分执行失败不会被发现，输出残缺结果； - 没有角色判定整体任务是否结束。 **适用范围**：多用于学术研究，生产环境极少落地；可控性差，调试难度高。 **架构选型策略** - 优先判断 Single‑Agent 是否可以完成任务，流程简单、规模适中直接选用。 - 当任务超出 Single‑Agent 能力边界，生产环境优先采用中心化 Orchestrator 架构。 **渐进式演进思路** 先用 Single‑Agent 跑通完整业务；当出现明确瓶颈，例如上下文溢出、特定子任务输出质量差，再把对应模块拆分为独立 Worker。禁止初始阶段直接搭建复杂多 Agent 系统。 ## Agent 记忆压缩？

Agent 记忆压缩用于解决上下文窗口限制、历史膨胀问题。 - **滑动窗口**实现最简单，保存最近 N 轮，缺陷为硬截断，会丢失早期关键信息。 - **摘要压缩**在丢弃历史前调用 LLM 生成摘要，层级摘要实现分层压缩，工程多和滑动窗口配合，但会损失细节。 - **重要性过滤**不以时间取舍，对消息打分保留高价值内容；衍生观察遮蔽、主动压缩，不等上下文满再处理。 - **结构化抽取**提取对话事实与决策，用结构化数据替代原始对话，保真度高，但开发成本高、通用性差。多种方案可以组合。Prompt Caching 是推理层优化，只降低延迟成本，不减少 token，不能解决超限。超长期会话需要搭配 RAG 向量记忆，将久远记忆移出上下文按需召回。

**一、背景** LLM 推理依赖传入完整 messages 上下文，上下文存在 token 上限。多轮会话会造成对话历史持续累积，触发截断，同时提升调用成本。记忆压缩目标：尽可能保留关键信息，降低上下文 token 占用。 > 记忆压缩处理**上下文窗口内部的对话**；RAG 向量长期记忆将记忆移出上下文做外部存储、按需检索召回，二者常组合使用，但 RAG 不属于上下文记忆压缩。 --- **二、滑动窗口** **原理**：仅保留最近 N 轮对话，超出部分从最早记录直接丢弃。 - 优点：实现简单，无额外 LLM 调用，无附加开销。 - 缺点：硬截断，以时间作为取舍依据，不区分信息重要程度；早期关键决策会随闲聊内容一同丢失。 - 适用场景：短会话，历史信息价值较低。 --- **三、摘要压缩** **原理**：对即将被截断的历史不直接丢弃，调用 LLM 将旧对话提炼为文本摘要，使用摘要替换原始对话；近期对话保留原始文本。 **层级式摘要**（进阶变种） **对历史分层压缩：最近 N 轮保留原文，中期历史生成中等粒度摘要，更早的历史生成高精简摘要**。越久远的信息压缩程度越高，兼顾近期细节与远期关键决策。 - 优点：规避直接硬截断，保留事件关键脉络；工程中常与滑动窗口组合。 - 缺点：摘要会丢失细节，信息完整性依赖 LLM 判断；产生额外 LLM 调用开销。 - 工程常用组合：**滑动窗口 + 摘要压缩**。窗口控制总长度，丢弃历史前执行摘要提炼。 --- **四、重要性过滤** **原理**：脱离时间维度，对每条历史记录进行打分，基于内容价值筛选，保留高分记录。两种打分实现： - 规则打分：基于关键词、消息被引用频次等规则计算；无模型调用开销，执行速度快，判断效果粗糙。 - LLM 打分：由模型评估每条消息重要等级；准确率更高，但调用开销大，多用于批量离线处理。 **变种** - **观察遮蔽 Observation Masking** 不物理删除记忆，在构造 Prompt 的运行时阶段，依据当前任务动态屏蔽无关历史，仅将相关内容送入上下文；原始记录持久化存储，不会产生不可逆信息丢失。 - **主动压缩 Proactive Compression** 不等待上下文临近溢出才被动执行压缩；每一步或每 N 轮执行完成后主动执行压缩。多用于工具调用场景，对大体积工具返回结果即时提炼要点，替换原始返回数据，从源头抑制上下文膨胀。 **优缺点** - 优点：可保留时间久远的高价值信息，过滤低价值闲聊内容。 - 缺点：打分逻辑存在误判风险；LLM 打分模式会带来额外成本。 --- **五、结构化抽取** **原理**：放弃原始对话文本载体，从对话中提取事实、状态、用户偏好、已确认决策，输出 JSON 等结构化对象；推理时直接注入结构化字段。 - 优点：信息密度高，关键信息精确保留，不存在摘要带来的语义模糊。 - 缺点：需要预先定义业务字段，强依赖业务理解，通用性弱，开发成本高。 - 适用场景：业务边界明确，存在大量可固化事实与状态。 --- **六、四类压缩方案定位** 1. 滑动窗口、摘要压缩：解决历史过长的截断问题；前者直接丢弃，后者丢弃前提炼信息。 2. 重要性过滤：打破时间顺序，按内容价值筛选记忆。 3. 结构化抽取：更换信息存储载体，使用结构化事实替代原始对话文本。 > 四类方案互不互斥，工程系统一般采用多种方案组合。 --- **七、计算层优化：Prompt Caching** 不属于信息层记忆压缩，属于推理侧优化，和记忆压缩互补。 **原理**：对于多次请求中不变的前缀 Prompt、历史片段，缓存 prefill 阶段的计算结果并复用，降低推理延迟与计费。 - 关键约束：**不会减少输入 token 数量，无法解决上下文溢出；命中缓存仅降低开销，超出窗口上限依旧触发截断。** - 适用场景：Agent 长会话，System Prompt、长期记忆片段重复复用。 --- **八、工程选型** 1. 会话简短：滑动窗口，实现成本最低。 2. 长会话，避免硬截断：滑动窗口 + 摘要压缩，通用性强。 3. 业务存在明确事实、状态、决策：优先结构化抽取。 4. 长 Prompt、成本敏感：启用 Prompt Caching 做计算层优化。 5. 超长期会话：上下文压缩搭配 RAG 向量长期记忆。 ## Prompt Caching 是什么

很多人对 Prompt 缓存有误解，首先记住核心结论：**它缓存的不是 AI 的回答，而是读取输入文本产生的 KV‑Cache，也就是中间计算半成品**。 AI 处理请求分为两步。**第一步读取全部输入文本，计算出数字矩阵形式的中间半成品；第二步依靠半成品逐字生成回复。** 没有 Prompt 缓存时，新一轮对话哪怕只新增一句话，模型也要把全部历史文本从头到尾重新读取、全部重新计算一遍，造成大量重复计算，增加耗时和成本。开启 Prompt 缓存之后，第一次输入长文本，模型完成读取并算出半成品，服务商保存这份中间数据。**下一轮对话，如果前面的历史文字一字没变，仅仅末尾增加新问题，模型会直接复用已缓存的半成品，不再重复解析旧内容，只处理新增文本，再生成全新答案。**这里一定要分清，答案是重新生成的，并不是直接调取旧回复。同时它有明显限制：**只要前面原始输入改动哪怕一个字符，缓存立刻失效，需要全部重新计算。**而且缓存不会增加上下文长度上限，文本超限依旧会截断，只是减少了重复计算，节省耗时与费用，不会改变模型输出本身。 ## 手搓 Agent vs 使用 Agent 框架

选择手搓还是框架不是非黑即白。**原型 POC 阶段（概念验证）框架效率很高，但框架多层抽象会带来黑盒问题，排错困难，版本升级存在风险，还会有通用逻辑带来的隐性性能开销。** 手搓核心逻辑最大收益是**链路透明、完全可控、没有多余开销，不受框架接口变动影响，但代价是要自己处理大量边界逻辑，开发测试成本更高。** 生产中更务实的方案是折中：Agent 核心循环、消息、工具调用这些核心逻辑手写，文档解析、追踪、数据库客户端这类外围组件继续复用第三方库。项目常见演进路径：先用框架验证想法，上线遇到问题后逐步迁移核心逻辑。需要警惕的是不理解内部实现就重度依赖高层框架 API。

**一、框架带来的价值** Agent 开发包含重复工作：工具 Schema 定义与解析、LLM 工具调用结果解析、对话消息维护、工具异常重试、知识检索接入。框架封装样板代码，避免重复造轮子。以 LangChain 为例：init_chat_model 兼容大部分大模型厂商的 API，`@tool`装饰器注册工具，同时提供了一些大模型、工具的一些环绕钩子。框架封装完整 ReAct 循环，内置回调、链路追踪、记忆管理。 POC 验证阶段，可以快速跑通流程，大幅缩短原型开发周期。 --- **二、框架在生产环境的痛点** 问题不会在原型阶段暴露，随项目迭代逐步显现： 1. **抽象层过深，调试排错困难** 业务代码很少，但异常堆栈穿透多层框架内部实现。故障难以区分问题来源：业务代码、框架 Bug、回调触发时机。类比整车黑盒，故障排查依赖阅读第三方源码。 2. **版本升级风险** 依赖框架大版本迭代容易出现不兼容变更（Breaking‑Change），线上业务逻辑强绑定框架高层接口，升级会引发线上故障；即使做语义化版本，依然存在隐性行为变更。 3. **通用性带来隐性开销** 框架为兼容各类场景，内置序列化、大量回调、通用日志逻辑。业务并不需要这些能力，但每次调用都会执行；高并发场景带来额外延迟与资源消耗。 --- **三、手搓 Agent 的核心优势：完全掌控** 1. **链路完全透明，可观测可控** 所有代码自主实现，可以任意埋日志、监控、断点。故障定位不需要穿透第三方黑盒，生产环境降低排错耗时。 2. **无冗余逻辑，按需实现** 只实现业务必需逻辑，没有通用兼容包袱；性能优化空间完全自主掌握。 3. **外部依赖风险低** 核心逻辑自研，不受第三方框架接口变更影响；仅依赖底层 LLM SDK，稳定性更强。 > Anthropic 官方建议：优先用最少抽象实现核心逻辑；过度框架抽象会加大故障调试成本。 --- **四、选型判断** **使用成熟框架适合** - POC 原型验证，快速验证业务想法； - 团队初次接触 Agent，规避基础底层坑； - 重度依赖框架生态组件，Agent 业务逻辑简单。 **手搓核心逻辑适合** - 进入生产环境，重视稳定性； - 流量上涨，性能、成本敏感； - 业务逻辑高度定制，和框架通用模型冲突； - 要求高可观测、完整链路回溯。 **工程折中方案（最常用）** > **Agent 核心心脏逻辑手写，周边组件复用第三方库** - 手写：Agent 循环、消息管理、工具执行、重试、会话状态、记忆处理； - 复用：链路追踪、文档解析、向量数据库客户端等外围组件。类比建房：自主把控承重墙、房屋布局；五金配件直接采购成品，不必从零制造。 --- **五、手搓的代价** - 需要自行实现大量边界处理：参数校验、多模型工具格式兼容、各类异常分类、重试、持久化、埋点，开发与测试成本上升。 - 框架已经沉淀大量线上边界 Case，手搓需要自己踩坑。 - 维护成本上升，对团队成员有大模型开发能力要求；人员流动场景维护负担加重。 - 复杂 Multi‑Agent 场景，完全手搓工作量会急剧放大。 > LangGraph 定位：仍然属于框架，但抽象偏向状态机，不强制使用高层 Agent 执行器；很多团队使用 LangGraph 做状态与 Checkpoint，Agent 业务循环自行编码，是中间路线。 ## 如何赋予 LLM 规划能力？

LLM 本身是**逐 token 生成**，直接输出答案是**隐式推理**，复杂任务容易误差累积、产生幻觉。规划能力的核心，就是把隐式推理显式化。首先是 CoT 思维链，分为 Zero‑shot 和 Few‑shot，通过提示词让模型输出线性思考步骤，实现简单，是 Agent 标配。但它**只有单条推理路径，一旦中间步骤出错，错误会顺着链条传递，没有纠偏回退的能力**。为了解决 CoT 单路径出错的问题，出现了 **ToT 思维树。它在应用层做多路径探索，流程是生成多条候选思路、对路径评估打分、剪枝保留优质路径迭代探索**。注意它不是模型内部的 beam search，是多次调用 LLM 在业务层实现的。它能规避单链走错的问题，但缺点是调用成本高，一般是 CoT 的 3‑5 倍，评估本身也会幻觉，工业界大多用简化版本，很少直接复现论文。再往上是 **GoT 思维图，把树形改成图结构，支持不同分支中间结果的汇聚复用**。不过实现复杂、开销大，目前主要停留在学术，生产基本不用。CoT、ToT、GoT 属于推理范式，可以脱离工具 Agent 使用。落到 Agent 工程落地，**主流用 Plan‑and‑Execute 规划执行模式。它把任务分成规划、执行两个阶段，由 Planner 做全局任务拆解，Executor 负责分步执行，执行内部经常嵌套 ReAct 循环，也就是思考‑行动‑观察**。这里重规划器 Re‑planner 是必不可少的，会根据工具返回结果动态修正计划，避免计划僵化。规划和执行还可以使用不同模型，做质量和成本的权衡。简单任务直接用 ReAct；复杂多工具任务，**业界通用方案是 CoT 加上带重规划的 Plan‑and‑Execute**。ToT 只在高准确率、预算充足场景考虑使用，GoT 了解思想即可。

LLM 原生为 next‑token 逐词生成模式，直接输出答案属于隐式推理。长任务场景下推理误差会逐步累积，容易产生幻觉错误。规划能力本质：**将模型内部隐式推理过程显式化**。 --- **一、CoT 思维链 Chain‑of‑Thought** **原理**：引导模型输出完整线性推理步骤，推理步骤进入上下文，作为后续生成的输入依据。 - Zero‑shot CoT：Prompt 添加提示词，不提供示例，让模型自主展开推理。 - Few‑shot CoT：提供多组包含完整推理过程的示例，让模型模仿推理格式输出。 **优势**：实现成本极低，仅修改提示词，是 Agent 系统标配。 **局限性**：仅维护单条推理路径；若中间步骤出错，错误沿链条传播，无回退、纠偏机制。 --- **二、ToT 思维树 Tree‑of‑Thought** **原理**：解决 CoT 单路径失效问题，应用层实现多路径搜索循环： - 生成多条候选推理分支； - 调用模型对各分支可行性做评估打分； - 剪枝舍弃低质量路径，保留高价值路径继续向下探索；循环迭代直至得到结果。 > 区别于模型内部 beam search：ToT 是多次独立 LLM 调用，在应用侧完成生成‑评估‑剪枝。 **优势**：支持多路径探索，可放弃错误分支，提升复杂任务正确率。 **局限性**：LLM 调用次数显著增加，典型场景算力成本为 CoT 的 3‑5 倍；评估环节本身存在幻觉风险，可能错误剪枝正确路径；分支数量、搜索深度需要调参；论文原版完整实现较少用于生产，多使用简化变种。 --- **三、GoT 思维图 Graph‑of‑Thought** **原理**：在 ToT 树形结构基础上升级为图结构。树结构节点仅能拥有单个父节点，分支互相独立；图结构允许一个节点接收多个前置节点输出，实现不同推理分支中间结果的汇聚、复用、合并。 **优势**：适配需要融合多条独立推导结论的复杂任务，推理表达能力更强。 **局限性**：节点依赖、图遍历、序列化实现复杂度高；Token 开销大；以学术研究为主，几乎无生产落地。 > 注：CoT、ToT、GoT 属于**推理范式**，可用于普通问答，不强制绑定工具调用。 --- **四、ReAct** 原理：Agent 局部循环范式，`Reasoning+Acting`。每一轮执行：先思考，再执行工具行动，再接收外部观察结果，进入下一轮循环。无顶层全局计划，属于边走边决策。 --- **五、Plan‑and‑Execute 规划‑执行模式（工程主流 Agent 规划方案）** 原理：将任务拆分为规划、执行两个阶段，增加重规划环节，用于复杂多工具 Agent： - **Planner 规划器**：接收用户目标，拆解出全局步骤清单；通常使用能力更强的大模型。 - **Executor 执行器**：按步骤执行任务，执行单元内部常结合 ReAct 完成单步思考与工具调用；可使用低成本模型。 - **Re‑planner 重规划器（必要组件）**：每一步执行完毕，结合工具返回结果评估现状，动态更新、修正原有计划。 --- **六、和 ReAct 关系** 二者非替代关系。Plan‑and‑Execute 负责顶层全局任务编排；Executor 内部可以嵌套 ReAct 完成单步循环。 **优势**：具备全局任务视角；规划、执行可拆分不同模型，实现质量与成本权衡。 **局限性**：用户需求模糊时，初始规划本身易出错；缺少重规划器会造成计划僵化，任务失败；细碎任务场景下预先生成完整计划会带来不必要开销。 > 关键概念区分 > > - CoT/ToT/GoT：推理范式，解决单步如何思考；可脱离工具 Agent。 > - ReAct：Agent 局部执行循环范式，思考‑行动‑观察。 > - Plan‑and‑Execute：Agent 高层任务编排范式，全局拆解、分步执行、动态修正。 ## Agent 的反思机制？为什么用？怎么实现？

Agent 反思机制，**核心是为 Agent 增加检查、批判、修正的闭环**。大模型单次生成属于一次性输出，缺少自查，容易出现逻辑跳步、信息遗漏、事实幻觉，反思就是用来缓解这类问题。 **基础方案来自 Self‑Refine，核心循环是生成、评估、改进。先由 Agent 产出输出，评估环节从事实、逻辑、完整性几个固定维度做审查；合格就终止，不合格输出具体问题。改进阶段必须同时传入原始任务、原始输出、评估意见，做针对性修改。**循环不能只依靠模型自身判断停止，工程上优先用结构化输出，**并且设置最大迭代轮次兜底，一般 2‑3 轮，防止死循环**。 **反思分为步骤级和任务级两种粒度**。步骤级反思在每一步工具调用之后执行，可以尽早拦截错误，避免错误向后传导，但每一步都会带来额外调用成本；任务级反思是任务全部完成后全局复盘，可以发现整体层面的矛盾，但如果中途出错，前面的执行会被浪费。 **反思分为自我反思和独立 Critic Agent 互评。自我反思是同一个模型既生成又检查，存在自洽偏见，难以识别自己制造的幻觉。Critic Agent 把生成和审查角色拆分，审查视角更客观，但会增加系统复杂度和调用开销，只用于质量要求高的场景**。学术界还有 Reflexion、LATS、辩论式反思。Reflexion 把失败经验保存，实现跨任务复用教训，但受上下文窗口限制。LATS 把树搜索和反思结合，偏向学术。工程落地需要做取舍，反思只加在关键节点，简单任务和强实时任务不开启，同时要认清反思不能彻底消除幻觉。

**一、为什么需要反思机制** LLM 为逐 token 生成模式，单次输出没有自查校验环节，容易产生逻辑跳跃、信息遗漏、事实幻觉、表达模糊等问题。反思机制就是为 Agent 引入**检查‑批判‑修正**的闭环，对已有输出识别缺陷并迭代优化。 --- **二、基础实现：Self‑Refine** 核心循环：**生成 → 评估 → 改进** 1. **生成**：Agent 产出原始输出。 2. **评估**：通过评估 Prompt，从事实错误、逻辑、内容完整性、表达清晰度多维度审查；设置终止信号，合格则通过，不合格输出具体问题与改进建议。 3. **改进**：改进 Prompt 同时传入**原始任务、原始输出、评估意见**，针对性修改输出。 4. **循环终止条件**：评估通过，或达到最大迭代轮次强制退出。 > 工程要点：不依赖纯文本 PASS 字符串匹配，优先采用结构化输出；必须配置最大迭代轮次兜底，避免无限循环。例如： ``` 任务：{task} 当前输出： {current_output} 请评估以上输出： 1. 有没有事实错误或逻辑问题？ 2. 有没有遗漏重要内容？ 3. 表达是否清晰准确？如果输出已经足够好，回复「PASS」；否则指出具体问题并给出改进建议。 ``` 如果评估结果不是 PASS，就把评估意见喂进第二个改进 prompt： ``` 原始任务：{task} 当前输出：{current_output} 评估意见：{reflection} 请根据评估意见改进输出： ``` --- **三、两种反思粒度** **步骤级反思** 每一次推理 / 工具调用完成后执行反思。 - 原理：在执行链路早期识别错误，阻止错误向后传递放大。 - 适用：步骤强依赖，前置错误会造成后续全部失效的任务。 - 代价：每步额外增加 LLM 调用，Token 与延迟开销高。 **任务级反思** 全部任务执行完毕后做一次全局反思。 - 原理：站在全局视角，发现单步骤无法察觉的整体矛盾、衔接问题。 - 适用：步骤相对独立，看重最终输出整体质量的任务。 - 代价：若任务中途出现严重错误，前期执行工作会被浪费。 --- **四、自我反思 vs Critic Agent 多 Agent 互评** 1. **自我反思**：同一个模型既负责生成，又负责评估。局限：存在自洽偏见，模型容易认可自己生成的错误，无法识别自身产生的高阶幻觉。 2. **Critic Agent 独立互评**：分离生成 Agent 与审查 Agent，Critic 专门做问题排查。原理：独立角色不受生成阶段固有逻辑约束，审查视角更客观。两种实现： - ① 同一模型使用不同 System Prompt； - ② 使用能力更强的独立模型。局限：增加 LLM 调用次数，提升系统复杂度与成本；仅适合高要求场景。 --- **五、学术进阶方案** - **Reflexion** 在 Self‑Refine 单任务迭代基础上，将反思得到的失败经验保存，作为后续任务的上下文参考，实现**跨任务复用教训，避免重复犯错**。 - 局限：经验直接注入上下文，依靠模型自身利用记忆，无专门向量检索；受上下文窗口长度限制。 - 区分：Self‑Refine 是**任务内迭代优化输出**；Reflexion 是**跨任务沉淀经验**。 - **辩论式反思** 多个 Agent 互相对抗辩论，一方输出方案，另一方专门提出反对意见，持续迭代优化输出。适用于高严谨度场景。 --- **六、工程权衡** - **适合开启反思**：输出质量要求高、错误代价大、逻辑复杂的关键节点。 - **不适合开启反思**：简单任务、高实时性要求场景，会带来额外延迟与成本。 - **硬性约束**：最大迭代轮次一般设置 2‑3 轮，作为强制兜底。 - **本质局限**：反思不能完全消除幻觉，若模型本身能力不足，无法识别自身错误。 - **落地现状**：工业界普遍使用任务级 Self‑Refine；步骤级反思、Critic 互评。 ## 多 Agent 的协作与动态切换机制？

多 Agent 协作与动态切换，核心解决两个核心问题：**Agent 之间如何传递信息，以及如何调度切换不同 Agent。** 主流**协作范式包含流水线、层级 Orchestrator 集中调度、协商模式**，多种范式可以组合使用。Agent 通信分为消息传递和共享状态。消息传递基于消息中间件，发送消息，下游订阅消费，优势是组件解耦、支持并行，但依赖中间件，需要处理消息可靠性。共享状态是所有 Agent 共用一套状态存储，适合步骤强依赖的流水线；设计上需要区分全局与局部状态，使用增量追加更新，避免数据覆盖污染。 **切换分为集中调度 Orchestrator 和去中心化 Handoff**。 Orchestrator 包含静态路由和 LLM 动态路由。静态路由依靠预设规则，稳定可预测；动态路由交由大模型决策，灵活但是带来额外开销，还会出现路由错误。工程一般主流程用静态路由保底，边缘场景启用动态路由，同时做参数校验、兜底 Agent 和日志记录。 Handoff 是去中心化交接，由当前 Agent 直接转交任务，没有中央调度；扩展性好，但缺少全局视图，极易产生循环，必须做访问记录检测循环，只适合 Agent 少、边界清晰的场景。复杂任务优先使用 Orchestrator 集中调度。选型上结合依赖关系、任务复杂度选择通信和调度方案。

**一、多 Agent 协作基础范式** 1. **流水线模式**：Agent 按照预设固定顺序串行执行，前序完成后流转至下一个 Agent；适用于标准化流程，灵活性较差。 2. **层级调度模式**：存在 Orchestrator 中央调度单元，负责任务拆解、子任务分发、结果聚合，支持子任务并行执行；存在中心节点单点风险。 3. **协商模式**：Agent 无上下级关系，依靠互相沟通、辩论达成共识；多用于方案评审，必须配置终止条件，否则对话难以收敛。 > 三种范式非互斥，复杂系统可混合使用。 --- **二、Agent 间通信协作机制** **① 消息传递** 原理：Agent 完成处理后将消息发送至消息中间件，下游 Agent 订阅对应事件进行消费处理。 - 优点：Agent 之间解耦，发送方无需感知接收方；天然支持多 Agent 并行执行。 - 缺点：依赖中间件组件，需要处理消息丢失、消息重试，系统复杂度提升。 - 适用：Agent 弱依赖，追求组件解耦、需要并行处理的场景。 **② 共享状态** 原理：全部 Agent 读写同一个状态对象，Agent 执行完成写入中间结果，其他 Agent 读取状态获取数据，LangGraph State 为典型实现。 - 优点：实现简单，数据集中存储，适配步骤强依赖的流水线流程。 - 缺点：全局状态为读写热点，并发下需要锁机制；易出现数据覆盖、脏数据，存在状态膨胀问题。 - 适用：Agent 前后步骤强依赖，流程明确的流水线。 **共享状态核心设计要点** - 状态分层 - 全局状态：存储公共数据，用户原始请求、任务进度、最终结果、错误信息，全部 Agent 可见。 - 局部状态：存储单个 Agent 私有中间产物，不对外暴露，防止信息污染。 - 更新策略：采用**增量追加更新**，禁止直接覆盖原有字段，由框架完成增量合并，避免数据被意外改写。 - 错误透传：Agent 执行失败时将错误写入状态，调度器依据错误执行重试、跳过、终止逻辑。 - 运维约束：做状态裁剪与快照，避免上下文无限膨胀。 --- **三、动态切换（路由）机制** 路由即决策下一步交由哪个 Agent 执行，分为集中式 Orchestrator 调度、去中心化 Handoff 交接。 **① Orchestrator 集中调度** **静态路由** 原理：预先编写业务规则，基于任务类型、执行进度分配 Agent。 - 优点：行为可预测，易于调试，无额外 LLM 调用，性能稳定。 - 缺点：无法处理未预定义的边缘场景。 **LLM 动态路由** 原理：向 LLM 传入当前任务上下文、可用 Agent 列表，由模型决策下一步 Agent。 - 优点：灵活性高，可处理未知边缘场景。 - 缺点：增加 LLM 调用，延迟与成本上升；存在路由错误，行为不可预测，故障复现难度高。 - 防护手段：校验输出 Agent 合法性，配置 Fallback 兜底 Agent，完整记录路由决策日志。 > 工程实践：主流程采用静态路由保障稳定性，边缘异常场景使用动态路由兜底。 **② Handoff 交接模式（去中心化）** 原理：不存在中央调度器，当前正在执行的 Agent 自主判断，直接将任务交接给下一个 Agent。 - 优点：无中心瓶颈，Agent 对自身任务边界感知最清晰，扩展性较好。 - 缺点：缺少全局视角，容易发生循环交接。 - 强制约束：维护已访问 Agent 列表，检测重复访问，触发终止或者切换兜底 Agent。 - 适用：Agent 数量少、职责边界清晰、任务流转简单；不支持复杂任务拆分、子任务并行与结果聚合。 --- **四、选型原则** 1. 强依赖流水线任务，选用共享状态；需要解耦、并行执行，选用消息传递。 2. Agent 少、边界清晰简单流转场景，可使用 Handoff；Agent 数量多、逻辑复杂优先 Orchestrator 集中调度。 3. 路由策略：静态规则为主，动态路由仅用于兜底边缘 case。 ## 什么是 Function Calling

Function‑Calling 是大模型标准化的工具调用机制，**核心要明确，模型只负责输出调用决策指令，它不能执行代码，也不能直接联网，真正执行函数和 API 的是宿主业务代码**。在该机制出现之前，工具调用依靠解析模型输出的自然语言意图，稳定性很差。Function‑Calling 通过 JSON Schema 定义工具，写明工具名称、功能描述以及入参，其中 description 直接影响模型选工具和填参的准确率。完整流程是**两轮模型推理加上中间本地执行。第一轮传入用户问题与工具定义，如果模型判定需要调用工具，finish_reason 会为 tool_calls，返回结构化 tool_calls，包含工具名、参数以及 tool_call_id。业务代码解析后执行工具，拿到结果，以 tool 角色消息回填上下文，携带 tool_call_id 做调用关联，再发起第二轮模型请求，模型结合工具返回结果输出最终答案。** 它支持**并行工具调用**，无数据依赖的多个工具，模型一次输出多条调用指令，业务侧并发执行，减少推理轮次降低延迟；存在依赖的调用只能串行。工程层面需要处理 JSON 格式异常，对模型输出参数做校验，配置最大调用轮次，防止循环调用与上下文溢出。同时要区分原生 Function‑Calling 和 Prompt 模拟 JSON 输出，模拟方案稳定性更低。

**一、定义** Function Calling 是大模型标准化工具调用机制。开发者使用 JSON Schema 描述外部工具，当任务需要外部信息或能力时，模型输出结构化的 `tool_calls` 调用指令，**模型仅做决策，不执行任何代码、不能直接访问网络**；由宿主程序解析指令完成实际函数、API 的执行，工具执行结果回填对话上下文，模型结合外部结果生成最终回答。 --- **二、产生背景** 在 Function‑Calling 之前，工具调用依靠模型输出自然语言表达调用意图，业务代码通过字符串匹配、规则判断解析意图。该方式鲁棒性差，受模型输出话术影响大，没有统一标准。Function‑Calling 通过约束模型输出结构化 JSON，实现标准化工具调用，提升稳定性。 --- **三、底层本质** 并非模型内置函数执行能力，是经过专项对齐微调，使模型遵循固定格式输出工具调用 JSON。模型依然存在输出非法格式的可能性。区分原生 Function‑Calling 与 Prompt 模拟调用：原生为模型 API 原生支持，稳定性高；仅依靠提示词强制输出 JSON 属于模拟方案，稳定性弱。 --- **四、工具 Schema** Schema 为工具的结构化描述，核心字段： 1. `name`：工具唯一标识，模型调用时引用。 2. `description`：描述工具功能、适用场景、限制条件；模型选择工具、填充参数主要依赖此字段，描述模糊会引发误调用。 3. `parameters`：基于 JSON Schema 定义入参，包含参数类型、描述、枚举值、`required` 必填列表。 --- **五、完整执行闭环** 整体为**两轮模型推理 + 中间本地执行** 1. 第一轮：用户请求连同工具 Schema 传入模型。`tool_choice`控制调用策略：`auto`模型自主判断； 2. 若返回 `finish_reason="tool_calls"`，模型返回 `tool_calls` 数组，包含工具名称、入参、`tool_call_id`，表示需要调用外部工具，不输出最终答案。 3. 宿主代码解析 `tool_calls`，执行对应工具逻辑，获取执行结果。 4. 将工具结果以 `role:tool` 的消息回填对话上下文，回填消息必须携带对应 `tool_call_id`，用于关联调用与返回结果。 5. 第二轮调用模型，模型结合原始上下文与工具返回数据，生成最终自然语言输出。 --- **六、并行工具调用** 1. 原理：多个工具调用不存在数据依赖时，模型单次响应返回多条 `tool_calls`；宿主程序并发执行全部工具，结果一次性回填上下文。 2. 收益：减少 LLM 推理轮次，降低整体延迟。 3. 约束：后序工具入参依赖前序工具输出时，存在数据依赖，只能够串行调用。 --- **七、工程约束与风险** 1. 模型可能输出非法 JSON，需要解析容错、重试处理。 2. 不可信任模型输出的参数，业务层必须做参数校验，防范非法入参。 3. 设置最大工具调用轮次阈值，避免模型无限循环调用工具。 4. 工具返回内容过大，需要截断或者摘要压缩，防止上下文窗口溢出。 ## LLM 是如何学会调用外部工具的？

大模型原生预训练是没有工具调用能力的，工具调用不是参数量大带来的涌现能力，需要经过两阶段专项训练。第一阶段是 SFT 监督微调，**构造大量完整工具调用对话样本去训练模型，让模型学会识别工具定义，按照规范输出 tool_calls 结构化 JSON，**解决 “会不会调用工具” 的问题。但是 SFT 存在缺陷，训练样本调用场景居多，模型容易过度调用，简单问题也会错误触发工具，缺少判断边界。第二阶段通过 RLHF 人类反馈强化学习来补齐边界判断力。**首先让模型生成多种输出，人工做偏好打分，训练奖励模型，再用 PPO 强化学习迭代主模型，教会模型区分哪些场景要调用工具，哪些场景直接回答**。RLAIF 是它的变体，用 AI 替代人工标注，降低成本。训练完成之后进入运行时，也就是 Function‑Calling 机制。业务把工具 Schema 和用户问题传给模型，模型输出结构化调用指令；注意模型只做决策，不会执行工具，由宿主代码真实执行函数 API，工具结果回填上下文，再交给模型生成最终答案。这种模型决策、代码执行的分工，也方便业务做权限、沙箱、参数校验，保证安全。

**一、基础认知** 预训练阶段的原生大模型**不具备工具调用能力**。预训练仅学习文本预测下一个 token，训练语料不存在标准化工具调用 JSON 格式。即便提示词告知模型可调用 API，未经过专项训练的模型只会输出自然语言描述意图，无法输出机器可解析的结构化调用指令。工具调用能力不是模型涌现能力自然获得，需要通过**SFT 监督微调 + RLHF 强化学习**两个阶段专项训练获得。模型仅负责工具调用决策，工具实际执行由外部宿主代码完成。 --- **二、第一阶段：SFT 监督微调（Supervised Fine‑Tuning）** 1. 目标：教会模型**怎么调用工具**，掌握输出规范结构化 JSON 的格式、完整对话流程。 2. 训练样本构成：样本包含 System 工具 Schema 说明、用户提问、Assistant 工具调用 JSON、Tool 工具返回结果、Assistant 最终自然语言回复。 3. 数据来源：人工标注高质量种子样本；强模型生成 + 人工校验的批量样本，为业界主流。 4. 能力收益：模型学会识别工具定义、识别用户意图、输出格式合法的`tool_calls`结构化指令。 5. 固有缺陷：样本中工具调用场景占比高，模型容易过度倾向调用工具，缺少 “不应该调用工具” 的判断力，边界感差；简单问题也会错误触发工具调用。SFT 只解决 “会不会调”，不能解决 “该不该调”。 --- **三、第二阶段：RLHF 人类反馈强化学习** 1. 目标：建立模型调用工具的判断力与边界感，解决 SFT 带来的过度调用问题，学会区分什么场景需要调用工具，什么场景直接回答即可。 2. 完整四步流程 1. 多样本生成：同一输入让模型产出多种行为，包含正确调用、错误调用、直接回答等多类输出。 2. 人工偏好标注：标注人员对不同输出做优劣打分，区分合理 / 不合理的工具调用行为。 3. 训练奖励模型 RM：基于人工打分数据训练独立打分模型，用来评判工具调用行为的优劣；奖励模型质量直接决定后续优化方向。 4. PPO 强化学习迭代主模型：利用奖励模型打分持续更新主模型参数，让模型偏向高分的合理行为。 3. RLAIF：RLHF 变体，使用 AI 替代人工完成打分标注，降低成本，工业界广泛使用。 --- **四、运行时推理阶段（Function Calling 运行机制）** 模型完成训练之后，上线推理阶段流程： 1. 业务侧将工具 Schema 集合连同用户 Query 一起传入模型。 2. 模型根据意图与工具描述做出决策，需要工具辅助则输出结构化`tool_calls`JSON 指令。 3. 宿主业务代码解析调用指令，完成真实函数、API 执行。 4. 将工具执行结果以`role:tool`消息回填对话上下文。 5. 再次请求模型，模型结合工具返回结果生成最终自然语言答案。 > Function Calling 就是训练完成后，工具调用能力在运行时的落地实现。 --- **五、核心设计原则** 模型只负责意图理解、工具选择、参数生成的决策工作；**不执行函数，无网络与系统访问权限**。执行交由宿主代码，业务层可以实现参数校验、权限管控、沙箱隔离，保障系统安全。 ## 什么是 MCP

MCP 全称模型上下文协议，是 Anthropic 推出的开放协议，它不是框架，要和 Function‑Calling 做区分。**Function‑Calling 解决模型怎么输出调用指令，MCP 解决工具标准化接入**，解决过去工具对接碎片化、强绑定 AI 应用、难以复用的痛点，**目标是工具实现一次，所有兼容 MCP 的客户端都可以直接使用**。 MCP 采用 Client‑Server 架构。Server 端封装工具、数据逻辑；**Client 端是 AI 或者 Agent 应用，一个 Client 可以连接多个 Server，聚合多种外部能力。MCP 定义三类核心能力：Tools 是带副作用的操作，会修改外部状态；Resources 是只读的数据资源；**Prompts 是可传参的提示词模板，方便团队复用。底层通信基于 JSON‑RPC2.0，传输支持 stdio 本地子进程模式，也支持 Streamable HTTP 远程部署。旧的 HTTP 加 SSE 双端点方案已经废弃。MCP 生态发展快，得益于开源 SDK 降低开发门槛，以及大量现成社区 Server，主流 AI 客户端原生支持，接入工具只需要配置，不用编写大量适配代码。运行时 MCP 会把 Server 的 Tools 转换成 Function‑Calling 的 Schema 给大模型，两者是配合协作的关系。

**一、定义与解决的问题** MCP 是 Anthropic2024 年底推出的**开放标准化协议**，不是框架，也不等同于 Function‑Calling。 > Function‑Calling 解决：模型侧如何输出工具调用结构化请求。 MCP 解决：工具侧如何标准化接入 AI 客户端，解决工具接入碎片化。在 MCP 出现前，工具对接强绑定特定 AI 应用，每接入一个工具需要编写定制适配、认证、格式转换代码，更换模型 / Agent 框架需要重新开发，工具无法复用。MCP 目标：工具按照协议实现一次，任意兼容 MCP 的客户端均可直接使用，实现一次实现，多处复用。类比 USB 接口标准。 --- **二、Client‑Server 架构** - **MCP Server**：工具能力实现端，封装业务逻辑、鉴权、错误处理，对外暴露能力。可以本地子进程运行，也可以远程部署。单个 Server 可对外暴露多项能力。 - **MCP Client**：AI 应用 / Agent 运行时端，例如 Claude Desktop、Cursor、自研 Agent，负责和大模型交互，与一个或多个 MCP Server 建立连接，自动发现 Server 提供的全部能力。 - 关键特性：一个 Client 可以同时连接多个不同 Server，聚合多方工具、数据、提示模板能力，无需额外适配代码。 --- **三、三大核心能力** 1. **Tools（工具）** 对应 Function‑Calling 中的函数，执行**存在副作用**的操作，会改变外部状态：创建文件、提交代码、调用 API、发送消息。存在状态变更，通常需要用户授权。 2. **Resources（资源）** 只读数据能力，无任何副作用，仅向模型提供数据：读取日志、查询数据库记录、读取文档。仅读取不修改，授权约束更宽松。 3. **Prompts（提示模板）** 预定义带占位参数的提示词模板。用于复用团队标准化 Prompt，传入参数即可展开完整 prompt，避免重复编写提示词，多用于工程、团队协作场景。 --- **四、底层通信机制** 1. 基础协议：底层基于 **JSON‑RPC 2.0**，轻量远程调用，使用 JSON 表达请求、参数、ID、响应与错误，语言无关。 2. 传输层两种实现： - stdio：Server 作为本地子进程，通过标准输入输出管道通信；适合本地工具，无需网络，低延迟。 - Streamable HTTP：远程 HTTP 服务，单`/mcp`端点；普通请求返回 JSON，长任务自动升级 SSE 流推送增量结果。 --- **五、MCP 与 Function‑Calling 关键区分** - Function‑Calling：属于**模型侧能力**，定义模型如何输出 tool_calls 调用指令。 - MCP：属于**工具接入层协议**，定义客户端和工具服务之间如何通信、如何暴露工具 / 资源 / 模板。二者配合工作：MCP Client 获取 MCP Server 的 Tools 列表，转化为模型 Function‑Calling 的 Schema 传给大模型；模型输出 tool_calls；Client 再通过 MCP 协议调用远端 Server 执行工具。 ## Skill 是什么

Skill 是 Anthropic 推出的 Agent 能力封装开放规范，用来把任务 SOP、指令、模板、参考资料打包成可版本管理复用的模块，解决传统复制粘贴 Prompt 带来的输出不稳定、团队标准不一致的问题。 **一个 Skill 就是一个文件夹，核心是 SKILL.md 文件，头部放元数据，正文写完整业务流程，还可以附带脚本、参考文档、输出模板。它最重要的设计是渐进式加载，为了节省上下文 token。Agent 启动时只加载每个 Skill 的名字和描述建立索引；任务匹配到对应 Skill 才加载完整指令；执行过程用到模板和参考文件时才读取附属资源，不会一次性把全部 Skill 塞进上下文。** 要区分几个概念：Tool 是底层执行能力，负责做事；Skill 是操作 SOP，定义拿到工具之后按什么流程完成任务；普通 Prompt 是一次性临时指令。Slash Command 需要用户手动触发，Skill 支持 Agent 自动识别任务、自动调用。该规范已经开源，目标实现跨 Agent 平台复用。

**一、定义与解决痛点** Skill 是 Anthropic 提出的**Agent 能力封装规范**，将反复使用的任务指令、执行 SOP、模板、参考资料、辅助脚本打包成可版本管理、可复用的标准化模块。解决痛点： 1. 普通 Prompt 是临时文本，每次对话需要手动复制粘贴，容易遗漏细节，输出不稳定。 2. 团队场景下人工复制 Prompt，版本分散，标准无法统一，更新难以同步。 3. Skill 支持 Agent**自动识别任务并主动调用**，无需人工手动输入触发指令。 --- **二、Skill 目录结构** Skill 以独立文件夹作为载体，核心文件为`SKILL.md`，其余资源可选。 - `SKILL.md`：必须存在。头部 YAML frontmatter 元数据（name、description），主体 Markdown 编写完整任务步骤、指令。 - `scripts/`：可选，存放可执行脚本。 - `references/`：可选，存放参考标准、文档资料。 - `assets/`：可选，输出模板、配置等资源文件。 --- **三、核心机制：渐进式加载（Progressive Disclosure）** 目的：节约上下文窗口 token，避免全部 Skill 一次性载入造成上下文膨胀。三层加载模型： 1. **第一层：索引层（仅元数据）** Agent 启动阶段，只加载每个 Skill 的`name`与`description`，token 消耗极低。Agent 仅知道 “有哪些能力可用”，不加载详细指令正文。 2. **第二层：加载指令正文** 当 Agent 判断当前任务匹配某个 Skill，才读取完整`SKILL.md`指令内容，注入上下文；无关 Skill 完全不加载。 3. **第三层：按需加载附属资源** 执行流程中，当指令引用模板、参考文档、脚本时，才读取对应的附属文件，未引用则不载入。本质：只在需要的时候，才把需要的内容送入上下文，最大化节约上下文窗口。 --- **四、Skill / Tool / Prompt / Slash Command 的区分** 1. **Tool（工具，含 MCP Tools）**：代表底层执行能力，用来做事，读写文件、调用 API、执行命令；只提供操作手段，**不知道业务流程与步骤**。类比员工的电脑软件。 2. **Skill**：业务 SOP、操作手册。定义拿到工具之后，按什么步骤、标准、格式完成完整任务。**Skill 依赖 Tool 完成实际操作**。 3. **Prompt**：临时口头指令，一次性，对话结束即失效，无法版本管理。 4. **Slash Command 斜杠命令**：保存好的指令片段，**必须用户手动触发调用**；Skill 可由 Agent 根据任务自动判断、自动加载执行，不需要用户显式触发。 > 关系：Tool 负责 “能做什么”，Skill 负责 “该怎么做”，Prompt 是临时口头指令。 ## A2A 协议？和 MCP 区别是什么？

A2A 是 Google 推出的 Agent‑to‑Agent 开放协议，**用来解决多个 AI Agent 之间发现、委派子任务、协作的问题。** **单个 Agent 存在工具过载、上下文窗口、专业能力三大约束，A2A 就是把大任务拆给多个专业子 Agent 执行。子 Agent 内部所有中间过程隔离，只返回最终结果，保护主控 Agent 上下文。** A2A 核心有 Agent Card 和 Task。Agent Card 是 JSON 名片，声明自己拥有哪些 Skill，实现 Agent 自动发现；Task 是任务单元，拥有完整状态机，专门支持长耗时异步任务，可以轮询或者 Push 回调通知完成。本质就是 Agent 世界的微服务。注意区分 MCP：MCP 是纵向向下，Agent 连接工具与数据；A2A 是横向，Agent 连接其他 Agent。二者互补，不存在替代关系。一般子 Agent 内部用 MCP 调用工具，Agent 之间互相委派子任务使用 A2A。

**一、定义 & 要解决的问题** A2A 是 Google 推出的**开放协议**，用于**Agent ↔ Agent 之间互相发现、委派子任务、协作通信**。 **单 Agent 三大瓶颈**（催生 A2A） - **工具过多**：单个 Agent 挂载大量工具，模型容易混淆、推理质量下降。 - **上下文窗口受限**：复杂任务中间产物快速占满上下文，信息被冲刷丢失。 - **专业能力局限**：一个 Agent 很难同时精通多类垂直领域。 > 多 Agent 协作收益：子任务交给子 Agent，**子 Agent 内部的中间过程隔离在自身上下文，只把最终摘要 / 结果返回给调度 Agent**，主控 Agent 上下文不会膨胀。 --- **二、A2A 核心概念** ① **Agent Card（Agent 名片）** 路径：`/.well‑known/agent‑card.json` - JSON 描述自身：身份、支持的 Skill 集合、能力说明、是否支持流式、异步回调。 - 作用：实现**自动发现**，新增 Agent 无需修改调度端代码；调度 Agent 读取卡片，判断该把什么子任务委派给谁。 ② **Task：任务基本单元** - 完整生命周期状态机：`submitted` → `working` → `completed / failed` - 产出物叫 `artifacts`：文本、文件、报告等结果。 - 原生面向**长耗时异步任务**：支持轮询状态 / Push 通知回调；调度 Agent 提交任务后可继续处理别的工作，不用阻塞等待。 ③ **架构本质：Agent 的微服务化** - A2A Agent 是独立 HTTP 服务，语言、框架无关。 - Agent Card ≈ API 文档；Task 状态机 ≈ 异步任务队列；自动发现 ≈ 服务注册中心。 --- **三、A2A vs MCP（重点，面试高频）** > 一句话定位： > > - ✅ **MCP：纵向，Agent 向下对接工具 / 数据资源（Agent‑to‑Tool）** > - ✅ **A2A：横向，Agent 向外对接其他 Agent（Agent‑to‑Agent）** > > 二者**互补，不是竞品，不互相替代**。 | 对比项 | MCP（Model Context Protocol） | A2A（Agent‑to‑Agent） | | -------- | ------------------------------------------- | --------------------------------------- | | 发布方 | Anthropic | Google | | 通信对象 | Agent ↔ 工具服务（Server） | Agent ↔ Agent | | 核心目标 | 工具、资源、Prompt 模板标准化接入、复用 | 多 Agent 互相发现、委派子任务、异步协作 | | 能力声明 | MCP Server 暴露 Tools / Resources / Prompts | Agent Card 暴露自身 Skill 列表 | | 任务模型 | 同步 / 流式工具调用，短操作为主 | Task 完整状态机，原生支持长耗时异步任务 | | 底层传输 | JSON‑RPC2.0；stdio / Streamable HTTP | HTTP 协议，JSON 负载，支持 Push 回调 | | 系统角色 | 每个 Agent 内部使用，拿外部能力 | 跨 Agent 之间分工调度、子任务委托 | ## MCP 协议的通信方式？

MCP 消息统一采用 JSON‑RPC2.0，消息格式和传输层解耦，有两种主流传输。本地场景用 stdio，客户端把 MCP Server 拉起为子进程，通过操作系统管道标准输入输出通信，不走网络，延迟低、不用端口，是本地工具的默认方案。远程跨机器场景现在推荐 Streamable HTTP，单 /mcp 端点 POST 调用；简单调用直接返回 JSON；流式长任务就在同一个 POST 连接升级 SSE 推送增量数据。早期是 HTTP+SSE 双端点方案，现在已经废弃，不要和 Streamable HTTP 混淆。MCP**没有使用 WebSocket 做传输**。

MCP**消息格式固定为 JSON‑RPC 2.0**，消息格式与底层传输层解耦。两大官方传输实现： 1. **stdio（本地子进程，首选）** 2. **Streamable HTTP（远程网络，新标准）** > 旧版双端点`HTTP+SSE`已废弃，仅做兼容；**MCP 不使用 WebSocket**。 --- **一、stdio（标准输入输出，本地）** - 场景：本机 MCP Server，作为子进程启动（Claude Desktop 本地工具就是这套） - 原理：操作系统管道，`stdin`发请求、`stdout`接收响应；**不走 TCP/IP、不占用端口**。 - 优点：延迟低、无网络安全风险；进程生命周期跟随客户端自动启停。 - 配置方式：客户端配置启动命令，spawn 子进程。 - 局限：只能本机，无法跨机器共享服务。 --- **二、Streamable HTTP（远程，当前规范推荐）** - 场景：跨机器、云端部署，多客户端共享同一个 MCP 服务。 - 单端点：`POST /mcp` - 1）短请求：直接返回 JSON； - 2）长任务 / 流式：同一个 POST 就地升级为 SSE 流，增量推送事件。 - 底层流式依旧使用 SSE，只是**取消双端点模式**。 - 优点：适配网关、反向代理、Serverless；支持多客户端共享服务。 - 缺点：带来网络延迟，需要处理鉴权、断连重连。 --- **三、已废弃：旧版 HTTP+SSE 双端点** - 两个接口：`GET /sse`建立长连接 + `POST /messages`提交请求。 - 问题：请求与事件分流到两条 HTTP 通道，会话绑定 SSE 连接，调试、状态管理复杂，Serverless 环境很难适配。 - 状态：deprecated，向后兼容，新项目禁止使用。 ## WebSocket 和 SSE 的区别及局限性？

我们先分清 SSE 和 WebSocket 的底层区别。**SSE 是基于 HTTP 的单向流式推送，不是新协议**。客户端发起 HTTP 请求，服务端保持长连接持续下发数据流，只能服务端主动发消息，客户端不能在这条长连接里上行发送数据。浏览器自带 EventSource，自带断线重连。 **WebSocket 是独立 TCP 全双工协议**，依靠 HTTP 握手升级，返回 101 状态码之后，通道脱离 HTTP。同一条连接可以双向随时收发消息。两者各有短板。SSE 最大问题是上下行通道割裂，发消息要额外调用 HTTP 接口；HTTP1.1 还有浏览器连接上限，原生不支持二进制。 WebSocket 的痛点在于它是有状态长连接，后端扩容很难，还要借助中间件转发消息；防火墙和 CDN 容易拦截，消息本身没有请求响应配对，业务要自己维护 ID，而且 TCP 重传会带来延迟。落到 AI 场景，选型一句话总结：**单向推送优先 SSE，真正双向实时通信再上 WebSocket**。普通大模型流式对话，用户提交 POST 请求，模型文字流式返回，SSE 足够，架构简单、运维方便，OpenAI 和 Anthropic 也都是这个方案。只有需要中途打断生成、多人实时协同这类随时上行消息的场景，才选用 WebSocket。实时语音对话适合 WebRTC，MCP 最新规范采用 Streamable HTTP，底层依然依托 SSE。不要盲目上 WebSocket，它会带来不必要的复杂度。

**一、核心原理与底层定义** **① SSE（Server-Sent Events）** SSE 是基于标准 HTTP 协议实现的**服务端单向流式推送**技术，不属于独立通信协议。客户端发起带流式标识的 HTTP 请求，服务端保持连接不关闭，持续向客户端推送文本数据流，连接持续复用直至任务结束或断开。通信模型为**单向通信**：仅服务端可主动推送数据，客户端无法在长连接通道内发送消息，客户端上行请求需额外发起独立 HTTP 请求。浏览器原生内置 EventSource API 支持，无需手动解析流数据，默认支持断线自动重连、消息序号回溯能力。 **② WebSocket** WebSocket 是基于 TCP 的**独立全双工通信协议**，并非 HTTP 衍生特性。通信建立阶段通过 HTTP 握手完成协议升级，返回 101 Switching Protocols 状态码后，TCP 连接脱离 HTTP 规范，转为独立双向通信信道。通信模型为**全双工双向通信**：客户端与服务端可在同一连接内随时主动发送消息，无通信方向限制，无需拆分上下行通道。 --- **二、各自局限性** **① SSE 局限性** - **通信通道割裂**：上下行分离，服务端推送走 SSE 长连接，客户端发消息需独立 HTTP 请求，需通过业务ID关联会话，状态管理复杂。 - **HTTP/1.1 连接数限制**：浏览器对单域名仅支持最多6条并行HTTP长连接，多标签页场景会导致连接排队、页面阻塞；该问题仅 HTTP/2、HTTP/3 可解决。 - **不支持原生二进制传输**：图片、音频等二进制数据需 Base64 编码，数据体积膨胀33%，增加传输与解码开销，不适合流媒体场景。 - **消息回溯依赖服务端实现**：内置重连仅基础能力，断线续传需服务端实现 Last-Event-ID 消息重放，默认实现易丢失数据。 **② WebSocket 局限性** - **有状态导致扩容困难**：连接固化绑定单个后端节点，横向扩容时新节点无法承接历史连接，需外置 Redis 等中间件做消息订阅中转，架构复杂度大幅提升。 - **网络兼容性差**：企业防火墙、老旧代理、CDN 常拦截 WebSocket 协议升级请求，导致连接建立失败，复杂网络环境适配成本高。 - **无原生请求响应配对**：消息无天然关联关系，需业务层自定义请求ID、维护回调映射表，断线重连后的请求重试、状态恢复逻辑繁琐。 - **TCP 重传延迟问题**：基于TCP可靠传输，网络波动时会持续重传丢失数据包，不适合实时性要求极高、可容忍少量丢包的语音视频场景。 --- **三、AI 场景下怎么选** 大原则是「单向推就用 SSE，真正需要双向才上 WebSocket」。文字对话天然是单向推：模型在说话，你在看，你想回复直接发一个新的 POST 就行，SSE 完全够。只有当你需要客户端在任意时刻主动说话，比如实时打断、多人协同编辑、游戏类实时同步，才值得引入 WebSocket 的复杂度。 | 场景 | 推荐方案 | 原因 | | ------------------------------------ | -------------------------------------- | ------------------------------------------------------------ | | LLM 流式文字输出（ChatGPT 风格） | SSE | 单向推送够用，轻量，HTTP 原生支持，运维简单 | | 多轮对话（用户发消息 + 模型回复） | SSE + 普通 POST | 用户发消息走 POST，模型回复走 SSE，解耦简单 | | 需要用户中途打断模型输出 | WebSocket | 需要客户端在流式输出中途主动发消息 | | 多人协同（多用户同时编辑、实时同步） | WebSocket | 频繁双向消息，SSE + POST 的双通道架构太繁琐 | | 实时语音对话 | WebRTC | 音频流需要 UDP + 低延迟，WebSocket 的 TCP 重传是瓶颈 | | MCP 远程 Server | Streamable HTTP（内部仍用 SSE 做流式） | MCP 2025-03-26 规范从早期的 HTTP+SSE 双端点升级为单端点的 Streamable HTTP，保留了代理穿透友好的特性 | 绝大多数 LLM 文字对话产品用 SSE 就够了，这也是为什么 OpenAI、Anthropic 的 API 都选 SSE 而不是 WebSocket。WebSocket 的复杂性只有在真正需要双向实时通信时才值得引入。 ## WebRTC 协议？和 WebSocket 在 AI 对话流中的差异？

WebRTC 是一套标准化实时媒体协议族，主要用于低延迟音视频场景，和 WebSocket 有本质区别。**WebSocket 底层基于 TCP，TCP 为保证可靠性会对丢失报文做重传**，对于文字传输是优势，但语音场景下重传会持续堆积延迟，造成对话卡顿抢话。 **WebRTC 媒体层使用 UDP 传输，放弃强制重传，通过丢包隐藏算法补偿少量丢包，以轻微音质代价维持低延迟。**它是多层协议组合：UDP 做底层传输，DTLS 完成 UDP 通道加密，SRTP 承载加密媒体数据，RTCP 做网络质量反馈。会话参数通过 SDP 协商，SDP 本身不负责传输，需要额外信令通道，例如 WebSocket 来交换。同时依靠 ICE 框架，通过本地直连、STUN 打洞、TURN 中转三级策略解决 NAT 内网穿透。WebRTC 还内置回声消除、降噪、自动增益、码率自适应等音频处理能力。 WebSocket 适合文本数据双向通信；WebRTC 适合实时语音，但部署复杂，需要信令、STUN、TURN 服务。OpenAI Realtime 语音 API 就是使用 WebRTC 实现低延迟实时对话。

**一、为什么实时语音场景需要 WebRTC** 文字传输依赖 TCP 可靠有序，丢包必须重传，保证内容完整正确。语音场景对延迟高度敏感，端到端延迟超过 200ms 即可感知卡顿，超过 400ms 会出现抢话冲突；语音可容忍少量报文丢失，但不能容忍重传带来的延迟堆积。 **WebSocket 底层基于 TCP，丢包会触发 TCP 重传**，阻塞后续媒体报文，延迟持续累积，无法满足低延迟语音对话需求。 WebRTC 是 W3C/IETF 标准化的**协议族**，并非单一协议，**媒体传输基于 UDP**。UDP 不提供重传与可靠保障，WebRTC 在 UDP 之上实现丢包隐藏算法，音频帧丢失时通过插值生成替代音频，以微小音质损失换取稳定低延迟。 --- **二、WebRTC 协议栈** - **UDP**：底层传输，无重传，保障低延迟。 - **DTLS**：UDP 之上的加密层，UDP 版本 TLS，完成密钥协商，对媒体数据加密。 - **SRTP**：承载加密音视频媒体，继承 RTP，携带序列号、时间戳，用于报文排序与丢包检测。 - **RTCP**：控制协议，负责网络质量统计、反馈，支撑自适应码率控制。 - **SDP**：会话描述协议，文本格式，协商编解码、加密参数、媒体能力；**SDP 只定义内容格式，不负责传输**。 - ICE 框架：NAT 穿透框架，连接尝试优先级： - 本地直连：同一局域网内网地址通信 - STUN：获取公网地址，NAT 打洞建立连接 - TURN：打洞失败时做流量中转服务器 > WebRTC 媒体流走 UDP，SDP 信令可通过 WebSocket、HTTP 等任意双向通道交换，WebRTC 不定义信令传输方式。 --- **三、WebSocket 和 WebRTC 的核心差异总结** | 对比维度 | WebSocket | WebRTC | | ------------ | ---------------------------- | ------------------------------------------------------------ | | 底层传输协议 | TCP | 媒体流基于 UDP；信令可基于 TCP (WebSocket/HTTP) | | 连接模式 | 客户端‑服务器模式 | 支持 P2P 直连；可降级 TURN 中转；AI 云端场景多为客户端‑服务器 | | 丢包处理 | TCP 强制重传，阻塞后续数据 | 不重传，丢包隐藏插值补偿，不阻塞媒体流 | | 延迟特征 | 50‑500ms，网络抖动时延迟累积 | 50‑150ms，无重传堆积 | | 媒体处理 | 无内置能力，全部业务自行实现 | 内置回声消除、降噪、增益、自适应码率 | | 连接建立 | HTTP 101 协议升级，流程简单 | 信令交换 SDP + ICE NAT 穿透，流程复杂 | | 部署依赖 | 仅服务端程序 | 需信令服务、STUN、TURN 服务器 | | 适用场景 | 文本、普通双向数据通信 | 实时音视频、低延迟 AI 语音对话 | 选型原则很清晰：文字对话用 SSE 或 WebSocket，实时语音用 WebRTC。WebRTC 的复杂度是真实存在的，信令服务器、STUN/TURN 服务器的部署和运维都需要成本，但这些复杂度换来的是无可替代的低延迟和音频质量，在 AI 语音助手这类产品里是值得付出的代价。 ## 大模型的网关框架？网关层解决了什么问题？

LLM 网关是位于业务应用和大模型 API 之间的中间代理层，和 Nginx 这类普通反向代理不一样，它专门针对大模型调用做能力增强。 **没有网关的情况下，真实 API 密钥散落在各个服务，多模型适配逻辑侵入业务代码，重试限流每个服务重复实现，同时缺少 Token 级别的配额管控，容易出现额度被耗尽，成本统计困难，安全过滤也分散在各个业务。** LLM 网关对外提供 OpenAI 兼容接口，**业务只调用网关，使用虚拟密钥，真实密钥统一托管在网关。它可以完成多模型协议转换，切换底层模型只改网关配置，业务代码不用修改。同时具备故障自动降级，按团队做 Token 配额隔离，集中统计 Token 用量做成本分摊。还可以在网关统一做 Prompt 注入、敏感信息过滤，实现集中安全防线。另外支持语义缓存，基于向量相似度命中历史结果，节约调用成本、降低延迟，但需要注意阈值调参和实时业务绕过缓存。** 生产常用开源框架有 LiteLLM、One‑API、Bifrost。普通 Nginx 只能做基础转发，无法实现上述大模型专属能力。

**一、基础概念** LLM 网关是部署在**业务应用与各类大模型后端 API 之间的中间代理层**。调用链路：业务应用 → LLM 网关 → OpenAI/Anthropic/ 国产大模型等后端服务。业务应用只对接网关，不直接对接各个模型厂商接口。普通 API 网关、Nginx 仅能完成通用转发，缺少大模型领域专属逻辑。 --- **二、没有 LLM 网关时的业务痛点** 1. **密钥安全风险**：各家厂商真实 API‑Key 散落在各个业务服务、配置文件，泄露风险高。 2. **多模型适配成本高**：不同厂商 SDK、鉴权、请求响应格式不一致，适配逻辑散落在各个业务代码。切换底层模型必须修改业务代码。 3. **重复开发容错逻辑**：重试、指数退避、超时、429 限流处理，各个服务重复实现，实现不一致，故障排查复杂。 4. **额度不可控**：缺少按业务、团队的 Token 配额限制，单个异常脚本可以耗尽全局 API 额度，造成全业务不可用。 5. **成本黑盒**：缺少统一的 Token 消耗统计，无法做业务线、团队维度成本分摊。 6. **安全防护分散**：Prompt 注入、隐私信息过滤需要每个业务单独实现，容易出现遗漏。 7. **缓存收益低**：仅支持精确字符串缓存，无法处理语义相近的请求，大量重复语义请求持续消耗模型调用。 --- **三、LLM 网关核心能力** 1. **多模型统一兼容接口** 对外提供 OpenAI 兼容标准接口，业务代码无需改动，仅修改 base_url 与网关下发的虚拟 Key。网关内部完成不同厂商协议、参数格式转换。切换底层模型、模型 A/B 测试仅修改网关配置，业务代码无感知。 2. **密钥集中管理** 真实厂商密钥统一保存在网关内部，业务侧只使用网关分配的虚拟 API‑Key，业务永远接触不到真实密钥，降低密钥泄露面。 3. **负载均衡与故障降级 / 容灾** 同一模型配置多条后端路由，主链路异常、503、限流 429 到达阈值后，网关自动故障转移到备用模型后端，业务无感知，提升整体可用性。 4. **Token 粒度限流与配额管控** 按虚拟 Key、团队、业务线设置 Token 调用上限，超配额直接返回 429，实现资源隔离，避免单业务耗尽全局额度。 5. **统一可观测与成本追踪** 网关层采集全量请求：输入输出 Token 数、延迟、错误码，支持对接 Prometheus、Langfuse 等观测组件。完成团队、业务维度成本统计与分摊，为成本优化提供数据依据。 6. **统一 Prompt 安全防线** 网关层统一执行输入输出检测：Prompt 注入防御、敏感隐私信息过滤、内容审核。安全策略集中更新，所有接入业务自动生效，避免业务漏实现。 7. **语义缓存** 区别普通 HTTP 精确匹配缓存；将用户输入生成 Embedding 向量，向量库做相似度检索。当相似度超过阈值，直接返回历史应答，跳过模型调用，降低延迟，节省调用成本。 > 工程注意点：需要调优相似度阈值；区分业务设置缓存 TTL；实时性强的业务需要绕过语义缓存，避免返回过期错误答案。 --- **四、常见网关框架对比** | 框架 | 语言 | 特点 | | ------------------ | ------ | ------------------------------------------------------------ | | LiteLLM | Python | 开源，支持上百种模型，社区活跃；需注意供应链安全，生产环境锁定版本校验哈希 | | One‑API | Go | 国内流行，国产模型适配好，部署简单 | | Bifrost | Rust | 高性能低延迟，高吞吐，新兴开源网关 | | PortKey | Python | 开源 + 商业托管，可减少自运维成本 | | Kong AI Gateway | - | 基于 Kong 扩展 AI 能力，适合已有 Kong 网关的企业 | | Nginx / Envoy 自研 | - | 高度灵活，需要自行实现全部大模型逻辑，开发维护成本高 |

Agent相关问题.

Dylan Kwok

Agent相关问题