1. 这道题到底在考什么从“会调API”到“会做规划”的分水岭面到“Agent 怎么做规划”这道题的时候很多候选人第一反应是背概念ReAct、Plan-and-Execute、Tree of Thoughts、Reflection一口气能报出七八个名词。但只要追问一句“那你打算怎么落地”场面立刻冷下来。我面过不少人也被人面过这道题真正筛掉的不是不懂名词的人而是没想清楚“规划”在工程上到底解决什么问题的人。先把话说透Agent 的规划本质上是在不确定环境里把一个大目标拆成可执行、可验证、可回滚的小步骤并且在执行过程中根据反馈动态调整。它和传统工作流编排最大的区别在于——工作流的路径是人写死的Agent 的路径是模型在运行时自己生成的。这个“自己生成”就带来了三个绕不开的难题拆得对不对、执行偏没偏、偏了怎么拉回来。为什么这道题淘汰率这么高因为它同时考察四层能力缺一层就露馅概念层知不知道主流规划范式的区别和适用边界设计层能不能针对具体任务选对范式而不是无脑上最复杂的工程层上下文怎么管、状态怎么存、失败怎么重试、成本怎么控判断层知不知道该在哪里设人工兜底哪里必须加校验。大多数人卡在第二层和第三层之间——概念能说一到“你这个 Planner 的输出格式长什么样、解析失败怎么办”就答不上来。下面我按自己实际做项目的思路把这道题从头到尾拆一遍。你不管是准备面试还是真要做 Agent都能直接拿去用。2. 规划范式的选择不是越复杂越好而是匹配任务的不确定性面试里最常见的失分点是一上来就吹“我用 Tree of Thoughts 做规划”。听起来高级但 ToT 的 token 消耗是线性的几倍甚至几十倍绝大多数业务场景根本扛不住。选范式之前先问自己一个问题这个任务的步骤是相对确定的还是高度发散的2.1 四类主流范式的适用边界我把常见的规划方式按“确定性”和“成本”两个维度整理了一下这张表建议直接记在脑子里范式核心思路适合场景主要代价单次规划Plan-and-Execute先一次性生成完整步骤列表再逐步执行步骤可预判、流程稳定的任务环境突变时整条计划作废边想边做ReAct每步都“思考-行动-观察”循环需要频繁与环境交互、探索性任务步数多时上下文膨胀快反思迭代Reflection执行后自我批判修正计划再执行有明确成功标准、可自动评估的任务需要可靠的评估信号树状搜索ToT / LATS多分支探索回溯选最优路径解空间大、需要试错的推理任务成本高、延迟大选型的核心逻辑是任务越确定越往“单次规划”靠任务越发散越往“边想边做反思”靠只有当你真的需要在一棵决策树里回溯时才上树状搜索。我见过太多项目为了“显得智能”硬上 ToT结果一个简单查询要跑十几秒、烧掉几万 token最后还不如一个写死的流程稳。2.2 一个反直觉的结论混合范式往往才是最优解真实项目里纯用某一种范式几乎都会翻车。我目前最常用的结构是**“粗规划 细执行 局部反思”**粗规划用一次 LLM 调用把任务拆成 3~7 个高层里程碑Plan-and-Execute 的思路这层不追求细节只定大方向细执行每个里程碑内部用 ReAct 循环边做边看环境反馈局部反思只在某个里程碑失败或结果异常时触发 Reflection而不是每步都反思。这么设计的原因很实在粗规划用一次调用锁定了全局方向避免 ReAct 走偏细执行保留了灵活性反思只在必要时触发把成本压下来。面试时如果你能说出“我为什么不在每一步都反思”比背十个范式名都加分——因为这说明你考虑过成本。2.3 面试官真正想听的“选型理由”当被问到“你怎么选”别只给结论要给判断链路。我通常这么答先看任务的可逆性——如果一步做错代价很高比如转账、删数据我会倾向单次规划加人工确认把不确定性前置如果一步做错可以重来比如搜索、草稿生成我会用 ReAct 让它大胆试。再看评估信号是否可得——如果我能自动判断结果对不对就加 Reflection判断不了反思就是自嗨不如不加。这段话之所以有效是因为它把“选型”从“我喜欢哪个”变成了“任务约束决定哪个”这是工程思维和背题思维的分水岭。3. 把规划拆成可落地的四步目标解析、任务分解、执行调度、动态修正光说范式还是虚的面试官接下来一定会问“那你具体怎么实现”。我一般把它拆成四个环节讲每个环节都有明确的输入输出和失败处理。这套结构我在好几个项目里复用稳定性和可解释性都不错。3.1 目标解析先把“模糊需求”翻译成“可判定目标”这一步最容易被跳过但恰恰是规划失败的根源。用户说“帮我分析一下这份销售数据”这句话里没有成功标准。如果直接丢给 Planner它拆出来的步骤大概率是散的。我的做法是先做一次目标澄清产出一个结构化的目标描述至少包含三要素最终交付物是一份报告、一个图表、还是一段结论成功判据怎么算做完了比如“报告包含同比、环比、Top5 品类”约束条件时间范围、数据源、格式要求、不能做什么。{ goal: 分析某季度销售数据并输出结论, deliverable: markdown 报告, success_criteria: [含同比环比, 含Top5品类, 结论有数据支撑], constraints: [仅用给定数据源, 不臆造数字] }这个结构化的目标就是后面所有规划的“锚”。没有它Planner 就是在雾里开车。面试时主动提这一步能立刻把你和只会说“让 LLM 拆解任务”的人区分开。3.2 任务分解颗粒度控制在“一次能验证”的粒度任务分解最容易犯的错是拆得太粗或太细。太粗执行时还是要现想太细步骤爆炸、上下文塞不下。我的经验法则是每个子任务的产出应该是一个可以被独立验证的中间结果。比如“分析销售数据”可以拆成读取并清洗数据 → 产出干净的数据表计算同比环比 → 产出对比数值找出 Top5 品类 → 产出排序列表汇总成报告 → 产出markdown 文本每一步都有明确产出且产出可以被检查。这里有个实操细节让 Planner 输出结构化的步骤列表而不是自然语言段落。自然语言段落解析起来极其脆弱模型稍微换个说法你的解析器就崩了。{ steps: [ {id: 1, action: load_and_clean, input: raw_data, output: clean_table, depends_on: []}, {id: 2, action: calc_yoy_mom, input: clean_table, output: comparison, depends_on: [1]}, {id: 3, action: top_categories, input: clean_table, output: top5, depends_on: [1]}, {id: 4, action: compose_report, input: [comparison, top5], output: report, depends_on: [2, 3]} ] }注意depends_on字段——它让步骤之间形成有向无环图而不是一条直线。这样第 2、3 步可以并行第 4 步等它们都完成。能识别并行机会的规划才是真正省时间的规划这一点很多人想不到。3.3 执行调度状态机比“for 循环”靠谱得多拿到步骤列表后最朴素的实现是写个 for 循环挨个跑。但真实场景里步骤会失败、会超时、会产出不符合预期的结果for 循环根本处理不了。我一般用一个轻量状态机来调度每个步骤有状态pending / running / success / failed / skipped只有依赖全部success的步骤才能进入running失败的步骤根据策略决定是重试、跳过还是终止整个计划def schedule(steps, state): while not all_done(state): ready [s for s in steps if state[s.id] pending and all(state[d] success for d in s.depends_on)] for s in ready: state[s.id] running result execute(s) state[s.id] success if validate(s, result) else failed if state[s.id] failed: handle_failure(s, state)这段伪代码的关键在validate——每个步骤执行完必须校验产出不能默认它成功了。校验可以是规则字段是否齐全、可以是另一个 LLM 调用结果是否合理也可以是断言。没有校验的 Agent等于闭着眼睛往前冲。3.4 动态修正计划赶不上变化时的三条退路执行到一半发现计划不对是常态。我一般准备三条退路按代价从低到高局部重试单步失败换个参数或换个工具再试一次局部重规划某步反复失败让 Planner 只重写这一步及其后续前面的成果保留全局重规划环境发生根本变化比如数据源没了整条计划推倒重来。这里有个血泪教训重规划一定要带上“已经完成了什么”的上下文。早期我做重规划时直接把原始目标丢回去让它重来结果它把已经做完的步骤又做了一遍浪费大量 token 还产生冲突。正确做法是把当前状态摘要一起喂进去明确告诉它“1、2 已完成从第 3 步开始重来”。4. 上下文与状态管理规划能不能跑长全看这一层很多人规划逻辑写得挺漂亮一跑长任务就崩问题几乎都出在上下文管理上。Agent 每执行一步都会产生新的观察结果如果无脑往上下文里塞几十步之后要么超长、要么关键信息被淹没。这一层做不好前面所有规划都是空中楼阁。4.1 上下文分层把“必须记住的”和“可以丢的”分开我的做法是把上下文分成三层每层有不同的保留策略持久层目标、成功判据、约束条件、已完成步骤的结论摘要。这层永远保留且要精简。工作层当前步骤的详细输入输出、最近几步的观察结果。这层滚动保留最近 N 步。临时层工具返回的原始大块数据比如整个表格。这层用完即弃只留摘要。这样设计的好处是无论任务跑多少步持久层的大小基本恒定工作层有上限临时层不累积。上下文不会随步数线性膨胀这是长任务能跑下去的前提。4.2 摘要压缩什么时候压、压什么、压多狠工作层滚动到一定步数后需要把旧内容压缩成摘要。这里有几个实操要点压缩时机不要等上下文快满了才压我一般在用到 60%~70% 窗口时就触发留出余量压缩内容只压“结论性信息”比如“第 3 步得到 Top5 品类为 A/B/C/D/E”而不是把原始数据也压进去压缩方式用一次独立的 LLM 调用做摘要prompt 里明确要求“保留数值、结论、未解决的问题丢弃过程细节”。注意摘要这一步本身也会失败或失真。我的做法是摘要生成后做一次校验——把摘要和原始目标一起喂给模型问它“基于这个摘要能否继续完成任务”答否就重新摘要。多花一次调用但能避免后面整条计划跑偏。4.3 状态持久化崩溃了要能接着跑Agent 跑长任务中途进程挂掉、超时、被中断都是常事。如果状态只在内存里一崩全没前面烧的 token 全白费。所以状态必须落盘。我一般用一个简单的 JSON 或 SQLite 存每个步骤的状态和产出{ task_id: abc123, goal: {...}, steps: [...], state: {1: success, 2: success, 3: running}, artifacts: {1: clean_table_ref, 2: comparison_ref} }恢复时读这个文件从最后一个未完成步骤继续。这个设计在面试里是加分项因为它体现了“我考虑过真实运行环境”而不是只想着 happy path。5. 失败处理与人工兜底规划系统的“安全气囊”规划再聪明也会遇到搞不定的情况。一个成熟的 Agent 规划系统必须想清楚“什么时候该放弃、什么时候该找人”。这一层是区分玩具和产品的关键也是面试里最能体现工程成熟度的地方。5.1 失败分类先搞清楚是哪种失败不同类型的失败处理方式完全不同。我一般分四类失败类型典型表现处理策略工具失败API 超时、返回错误码重试 退避换备用工具解析失败模型输出格式不对重新生成加格式约束逻辑失败步骤执行了但结果不对触发反思局部重规划目标失败任务本身无法完成终止并上报请求人工介入把失败分类是为了避免用同一种方式处理所有问题。我见过有人所有失败都无脑重试三次结果逻辑失败重试一百次也没用纯烧钱。5.2 重试的边界什么时候必须停重试要有上限而且上限要分维度设单步重试上限同一个步骤最多重试 2~3 次总步数上限整个任务最多执行 N 步防止无限循环总成本上限token 或调用次数超过阈值就熔断时间上限超过预期时长就停。这四个上限缺一不可。我踩过的坑是只设了单步重试上限结果 Agent 在“重规划-失败-再重规划”之间来回横跳单步都没超限但整体跑了半小时。全局熔断比单步限制更重要。5.3 人工兜底把“不确定”交给人而不是硬扛有些决策 Agent 不该自己做比如涉及资金、删除、对外发送。我的原则是不可逆操作、高代价操作、目标模糊的操作一律设人工确认点。具体做法是在计划里标记“需要确认”的步骤执行到这类步骤时暂停把当前状态和待确认内容推给人等人确认后再继续。这样既保留了自动化的效率又把风险控制住了。面试时如果你能主动提“我会在哪里设人工确认”面试官对你的信任度会明显上升——因为这说明你知道 Agent 的能力边界。6. 面试现场怎么答一套能拿高分的表达框架前面讲的是“怎么做”最后说说“怎么答”。这道题是开放题没有标准答案但有一套能体现你思维深度的表达顺序。我按这个顺序答反馈一直不错。6.1 先反问把题目边界问清楚别急着答先问清楚场景。我通常问三个问题这个 Agent 面对的任务是确定性的还是探索性的有没有自动评估结果对错的手段对延迟和成本有没有硬约束这三个问题一问面试官就知道你是做过真东西的。而且答案会直接决定你后面选哪个范式——先问后答比上来就背概念强十倍。6.2 用“分层”结构组织回答回答时别平铺直叙用分层结构范式层我选什么范式为什么结构层目标解析、任务分解、执行调度、动态修正怎么设计工程层上下文、状态、失败处理怎么落地边界层哪里设人工兜底哪里熔断。每层讲一两句核心重点讲你踩过的坑和取舍。面试官想听的不是“我知道什么”而是“我判断过什么”。6.3 主动暴露取舍而不是只讲优点最后一个小技巧主动说出你方案的缺点。比如“这套方案在步骤超过 20 步时上下文管理会变复杂我目前的处理是……”。主动暴露边界反而显得你对自己的方案有清醒认知。只讲优点的回答听起来像背的讲得出缺点的才是真做过。我在实际项目里的体会是Agent 规划这件事难的不是让它“能跑”而是让它“跑得稳、跑得省、跑得可解释”。面试考的就是你有没有从“能跑”往“跑得稳”想过。把上面这套思路理清楚这道题基本就稳了。