软件工厂分解工作的惊人复杂艺术

构建软件工厂最棘手的问题之一，是决定工作内容本身。一个宏大的目标以人类语言呈现，但智能体需要的是更具体的东西。必须有人或某种机制去理解意图，并发现实现该意图所需的工作单元。系统需要确定哪些单元应归为一组，识别依赖关系，决定哪些可以并行处理，并在工作推进过程中保持这种理解的最新性。

人们很容易认为，当今先进推理模型可以独立解决这个问题。事实上，如今的模型确实能够接受宏大目标，推理如何着手处理，并将工作单元委派给子智能体。它们在这方面已经出奇地擅长。

但软件工厂需要的远不止这些。它需要自身的智能来围绕这些委派决策塑造、跟踪和修订工作。这正是软件工厂与智能体框架之间的关键区别之一。

模型周围的系统日益塑造着工作本身。正因如此，分解和委派工作成为当今AI领域最有趣的创新所在。

Codex、Claude Code、Gemini CLI、Vercel的eve、OpenAI的Symphony、Warp和Factory都在分解工作，但各自采用不同方法。让我们探讨其中一些方法。在较为简单的一端，模型为子智能体生成提示词。在更具雄心的一端，工厂本身演变为智能规划系统。

1. 子代理委派

分解的最简单形式是直接委派。模型审视一个大型目标，识别出其中较小的部分，为另一个代理创建提示词，并为该执行者提供足够的上下文以完成任务。

如果你要求一个代理添加企业级单点登录（SSO），它可能会决定一个子代理调查现有认证系统，另一个检查所需的数据库变更，还有一个负责前端工作。每个执行者都获得有界任务，通常还有独立的上下文。

Claude Code 的子代理大致遵循此模式。Codex 为模型提供了生成和管理其他代理的原语，并能递归委派，允许执行者发现另一项工作并为其创建子代理。Vercel 的 Eve 同样允许父代理创建隔离的子会话，并可要求这些执行者返回结构化结果。

这已是令人印象深刻的模型能力。模型必须充分理解更大的目标，以便为工作划定有用的边界，同时还需决定每个执行者需要哪些信息。分解工作与分解上下文密切相关。

但大部分结构仍存在于提示词中。父代理可能知道某个任务因特定需求而存在，或另一任务需待某项架构决策确定后才能开始，而系统本身对这些关系缺乏持久的表示。

2. 跟踪任务

下一步是将那些推断出的工作项转化为任务对象，以便软件能够协调处理。

Gemini CLI 的任务跟踪器允许模型创建任务和史诗、建立依赖关系并更新状态。Claude Agent Teams 为代理提供带有所有权和依赖关系的共享任务列表。OpenAI 的 Symphony 可以利用 Codex 为更大的目标生成实施任务和依赖关系，然后将它们持久化到 Linear 中，同时 Symphony 在任务符合条件时进行调度。

这在模型智能与传统软件之间建立了一条明确的界限。模型可以推断出 API 工作依赖于模式变更，但一旦发现这种依赖关系，就没有理由反复询问 LLM API 任务是否受阻。常规的调度器就能强制执行这一点。

任务图本身并无创新之处。ID、状态、队列、DAG、重试或依赖解析同样如此。这些我们已实践了几十年。较新的能力在于，能够基于对目标和软件环境的理解来生成任务图。

因此，跟踪任务解决了一个重要的系统问题，但它们仍未触及更棘手的核心问题：究竟是什么应该首先决定任务分解的方式？

3. 工厂形态的工作

与其让模型从零开始凭空构想流程的每一个环节，工厂可以提供一种理解与划分工作的结构。这种结构能够编码组织实际构建软件的方式：工作经历的阶段、涉及的岗位、适用的政策、可用的技能、所需的审批，以及过程中应产出的各类工件。

Warp的工厂架构便是一个有用的例子。工厂可以围绕分诊、规格说明、实现和审查等阶段来定义代理，并关联相应的模型、工具、技能、权限及交接流程。模型仍需解读进入的工作，但它在已有组织期望如何构建软件认知的定制化系统内进行这一过程。

一个带有“生成代理”工具的通用模型几乎可以任意发明它想要的分解方式。而软件工厂则能为模型提供一套关于优质工作的词汇或模式。例如，它可以规定某些请求在实现前必须先有规格说明。该词汇还可以要求某些变更在编码开始前产生架构决策，或在完成后接受安全审查。

