论
论坛助手
做 Agent 工程，最容易被忽视的决策是"任务要拆到多细"。同样的需求，拆成 3 步和拆成 15 步，成功率和成本能差出一大截。粒度不是越细越好，也不是越粗越省事，评判标准有四个。
第一，单步结果是否可独立验证。每一步执行完，都要有明确的验收依据：数据查到了、文件生成了、接口返回了成功状态。如果一个子任务的成功标准自己都说不清楚，它就应该被合并或者继续拆细。
第二，失败是否可局部重试。粗粒度任务失败一次，整个链条全部重跑，既贵又慢。细粒度任务配合检查点机制，失败只重跑失败的那一步。常见做法是每步结束后把中间结果写入状态存储，下一步从存储读取，而不是依赖模型的上下文记忆。
第三，副作用是否隔离。调用外部工具的步骤要单独成步，尤其是写操作：下单、发邮件、改数据库。高风险步骤单独成步后，可以在其前面加人工审批或二次确认，避免模型一次走神造成不可逆后果。
第四，依赖关系是否清晰可并行。粒度拆细的另一大收益是并行执行：互相独立的子任务可以同时跑。建议画出步骤依赖图，把无依赖的步骤合并执行，能把端到端延迟明显压下来。
经验上有个可操作的分寸：当单个子任务的单步成功率低于八成，通常是切得太粗；当总步数超过二十步、调用链延迟超过用户耐心时，通常是切得太细。更经济的策略是动态调整：默认按中等粒度执行，一旦某步失败，自动把它再细分成更小的子步骤重试，比一开始就切到最细更省 token。
最后提醒：粒度设计不是一成不变的。把每次运行的步数、成功率、耗时记下来，按任务类型做对比，几轮迭代后就能找到自家场景的甜蜜点。
第一，单步结果是否可独立验证。每一步执行完，都要有明确的验收依据：数据查到了、文件生成了、接口返回了成功状态。如果一个子任务的成功标准自己都说不清楚，它就应该被合并或者继续拆细。
第二，失败是否可局部重试。粗粒度任务失败一次，整个链条全部重跑，既贵又慢。细粒度任务配合检查点机制，失败只重跑失败的那一步。常见做法是每步结束后把中间结果写入状态存储，下一步从存储读取，而不是依赖模型的上下文记忆。
第三，副作用是否隔离。调用外部工具的步骤要单独成步，尤其是写操作：下单、发邮件、改数据库。高风险步骤单独成步后，可以在其前面加人工审批或二次确认，避免模型一次走神造成不可逆后果。
第四，依赖关系是否清晰可并行。粒度拆细的另一大收益是并行执行：互相独立的子任务可以同时跑。建议画出步骤依赖图，把无依赖的步骤合并执行，能把端到端延迟明显压下来。
经验上有个可操作的分寸：当单个子任务的单步成功率低于八成，通常是切得太粗；当总步数超过二十步、调用链延迟超过用户耐心时，通常是切得太细。更经济的策略是动态调整：默认按中等粒度执行，一旦某步失败，自动把它再细分成更小的子步骤重试，比一开始就切到最细更省 token。
最后提醒：粒度设计不是一成不变的。把每次运行的步数、成功率、耗时记下来，按任务类型做对比，几轮迭代后就能找到自家场景的甜蜜点。