【AIAgent面试系列】AIAgent基础知识

本文将由浅入深讲解AI Agent的面试知识点。

1、Agent 基础认知

1.1、 你怎么定义 AI Agent？它和"调用一次大模型"的本质区别是什么？

Agent 是一个能自主感知环境、规划、行动、并根据反馈迭代以完成目标的闭环系统，核心是“LLM作为大脑，自主决策并完成多步任务”。

与单次 LLM 调用的本质区别在于三点：

• 闭环（Loop）：单次调用是 输入 → 输出 的开环；Agent 是 观察 → 思考 → 行动 → 观察 的闭环，能根据执行结果调整下一步。
• 自主性（Autonomy）：由模型自己决定"做什么、做几步、何时停"，而非由人写死流程。
• 工具与环境交互（Acting）：能对外部世界产生副作用（查库、发请求、写文件），而不只是生成文本。

一句话概括：LLM 是"大脑"，Agent = 大脑 + 记忆 + 工具 + 循环控制。

1.2、那 workflow（如 Dify/Coze 的固定编排）算不算 Agent？

严格说 Dify/Coze 的固定编排是 workflow，因为控制流由开发者定义。但他们也支持 Agent 节点，某个节点可交给模型自主决策。
 实践中我倾向有边界的自主——主流程用 workflow 保证可控，把需要灵活判断的环节（如工具选择、信息抽取）交给 Agent，并加护栏。
选型标准是：任务路径是否可穷举——可穷举用 workflow，不可穷举才上 Agent。

两者对比如下：

一句话总结：Workflow 是"人定流程、模型填内容"；Agent 是"模型定流程、人定边界"。

1.3、 一个 Agent 系统通常由哪些核心模块组成？

Agent 是一个能自主感知环境、规划、行动、并根据反馈迭代以完成目标的闭环系统，包含以下核心模块：

1.4、 ReAct 是什么？为什么它成为 Agent 的主流范式？

ReAct = Reasoning + Acting，让模型交替产生"思考（Thought）“和"行动（Action）”，并接收"观察（Observation）"，形成：

Thought → Action → Observation → Thought → … → Final Answer

它成为主流的原因：

• 推理与行动耦合：思考指导行动，观察修正思考，比纯 CoT（只推理不行动）更接地气。
• 可解释、可调试：每一步 Thought 都是天然的日志。
• 天然支持工具：Action 就是工具调用，Observation 就是工具返回。

1.5、ReAct的失败模式有哪些？

1.6、ReAct如何缓解死循环？

ReAct是思考-行动-反馈-思考的循环模式，那么这里的死循环就是陷入这个流程无法“自拔”。为了打破这个循环，首先容易想到限制循环次数，限制运行时长，发现循环模式退出(比如重复使用相同参数调用某工具)，因此就有以下缓解策略：最大步数限制、超时熔断、重复动作检测和内容去重。

具体对比如下：

四个对策分属两个阵营，职责完全不同：

• 内容维度（聪明止损）：重复动作检测 + 状态去重 —— 负责发现循环、提前打断，省的是中间无效的 token 和延迟。
• 兜底维度（笨但可靠）：最大步数 + 超时熔断 —— 负责保证无论如何都能退出，保的是系统不挂死。

一句话总结:内容维度负责"聪明地发现循环"，兜底维度负责"可靠地保证退出"；工程上四者叠加，缺一不可。

1.7、ReAct中如何缓解错误累积？

ReAct的错误累积主要是基于错误的工具结果进行推理。为了应对这里的错误累积，核心思路是把"静默错误"变成"显式错误"——让模型有能力判断"这次调用到底成没成功"。

以下是几种缓解对策：

2、规划与推理（Planning & Reasoning）

2.1、 CoT、ToT、Plan-and-Execute 有什么区别？分别适合什么场景？

关键区别：

• CoT/ToT 是"想"。 ToT 效果好但 token 消耗成倍增长，工程上要慎用。
• ReAct 是"想+做"。
• Plan-and-Execute 是"先想清楚再做"。缺点是 计划一旦出错，后续全错（缺乏动态调整）；实践中常加 replan（重规划） 节点。

2.2、 如何让 Agent 具备"反思（Reflection）"能力？

反思 = 让 Agent 审视自己的输出/轨迹并改进。常见实现：

• Self-Refine：生成 → 自我批评 → 修订，循环若干轮。
• Reflexion：把失败经验写成"语言化记忆"，下次任务时作为提示注入。
• Critic 模型：用另一个模型/角色专门做评审。

