跳转至

1 Agent 面试

Q1：请简述Agent的基本架构组成，并解释其与传统LLM Chain的区别

回答要点：Agent = LLM +规划（Planning）+记忆（Memory）+工具使 (Tool Use).

区别：

  • Chain是预定义的、线性的硬编码工作流。
  • Agent具备”自主性”，它根据目标自发决定执行路径，通过推理循环（ReasoningLoop）不断调整策略。

AI Agent（人工智能智能体）被认为是大模型走向通用人工智能（AGI）的核心形态。它的基本架构通常遵循 Lil'Log（OpenAI 研究员 Lilian Weng）提出的经典公式：Agent = LLM + 规划 + 记忆 + 工具使用。

以下是 Agent 的基本架构组成及其与传统 LLM Chain（大模型链）的区别：

一、 Agent 的基本架构组成

  1. 大脑（Brain - LLM）：

    • 这是 Agent 的核心，通常由强大的大语言模型（如 GPT-4, Claude 3.5）担任。它负责推理、理解意图、做出决策。

  2. 规划（Planning）：

    • 任务拆解： Agent 会将复杂的目标分解为可操作的小步骤（如 Chain of Thought 或 Tree of Thoughts）。
    • 反思与修正： Agent 能够对过去的行为进行自我批评和审视，如果发现路径不对，会调整策略（如 ReAct 模式）。

  3. 记忆（Memory）：

    • 短期记忆： 利用上下文（Context Window）记录当前的对话历史和推理过程。
    • 长期记忆： 通常结合外部矢量数据库（RAG），存储历史经验、专业知识或用户偏好，以便在长周期任务中提取。

  4. 工具使用/动作（Action/Tool Use）：

    • 这是 Agent “手脚”的体现。它通过调用外部 API（搜索网页、执行代码、操作数据库等）来获取模型训练数据之外的信息或改变物理/数字世界。

二、 Agent 与 传统 LLM Chain 的区别

传统 LLM Chain（如 LangChain 中的基本 Chain）和 Agent 的本质区别在于控制流的决定权。

维度 LLM Chain (传统链式) AI Agent (智能体)
执行逻辑 硬编码 (Hard-coded)。由开发者预先定义好步骤：A -> B -> C。 动态编排 (Dynamic)。由 LLM 根据目标和当前环境决定下一步做什么。
自主性 低。它像是一条流水线，每一步都是固定的。 高。它像是一个项目经理，能根据反馈改变计划。
应对复杂性 适合可预测、结构化的任务（如：翻译 -> 总结）。 适合模糊、开放、多步骤的任务（如：写一段代码并运行，报错了就去搜 Google 解决它）。
循环与反馈 通常是单向执行，没有“重试”或“纠错”的闭环。 具备推理-观察-行动 (Reasoning-Observation-Action) 的循环。
工具调用 在特定步骤调用特定工具。 根据需要自主决定何时使用哪个工具。

形象比喻：

  • LLM Chain 像“菜谱”： 你必须严格按照第一步洗菜、第二步切菜、第三步炒菜的顺序执行。如果中间没菜了，程序可能直接崩溃或报错。
  • AI Agent 像“厨师”： 你给他的指令是“做顿红烧肉”。厨师会检查厨房有没有肉，没有肉就自己去买（工具调用）；火太大了就调小点（反思与修正）；他会根据实际情况自主完成任务。

三、 总结

  • LLM Chain 解决的是确定性流程的自动化。
  • Agent 解决的是不确定性环境下的目标达成。

Agent 的出现意味着我们不再需要为每一个场景写死逻辑，而是提供目标和工具，让 LLM 充当“大脑”自主调度。这种从“面向过程编程”向“面向目标编程”的转变，正是 Agent 架构的核心魅力。

Q2：解释ReAct模式的工作原理

回答要点：ReAct （Reasoning+Acting）是Agent的基石。

它将”；

思考”（Thought）和”行动”（Action）结合。LLM先生成一段推理，说明下一步要做什么，然后调用工具观察（Observation）结果，再根据结果进入下一轮推理。

ReAct 是 Reasoning（推理）与 Acting（行动）的缩写。它是由 Shunyu Yao 等人在 2022 年（ICLR 2023）提出的一种促使大模型在复杂任务中交替进行“逻辑推理”和“外部执行”的方法论。

