功能解释 01: Orchestration引擎

从第一个任务到审核过的补丁

Agent Argo并非由一个单一模型组成，该模型可能长时间处理一项任务。它是一个将软件工作转化为可追溯步骤的系统：计划、拆分、处理、审核、修正，最后再提交。

随着本文的开始，"功能解释"系列也拉开帷幕。该系列旨在通过实际应用场景而非营销承诺，使Agent Argo的核心机制变得清晰。这一系列的开端是协调引擎：它将需求转化为可控的工作流程。

1. 开始前：确定质量、成本和自主性

在Argo开始处理任务之前，两个决定至关重要。它们故意分开：

1. Argo如何在成本和结果质量之间权衡？
2. Argo在项目中允许多自主？

这可以避免典型的目标冲突：一个彻底的流程不必自动获得更多写入权限。一个自主的流程也不必自动选择昂贵的模型。

成本和质量的三个阶段

模型路由器了解三种可理解的模式。它们改变价格和模型层级在选择中的影响力；所需技能始终是核心。

阶段	路由器模式	适用于
节省型	economy	常规任务、提取、明确的更改。成本权重较大。
平衡型	balanced	大多数运行的标准：技能匹配、成本和质量层级保持平衡。
高要求型	expert	架构、研究、复杂分析和严格审查。模型层级权重显著，成本较少。

运行配置文件"快速且廉价"、"平衡"和"严谨"将这些路由器模式与其他决策结合：例如，共享思考是否仅被观察或主动执行，验证是否具有约束力，以及Argo在失败时是否允许更强烈的升级。

自主性的三个阶段

自主性并非决定Argo认为什么是正确的，而是决定它何时需要人类。

阶段	行为
安全	Argo分析并计划。更改需经过审核；在写入或风险较高的操作前会询问。
平衡	可在隔离工作状态下产生常规更改。在删除、命令、下载、网络访问或受保护路径时，Argo会进一步询问。
完全自主	运行不需要常规的人类反馈。严格的安全、政策和预算限制仍然适用。

这些规则在代码中比readonly、confirm_write、auto_write和bypass更详细实现。三个阶段使它们可操作；但项目政策始终是最终权威。它可以排除云提供商，仅允许本地模型，阻止网络访问，限制命令，保护敏感信息或设置成本上限。

2. CEO层将任务转化为计划

用户最初用普通语言描述目标。Argo的CEO层获得有限的项目概览、可用模型目录和相关项目信息。它可以在开放问题时先提问或生成计划。

计划不仅仅是待办事项列表。每个任务都会被分配角色、描述、依赖关系和所需技能——例如coding、planning、qa_review或context_comprehension。对于困难任务，还可以记录更高的难度。CEO层并不严格指定模型：它描述工作，路由器后来会为每个任务决定合适的模型。

因此，计划成为人类可读的协议，而执行可以保持适应性。

3. 计划转化为任务图

在计划获批后，Argo将任务转化为任务图。一个节点只能在其依赖项成功完成后运行。独立任务可以并行运行。

调度器根据一种可理解的效用启发式对准备好的节点进行排序：预期质量减去成本、时间和风险惩罚。如果一个节点在关键路径上，在平局时会优先，因为它决定了整个运行的总时长。

在高不确定性或高风险情况下，Argo可以在处理之前选择一个共同思考模式：多个视角开发方法，相互批评并提供有根据的工作方案给Worker。是否仅记录或真正执行，由之前选择的运行配置文件决定。

4. 每个任务前：合适的上下文、技能和模型

在Worker启动前，Argo会为角色和任务构建定制的上下文。这包括相关文件、依赖项结果——如果启用的话，还包括紧凑的内存包和适当的技能指南。Argo不会盲目将整个项目知识纳入提示。内存和技能会根据相关性、来源、时效性、成本和安全状态进行选择。

然后，模型路由器选择模型。首先排除不可访问的、上下文窗口不足、配额耗尽或违反活动政策的候选模型。从剩余模型中，Argo评估四个因素：

• 技能匹配度：模型对所需技能的评估如何？当有多个技能时，会考虑平均值。
• 成本：请求的费用——或在启用成本路由时预期成功结果的费用？
• 模型层级：困难、安全关键、架构和审查任务可以优先选择旗舰层级。
• 经验值：在足够多的真实结果后，最近的成功率和重复率对于模型/技能组合会流入。

