第四篇 Agent智能体开发专项

第四篇 Agent智能体开发专项

本篇定位：AI应用开发面试第二核心考点，占比约30%，覆盖从单Agent到多Agent、从框架原理到生产落地的全链路能力。中高级岗考察深度逐年提升，重点掌握核心原理、工程落地、问题排查与架构设计能力。

---

4.1 Agent核心原理与经典范式

核心题1：什么是AI Agent？和普通对话、RAG系统的核心区别是什么？

背诵要点

• 定义：目标驱动、能自主规划、调用外部工具、迭代反馈的智能系统，核心是「自主决策+外部行动」
• 普通大模型对话：被动问答，仅依赖模型内置知识，无外部执行能力，输出不产生真实业务动作
• RAG系统：增强知识库问答，本质仍是固定流水线的问答模式，无自主规划和执行能力
• Agent：目标驱动，自主拆解任务、调用工具、修正错误，可产生真实业务副作用，能力边界远超单纯问答

核心题2：ReAct框架的核心思想是什么？和思维链（CoT）有什么区别？

背诵要点

• ReAct = Reasoning（推理） + Acting（行动），推理与工具调用交替循环
• 标准流程：思考下一步动作 → 调用工具获取结果 → 基于结果继续推理 → 循环至任务完成
• 和CoT的区别：
  • CoT是纯内部逻辑推理，仅在模型内部思考，无法获取外部信息，解决不了知识过时和事实性问题
  • ReAct结合外部工具，能获取实时信息、执行真实操作，可落地性更强，是生产级Agent的基础范式

核心题3：Plan-and-Execute规划模式是什么？和ReAct相比有什么差异？

背诵要点

• 核心思想：先做全局规划，拆解为多份子任务，再逐个执行，执行过程中可动态调整计划
• 标准流程：理解目标 → 生成多步执行计划 → 按计划执行子任务 → 复盘调整计划 → 最终输出
• 和ReAct的差异：
  • ReAct：走一步想一步，灵活度高，适合简单、开放、路径不确定的任务，容易跑偏和死循环
  • Plan-and-Execute：先规划后执行，可控性强，适合复杂长流程任务，任务完成度更高
• 生产级趋势：两者结合，先做顶层规划，具体子任务用ReAct模式执行

核心题4：一个标准Agent由哪些核心模块组成？

背诵要点

六大核心模块，各司其职：

1. 大模型推理层：Agent的大脑，负责规划、决策、推理、反思
2. 记忆模块：保存会话历史、中间状态、长期知识与经验
3. 工具集：外部能力入口，包括搜索、数据库、API、文件操作等
4. 规划模块：任务拆解、路径规划、异常修正、动态调优
5. 执行层：工具调用调度、结果回传、状态更新
6. 评估反思模块：校验结果正确性、自我修正、沉淀经验

高频追问

1. Agent必须用大模型吗？小模型能不能做Agent？

   • 不一定。固定流程、简单工具调用的规则化Agent，小模型加规则就能实现
   • 复杂开放场景、自主规划、灵活推理、异常处理，必须用大模型
   • 生产主流架构：大模型做规划调度，小模型做具体执行，分层降本提效

2. AutoGPT为什么生产落地很少用？

   • 无边界规划，容易死循环、任务跑偏，可控性极差
   • Token消耗极高，单任务成本不可控
   • 任务成功率低，稳定性差，无法满足生产要求
   • 生产级Agent都是限定场景、明确边界、可控流程，不会做无限制的通用Agent

3. Agent规划失败常见原因有哪些？怎么优化？

   • 原因：任务理解偏差、工具边界描述不清晰、缺乏领域知识、异常场景未覆盖
   • 优化：完善工具描述、加入少样本示例、引入自我反思机制、预设常见异常分支、通过人工反馈持续调优

---

4.2 Agent开发框架与选型

核心题1：主流Agent开发框架有哪些？各自适用场景是什么？

背诵要点

四大类框架，按需选型：

1. LangChain / LangGraph ：代码级框架，全球生态最完善
   • LangChain：封装工具调用、RAG、记忆等基础能力，适合快速搭建简单Agent
   • LangGraph：基于状态机架构，支持循环、条件分支、持久化状态，生产级复杂Agent首选
2. Dify ：国产企业级可视化平台
   • 自带可视化工作流、RAG管线、Agent配置，低代码可快速落地
   • 适合企业内部工具、非技术团队快速验证业务场景
