1. 什么是agent

指一个能够自主感知环境、进行思考决策并执行动作以实现特定目标的系统或程序

2. Agent 核心运作闭环

感知 -> 规划 -> 行动 -> 再感知
三个核心
- 工具调用（Tool Use）
- 记忆机制
- 多步推理和自我纠错

3 什么是MCP

是由 Anthropic 推出的一项开源开放标准。它的作用就像 AI 世界的“通用 USB 接口”，旨在为大语言模型（LLM）提供标准化的方式来读取本地文件、连接数据库、调用外部 API 等
MCP的架构做成:

4 什么是A2A协议

A2A协议（Agent2Agent Protocol，智能体间通信协议）是首个专为不同AI智能体（Agent）之间实现无缝通信与协作而设计的开放标准协议

5 Agent架构的核心组件

LLM、工具、记忆、规划模块。

• LLM: 它是整个 Agent 的大脑, 所有的输入，不管是用户的指令、工具返回的结果还是记忆里调出来的内容，最终都要经过 LLM 来理解和决策。它负责判断：下一步该做什么？是继续思考、调用某个工具、还是已经可以给出最终答案了？
• 工具: 这是 Agent 和外部世界交互的唯一入口。 这是 Agent 和外部世界交互的唯一入口。
• 记忆系统：
  类型：
  （1）短期记忆：就是当前这轮对话的上下文，装在 context window 里
  （2）长期记忆：通常用向量数据库来实现，把重要信息 embedding 之后存起来，下次用的时候做语义检索拿回来。通常用向量数据库来实现，把重要信息 embedding 之后存起来，下次用的时候做语义检索拿回来。
  注： 这里借用认知科学对人类长期记忆的分类来理解 Agent 长期记忆的组织方式（注意这只是便于理解的类比，Agent 系统里的实现通常都是向量检索 + metadata 过滤，不一定真的分这么细）长期记忆的存储粒度可以为「一次完整交互」或「一个独立知识点」：

【1】 语义记忆（Semantic Memory）存的是事实性知识，比如「用户是做金融行业的」「某个 API 的调用频率限制是每分钟 60 次」；
【2】情景记忆（Episodic Memory）存的是具体的经历，比如「上次用户问退款问题时我们查了订单系统，发现他的订单已过退款期」；
【3】 程序性记忆（Procedural Memory），存的是「怎么做事」的经验，比如「处理退款问题的标准流程是先查订单状态再核实支付方式」
长期记忆存储策略

• 重要性评估: 只把真正有价值的信息持久化
• 记忆衰减: 做法是给每条记忆加一个时间权重，越久远的记忆权重越低，检索的时候自然就排在后面了。

（3）感知记忆：这是最短暂的一层，就是「当前这次调用的原始输入」，用户发来的这条消息、上传的截图、传入的文档。它的生命周期只有一次调用，处理完就消失，不会主动保留。

（4）实体记忆：这层比长期记忆更精炼，它不是存原文，而是把对话中出现的关键实体和事实主动提取出来，存成结构化字段。
而不是原始对话本身。类比到人的话，就像医生的病历卡，不是把问诊录音存起来，而是结构化地记录「主诉：头痛三天；诊断：偏头痛；用药：布洛芬」。信息密度高，查询快，而且不受原始表述方式影响。

• 规划模块: 规划模块的底层其实依赖的是 LLM 的推理能力
  几种主要的技术手段
  【1】 CoT（Chain of Thought，思维链）: 它的核心思想是让模型「把思考过程写出来」，而不是直接输出最终答案。你可以在 prompt 里加一句「Let's think step by step」，模型就会把推理的中间步骤一步步展开。
  【2】ToT（Tree of Thoughts，思维树）: 而是在每个推理节点上展开多个可能的分支，然后评估每个分支的质量，选出最优的路径继续往下走。
  主要流程为：「生成 -> 评估 -> 剪枝
  （1）首先是生成多个候选思路，让 LLM 针对同一个问题给出 3 个不同的初步方向，而不是只走一条路。
  （2）然后是评估每个思路的可行性，用另一个 LLM 调用（或同一个 LLM 带上评估 prompt）给每个思路打分，判断哪个最有希望。
  （3）最后是选优继续深入、剪掉差的，只保留分数高的思路，再展开下一层推理，反复循环直到得出最终答案。