简单来说，ReAct 模式让大模型像人类一样工作：先思考（Thought），再动手（Action），然后看结果（Observation），最后再决定下一步怎么做。

1. ReAct 的核心工作流程

ReAct 的工作原理是一个循环的迭代过程，通常被称为 Thought-Action-Observation 循环：

  1. Thought (推理/思考)：
    • 模型生成一段文字，描述当前的状态、面临的问题以及接下来的打算。
    • 作用： 帮助模型拆解任务，确定需要调用什么工具，避免盲目行动。
  2. Action (行动)：
    • 模型根据思考的结果，输出一个具体的指令（例如调用搜索 API、执行 Python 代码或查询数据库）。
    • 作用： 与外部世界交互，获取模型自身权重中不包含的实时或专业信息。
  3. Observation (观察)：
    • 系统执行 Action 后的返回结果（例如搜索到的网页片段、代码运行报错、数据库返回的行）。
    • 作用： 提供外部反馈，作为下一次推理的依据。
  4. 循环迭代：
    • 模型看到 Observation 后，进入下一个 Thought 阶段，评估结果是否满意。如果满意，则给出最终答案；如果不满意，则继续规划下一次 Action。

2. 一个具体的例子

假设用户问：“现任苹果公司 CEO 出生的那一年，世界杯冠军是谁？”

  • Thought 1: 我需要先知道现任苹果 CEO 是谁，以及他的出生年份。
  • Action 1: Search("Current Apple CEO")
  • Observation 1: 苹果现任 CEO 是蒂姆·库克（Tim Cook），他出生于 1960 年。
  • Thought 2: 既然库克出生于 1960 年，我现在需要查找 1960 年的世界杯冠军是谁。
  • Action 2: Search("1960 World Cup winner")
  • Observation 2: 1960 年实际上并没有举办世界杯（世界杯每四年一届，1958 年后是 1962 年）。但 1960 年举办了首届欧洲杯。
  • Thought 3: 搜索结果显示 1960 年没有世界杯。我应该告诉用户这一事实，或者检查用户是否指的是欧洲杯。根据问题，我先确认 1960 年确实没有世界杯。
  • Final Answer: 苹果现任 CEO 蒂姆·库克出生于 1960 年。然而，1960 年并没有举办足球世界杯，那一年举办的是第一届欧洲足球锦标赛（苏联队夺冠）。

3. 为什么 ReAct 如此重要？（解决两大痛点）

在 ReAct 出现之前，LLM 处理任务主要有两种模式，但都有缺陷：

  • 只有 Reasoning (如 Chain of Thought):
    • 模型只在脑子里想。虽然逻辑清晰，但如果模型内部知识过时或错误，它会产生幻觉 (Hallucination)，一本正经地胡说八道。
  • 只有 Acting (如简单的 API 调用):
    • 模型直接调用工具。但由于缺乏思考，它可能无法理解复杂的指令，或者在工具返回错误信息时不知道如何调整策略，鲁棒性差。

ReAct 的优势：

  • 协同效应： 推理引导行动，行动验证推理。
  • 可解释性： 开发者可以清晰地看到模型每一步的“心路历程”，便于调试。
  • 准确性： 通过观察外部反馈，模型能及时修正路径，大大降低了幻觉。

4. 总结：ReAct 的精髓

ReAct 模式的精髓在于 “闭环反馈”。它不再是把一串指令丢给模型让它一次性输出，而是建立了一个 “规划 -> 执行 -> 检查结果 -> 修正规划” 的动态机制。

这种模式目前已成为 LangChain、AutoGPT、BabyAGI 等主流 Agent 框架实现自主调度（Autonomous Orchestration）的核心底层逻辑。

Q3：如何实现Agent的长期记忆（Long-term Memory)

回答要点：

  • 短期记忆：利用Context Window，存储当前会话的历史（Chat History)

  • 长期记忆：通过RAG（检索增强）。将历史经验、知识编码为 Embedding存入向量数据库，Agent在执行任务前检索相关经 Ja(Experience Retrieval).

  • 2026新趋势：利用长文本模型（Long-context LLMs）直接处理超长历史，或者通过”摘要层级结构”对记忆进行递归压缩。

