Agent 面经

Agent 是以 LLM 为「大脑」，能够自主感知、规划、调用工具并根据反馈迭代，直到完成目标的系统。核心区别在于控制流由谁决定：

• 普通 LLM 调用：一问一答，无状态、无行动能力。
• 固定工作流 (Workflow)：路径由人预先编排，LLM 只在固定节点被调用，流程是确定的。
• Agent：下一步做什么由模型在运行时动态决定，具备「观察 → 思考 → 行动」的循环，能使用工具、访问记忆、自我纠错。

一句话：Workflow 是「写死的路」，Agent 是「自己找路」。工程上二者常混合——用 Workflow 保证可靠性，在需要灵活性的环节引入 Agent。

ReAct = Reasoning + Acting，让模型在「推理(Thought)」和「行动(Action)」之间交错进行：Thought 决定下一步意图，Action 调用工具，Observation 拿到工具返回，再进入下一轮 Thought，直到给出 Final Answer。

它解决的问题：

• 纯 CoT 只在脑内推理，容易凭空捏造事实；ReAct 通过工具（检索、计算等）把外部世界的真实反馈引入推理链，缓解幻觉。
• 让推理过程可观测、可干预，每一步的 Thought/Action 都能被日志记录和调试。

局限：Thought 冗长、token 消耗大；错误会沿着链条传播。实践中常配合 reflection、限制最大步数、结构化输出来约束。

• 任务分解 (Decomposition / CoT)：把大目标拆成子任务，逐步求解。
• Plan-and-Execute：先一次性生成完整计划，再逐步执行，执行中可重规划 (replan)。减少反复调用大模型。
• ReWOO：把推理与观测解耦，先规划出带占位符的计划，再统一执行工具、最后汇总，显著降低 token。
• Tree of Thoughts (ToT)：把推理组织成树，允许分支探索与回溯，适合搜索型问题。
• LLM Compiler / 并行调度：识别无依赖的子任务并行执行，降低延迟。

选型看任务特征：步骤多且相对确定 → Plan-and-Execute/ReWOO；需要探索多种可能 → ToT；强调低延迟 → 并行编排。

Reflection 指 Agent 在产出结果后，对自己的输出/轨迹进行批判性评估，发现问题并改进，形成「生成 → 评价 → 修正」的闭环。

常见落地方式：

• Self-Refine：同一模型自我打分并给出修改建议，迭代重写。
• Reflexion：把失败经验以语言形式写入记忆，下一轮尝试时作为提示，避免重蹈覆辙。
• 外部信号驱动：用单元测试、编译器、检索校验等客观反馈触发反思，比模型自评更可靠。

注意：反思会增加成本和延迟，且模型可能「越改越错」，应设置停止条件并优先使用可验证的外部信号。

两者的根本差异在于**「边想边做」还是「先想好再做」**：

• ReAct（反应式）：每一步都重新推理下一步动作，走一步看一步。灵活、能随时根据观测调整，但每步都调用大模型、token 和延迟高，长任务里容易走偏或陷入循环。
• Plan-and-Execute（先规划后执行）：先一次性生成完整计划，再按计划逐步执行，必要时 replan。规划与执行分离，调用大模型次数少、成本低、全局性更强，但对「计划赶不上变化」的动态环境适应差。

怎么选：

• 任务步骤少、强依赖中间结果、环境多变 → ReAct。
• 任务步骤多、可提前拆解、追求成本可控和稳定性 → Plan-and-Execute。
• 实践中常混合：用 Plan 定骨架，子步骤内用 ReAct 处理局部不确定性。

Context Engineering 指系统性地管理「进入模型上下文窗口的全部信息」——不只是一句提示词，还包括系统指令、工具定义、检索到的知识、历史记忆、中间结果等，目标是在有限的上下文里放进「恰到好处」的信息，让 Agent 在多轮、长程任务中稳定工作。

和 Prompt Engineering 的关系：Prompt Engineering 是 Context Engineering 的子集。

• Prompt Engineering：关注怎么写好「那一行指令」，是单次、静态的。
• Context Engineering：关注在 Agent 循环中，每一步动态地决定「上下文里该有什么、该丢什么、以什么结构组织」，是系统化、动态的工程问题。

为什么重要：Agent 会跨越数百轮推理、反复调用工具，光靠写好一个 prompt 远远不够；上下文的组织、压缩、隔离直接决定了 Agent 的可靠性与成本。（Anthropic 于 2025 年系统阐述了这一范式。）

