先记住这个答案
一个合适的 Agent 子任务应有明确输入、有限范围、可验证输出和完成条件，失败后能定位原因并单独修复。拆得过粗，容易遗漏约束且难以恢复；拆得过细，又会增加上下文传递、模型调用与协调成本。应结合依赖关系、共享资源、可观察进展和副作用边界决定粒度，过程中再根据新的信息调整计划，不能仅以步骤数量评价规划质量。
- 每个子任务应有可验证的输出与完成条件
- 可并行取决于依赖和资源，不只看任务名字
- 过细拆分会增加信息损失与协调成本
怎样识别一个过大的子任务
“检查整个系统并修好所有问题”没有明确边界，执行过程中很难判断发现的问题是否属于原目标。可以先限定模块与现象，再把结果拆成定位证据、修复方案、实现与验证等有依赖的产物。每一步不仅写一个动词，还应说明输入来自哪里、结果如何检查。
但不应把这种划分变成死板的流水线。某个小错误可能在定位后就能直接修复并验证，强行要求四次独立模型调用只会重复传递上下文。粒度选择需要匹配问题规模，而不是为了让计划看起来详细就把每一次读取文件都包装成独立任务。
文档审核与代码修复的依赖并不相同
假设需要核对三份互不依赖的接口文档，每份都能产出字段差异和引用位置，这些审查可以相对独立进行。最后汇总时再统一处理跨文档命名冲突。若两个任务同时修改同一份规范，就还需要明确修改所有权或串行合并，不能只依据阅读工作独立就直接并行写入。
对于代码修复，验证方案依赖已确定的预期行为，实现又可能改变需要检查的边界。可以并行收集不同模块的只读证据，但最终修改与验证应围绕一致的状态进行。把相互依赖的步骤同时执行，常导致后续任务依据旧文件作出结论，省下的时间又被返工消耗。
通过失败与反馈调整拆分粒度
如果一个子任务反复超出上下文、输出难以验收或失败后必须重做大量工作，说明可能需要缩小范围。可以按模块、数据分区或独立验收条件继续拆分，并记录已经获得的证据。相反，如果大量小步骤只是在转述相同背景，没有独立决策价值，可以合并以减少信息传递。
涉及外部副作用时，粒度还应支持重试与幂等。例如“生成报告草稿”与“发送报告”最好有明确边界，前者可以反复修改，后者需要知道是否已经执行。计划状态应反映实际产物，而不是仅由模型说一句已完成就推进；必要时用工具结果或可检查的文件确认。
容易答错的地方
- 把任务越细理解成可靠性越高
- 每次交接都可能损失约束和证据，拆得过细会增加协调、重复阅读和结果合并成本。应衡量失败恢复收益是否覆盖这些开销，而不是用计划行数代替质量指标。
- 认为两个子任务名称不同就能并行
- 它们可能共享同一文件、依赖同一条中间结果或竞争有限的外部资源。并行前应检查数据依赖与修改范围，并规定冲突处理；名称差异并不能证明执行独立。
面试官还会怎么问？
怎样写出可以验收的子任务？
除了动作，还要写输入、范围、交付物和检查方式。例如要求指出某接口字段差异并附具体出处，比要求研究接口更容易判断是否完成，也便于发现证据不足的地方。
任务执行中发现新依赖，是否应该坚持原计划？
不应该机械坚持。应记录新事实、更新依赖关系，并判断哪些已完成产物仍然有效；调整计划的依据是环境变化与证据，而不是模型随意换一种步骤描述。
规划本身耗时过多时如何简化？
对路径明确且可直接验证的小任务，可以采用较短的执行循环，只保留关键检查点。复杂任务再按需要细化，避免在尚无事实支撑时提前生成大量不会被实际使用的子步骤。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。