【3】 GoT:（思维图 / Graph of Thoughts）：它将思考过程构建为一张“网络图”（有向图），图中存在使用相同的节点，每个节点代表执行的步骤，表示在执行推理的过程中可以利用重复的步骤。

CoT 有两种触发方式：
（1） Zero-shot CoT：直接在 prompt 末尾加上「让我们一步步思考」这句话就行了，LLM 会自己展开推理过程，不需要你提供任何示例。优势是零成本、即插即用，缺点是 LLM 的推理格式和深度完全靠它自己发挥，不太稳定，有时候会写得很详细，有时候又跳步。
（2） Few-shot CoT，在 prompt 里给几个带有完整推理过程的例子，让 LLM 照着这个格式来模仿。比如你先写一道数学题，把每一步怎么算、最后得出什么结论都写清楚，Few-shot 的效果更稳定，特别适合输出格式要求比较固定的场景，代价是需要你提前准备高质量的示例，而且示例本身也会占用 token。

两种主流模式：

• Plan-and-Execute 模式：先让 LLM 输出一个完整的步骤列表，然后按顺序逐步执行。好处是整体结构清晰，你能在执行前就看到完整计划，方便人工审核；缺点是如果中间某一步的结果和预期不一样，原来的计划可能就不合适了，需要重新调整。
  这里有一个重规划的过程：每执行完一步都会把结果反馈给规划器，规划器会判断：当前的执行结果和预期一致吗？后续的计划还适用吗？需不需要调整？如果发现某一步的结果和预期严重偏离，规划器会修改后续的步骤，甚至插入新的步骤来应对。

• ReAct 模式：每走一步就根据当前结果重新思考下一步该做什么，不提前制定完整计划。好处是灵活性极高，能根据实际情况随时调整；缺点是容易「走偏」，因为每一步都是局部最优决策，有时候会忽略整体目标。
  主要由三个步骤组成：思考-> 行动 -> 观察
  （1）Thought 阶段，LLM 先把当前的情况分析一遍，把推理过程写出来，比如「用户想查竞品信息，我应该先用搜索工具查一下竞品 A 的最新动态」
  （2）Action 阶段，LLM 根据思考的结论决定调用哪个工具、传什么参数；
  （3）Observation 阶段，工具返回的结果被反馈给 LLM，它读取这个结果，然后进入下一轮 Thought，重新分析当前局面、决定接下来怎么做。

优缺点：
（1）循环漂移：每一步都是根据当前历史重新决策的，没有一个全局计划在约束它，跑着跑着就可能偏离最初的目标。举个例子就是：当前查询公司A近三年的应收，第一步搜索公司A的数据，但是第二部看到搜索结果有公司B的信息，然后模型看到这个有意思，就去查公司B的数据，然后就越走越远，偏离目标
（2）错误传播：ReAct 的每一步决策都建立在前面所有步骤的结果之上，如果中间某一步拿到了错误的信息，或者工具返回了一个有误的结果，后面所有的推理都会被这个错误带跑

实际工作中，以上模式往往不是单独存在的，而是相互集合，比如先使用Plan-and-Execute 模式规划好任务的执行，然后在具体的步骤中，根据当前结果决定下一步做什么

适用场景：
（1）ReAct 的优势在于灵活，每一步都能根据最新情况做决策，特别适合那些任务边界不太明确、需要探索性地获取信息的场景，比如开放式的问答，信息搜索这类任务。
（2）Plan-and-Execute 的优势在于有全局视野，不容易跑偏，特别适合那些目标明确、需要多步骤协作完成的复杂任务，比如深度研究、长文写作、多工具协同的数据分析。的代价是初始规划本身就需要一次 LLM 调用，如果任务很简单（一两步就能搞定），这个规划步骤反而是多余的开销。

