@aiDotEngineer: The Multi-Agent Architecture That Actually Ships https://youtube.com/watch?v=ow1we5PzK-o… What does a multi-agent codin…

The Multi-Agent Architecture That Actually Ships https://youtube.com/watch?v=ow1we5PzK-o… What does a multi-agent coding system look like when it actually works in production? @luke_alvoeiro from @FactoryAI breaks down a system that has already run for 16 days straight, using orchestrators, workers, and validators to keep long-running work on track. The key ideas here are validation contracts written before implementation, structured handoffs between agents, and adversarial verification that checks behavior, not just code. If you’re tired of vague multi-agent diagrams and want the real design tradeoffs, this is a good one.

TL;DR: 本文系统解析了 Factory 的 Missions 多智能体架构，通过整合委托、创建者-验证者等五种通信机制，结合三角色分工、验证合约与结构化交接设计，使智能体团队具备无人值守连续运行数十天的能力，从而将软件工程瓶颈从执行转向人类注意力与架构决策。

软件工程的新瓶颈与多智能体范式

当前软件开发的瓶颈已不再是人工智能的智力，而是人类注意力的物理极限。即使顶尖工程师一次也只能处理少量任务，面对数十个待办需求时，每日能推进的数量受限于代码审查与上下文切换的带宽。如今的大语言模型已完全具备独立完成这些任务的能力，但缺乏足够的监督算力。

解决思路很明确：人类负责定义“做什么”，系统自动规划“怎么做”。智能体可以持续工作数小时甚至数天，开发者返回后即可接管收尾。为实现这一目标，必须建立一套稳定、可长周期运行的多智能体协作架构。

五大核心通信机制分类体系

多智能体领域术语与框架繁杂，但可归纳为五种基础通信模式。理解这些积木块是构建可靠系统的前提。

委托（Delegation）

最基础的形态。父智能体将子任务（如“梳理数据库模式”）派发给子智能体，并等待结果返回。子智能体配合编码工具是最常见的落地形式。

创建者-验证者（Creator-Verifier）

核心在于职责分离。创建者天然带有“建设性偏见”，倾向于让代码跑通；而独立拥有全新上下文的验证者更容易发现隐藏问题。该模式类似于人类的代码审查流程。

直接通信（Direct Communication）

智能体绕过中央协调器进行点对点交流。难点在于缺乏单一事实来源，对话状态极易碎片化，难以维持长期一致性。

协商（Negotiation）

多个智能体共享资源或冲突修改同一代码库/API 时发生。理想场景并非零和博弈，而是正和交互，各方在协调中实现双赢。

广播（Broadcast）

单个智能体向群体发布状态更新、新上下文或共享约束。虽然不如其他机制炫酷，却是维持长时间任务一致性的基石。

Missions 架构：将策略转化为可连续运行的系统

将上述机制整合进单一工作流的方案称为 Missions。它并非单次会话，而是一个通过结构化交接与共享状态运行的智能体生态系统。其核心由三个角色构成。

三角色设计：编排器、工作者与验证器

• 编排器（Orchestrator）：负责顶层规划。当开发者输入需求后，编排器会提出战略性问题以消除模糊地带，最终输出包含功能列表、里程碑及**验证合约（Validation Contract）**的计划。验证合约在编码前明确界定“完成”的标准，是系统防偏离的关键。
• 工作者（Workers）：专注具体实现。每个功能分配给独立的工作者，享有纯净上下文，避免历史包袱干扰注意力。工作者按规格编写代码并通过 Git 提交，确保下一位工作者能继承干净起点与可运行仓库。
• 验证器（Validators）：负责质量把关。传统系统仅依赖 lint、类型检查与单元测试，Missions 进一步要求验证行为表现与端到端可用性。这是系统能连续运行数十小时不失控的核心差异。

重构验证逻辑：验证合约与双轨验证

多数代码智能体陷入“测试被代码引导”的陷阱：先写功能，再补测试，测试通过率仅是既定决策的确认而非需求驱动。这会导致长周期开发必然产生偏差。

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

每个里程碑完成后，系统触发两类验证器：