「用 Workflow 约束 Agent」是近两年工程界的主流趋势：在人为定义好的流程框架内，只在需要灵活性的局部节点给 Agent 自主决策权，而不是让它从头到尾自由发挥。

为什么这么做：

• 全自主 Agent 灵活但不可控、不可预测、难调试、成本高，在生产环境风险大。
• 纯 Workflow 稳定可控，但不够灵活，覆盖不了长尾情况。

平衡思路：

• 用 Workflow / 状态机定「骨架」和关键路径，保证可靠性与可观测性。
• 在某些节点（如「理解用户意图」「决定用哪个工具」）交给 Agent 局部决策。
• 关键动作加护栏：权限最小化、人工确认 (HITL)、输出校验、最大步数限制。

一句话：把「确定性交给工程，不确定性交给模型」，自主性服从于可控性。

• 短期记忆 / 工作记忆：当前会话的上下文窗口，包含近期对话、中间结果。受 token 限制。
• 长期记忆：跨会话持久化，通常存在向量库或数据库中，按需检索。可再细分：
  • 情景记忆 (Episodic)：具体发生过的交互/事件。
  • 语义记忆 (Semantic)：抽象的事实、知识、用户偏好。
  • 程序性记忆 (Procedural)：技能、流程、系统提示与工具用法。

工程实现上，短期记忆靠上下文管理，长期记忆靠「写入策略 + 检索策略」的记忆模块。

目标是在有限 token 内保留最相关信息。常用手段（可组合）：

• 摘要压缩：把较早的对话滚动摘要成简短记录，只保留结论与关键事实。
• 滑动窗口 / 截断：只保留最近 N 轮，配合固定的系统提示与任务状态。
• 检索式记忆：历史存入向量库，每轮只召回与当前问题最相关的片段。
• 结构化状态：用 scratchpad / 待办清单 / 变量表把状态外置，而不是全塞进对话。
• 分层记忆：短期原文 + 长期摘要 + 外部知识分级管理。

权衡：压缩会丢信息，检索可能漏召回。关键状态（目标、约束、已完成步骤）应始终保留在上下文中。

写什么、何时写：不是所有对话都值得记。可用 LLM 抽取「值得长期保存的事实/偏好/结论」，或在任务结束时做一次记忆固化 (consolidation)。

怎么存：向量检索适合语义模糊查询；结构化字段（用户ID、时间、类型）适合精确过滤；二者常结合做混合检索。

怎么取：基于当前 query 做相似度召回 + 元数据过滤 + 时间衰减/重要性加权，再 rerank，控制注入条数避免污染上下文。

更新与冲突：新事实可能与旧记忆矛盾，需要去重、覆盖或标注时效；长期还需「遗忘」机制淘汰过期低价值记忆。可参考 MemGPT、Generative Agents 的记忆流 + 重要性/相关性/新近度打分。

上下文污染指上下文里混入了错误、过时、无关或误导性的信息，随着对话/任务变长不断累积，逐步干扰模型判断，导致答非所问、幻觉加剧甚至滚雪球式出错（也叫 context rot）。

常见来源：早期的错误结论没被清理、检索召回了不相关内容、工具返回的冗余噪声、多轮对话里的自我强化偏见。

防治手段：

• 精简与筛选：只放当前步骤真正需要的信息，检索结果先 rerank / 过滤再入上下文。
• 隔离：把不可信数据（用户输入、网页内容）与系统指令、可信事实分区标注，避免相互污染。
• 定期清理 / 压缩：滚动摘要时剔除已被推翻的结论，而不是无脑累加。
• 结构化状态外置：用独立的状态表 / 待办清单管理关键信息，减少对话原文堆积。
• 纠错机制：发现错误结论后显式标注失效，防止后续步骤继续引用。

本质是让模型输出结构化的工具调用意图，由外部程序真正执行，再把结果喂回模型。流程：

• 把可用工具的名称、描述、参数 JSON Schema 一起放进请求。
• 模型根据用户意图，输出「调用哪个工具 + 参数」（结构化 JSON），而不是自然语言。
• 运行时解析并实际执行该函数（模型本身不执行代码）。
• 把执行结果作为新的消息回传，模型据此继续推理或给出最终回答。

