滴滴 AI 研发岗一面:Agent 有几种设计模式?不能只背 5 个名字

发布时间:2026/7/28 2:33:05
滴滴 AI 研发岗一面:Agent 有几种设计模式?不能只背 5 个名字 最近互联网行业确实有点“风声鹤唳”。组里一位同事也“被广进”了出来看机会时面了滴滴的 AI 研发岗。一面面试官问了他一道 Agent 题Agent 的设计模式有几种分别适合什么业务场景这题看着像八股真正的坑却是分类口径Agent 的设计模式没有公认的固定数量。如果直接回答“有三种”或“有五种”再把 ReAct、Plan-and-Execute、Reflection、Multi-Agent 平铺在一起名词可能都对层次却乱了。更推荐的答法是按业务系统怎么推进任务来分。先给出五类常见方式再说它们分别适合什么场景。常见方式核心特点适合的业务场景Workflow确定性流程步骤、分支和规则提前写好审批、退款、批处理等路径稳定的任务ReAct根据工具刚返回的信息决定下一步异常定位、客服取证、开放式检索Plan-and-Execute先拆出主计划执行中允许调整多源分析、复杂报告、长周期任务Reflection生成后按标准检查不达标就重做代码、SQL、合规文案和分析报告质检Multi-Agent把任务交给不同专业角色需要不同工具、权限或专业背景的协作任务严格来说这五个名词不在同一层Workflow 不是自主 AgentReflection 是质检回路Multi-Agent 是组织方式。但面试官问的是“分别使用什么业务场景”把它们放在一张选型表里比纠结到底算三种还是五种更有用。真实系统也很少五选一。常见组合是Workflow 定住主干局部用 ReAct复杂任务加 Plan关键产物再用 Reflection 验收。只有分工确实带来收益时才增加多个 Agent。01Workflow路径能写清就不让 Agent 自由决定Workflow 的核心是确定性。先做什么、后做什么、什么条件走哪个分支都由开发者提前写进代码。模型可以参与其中某个节点但不拥有整条路径的控制权。例如退款处理系统依次检查订单状态、退款资格、金额上限和风险等级低风险请求自动执行超过阈值再进人工审批。模型可以帮忙识别用户意图、提取申请理由但资格判定、金额计算和真正打款仍由规则控制。这类场景要的是可预测、幂等和可审计不是模型临场发挥。审批流、批量任务、规则计算和关键状态写入默认都应从 Workflow 开始。02ReAct下一步取决于刚拿到的结果ReAct 把 Reasoning 和 Acting 交替起来模型判断下一步动作调用工具读取环境返回的 Observation再决定下一步。它不是一次把路线想完而是边取证边调整。ReAct 原始论文就是用这种交替方式把推理和外部行动接到了一起。判断一个业务是否适合 ReAct我主要看一句话没有上一步的查询结果现在就无法决定下一步。例如乘客反馈“这笔订单金额不对”。客服 Agent 可以先查订单明细如果里程和时长异常继续查计价明细如果计价正常但优惠未生效再查优惠资格和使用记录如果应付金额正确、实付金额异常转去查支付流水证据仍不完整就停止自动判断交给人工处理。这里不存在一条对所有投诉都适用的固定查询路径。每次工具返回的事实都会缩小下一步的选择范围。这就是 ReAct 的业务价值。它适合异常定位、开放式检索、动态问答和需要逐步取证的客服场景。代价也很直接调用轮数多容易兜圈子错误判断还会沿着后续步骤放大。PS不是每个 Tool-Calling Loop 都严格等同于 ReAct。现代 SDK 可以只暴露工具调用与返回结果不要求显式输出论文里的推理轨迹。这里借用的是“根据新观察选择下一步”这个核心结构。加分项ReAct 上生产还要主动限制它的行动范围。我至少会加四个限制只读工具优先、最大轮数、总成本预算、触发人工接管的条件。涉及退款、改价、封禁等写操作时模型可以给建议但不能凭一条推理链直接落库。03Plan-and-Execute任务很长要先做主计划Plan-and-Execute 先让 Planner 生成多步计划再由 Executor 逐项完成执行结果不符合预期时重新规划剩余步骤。LangChain 对这一架构的实现也包含 Planner、Executor 和 Replan而不是“计划生成后永远照着跑”。它和固定工作流的差别很关键。固定工作流的路径由开发者预先写进代码Plan-and-Execute 的计划由模型根据当前任务动态生成而且允许重排。两者也不能只按任务长短区分。ReAct 每轮决定的是下一次工具调用Plan-and-Execute 先排出一段可审查的任务计划。执行器内部仍然可以运行 ReAct只有计划失效时才回到 Planner 重排。因此“退款申请依次经过资格校验、金额计算、审批和打款”不是 Plan-and-Execute 的好例子。这些步骤明确、规则稳定直接写工作流更可靠。更合适的业务场景是生成一份城市运力异常分析报告。目标很清楚但每次分析的重点不同。Agent 可以先规划确认异常发生的城市、时段和指标拉取供需、天气、活动和交通数据找出变化最大的区域验证几个可能原因形成结论、证据和建议。执行到第三步时如果发现异常只集中在机场区域后续计划就应该收缩到航班、排队时长和机场运力而不是机械跑完原计划。适合 Plan-and-Execute 的不是“步骤固定”而是“目标稳定、任务较长、主路线可以先规划”。它常用于多源分析、复杂报告、跨系统资料整理和长周期研发任务。两三次工具调用能解决的事先生成一份长计划只会增加延迟。04Reflection要解决的是结果合不合规很多面试答案会把 Reflection 和前两种模式并列。我觉得这句话只对了一半。ReAct 和 Plan-and-Execute 解决“怎么推进任务”Reflection 解决“当前产物是否合格应该回到哪一步重做”。它可以放在最终结果之后也可以插在计划、查询或生成的中间节点但通常不单独完成业务目标。它适合什么业务得先有可检查的标准。例如 Agent 写完一份客诉处理建议后评估器检查引用的订单、计价和支付事实是否都有查询证据建议是否符合当前赔付规则有没有承诺系统无法执行的动作缺少关键证据时是否明确转人工。检查不通过再带着具体问题修改一次。这里的反馈来自证据和规则而不是让另一个模型泛泛地说“还可以写得更好”。代码生成、SQL 生成、合规文案、分析报告都适合加这一层因为测试、Schema、政策条款或事实清单能充当外部评分信号。反过来如果标准含糊、没有新证据、修改也无法验证Reflection 很容易变成两个模型互相提意见成本翻倍质量却没有稳定提升。PSReflexion 研究使用环境反馈形成可带入后续尝试的反思记忆Evaluator-Optimizer 则是“生成—评估—修改”的迭代回路。两者都处理质量问题但不是同一种实现。05Multi-Agent任务需要不同专业角色协作Multi-Agent 是把一个任务拆给多个专业 Agent分别使用它们的工具、权限或领域上下文再组合结果。每个子 Agent 内部仍然可以跑 ReAct也可以执行 Planner 分配的任务。例如一次复杂客诉同时涉及订单、计价、支付和风控证据。主 Agent 根据投诉内容决定调查项再把查询交给具备不同工具权限的专家 Agent最后统一汇总证据和结论。这就是 Multi-Agent 有收益的场景分工来自真实的专业和权限边界不是为了多创建几个 Agent。但如果查询项早就固定为订单、支付、优惠券三项普通并行工作流就够了不必创建三个会对话的 Agent。多 Agent 真正成立至少要满足一项子问题需要不同工具、权限或专业上下文子任务可以并行节省的时间大于协调成本需要多个独立视角交叉检查子任务无法在设计阶段预先写死要由编排者动态决定。PSMulti-Agent 还要说清任务所有权。主 Agent 保留最终责任、调用专家完成子任务常被称为Manager当前 Agent 把本轮后续处理交给专家 Agent常被称为Handoff。前者是“请专家帮忙”后者是“接下来由专家负责”。加分项多个 worker 可以并行查不能默认并行改。同一订单状态、同一赔付结论或同一业务对象存在共享写入时要么划清所有权要么回到单线程提交。06到底怎么选只看 5 个判断路径能提前写清吗能就用 Workflow。下一步是否依赖刚返回的信息是用 ReAct否则看是否需要先做计划。任务是否较长主路线能否提前拆出能用 Plan-and-Execute。结果有没有明确标准可检查有再加 Reflection。子任务是否需要不同工具、权限或专业背景需要才考虑 Multi-Agent。这道题真正想听的不是你能背出多少名词而是三件事能不能先说清分类口径能不能把设计模式映射到业务条件能不能知道什么时候不该让 Agent 做决定。只答 ReAct、Plan-and-Execute、Reflection是在回答“你听过什么”能讲清控制权、任务所有权和失败代价才是在回答“你能否把 Agent 放进真实业务场景里”。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】