实现 AI Agent 的长期记忆（Long-term Memory），本质上是让 Agent 突破 LLM 上下文窗口（Context Window）的限制，能够跨越时间存储、检索并利用历史信息。

目前，实现长期记忆的主流技术路径可以总结为以下几种方案：

1. 基于矢量数据库的语义搜索 (RAG 模式)

这是目前最通用、最主流的方案，模拟的是人类的“语义记忆”。

  • 工作流程：

    1. 存储： 将 Agent 过去的对话历史、任务执行结果、外部文档等切分成块（Chunks）。
    2. 向量化： 使用 Embedding 模型将文本转化为高维向量。
    3. 持久化： 存入矢量数据库（如 Pinecone, Milvus, Weaviate, FAISS）。
    4. 检索： 当新请求进来时，将请求向量化，在库中搜索最相似的 top-k 条记录。
    5. 注入： 将检索到的相关记忆作为上下文（Context）输入给 LLM。

  • 优点： 存储量大，检索速度快。

  • 缺点： 缺乏时间序列逻辑，有时难以处理“昨天”和“今天”这种具有时间敏感性的冲突信息。

2. 递归总结与记忆压缩 (Recursive Summarization)

这种方案模拟人类对信息的“抽象与提炼”，常见于长文本对话场景。

  • 工作流程：

    1. 当对话长度接近模型窗口上限时，触发一个“总结任务”。
    2. LLM 将之前的对话摘要成一段精华文字（如“用户提到他住在上海，喜欢猫”）。
    3. 将摘要保存，并清理掉原始的琐碎对话。
    4. 下一次交互时，模型读取的是这个“摘要”而非原始对话。

  • 典型案例： ChatChain, LangChain 的 ConversationSummaryMemory。

  • 优点： 保持了逻辑连贯性，模型负担轻。
  • 缺点： 随着压缩次数增加，细节会丢失（信息的逐级损耗）。

3. 实体与知识图谱记忆 (Knowledge Graph)

这种方案模拟人类的“逻辑关系记忆”，侧重于事实的准确性。

  • 工作流程：
    1. Agent 从对话中提取三元组：实体 - 关系 - 实体（例如：Tim Cook - 是 - Apple CEO）。
    2. 将这些关系存入图数据库（如 Neo4j）。
    3. 查询时通过图谱路径检索关联信息。
  • 优点： 极其精准，不会产生幻觉，适合处理复杂的业务逻辑。
  • 缺点： 提取和构建成本高，难以处理非结构化的情绪或氛围信息。

4. 分层存储架构 (Tiered Memory)

受到操作系统（缓存-内存-硬盘）的启发，现代 Agent 往往采用多级存储：

  1. 感知记忆（Sensory Memory）： 当前输入的最直接上下文。
  2. 短期记忆（Short-term Memory）： 当前 Session 的最近几轮对话（直接放 Context 窗口）。
  3. 长期记忆（Long-term Memory）：
    • 经验数据库： 过去成功完成任务的步骤。
    • 个性化数据库： 用户的偏好、职业、固定习惯。

5. 进阶方案：反射与自我优化 (Reflection/Self-Optimization)

这是让 Agent 具有“成长性”的关键，代表作是斯坦福的虚拟小镇（Generative Agents）和 MemGPT。

  • 反思机制 (Reflection)： Agent 定期审视自己的记忆库，问自己：“从过去一天的经历中，我学到了关于用户的哪三件最重要的事？”然后将这些反思结果存入长期记忆。
  • 主动管理 (Memory Management)： 像操作系统管理内存一样，Agent 可以自主决定哪些信息是重要的需要永久保留，哪些是无用的可以删除（摒弃了被动检索）。

实现工具推荐

如果你想动手实现，可以参考以下框架：

  • MemGPT： 专门为解决长记忆设计的框架，将 LLM 视为处理器，将向量库视为硬盘。
  • Zep： 专为 AI Agent 打造的长期记忆层，支持自动总结、命名实体识别和异步存储。
  • LangGraph： 通过状态机管理复杂的状态（State），可以方便地实现记忆的持久化。
  • Pinecone/Milvus： 作为底层的向量存储设施。

