如何将复杂 Agent 的有效交付效率提高 96.3 倍

在生成式 AI 领域，原型设计 Agent 是一类典型的复杂任务系统。它的目标是将自然的语言需求转化为可交互、可运行的完整产品原型。

这一过程涵盖“需求理解 → 方案制定 → 页面拆分 → 并行实现 → 整体验证 → 迭代修复”等多个环节，构成一个动态任务图。随着原型复杂度的提升，任务节点之间的关联度成倍增加：局部页面的组件失配、视觉规范偏离或交互断层，都会引发多轮震荡修复；而全局设计的偏差，更可能导致整个任务图的失效与重构。

这类系统的优化目标需要围绕三个核心架构问题展开：

1. 终局边界：怎样的结果才构成真正的“完成”；
2. 推理边界：哪些状态转折点值得引入大模型的非确定性推理；
3. 控制边界：已确定的计算与规则工作流应当如何高效执行。

本文梳理该系统在过去数月演进中的架构迭代逻辑：系统从最初依赖模型自由探索的 ReAct 模式，逐步收敛为基于契约解耦、确定性工作流与上下文拓扑优化的高效率架构。

1. 演进困境：当事后审查成为成本与时延的黑洞

在早期架构中，系统采用 ReAct 机制驱动整个生成生命周期。Agent 根据当前状态推理下一步动作，调用工具执行代码编写或校验，并依据反馈决定继续生成、修复还是终止任务。

为了确保交付质量的下限，设计者在 ReAct 循环中逐渐叠加了多层审查机制。每次页面生成后强制进入审查环节，若发现缺陷则触发修复，修复完成后再次校验。

graph LR
    A[页面实现] --> B[审查评估]
    B -- 发现问题 --> C[修复]
    C --> B
    B -- 通过 --> D[交付]

这一阶段的架构在效果维度拦截了低质量产物到达交付门禁。但在系统工程维度，过度依赖事后审查产生了显著的副效应：

• 计算链路膨胀：每一轮审查都伴随着完整的上下文装载、模型推理与工具交互。修复过程可能改写原本正确的模块，引发连锁式的二次审查。
• 长尾时延显著：在复杂场景下，单次任务的模型成本经常超过 20 美元，端到端耗时突破 60 分钟。
• 结果确定性降低：即便简单任务也可能因模型评估的波动陷入多轮审查，导致服务时延承诺难以保持稳定。

在一组复杂度分布一致的代表性样本中，Review-heavy 版本已经出现了非常典型的长尾：

这组数字揭示了一个反直觉现象：更多 Review 确实抬高了效果下限，却没有同步提高有效交付能力。相反，它让系统用越来越多的成本，换取越来越不确定的完成时间。

在此背景下，系统的改进方向从单纯追求高成功率，转向在可控成本与时延约束下提供工程可用性。

2. 指标重塑：定义“有效交付效率”

为衡量架构演进的实际收益，系统引入了有效交付效率这一核心工程指标。

在传统服务中，吞吐量统计处理的请求数，有效吞吐量则强调满足服务质量目标的请求。在 Agent 系统中，单次用户请求包含数十次模型调用与多次内部修复，因此最小评估单元应当设为完整的交付结果。

系统将有效交付效率定义为：

这一指标用于衡量：系统每消耗 100 美元算力，能在承诺时限内交付多少个合格的产品原型。

公式对分子与分母施加了明确约束：

• 分子筛选：仅包含同时满足“产品完整度达到标准”且“端到端耗时在规定范围内”的任务；
• 分母核算：包含全量算力开销，涵盖模型 Token、工具运行、中间审查、失败任务的重试及未完成任务消耗的资源。

有效交付效率明确了架构优化的先后顺序：在效果达到交付标准的前提下，首先将时延收敛至合理区间，在此基础上最小化完成任务的算力成本。

