华为诺亚方舟实验室造出了一家"AI公司"：让一群不同血统的AI智能体，真正像公司员工一样协同工作

这项由华为诺亚方舟实验室、伦敦大学学院和利物浦大学联合开展的研究，于2026年4月24日以预印本形式发布在arXiv平台，编号为arXiv:2604.22446v1，研究方向属于人工智能中的多智能体系统领域。有兴趣深入了解的读者可以通过该编号直接查询完整论文。

**一件让所有AI工程师头疼的事**

假设你是一家公司的老板，手下有几十个员工。有人擅长写代码，有人擅长画图，有人擅长写文案。你想做一个产品，需要这些人协同配合——前端工程师要等设计师出图，设计师要等产品经理定需求，所有人做完之后还需要一个质检员来验收。这听起来是再正常不过的公司运作方式，但在AI的世界里，这件事却出奇地难。

现有的多智能体AI系统有点像一个剧本早已写死的话剧团：演员（AI智能体）固定，剧情（工作流程）固定，每个角色只能照着剧本走，即便中途发现某个场景需要加一个新角色，也没有办法临时"招人"。更麻烦的是，不同"门派"出身的AI——比如谷歌系、Anthropic系、开源社区系——各自有各自的运行规范，彼此之间根本没法无缝沟通，就像一个说中文的员工和一个说英文的员工，连基本对话都困难。

研究团队把这个问题看得很透彻：问题的根源不在于单个AI不够聪明，而在于缺少一套真正的"组织管理层"。于是他们做了一件很有意思的事——把一家真实公司的运作逻辑，原封不动地搬进了AI系统，造出了一个叫做 **OneManCompany（简称OMC）** 的框架。

**一、从"工具箱"到"员工档案"：重新定义AI的身份**

现有的AI能力扩展方式，有点像给一把瑞士军刀加工具。你想让AI会搜索，就给它加个搜索插件；想让它会画图，就接入一个画图API。这些插件和工具，业内叫做"技能（Skills）"，每种技能就像军刀上的一个小刀片，只服务于拥有这把刀的那个AI本身，换一个AI就得重新配。

OMC的研究团队觉得，这种方式太局限了。他们提出了一个更高层次的概念——**Talent（人才包）**。

如果说技能是刀片，那Talent就是一份完整的员工档案。这份档案里包含了这个AI的角色定位（比如"软件工程师"或者"艺术设计师"）、工作原则、配备的工具清单、专属技能，以及行为准则。更关键的是，这份档案是"可移植的"——就像一个有丰富工作经验的人，不管去哪家公司，他的能力和经验都跟着他，不会因为换了办公室就变成另一个人。

与Talent配套的，是另一个概念——**Container（运行容器）**。如果Talent是员工本人，Container就是员工的工位和工作环境。OMC目前支持三种不同类型的"工位"：基于LangGraph的工位适合需要频繁调用工具的任务，基于Claude Code的工位适合长时间深度思考和编程的任务，还有基于脚本的轻量级工位适合简单快速的任务。三种工位规格不同，但都能接纳同一份Talent档案。这就实现了一个关键突破：同一个AI"员工"，可以被安置在不同类型的"工位"上工作，而不同血统的AI，也可以在同一个OMC框架下共存、协作。

把Talent和Container合在一起，就构成了一个完整的OMC "员工"。这个员工有编号、有档案、有工位、有绩效记录，从入职到离职，整个生命周期都被系统管理着。

为了让这套接口体系更严格，Container被设计成必须提供六个标准化的"组织接口"，就像公司要求所有员工都必须遵守相同的入职流程、汇报格式和沟通规范一样。这六个接口分别负责：执行任务并返回结果、管理每个员工的任务队列（同一时间只能处理一项任务，不能同时开工）、在组织内部发布和接收事件通知、读写持久化的记忆存储、在执行任务前组装好完整的上下文（包括角色定位、工作原则、历史记忆）、以及在任务前后执行检查和自我优化的钩子程序。这六个接口的设计，研究者自己也坦言，和操作系统内核的六大子系统高度对应——进程管理、内存管理、文件系统、I/O管理、进程间通信、安全审计——这套设计哲学已经在计算机科学领域被验证了几十年。