关键点：工具描述写得清楚、参数 schema 约束严格，模型选对工具、填对参数的概率就高。多数能力来自训练阶段对工具调用格式的对齐。

保证参数正确：

• 用 JSON Schema / Pydantic 做强类型约束，并开启结构化输出 (structured output / JSON mode)。
• 服务端二次校验参数（范围、枚举、必填），非法则拒绝并返回明确错误。
• 工具描述里给出示例和边界说明，减少模型「猜参数」。

处理失败：

• 把错误信息结构化回传给模型，让它据此修正参数重试（有限次数）。
• 设置超时、重试上限、熔断，避免无限循环。
• 提供兜底策略：降级到其他工具、请求人工介入 (HITL) 或返回可解释的失败结论。

MCP 是一套开放的标准协议，用于统一「模型/Agent」与「外部工具、数据源、上下文」之间的连接方式，可以类比为「AI 应用的 USB-C 接口」。

它解决的问题：过去每接一个工具/数据源都要写一套私有适配，N 个模型 × M 个工具会变成 N×M 的集成成本。MCP 定义统一的 Server（暴露 tools / resources / prompts）与 Client 通信规范，让工具「即插即用」，把复杂度降到 N+M。

好处：工具可复用、生态可共享、权限与传输标准化，Agent 接入新能力的成本大幅下降。

工具太多会撑爆上下文、干扰模型选择、拉低准确率。核心思路是不要把所有工具一次性都塞给模型，而是「先缩小候选，再精确选择」：

• 工具检索 (Tool RAG)：把工具描述向量化，根据当前任务只召回 Top-K 个相关工具放进上下文，而非全量。
• 分层 / 分组路由：先让模型选「工具类别 / 子 Agent」，再在类别内选具体工具（二级路由），降低单次决策空间。
• 按角色拆分：不同子 Agent 各自只持有自己领域的一小组工具。
• 清晰的描述与命名：名称、描述、参数说明写好，减少混淆；相似工具合并或明确区分边界。
• 兜底与校验：选错工具时能根据错误反馈重选；对高危工具加白名单 / 确认。

A2A（Agent2Agent）是 Google 于 2025 年推出的开放协议，用于「Agent 与 Agent 之间」的通信协作：让不同厂商、不同框架构建的 Agent 能互相发现能力、分配任务、交换结果，实现跨系统的多智能体协作。

和 MCP 的区别在于连接的对象不同：

• MCP（Model Context Protocol，Anthropic）：解决 Agent ↔ 工具 / 数据源 的连接，把外部能力标准化地接入单个 Agent。
• A2A（Google）：解决 Agent ↔ Agent 的连接，让多个自治 Agent 之间协作。

两者是互补而非竞争：一个 Agent 用 MCP 调用工具获取能力，同时用 A2A 与其他 Agent 协作完成更大任务。常见类比：MCP 是「给 Agent 接上工具」，A2A 是「让 Agent 们组队」。

RAG = Retrieval-Augmented Generation，用检索到的外部知识增强生成。分离线与在线两阶段：

• 离线索引：文档清洗 → 切块 (chunking) → 向量化 (embedding) → 存入向量库/索引。
• 在线问答：用户 query → 向量化 → 检索 Top-K 相关块 →（可选 rerank）→ 拼进提示词 → LLM 基于上下文生成答案 →（可选）附引用出处。

价值：无需重新训练即可注入私有/实时知识，降低幻觉、可溯源。

按流程各环节排查、逐点优化：

• 切块：语义/结构化切块、控制块大小与重叠、保留标题层级；父子块 (small-to-big) 检索。
• 检索：向量 + 关键词 (BM25) 的混合检索；多路召回后融合 (RRF)。
• 查询改写：query rewrite、拆分多子问题、HyDE（先让 LLM 生成假设答案再检索）。
• 重排：用 cross-encoder / rerank 模型对候选精排，取更相关的少量块。
• 后处理：上下文压缩、去冗余、按需迭代检索 (agentic RAG)。
• 评估驱动：用检索命中率、上下文相关性、答案忠实度等指标定位瓶颈，别盲目调。

• RAG：适合知识频繁更新、需要溯源、知识量大的场景；改知识不改模型，成本低、可解释。
• 微调 (Fine-tune)：适合改变模型的风格、格式、领域能力或行为模式，而非灌输大量事实；知识更新需重训。
• 长上下文：适合一次性、上下文规模可控的任务；但 token 成本高、可能「中间信息丢失 (lost in the middle)」，不适合海量知识库。

