# 无人值守的代码军团：Missions多智能体架构方案底层原理深度解析

> **编排器 x 工作者 x 验证者** —— 软件工程瓶颈从智力向注意力转移的范式变革

---

## 一、引言：上下文稀释 —— Agent系统的根本瓶颈

2026年的软件工程领域正在发生一场静默而深刻的范式转移。Factory.ai在其技术博客中抛出了一个核心论断：**软件工程的瓶颈不再是智力，而是人类注意力**（human attention）。即便是最优秀的工程师，同一时间也只能聚焦少数几个任务；无数高价值的特性因人力约束而被搁置在 backlog 深处，永远无法排上开发日程。

这一判断直接指向了AI Agent领域的核心命题：当模型能力突飞猛进、上下文窗口不断扩容，为什么单个Agent在复杂项目上依然表现乏力？

答案隐藏在 **上下文稀释（Context Dilution）** 这一现象中。

Factory的研究团队指出，Agent对其上下文具有高度反应性（highly reactive to context）。Agent的轨迹（trajectory）是追加式的（append-only），模型在任意时刻的推理，都是其过往所有思考、观察与行动的函数。模型追求连贯性：它将上下文中的所有信息整合为统一的世界观，并据此向前推理。因此，当轨迹中的每一步都将Agent推向下一步最优行动时，其表现最佳。

当上下文窗口中累积了与当前目标无关、甚至 actively working against 当前目标的信息时，性能就会下降。两种失败模式由此产生：

**（1）无关上下文累积（Irrelevant context accumulates）**

任务范围过于宽泛时，Agent的上下文会不断增长，其中大量信息与当前工作无关。范围越广，上下文中推动Agent朝向最优下一步的信号比例就越低，信噪比持续衰减。

**（2）对抗性上下文累积（Adversarial context accumulates）**

实现了某项功能的Agent，在客观评估自身工作方面，远不如一个全新、无偏见的评审者。其先前的推理会产生一种 **确认偏误（confirmation bias）** —— 倾向于确认自己已经做过的事情。 prior reasoning anchors evaluation，评估被先验推理锚定，远离正确的评估区域。

Factory给出的解决方案名为 **Missions** —— 一个让多智能体团队能够无人值守、连续运行多日而不偏离轨道的工程架构。这不是概念的堆砌，而是经过生产环境验证的系统性方法论。

---

## 二、设计原则：从问题到方案的推导

Missions架构的大多数设计决策都源于上述核心观察。以下是四个关键设计原则：

### 2.1 关注点与激励的分离（Separation of concerns and incentives）

每个角色拥有单一目标，系统结构确保Agent的轨迹中没有任何因素将其从目标上拉扯偏离。

- **Orchestrator（编排器）**：规划并分解用户目标的实现路径，驱动执行直至完成，通过所有验证关卡。它避免积累过于细粒度的上下文，将所有深入调查和实现委派给子Agent和工作者。它不直接驱动验证 —— 系统在里程碑处注入验证器以发现问题。

- **Workers（工作者）**：完成具有明确成功标准的、定义良好的功能。它们迭代工作直至自认正确，然后交接。但关于正确性的最终判定权不属于工作者 —— 独立的验证者做出这一决定。

- **Validators（验证器）**：评估已完成工作的正确性与完整性，发现bug与遗漏。它们不实施修复 —— 而是将问题暴露给编排器，由编排器创建修复功能，由后续工作者实施。

### 2.2 双层测试驱动开发（Test-driven development at two levels）

同一原则在两个尺度上同时运作：

**尺度一（工作者级别）**：每个工作者在写代码之前先写测试，确保测试反映预期行为而非实现细节。

**尺度二（Mission级别）**：编排器首先定义正确性 —— 在定义任何功能之前创建 **验证合约（Validation Contract）** ，即一组定义成功的、可测试的行为断言集合。

这一顺序至关重要。创建验证合约时，编排器从对需求的理解出发。如果先创建功能再制定合约，合约将被已经规划好的实现所影响。

这些断言后续由全新的Agent验证，它们像真实用户一样 **将系统作为黑盒使用（exercise the system as a black box）** —— 而非检查实现它们的代码。

### 2.3 状态外部化（Externalized state）

没有任何单一Agent需要在其上下文中同时持有完整图景。完整状态分布在共享制品（shared artifacts）中：验证合约、功能列表、研究笔记、操作指南，以及一个随Mission运行不断演化的知识库。

每个Agent只读取与其当前工作相关的内容。即便是编排器，也将深入调查委派给子Agent，以避免自己消耗每一个细节。

### 2.4 模型专业化（Model specialization）

不同模型具有不同优势 —— 推理能力、纪律性、创造力、 thoroughness、速度、成本。没有任何单一模型在所有维度上都是最优的。

一旦角色被 cleanly separated，模型选择就变为每个角色的本地决策：编排器需要宏观规划与判断力，工作者需要可靠执行与成本效率，验证器需要 thoroughness 与 skepticism（彻底性与怀疑精神）。