**二、公司不自己造员工，而是去市场上招人：数字人才市场**

一家真实的公司不会把所有员工都从头培训，更常见的做法是去劳动力市场招募已经具备相应技能的专业人才。OMC也遵循了这个逻辑，搭建了一个配套的**Talent Market（人才市场）**。

这个市场里有三类"候选人"来源。第一类是来自成熟开源社区的现成agent实现，这些都是经过社区验证、有实际使用记录的agent，打包成标准Talent格式后上架。第二类是从一个叫做Agency-Agents的项目中提取的140多个专业角色定义，这些角色定义详细描述了工作原则和交付标准，但本身没有配工具；OMC的系统会自动去另一个叫SkillsMP的技能市场里，根据角色需求检索并组装配套工具，变成完整的可部署Talent。第三类则是完全动态组装的——当某个领域既没有现成的实现，又没有合适的角色定义时，HR agent会根据任务需求描述，直接从SkillsMP里搜索合适的技能片段，从零拼装出一个全新的Talent，作为冷启动的兜底方案。

当一个项目需要某种当前团队不具备的能力时，HR agent会主动查询Talent Market，按技能匹配度和社区评分生成一份候选推荐列表，提交给CEO（也就是人类用户）审批。CEO选定之后，系统自动为这个新"员工"配置工位、分配工具权限、注册到组织架构里——全程无需人工操作。这个过程，和现实中HR部门从猎头平台筛选候选人、入职后IT部门配发电脑权限、行政部门分配工位，几乎是一模一样的。

**三、公司怎么承接项目？一套有理论保障的任务拆解机制**

一个大型项目摆在面前，怎么拆？拆成几个部分？谁来做哪部分？如果某人做出来的东西不过关，怎么办？这些问题，在现实公司里靠经验和制度来解决，在OMC里，有一套叫做 **E?R树搜索（Explore-Execute-Review）** 的机制来处理。

E?R的灵感来自棋类游戏中的蒙特卡洛树搜索，但它处理的不是棋局，而是真实的工作任务。整体逻辑是这样运转的：

先说**探索阶段（Explore）**。当一个任务节点需要被拆解时，负责该节点的AI"主管"（比如COO或资深员工）会根据当前的组织状态、员工档案和历史绩效，决定如何拆分子任务，以及把每个子任务分配给谁。这个过程天然面临"用熟手还是试新人"的权衡——选绩效好的老员工更稳妥，但尝试新员工或者招募新人或许能发现惊喜。

再说**执行阶段（Execute）**。每个被分配了任务的员工通过组织接口开始工作，调用自己的工具和技能，产出结果。执行本身对组织层来说是个"黑盒"——不管里面用了什么模型、什么推理策略，外层只关心输入和输出。

最后是**评审阶段（Review）**。任务完成后，由该节点的"父级"主管（或COO）来评审结果，给出"通过"或"不通过"的判断。如果通过，结果会解锁下游依赖这个任务的其他任务；如果不通过，系统会回到探索阶段，用失败的上下文信息作为参考，重新拆解这个子任务或者换人重做。

整个项目被组织成一棵动态生长的树形结构，树的节点是任务，树的边是父子关系（谁拆了谁）和依赖关系（谁等谁）。依赖关系构成的图必须是无环的（就像施工顺序不能出现循环依赖），这个约束在每次添加新任务时都会自动检查。

为了防止系统"卡死"，OMC设计了三个保险开关：如果一个子任务被评审拒绝超过3次，就上报给更高层主管处理；如果一个任务执行超过3600秒，直接标记为失败；如果整体消耗超过预算上限，暂停执行等待人工介入。

