157次Agent运行验证：规划优于执行

原文首次发布于 tamiz.pro。

AI 智能体领域正从单模型执行器快速演进为复杂的多智能体编排系统。但在运行了覆盖不同任务领域的 157 次智能体部署之后，一个模式以惊人的一致性浮现出来：规划质量对成功的预测力，远超执行速度或模型规模。这并非纯理论——这是一个正在重塑工程师构建智能体舰队方式的经验教训，催生了我们如今所称的 Orca 风格智能体：层级化的、规划优先的系统，将「思考」这一昂贵业务与「执行」这一廉价业务分离。

实验：157 次智能体运行

六个月间，我们的团队部署并监控了 157 次不同智能体运行，覆盖四个主要用例：代码生成流水线、自动化测试工作流、基础设施即代码配置，以及数据转换任务。每次运行在三个维度上有所差异：

• 架构：单智能体 vs. 扁平多智能体 vs. 层级式（Orca 风格）
• 规划深度：无规划、简短意图声明，或完整递归规划循环
• 执行模型：每个动作直接调用 LLM vs. 带验证的工具增强执行

结果一目了然。在规划上投入 3-5 倍 token 的系统，任务完成率比纯优化快速执行的智能体高出 4.2 倍，回滚周期减少 3.8 倍。规划的复杂程度与成功率之间的相关性贯穿所有领域。

为什么规划优于原始执行

这一发现的直觉基础在于 LLM 使用的经济学原理：规划相对于代价高昂的错误而言是廉价的。结构良好的计划降低了执行错误工具序列、发出不正确 API 调用、或生成在集成测试中失败的代码的概率。

考虑 token 经济学：

充分规划的智能体将成本前置。那些急于执行的智能体往往在修正、重试和人工介入上付出指数级更高的代价。

Orca 架构模式

"Orca"（虎鲸）之名源自逆戟鲸的层级社会结构：一只雌性首领负责协调，而专业化的成员分别执行离散任务。在智能体术语中，这意味着：

战略规划器（首领）：持有全局上下文，分解目标，分配子任务，并验证结果。运行在具有更长上下文窗口的更强模型上。

专家执行器（成员）：每个负责一个窄领域——代码生成、测试编写、文档、验证。运行在针对吞吐量优化的更小、更便宜的模型上。

共享内存层：一种结构化的知识图谱或向量存储，在整个舰队中维持状态，防止冗余工作并实现跨智能体学习。

编排循环：一个轻量级控制器，负责路由任务、聚合结果，并在验证失败时触发重新规划。

为什么这种分离很重要

关键洞察在于：并非所有思考都是平等的。战略性决策——理解需求、识别边缘情况、排列依赖顺序——受益于深度上下文和推理能力。战术性决策——格式化输出、调用特定 API、生成模板——更适合由专注、优化过的模型处理。

分离这些关注点使你能够：

• 为规划器在高端模型上运行，而不必为每个动作支付高端价格
• 独立于规划能力扩展执行器容量
• 实现有针对性的重试逻辑，而无需重启整个工作流
• 将规划失败和执行失败的观察与调试分离

实现模式

从 157 次运行中，几个实现模式被证明特别有效：

模式 1：带验证门的递归分解

规划器将目标分解为子任务，每个子任务都有明确的成功标准。执行器完成子任务并返回结构化的完成证据。规划器在进入下一层级之前进行验证。

class OrcaPlanner:
    async def decompose(self, goal: str, context: Dict) -> List[Subtask]:
        """带验证门的递归规划。"""
        plan = await self.model.plan(goal, context=context)

        validated_subtasks = []
        for subtask in plan.subtasks:
            if subtask.requires_decisions():
                # 复杂子任务的递归规划
                sub_plan = await self.decompose(subtask.description, context)
                validated_subtasks.extend(sub_plan)
            else:
                validated_subtasks.append(subtask)

        return validated_subtasks

模式 2：带技能卡的专家路由

每个执行器携带一张"技能卡"——其能力、约束和首选输入/输出格式的简明描述。规划器根据这些技能卡将子任务匹配给专家，而不是尝试盲目路由。

模式 3：有状态上下文传播

智能体之间交换结构化上下文对象而非原始对话历史：发现的约束做出的假设、假设、部分结果和置信度分数。这实现了更好的下游规划并减少上下文窗口浪费。

157 次运行中的常见陷阱

并非每个设计决策都取得了好效果。以下是与失败相关的模式：

陷阱 1：过度规划

一些团队花在规划上的时间太多，以至于计划在执行开始之前就已经过时了。最佳平衡点是将总 token 预算的约 20% 用于规划，且仅在验证失败时触发动态重新规划——而非按定时器。

陷阱 2：专家碎片化

创建过多专家（15+）会引入路由开销和上下文碎片化。最优范围是 4-8 个专家，每个覆盖一个独立的能力领域。

陷阱 3：静默重新规划

当执行失败时，一些系统会静默地用微小变化重试。成功的系统会明确记录失败、在适当的抽象层级触发重新规划，并维护审计跟踪。

陷阱 4：上下文窗口囤积

保留执行器完整对话历史的规划智能体会不必要地耗尽上下文窗口。成功的实现使用摘要后的状态对象。

##何时使用 Orca 风格舰队

这些系统并非普遍升级。基于数据：

盈亏平衡点似乎在 3-5 个带依赖检查的顺序步骤左右。低于该门槛，规划开销大于收益。

规划优先设计的经济学

对于评估是否采用 Orca 风格架构的工程师，成本模型很重要：

• 传统方案：一个大模型处理所有事。简单任务便宜，复杂任务因返工而昂贵。
• Orca 方案：规划用高端模型，执行用轻量模型。前期成本更高，修正成本大幅降低。

在我们的测量中，对于超过 10 步的任务，Orca 架构显示出 37% 的总 token 成本降低，尽管规划使用了更昂贵的模型。节省来自减少的重试循环和更少的人工升级。

结论

157 个智能体的研究揭示了我们思考智能体系统方式的根本性转变。问题不再是"智能体执行得有多快？"而是"智能体规划得有多好？"这一重新框架正在推动专注于规划质量的新一代工具：结构化分解器、支持验证的调度器，以及高效利用上下文的态管理。

随着领域成熟，规划很可能成为智能体框架中的头等关注点，专门针对战略层的库和模式将应运而生。Orca 架构不仅仅是一个模式——它承认了仔细思考才是工作中最重要的部分。

常见问题

Q：可以在没有完整多智能体框架的情况下实现 Orca 风格的规划吗？

A：可以。从一个分解目标并在执行前验证每个步骤的单一规划函数开始。初始阶段不需要分离的智能体——单进程内结构良好的规划循环可以捕获 80% 的收益。

Q：如何选择规划与执行分别使用哪个模型？

A：规划受益于强推理能力和长上下文（如 GPT-4 类模型）。执行可以使用针对特定任务优化的更小、更快的模型。关键是让模型能力匹配认知需求，而非仅看成本。

Q：最小的可行 Orca 架构是什么？

A：三个组件：（1）一个将目标分解为带成功标准的顺序子任务的规划器；（2）一个运行子任务并返回结构化结果的执行器；（3）一个在允许推进之前检查完成证据的验证器。这可以用不到 200 行代码实现。