总结

实现 Agent 长期记忆的最佳实践通常是：“向量数据库检索（找细节） + 定期总结（找主线） + 反思机制（提炼核心特征）” 的组合拳。

二、多智能体协同（Multi-Agent Systems, MAS）

Q4：单Agent遇到瓶颈时，为什么需要Multi-Agent？常见的协作模式有哪些？

原因：单个Agent在处理复杂、跨领域长任务时容易出现” 注意力漂移”或”推理链断裂”。

协作模式：

  • 中心化（Boss-Worker）：一个主Agent拆分任务并指派给子 Agent.
  • 流水线（Pipeline/Sequential）：A的输出作为B的输入（如代码生成->代码审查->修复）。
  • 民主协作（Joint Discussion）：多个Agent共同讨论得出结论。

当单个 Agent 在面对复杂任务遇到瓶颈时，引入 Multi-Agent System（MAS，多智能体系统） 是目前的必然趋势。

一、 为什么单 Agent 会遇到瓶颈？

即使是 GPT-4 这样强大的模型，作为单 Agent 运行也会面临以下挑战：

  1. 上下文迷失（Context Overload）： 当任务极其复杂时，系统提示词（System Prompt）会变得非常冗长，模型容易顾此失彼，产生“注意力稀释”或忽略指令。
  2. 角色冲突（Role Confusion）： 一个模型很难同时演好“严谨的审计师”和“天马行空的创意家”。角色的对立会导致输出平庸化。
  3. 错误累积（Error Propagation）： 在长链路任务中，单 Agent 如果第一步走错，后面会沿着错误方向越走越远，缺乏有效的外部审视机制。
  4. 工具过载： 如果给一个 Agent 挂载 50 个工具，它在选择工具时会由于候选干扰太多而导致调用准确率大幅下降。

二、 为什么需要 Multi-Agent？

多智能体系统的核心逻辑是“分而治之”（Divide and Conquer）。

  • 专业化（Specialization）： 每个 Agent 只负责一个子领域（如代码编写、文档撰写、质量测试），Prompt 更精简，性能更强。
  • 对抗与校验（Criticism & Verification）： 通过“引入第二双眼睛”，让一个 Agent 专门负责审核另一个 Agent 的结果，能显著降低幻觉。
  • 模块化扩展： 增加新功能只需增加一个新的小 Agent，而不必重写庞大的主 Prompt。

三、 常见的 Multi-Agent 协作模式

目前的框架（如 AutoGen, LangGraph, CrewAI）主要采用以下几种协作模式：

1. 顺序流水线模式 (Sequential / Chain)

这是最简单的模式，任务像流水线一样传递。

  • 流程： Agent A -> Agent B -> Agent C。
  • 场景： 翻译并润色文章。Agent A 负责初译，Agent B 负责语法检查，Agent C 负责风格润色。
  • 特点： 逻辑线性，适合步骤明确的任务。
2. 主从模式 (Manager / Hub-and-Spoke)

类似于公司里的“经理与员工”。

  • 流程： 存在一个 Manager Agent，它接收用户目标，拆解任务，分发给下属 Worker Agents，最后汇总结果。
  • 场景： 软件开发。Manager 将需求拆分，分给前端 Agent、后端 Agent 和测试 Agent，最后由 Manager 合并代码。
  • 特点： 控制力强，适合复杂且需要中心化调度的任务。
3. 协作/群智模式 (Joint Collaboration / Joint Effort)

Agent 之间在一个共同的空间（如群聊或看板）内自由交互。

  • 流程： 多个 Agent 看到同一个状态，根据自己的专业判断决定何时“举手”发言。
  • 场景： 创意头脑风暴。产品经理、技术架构师、市场专家在一个会话中自由讨论。
  • 特点： 灵活性极高，容易产生意想不到的创新。
4. 对抗/辩论模式 (Debate / Peer Review)

让两个 Agent 持有相反观点或竞争关系。

  • 流程： Agent A 给出方案，Agent B 专门负责找茬（红蓝对抗），Agent A 根据反馈修改，直到达成共识。
  • 场景： 法律条文分析、科学论文评审、复杂算法的逻辑推演。
  • 特点： 极大提高结果的严谨性和准确性。