从理论角度，OMC提供了七条形式化保证：任务图永远是无环的、每个员工同时只处理一个任务、任务不会被重复执行（崩溃恢复后也不会）、每个节点最多被评审固定次数后强制上报、取消一个任务会传导取消所有依赖它的下游任务、每次任务状态变更都会触发依赖检查避免遗漏、系统崩溃恢复后能从一致状态继续执行。这七条保证，解决了现有多智能体系统最头疼的"任务悄悄卡住没人知道"的问题。

每个任务节点在生命周期中会经历一系列状态变迁：从等待分配（Pending）、执行中（Processing）、因依赖未满足而搁置（Holding）、已完成等待评审（Completed）、评审通过（Accepted）、最终结束（Finished），以及可能的失败（Failed）、被取消（Cancelled）等状态。其中，"已完成"到"评审通过"之间的这一步必须经过主管明确审核，不能自动跳过——这条设计阻止了"AI自说自话、把错误结果当成功结果传下去"的常见问题。

**四、公司怎么越做越好？个人成长与组织学习的双轨机制**

一家只会干活不会学习的公司，很快就会被淘汰。OMC在这一点上的设计，和现实公司的人才培养体系惊人地相似。

**个人层面**，每个AI员工都维护一份持续更新的"成长档案"，包含跨任务的进度日志和经过AI总结提炼的工作原则。有两个场景会触发员工的自我反思：一是CEO和该员工进行"一对一谈话"（CEO通过界面直接给员工发反馈），员工会据此梳理自己的行为偏差并更新工作原则；二是每次任务完成后，员工会回顾自己的决策轨迹、工具使用情况和遇到的障碍，写一条经验总结追加到成长日志里。这些更新不会修改底层大语言模型的权重，只是修改Talent档案中的工作原则文本——相当于员工自己在日记本上记下新的心得，下次接任务时带着这份心得去做，而不需要"重新上学"。

**组织层面**，每个项目结束后，COO会召集一次正式的"项目复盘"。参与项目的每个员工提交自评，COO汇总这些自评，再结合任务重试次数、评审被拒原因、资源消耗等客观数据，提炼出两类输出：一是针对每个员工的个人反馈（更新他们的工作原则），二是组织级别的标准操作程序（SOP）——比如"前后端集成之前必须先确认API接口规范"这样的组织规律。这些SOP会以文档形式持久存储，在后续项目中自动注入到相关员工的上下文里，确保组织知识不只停留在某个员工的记忆里，而是真正成为公司的"制度记忆"。

**HR绩效管理**方面，每完成三个项目，HR agent会自动对参与员工展开一次绩效评估，考察任务完成质量、评审通过率和协作效果。连续三次绩效不达标的员工会进入"绩效改进计划（PIP）"，在更密集的辅导和监督下工作；如果PIP期间再次不达标，系统会触发自动"离职"流程——注销该员工的Container、释放工位，并将能力缺口标记为需要重新招募。

研究团队自己指出，这套HR生命周期管理机制在现有AI agent研究中没有先例——把"绩效考核、改进计划、自动解雇"这套人力资源管理逻辑完整地移植到AI系统里。

**五、实验结果：真实战绩说话**

研究团队选用了PRDBench作为定量评测基准。这是一个模拟真实软件开发场景的基准测试，包含50个项目级任务，横跨20多个不同领域，每个任务有一份完整的产品需求文档（PRD），配套了详细的测试计划和可执行的评测脚本。这个基准测试的特点是不考核孤立的代码片段，而是考核从理解需求、拆分任务、实现功能、到满足验收条件的完整项目能力。

OMC的具体配置是：一个基于Gemini 2.1 Flash Lite Preview的LangGraph agent作为"创始团队"成员，加上从Talent Market招募的三位专职员工——一位基于Claude Code和superpowers插件的软件工程师、一位来自agency-agents项目的软件架构师、一位同样来自agency-agents项目的代码评审员。测试采用单次零样本设置，每个任务只提交一次PRD，不允许中间反馈或人工干预。