3. Coze（扣子） ：字节跳动出品，零代码可视化平台
   • 插件生态丰富，上手极快，适合个人开发者、小团队快速验证Demo
4. AutoGen / CrewAI ：专攻多Agent协作
   • 内置成熟的分工协作模式，不用自研调度逻辑
   • 适合多角色协同、流水线式的复杂任务场景

核心题2：LangGraph和LangChain的核心区别是什么？解决了什么痛点？

背诵要点

• LangChain：线性链式执行，状态管理弱，无法优雅处理循环、条件分支，适合简单单轮任务
• LangGraph：基于状态机的架构，是LangChain生态的进阶方案
  • 原生支持循环推理、条件分支、人工介入，天然适配Agent思考-行动循环
  • 内置持久化状态，支持断点续跑、任务中断恢复
  • 执行步骤可控，可观测性更强
• 解决的核心痛点：LangChain链式结构无法满足Agent多轮迭代、状态持久化、复杂流程编排的需求

核心题3：什么时候选低代码可视化框架，什么时候选手写代码框架？

背诵要点

• 选低代码框架（Dify/Coze）的场景：
  • 快速验证业务想法、做MVP原型
  • 内部工具、简单业务场景，无深度定制需求
  • 产品/运营等非技术团队主导的场景
• 选代码级框架（LangGraph等）的场景：
  • 生产级复杂系统，需要深度定制逻辑
  • 复杂工作流、多系统深度集成
  • 对性能、可控性、可扩展性要求高
  • 需要融入现有技术栈和工程体系
• 选型原则：简单场景优先低代码提效，复杂核心场景用代码级框架保障可控性

高频追问

1. 从零手写Agent和用框架比有什么优劣？

   • 手写优势：灵活度最高、完全可控、无框架依赖、无冗余逻辑
   • 手写劣势：开发成本高、重复造轮子、需要自己踩所有坑
   • 框架优势：开发快、生态完善、内置最佳实践、社区问题多易排查
   • 框架劣势：有学习成本、API变动频繁、深度定制有约束
   • 生产建议：绝大多数场景用成熟框架，极端定制化场景才考虑自研核心

2. 框架更新太快、API经常变怎么办？

   • 锁定稳定版本，不盲目追新
   • 封装一层业务抽象层，框架只做底层实现，业务代码不直接依赖框架API
   • 重点吃透底层原理，框架只是工具，原理是通用的
   • 核心逻辑尽量轻量化，不重度依赖框架高级特性

---

4.3 工具调用工程与MCP协议

核心题1：Function Calling完整执行闭环是什么？

背诵要点

标准四步闭环，缺一不可：

1. 定义：预先定义工具Schema，包括功能描述、参数结构、返回值说明
2. 决策：大模型根据当前任务，判断是否需要调用工具、调用哪个工具、传入什么参数
3. 执行：业务代码解析模型的调用指令，执行真实工具逻辑，获取执行结果
4. 回传：将工具执行结果返回给大模型，模型基于新信息继续推理，直至任务完成

核心题2：工具Schema设计有哪些最佳实践？

背诵要点

1. 单一职责：一个工具只做一件事，避免大而全的万能工具，降低模型理解成本
2. 描述清晰：功能描述准确，写明适用场景和边界，减少模型误用
3. 参数强类型：明确参数类型、必填/选填、枚举值范围，减少参数错误
4. 结构化拆分：复杂参数拆分为多个明确字段，避免模糊的字符串参数
5. 返回值规范：明确返回格式和字段含义，错误信息也要结构化返回，方便模型处理

核心题3：工具调用有哪些常见异常？怎么处理？

背诵要点

五大常见异常与对应方案：

1. 参数格式错误 ：参数缺失、类型错误、取值非法
   • 处理：前置参数校验，不合法则返回错误信息，让模型重新生成参数
2. 工具执行失败 ：网络错误、下游服务异常、业务逻辑报错
   • 处理：结构化返回错误信息和原因，让模型决定重试或更换方案
3. 循环重复调用 ：相同工具相同参数反复调用，陷入死循环
   • 处理：设置最大执行步数，重复调用检测，触发后引导反思换方法
4. 幻觉调用 ：模型调用不存在的工具
   • 处理：工具白名单校验，不存在则返回提示，引导使用已有工具