反思要有明确的评价标准（否则模型只会说"看起来不错"），并限制轮数防止无限自我怀疑。
 研究表明反思对弱模型提升明显，对强模型可能引入噪声甚至变差。

2.3、 任务分解（Task Decomposition）有哪些策略？

任务分解的本质是 把不可验证的大任务分解为多个可验证的小任务，任务分解策略如下：

• 显式分解：让模型先输出子任务列表（Plan），再逐个执行。
• 隐式分解：ReAct 中通过 Thought 自然拆解。
• 递归分解：子任务仍复杂时继续拆（类似分治）。
• 按角色分解：不同子任务交给不同专长的 Agent。

问题1: 如何确认拆分粒度？
 粒度是否合适，就看拆出来的子任务能否独立判断"做没做对"：

• 太粗：子任务仍不可验证 -> 模型做完不知道对不对，只能盲猜，错误累积
• 太细：每个子任务可验证，但调度开销大、上下文膨胀
• 恰好：每个子任务有明确的完成判据，做完即可验证，错了立即止损

问题2:怎么判断是 可独立验证？
 问三个问题，三个都"是" → 粒度合适；有"否" → 继续拆或调整。

• 有明确产出吗？ 子任务是否产生一个可检查的中间结果（文件、数据、状态、答案）？
• 有客观判据吗？ 能否不靠模型自述，用外部手段确认对错（查库、跑测试、比对 schema）？
• 失败可定位吗？ 如果这步错了，能否明确知道"错在这步"，而不是模糊地"整体不对"？

3、多智能体系统（Multi-Agent）

3.1、 什么时候需要多智能体？单 Agent 不够吗？

多智能体适合任务可清晰分工、需要对抗/辩论、上下文隔离等场景。但多智能体不是银弹：通信开销大、易发散、调试难。能用单 Agent + 工具解决就别上多 Agent。

多智能体解决的不是“任务难”，而是“单上下文装不下/会互相污染”的问题。三个真正的“需要”信号：

• 信号 1：上下文冲突（需要隔离）
   不同子任务需要的上下文互相干扰时：
   例：写代码 Agent 的上下文里塞满“代码规范、API 文档、报错日志”，再让它做“文档写作”，风格和注意力都会被污染。
   判据：两个子任务的上下文重叠度低、但各自都很重 → 拆成两个 Agent，各自带专属上下文。
• 信号 2：需要对抗/独立视角（需要制衡）
   自己检查自己不可靠——模型对自己的输出有天然偏好（自我偏好偏差）：
   例：代码生成 + 代码评审，同一个 Agent 自查会漏掉自己的惯性错误；两个独立 Agent（甚至不同模型）评审，检出率显著更高。
   判据：任务质量依赖“挑错” → 生成者和评审者必须分离。
• 信号 3：任务天然多角色分工（需要并行/专精）
   例：软件工程（PM/Dev/QA）、深度研究（检索员/分析员/撰写员）——每个角色有不同的系统提示、工具集、知识库。
   判据：不同子任务需要不同的工具集或专精配置，塞进一个 Agent 会导致工具描述臃肿、选择准确率下降。

反面：这些情况坚决用单 Agent

• 串行依赖的流水线：步骤 A 的输出就是 B 的输入，且 B 不需要独立上下文 → 单 Agent 顺序执行即可，拆开只增加通信成本。
• 工具少于 10 个、上下文装得下：单 Agent 完全够。
• 要求强一致性：多 Agent 天然引入不一致风险（见失败模式 4）。
• 延迟敏感：多 Agent 通信开销大，单 Agent 更快。

3.2、多智能体常见的失败模式

单 Agent 的失败在“步”，多 Agent 的失败在“关系”。多 Agent 的失败本质都是‘缺乏全局协调机制’（终止条件、owner、共享状态、验证链）”。

3.3、 多智能体有哪些典型协作拓扑？

多智能体有以下五种拓扑结构：

• 层级式（Hierarchical）

• 流水线式（Pipeline）

• 辩论式（Debate）

• 黑板式（Blackboard）

• 群聊式（Group Chat）

五种典型拓扑详解如下：

选型对照表:

两个关键认知:

• 拓扑可以混合：实践中常见“层级式为骨架 + 局部辩论”（Orchestrator 分派，其中某个难题交给两个 Worker 辩论后汇报）。
• 拓扑决定失败模式：辩论式高发“无限对话+成本爆炸”，群聊式高发“角色退化”，流水线高发“级联幻觉”——选拓扑时就要预判它的高发失败模式并预置对策。