@aiDotEngineer：真正能投入生产的多智能体架构 https://youtube.com/watch?v=ow1we5PzK-o… 实际可用的多智能体编……

《真正能落地交付的多智能体架构》 https://youtube.com/watch?v=ow1we5PzK-o … 当多智能体编程系统真正投入生产环境运行时，究竟呈现怎样的形态？@FactoryAI 的 @luke_alvoeiro 深度剖析了一个已连续稳定运行 16 天的系统。该系统通过编排器（Orchestrator）、工作者（Worker）和验证器（Validator）的协同，确保长时间运行的任务始终保持在正确轨道上。其核心理念包括：在实现前编写验证合约、智能体之间的结构化交接，以及仅关注行为表现而非单纯代码本身的对抗式验证。如果你已对那些模糊不清的多智能体示意图感到厌倦，并希望了解真实的设计权衡，这是一篇不可多得的好文。

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