5. 分层模式 (Hierarchical)

多级管理架构。

  • 流程： 顶级经理指挥中层经理，中层经理指挥底层执行者。
  • 场景： 跨国公司的市场进入战略分析。
  • 特点： 适合规模极大的工程，避免单个 Manager 节点过热。

四、 总结：从“全才”到“团队”

如果说 Single Agent 追求的是打造一个“全能天才”，那么 Multi-Agent 追求的就是构建一个“高效组织”。

  • 单 Agent 像一名自由职业者，适合处理快、平、准的日常任务。
  • 多 Agent 像一支特种部队，通过角色分工、相互审计和动态反馈，能够解决单模型无法逾越的复杂逻辑难题。

在实际落地中，目前业界的共识是：宁可要 5 个各司其职的小 Agent，也不要 1 个写了 2000 行 Prompt 的超级 Agent。

Q5：多智能体系统中如何解决”无限循环”或”通信冗余”问题？

回答要点：

  • 循环检测：引入状态机控制流程，设置最大迭代次数。
  • Token控制：对Agent间的对话进行摘要处理。
  • 终止条件：明确定义任务完成的标准（Definition of Done）

在多智能体系统（Multi-Agent System, MAS）中，“无限循环”（指 Agent 之间陷入死循环或重复错误）和“通信冗余”（指无效信息堆叠、Token 浪费）是两个非常核心的工程挑战。

以下是解决这些问题的常用策略和工程实践：

一、 解决“无限循环” (Infinite Loops)

无限循环通常发生在 Agent 陷入“复读机”模式，或者两个 Agent 相互推诿、反复纠结于同一个无法解决的错误。

  1. 设置强制终止条件 (Hard Constraints)：

    • 最大迭代次数 (Max Iterations)： 设定一个硬性上限（如 10 次或 20 次），一旦超过则强制停止并返回“任务失败”或当前最好结果。
    • Token 预算上限 (Token Budget)： 为整个任务流设置 Token 使用上限。

  2. 状态监控与检测 (State Detection)：

    • 重复检查 (Deduping)： 记录 Agent 的历史 Action 和 Thought。如果模型连续 3 次输出了完全相同的指令或思路，系统自动介入，强制修改 Prompt（例如：“你已经尝试过此方法且失败了，请换一种思路”）。
    • 停滞检测 (Stagnation Detection)： 监控“任务进度”。如果 Observation（观察结果）在连续几轮中没有实质性变化，判定为停滞。

  3. 引入判定者/协调者 (Supervisor / Arbiter)：

    • 引入一个高阶的 Manager Agent，专门负责监控对话流。如果它发现下属 Agent 陷入死循环，它有权打断对话，重新分配任务或直接改变策略。

  4. 环境对齐 (Environmental Grounding)：

    • 当循环发生时，强制 Agent 调用一个“自检工具”。例如在代码循环报错时，强制其查看本地文件系统或执行 Linter，用外部世界的“物理事实”打破模型内部的逻辑循环。

二、 解决“通信冗余” (Communication Redundancy)

冗余通常表现为 Agent 之间的“废话”（如：不断的客套、重复确认）以及全局广播导致的 Context 爆炸。

  1. 改变通信拓扑结构 (Topology Optimization)：

    • 由“群聊”转为“私聊”： 不要让所有 Agent 都能看到所有人的发言（Broadcast）。采用 Point-to-Point (点对点) 通信，只有相关的人才接收特定信息。
    • 分层架构 (Hierarchy)： 下层 Agent 只向直属上级汇报摘要，而不是把所有日志都传给顶层。

  2. 结构化输出 (Structured Communication)：

    • 强制 Schema： 要求 Agent 必须以 JSON 或特定的 XML 格式通信。在 Prompt 中明确禁止“客套话”（如：“好的，我非常乐意为您服务”）。
    • 协议化： 规定通信协议，例如必须包含 Reasoning (理由)、Action (指令)、Data (数据) 三部分，忽略非结构化文字。

  3. 上下文摘要与压缩 (Context Compression)：

    • 短期记忆修剪： 只保留最近 $N$ 轮的原始对话。
    • 滚动摘要： 每一轮对话后，由系统自动生成一份“当前进度摘要”，后续 Agent 只读摘要，不读原始长对话。
    • 关键信息提取： 仅传递特定的“状态变量”（State），而非完整的聊天历史。

  4. 按需激活 (On-demand Activation)：

    • 不是所有 Agent 都在每一轮被唤醒。通过 Router (路由) 机制，只有当 Manager 判定需要某 Agent 的专业技能时，才将其唤醒并将必要信息推给它。

