规划
规划题常出现在“你是否做过复杂 Agent 任务”的追问里。关键不是会不会说“先拆任务”，而是知道什么时候该拆、怎么拆、拆完怎么收敛，以及什么时候根本不该上显式 Planning。
这一页最适合按“触发条件 -> 计划质量 -> 执行修正”这条线来读。先用短答版记住判断结论，再用深答版补“ReAct 和 Planning 的层级差异、过度规划的代价、重规划的检查点”，这样你在回答复杂任务题时会更像做过系统，而不是只会讲方法论。
高频题
1. 为什么 Agent 需要 Planning？
题目：模型不是已经可以边想边做了吗，为什么还要单独做计划？
面试官想听什么：你是否理解 Planning 解决的是复杂任务的全局结构问题，而不是给所有任务都加一个“看起来更高级”的步骤。
短答版：在任务复杂、步骤多、依赖关系明显时，只靠局部 ReAct 容易短视。Planning 的价值在于先建立全局任务结构，减少走一步看一步导致的反复试错和遗漏。
深答版：
展开深答版
这题的本质是解释 Planning 解决的到底是什么问题。ReAct 擅长局部闭环，适合“看到一步，做一步，再根据反馈继续”的任务；但一旦任务很长、依赖很多、失败代价高，只靠局部反应就容易短视，前面做得很积极，后面却发现顺序错了、关键依赖漏了。
Planning 的价值不是“让回答看起来更高级”，而是先把任务结构看清。它解决的是阶段划分、依赖顺序、验证节点和资源分配这些全局问题，也就是让系统知道“先做什么、后做什么、做到哪里算过关”。
工程上，Planning 会增加额外 token 和延迟，但能换来更少的盲试和返工。常见误区是把 Planning 理解成写一份漂亮提纲。你可以记成：
ReAct 管当前一步，Planning 管整条路线。追问方向：什么任务明显不值得上显式 Planning？
2. ReAct 和 Planning 的区别是什么？
题目：两者看起来都在“思考后行动”，边界到底在哪？
面试官想听什么：你能不能说清两者的职责分层，而不是把它们当成两个互斥名词。
短答版：ReAct 更偏局部闭环，每一步根据当前观察继续下一步；Planning 更偏全局视角，先把任务拆成阶段，再逐步执行和更新。复杂任务里常见的做法是先 Planning，再在子任务内部用 ReAct。
深答版：
展开深答版
这题的核心判断是，ReAct 和 Planning 的区别在“控制粒度”。ReAct 更偏局部闭环，关注的是当前观察下下一步该做什么；Planning 更偏全局控制，关注的是任务应该拆成几段、依赖怎么排、每段怎么收敛。
它们并不是互斥关系。很多成熟系统其实就是先用 Planning 搭出全局框架，再在每个子阶段内部用 ReAct 做局部推进。也就是说，一个解决“路线”，一个解决“步法”，两者是不同层级的控制机制。
工程上，如果只用 ReAct，复杂任务容易迷路；如果所有问题都先强制 Planning，系统又会变慢变重。你可以记成：
Planning 管全局结构，ReAct 管局部推进。追问方向：有没有场景是 ReAct 足够，但显式 Planning 反而浪费？
3. 一个好计划应该长什么样？
题目：如果让 Agent 先出计划，你怎么判断这个计划是好是坏？
面试官想听什么：你是否有评价计划质量的标准，而不是只看它是否“条理清楚”。
短答版：好计划应该目标清晰、阶段边界明确、依赖关系合理、可验证，而且能支持中途修正。坏计划通常表现为过细、过虚，或者根本不能映射回实际执行动作。
深答版：
展开深答版
这题本质上在看你有没有“计划质量观”。一个好计划不只是条理清楚，而是至少能回答四件事：目标是什么、阶段怎么拆、依赖关系是什么、每阶段怎么验收。没有这四件事，计划再整齐也只是表面好看。
真正的难点在粒度控制。计划过粗，会失去指导意义；计划过细，又会在执行前就把大量 token 花在未来细节上，而且环境一变就得重写。好计划通常是“足够细到能执行，足够粗到能调整”，它应该帮助执行，而不是绑死执行。
工程上，计划如果不能映射回真实动作和验证节点，就只是昂贵的装饰。你可以记成：
好计划不是写得多，而是可执行、可验证、可调整。追问方向：为什么“计划写得很漂亮”不等于“计划能执行”？
4. 计划执行过程中需要更新吗？
题目：如果执行中拿到新信息，原计划是不是就没用了？
面试官想听什么：你是否知道计划是运行时工件，而不是一次生成就永远正确的静态文档。
短答版：计划应该是可修正的，不是一次性产物。关键是控制更新粒度，只在关键假设变化、依赖失效或阶段目标偏移时重算，而不是每一步都重做全计划。
深答版：
展开深答版
这题的核心判断是，计划必须允许修正，但不能无限抖动。真实任务执行里，外部信息变化、依赖失败、阶段结果偏差都可能让原计划失效，这时继续死守旧计划，往往比更新更危险。
但反过来，也不能每走一步都重做全计划。那样系统会变成“不断计划、几乎不执行”，最后计划成本反而吞掉执行收益。所以计划更新应该发生在关键节点，比如阶段切换、关键依赖失效、目标被改写、验收不过关这些时刻。
工程上，你要找的是“稳定推进”和“动态修正”之间的平衡。常见误区是要么完全不改，要么一有波动就全盘重算。你可以记成：
计划要能改，但只在关键变化时改。追问方向：你怎么判断“该修计划”而不是“继续执行”？
5. Planning 的代价是什么？
题目：为什么不是所有复杂任务都默认加一个计划器？
面试官想听什么：你是否有成本意识，知道 Planning 不是免费午餐。
短答版：Planning 会增加额外 token 成本、响应延迟和系统复杂度，还可能产生“看上去合理但实际无效”的幻觉计划。它适合高复杂度任务，但会给简单任务引入额外负担。
深答版：
展开深答版
这题的本质是谈 Planning 的负债。显式计划不是免费午餐，它往往意味着额外模型调用、更长上下文、更高延迟以及更多中间状态要维护。如果计划质量不高，这些成本并不会换来收益，只会多生成一份看起来合理的中间产物。
所以复杂任务确实更适合 Planning，但简单任务往往直接执行更快更稳，因为计划没有提供额外信息价值。是否触发 Planning，本质上取决于任务长度、依赖复杂度、失败代价和回滚难度，而不是“感觉先计划一下比较保险”。
工程上，最常见的误区就是把 Planning 默认化。你可以记成：
Planning 的收益来自复杂任务，代价来自额外控制层。追问方向：你会用什么信号决定是否触发 Planning？
扩展题
6. 你会用什么信号触发 Planning？
题目：如果不是所有任务都要先做计划，那系统到底该根据什么信号决定触发？
面试官想听什么：你有没有可落地的触发启发式，而不是笼统说“复杂任务就触发”。
短答版：我会看四类信号：步骤数是否不可一眼完成、是否存在跨工具依赖、失败回滚成本高不高、目标是否需要阶段性验收。满足越多，越值得先 Planning。
深答版：
展开深答版
这题重点不是下定义，而是给出稳定的触发规则。真正可用的启发式通常来自任务结构，比如需要多个工具串联、前一步结果会限制后一步、存在外部信息不确定性，或者中间结果必须验收才能继续。
一个常见误判是把“问题描述很长”当成“任务很复杂”。其实有些问题虽然说得很长，但本质上一步查询就能解决；反过来，有些请求看起来很短，背后却藏着多阶段依赖和高回滚成本。是否触发 Planning，应该看任务结构，而不是字面长度。
工程上，触发阈值过低会让系统变重，过高又会让复杂任务直接裸奔。所以更稳的做法是把工具数、依赖深度、不确定性和失败代价组合成启发式，而不是只看“感觉复杂”。
追问方向：哪些信号最容易被误判，导致本来不用规划的任务被规划了？
7. 怎么避免过度规划？
题目：如果模型很喜欢先写一大段计划，你怎么防止它把时间都花在计划上？
面试官想听什么：你是否知道过度规划的常见表现，以及怎么从机制上收住。
短答版：核心是限制计划粒度和预算。计划只需要细到能指导下一阶段，不需要把所有分支都预演完；否则 token、延迟和幻觉风险都会上升。
深答版：
展开深答版
这题考的是成本控制能力。过度规划常见的表现是，模型把本来两三步能验证的事，提前扩写成十几步，还对未来分支做大量猜测。计划越长，看起来越完整，实际上往往和真实执行越脱节。
计划不是越完整越好，因为执行环境会变化，太早写死细节只会增加返工。真正有效的做法通常是收住粒度，只规划到阶段而不是动作；收住窗口，只覆盖最近一段执行区间；收住承诺，不要求模型把未知条件全部补齐。
工程上，好的系统不是一味禁止长计划，而是让计划只承担当前必要的指导职责。只要计划开始抢走执行预算，它就已经过度了。
追问方向：如果模型总是把子步骤拆得过细，你会改 prompt、改结构，还是加预算限制？
8. 重规划检查点应该放在哪里？
题目：执行长任务时，你会把“要不要重规划”的判断放在哪些节点，而不是让系统每一步都犹豫？
面试官想听什么：你能不能设计重规划检查点的节奏，而不是只会说“发现变化就更新计划”。
短答版：我通常把检查点放在阶段结束、关键依赖失败、验收未通过这三类节点。这样既能及时纠偏，又不会每走一步都触发全局评估。
深答版：
展开深答版
这题重点是检查点设计，不是泛泛谈“计划会变化”。真正稳定的做法，是把“要不要重规划”收敛到少数高价值节点，比如阶段结束、关键依赖失败、验收不过关、目标被改写这些时刻。
局部工具失败、单条结果不理想、一次轻微偏差，这些通常更适合先做局部补丁，而不是立刻拉起全局重算。只有当问题已经影响后续顺序、资源假设或阶段目标时，重规划才真正值得。
工程上，检查点放太密会让系统反复停下来评估，放太稀又会把错误带进下一阶段。所以常见做法是按阶段节奏评估，再用关键失败事件做补充。
追问方向：你会怎么定义“局部补丁还够用”和“已经必须全局重规划”的分界线？
9. 你怎么验证一个计划是可执行的？
题目：计划生成出来以后，你怎么知道它不是一份听起来对、做起来不通的假计划？
面试官想听什么：你是否把计划验证当成独立环节，而不是默认模型写出来就能执行。
短答版：我会检查三件事：每个阶段有没有明确产出、关键依赖是否能被当前工具满足、阶段完成后是否有验收信号。缺一项，这个计划就不算可执行。
深答版：
展开深答版
这题考的是计划验证意识。很多失败不是执行器不行，而是计划本身没和现实约束对齐，比如假设了不存在的工具、要求了拿不到的数据，或者阶段之间没有可验证输出。
所以计划验证不是把任务先偷偷跑一遍，而是做一致性检查：目标和步骤是否对齐、步骤和资源是否匹配、阶段是否有明确产出、完成后是否有验收信号。没有这些，计划看起来再顺，也可能一落地就断。
工程上，验证做得太重会抵消 Planning 收益，但完全不验又容易把坏计划直接送进执行。轻量、结构化的一致性检查，通常比追求“完美计划”更有价值。
追问方向：如果计划逻辑合理，但现有工具做不到，你会让模型改计划还是升级工具集？
10. Planning 和任务拆解是什么关系？
题目：很多人把 Planning 等同于任务拆解，这样说够不够？
面试官想听什么：你能不能区分“拆开”与“安排好”这两层能力。
短答版：任务拆解只是 Planning 的一部分。拆解回答的是“分成哪些块”，Planning 还要回答“先后顺序是什么、依赖怎么处理、每一块怎么验收”。
深答版：
展开深答版
这题常用来区分你有没有把概念讲透。任务拆解只是把大任务切小，回答的是“分成哪些块”；Planning 还要进一步回答“先后顺序是什么、依赖怎么处理、每块怎么验收、哪块能并行”。
所以拆解本身不等于计划。几个独立查询并列跑，也许只需要 decomposition；但一旦子块之间存在前置关系、共享资源或汇合节点，就已经进入真正的 Planning 问题。也就是说，拆开只是第一步，安排好才叫计划。
工程上，把两者混为一谈，会让系统要么过度串行化，要么误以为拆完就能跑。更稳的说法是：拆解解决粒度，Planning 解决结构。
追问方向：有没有场景只做 decomposition 就够，不值得上完整 Planning？
11. Planning 怎么支持并行分支，而不是把所有事都串行化？
题目：如果任务里有几块可以并行做，Planning 应该怎么表达，才不会把系统变成单线程？
面试官想听什么：你是否理解计划不仅决定顺序，也决定哪些地方可以并发推进。
短答版：好计划不只是排顺序，还要显式标出独立分支、汇合点和共享依赖。能并行的部分就并行，真正串行的只保留在关键路径上。
深答版：
展开深答版
这题在考你有没有“关键路径”意识。很多系统一做 Planning，就下意识把任务写成线性步骤，结果把本来独立的信息收集、候选方案评估都串行化了，白白拉长整体延迟。
但并行也不是越多越好。并行分支会增加状态合并、冲突处理和失败隔离复杂度，尤其在共享上下文或共享资源时更容易出问题。真正值得并行的，是那些彼此独立、合并规则清楚、失败不会相互污染的分支。
Planning 在这里的价值，不是把所有事排成一条线，而是提前把可并行区和必须串行的关键路径分开。计划做得好，本质上是在保护端到端效率。
追问方向：并行分支的结果不一致时，你会在计划层合并，还是交给后续决策层处理？
12. 系统什么时候应该默认直接执行，复杂了再升级到 Planning？
题目：如果你设计的是线上系统，你会不会让它先轻量执行，只有复杂度升高时再切到 Planning？
面试官想听什么：你是否理解“先执行、再升级”的运行时策略，而不是只会在入口处做一次静态判断。
短答版：会。很多请求更适合默认轻量执行，用局部观察先推进；只有在执行中暴露出依赖链变长、反复试错、阶段目标不清这些信号时，再升级到显式 Planning。
深答版：
展开深答版
这题和“什么信号触发 Planning”不一样，重点在运行时策略。入口判断再准，也很难一次看清全部复杂度，所以更实用的做法往往是先用轻模式推进一小段，把真实反馈拿到手，再决定要不要升级到显式 Planning。
这种策略适合短链路、高频请求，因为它能减少一上来就进入重流程的成本；但如果任务本身失败代价很高，或者走错一步就很难回滚，就不该赌“先试试看”。也就是说，先执行再升级，不是通用法，而是有前提的运行时策略。
工程上，系统需要平滑升档机制，比如连续局部修补仍不收敛、上下文开始跨阶段蔓延、明确依赖链已经出现时，立刻切到显式 Planning。真正成熟的系统，不是一开始就永远判断对，而是复杂度升高时能及时升档。
追问方向：从轻量执行切到 Planning 时，怎么避免把前面试出来的信息丢掉？
13. Agent 任务的一步执行应该怎么设计？
题目：如果你要把一个 Agent 的执行过程拆成“单步”，你怎么定义这一步，才不会要么太大、要么太碎？
面试官想听什么：你是否理解“一步执行”不是一次模型调用，而是一个可验证、可恢复、可继续推进的最小执行单元。
短答版：我会把一步定义成“读取当前状态和目标 -> 让模型做局部决策 -> 执行动作 -> 回填结果和状态”的完整闭环，而不是只看模型输出。一旦这一步不能形成明确产出和回填，它就不算真正完成。步长太大，出错后难定位也难回滚；步长太小，则会让系统被频繁决策和上下文切换拖慢。
深答版：
展开深答版
这题的核心不是“模型每轮说一句话算不算一步”，而是你怎么定义一个既能推进任务、又能被系统治理的执行单元。真正有工程意义的一步，至少要同时包含四件事：拿到当前状态、形成局部决策、执行一个动作、把结果写回状态。少了最后的结果回填，这一步只是“做了动作”，不是“完成了一步”。
为什么不能把一步简单理解成一次模型调用？因为模型输出本身并不改变世界。真正改变系统状态的，是工具调用、数据写入、任务标记、错误记录这些动作。如果你把模型调用和动作执行拆得过散，系统会出现“模型已经说过了，但状态里没有留下可靠痕迹”的问题；如果你把一步做得过大，比如让系统一口气跑完整个子任务，失败时又很难知道是决策错了、工具错了，还是中间状态漂了。
更稳的设计方式是让一步天然带有验收边界。也就是说，你要能明确回答：这一步做完后，系统多了什么新信息，或者完成了什么局部推进；如果失败，应该在什么位置停住；如果继续，下一步应该基于哪个状态开始。对 Agent 来说，一步不是“说完就算”，而是“状态发生了可追踪的前进”。
面试里可以这样收口：
一步执行不是一次模型说话，而是一次可验证的局部闭环。追问方向：你会把“工具调用失败后的补救”放在这一步内部处理，还是作为下一步单独处理？
14. 如何把 Agent 的执行过程设计成可中断、可恢复、可重试？
题目：如果 Agent 跑到一半被打断、进程重启，或者某个工具临时失败了，你怎么让它不是从头瞎跑？
面试官想听什么：你是否真正考虑过运行时治理，包括中断点、状态持久化、幂等性和重试层级，而不是只会讲“失败了就再试一次”。
短答版：我会先定义可中断点和可恢复点，让每个阶段都有持久化状态，而不是把一切都寄托在上下文里。重试也不能一刀切，纯读取类工具可以局部重试，带副作用的写操作要先保证幂等或补偿机制，再谈重试。真正稳定的设计不是“永不失败”，而是失败后知道该从哪里接回来、该在哪一层重试。
深答版：
展开深答版
这题的本质是把 Agent 当成长任务系统来看，而不是一次性问答。可中断、可恢复、可重试，本质上是三个不同问题。可中断强调的是“系统在什么位置安全停下”；可恢复强调的是“停下后还能从哪个状态继续”；可重试强调的是“失败后哪些动作可以重做，哪些动作不能裸重做”。
可恢复的关键不在于把所有历史原文都塞回上下文，而在于把任务状态结构化持久化下来，比如当前阶段、已完成动作、待确认结果、工具输出摘要、失败原因等。这样 Agent 被打断后，不需要重新“回忆”自己做到哪了，而是直接从系统状态恢复。否则只靠聊天上下文，很容易出现恢复时状态不一致，甚至重复执行。
重试层级更是常见分水岭。纯读取、纯查询类失败，通常可以在工具层局部重试；但一旦动作带副作用，比如写文件、发消息、改数据库，就必须先考虑幂等键、状态检查或补偿逻辑。否则一句“再试一次”就可能把副作用执行两遍。再往上一层，如果多次局部修补仍然不收敛，才应该升到任务级回退或重规划，而不是无限原地重试。
所以真正成熟的执行设计，重点不是“让 Agent 不出错”，而是“让错误有边界、恢复有入口、重试有层级”。面试里可以用一句话收口：
可恢复靠状态设计，可重试靠副作用治理。追问方向：如果一次工具调用已经部分成功、部分失败，你会怎么决定是恢复、补偿，还是整段回退？
15. 什么时候应该先规划再执行，什么时候应该直接单步反应？
题目：不是所有任务都值得先出一份计划，那你怎么判断什么时候应该先 Planning，什么时候直接让 Agent 边看边做？
面试官想听什么：你是否有清晰的触发标准，能把“任务复杂度”“失败代价”“依赖结构”这些信号讲明白，而不是只说一句“复杂任务先规划”。
短答版：我通常先看三件事：任务路径是不是一眼能走通，步骤之间有没有明显依赖，走错一步的代价大不大。如果路径清晰、依赖少、失败成本低，直接单步反应通常更快；如果依赖链长、阶段目标多、回滚成本高，就更应该先规划再执行。核心不是任务描述长不长，而是决策空间开不开、返工代价高不高。
深答版：
展开深答版
这题的关键不是背一个“简单用 ReAct，复杂用 Planning”的口号，而是给出可操作的判断框架。真正决定要不要先规划的，不是问题字数，也不是用户提问听起来高不高级，而是任务的结构特征。你要看的是：下一步是否显而易见，后续是否依赖前面的结果，失败之后是否容易补救，以及中间是否存在必须验收的阶段节点。
直接单步反应适合那种“先做一步看看反馈，再决定下一步”的轻路径任务。比如一次搜索、一次调试试探、一次小范围读取，这类任务的特点是局部反馈价值高，且即便走错也容易纠正。此时如果一上来先规划，系统往往会花额外成本做并不必要的全局建模，反而拖慢响应。
先规划再执行更适合另一类任务：步骤多、依赖强、阶段之间会互相限制，或者错误动作带来明显返工与副作用。此时 Planning 的价值不是“看起来专业”，而是提前把路径、顺序、检查点和失败处理设计清楚，降低执行中短视决策的概率。也就是说，Planning 解决的是全局结构风险，单步反应解决的是局部不确定性。
面试里可以这样收口：
该不该先规划，不看题目长短，看的是依赖复杂度和走错代价。追问方向：如果一个任务前 70% 路径很确定，后 30% 需要探索，你会整段先规划，还是分段切换执行模式？
16. 多 Agent 什么时候真的有必要，什么时候只是把复杂度放大？
题目：很多团队一上来就想拆成多 Agent，你会怎么判断这是真的有必要，还是只是把单 Agent 没解决好的问题分散掉？
面试官想听什么：你是否能从任务解耦、并行收益、协调成本和错误传播角度判断多 Agent 的真实边界，而不是把它当成默认高级形态。
短答版：只有当任务能被清晰拆成相对独立、接口明确、并行收益明显的子问题时，多 Agent 才值得做；如果子任务强依赖共享上下文、频繁互相纠偏、协调成本高，那通常只是把复杂度换了个地方。很多时候先把单 Agent 的状态管理和执行边界做好，比盲目拆多 Agent 更有效。
深答版：
展开深答版
这题的核心是别把“多 Agent”当成能力增强咒语。多 Agent 真正解决的是任务分解和并行处理问题，不是自动解决推理质量、状态管理或工具鲁棒性问题。如果单 Agent 连目标、状态、边界都没理顺，拆成多个 Agent 往往只是把原本集中暴露的问题分散到协调层，再额外引入通信、仲裁和一致性成本。
真正适合多 Agent 的场景通常有几个特征：子任务天然可分，比如检索、分析、执行、审核职责清晰分开；不同子任务之间接口相对稳定，不需要来回高频改口；并且并行执行真的能换来明显收益，比如缩短总耗时、降低主 Agent 上下文负载、或者把高风险动作隔离给专门角色。换句话说，多 Agent 要解决的是结构性并行问题，不是抽象上的“更智能”。
反过来，如果任务本身高度耦合，前一步的细小变化就会不断改写后一步目标，或者多个 Agent 需要共享大量隐式上下文、频繁协商谁说了算，那多 Agent 往往得不偿失。你会得到更多提示词、更多状态同步、更多日志链路、更多失败模式，但不一定得到更高质量。很多团队最后发现，最大的问题不是“Agent 不够多”，而是“任务边界没定义清楚”。
面试里可以收口成一句：
多 Agent 适合解决可解耦、可并行、可仲裁的问题；如果问题本身还没被结构化，先拆 Agent 往往是在放大协调复杂度。追问方向：如果一个系统拆成了“规划 Agent + 执行 Agent + 审核 Agent”，你会先检查哪条交接边界最容易出问题？
17. 什么时候应该让 Agent 自己决定是否调用工具？
题目：不是所有场景都适合把工具调用权完全交给 Agent，那你会怎么判断什么时候该让它自己决定，什么时候应该由流程显式约束？
面试官想听什么：你是否能从不确定性、错误代价、工具副作用和决策空间大小来设计工具调用自治边界。
短答版：当任务目标开放、是否需要外部信息本身就是运行时问题、且工具副作用低时，更适合让 Agent 自主决定要不要调工具；当工具调用代价高、风险高、流程顺序固定时，应该由系统显式约束。核心不是“信不信模型”，而是工具选择是不是值得放进运行时决策空间。
深答版：
展开深答版
这题本质上是在谈自治边界。很多人一旦有 Tool Use，就默认“让模型自己判断什么时候调用”，但这其实是在把系统控制权交给运行时决策。只有在这种决策真的有价值时，这么做才合理。比如用户问题是否需要检索、是否需要额外读取上下文、是否需要做一次验证，这些都属于典型的运行时不确定性，Agent 自主判断通常能减少硬编码流程的僵硬性。
但如果工具调用本身代价高、顺序固定、或者一旦出错就有明显副作用，完全放权就容易把问题变成事故。比如写数据库、发通知、审批操作、外部系统变更，这类动作更适合被明确门控，至少要把触发条件、前置检查和审批边界写死，而不是让模型“觉得现在应该调一下”。这里的问题不是模型聪不聪明，而是错误的容忍度有多低。
一个实用判断标准是看“调用决策本身是否值得智能化”。如果这个决策高度依赖现场上下文，而且调错一次的成本可控，就可以给 Agent 自主空间；如果这个决策其实是固定流程、只是不想写死代码，那多半不该交给模型。很多系统不是因为工具不够，而是因为把本应由流程保证的东西让模型临场决定了。
面试里可以收口成一句：
该不该让 Agent 自己决定调不调工具，不看技术上能不能，而看这件事是不是一个值得开放给运行时的不确定决策。追问方向：如果一个工具“读操作便宜、写操作高风险”，你会怎么设计同一个工具的不同调用权限？
18. 什么时候应该先让 Agent 产出澄清问题，而不是直接开始执行？
题目：有些任务一上来就执行会不断返工，你会怎么判断应该先让 Agent 提澄清问题，而不是直接开做？
面试官想听什么：你是否理解“先问清楚”本身也是一种执行策略，能从目标歧义、约束缺失和错误代价角度设计澄清门槛。
短答版：当目标定义不完整、成功标准不清楚、关键约束缺失，或者走错第一步代价很高时，我会先让 Agent 产出澄清问题。澄清不是拖延，而是用更低成本换更小的返工面。只有在目标清晰、局部试探成本低时，才更适合直接边做边看反馈。
深答版：
展开深答版
这题核心是把“澄清”从礼貌动作提升为运行时决策。很多系统默认只要收到请求就立刻开始做，但有些任务的问题不是缺执行力，而是入口信息根本不足。此时直接执行，表面上很积极，实际上只是在用猜测替代约束，后面返工几乎是必然的。
什么时候该先澄清？典型信号包括：目标本身有多种合理解释，比如“帮我整理一下”到底是摘要、重写还是结构化；关键约束没给，比如格式、时限、审批边界、工具范围；成功标准不明确，比如“做好一点”没有可验证出口；还有一种是第一步一旦走错，后面要么代价高、要么会污染状态。这些场景里，先问清楚通常比先做一步再回头改更便宜。
当然，也不是所有任务都值得先问。对低风险、可局部试探、反馈很快的任务，过早澄清会把系统变笨变慢。所以成熟的设计不是“凡事先问”，而是能识别哪些不确定性必须在执行前消掉，哪些可以留到执行中边走边收集反馈。也就是说，澄清是为了压缩高成本不确定性，不是为了追求形式完整。
面试里可以收口成一句：
该不该先澄清，不看礼貌与否，看的是当前不确定性会不会在执行后变成高成本返工。追问方向：如果用户问题里同时缺目标边界和输出格式，你会先问哪个，为什么？
19. 什么时候应该把规划结果结构化，而不是只保留自然语言计划？
题目：很多 Agent 系统会先让模型产出一段自然语言计划，但在工程里，什么时候应该把计划进一步收敛成结构化结果，比如 step list、依赖关系、状态枚举、约束字段，而不是只保留“模型写出来的一段话”？
面试官想听什么：他想判断你是否理解“计划”在工程里不仅是给人看的解释文本，更是后续执行、校验、恢复、重试、监控和协同的控制对象。一个成熟候选人会讲清楚自然语言计划的优点，也会知道一旦计划要参与系统控制，就必须逐步结构化。
短答版：只要计划不只是给人看，而是要进入执行、恢复、审批或监控链路，就应该结构化。自然语言计划适合思考和沟通，结构化计划适合机器执行和系统治理。通常不用一开始就做复杂 DSL，先把步骤标识、依赖关系、输入输出和失败策略这些关键字段抽出来就够了。
深答版：
展开深答版
很多团队一开始会让模型输出一段“接下来我会先做 A，再做 B，最后做 C”的自然语言计划，这在 demo 阶段没有问题，因为它足够快、足够灵活，也便于人理解。但一旦系统开始把这份计划当成执行依据，自然语言的边界就立刻暴露出来了：它不稳定、不易校验、不方便恢复、也难以做运行时治理。
你可以用一个简单标准判断要不要结构化：这份计划是不是只给人看，还是还要给系统用。只给人看，自然语言就够；要给系统用，就必须把计划里最关键的控制信息抽出来。因为系统不是在理解“文采”，系统要知道的是当前执行到哪一步、下一步依赖什么、失败后能不能重试、哪些步骤能并行、哪些步骤需要审批、哪些步骤消耗高、哪些步骤可跳过。这些都不是一段自由文本能稳定承载的。
更具体地说，只要出现以下需求，结构化几乎就是必选项。第一，步骤级执行。执行器需要知道 step 边界，而不是从一段话里猜。第二，依赖控制。没有显式依赖关系，就做不好并行与阻塞。第三，状态持久化。想做中断恢复，就必须把“计划状态”与“执行状态”解耦并存档。第四，策略治理。比如高风险步骤必须人工批准，外部写操作必须带权限标签，这些都要求计划里有明确字段。第五，运行分析。你如果想知道哪类步骤最容易失败、哪类步骤最费 token、哪类计划经常被改写，结构化数据是前提。
但结构化不代表一开始就造一门复杂的计划语言。更稳的做法是渐进式结构化。先保留自然语言计划用于解释，再从中抽出少量核心字段作为执行层的真实输入，比如
step_id、description、goal、inputs、outputs、dependencies、can_retry、timeout、risk_level、requires_approval。这样既保留模型规划时的表达弹性，也让执行层有明确边界。很多工程失败，不是因为没有规划，而是因为把“解释性文本”误当成了“控制性协议”。再往前走一步，如果系统需要多 Agent 协作、跨工具编排、长任务恢复，结构化计划还应该和运行时状态分离。计划描述的是“原本打算怎么做”，状态描述的是“实际上做到了哪”。这样当任务中途失败时，系统可以决定是回到原计划继续、局部重规划，还是直接人工接管。如果计划本身只是自然语言，恢复时就容易退化成“把历史全部塞回上下文再让模型重新猜”，这在稳定性和成本上都很差。
所以推荐的工程判断是：把自然语言计划当作思考和沟通层，把结构化计划当作执行和治理层。不是二选一，而是分层。真正成熟的系统，往往不是“模型写得更像计划”，而是“系统把计划管理成了可执行对象”。
追问方向：结构化计划和 workflow DSL 的边界怎么划分？计划变更时如何做版本兼容？结构化过度会不会压缩模型探索空间？如果模型产出的结构化计划不合法，应该重试、修正还是降级成人工确认？