当模型学会自我规划，流程脚手架如何取舍

一、流程脚手架为什么曾经是“必装”

智能编程代理刚普及的那段时间，模型最让人头疼的不是写不出代码，而是“抢跑”：需求还没对齐就动手实现；改完不跑验证，直接丢下一句“已完成”；顺手修改了与任务无关的文件，事后才被发现。这类问题的根源在于早期模型缺乏稳定的任务理解与自我约束机制，仅靠系统提示词里写一句“请先确认需求”，约束力非常有限。

于是，在模型外层套一套完整流程框架成了社区的主流做法。典型的流程是四道闸门：

• 需求澄清：动手前强制进行一轮对话式梳理，把模糊需求变成明确清单；
• 计划产出：先写设计与任务拆解文档，经确认后再执行；
• 测试先行：要求测试驱动开发，先写失败用例再补实现；
• 独立评审：由另一个代理角色复查代码与测试覆盖。

每道闸门都对准一个真实存在过的故障模式。在模型“知道该做什么但经常做不稳”的年代，这套脚手架确实显著降低了返工率，笔者也曾长期把它放进默认配置并主动推荐。

二、临界点：模型原生能力覆盖了框架的核心职责

变化发生在新一代旗舰模型上线之后。以当前业界主流的模型能力划分为参照，旗舰档模型普遍具备三类此前需要外部框架兜底的能力：

1. 自主规划：接到复杂任务后，模型会先做需求拆解、依赖识别和步骤排序，规划质量已不逊于许多模板化的计划文档；
2. 子代理调度：面对可并行的子任务，模型能主动拆分并分发给多个子代理协同完成，不再需要外层框架代劳编排；
3. 长任务续航：多步骤任务可以持续推导、中途自检、按里程碑推进，而不是走两步就断。

这三项能力恰好是流程框架的核心卖点。当模型自己会规划、会调度、会持续推进时，外层再完整跑一遍“拆解→排期→分发→检查”，本质上成了重复调度。重复调度带来的不只是时间开销，还有一致性成本：两套规划逻辑可能互相冲突，框架拆出的子任务与模型自己的执行路径打架，代理在中断确认上消耗的轮次甚至超过实际写代码的轮次。

这也是近期多个开发者社区反馈呈现出的共同趋势：框架没有“变坏”，而是它的核心职责被模型原生能力覆盖了。

三、现象复盘：小任务被做成了大项目

把社区里的典型反馈归纳一下（细节已做匿名化处理），大致有三类：

• 耗时失衡。有开发者做过对照：同一个边界清晰的小任务，关闭流程编排后几十秒交付；开启后耗时数分钟，期间还停下来向用户确认了多次。交付质量是否因此提升，原帖并未给出可验证的对比，但等待成本是实打实的。
• 文档膨胀。有人反馈，实际代码改动只有几行，整个会话却跑了近二十分钟，最后留下两百多行过程文档——需求说明、设计记录、任务清单、评审纪要一应俱全，而它们描述的改动用肉眼十分钟就能审完。
• 调度过载。更极端的案例里，一个普通任务被拆成十几个子任务，每个子任务再走两轮评审，累计创建三十多个子代理。任务本身推进有限，调用额度先耗尽了。

这些案例的共同结构值得仔细拆解：每一步单独看都合理，组合起来却比任务本身还重。改几行代码前先写设计文档，单独看是严谨；补一组回归测试，单独看是负责；开一轮独立评审，单独看也是最佳实践。但当任务本身只需要五分钟时，整套流程的成本收益比就完全失衡了。

这里可以引入一个简单的度量视角：过程产出/有效产出比。几百行过程材料、几十次代理调用，究竟替我们挡住了什么风险？如果改动边界清晰、影响面小、随时可回滚，那么这些过程材料的信息价值趋近于零，剩下的几乎全是纯开销。以前我会把这类开销当作严格流程必须支付的成本，现在更倾向于先算账，再决定是否支付。

四、按风险分层：把流程强度当成配置项，而不是信仰

既然“一刀切全开”不再合理，替代方案也不是“一刀切全关”，而是把流程强度做成随风险变化的分层配置。结合近期的实践，可以把日常任务分成三档：