三、 工业界框架的成熟方案

目前主流的 Agent 框架已经内置了一些机制来处理这些问题：

  • AutoGen (Microsoft)：
    • 通过 max_consecutive_auto_reply 限制连续自动回复次数。
    • 利用 GroupChatManager 的选择机制（Selection Method）来决定下一个谁说话，减少无关发言。
  • LangGraph (LangChain)：
    • 状态机控制： 它将 Agent 协作抽象为图（Graph）。你可以精确控制每一步的跳转逻辑（Edges），如果检测到循环路径，可以通过逻辑条件跳转到 END。
    • Persistence (持久化)： 支持检查点（Checkpoints），当发生冗余或错误时，可以手动或自动回溯到之前的某个状态。
  • CrewAI：
    • 强调“角色职责”，通过 Process 类（如 Sequential, Hierarchical）来规范任务流向，避免无序的通信。

总结

  • 解循环： 靠限额、重定向和外部反馈。
  • 减冗余： 靠权限隔离、结构化协议和摘要机制。

处理 MAS 的核心思想是：“像管理一个人类团队一样去管理 Agent”。明确的规章制度（Schema）、严密的汇报层级（Hierarchy）以及及时的绩效考核（Supervisor），是维持系统高效运转的关键。

三、Agent核心设计模式（Design Patterns）

Q6：请对比”工作流（Workflows）"与” 自主智能体（AutonomousAgents）”的优劣。

  • Workflows： 通过DAG（有向无环图）或状态机硬编码路径。优点是高可靠性、结果可预期，适用于报销审批、标准化客服。
  • Autonomous Agents：由LLM决定循环次数和工具调用。优点是灵活性极高，适用于开放式研究、代码编写。

面试金句：2026年的工程趋势是”用Workflow约束Agent”，即在框架定义的路径内给子Agent局部决策权。

在 AI 系统设计中，工作流（Workflows）与自主智能体（Autonomous Agents）代表了两种截然不同的设计哲学：一个是“确定性的编排”，另一个是“概率性的自主”。

以下是两者的详细对比、优劣分析以及适用场景：

1. 概念定义

  • 工作流 (Workflows)： 由开发者预先定义好步骤、分支和逻辑。AI（LLM）在其中通常扮演“执行节点”的角色，负责处理特定环节的任务。路径是固定的（A -> B -> if C then D）。
    • 例子： LangGraph 的状态机、低代码平台（如 Coze/Dify）的连线流程。
  • 自主智能体 (Autonomous Agents)： 由开发者给定一个目标（Goal）和一套工具（Tools）。Agent 拥有决策权，通过“思考-行动-观察”的循环自主决定执行步骤，路径是动态生成的。
    • 例子： AutoGPT、BabyAGI、基于 ReAct 模式的任务达成器。

2. 深度对比

维度 工作流 (Workflows) 自主智能体 (Autonomous Agents)
控制权 人类开发者掌握控制权。 LLM (大脑)掌握控制权。
可预测性 极高。结果稳定，每一步都可预期。 较低。同样的目标，每次执行路径可能不同。
灵活性 低。遇到未定义的边界情况容易报错或停滞。 极高。能根据环境反馈调整策略，应对复杂变数。
调试成本 低。路径清晰，哪里报错修哪里。 高。难以重现错误路径，容易进入死循环或产生幻觉。
Token 消耗 低。路径直达，效率高。 高。需要大量的“思考”过程和重复尝试。
适合规模 适合大规模、高频率的生产环境。 适合小规模、高度定制、探索性的任务。

3. 优势与劣势分析

