百度 Agent 算法岗一二面面经：Agent 架构、上下文管理与 Skill 设计

《面试题目》

一面

1. Agent 的核心组成模块有哪些？主流 Agent 框架有哪些？
2. 简述 ReAct、Plan-and-Execute 机制的区别与适用场景，还知道哪些规划算法？
3. 工程场景：Agent 拥有海量工具、技能时，如何解决 Token 爆炸、工具乱选、检索慢、调用不准等问题？
4. 什么是 Agentic RL？为什么 Agent 需要引入强化学习优化？
5. Agent 如何做全方位评测？除最终结果外还有哪些评估维度？
6. 单 Agent 与多 Agent 的差异、适用场景是什么？
7. Agent 上下文溢出如何解决？常见的上下文管理方案有哪些？
8. 手撕：翻转整数。

二面

9. 是否阅读过 OpenClaw、Claude Code 的源码？核心收获是什么？
10. 对比两者记忆机制、上下文管理机制的实现差异。
11. 工具数量过多为何会导致错选？对应的优化方案是什么？
12. 简述自定义 Skill 的结构，你开发过哪些 Skill 能力？
13. 请设计 Agent 完成「预订明日上海机票」的完整执行链路。
14. Agent 任务停滞、重复调用同一工具、无法推进任务时，如何处理异常？
15. 手撕：单词拆分。

《参考解析》

Agent 的核心模块与主流框架：先把边界说清楚。 一个能用的 Agent 至少要有四块：负责决策的模型（Planner）、可调用的工具与技能集合（Tool / Skill）、承载历史与知识的状态（Memory / Context）、以及驱动它们循环的执行器（Runtime / Loop）。框架层面，LangGraph 把流程建模成图，节点是动作、边是转移条件，适合需要显式状态机和人工审批的链路；AutoGPT 式的自由循环直观但不可控；OpenAI 的 Agents SDK、Claude 官方的 Agent SDK 以及各家 MCP 客户端更强调工具协议与沙箱；如果只是做产品内的固定流程，直接用函数编排往往比引入框架更省事。回答时给一句取舍标准更显成熟：流程可枚举就用工作流，分支靠模型判断才上 Agent，因为「让模型做确定性的事」是稳定性问题的最大来源。

ReAct 与 Plan-and-Execute：一个边走边想，一个先想清楚再走。 ReAct 把「思考—行动—观察」串成一个循环，每一步都根据最新观察决定下一步，优点是灵活、能对工具返回的意外结果及时纠偏，缺点是步数一多就漂移、Token 消耗随轮次线性增长，适合探索性强、步骤短的任务。Plan-and-Execute 先产出完整计划再逐步执行，好处是全局可控、可以并行、可以给人审计划，代价是计划一旦与真实环境不符就要重规划，多一层重规划逻辑；实践中常见的是两者混合——先出粗计划，执行中按需 replan。其他规划思路还包括 Tree of Thoughts（多分支搜索加剪枝）、Reflexion（把失败轨迹写成反思再重试）、以及把工具选择交给专门的路由模型。适用场景的判据可以落到三点：任务步数是否可预估、环境反馈是否强、错了重来代价有多大。

海量工具下的四类问题：Token 爆炸、乱选、检索慢、调用不准。 它们的根因其实是同一个——把「工具全集」直接塞进上下文。常规解法分层：① 检索式工具暴露，先按意图从工具库里召回 Top-K（向量检索 + 关键词混合），只把相关的几个工具定义给模型；② 工具分层与命名收敛，用命名空间把上百个工具压成十几个「能力域」，先选域再选具体函数；③ 描述工程，参数 schema 用严格类型、枚举和示例写清楚，把容易混淆的工具用反例明确区分；④ 执行侧兜底，参数校验失败要把校验错误原文回给模型让它自纠，命中高危操作则走人工确认。工程上还有两个细节值得说：工具结果是 Token 大户，长输出应先摘要或落盘只回引用；延迟上可以把工具描述做本地缓存、并行预热，避免「检索慢」拖垮整体时延。