---

## 三、系统运行流程

基于上述原则，一个Mission的实际运行流程如下：

**步骤1：需求澄清**。用户描述想要构建的内容。编排器进行调查并提出澄清性问题，直到需求无歧义。

**步骤2：生成验证合约**。编排器编写验证合约 —— 一个定义Mission完成与正确性的、可测试行为断言的有限清单。

**步骤3：功能分解**。编排器将工作分解为功能（features），每个功能是一个有边界的实现片段，声明它将满足哪些断言。功能被分组为里程碑（milestones），每个里程碑涵盖一个逻辑功能单元。

**步骤4：创建共享状态文件**。编排器创建边界和程序，约束其工作者的最优结构与行为，以及一个将在Mission运行期间累积知识的库。

共享状态文件包括：
- `validation-contract.md` —— 验证合约
- `features.json` —— 功能列表
- `services.yaml` —— 服务配置
- `AGENTS.md` —— 操作指南

**步骤5：功能执行**。程序化的运行器（runner）接收功能列表，按顺序为每个功能生成一个工作者。每个工作者以干净的上下文启动，接收其功能规格，先写测试，再实现。

**步骤6：里程碑验证**。一个里程碑内的所有功能完成后，运行器触发验证，使用全新的Agent。

- **Scrutiny validators（审查验证器）**：审查每个工作者的实现和轨迹的质量与正确性，将相关知识更新编码到共享状态中。
- **User-testing validators（用户测试验证器）**：将系统作为黑盒使用 —— 像真实用户一样使用 —— 并根据验证合约验证行为。

**步骤7：修复循环**。验证后，编排器审查工作者和验证器标记的问题。它创建针对可操作的差距的修复功能，在里程碑重新验证之前执行。这一循环重复，直到里程碑验证通过。

**步骤8：阻塞处理**。如果实现或验证被阻塞，编排器暂停Mission并将控制权交还给用户。

---

## 四、验证契约与双轨验证机制

多数代码Agent陷入了一个隐蔽而危险的陷阱：先写功能，再补测试。测试通过率沦为对既定决策的确认，而非需求驱动的质量把关。这导致长周期开发必然产生偏差 —— 测试被实现引导，而非测试引导实现。

Missions采用的解决策略是 **双层测试驱动开发** ，核心创新在于 **验证合约（Validation Contract）**。

### 4.1 验证合约：在实现之前定义正确性

验证合约在规划阶段生成，独立于实现路径定义正确性。复杂项目可能包含数百条可测试的行为断言，每条功能映射到对应断言，所有功能覆盖总和必须满足全部合约要求。

这一顺序至关重要 —— 如果先创建功能再制定合约，合约将被已计划的实现所影响。

### 4.2 审查验证器（Scrutiny Validator）

运行测试套件、类型检查与Lint。关键升级为：每个已完成功能都会生成专属的代码审查Agent。这些审查Agent运行前未见相关代码，无实现偏见，审查过程从设计之初即为对抗性。

### 4.3 用户测试验证器（User Testing Validator）

扮演QA工程师角色，通过Computer Use启动真实应用，模拟填写表单、点击按钮、检查页面渲染逻辑。该步骤耗时最长（消耗大量墙钟时间而非Token生成），但直接验证业务流是否通畅。

两者在运行前均未见相关代码，无实现偏见，验证过程从设计之初即为对抗性。这种 **"黑盒验证"** 方法 —— 像真实用户一样使用系统，而非检查实现代码 —— 是Missions质量保障体系的关键创新。

---

## 五、真实案例：16.5小时构建Slack克隆

为验证架构的可行性，Factory团队运行了一个完整的Mission：从零开始构建一个功能完备的Slack克隆，涵盖工作空间认证、频道与线程、带表情回应和提及的实时消息、文件上传、搜索、在线状态与通知等全部核心功能。

### 5.1 核心效率数据

| 指标 | 数值 | 说明 |
|------|------|------|
| 总运行时间 | 16.5小时 | 完整闭环 |
| 编排时间 | 0.38小时（2.3%） | 战略规划开销极低 |
| 实现时间 | 9.98小时（60.5%） | 工作者执行 |
| 验证时间 | 6.14小时（37.2%） | 质量保障投资 |
| 代码总量 | 38,800行 | 52.5%为测试代码 |
| 源代码 | 18,500行 | 业务逻辑 |
| 测试代码 | 20,400行 | 自动化测试 |
| 语句覆盖率 | 89.25% | 接近工业级标准 |
| 里程碑数量 | 6个 | 分阶段推进 |
| Agent总运行次数 | 185次 | 63次工作者 + 27次验证器 |
| 验证器发现问题 | 81个 | 65个阻断性 + 11个非阻断性 + 5个建议 |
| 修复功能数量 | 21个 | 占实现工作的34.4% |
| Token总消耗 | 778.5M | 485.5M实现 + 263.8M验证 |