最终结果是OMC以**84.67%的成功率**高居榜首，比排名第二的Claude-4.5（69.19%）高出15.48个百分点，比GPT-5.2（62.49%）高出22个百分点，更远超Claude Code独立模式（56.65%）和其他各类商业及开源模型。50个任务的总花费为345.59美元，折合每个任务约6.91美元，成本来自多智能体协调的额外开销——但其他baseline系统的成本数据未被原始论文报告，所以直接的成本效率比较无法进行。

研究者分析，这个成绩背后有三个关键因素：任务树在执行过程中能根据中间结果动态调整，而不是死守最初的计划；"已完成→评审通过"这个强制门控阻止了错误结果向下游传播；Container与Talent的分离让系统可以在同一个项目里调用不同家族的AI，给不同子任务匹配最合适的工具。

**六、四个真实案例：不只会写代码**

除了PRDBench的量化成绩，研究团队还展示了四个跨领域的应用案例，来证明OMC的组织框架不依赖特定领域。

第一个案例是**内容生成**。CEO输入一句话："帮我组建一个搜索-写作团队，生成过去一周GitHub上最热门的AI Agent仓库周报，包含真实链接，完成后发邮件给我。"系统随即招募了一位GPT-4o驱动的研究员和一位Claude Sonnet 4驱动的撰稿人，研究员负责从GitHub采集真实数据，撰稿人负责写报告并发送邮件。整个流程耗时不到10分钟，总花费约4.48美元。研究团队事后人工核实了报告中所有仓库链接和星标数，全部属实。

第二个案例是**游戏开发**。CEO要求开发一款具有精良视觉效果的街机格斗网页游戏。系统招募了Claude Sonnet 4驱动的游戏开发者和Gemini 2.5驱动的美术设计师。美术设计师先生成角色动作帧（待机、行走、踢击、受击），游戏开发者等待素材就绪后集成到代码里。第一版完成后发送给外部人类评测员，评测员发现精灵图（sprite sheet）的帧切割有问题，反馈回系统。COO和EA商议后，没有打补丁了事，而是给美术设计师创建了一个新技能——用程序自动切割精灵图帧。有了这个新技能，美术设计师重新处理了所有素材，游戏开发者再次集成，最终通过评审。这个案例展示了OMC在外部反馈驱动下自主扩展自身能力的过程。

第三个案例是**有声读物制作**。CEO要求用动物角色重新演绎《浴血黑帮》第一、二集，每集生成8张场景插图，配英语配音，最终剪辑成视频。系统招募了一位小说撰稿人（负责改编剧本）和一位基于Gemini 3.1 Pro的AV制作人（负责图像生成、语音合成、视频剪辑）。两者通过共享任务树协作，分两个阶段完成项目：先写脚本，再逐场景生产素材并组装。最终产出16张场景图、16条配音、背景音乐和两段完整视频，总花费仅1.57美元。

第四个案例是**自动化学术调研**。CEO提交一句话："调研2021-2026年间'具身智能与机器人世界模型'这一课题，生成详细思维导图，并提出三个可行的研究方向。"系统招募了两位Claude Sonnet 4.6驱动的研究科学家和一位自托管AI工程师。三人并行工作：一人搭建调研框架和初始论文清单（35篇种子论文），一人精读17篇论文并归纳8个开放问题与11种失效模式，一人评估28个系统的部署就绪度。Phase 2中，团队产出了纳入协议文件、931行文献综述框架，以及三个基于失效模式分析的具体研究方向。整个过程不足一小时，花费16.26美元，产出17份结构化文档和一张涵盖6大主题约70个节点的思维导图。研究团队人工验证了引用论文的真实性，并对其中第三个研究方向（将元学习与保形预测结合用于仿真到真实场景的迁移）评价为具有真实创新性。

**七、与同类系统的对比：差距在哪里**

研究团队把OMC和八类代表性系统做了结构性对比，包括MetaGPT、ChatDev、AutoGen、LangGraph、CrewAI、OpenHands、AIOS、AgentScope和Paperclip。对比维度涵盖设计范式、执行模型、智能体与平台的交互契约、状态管理方式、是否支持异构后端、智能体来源，以及个体自进化和组织级进化能力。