为了让不同阶段能够横向比较，以下数据采用同一组任务结构进行归一化：每个阶段取 40 个代表性任务，共 200 个样本，覆盖 2～6 个页面，并统一以 8 分钟作为交付 SLA。成本分母包含失败、取消前消耗和重试；旧版本数据由历史架构表现与同任务集回放估算，当前版本以 staging trace 的量级进行校准。因此，这些数字用于表达架构趋势，而不是生产经营或财务审计口径。

真正的拐点不是换用了更便宜的模型，而是系统先减少了不必要的推理，再让剩余推理以更高并发、更高缓存命中率运行。叠加 Review 的 5 月反而形成效率低点，也说明单独提升效果下限，并不等于系统整体更有效。

3. 阶段一架构重构：规划前置与不确定性的集中压缩

指标演进推动系统将不确定性的压缩集中到执行阶段之前。

新架构在实现阶段之前引入了显式的规划节点。规划节点集中定义了三类系统级契约：

1. 任务拆分契约：确定产品包含的具体页面树与边界；
2. 共享约束契约：收敛全局视觉规范、通用组件库与数据流模式；
3. 验收契约：明确判定任务完成的客观条件。

graph TD
    subgraph 旧架构
        O1[页面 A 独立理解需求] --> O2[实现] --> O3[全局审查发现偏差] --> O4[重构]
    end

    subgraph 新架构
        N1[规划节点生成全局契约] --> N2[页面 A 边界内实现]
        N1 --> N3[页面 B 边界内实现]
        N1 --> N4[页面 C 边界内实现]
        N2 --> N5[确定性门禁校验]
        N3 --> N5
        N4 --> N5
    end

在旧架构中，每个页面生成节点独立理解整个产品，容易产生决策冗余与方向偏离；规划节点将全局设计决策前置，使下游子任务聚焦于明确边界内的局部实施。

事后审查机制随之转变为确定性门禁与局部修复。系统优先校验产物是否符合事先约定的交付契约，减少无差别的长链模型审查。

4. 阶段二架构重构：安全并行与上下文拓扑优化

全局规划契约的确立，为系统开辟了执行流并行化与上下文共享缓存优化的空间。

4.1 基于契约的独立并行

在获得稳定的规划契约后，页面级实现任务共享相同的产品事实，可独立并行推进。

• 串行耗时：\( T_{\text{serial}} \approx T_{\text{plan}} + \sum T_{\text{page}} + T_{\text{gate}} \)
• 并行耗时：\( T_{\text{parallel}} \approx T_{\text{plan}} + \max(T_{\text{page}}) + T_{\text{gate}} \)

系统将端到端耗时的增长模式从随页面数量线性累加，转变为由最慢关键路径决定。

按页面数量分桶后，并行化的收益更加直观：

旧架构的耗时随页面数量近似线性增长；新架构中，页面数增加主要扩大并发宽度，而不再等比例拉长关键路径。与此同时，完整交付率没有因为并行而下降，说明 Plan 已经把原本由末端 Review 承担的质量底线前置到了执行之前。

4.2 树状上下文拓扑与前缀缓存

并行化后，不同页面分支的上下文存在大量重叠，包括全局需求、产品结构与视觉约束。

新架构将输入上下文结构化解耦为全局静态前缀与局部动态任务两部分。

flowchart TB
    P["全局静态前缀<br/>需求 · 结构 · 视觉约束 · 规范"]
    P -->|Prefix Cache 共享| A["页面 A<br/>局部任务"]
    P -->|Prefix Cache 共享| B["页面 B<br/>局部任务"]
    P -->|Prefix Cache 共享| C["页面 C<br/>局部任务"]

全局静态前缀利用推理引擎的 Prefix Cache 特性建立 KV 缓存，后续并行分支均可复用该缓存。

工程实践表明，原型复杂度越高、页面数量越多，前缀缓存的相对成本收益越显著。首次写入开销被多个分支摊薄后，复杂原型的上下文获取成本下降超过 80%。

