把大任务切成 Agent 能消化的块：任务分解

任务分解的目标是让每个任务块在上下文崩塌之前完成。这需要在两个维度上进行切分。

空间维度上，通过模块化和 API Contract 划定每个 Agent 的工作围栏。每个模块有完整的输入输出定义，Agent 在围栏内自由发挥，围栏外的依赖通过 Mock 隔离。这使得每个 Agent 在有限的上下文窗口内获得完整的、自包含的工作环境。它不需要理解整个系统，只需要理解自己负责的模块和它与外部的接口契约。

API Contract 在这里扮演了关键角色。它既是模块之间的技术边界，也是 Agent 工作范围的认知边界。一个定义清晰的 API Contract 告诉 Agent：你负责实现这个接口背后的逻辑，输入是什么格式、输出是什么格式、错误情况怎么处理，都写在契约里了。契约之外的系统对你透明，你不需要也不应该关心。

时间维度上，即使在同一个模块内，也将任务拆分为小块。每块完成后验收，确认产出符合预期，然后为下一块重新整理上下文。这直接对抗长链推理中早期决策被遗忘的问题：通过频繁的上下文重置，确保每一步都在干净的、聚焦的上下文中执行。

判断粒度的标准来自实践经验。一个任务块的理想大小是：Agent 能在一个会话内完成，产出可以被独立验证，且完成后的代码处于一个可集成的状态。如果一个任务块在执行过程中出现了 Agent 自相矛盾的迹象，说明粒度太大，需要进一步拆分。

两个维度结合，形成一种混合执行模式。需求阶段采用迭代探索，允许模糊和试错。一旦进入执行阶段，严格按序推进：规约 → 测试 → 编码 → 验收。规约是分界线。规约之前自由迭代，规约之后严格执行。这个模式可以概括为"敏捷需求，瀑布执行"。AI Agent 在紧约束下表现最佳。模糊的流程导致上下文污染和偏离。