5. 返回结果过长 ：工具返回内容太多，上下文溢出
   • 处理：工具侧做摘要、分页，或让模型指定需要的字段，二次查询

核心题4：什么是MCP协议？和传统工具接入比有什么核心优势？

背诵要点

• 定义：模型上下文协议（Model Context Protocol），是Agent对接外部工具与数据源的行业标准接口
• 核心优势：
  1. 一次实现，处处调用：工具端只需实现一次MCP接口，所有支持MCP的Agent都能直接调用，告别重复适配开发
  2. 标准化企业级能力：内置权限控制、异步任务、UI交互渲染等标准能力，不用每个工具重复开发
  3. 解耦架构：Agent和工具完全解耦，工具升级、更换不影响Agent逻辑
  4. 生态爆发：已成行业事实标准，主流大模型厂商全量适配，社区成熟工具丰富

高频追问

1. 多个无依赖的工具可以并行调用吗？怎么实现？

   • 可以，能大幅缩短总任务耗时
   • 实现：模型一次性返回多个独立的工具调用指令，业务层并行执行所有工具，全部完成后统一回传给模型
   • 注意：先判断工具间是否有依赖关系，有依赖的必须串行执行
   • 适用场景：多份信息检索、多个独立数据查询

2. 工具调用的幂等性怎么保证？

   • 每个工具调用生成唯一请求ID，工具侧做去重校验
   • 查询类工具天然幂等，写入类工具加幂等键
   • 断点续跑时，已执行成功的步骤标记状态，不再重复执行
   • 有副作用的操作，必须设计幂等机制，避免重复执行产生业务损失

3. 工具返回结果太长，上下文塞不下怎么办？

   • 工具侧支持分页、字段筛选，只返回核心信息
   • 对返回结果做摘要压缩，提取关键内容
   • 让模型明确指定需要的信息，工具做二次精准查询
   • 分多次调用，分批处理结果，逐步推理

---

4.4 状态管理与分层记忆系统

核心题1：Agent的三层记忆架构是什么？各自的作用和存储方式？

背诵要点

经典三级记忆体系，模拟人类记忆机制：

1. 工作记忆
   • 作用：当前任务的上下文、中间推理结果、临时状态
   • 存储：程序内存、滑动窗口，随任务结束释放
   • 时长：分钟级，容量有限
2. 短期记忆
   • 作用：单轮会话的完整交互历史、执行轨迹
   • 存储：Redis、内存数据库
   • 时长：小时到天级，会话结束后可保留一段时间
3. 长期记忆
   • 作用：用户偏好、领域知识、成功经验、行为习惯
   • 存储：向量数据库 + 关系型数据库
   • 时长：永久存储，按需召回

• 核心原则：分层存储、按需召回，控制上下文体积，避免信息过载

核心题2：长对话上下文溢出怎么解决？

背诵要点

五种主流方案，可组合使用：

1. 滑动窗口：只保留最近N轮对话，丢弃最早的内容，实现最简单
2. 摘要压缩：对历史对话做总结摘要，用压缩后的摘要替代完整原文，保留全局信息
3. 记忆召回：把历史记忆向量化，只召回和当前任务相关的片段，不全量塞入上下文
4. 状态外移：工具执行结果、中间状态等数据存在外部存储，上下文只保留核心推理信息
5. 长上下文模型：更换更大窗口的模型，作为兜底方案，成本更高

核心题3：Agent任务中断后，怎么实现断点续跑？

背诵要点

• 核心依赖：持久化的状态存储
• 完整实现流程：
  1. 每执行完一个步骤，就将当前状态（已完成步骤、中间结果、待执行任务、错误信息）持久化到Redis或数据库
  2. 任务中断重启后，读取历史状态，定位中断节点
  3. 从断点处继续执行，已完成步骤不重复调用
• 配套要求：
  1. 工具调用支持幂等，避免重复执行产生副作用
  2. 状态包含完整的上下文信息，保证恢复后推理不中断
  3. 异常节点记录错误信息，恢复后可重试或跳过

核心题4：记忆的召回和遗忘机制怎么设计？

背诵要点

召回机制：

1. 相关性召回：基于向量相似度，召回和当前任务最相关的记忆
2. 时效性加权：近期记忆权重更高，远期记忆权重降低
3. 重要性加权：关键决策、成功经验、用户偏好优先级更高
4. 混合召回：关键词匹配 + 语义相似度结合，提升召回准确率