1. 严格审查验证器（Scrutiny Validator）：运行测试套件、类型检查与 Lint。关键升级是为每个已完成功能 spawn 专属的代码审查智能体。
2. 用户测试验证器（User Testing Validator）：扮演 QA 工程师角色，通过 Computer Use 启动真实应用，模拟填写表单、点击按钮、检查渲染逻辑。该步骤耗时最长（消耗大量墙钟时间而非 Token 生成），但直接验证业务流是否通畅。

两者在运行前均未见相关代码，无实现偏见，验证过程从设计之初即为对抗性。

结构化交接与自我修复机制

为防止长周期运行中的上下文丢失，工作者完成任务后必须填写结构化交接文档，记录完成项、未竟项、执行的命令及其退出码、发现的问题以及对既定流程的遵循程度。错误被强制拦截在里程碑边界，修正范围重新划定，系统借此实现自我拉回正轨。这套机制不依赖智能体的记忆能力，而是强制文档化与问题解决。该系统最长连续运行记录达 16 天，理论支撑上限约 30 天。

执行策略与工程优化

串行主框架配合内部只读并行

直觉上全量并行可提升吞吐量，但在软件开发任务中会导致更改覆盖、重复劳动与架构决策不一致，协调开销反而吞噬收益。Missions 采用串行执行功能的主框架，任意时刻最多仅一个工作者或验证器活跃。仅在功能内部允许只读操作并行，例如遍历代码库、调研 API 或在验证阶段并行处理代码审查。这种带针对性内部并行的串行模式显著降低错误率，在多日运行中形成正确性复利。

Mission Control 监控视图

标准聊天界面无法胜任数天级任务。Mission Control 提供异步运行所需的可视化面板，实时展示活跃工作者动态、交接摘要、验证器发现及路线调整策略。开发者可选择作为项目经理介入监督，也可直接放手处理其他事务。

“Droid Whispering”：模型路由与选型哲学

不同角色对模型能力要求各异：编排需缓慢严谨的推理，实现需快速代码流利度与创造力，验证需精确指令遵循。单一模型无法在所有维度最优。构建此架构需掌握一项新技能——Droid Whispering，即在脑中建模不同大模型的交互方式、失效模式及其在多日运行中的放大效应，进而审慎分配位置。

该系统采用模型无关架构。验证环节可使用独立供应商以防止训练数据同质化带来的偏见。同时，严格的验证合约与里程碑检查点也能弥补非前沿模型的性能短板，甚至支持开放权重模型的成功部署。随模型细分演进，“在正确位置使用正确模型”将成为复利型优势。

生产实践与长期价值

实际案例数据与成本优化

以克隆 Slack 的生产环境测试为例：60% 的运行时间与 Token 消耗用于功能实现。首次验证通常不通过（左下角数据可见），系统自动生成后续补充功能，印证了 QA 闭环的价值。最终代码库中约 50% 为测试用例，业务逻辑覆盖率高达 90%。通过重度使用 Prompt 缓存，有效对冲了长周期运行的 Token 成本。

对抗“苦涩教训”的架构设计

多智能体开发者普遍担忧下一代模型发布会使现有架构过时。为此，Missions 的设计原则是让系统随模型迭代持续增强。几乎全部编排逻辑均定义在 Prompts 与 Skills（技能集）中，而非硬编码状态机。拆解失败、功能分解与异常处理逻辑浓缩于约 700 行文本内，仅修改四句即可大幅改变执行策略。工作者的行为由编排器为每次 Mission 动态定义的 Skills 驱动，系统仅承担记账、调度与进度拦截等确定性逻辑。系统保证纪律性，模型提供智能，双方利用 agents.md、Skills 等原生生态协同。

释放人类注意力与团队效能跃迁

回到最初的瓶颈：过去一支 5 人的工程团队在同一时间或许只能维护 10 个工作线。借助 Missions，该数字可提升至 30 左右。团队得以从执行细节抽身，聚焦架构设计与产品决策。更重要的是，由端到端测试、单元测试、Skill 规范与整体结构共同保障的最终代码库，会比开发起点更整洁。未来，人类与智能体将在该高规范性环境中展现更高的复合生产力。

Source: https://www.youtube.com/watch?v=ow1we5PzK-o