• Reflection（反思） 则是在前两种范式的基础上加了一层「质量保障」。做法是在 Agent 完成一步或者完成整个任务之后，再让一个 LLM（可以是同一个模型也可以是专门的评估模型）来判断做得好不好、结果是否符合预期。如果评估不通过，就重试或者换一种策略。
  Reflection 有一个非常值得关注的变体叫 Reflexion。它和基础 Reflection 的区别在于，Reflexion 不只是简单地说「这个结果不好，重做一遍」。而是会生成一段具体的「反思总结」，记录下这次失败的原因和改进建议，然后把这段总结作为额外的上下文传给下一次尝试。

6. workflow，agent，tool三者有什么区别

• Tools 是最小的能力单元，就是封装好的可调用函数，比如搜索、执行代码、发邮件，它只负责「执行」，本身没有任何决策能力。

• Agent 是一个完整的决策系统，内部用 LLM 做大脑，自己判断什么时候调哪个 Tool、要不要继续、什么时候结束，是主动的。一个成熟的 Agent 系统必须有明确的停止机制，不能让它无限跑下去。
  常见的停止条件有这几种：
  （1） LLM 主动判断任务完成，
  （2）设置最大循环次数。
  （3）设置总 token 预算上限。
  （4）超时机制，例如：整个 Agent 运行时间超过比如 60 秒就终止

• Workflow 是更上层的编排框架，把 Agent、LLM、Tools 组织成一条确定性流程，每个节点做什么、按什么顺序流转都是开发者事先写死的。

主要做的事是：把整个执行流程的「骨架」写在代码里，LLM、Agent、Tools 都只是这个流程里的「节点」，每个节点负责完成自己那一步，但整体走哪条路、下一步去哪里，全由开发者的代码决定，不是任何节点自己说了算。

三者最核心的\区别就一句话：Tools 不做决策只执行，Agent 自己做决策，Workflow 是开发者替所有节点把决策提前写好。

注: 好的工具设计原则
（1）职责单一：一个工具只做一件事
（2）描述要精确：这一点的重要性怎么强调都不过分，模型完全靠你写的 description 来理解这个工具能做什么。描述写成 查询数据 和 查询公司内部销售数据库，支持按日期和产品类别筛选，返回销售额和订单数 是不同的，后者模型就能精确判断什么场景该用它
（3）错误信息要清晰：工具执行失败的时候，返回给 LLM 的错误信息必须是它能「看懂」的，比如「参数 city 不能为空」就比「Error code 400」好得多。
（4）参数设计要简洁：能少传的参数就不传，能有默认值的就给默认值，因为 LLM 填的参数越多，出错的概率就越大

7. 什么是 Agentic Workflow

用 Workflow 固定主流程的骨架，在需要灵活判断的节点嵌入 Agent，其余固定节点直接用 LLM 或 Tools。 骨架是确定的，让你能控制整体行为、便于调试；关键节点是灵活的，让你能应对各种复杂情况。两个优点都有，两个缺点都被削弱了。

几种常见的 Workflow 编排模式：
（1）「Prompt Chaining」（提示链），就是把一个大任务拆成多个小步骤，前一步的输出作为后一步的输入，像流水线一样串起来。
（2）「Routing」（路由），先用一个 LLM 做分类判断，然后根据分类结果把请求分发到不同的处理分支，前面客服系统的例子就是典型的路由模式。
（3）「Parallelization」（并行化），把可以同时进行的子任务并行执行，最后汇总结果，这在需要多维度分析的场景下特别有用，比如同时从多个数据源检索信息。
（4）「Orchestrator-Workers」（编排者-工人），一个中央编排者负责分配任务，多个 Worker 各自完成子任务，适合任务可以分解但子任务之间相互独立的场景。
（5）「Evaluator-Optimizer」（评估者-优化者）, 一个 LLM 负责生成输出，另一个 LLM（或者同一个模型换一个角色）负责评估这个输出的质量，如果评估不通过就把反馈给回生成者，让它改进后重新输出，如此循环直到评估通过或者达到最大重试次数。适合对输出质量要求很高的场景，比如生成营销文案、撰写法律条款、编写代码等等。