遗忘机制：

1. TTL过期：短期记忆设置过期时间，自动清理
2. 低频淘汰：长期不访问、不重要的记忆自动归档或淘汰
3. 冲突更新：新的正确记忆覆盖旧的错误记忆
4. 摘要合并：相似的记忆合并摘要，减少冗余

高频追问

1. 滑动窗口和摘要压缩各有什么优劣？怎么选？

   • 滑动窗口：实现简单、信息无损失；长对话会丢失早期关键信息
   • 摘要压缩：保留全局信息，上下文体积小；有细节损失，实现复杂
   • 选型：短对话用滑动窗口，长对话用「早期摘要 + 近期滑动窗口」结合的方案

2. 会话记忆为什么不建议参与检索？

   • 历史话题会干扰当前检索，导致召回偏移
   • 指代、省略语会让检索Query不完整，降低召回准确率
   • 最佳实践：检索只基于当前问题（可做指代消解），记忆只辅助生成环节

3. 长期记忆和RAG知识库有什么区别？

   • RAG知识库：公共知识、文档资料，面向所有用户，结构化程度高
   • 长期记忆：个性化信息、用户偏好、历史交互经验，面向单个用户/会话
   • 技术上都可以用向量数据库存储，但数据来源、使用场景、更新频率不同

---

4.5 多Agent协作架构

核心题1：多Agent系统相比单Agent有什么优势？适用哪些场景？

背诵要点

核心优势：

1. 专业分工：每个Agent专注一个领域，专业度更高，输出质量更好
2. 效率提升：无依赖的子任务可并行处理，缩短整体耗时
3. 降低幻觉：多Agent交叉验证、互相评审，提升结果准确性
4. 拆解复杂任务：把复杂大任务拆分为小任务，降低单Agent难度，提升成功率

典型适用场景：

1. 长流程流水线任务：调研→分析→写作→校对
2. 多领域专业任务：需要不同领域知识协同完成
3. 高准确率要求场景：多Agent辩论评审、交叉校验
4. 大规模并行任务：批量处理多份同类任务

核心题2：常见的多Agent协作模式有哪些？

背诵要点

四种经典模式，适配不同场景：

1. 流水线模式
   • 按任务阶段分工，顺序执行，前一个Agent的输出是后一个的输入
   • 适合：标准化、流程固定的任务，如内容生产流水线
2. 主从调度模式
   • 一个总管Agent统筹调度多个专业子Agent，负责分配任务、整合结果、把控全局
   • 适合：复杂开放任务，场景多变，需要动态分配工作
3. 辩论评审模式
   • 多个Agent分别输出方案，互相评审、质疑、迭代优化，最后输出最优结果
   • 适合：高决策质量、低容错的场景，如方案评审、风险评估
4. 自由协作模式
   • Agent之间平等通信，自主协商分工，自发协作
   • 适合：科研探索、创意类场景，灵活性最高但可控性最差

核心题3：多Agent之间怎么通信？怎么解决信息同步问题？

背诵要点

主流通信方式：

1. 共享状态模式：通过统一的全局状态存储共享信息，所有Agent读写同一份状态
2. 消息传递模式：通过消息队列或直接调用传递信息，Agent间点对点通信
3. 协调者中转模式：由调度Agent统一收发信息，所有子Agent只和调度者交互，避免点对点混乱

信息同步方案：

1. 全局状态唯一数据源，所有变更都通过统一入口更新
2. 版本号机制，防止并发写冲突，乐观锁控制
3. 关键资源操作加分布式锁，避免并发修改
4. 事件广播机制，状态变更后主动通知相关Agent

高频追问

1. 怎么避免多Agent沟通成本过高、效率反而下降？

   • 明确职责边界，避免职责重叠和重复劳动
   • 统一调度器，避免点对点的混乱通信
   • 标准化信息格式，减少理解和对齐成本
   • 控制Agent数量，不是越多越好，简单任务单Agent更高效
   • 减少不必要的交互次数，一次传递完整信息

2. 多个Agent意见不一致时怎么裁决？

   • 设置主Agent做最终决策，负责制衡和拍板
   • 投票制，多数意见胜出，适合评审类场景
   • 引入专门的评审Agent，独立做最终裁决
   • 高风险、高重要性场景，最终提交人工决策