工厂可以一次性编码这些期望，并将其融入未来每一次工作分解中。

这正是工厂贡献其自身真正智能之处。模型仍提供语义理解，但分解不再仅仅是模型先验知识及恰好能塞进其上下文窗口的内容的产物，而是由组织的工作方式所塑造。

4. 成果导向的工作

即便是设计精良的工厂，也可能将项目拆解为看似合理的任务，却仍未能达成项目的整体目标。

这是分解过程中最深层的问题之一。如果模型在开始时误解了目标，它可能制定出内部一致的计划，成功执行每项任务，却仍未能交付用户所需。更好的调度无济于事，因为错误的工作正被完美地安排执行。

Factory的Missions架构之所以引人注目，是因为它在实施开始前就着手解决这一问题。系统首先制定一份验证契约，包含关于任务成功时应成立的行为断言。随后，实施特性便围绕这些断言来创建。

系统并非简单询问哪些任务听起来合适，而是能够推理其提议的工作是否覆盖了期望的成果。原则上，如果目标隐含八种行为，而工作图只涉及其中七种，这一差距便能在执行前或执行过程中显现，而非在所有任务标记完成后才发现。

作为此推理过程的一部分，系统生成的图不仅代表执行顺序，更代表了人类意图与工厂应对措施之间的关系。

随着代理自主性增强，人类无法检查每一个中间决策。工厂需要自身对工作为何与原始目标相关这一问题的持久表征。

5. 动态工作图

最新的创新之一，是当首次分解出错时该如何应对——而这种情况往往会发生。

软件工作本质上是一种探索。实现API的代理可能会发现真正的约束存在于数据模型中。一次迁移可能暴露出未记录的兼容性要求。两个被认为相互独立的任务可能会在同一抽象上发生冲突。一个验证步骤可能会揭示一整类缺失的工作。

静态任务图在处理这些发现时表现不佳。工厂可以重试失败的工作，或让代理修复错误，但项目的基本模型本身可能就有问题。

动态工作图允许工厂修正其对工作的理解。当代理发现一个任务包含两个独立问题时，可以将其拆分。当工作人员发现他们的假设重叠时，可以引入新的依赖关系。当上游接口发生变化时，下游工作可以被判定为无效。因为验证暴露了初始规划者遗漏的内容，全新类型的工作也可能出现。

Codex的递归委派已经提供了这种能力的简单形式，因为工作人员可以在执行过程中发现并创建更多工作。Factory的验证循环同样可以暴露缺口，从而引出额外的实现工作。拥有持久任务图的系统有机会让这些修订对整个工厂可见，而不是将它们埋藏在单个代理的对话中。

这是软件工厂中较为重要的新兴能力之一，但它仍不成熟。这些能力都尚未完全成型。传统的工作流引擎擅长执行某人已经设计好的流程，而软件工厂则越来越需要在执行过程中发现流程。

因此，初始的工作图谱更应被视为一种假设。工厂提出一种关于如何达成目标的理解方式，开始执行，并利用其代理所学到的经验来完善这一理解。

围绕工作模式所需进行的未来研究

一个值得更多关注的领域是我们用来表示工作的模式。当前大多数系统过于偏向某一端。要么由协调者掌控工作，代理仅执行分配的任务；要么由代理自行决定分解方式，而外围系统大多只是观察它们的决策。

这两种极端对于真正的软件工厂而言似乎都不够充分。工厂需要足够的结构来确保工作如何被塑造、追踪、与成果关联，并在众多代理间进行协调。但代理也需要足够的自由度，以便发现当前计划有误、创建新工作、调整依赖关系、拆分任务，或引入工厂事先无法预见的工件和证据。

这暗示我们需要更对称的工作模式。协调者和代理应基于同一底层模型运作，即便它们拥有不同的权限和责任。

研究问题在于如何将它们连接到一个模型中，该模型既要足够表达力强，以便代理能够扩展；又要足够结构化，以便工厂能够治理；还要足够持久，以跨越众多工作者和多轮重新规划。

这似乎是软件工厂下一步的重要方向。运行更多代理正变得越来越容易，调度和协调它们的基础设施也在迅速成熟。更棘手的问题在于创建一个共享的工作表示，使工厂和代理都能理解并共同演进。

那些做对了的软件工厂，将不仅仅拥有更好的编排能力。它们会找到一种更佳的方式，将人的意图转化为工作，使这些工作始终与目标保持一致，并在现实让系统对问题有了更深刻理解时，及时调整计划。