8. Agent的设计范式怎么选

• ReAct: 任务复杂度和质量要求。如果任务步骤不多、每步都比较独立.
• Plan-and-Execute: 如果任务很复杂、步骤之间有依赖关系需要全局统筹
• 如果对输出质量要求特别高、允许多花一些时间和成本，就在前面的基础上叠加 Reflection。
  注：项目里这三种范式也不是互斥的，很多系统会混合使用，比如用 Plan-and-Execute 做整体规划，每个步骤内部用 ReAct 来执行，关键步骤再加上 Reflection 做质量把关

9. 复杂任务怎么拆分

• 静态拆分：是你提前把任务流程设计好，固定成一个确定的 Workflow，每一步是什么、按什么顺序执行，全部事先写死。
  优缺点：
  优点：行为可预测，容易排查
  缺点：灵活性低，遇到没设计的流程容易出问题

• 动态拆分：是把「任务拆解」这件事本身也交给 LLM 来做。你给它一个目标，让它先输出一个执行计划，再按计划一步步执行，

• 自适应拆分：在做的过程中，先不要拆分，如果当前步骤完成难度较大，或者超过最大步数，将其交给规划器，对任务重新进行拆分

拆分步骤的标准是原子操作：这个步骤只做一件独立的事，边界清晰，做完有明确的输出，和其他步骤不互相依赖。

一个好的拆分结果应该满足三个条件：
（1）完备性：也就是所有步骤加在一起，能不能覆盖原始任务的全部要求，有没有遗漏。
（2）独立性：也就是每个步骤的职责边界是不是清晰，有没有两个步骤在做同一件事，或者某个步骤的输出和另一个步骤的输出有重叠。
（3）可验证性：每个步骤执行完之后，能不能用一个简单的标准判断它做对了没有。比如你拆了一个步骤叫「搜索竞品 A 的定价信息」，如果没有完成标准，执行完之后你只能人工看一眼判断做得好不好。但如果你在拆分时就定义了「输出中必须包含价格数字和计费模式（按量/包月/免费增值）」，执行完之后自动检查输出是否包含这两个要素就行了，缺了就自动触发重试。

10. 实现记忆模块的核心问题

（1）存什么
这条信息，下次任务开始时如果知道，会让 Agent 做得更好吗？
通常值得存的有三类：用户偏好和习惯（语言风格、技术栈偏好、工作习惯）、任务执行中产生的关键结论和决策（比如「调研发现竞品 A 的定价策略是按用量收费」）、以及外部知识（产品文档、FAQ、历史案例）。
不值得存的：中间推理过程、工具返回的原始数据（日志太啰嗦）、闲聊内容。这些存进去只会稀释有价值的记忆，让检索的信噪比下降。
（2）怎么存
需要语义检索的内容，比如文档知识、对话摘要这类非结构化的文本，适合存进向量数据库，用 embedding 编码后通过相似度检索。结构化的用户偏好和状态字段，
而语言偏好、项目配置这些可以精确查询的内容，更适合用关系数据库或 Key-Value 存储，查询速度快，

（3）什么时候取出来用？

• 主动检索：在任务开始前，用当前任务的描述去检索相关记忆，把结果注入 system prompt 作为背景知识。这样 Agent 一开始就带着「历史记忆」进入任务，不需要用户每次重新交代背景。
• 被动触发：Agent 在推理过程中，判断当前步骤需要某类特定知识时，主动发起检索。具体做法是把「查记忆」封装成一个 Tool，让 Agent 自己决定什么时候调。这种方式更灵活，但依赖模型判断什么时候该去查。