3. 多Agent系统的常见坑有哪些？

   • 通信开销大，交互轮次多，成本和耗时飙升
   • 职责不清，互相推诿或重复工作
   • 错误传导，一个Agent出错，后续全部跑偏
   • 调试难度大，链路长问题难定位
   • 过度设计，简单问题用多Agent，反而更复杂

---

4.6 Agent工程化落地与性能优化

核心题1：生产级Agent为什么需要消息队列？解决什么核心痛点？

背诵要点

• 核心解决：同步执行用户等待久、长耗时任务阻塞线程、系统耦合度高的问题
• 具体价值：
  1. 异步解耦：用户提交任务立即返回处理中，后台异步执行，彻底告别无效等待
  2. 削峰填谷：突发流量缓冲排队，避免瞬间打垮大模型和下游服务
  3. 可靠重试：任务失败自动重试，提升任务成功率
  4. 组件解耦：Agent和下游工具通过队列解耦，可独立迭代扩容

核心题2：工作流编排工具和Agent框架是什么关系？什么时候需要？

背诵要点

• 关系：互补而非替代。Agent框架负责智能决策、推理逻辑；工作流编排负责任务的可靠执行
• 工作流核心能力：自动重试、超时控制、断点恢复、分布式调度、持久化执行
• 需要引入工作流的场景：
  1. 长耗时、多步骤的生产级任务，需要高可靠性
  2. 需要断点续跑、中断恢复的任务
  3. 跨系统、多服务协同的复杂流程
  4. 需要定时触发、延迟执行的任务
• 典型选型：Temporal、XXL-JOB、PowerJob，轻量场景也可用LangGraph替代部分能力

核心题3：Agent全链路耗时怎么优化？

背诵要点

分层优化，从用户感知到系统吞吐全面提升：

1. 模型层
   • 分级模型路由，简单任务用小模型
   • 流式输出（SSE），首字快速返回，降低用户感知等待
   • 推理加速框架提升吞吐
2. 工具层
   • 工具结果缓存，高频调用直接返回
   • 无依赖工具并行调用，缩短总耗时
   • 优化第三方接口超时，就近部署
3. 架构层
   • 异步化非关键步骤，先返回再处理
   • 进度实时推送，降低用户等待焦虑
   • 减少网络传输，服务同可用区部署
4. 产品层
   • 执行过程可视化，展示当前步骤，提升体验

核心题4：Agent的容灾降级体系怎么设计？

背诵要点

五层兜底，保障服务高可用：

1. 模型降级：主模型不可用、超时、限流时，自动切换备用模型
2. 工具降级：核心工具故障时，切换备用工具或降级为纯模型回答
3. 流量削峰：高并发时限流排队，非核心功能临时关闭
4. 熔断机制：连续失败触发熔断，快速返回失败，避免雪崩效应
5. 兜底回复：极端故障场景，返回预设兜底话术，引导用户稍后重试

高频追问

1. Agent任务执行超时怎么处理？

   • 设置单步超时和总任务超时双重阈值
   • 超时后触发重试，重试失败转降级方案
   • 记录超时异常，用于后续优化
   • 主动通知用户任务状态，避免无响应的体验
   • 长耗时任务用异步+回调模式，不阻塞用户

2. 生产环境监控Agent的核心指标有哪些？

   • 效果类：任务成功率、工具调用准确率、异常率、死循环发生率
   • 性能类：平均任务耗时、首响应时间、Token消耗速度
   • 资源类：模型QPS、线程池水位、消息队列堆积量
   • 成本类：单次任务成本、日总Token消耗、工具调用费用
   • 安全类：风险操作拦截率、越权尝试次数

3. 大模型API限流时怎么应对？

   • 消息队列削峰，任务排队异步执行
   • 降级策略：简单任务切换为小模型处理
   • 触发限流时返回排队状态给用户，告知预计等待时间
   • 配置多厂商备用模型池，分摊流量
   • 配额预警，快达上限时提前降级

---

4.7 安全合规与人在回路

核心题1：Agent调用工具有哪些安全风险？怎么分层防控？

背诵要点

四大核心风险：越权操作、恶意代码执行、数据泄露、误操作产生业务损失

五层防控架构：

1. 权限层：最小权限原则
   • Agent只分配完成任务必需的最小权限，杜绝过度授权
   • 不同业务线、不同角色的Agent权限隔离
