《AI 渐进编程》之二十三：自适应调度——什么时候启用多Agent流水线

上一篇我们搭建了「执行Agent+审查Agent」双角色制衡架构，解决单Agent自审盲区、隐性技术债泛滥的问题。但很多人落地时会走入极端：不分任务大小全部上双Agent流水线，导致Token开销翻倍、迭代时延拉长，简单单行修改也要走完完整评审流程，违背本系列开篇“渐进分层控制”核心思想：能轻则轻，风险提升再逐层加约束。

本篇给出一套可直接落地的自适应判定标准、调度分支逻辑、成本损耗量化对比，打通多Agent架构与SIADOS全局状态、Harness控制层的联动规则。

一、多Agent流水线不可忽略的硬成本代价

在选择架构前，必须先看清两套方案的工程开销差异，这是自适应调度的底层依据：

1. Token消耗成本
   • 单Agent：仅一轮代码生成+自测输出证据包，单次上下文长度可控；
   • 双Agent：执行生成完整证据包→审查完整通读证据包并输出评审意见→执行二次迭代重写，完整闭环Token消耗提升2～4倍，频繁驳回场景开销会进一步放大。
2. 执行时延成本
   • 单Agent：一轮推理即可交付结果；
   • 双Agent：至少两轮独立LLM调用，存在来回驳回迭代时，整体耗时提升数倍，不适合需要快速热修复、单行bug修补的低延迟场景。
3. 维护成本
   双Agent需要维护两套独立Prompt、统一证据包交互模板、评审规则阈值；简单任务强制走双流水线会让Harness控制层冗余臃肿，出现前文提过的Harness肥胖反模式。
4. 死循环风险
   执行与审查目标天然对立：执行追求快速落地，审查追求架构安全，无迭代上限约束时会陷入无限来回修改，持续消耗算力。

二、三级任务分级：单Agent/双Agent/三层Agent判定标准

基于改动文件数量、影响范围、业务风险划分三级任务，Harness自动分流对应流水线，判定逻辑写入SIADOS任务状态元数据。

1级：轻量低风险任务 → 单Agent直通模式（跳过审查）

满足任意一条即启用：

• 仅修改单个文件内单行/单函数，无跨文件依赖变更；
• 纯文本注释、日志打印、变量命名优化，不改动业务逻辑；
• 独立工具函数小bug修复，不影响对外接口与数据库操作；
• 单元测试补充、注释完善，无生产运行风险。

流转流程
任务下发 → 单执行Agent生成代码+极简证据包 → 直接更新SIADOS任务状态，闭环结束，不启动审查Agent。

2级：中等变更任务 → 标准双Agent流水线（执行+审查）

满足任意一条启用二元制衡架构：

• 新增/修改对外接口、新增模块类，涉及2～5个文件改动；
• 业务逻辑调整、参数校验规则修改，存在线上报错风险；
• 重构局部代码、拆分函数，影响上下游少量调用方；
• 涉及数据库读写、缓存更新、第三方接口调用。

流转流程
执行Agent产出完整标准证据包 → 审查Agent独立审计风险 → 合规放行/驳回迭代，设置最大3轮迭代上限。

3级：高危跨模块重构 → 三层专业Agent团队（规划+执行+审查）

满足任意一条强制三层架构，人工前置确认：

• 跨模块大规模重构，改动文件超10个，影响多条业务链路；
• 核心底层框架、权限体系、事务逻辑修改；
• 版本升级、依赖大更换、数据库表结构变更；
• 线上核心支付、用户鉴权等高风险代码改动。

规划Agent核心职责
拆解需求边界、划定修改范围、输出标准化任务契约，写入SIADOS全局状态，人工确认契约后，再下发执行+审查流水线。

三、SIADOS全局状态如何支撑自适应调度

自适应分流不是独立开关，完全依附SIADOS六元状态做判定，每一轮任务启动前读取状态内3个核心字段：

1. scope_files：改动文件清单，统计数量判定任务等级；
2. risk_level：Harness预先配置的模块风险标签（low/mid/high）；
3. cross_module：布尔标记，是否跨业务模块修改。

调度规则写入Harness控制层统一约束，保证全项目判定标准一致，不会出现同一类改动这次走单Agent、下次走双Agent的规则漂移问题。

同时所有Agent均只读SIADOS原始状态，仅执行Agent拥有代码写入权限，审查、规划Agent禁止修改项目文件，从状态层隔离权限，杜绝并发覆盖、状态撕裂。

四、双Agent流水线熔断自愈机制（解决无限驳回死循环）

自适应调度搭配熔断兜底，作为Harness内置防护规则，弥补22篇未覆盖的异常场景：

1. 迭代轮数熔断
   双Agent流水线设置最大3轮驳回迭代，连续3次修改仍无法通过审查，直接熔断流程，标记高风险，强制人工介入复核完整证据包。
2. 风险量化阈值熔断
   审查Agent输出标准化风险打分（0～10分），单次改动风险分超过8分，直接阻断迭代，不允许执行Agent反复尝试修复。
3. 无实质修改熔断
   连续两轮执行Agent仅微调格式、未解决审查标记的核心架构问题，判定无效迭代，终止流水线转人工。

五、完整自适应流转总览

1. 需求进入Harness控制层，初始化SIADOS任务状态；
2. Harness读取scope、风险标签、跨模块标记，自动判定任务分级；
3. 1级轻量任务：单Agent直通交付；
4. 2级中等任务：双Agent制衡流水线，带3轮迭代熔断；
5. 3级高危任务：规划Agent前置拆解契约→人工确认→双Agent评审；
6. 所有流水线完成后，将本次改动、评审记录、风险标记写入SIADOS归档，沉淀为项目长期规则（承接第14篇修复沉淀逻辑）。

六、本章总结

双Agent多角色架构不是全能最优解，只是中高风险任务的质量制衡手段。

AI渐进编程的“渐进”，体现在架构随风险动态升降：低风险轻量化单Agent控成本、提速度；中风险启用二元Agent做审计制衡；高危重构叠加规划层前置约束，搭配SIADOS统一状态、Harness分级调度、熔断自愈三层保障，在开发效率与长期工程稳定性之间取得可控平衡。

下一篇预告：多Agent场景下SIADOS状态共享、版本锁、并发修改冲突解决方案