Factory Missions架构解析：连续运行16天的多智能体系统如何设计

核心问题：人类注意力才是软件工程的真正瓶颈

在AI Engineer大会上，Factory核心智能体引擎负责人Luke分享了他们构建的多智能体系统——Missions。Luke曾在Block公司创建了开源编程智能体Goose，现在他提出了一个关键洞察：当今软件工程的瓶颈不是智能，而是人类注意力。

这一洞察有深厚的认知科学基础。心理学研究表明，人类工作记忆容量极为有限（Miller定律指出约为7±2个信息块），且在任务切换时会产生显著的"切换成本"（switching cost）——每次上下文切换平均需要23分钟才能完全恢复专注状态。在软件工程领域，这意味着工程师的有效并发任务数通常不超过3-5个。与此同时，现代LLM已展现出在代码生成、调试和架构设计方面接近或超越初级工程师的能力，这使得"智力资源"不再稀缺，而"监督带宽"成为真正的限制因素。这一转变类似于工业革命时期从人力到机械动力的跃迁——不是替代人类判断，而是将人类从执行层解放到决策层。

即使是最优秀的工程师，每天也只能推进几个任务。积压的50个功能需求，当前模型完全有能力处理，但缺乏足够的人类带宽来监督执行。Factory的愿景是：人类决定构建什么，系统负责弄清楚如何实现——智能体可以连续工作数小时甚至数天，你回来时工作已经完成。

五种多智能体协作模式分类

Luke提出了一个简洁的分类体系，将多智能体框架归纳为五种基本模式。这五种模式实际上对应了分布式系统和组织理论中的经典通信拓扑，本质上是在通信开销、状态一致性和并发效率之间进行权衡，与分布式系统的CAP定理面临的挑战高度同构：

1. 委派（Delegation）：一个智能体生成另一个子智能体，对应树形层级结构，是最低通信开销的多智能体通信形式
2. 创建者-验证者（Creator-Verifier）：一个智能体构建，另一个检查，源于软件工程中的"四眼原则"（Four-Eyes Principle），通过角色分离消除确认偏差，利用关注点分离避免沉没成本偏差
3. 直接通信（Direct Communication）：智能体之间无中央协调器的直接对话，对应点对点网络，灵活但状态容易碎片化
4. 协商（Negotiation）：智能体围绕共享资源进行沟通，借鉴了博弈论中的机制设计（Mechanism Design），最佳场景是正和博弈
5. 广播（Broadcast）：一个智能体向多个智能体发送信息，类似发布-订阅（Pub/Sub）架构，对长期任务的一致性维护至关重要

Missions架构设计：三角色协作系统

Missions将委派、创建者-验证者、广播和协商四种模式组合成一个统一工作流。你描述目标，通过对话确定范围，批准计划，然后系统处理数小时或数天的执行。

编排器（Orchestrator）：规划层

编排器像你的战略顾问，提出正确的问题，检查需求中的模糊之处，最终产出包含功能、里程碑和**验证合约（Validation Contract）**的计划。验证合约在任何代码编写之前就定义了"完成"的含义——这是整个系统的关键设计。

工作者（Workers）：实现层

每个工作者拥有干净的上下文，没有累积的包袱和退化的注意力。工作者读取规格说明，实现功能，通过Git提交，让下一个工作者继承干净的代码库。

验证器（Validators）：质量保障层

大多数系统通过lint、类型检查和测试来验证。Missions不仅做这些，还验证行为——不只是问"代码看起来对吗"，而是"这端到端能工作吗"。

验证合约机制：先写断言再写代码的工程智慧

验证合约的设计理念深度借鉴了测试驱动开发（TDD）和契约式设计（Design by Contract）两大工程传统。TDD由Kent Beck在极限编程（XP）中系统化，核心是"红-绿-重构"循环——先写失败的测试，再写最小实现使测试通过，最后重构。契约式设计则由Bertrand Meyer在Eiffel语言中提出，通过前置条件、后置条件和不变量形式化定义组件行为。

传统模式中，智能体写代码后再写测试，测试通过、覆盖率满，但测试是被代码"塑造"的——它们确认决策而非捕获缺陷。这正是AI代码生成的核心问题：模型倾向于生成"看起来合理"的测试而非"能捕获真实缺陷"的测试，因为后者需要独立于实现的视角。如果依赖这种验证，系统终将偏离。

验证合约在规划阶段编写，独立于实现定义正确性，将这两种思想推进到多智能体场景：它不仅是测试，更是"完成