5.4 任务拆解与约束声明

面向经管学生、研究者与从业者的 AI 智能体设计教材

5.4 配图

任务一复杂，很多人第一反应就是把每一步都写出来。这样有时有效，但如果把所有任务都拆成细密流程，模型会失去弹性，人也会把大量篇幅花在控制枝节上。真正要问的不是要不要拆，而是哪些地方必须显式控制，哪些地方可以交给模型自己完成。

先看一张“拆不拆”判断表。

判断问题	如果答案是“是”	建议
这一步会产生不可逆动作吗	例如修改文件、删除内容、提交结果	要拆，并设置确认点
需要审查中间产物吗	例如先看分类方案，再决定是否执行	要拆，保留阶段性交付
任务存在明显分叉吗	例如先判断类型，再决定后续路径	要拆，把判断节点写出来
最终结果很容易直接验收吗	例如简单润色、短摘要	可以不拆，只保留目标和边界
失败成本很低吗	做错后很容易回滚	可以少拆，给模型留弹性

显式拆步真正适合四类场景：有风险动作、要看中间产物、存在分叉判断、需要留下复核痕迹。离开这些场景，过度拆解通常只是在放大控制欲。

拆解之外，另一半同样重要的是约束声明。好的约束不是“提醒模型注意”，而是把边界写成可执行规则。约束至少要覆盖四类内容：

• 资料边界：能读什么，不能读什么，是否允许扩展材料。
• 工具边界：能不能运行命令，能不能修改文件，能不能安装依赖。
• 主动性边界：可以自己推进到什么程度，哪些节点必须先回来确认。
• 成本边界：时间预算、搜索轮数、输出长度、调用次数。

两种写法的差别通常很明显。

• 弱约束：尽量不要改太多文件。

• 强约束：只允许修改 src/parser.py 和 tests/test_parser.py，其余文件只读。

• 弱约束：必要时再去搜索资料。

• 强约束：先使用本地材料，只有关键定义缺失时才允许联网搜索，且不超过 2 次。

过度拆解的风险

把每一步都写成固定流程，会让模型失去根据现场调整的弹性。只有涉及不可逆动作、需要审查中间产物、存在分叉判断这三类场景时，才有必要显式拆步。

一句话总结这一节：显式拆步只用在需要控制路径的地方，约束声明则用来防止范围、成本和动作边界悄悄失控。