MREA：面向企业开发的开源多智能体治理框架

MREA（Multi-Role Execution Architecture）是一个面向企业级 AI 辅助软件开发场景的开源治理框架。它把当前常见的「单一巨型智能体」模式拆分为协调者、架构师、审计者与实施者等明确角色，并强调「设计与验证分离、验证与实施分离」，试图在复杂代码库上缓解过度工程化、自我验证偏差和 token 浪费等系统性问题。

单一智能体模式的常见失效

许多 AI 编程工作流仍由一个全能型智能体贯穿始终：理解需求、探索代码、设计方案、写代码、自我审查、再向用户解释。框架作者认为，这种模式在小型任务上尚可工作，但在企业级复杂代码库中容易出现以下问题：

• 过度工程化：不必要的抽象、封装、依赖与样板代码
• 范围蔓延：智能体主动「优化」未被要求的部分
• 自我验证偏差：同一智能体既设计又审批自己的方案
• 上下文污染：架构、实现、调试、对话挤占同一上下文窗口
• 死亡循环：反复尝试修复自己引入的问题
• Token 浪费：昂贵的推理模型被用于不匹配其能力的任务

MREA 的核心思路正是把这些职责拆开，让不同智能体各司其职。

多角色架构与工作流

MREA 将 AI 辅助开发建模为一条带质量门的受控流水线，而非一次自由对话。请求依次经过：需求发现 → 风险分类 → 架构设计 → 独立审计 → 人工审批 → 实施 → 验证。其中：

• 非重大变更（如错别字、标签修改）在协调者可证明其非重大的前提下可省略审计
• 涉及关键行为、安全、跨系统集成、数据迁移、对外契约或回滚困难的变更被定义为「重大变更」，必须经过独立审计，且实施前需获得明确的人工审批

在架构层面，用户请求首先进入协调者（Orchestrator），由其调度软件架构师、高级软件架构师、设计架构师分别产出方案，再交由技术审计者与设计审计者独立挑战与校验，最终由实施者按已批准的计划执行。框架明确要求：实施不会自动开始，系统必须先满足对需求的清晰理解、来自代码库的证据、明确的实施计划、必要时的独立审计以及明确的人工审批，才允许修改代码。

严格的角色边界

框架显式定义了一套层级化的角色清单：

• 协调者（Orchestrator，主智能体）：路由任务、强制流程与质量门、管理人工审批，但不能直接实施变更
• 软件架构师：设计常规后端与系统变更，不能实施
• 高级软件架构师：处理复杂、关键、高影响或跨系统架构，不能实施
• 设计架构师：负责 UI / UX / 前端架构，不能实施
• 技术审计者：挑战架构、识别不必要复杂度，不能实施
• 设计审计者：校验 UX、UI 与设计系统合规，不能实施
• 实施者：执行已批准的计划，但不重新设计方案

这种「有意制造的摩擦」使得没有任何一个智能体可以独自完成从设计到落地的全部链条。

设计哲学：代码是负债

MREA 在两条原则下运作。其一是「Ponytail 哲学」：默认代码是一种负债，新增代码必须经过三道前置追问——能否复用已有代码？能否由框架原生能力解决？需求本身能否简化？只有当三问皆否时，才允许写入新代码。

其二是「按设计做 FinOps」：将推理成本与执行成本分离。昂贵的推理模型用于架构设计、复杂分析与独立审计；成本更低的执行模型则承担实施、机械性修改与聚焦的代码生成，从而按任务复杂度路由模型，而不是把所有请求都丢给最贵的模型。

该框架以开源形式发布，完整的架构图、角色定义与风险模型文档在项目仓库中提供。