实务上常组合：微调塑造能力/格式 + RAG 提供实时知识 + 长上下文承载当次任务材料。先问「问题是知识缺失还是能力缺失」，再选方案。

Agentic RAG 是把 Agent 的自主决策能力引入检索流程：不再是「检索一次 → 生成」的固定管道，而是让 Agent 主动决定要不要检索、检索什么、检索几次、用哪个数据源，并根据结果迭代。

与传统 RAG 的区别：

• 传统 RAG：流程固定，一次 query → 一次检索 → 拼接生成，简单但对复杂问题力不从心。
• Agentic RAG：
  • 会查询改写 / 拆分成多个子问题分别检索。
  • 能多轮迭代检索：结果不够就再查、换关键词、换数据源。
  • 能路由到不同知识库 / 工具（向量库、SQL、API、网页）。
  • 会评估检索质量，不满意就重试或换策略。

代价：更灵活、更适合复杂多跳问题，但延迟、成本、编排复杂度都更高。

多智能体优势：职责分离、专精化（各 Agent 用不同提示/工具/模型）、可并行、单个上下文更短更聚焦、易于扩展。

代价：编排复杂、通信开销与延迟增加、错误跨 Agent 传播、整体成本更高、调试更难。

选择建议：任务简单或强顺序依赖 → 单 Agent 更稳更省；任务可清晰拆成相对独立的子任务、需要不同专长或并行 → 多 Agent。原则是「能用单 Agent 解决就别上多 Agent」，先把单体做扎实再拆。

• Supervisor / 层级式：一个主管 Agent 负责路由与分派，子 Agent 各司其职，结果汇总回主管。最常用。
• Pipeline / 顺序：Agent 按流水线依次处理，前一个的输出是后一个的输入。
• Network / 去中心化：Agent 之间可自由通信协作，灵活但难控。
• Debate / 辩论投票：多个 Agent 独立作答并互相批评/投票，提升答案质量。
• Group Chat：多个角色在共享对话中协作（如 AutoGen 风格）。

选型看任务的依赖结构与可控性要求，层级式在工程上最好治理。

常见几种方式：

• 消息传递：Agent 间显式发消息（含结果/请求），适合松耦合与去中心化协作。
• 共享状态 / 黑板 (Blackboard)：所有 Agent 读写同一份全局状态（如 LangGraph 的 state），一致性好、便于追踪。
• Handoff / 移交：把控制权连同上下文交给另一个 Agent，如客服转接。

要点：控制上下文传递量（只传必要信息，避免上下文爆炸）、定义清晰的消息 schema、处理并发写入的一致性，以及防止「echo/循环对话」不收敛。

角色分工：按「职责单一」原则拆分，每个 Agent 有明确的目标、可用工具和输入输出边界（如规划者 / 检索者 / 编码者 / 审查者）。拆分粒度要适中——太粗失去专精优势，太细则通信开销和出错点激增。

冲突仲裁（多个 Agent 给出不一致结论时）：

• 主管裁决 (Supervisor)：由一个协调 Agent 汇总各方结果并做最终决定，最常用、最可控。
• 投票 / 多数表决：多个 Agent 独立作答，取多数或加权结果。
• 辩论 (Debate)：让 Agent 互相质疑、给出理由，再收敛到更优答案。
• 置信度 / 优先级：按各 Agent 的置信度或预设优先级选择。
• 规则兜底：仲裁不了时回退到确定性规则或人工介入。

关键还要防止「循环对话不收敛」：设最大轮数、明确终止条件、共享统一状态避免各说各话。

要同时看「结果」和「过程」：

• 端到端 (结果)：任务成功率、答案正确性/忠实度、格式合规率。
• 轨迹 (过程)：工具选择是否正确、步数/冗余、是否走了合理路径、是否命中该用的工具。
• 分步评估：对单个节点（检索、单次工具调用、单步推理）打分，便于定位问题。
• 评判方法：可自动校验的用规则/单测；开放式的用 LLM-as-Judge（需校准、防偏差），关键场景配人工标注。
• 离线 + 在线：离线用固定评测集回归；在线看真实成功率、用户反馈、成本、延迟。

基础设施：建评测集、做 tracing、支持轨迹回放，才能持续迭代。