对比结果显示，现有所有系统中没有任何一个同时具备以下三点：支持多种异构执行后端共存、提供可证明终止性和无死锁的动态任务分解机制，以及同时实现个体和组织两个层面的持久化自我进化。OMC在这三个维度上都给出了正向答案。

Paperclip是相对接近的系统，它也支持多家族智能体混合和人工战略导演角色，但没有"创始团队"用于冷启动，更没有结构化的绩效管理机制——研究团队认为Paperclip的角色是靠描述性提示词定义的，不如OMC的Talent合约机制可靠。

**八、坦诚面对局限**

研究团队在论文中直接指出了两个尚待解决的问题。

定量评测目前只在PRDBench这一个基准上进行，而PRDBench本质上还是软件开发任务，虽然案例研究证明了跨领域能力，但在非编程类任务上的系统性评估还缺失。

自进化机制（一对一谈话、项目复盘、绩效考核）已经在系统中实现并上线，但每个机制对最终成绩贡献多少，目前没有做过消融实验，需要跨越多个项目的纵向研究才能量化。

成本方面，多智能体协调带来了显著的额外开销——每个PRDBench任务约6.91美元，远高于单一模型直接做的成本。研究团队为此引入了"自适应分发模式"：CEO可以选择把简单任务路由给单个agent，只在任务复杂度超过阈值时才启动完整的多智能体流程。

---

归根结底，这项研究做的事情是把一个几千年来经过人类反复验证的管理智慧——如何让一群能力不同的人协同完成复杂目标——翻译成了AI系统能理解和执行的语言。当你的公司有HR负责招聘、有COO负责统筹、有一对一谈话来帮员工成长、有项目复盘来提炼经验，整个组织就能越来越好。OMC的核心发现是：这套逻辑对AI同样成立。

对普通人而言，这意味着未来使用AI工具的门槛可能会进一步降低——你不需要知道哪个模型最适合哪种任务，也不需要手动编排工作流程，只需要像真正的老板一样说一句"帮我做这件事"，后面的招聘、分工、协调、检查、优化，都可以交给这套组织机制去完成。

当然，从实验室到真正落地还有很长的路。成本控制、非编程场景的普适性、组织自进化的量化证明……这些都是接下来需要回答的问题。有兴趣深入探索的读者，可以通过arXiv编号2604.22446查阅完整论文，也可以访问项目主页 one-man-company.com 或代码仓库体验这套系统的实际运作。

---

**Q&A**

Q1：OneManCompany框架中的Talent和普通的AI技能插件有什么区别？

A：普通AI技能插件就像给一个工具加功能，只对拥有它的那个AI有效，换一个AI就得重新配。Talent则是一份完整的员工档案，包含角色定位、工作原则、工具清单和技能组合，可以在不同运行环境之间移植，不会因为换了"工位"就失效。简单说，技能是刀片，Talent是整个人。

Q2：E?R树搜索是怎么保证任务不会卡死或无限循环的？

A：OMC设计了三个保险机制：同一个子任务被评审拒绝超过3次就强制上报给更高层；单个任务执行超过3600秒直接标记失败；总消耗超出预算则暂停等待人工处理。同时，每个任务节点都有一套状态机来追踪当前所处阶段，任务依赖图在每次添加时都会检查是否成环，从根源上避免循环依赖导致的死锁。

Q3：OneManCompany在PRDBench上比Claude Code单独使用高出这么多，主要靠什么？

A：主要有三个原因。第一，任务树是动态的，可以根据中间结果调整分解方案，而不是一开始就把路线写死。第二，每个子任务完成后必须经过主管明确审核才能解锁下游任务，阻止了错误结果在系统内扩散。第三，框架允许同一个项目里混用不同家族的AI，可以把最适合的工具分配给最对口的子任务，而不是强迫所有任务都用同一个模型。