先记住这个答案
目标含糊不等于所有工作都必须暂停。Agent 应先从上下文识别成果、对象和约束，把已经确认的要求继承下来。若缺失信息会改变交付物、操作对象或不可逆行动，就提出具体问题并等待该部分答案；若只是可撤销的实现细节，可以说明合理假设并继续。任务分解也可以分两层：先列稳定的阶段，等调查或澄清得到事实后，再展开依赖这些事实的步骤。
- 先查现有上下文，避免重复询问已经确认的信息
- 只让会改变关键执行分支的歧义阻塞相关工作
- 假设要可见且可修正，不能充当用户授权
先恢复用户真正要完成的事
用户说优化搜索，可能指搜索速度、结果相关性或搜索引擎收录。应先检查正在讨论的页面、已有问题和明确约束，再把目标转成可以观察的行为。如果上下文已经说明搜索很慢，就不必从零询问优化是什么意思，可以继续定位耗时环节。
规划时将未知条件显式记录，避免它们被悄悄写成确定需求。比如尚未确定是否允许改索引，可以先分析慢查询与现有结构；依赖索引变更的实施步骤暂不执行。这比把整个项目锁住更能利用等待时间。
提出能改变下一步的具体问题
对于清理旧文件的请求，如果旧的定义会影响保留范围，问题应该围绕保留条件，而不是笼统询问更多信息。可以先列出候选清单及各类文件的用途，让用户面对一个可判断的范围，之后再执行依赖确认的动作。
如果只是样式间距、局部函数命名等可撤销细节，Agent 可以结合项目规范自行选择。说明假设时要讲清实际采用的条件和影响，不需要把每个小决定都转交给用户。等待可选偏好期间，也应给对方合理回复机会，避免刚提问就宣称默认选项已获批准。
答案到来后更新计划而非重启任务
用户补充只优化移动端时，应调整相关测试范围与实现分支，同时保留已经完成且仍适用的调查结果。任务分解的节点需要关联需求，才能判断哪些步骤保留、哪些失效。把每次回复都当新任务，会丢失原目标和已有进度。
若关键答案一直没来，依赖它的行动仍不能擅自执行；可以继续完成独立检查并准确记录阻塞位置。目标澄清的效果可通过返工率、重复问题数和关键误操作衡量，而不是简单要求 Agent 永远少问或永远先问。
容易答错的地方
- 用默认选项代替同意
- 界面预选、用户沉默或时间经过都不能证明用户接受了关键条件。必要答案没有到达时，应保留阻塞状态。
- 先把所有细节问完再开始
- 能由代码、文件或既有约定回答的问题应先自行调查，只把真正影响用户意图的缺口留给用户。排查“Agent 目标澄清与任务分解的决策边界”时还要核对输入、版本和执行顺序，并用反例确认修复后的边界。
面试官还会怎么问？
用户说你决定就好，还需要问吗？
这扩大了常规实现选择空间，但应结合具体任务理解，不能凭这一句话推导出任意对象和任意范围的授权。
分解任务时可以写假设吗？
可以，注明假设、依赖它的步骤以及验证方式。新信息推翻假设时只调整受影响部分。针对“Agent 目标澄清与任务分解的决策边界”，还应保留最小复现、预期结果和失败路径，避免只凭一次现象下结论。
如何评价提问是否有用？
看不同答案是否会带来不同的执行路径或验收条件。如果答案不影响行动，问题可能只是增加沟通负担。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。