这里需要区分三个口径：“超过 80%”描述的是复杂任务中重复上下文的获取成本，而不是整个任务的总成本。模型仍然需要为每个页面生成不同的实现，工具和门禁也不会因为缓存消失。即便如此，仅通过调整上下文拓扑，5～6 页原型的完整任务成本仍下降了 56%。

5. 阶段三架构重构：从开放 ReAct 到有界工作流的收敛

解耦任务边界与上下文开销后，系统进一步解决 ReAct 循环带来的不确定性执行时长。

ReAct 适合探索未知空间。但在任务目标与验收标准已明确的阶段，继续由模型自主决定是否持续审查，会增加执行过程的熵增风险。

新架构将确定性的执行逻辑从 ReAct 抽离，收回至确定性的状态机工作流中。

flowchart LR
    P["规划<br/>Agent 探索"] --> E["分支并行<br/>工作流控制"]
    E --> G["契约门禁<br/>规则校验"]
    G -->|通过| D["交付"]
    G -->|失败| R["异常修复<br/>局部 Agent"]
    R --> G

在新控制流中：

• 工作流 掌控分支并发、超时控制与重试次数上限；
• 门禁 提供客观的校验信号；
• Agent 集中在规划阶段的开放决策以及门禁未通过时的局部有界修复。

当门禁校验通过时，工作流立即终止，拦截无意义的优化循环；校验失败时，修复上下文限定在报错模块内部，避免全局重跑。

这种控制收敛降低了长尾耗时。在当前标准化成功交付样本中，端到端耗时的最小值为 2.1 分钟，P50 为 4.1 分钟，P95 为 7.6 分钟，极大值为 8.0 分钟。简单任务因此可以在约 2 分钟内完成，复杂任务也被控制在 8 分钟的 SLA 范围内。

成本长尾也随控制流一起收敛。当前简单原型的单任务成本可以降至 0.6 美元；随着页面数和交互复杂度增加，成本仍会上升，但不会再被无限 Review 放大。

更重要的是，8 分钟不只是一次较好实验的观测值，而是控制流设计出来的边界：分支并发、重试预算、局部修复范围和终止条件共同决定了系统不会再次滑入无限 Review 的极端长尾。

6. 架构反思：重构任务图本身

当前针对 Agent 系统的效率优化路径包括：

• Anthropic 建议从极简架构切入，按需增加复杂度；
• OpenAI 建议建立基线后，尝试小模型替换；
• EvoRoute 等研究采用动态路由，为不同步骤匹配合适的模型；
• AI21 Maestro 在多维空间中搜索 Agent 的协同配置。

这些方法侧重于在既定任务图上优化模型分配与参数策略。

本系统的演进侧重于重构任务图本身：

flowchart LR
    subgraph ROUTE["模型路由优化"]
        R1["给定任务图"] --> R2["选择模型"] --> R3["优化路由策略"]
    end
    subgraph SYSTEM["本系统的优化"]
        S1["重构任务图"] --> S2["规划前置"] --> S3["契约解耦"] --> S4["控制流收敛"]
    end

模型路由确定执行载体；而规划约束、确定性工作流、门禁校验与前缀缓存拓扑，从根本上减少不必要的推理发生。

7. 结语

该系统自 4 月以来的架构演变涵盖三个阶段：

1. 粗放探索期：依靠审查机制保障质量下限；
2. 结构解耦期：通过规划集中压缩不确定性，结合前缀缓存与并行化优化算力拓扑；
3. 控制收敛期：利用确定性工作流替换 ReAct 开放循环，实现时延与成本的明确控制。

以 5 月稳定版作为基线，在相同质量标准与 SLA 约束下，系统每 100 美元完成的合格原型数从约 1.03 个提升至当前的约 99.43 个，整体有效交付效率提高约 96.3 倍。更直观地看，旧 Review 框架中经常超过 20 美元的任务，在当前架构下，简单场景已经可以用约 0.6 美元完成。

复杂 Agent 的系统工程优化遵循三条原则：

系统架构的核心职责在于大模型调用前明确判定：这一次推理是否需要发生。