Agent 组成与设计边界
Q:了解过 Agent 的设计范式吗?
来源:字节后端开发 Agent 一面 【淘宝闪购一面同题:Agent 有哪些模式】
新手答:“ReAct,就是边想边做。”
高手答:
主流的 Agent 设计范式有四种,适用场景不同:
1. ReAct(Reason + Act)
循环:思考 → 行动 → 观察 → 思考 → 行动 → ...每一步先推理下一步该做什么,执行后观察结果,再决定下一步。灵活,适合开放性任务,但 token 消耗大,且容易在循环中迷失方向。
2. Plan-and-Execute
先规划:任务 → 拆解成步骤列表
再执行:逐步执行,不回头修改计划先出完整计划再执行,适合流程固定的任务(如日报生成、数据 ETL)。省 token,但不灵活——中间出了预期外的情况没有修正机制。
3. 反思范式(Reflexion / Self-Refine)
生成 → 评估 → 修正 → 再生成生成结果后,用另一个 Prompt(或另一个模型)评估结果质量,发现不足后修正并重新生成。适合质量要求高的场景(代码生成、文案润色)。代价是多轮调用,延迟和成本翻倍。
4. 多 Agent 协作范式
多个角色 Agent,各负其责,通过消息协作把复杂任务拆给不同角色的 Agent——程序员、审查员、产品经理等。适合需要多视角的复杂任务。工程复杂度最高,需要解决通信、冲突、一致性等问题。
实际工程中怎么选:
任务确定性高 + 流程固定 → Plan-and-Execute
任务开放 + 需要灵活应变 → ReAct
输出质量要求极高 → Reflexion
任务复杂 + 需要多视角 → 多 Agent 协作大多数生产系统是混合范式——宏观用 Plan-and-Execute 做任务分解,微观用 ReAct 处理每个步骤,关键输出用 Reflexion 做质量检查。
差距在哪:新手只知道一种范式。高手列出了四种范式、各自的适用场景和代价,且指出生产系统通常是混合范式。面试官考的是你有没有对 Agent 设计范式的全局认知——不是只知道一种,而是知道多种,并且能说清楚什么场景用哪种。
Q:Agent 的架构设计?从系统角度来拆分
来源:阿里 AI Agent 开发一面
新手答:“用大模型接工具就行。”
高手答:
一个完整的 Agent 不是单独一个大模型就能跑,核心拆成四层:
- 任务入口层:负责接收用户问题和上下文
- 决策层:意图识别、任务拆解、规划、工具选择
- 执行层:真正去调工具、查知识库、访问服务
- 记忆与状态层:维护多轮上下文、历史执行结果和中间变量
如果做得再工程化一点,通常还要加一个校验层——模型规划出来的步骤不一定对,工具参数也可能填错,所以在执行前后都要做检查:参数合法性校验、工具返回结构校验、结果一致性校验。
Agent 正确的地方不是“能不能想”,而是“想完能不能稳定执行”。
差距在哪:新手把 Agent 等同于“大模型 + Prompt”。高手的回答展示了分层架构的思维——入口、决策、执行、记忆各司其职,还有校验层做兜底。面试官想看你脑子里有没有系统设计的概念。
Q:Agent 在学术上由哪些部分组成?
来源:字节后端开发 Agent 一面
新手答:“大模型加上工具调用。”
高手答:
按学术界的主流框架(参考 Lilian Weng 的综述),Agent 由四个核心模块组成:
Agent = LLM(大脑)+ Planning(规划)+ Memory(记忆)+ Tool Use(工具使用)- LLM(大脑):核心推理引擎,负责理解任务、生成决策。它不等于 Agent——它是 Agent 的一个组件
- Planning(规划):把复杂任务拆解成可执行的步骤序列。包括任务分解(Task Decomposition)、自我反思(Self-Reflection)、方案修正。典型方法:Chain of Thought、Tree of Thoughts、ReAct
- Memory(记忆):分短期记忆(当前上下文窗口内的信息)和长期记忆(持久化存储的历史信息、知识、用户偏好)。短期记忆就是 in-context learning,长期记忆通常靠外部存储 + 检索
- Tool Use(工具使用):调用外部 API、数据库、搜索引擎、代码执行器等。让 Agent 能做 LLM 本身做不到的事——精确计算、实时信息获取、执行操作
进阶补充:工业界还会加两个模块——Perception(感知) 处理多模态输入,Action(执行) 管理对外部环境的操作和副作用控制。
差距在哪:新手只看到了“大模型 + 工具”两个组件。高手的回答基于学术框架,把 Agent 拆成四个独立模块,每个模块有明确的职责和典型方法。面试官想确认你读过核心论文,对 Agent 有结构化的认知。
Q:如果让你设计一个 Agent 的规划器,怎么避免它每一步都重新规划,导致路径震荡?
来源:腾讯大模型应用开发二面
新手答:“加个缓存,记住之前的计划就行。”
高手答:
规划器不能每拿到一个 observation 就整体重算,不然很容易出现前一步刚决定检索、后一步又改成总结、再下一步又回去检索——整个执行路径来回抖动。
更稳的做法是把规划分成**“全局计划”和“局部调整”两层**:
- 全局计划只定义阶段目标,比如信息收集 → 证据检验 → 结果生成
- 局部调整只允许在当前阶段内微调具体动作,不回头改全局计划
另外要给 planner 一个明确的状态表示——当前子目标、已完成步骤、失败原因、剩余预算。如果没有状态约束,模型会把每次新 observation 当成全新任务来理解。
线上一般还会加**“重规划阈值”**,只有在关键前提失效、连续失败或者用户目标变化时才允许重新规划,日常微调不触发全局重规划。这样路径会稳定很多。
差距在哪:新手没有意识到路径震荡的根因——每次重规划等于丢弃之前的决策积累。高手用“全局 + 局部”两层分离解决了稳定性问题,且引入了状态表示和重规划阈值两个工程手段。面试官考的是你有没有把规划器当成一个需要工程约束的系统来设计。
Q:如果模型特别擅长生成,但不擅长严格遵守流程,你会怎么把它放进一个强约束工作流里?
来源:腾讯大模型应用开发二面
新手答:“在 Prompt 里强调让模型按步骤执行。”
高手答:
最常见的办法是把**“生成自由度”和“流程控制权”拆开**。模型只负责局部判断和内容生成,流程推进由外部状态机控制。
比如工作流规定必须先做参数校验 → 再检索知识 → 再调用工具 → 最后生成答复。模型不能跳步,能做的只是当前节点下的判断,例如“检索关键词应该怎么改写”“看了这些证据后怎么总结”。
状态机控制:参数校验 → 知识检索 → 工具调用 → 结果生成
模型负责: 每个节点内的局部判断和内容生成这样一来,模型仍然发挥语言理解优势,但不会破坏整体流程。真正线上稳定的 Agent,很多都不是纯模型自治,而是**“系统控流程,模型控局部智能”**。
差距在哪:新手试图用 Prompt 约束模型行为——这是最弱的防线。高手的回答把流程控制权从模型手里拿走,交给外部状态机,模型只在受控的节点内发挥能力。面试官考的是你理不理解“生产级 Agent = 系统控流程 + 模型控智能”这个核心设计原则。