• 接地 (Grounding)：用 RAG/工具提供事实依据，要求答案基于给定材料并附引用。
• 约束输出：允许模型说「不知道」，对无依据内容拒答；降低发挥空间（温度、结构化输出）。
• 验证环节：用第二个模型/规则校验事实一致性，或让工具（计算、查库、单测）做客观核对。
• 提示工程：清晰指令、示例、引用格式；减少诱导性/歧义提问。
• 反思与自检：生成后自查是否有无依据断言。

幻觉无法彻底消除，目标是把它降到业务可接受并可被发现。

Prompt Injection 指外部内容（用户输入、被检索的网页/文档）中夹带恶意指令，诱导 Agent 偏离原目标或泄露信息。防护要分层：

• 数据与指令隔离：明确区分「系统指令」与「不可信数据」，用分隔/标注告诉模型数据区内容不是指令。
• 最小权限：工具按需授权、敏感操作加确认，即使被注入也难造成实质破坏（纵深防御）。
• 输入/输出过滤：对可疑指令、敏感信息做检测与脱敏；对工具参数做白名单/校验。
• Human-in-the-loop：高风险动作（付款、删除、发外部消息）需人工确认。
• 沙箱化：代码执行、文件/网络访问放进受限沙箱。

核心思想：不要假设模型永远听话，用系统级的权限与边界来兜底。

• 硬约束：设置最大步数/最大 token/超时，超过即终止并返回当前最优结果。
• 循环检测：记录近几步的 (动作+参数)，出现重复则打断、提示模型换策略。
• 状态可见：把「已做过什么、已知结论」显式写进上下文，避免模型忘记而重复。
• 更清晰的反馈：工具失败时给出可操作的错误信息，而不是模糊报错，帮助模型跳出。
• 兜底：多次失败后升级为人工介入或返回可解释的失败。

Demo 能跑通不代表能上线，落地的核心难点在于可靠性与可控性：

• 稳定性 / 长尾：Demo 只覆盖顺利路径，真实场景充满边界情况，成功率从「看起来能用」到「稳定可用」差距巨大；错误还会跨步骤累积放大。
• 评估难：Agent 非确定、多步，缺乏好的评测集和自动化评估就无法量化改进、无法回归。
• 成本与延迟：多轮推理 + 多次工具调用，token 成本和响应时间在规模化后成为硬约束。
• 幻觉与安全：生产环境对错误容忍度低，需要 grounding、权限控制、Prompt Injection 防护、HITL。
• 可观测性与运维：没有 tracing、日志、回放，线上出问题无法定位。
• 状态与并发：多用户隔离、状态持久化、幂等、故障恢复等工程问题。

一句话：Demo 拼的是「能力上限」，生产拼的是「稳定下限 + 可控成本 + 可观测」。

• 缓存：Prompt/KV 缓存复用固定前缀；对相同请求做结果缓存（语义缓存）。
• 模型路由：简单任务用小模型/便宜模型，难任务再升级到大模型 (model cascade)。
• 减少轮次：用 Plan-and-Execute/ReWOO 降低反复调用；一次多工具并行调用。
• 并行化：无依赖的子任务/检索并发执行。
• 控制上下文：精简提示、压缩历史，token 越少越快越省。
• 流式输出：先返回部分结果改善体感延迟。

先用 tracing 找到耗时/费钱的瓶颈环节，再针对性优化，别过早优化。

Agent 是非确定性、多步的，可观测性是运维前提：

• Tracing：记录每一步的输入/输出、工具调用、耗时、token，串成一次完整调用链。
• 指标：成功率、延迟 (P50/P95)、成本、工具错误率、人工介入率。
• 日志与回放：保存完整轨迹以便复现问题、回归测试。
• 评估在线化：对线上样本抽样跑自动/人工评估，监控质量漂移。
• 告警：异常成本、循环、失败率飙升触发报警。

常用工具如 LangSmith、Langfuse、OpenTelemetry 等。

• 状态持久化：把执行状态 checkpoint 到存储（DB/KV），支持长任务断点续跑、崩溃恢复，也便于 HITL 暂停/恢复。
• 幂等：工具调用尽量幂等或带幂等键，避免重试导致重复下单/重复写入等副作用。
• 并发：多用户/多任务隔离会话与记忆；对共享资源加锁或用乐观并发控制。
• 副作用管理：区分只读与有副作用的操作，对不可逆操作加确认与审计。
• 恢复策略：失败可重放 (replay) 到断点，而非从头再来。