L0：轻量任务——直连模型，流程归零。 边界清晰的小修复、格式调整、局部重构、文案改动，直接让模型执行，只保留最基本的动作：改动后运行相关测试或让模型自检一遍代码差异。不写计划文档，不建隔离工作区，不开独立评审。

L1：常规任务——用模型原生规划替代外部编排。 跨模块的功能开发、有一定不确定性的需求，先让模型进入原生规划模式，产出执行计划并确认后再动手。规划、执行、自检由同一个模型体系闭环完成，避免外部框架再叠一层调度。

L2：高风险任务——测试先行与独立评审回归。 涉及支付链路、权限体系、数据迁移、并发状态管理的变更，故障代价高且难以回滚，此时测试先行和独立评审的价值重新超过其开销：测试用例本身就是需求确认的产物，独立评审代理能补偿模型自我检查的盲区。此外还应补充迁移演练、回滚预案等闸门。

用示意性配置表达这套思路（伪配置，仅表达结构，不代表任何具体产品的语法）：

workflow_profiles:
  lite:                      # L0：小改动
    planning: none
    verification: run_related_tests
    review: self_check_diff
  standard:                  # L1：常规开发
    planning: native_plan    # 使用模型原生规划，确认后执行
    verification: affected_paths
    review: single_pass_agent_review
  strict:                    # L2：高风险变更
    planning: native_plan
    verification: tdd_required
    review: independent_reviewer
    extra_gates: [dry_run, rollback_plan]

如何判断一个任务属于哪一档？可以用四个问题做快速分诊：

1. 可逆性：出错后能否在几分钟内回滚？能，降档；不能，升档。
2. 影响面：改动是否触及资金、权限、个人数据、存储结构？触及任何一项，直接进 L2。
3. 验证成本：能否用自动化测试在短时间内给出明确对错信号？能，流程可以轻；只能靠人工判断，流程要重。
4. 团队契约：团队是否有强制评审的合规要求？有，以契约为准，不因任务小而豁免。

五、落地建议与常见误区

第一，警惕从一个极端滑向另一个极端。“全开”的问题是流程空转，“全关”的问题是高风险任务失去闸门。分层的关键在于高风险清单必须显式维护，而不是凭模型或个人临场判断。

第二，定期审计规则库。流程框架里积累的规则往往带着历史痕迹。建议每隔一段时间逐条自问：这条规则当初防的是什么问题？现在模型是否已经原生解决？如果答案是否，就把它从默认路径移到 L2 白名单里，而不是继续让所有任务为它付费。

第三，把流程开销纳入度量。可以简单记录每次任务的会话时长、过程文档行数、子代理调用次数与实际代码变更量的比值。当比值持续失衡时，就该检查流程配置是否与任务类型错配。

第四，善用多档模型分工。当前主流模型普遍提供多档位：旗舰档处理复杂分析、编程与长任务，均衡档作为日常默认，轻量档承接高频、成本敏感的场景。档位选择应与流程分层联动——L0 任务用轻量档直连，L1 用均衡档加原生规划，L2 用旗舰档并叠加完整闸门，避免“轻任务用重模型、重流程”的双重浪费。

第五，团队层面先约定再推广。分层策略涉及个人判断，落地时最好把 L2 清单、分诊问题、评审要求写进团队约定，让“什么时候必须走重流程”成为显式规则，而不是各凭习惯。

顺带一提，这套分层思路与具体工具链无关：无论团队使用自建脚本编排，还是百度智能云等云平台提供的智能开发与持续集成类工具，都可以按同样的风险维度配置流程强度，核心始终是“流程强度与任务风险匹配”。

六、结语

流程脚手架的兴衰，本质上是模型能力边界外移的结果。当模型“知道该做什么但做不稳”时，外部规则是必要的护栏；当模型学会规划、调度与持续执行后，继续叠加完整流程就成了重复建设。工具的价值来自它填补的缺口，缺口变了，工具的定位就该重估——该保留的闸门（高风险变更的测试与评审）要坚决保留，该拆除的门槛（小任务上的全套仪式）也要果断拆除。对开发者而言，比“装或不装”更重要的，是建立起一套随模型能力演进而持续审视自身工作流的习惯。