2. 执行层：沙箱隔离
   • 代码执行类工具放在Docker/Wasm沙箱中运行，限制资源、禁止网络访问
   • 敏感操作环境隔离，不触碰生产核心数据
3. 校验层：参数与行为校验
   • 工具执行前校验参数合法性，过滤恶意内容
   • 高危操作自动识别拦截
4. 审计层：全链路留痕
   • 所有工具调用全量日志记录，支持完整回溯审计
   • 操作人、操作时间、入参出参完整记录
5. 人工层：高危操作人在回路
   • 高风险操作必须人工确认后才能执行

核心题2：什么是人在回路（Human-in-the-Loop）？哪些场景必须加？

背诵要点

• 定义：高风险环节暂停Agent执行，等待人工确认通过后再继续执行
• 核心价值：平衡自动化效率与风险，降低Agent误操作带来的损失

必须加人在回路的场景：

1. 产生真实业务副作用：发送正式邮件、修改生产数据、删除资源、执行支付
2. 高风险决策：合规审批、客户投诉回复、对外正式公告发布
3. 低置信度场景：Agent判断不确定、首次执行的新类型任务
4. 涉及敏感数据、用户隐私的操作

核心题3：怎么防御Prompt注入攻击，诱导Agent执行恶意工具？

背诵要点

分层防御，多重兜底：

1. 系统Prompt加固
   • 明确指令优先级，禁止用户指令覆盖系统规则
   • 强调安全边界和禁止行为
2. 输入检测
   • 用户输入做注入检测，过滤恶意指令、越狱话术
   • 对外部工具返回的内容也做安全校验，防止间接注入
3. 工具白名单
   • Agent只能调用预定义的白名单工具，禁止执行未知操作
   • 工具本身有权限边界，就算被调用也无法越权
4. 输出校验
   • 工具调用前做二次校验，判断是否符合当前任务目标
   • 异常调用自动拦截，不执行
5. 权限兜底
   • 工具侧严格的权限控制，是最后一道防线

核心题4：代码执行沙箱有哪些方案？怎么选型？

背诵要点

三种主流方案，各有适用场景：

1. Docker容器沙箱
   • 优势：隔离彻底，可限制CPU、内存、网络、磁盘
   • 劣势：启动慢、资源占用高
   • 适合：重任务、长时间运行、对隔离要求高的场景
2. Wasm沙箱
   • 优势：启动极快、资源占用低、安全性好
   • 劣势：支持的语言和能力有限
   • 适合：轻量代码执行、短任务、高并发场景
3. Serverless函数
   • 优势：天然隔离、免运维、弹性扩容
   • 劣势：冷启动、成本较高
   • 适合：波动大、调用频率不固定的场景

高频追问

1. Agent生成的SQL怎么防止删库、拖库？

   • 数据库账号只给只读权限，禁止写操作
   • SQL语法白名单校验，禁止DROP、DELETE、UPDATE等危险语句
   • 限制查询行数和执行超时，防止全表扫描拖库
   • 高危查询执行前必须人工确认
   • 走专用只读从库，不碰主库，避免影响业务

2. 只靠Prompt做安全约束为什么不行？

   • 大模型存在指令逃逸风险，Prompt注入可以绕过约束
   • 非确定性输出，无法100%保证遵守规则
   • 工具侧如果没有权限限制，一旦被调用就会造成损失
   • 核心结论：Prompt安全只能做辅助，系统层权限和校验才是底线

3. 数据合规方面需要注意什么？

   • 国内落地遵守《数据安全法》《个人信息保护法》
   • 涉及个人信息的场景，做好脱敏和授权
   • 调用海外大模型要注意数据出境合规风险
   • 敏感数据优先用私有化部署的国产模型
   • 全链路数据加密，访问留痕可审计

---

4.8 Agent评估体系

核心题1：Agent评估和传统软件、RAG评估有什么区别？

背诵要点

• 传统软件：输出确定，用单元测试、断言校验，标准明确
• RAG评估：评估召回准确率、答案相关性，输出相对固定，链路短
• Agent评估：输出非确定性、过程多步可变、路径不唯一，核心评估端到端任务完成度和过程合理性
• Agent评估的难点：成功路径不唯一、多步误差传导、任务成功标准难量化、成本更高