工作流 (Workflows)
  • 优势：
    • 可靠性与安全性： 非常稳定，不会跑偏，适合对错误零容忍的业务（如财务审核、法律流程）。
    • 性能优化： 因为路径固定，可以针对每个节点进行专项提示词优化或微调（Fine-tuning）。
    • 透明度： 过程完全可视化，非技术人员也能理解业务逻辑。
  • 劣势：
    • 开发负担重： 开发者需要预见所有可能的情况。如果任务极其复杂，流程图会变成令人绝望的“蜘蛛网”。
    • 扩展性差： 增加一个新功能可能需要重构整个逻辑链条。
自主智能体 (Autonomous Agents)
  • 优势：
    • 解放双手： 开发者只需定义“做什么”，而不用管“怎么做”。
    • 处理不确定性： 擅长处理模糊、开放式的问题（如：请帮我调研市场上所有竞品的定价并写一份分析报告）。
    • 突现能力： 有时能发现开发者未曾预料到的高效路径。
  • 劣势：
    • 不可控性（幻觉）： 可能在错误的方向上努力，甚至在自我反馈中产生逻辑闭环（陷入死循环）。
    • 成本黑盒： 由于是动态迭代，很难预估完成任务需要消耗多少 Token 和时间。

4. 总结与建议：如何选择？

在目前的工业界实践中，“工作流为主，Agent 为辅”是主流趋势。

选择工作流场景：
  1. 流程标准： 任务可以被清晰地拆解为标准步骤（SOP）。
  2. 注重效率： 对响应时间有严格要求。
  3. 合规性高： 必须遵循特定的法律、财务或技术规范。
  4. 例子： 自动化客服、标准报告生成、数据清洗流水线。
选择自主智能体场景：
  1. 目标导向： 路径极度不确定，甚至开发者都不知道该怎么做。
  2. 长尾任务： 场景太多，无法穷举所有分支。
  3. 个人助手： 需要极高的个性化和对用户意图的深度理解。
  4. 例子： 个人调研助手、代码自动修复、开放式解谜。
趋势：混合模式 (The Hybrid Pattern)

现在的顶尖设计往往是：在一个大的、确定的工作流中，嵌套几个微型的自主 Agent。

  • 大的方向由工作流控制（保证不跑偏）。
  • 具体的、具有挑战性的子任务交给 Agent（保证灵活性）。

这种模式通常被称为 “约束下的自主”，它平衡了系统的可靠性与灵活性。

Q7：详细解释”编排者-执行者（Orchestrator-Workers）”模式。

回答要点：

主Agent（Orchestrator）负责将复杂任务分解为子任务，分发给具有不同Skill的Worker Agents，最后汇总结果。

适用场景：大型软件开发（一个写UI，一个写后端，一个写测试）。

难点：任务分解的粒度。如果拆得太细，通信成本极高；太粗，Worker会产生幻觉。

Q8：什么是”反思/自我纠正（Reflection/Self-Correction）"模式？

这是提升Agent成功率最有效的模式。Agent生成输出后，由另一个（或同一个）Agent扮演批评者（Critic），检查输出是否符合约束条件，并提供反馈让前者迭代。

技术细节：可以使用Reflexion架构，记录”失败轨迹”作为长短期记忆，避免重复同样的错误

四、深度技术实现与状态管理

09：在多轮对话Agent中，如何处理”状态爆炸”和” 上下文溢出”？

回答要点：

State Schema：定义严格的状态结构（如使用LangGraph的TypedDict），只保存核心变量。

Trim Strategy：不仅是简单的截断，而是根据语义重要性保留（例如保留SystemPrompt、最近N轮对话和当前任务目标）。

Summary Buffer： 将I日的对话摘要化，将摘要存入Context头部。

Q10：如何保证Agent调用工具（Function Calling）的可靠性？

语法层面：利用JSON Mode或强类型约束。

逻辑层面：引入”确认机制（Human-in-the-loop）”，对于高风险操作（如删库、转账）必须由人点击确认。

重试逻辑：如果LLM生成的参数不合法，将报错信息返回给 LLM，让其自我修复（Self-heal）

Q11:LangGraph中的” 节点（Node）"和”边（Edge）”与传统工作流有何不同？

传统工作流的边是固定的。

LangGraph的边可以是条件边（Conditional Edges），由LLM的输出决定下一步走向哪个Node。

支持循环（Cycles），这是Agent能够不断尝试直到成功的核心。