11：短期记忆不够大怎么办

（1）滑动窗口：只保留最近的N轮对话
（2）摘要压缩：，用 LLM 把早期的对话历史压缩成一段摘要，替换掉原始的冗长历史。
（3）不常用但重要的信息「卸载」到长期记忆里：执行过程中产生的中间结果，如果当前步骤不需要但后面可能用到，就先存到向量数据库里，从 context window 中移除，等后面某步需要时再检索回来。

专门为 Agent 记忆设计的开源框架：

• Mem0 ：它的核心思路是把记忆管理做成一个独立的服务层。你只需要调用 memory.add() 存记忆、memory.search() 查记忆，底层的 embedding、去重、冲突消解它全帮你做了。
• Letta：它的设计灵感来自操作系统的内存管理。就像操作系统把内存分成多个层级（寄存器、缓存、主存、磁盘），Letta 也把 Agent 的记忆分成了三个层级。
  【1】Core Memory：始终留在 context window 里的核心信息（比如用户画像、当前任务目标），类似于操作系统的主存，随时可读可写；
  【2】Recall Memory ：是最近的对话历史，类似于缓存，按时间顺序存储，支持快速回溯；
  【3】Archival Memory ： 是长期归档的知识，类似于磁盘，容量无限但检索需要主动发起。

记忆整合：就是定期对长期记忆做「清理和升华」的过程，它包含几个关键环节：
【1】第一个环节是去重：把语义相近的多条记忆合并成一条更完整的版本。比如你存了「用户喜欢简洁的代码」「用户说过代码要精简」「用户要求不要冗余代码」三条，其实表达的是同一个意思，合并成一条「用户偏好简洁精练的代码风格，反对冗余」就够了。
【2】第二个环节是冲突消解：两条记忆互相矛盾时（比如「用户偏好 Python」和后来说的「最近转用 Go 了」），保留时间更新的那条，标记旧的为过期。这里时间戳就非常关键了，没有时间戳就无法判断哪条是最新的。
【3】第三个环节也是最有价值的一个，叫做「抽象提炼」，本质上就是把情节记忆转化为语义记忆的过程。类似于将多个情节记忆整合成一次固定的只是，例如：比如第一次「用户让我写爬虫，requests 被反爬拦住了，换成 Selenium 才行」，第二次「用户让我抓某个电商网站的价格，页面是 JavaScript 渲染的，requests 拿到的是空页面，最后用 Playwright 解决了」，第三次「用户让我采集论坛帖子，同样遇到动态加载的问题」。
将这3个情节记忆整理后总结成一条规律：当目标网站有动态渲染时，基于 HTTP 的简单请求库（如 requests）往往拿不到完整内容，需要用浏览器自动化工具（Selenium/Playwright）来处理。这条从多次经历中「蒸馏」出来的规律，就是语义记忆。它比任何一条情节记忆都更通用、更浓缩、更容易在未来的新任务中被检索命中。这个转化过程可以用 LLM 来自动完成

把四层记忆和三个核心问题放在一起，来走一遍一次完整任务里它们是怎么协作的。整个过程可以用「读 -> 用 -> 写」三个阶段来描述。
【1】任务开始前，先「读」记忆：
用户发来一个新请求，Agent 不是立刻开始干活，而是先去「翻档案」，从实体记忆里取出用户的结构化偏好（语言偏好、风格要求、过往决策），再用任务描述作为查询词，去长期记忆里做一次语义检索，拿回最相关的历史背景。把这两部分信息拼进 system prompt 的开头。Agent 进入任务时就已经带着完整的「用户画像」，不需要用户重复交代背景。
【2】任务执行中，持续「用」记忆
任务执行过程中，用户的输入，工具的条用，模型的输出都放进短期记忆力，必要时涉及到相关的章节，使用长期记忆检索历史的相关决策
【3】任务结束后，主动「写」记忆
把本次任务产生的新知识写回持久化存储，把任务过程中，产生新的用户偏好，就更新实体记忆的对应字段；如果任务产生了有价值的结论（「竞品 A 的定价是按用量收费」），就把这条摘要写入长期记忆，embedding 后存入向量数据库，供下次检索。最后，短期记忆（messages 列表）清空，工作台恢复干净，等待下一个任务。