核心题2：Agent评估的核心指标有哪些？

背诵要点

五大维度全面衡量：

1. 效果指标
   • 端到端任务成功率、答案准确率、幻觉率
   • 工具调用准确率、规划合理性
2. 过程指标
   • 平均执行步数、无效调用占比
   • 异常发生率、死循环发生率
   • 自我修正成功率
3. 性能指标
   • 任务平均耗时、首响应延迟
   • 系统吞吐量、并发能力
4. 成本指标
   • 单次任务Token消耗、平均成本
   • 工具调用成本、基础设施成本
5. 安全指标
   • 越权操作率、风险操作拦截率
   • 注入攻击防御成功率

核心题3：怎么自动化评估Agent的任务效果？

背诵要点

「规则校验 + LLM-as-Judge」结合的方案：

1. 构建标准化测试用例集
   • 覆盖正常场景、异常场景、边界场景、对抗场景
   • 每个用例明确任务目标和成功标准
2. 自动化执行
   • 批量运行所有测试用例，记录完整执行轨迹
   • 每次代码、Prompt、模型变更后自动跑回归
3. 规则层校验
   • 校验工具调用是否正确、参数是否合法
   • 校验是否越权、是否超出任务边界
   • 校验输出格式、关键信息是否符合要求
4. 大模型评委
   • 用更强的大模型做评委，从任务完成度、逻辑合理性、信息准确性等维度打分
5. 结果分析
   • 统计各项指标，生成版本对比报告
   • 定位失败case，归因分类，指导优化

高频追问

1. LLM-as-Judge本身有偏见、不稳定怎么办？

   • 用更强的模型做评委，提升可靠性
   • 多模型交叉评测，取综合结果
   • 制定详细的打分标准和参考示例，减少主观偏差
   • 人工抽检校准，定期调整打分Prompt
   • 关键指标用规则校验兜底，不完全依赖大模型

2. 任务成功率一直上不去，一般从哪些方向排查？

   • 先看工具描述：工具描述是否清晰，模型是否理解能力和边界
   • 再看规划能力：任务拆解是否合理，有没有明显的规划错误
   • 再看异常处理：遇到错误是否能自我修正，还是直接卡死
   • 再看记忆和上下文：信息是否完整，有没有关键信息丢失
   • 最后看模型能力：是不是模型能力不足以支撑复杂任务

3. 评估成本太高怎么办？

   • 分级测试：核心场景全量跑，边缘场景抽样跑
   • 小模型初筛：先用小模型快速初评，有问题的再用大模型复评
   • 缓存结果：相同用例相同版本不重复评测
   • 重点回归：只跑变更影响到的相关用例，不全量跑

---

4.9 实战场景设计题

核心题1：Agent执行任务陷入死循环，怎么检测和处理？

背诵要点

检测手段：

1. 硬限制：设置最大执行步数，超过强制终止，是最后一道防线
2. 重复检测：相同工具+相同参数连续调用N次，判定为死循环
3. 无进展检测：连续多轮任务状态无推进、结果无新信息
4. 超时检测：总任务超时、单步骤超时

处理方案：

1. 触发自我反思：注入提示，让Agent复盘问题，重新规划路径
2. 引导干预：主动提示更换工具、更换方法，跳出循环
3. 强制终止：多次尝试无效后，强制终止任务，返回失败原因
4. 转人工处理：复杂场景提交人工介入
5. 沉淀bad case：记录循环原因，用于后续优化Prompt、工具描述

核心题2：设计一个自动数据分析Agent，核心架构是什么？

背诵要点

五层标准架构：

1. 交互层：接收用户自然语言需求，流式返回执行过程和最终结果，支持图表、文件导出
2. 规划层：理解分析需求，拆解为数据提取、数据清洗、分析计算、可视化等子步骤
3. 工具层：SQL查询工具、Python代码执行沙箱、图表生成工具、文件导出工具
4. 记忆层：保存分析上下文、历史分析经验、数据元信息
5. 安全层：数据权限过滤、代码沙箱隔离、高危操作人工确认

• 关键设计点：代码执行必须沙箱化，数据访问严格权限控制，分析过程可追溯

核心题3：设计一个智能客服Agent，怎么平衡自动化和人工介入？

背诵要点

分层处理机制，逐级升级：

1. 第一层：简单问题全自动
   • FAQ匹配、知识库问答，Agent直接回答
   • 常见业务查询，调用系统工具自主处理