Q12：你如何量化一个Agent的性能？

任务成功率（Success Rate）：这是核心指标。

平均推理步数（Avg Steps）：步数越少，成本越低，响应越快。

工具调用准确率（Tool Call Accuracy）。

影子测试（Shadow Testing）：在生产环境并行跑新IAgent逻辑，对比输出差异。

Agentic RAG专项问答

Q13: RAG系统中经常遇到检索出来的片段（Chunk）互相冲突，Agent该听谁的

元数据加权：根据文档的实时性、权威性（部门等级）进行权重排序。

多智能体辩论（Multi-Agent Debate） ：让不同的Agent持不同的Chunk进行对比，识别！出冲突点并反馈给用户，或者根据逻辑一致性选择最合理的解释。

引用溯源：强制要求输出必须附带Source链接，让用户做最后校验。

Q14：如何处理企业知识库中的”权限隔离”问题？

Agent会不会把高管工资查出来给普通员工

核心策略：RAG权限对齐。

实现方式：在向量数据库中，每个Embedding向量都附带ACL（访问控制列表）元数据。

在Agent触发检索请求时，强制将”当前用户信息”作Filter注入检索语句中。确保在向量检索阶段就完成物理隔离，而不是靠提示词拦截。

Q15：当知识库内容更新很快（如每日新闻或实时股价）时，你的RAG系统如何应对？

动态路由：Agent根据问题类型识别出”实时性要求”，如果是实时问题，优先调用实时API或搜索工具，而非检索向量库。

流式索引更新：利用数据流（如Kafka）监听知识库变化，实现增量Embedding写入。

缓存失效策略： 针对高频问题设置TTL缓存，并在源数据更新时触发缓存失效

Q16：如何提升问答准确度

提升准确度不能只靠Prompt，而是一套组合拳：

1、深度解析层：Layout-Aware Parsing（布局感知解析）

痛点：传统的文本分割（Chunking）会打断表格结构或将标题与正文分离，导致语义断裂。

解决方案：

  • 使用Layout Analysis 模型（如 DocLayout-YoLo或Unstructured）。将文档识别为：标题、正文、表格、图片、列表。
  • 语义分块：按标题层级（H1-H4）进行切分，而不是按字符数。确保每个Chunk都有完整的上下文。

2、检索增强层：Multi-Stage Retrieval

混合检索（Hybrid Search）：向量检索（语义）+BM25（关键词，解决专有名词、缩写问题）

重排序（Reranking）：使用Cross-Encoder 模型（如BGE-Reranker）对初筛的Top-50进行精排。这是提升准确度性价比最高的方法。

查询扩展（Query Expansion）：Agent自动生成3个同义问题并行检索，解决用户提问过于简单的问题。

3、生成校验层：Self-Correction（Self-RAG）

验证节点：在生成答案前，让Agent判断：

"检索到的内容是否足以回答问题？”（不够则重新检索）

“答案中是否有任何内容是检索结果里没提到的？“（防止幻觉）

Q17：回答中如何包含原文档相关的图和表格

这是目前工业界的难点，核心在于“多模态对齐”和“引用索引”。

1. 表格的处理（Tables）

  • 解析阶段：不要将表格转为纯文本。
  • 最佳实践：将表格解析为 Markdown 或 HTML格式。LLM 对结构化标记语言的理解能力远强于纯文本。
  • 摘要索引：为每个表格生成一个自然语言摘要（Summary），将摘要存入向量库。检索时通过摘要定位表格，但在生成时把完整的 Markdown 表格喂给 LLM。
  • 渲染阶段：前端直接渲染 LLM 输出的 Markdown 表格。

2. 图片的处理 （Images）

多模态索引法：

  1. Image Captioning：使用多模态模型（如GPT-40-mini 或本地的Qwen-VL）为图片生成详细描述。
  2. 存入向量库：将“图片描述+图片ID +所在页码”存入向量库。
  3. 检索逻辑：当用户问到“XX流程图” 时，匹配到图片描述。

回显机制：

  1. 在返回给用户的答案中，使用特定占位符，如［IMAGE_ID: 123］。
  2. 前端解析该占位符，从静态资源服务器（OSS）调用对应的图片 URL 进行展示。