12 为什么用muti-agent

（1） context 窗口大小, 复杂信息一撑就爆
（2）专业度不强，一个能做各方面的事情的人，往往各个方面都不如对应领域的人的专业度强

agent间协作方式：

• 顺序流水线
• 并行扇出
• 辩论/评审模式：多个 Agent 对同一个问题各自给出方案，然后由一个裁判 Agent 或者它们互相评审来筛选最优解，这种模式在需要高质量决策的场景特别有用，比如代码评审、方案选型。

single-agent和muti-agent的选型标准
（1）context 要撑爆了、
（2）需要不同专业分工、
（3）有子任务可以并行
不属于这三类就用 Single-Agent

agent间消息传递方式
（1）Agent 完成自己的工作后把结果发送到一个消息队列，下游的 Agent 订阅自己感兴趣的消息，取到了再开始处理
（2）共享状态: 共享状态一般分为两种全局状态和局部状态
【1】全局状态存放所有 Agent 都需要读取的信息，比如用户的原始请求、当前任务进展、最终输出，这些是共享的
【2】局部状态存放每个 Agent 自己的中间结果，比如搜索 Agent 找到的候选文档列表、代码 Agent 生成的草稿代码，这些在 Agent 内部使用，不会直接暴露给其他 Agent，避免信息污染。
两种方式怎么选：
如果各 Agent 之间的依赖关系比较强，前一步的结果要直接传给后一步，用共享状态更直接。如果你希望 Agent 之间尽量解耦，互相不知道对方的存在，用消息传递更合适。

路由方式：
（1）静态路由
（2）动态路由
（3）handoff:不需要一个中央的 Orchestrator 来决定「下一步找谁」，而是让当前正在执行的 Agent 自己决定「我做完了，接下来应该把任务交给谁」

12 Agent 记忆压缩通常有哪些方法

• 摘要压缩、

• 滑动窗口

• 重要性过滤：按内容的实际价值来决定去留：给每条对话记录打一个重要性分数，低于阈值的淘汰，高分的保留。
  两种打分方式：
  （1）一种是规则打分：包含「决定」「确认」「需求」等关键词的记录加分，被后续对话引用次数多的加分，纯闲聊降分。规则快、没有额外开销，但比较粗糙，边界情况容易判断失误。
  （2）另一种是让 LLM 来打分：逐条判断每条记录的重要程度。准确率更高，但每条记录都需要一次 LLM 调用，开销大，通常在批量清理历史时做，而不是实时处理每条消息。
  （3）观察遮蔽：它的做法不是删除低分内容，而是在构造 prompt 时选择性地「隐藏」某些历史条目。
  比如当前任务是写代码，Agent 会把之前关于需求讨论的对话标记为「与当前步骤无关」，构造 prompt 时直接跳过这些条目，只把和代码相关的历史传进去。任务进入测试阶段时，再把测试相关的历史「显示」出来，代码实现的细节对话则被遮蔽。

• 结构化抽取：很多场景里，真正有价值的不是对话文字，而是对话中传递的事实和状态。比如「用户偏好用 Python」「预算上限是 5 万」「已确认方案 B」「需要兼容移动端」。把这些信息主动提取出来，存成结构化字段，后续注入 prompt 时直接用这些字段，比传一大段对话文本要高效得多，信息密度也高得多。

13 反思机制

两个粒度：

• 步骤级
• 任务级