### 5.2 里程碑演进与可靠性循环

该Mission跨越六个里程碑推进，每个里程碑在2-4轮验证内收敛：

| 验证轮次 | 通过里程碑数 |
|----------|-------------|
| Round 1 | 0/6 |
| Round 2 | 1/6 |
| Round 3 | 2/6 |
| Round 4 | 6/6 |

验证器共发现81个问题，编排器生成21个针对性修复功能（占实现工作的34.4%），形成稳定的 **"实现-验证-修复"** 正循环。实现与验证的中位轨迹长度分别为51轮和30轮，始终保持在合理范围内。

### 5.3 关键洞察

值得注意的是，验证占据了总运行时间的37.2% —— 这不是浪费，而是确保多日运行不漂移的 **"保险费"** 。52.5%的代码量为测试代码，89.25%的语句覆盖率，这些数字共同说明：**质量不是事后检查出来的，而是架构设计进去的**。

---

## 六、结构化交接与知识累积

多Agent系统在长周期运行中最大的风险是上下文丢失。工作者在完成任务后"遗忘"关键信息，导致后续Agent重复踩坑或在错误假设上继续建设。Missions通过以下机制解决：

### 6.1 结构化交接文档

每个工作者完成后必须填写结构化交接文档，记录已完成项、未竟项、执行的命令及其退出码、发现的问题、对既定流程的遵循程度。这不是可选的"最佳实践"，而是强制执行的系统约束。

### 6.2 强制检查点

错误被强制拦截在里程碑边界，修正范围重新划定，系统借此实现自我拉回正轨。这套机制不依赖智能体的记忆能力，而是依赖强制文档化与问题解决。

### 6.3 知识库累积

编排器会提炼踩坑经验为共享技能（Skills）。第一个Worker发现的API特殊包装层，自动变成后续所有Worker的默认技能 —— 避免重复踩坑。这种组织级学习机制，使得系统越运行越聪明。

---

## 七、面向Agent时代的启示

Missions架构的第一个版本已经闭合了软件开发的自动化循环。随着模型在推理、规划、执行和计算机使用方面的能力持续提升，每一项改进都会通过架构产生 **复合效应（compounding effect）** ：更好的规划者产生更紧凑的规格，更好的工作者减少错误，更好的验证者在更广的范围内可靠地判断正确性。随着模型变得更快更便宜，循环变得更紧密 —— 更多验证轮次变得实际可行，更宏大的Mission对更多团队和代码库变得可行。

对于技术从业者而言，这一架构带来的启示远超具体实现细节：

1. **职责分离不是可选项，而是Agent系统的生存必需**。让实现者同时担任判定者，必然导致质量债务累积。

2. **验证必须前置**。在编码前定义正确性，而非事后补测试，是防止长周期漂移的唯一有效策略。

3. **状态必须外部化**。没有任何单一Agent需要在其上下文中同时持有完整图景 —— 完整状态分布在整个共享制品中。

4. **模型选型需要策略思维**。"在正确位置使用正确模型"将成为复利型优势。

软件工程的瓶颈正在从代码编写能力转向架构设计能力与人类注意力管理。Missions所代表的，不仅是技术的进步，更是一种全新的工程哲学：**当智能体能够可靠地协作、验证和自我修正，人类的角色将从执行者转变为架构师 —— 设计系统，然后让系统自行运转**。


2026年的软件工程领域正在发生一场静默而深刻的范式转移。Factory.ai在其技术博客中抛出了一个核心论断：软件工程的瓶颈不再是智力，而是人类注意力（human attention）。即便是最优秀的工程师，同一时间也只能聚焦少数几个任务；无数高价值的特性因人力约束而被搁置在 backlog 深处，永远无法排上开发日程。

Agent超长时间运行的架构设计

人工智能

后端

架构设计

Factory.ai的Missions多智能体架构通过编排器、工作者和验证者的角色分离解决AI开发中的上下文稀释问题。采用验证合约前置与双层测试驱动开发，确保系统在无人值守下长时间运行不偏离轨道。该方案在Slack克隆项目中验证成功，实现超89%代码覆盖率，37.2%时间用于质量验证，推动软件工程从智力瓶颈转向注意力管理的新范式。

软件工程

软件开发

智能体

AI Agent

Agent

2026采购季 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Factory.ai的Missions多智能体架构通过编排器、工作者和验证者的角色分离解决AI开发中的上下文稀释问题。采用验证合约前置与双层测试驱动开发，确保系统在无人值守下长时间运行不偏离轨道。该方案在Slack克隆项目中验证成功，实现超89%代码覆盖率，37.2%时间用于质量验证，推动软件工程从智力瓶颈转向注意力管...

Agent超长时间运行的架构设计-腾讯云开发者社区-腾讯云

Agent超长时间运行的架构设计

Agent超长时间运行的架构设计

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