Agentic RL：把多步决策当成一条轨迹来优化。 传统 SFT 只教模型「这一步该怎么回」，而 Agent 的成败往往由多步序列决定，中间某一步选错工具，后面再正确也拿不到分。Agentic RL 的做法是把整条交互轨迹当样本，用任务终局（答案对不对、任务是否完成）或过程奖励（工具选择是否正确、格式是否合规）来给整条轨迹打分，再用 PPO、GRPO 这类算法更新策略；它对奖励设计的依赖比普通 RLHF 更重，因为奖励稀疏、且容易奖励 hack（比如模型学会不调用工具、直接编答案反而拿到格式分）。因此实践中常见的是：先用规则校验和可自动判定的任务构造可验证奖励，再逐步加过程奖励，并用留出集盯住「分数涨了但真实成功率没涨」这种退化。

评测、单 Agent 与多 Agent、上下文管理。 评测不能只看最终答案，至少要分四层：结果层（准确率、任务完成率、通过率）、过程层（工具调用是否为必要且最少、参数正确率、平均步数、重试率）、成本层（Token 与耗时、单位任务成本、缓存命中率）、稳定与安全层（同题多次运行的方差、越权与注入抵抗、崩溃率）。单 Agent 与多 Agent 的分界是「上下文能不能共享在一块」：单 Agent 状态一致、调试简单，但上下文容易爆、职责混杂；多 Agent 让每个子 Agent 只带自己的上下文与工具，适合角色清晰、可并行的子任务（检索、写作、审校），代价是通信协议、状态同步与失败传播都要额外设计，还容易出现「互相甩锅」式的死循环。上下文溢出的处理手段包括滚动摘要（保留近期原文、把远期压成摘要）、分层记忆（工作记忆 / 长期事实 / 检索式知识库）、结构化裁剪（丢弃中间观察、只留结论与引用）、子 Agent 隔离（把长过程放进子流程，只回传摘要），以及把大块中间产物落到工作区、上下文里只留路径。

源码阅读与 Skill、机票链路、任务停滞。 被问「读过哪些 Agent 源码」时，面试官要的是具体的机制对比而不是印象：围绕三处讲——上下文怎么装（系统提示与规则文件何时注入、超长时是压缩还是截断）、记忆怎么存（会话内的消息历史 vs 跨会话的持久记忆文件或向量库，谁负责写、什么时候写）、工具怎么管（工具注册与权限、MCP 这类协议的位置、子 Agent 怎么拿到工具）。「工具数量为何导致错选」的答案要落到注意力竞争与描述相似度上：候选过多时模型对工具描述的区分度下降，选错的概率上升，解法就是前面说的检索召回、命名分层和描述区分。自定义 Skill 的结构可以按「元信息（名称、适用场景）+ 输入输出契约 + 步骤与工具白名单 + 校验与失败处理」讲，并准备一两个你真正写过的能力。设计「预订明日上海机票」时，链路要覆盖：确认出发地与日期（缺信息先问而不是猜）、查航班（多结果排序依据）、比价与舱位约束、下单前的人机确认（支付属高危动作）、支付与出票、失败回滚与重试、最后把行程写入记忆并给出可点击的回执。任务停滞的处理是这类面试的高频追问：要有最大步数与无进展检测（连续 N 轮工具返回相同或语义重复即判停滞）、失败分类（工具报错、参数错、环境不可用）、升级策略（换工具、简化目标、回问用户），并且写清楚「什么时候认输」——观测不到成功一律记失败，不许把没做完报成做完。两道手撕都不难：翻转整数要注意 32 位溢出边界（用 long 暂存或先判再拼）、负数取模的处理；单词拆分是经典 DP，dp[i] 表示前 i 个字符可拆，枚举切分点并在字典里查，也可以用字典树剪枝优化。