2. 第二层：复杂问题辅助处理
   • 复杂业务问题，Agent调用业务工具查询信息，自主处理
   • 低置信度时主动确认信息
3. 第三层：自动转人工
   • 触发条件：用户明确要求人工、连续2轮未解决、用户负面情绪强烈、超出处理权限
   • 转人工时附带完整上下文和历史记录，减少人工重复询问
4. 第四层：人工反馈沉淀
   • 人工处理的问题，自动沉淀到知识库，优化Agent能力
   • 持续迭代，逐步提升自动化率

高频追问

1. 从零搭建企业级Agent平台，整体架构怎么设计？

   • 接入层：API网关、鉴权、限流、SSE流式输出、前端交互
   • 编排层：Agent运行时、状态管理、工具调度、工作流引擎
   • 能力层：模型网关、向量检索、工具市场、记忆服务、权限控制
   • 基建层：消息队列、缓存、数据库、可观测性、日志监控
   • 运营层：评估体系、反馈闭环、Prompt管理、数据分析

2. Agent怎么和现有业务系统集成？有哪些难点？

   • 集成方式：API对接、数据库对接、前端嵌入、MCP标准协议接入
   • 核心难点：权限体系打通、数据安全、业务系统稳定性影响、旧系统无API
   • 落地原则：低侵入、可降级、可审计、不影响主业务流程
   • 优先从读操作、查询类场景切入，再逐步扩展到写操作

---

4.10 前沿趋势

核心题1：什么是端云协同Agent？有什么优势？

背诵要点

• 核心架构：端侧Agent + 云端Agent混合协作
  • 端侧：处理日常交互、简单任务、敏感数据计算、系统级工具调用
  • 云端：负责复杂推理、大规模知识检索、模型微调、长期记忆同步
• 核心优势：
  1. 极低延迟：本地推理响应快，无需等待网络传输
  2. 隐私安全：敏感数据完全不出设备，合规性强
  3. 离线可用：无网络环境也能完成基础任务
  4. 成本最优：简单任务本地处理，复杂任务上云，降低云端成本
• 适用场景：消费级产品、移动端、IoT、车载等端设备场景

核心题2：多模态原生Agent和传统Agent有什么区别？

背诵要点

• 传统Agent：文本大脑 + 多模态插件，先把图片/音频转文本再推理，信息损失大
• 多模态原生Agent：在统一特征空间中同时处理文本、图像、音频、视频，多模态平等参与推理
• 核心能力升级：
  1. 视觉思维链：像人类一样逐步分析视觉内容，推理更准确
  2. GUI原生操作：直接看懂软件界面，通过模拟键鼠完成跨应用操作，不需要对方提供API
  3. 多模态输出：同时生成文字、图片、语音等多类型结果
• 落地场景：工业质检、UI自动化测试、智能办公、视频内容理解等

核心题3：自主进化Agent的核心特征是什么？

背诵要点

从被动执行者向主动思考者演进，四大核心特征：

1. 自主任务拆解：用户只给高层目标，自动拆分子步骤、选择工具、规划路径
2. 自我反思修正：执行中自动校验结果，发现错误自主回溯修正，不需要人工干预
3. 经验沉淀复用：成功完成的任务自动沉淀为经验，同类任务直接复用最优路径，越用越高效
4. 自适应规划：根据环境变化、工具返回结果，动态调整执行计划，不死板执行初始方案

高频追问

1. 未来1-2年Agent技术的核心演进方向是什么？

   • 标准化：MCP等协议普及，工具生态标准化，适配成本大幅降低
   • 工程化：可观测性、评估体系、安全体系逐步成熟，生产落地门槛降低
   • 端侧化：端侧模型能力提升，端云协同成为主流部署形态
   • 多模态：从文本Agent走向原生多模态Agent，能力边界大幅拓展
   • 专业化：从通用Agent走向垂直领域深度优化的行业Agent

2. 多Agent协作未来的发展趋势是什么？

   • 协作协议标准化：跨框架、跨厂商的Agent可以直接互相协作
   • 角色动态化：按需动态生成Agent，任务完成后释放，资源利用率更高
   • 托管化：云厂商提供多Agent即服务，开发者只需要实现业务逻辑
   • 人机协同：人和多Agent无缝协作，各自发挥优势