对于成本计算，Argo可以使用成功成本预期值：直接价格、预期重复次数、验证开销、可能的修复工作和小的延迟惩罚。一个廉价的单次调用并不总是最便宜的解决方案，如果它经常失败或触发修复工作。

只有在可用、符合政策且足够大的情况下才会接受明确的模型建议。CEO层的计划、委托和上下文理解也使用专门为这三个技能选择的强大模型。

5. Worker在小步骤中处理任务

Worker不会用单一回答。它会经过一个有限的ReAct循环：

1. 模型提出结构化的动作——例如读取文件、搜索、运行测试或写入更改。
2. 执行器检查权限、路径、命令风险和活动政策。
3. Argo仅执行允许的动作。
4. 结果、差异和错误消息作为观察返回给模型。
5. 基于此，Worker修正下一步或关闭任务。

这样，Agent可以先读取受影响的代码，然后进行更改，运行测试，并将测试结果纳入下一步决策。整个流程在运行日志中可见。

输出本身也会被检查。如果模型提供无效的动作JSON，Argo可以请求有限的修复循环。在严格模式下，持续错误的输出会被控制性拒绝，而不是被解释为动作。

6. 错误时：有针对性的修正而非盲目重试

并非每个失败的任务都意味着整个运行失败。协调引擎区分错误原因并做出受控反应：

• 临时错误可以在固定限制内重试。
• 严格验证结果会提供具体批评作为下一次尝试的任务。
• 如果启用级联处理，下一次尝试会继承之前的见解，而不是从零开始。
• 在失败后，Argo可以优先选择更强大的模型。
• 如果预算耗尽，不会启动昂贵的盲目尝试：节点会以记录的部分结果结束或可见地升级。

节点策略最终决定任务是否可以跳过、失败或需要用户决定。依赖任务只能获得确认的部分结果。这样，局部错误不会变成静默错误，继续影响整个计划。

7. 完成后：审查、验证和可能的另一个循环

当计划任务完成后，Argo会从多个角度检查集成状态：

• QA代理可以读取文件并执行测试命令。
• 架构代理以只读方式检查结构，并保持明确的无写入权限。
• 确定性验证器可以执行测试、类型检查或linting作为客观的标准。
• 模型基础和确定性发现结果会合并成总体判断。

如果QA、架构或强制验证器发现问题，Argo会将发现归因于相关任务。只有这些任务会使用具体反馈重新处理。之后再次进行审查和验证。如果没有共识模式，这个循环是有限的；在明确选择的共识模式下，它会继续运行，直到用户停止或审查者同意。

验证器在观察模式下记录发现但不阻止。在强制模式下，严格的发现可以阻止结果被视为成功。这样，严格性可以根据运行配置文件选择，而不牺牲可追溯性。

8. 只有在状态被验证后：文档和CEO总结

在完成工作和验证循环后，文档代理可以记录更改。随后，CEO层为用户创建总结：完成了什么？哪些仍然开放？哪些验证通过了？哪些文件或决策受影响？

结果不仅仅是聊天文本。运行会生成计划、模型选择、成本、操作、验证判断、用户中断和后续补丁决策的共同标识。这样可以追溯Agent Argo如何得出结果。

9. 最后由人决定真正的工作空间

默认情况下，Argo在隔离的工作树中工作。更改在那里作为补丁存在，而不是直接在真实项目中。根据自主性阶段，随后会发生以下三种情况之一：

• 补丁保持待接受、部分采用、编辑或拒绝的状态。
• 成功的补丁会自动应用。
• 如果与中间更改的文件发生冲突，Argo会停止可见；它不会覆盖他人的更改。

失败的运行不会自动应用。即使高度自主的配置也不会绕过政策：秘密保护、命令规则、提供商限制、预算限制和必要的人类门槛仍然有效。

协调引擎的作用

协调引擎不仅决定下一个回答的模型。它将用户意图、设置、计划、并行化、模型选择、工具使用、错误修正、质量保证和安全接管连接成一个连贯的流程。

标准不是"尽可能多的Agent"。额外工作只在合理的情况下发生：为复杂的架构决策使用更强大的模型，在不确定性时使用第二个思路，在验证者批评后有针对性的重试，或在风险影响前的人类批准。

因此，方向已设定。