乔木博客

全部

AI工具

AI教程

AI生成

AI资讯

健脑房

播客解读

论文学习

AI也要做绩效考核？这个框架给智能体安排了HR、PIP和末位淘汰

论文学习

·

2026年4月29日

·

1261 次阅读

·

约 25 分钟

最近读到一篇很有意思的论文，来自华为诺亚方舟实验室、UCL和利物浦大学的团队，发布于2026年4月。

论文标题叫《From Skills to Talent》，核心想法用一句话概括：把多智能体系统，真正当成一家公司来管理。

https://arxiv.org/pdf/2604.22446

先说清楚背景：现在的AI智能体系统，问题出在哪

过去几年，单个AI智能体的能力进步很快。

Claude Code、Codex这些工具，已经能独立完成相当复杂的编程任务。

进步的关键，是模块化技能（Skills）的生态。

你可以给一个智能体装上搜索工具、代码执行工具、邮件工具，像插件一样组合，不需要重新训练模型。

但技能只在单个智能体内部起作用。

任务一旦复杂到需要多个智能体协作，麻烦就来了。

现有的多智能体框架，比如CrewAI、AutoGen、Paperclip，有几个共同的毛病：

团队结构写死了。

项目开始前就定好谁做什么，遇到新类型的项目，整套配置就不灵了。

不同家族的智能体没法混用。

Claude的智能体和LangGraph的智能体，底层运行环境不兼容，没法放在同一个项目里协作。

角色靠prompt描述，不靠实际能力。

说自己是"高级工程师"，但能不能真的干活，没有验证机制，容易产生能力幻觉（hallucinated capabilities，智能体声称自己会某件事，但实际上做不到）。

自我改进是一次性的。

这个项目学到的东西，下个项目全忘了，没有跨项目的知识积累。

这些问题加在一起，论文团队认为，根源是缺少一个组织层。

现有系统解决的是"智能体怎么交互"，但没有回答"这支智能体队伍应该怎么组建、管理、进化"。

他们把这个缺失的层，叫做 AI组织（AI Organisation），并给出了一个正式定义：

一个由异构智能体组成的自治系统，具备结构化协调、生命周期管理和经验驱动的进化能力。

三个关键词：结构化协调（有明确协议，不是随意对话）、生命周期管理（从招募到退出，有完整流程）、经验驱动进化（通过系统性反馈持续改进）。

OMC是什么，整体架构长什么样

OMC（OneManCompany） 是他们基于上述思路开发的开源框架。

名字有点反直觉，"一人公司"，但意思是：你一个人作为CEO，管理一整支AI员工队伍。

系统启动时，有一支创始团队（Founding Team），四个默认员工：

HR（人力资源经理）：负责招募、评估、管理员工生命周期

EA（行政助理）：负责任务分析、路由、项目管理

COO（首席运营官）：负责运营、工具管理、战略

CSO（首席销售官）：负责销售管理、合同审查、客户关系

CEO是唯一的人类，也是这家AI公司的创建者和维护者。

整个框架建立在三根柱子上，分别对应公司运营的三个核心功能。

第一根柱子：Talent-Container 架构

这是OMC最基础的设计，解决"怎么管理异构智能体"的问题。

Employee = Talent + Container

每个AI员工被拆成两个部分：

Talent（人才包），是这个智能体的"认知身份"，包含：

角色定义和工作原则

技能脚本

工具配置（比如WebSearch、GitHub、邮件）

领域知识文件

基准测试结果（证明它真的会做某件事）

Container（容器），是运行环境，目前支持三种：LangGraph、Claude Code、脚本进程。

两者分离的核心价值：

同一个Talent，可以跑在不同的Container上；

同一个Container，可以承载不同的Talent。

这意味着，Claude的智能体和Gemini的智能体，可以在同一个项目里协作，不需要改任何代码。

Container通过六个类型化组织接口与平台交互，这六个接口的设计，论文明确类比了操作系统内核的六大子系统：

组织接口

职责

对应OS子系统

Execution（执行）

把任务发给后端，返回结果

进程管理

Task（任务队列）

每个员工的任务队列，互斥执行

进程调度

Event（事件总线）

发布/订阅式的组织事件通信

IPC进程间通信

Storage（存储）

持久化记忆，短期和中期状态

文件系统

Context（上下文）

组装执行提示词，整合角色、原则、记忆

内存管理

Lifecycle（生命周期）

执行前后的钩子，验证、护栏、自我改进

安全与审计

这个设计带来三个好处：

身份与底层分离：同一个Talent可以跑在任何支持的Container上，不需要修改。

多租户隔离：所有智能体与平台的交互，必须通过这六个接口，没有后门，组织策略无法被绕过。

可扩展性：新增一种智能体运行时，只需要实现这六个接口，不需要改动现有的任何代码。

Talent Market：社区驱动的人才市场

OMC集成了一个Talent Market（人才市场），这是框架的供给侧。

与其他系统"用prompt临时捏造一个角色"不同，OMC从社区验证过的、有基准测试结果背书的智能体实现中招募。

市场上的每个Talent，都是一个完整的可部署包，包含系统提示词、工具配置、技能脚本、领域知识文件，以及基准测试结果，证明它真的能做它声称的事。

人才来源分三种类型：

Type 1：策划仓库智能体。

从成熟的开源智能体仓库手动打包，经过社区验证和基准测试，适合已有成熟实现的领域。

Type 2：Prompt来源智能体 + 技能组装。

从社区整理的高质量Prompt库出发（比如Agency-Agents项目，提供140多个专家角色），再通过SkillsMP市场自动匹配和组装工具技能，适合有明确角色描述但没有完整实现的情况。

Type 3：云端技能动态组装。

完全从SkillsMP的模块化技能库动态构建，角色和技能都是按需生成，适合冷启动场景或者小众领域。

推荐列表的构成大约是80%的Type 1和Type 2，20%的Type 3，反映各渠道当前的成熟度差异。

CEO不是全自动的，系统会给CEO呈现一个排名候选列表，CEO做最终选择，批准后，自动化流程负责配置Container、分配工位、注册组织层级，全程无需手动设置。

三种类型之间也有反馈回路：Type 3动态组装出来的有效角色，可以沉淀为Type 2的Prompt模板；

智能体自我改进后积累的技能，可以发布回技能市场，丰富整个社区资源池。

第二根柱子：E2R 树搜索

这是OMC处理复杂项目的核心机制，解决"怎么把一个大项目拆解并可靠执行"的问题。

为什么需要树搜索

想象一家公司接到一个项目。

可能的应对方式有很多：怎么拆解任务，分配给谁，中间结果不满意怎么办，要不要重新规划。

现有框架要么写死流程图，要么让智能体自由协商。前者遇到新项目傻眼，后者没有收敛保证。

论文观察到，这个问题和博弈树搜索有相同的结构特征：分支因子大、执行结果有随机性、需要平衡探索和利用。

所以他们借鉴了MCTS（蒙特卡洛树搜索） 的结构思路，设计了 E2R（Explore-Execute-Review）。

但有个关键区别：MCTS用模拟估值，E2R用真实执行结果。

智能体真的在做事，不是在估算。

E2R 的三个阶段

Stage 1：Explore（探索，策略选择和任务树展开）

负责决定"怎么拆解当前任务，分配给谁"。

这里有经典的探索-利用权衡：是把任务分给有可验证记录的员工，还是尝试没怎么用过的员工甚至招募新人（探索）？

分支因子是无界的，因为LLM在运行时决定拆解粒度。

Stage 2：Execute（执行，智能体实际完成工作）

每个分配到任务的员工，通过组织层执行任务，产出结果和成本。

对于Claude这样的闭源智能体，内部执行过程对组织层是不透明的，组织层只看输入和输出。

Stage 3：Review（复盘，质量信号向上传播）

每个完成的节点，由其父节点的负责人（通常是COO或上级员工）评估，给出 accept 或 reject 的质量信号。

如果接受，信号向上传播，可能解锁依赖它的下游任务。

如果拒绝，系统重新进入Stage 1，在同一个父节点下探索新的分解方案，相当于在失败的尝试基础上长出一棵新的子树。

这个循环持续到根节点被解决，或者触发熔断机制。

任务树的结构

树的每个节点，代表一个决策点的组织状态，包含：任务描述、分配的员工、当前状态、执行结果、累计成本，以及整棵树共享的员工状态和资源状态。

边分两种：

分解边（Decomposition edges）：父任务被拆成子任务，形成严格的树结构。

依赖边（Dependency edges）：任务执行顺序的约束，比如"前端任务必须等API任务完成才能开始"，可以跨越兄弟节点。

两种边合在一起，必须构成DAG（有向无环图，Directed Acyclic Graph），在插入时通过DFS（深度优先搜索）检测循环，强制保证无环。

系统支持五种动作类型：分解（Adecompose）、分配（Aassign）、招募（Arecruit）、审查（Areview）、迭代（Aiterate）。

有限状态机：每个任务节点的生命周期

每个任务节点有9个状态：

两个关键设计：

completed → accepted 需要主管明确审批。

任务完成不等于可以解锁下游，必须经过审查才行。这是防止错误级联的核心机制。

failed → processing 的重试次数有上限。

超过最大重试次数，自动升级给上级处理，保证没有节点会无限循环。

一个节点被认为"已解决"（resolved），需要满足：

父节点的所有子任务都必须完成，父节点才算完成。没有子任务可以被悄悄跳过。

调度和依赖解析

一个节点变成"可执行"的条件：

调度器按FIFO顺序选择每个员工的第一个可执行节点，并强制互斥执行：每个员工同时只能跑一个任务。

当一个节点进入终态，依赖解析向前传播：

依赖全部满足的节点进入执行队列；

依赖失败的节点被标记为blocked或级联取消；

取消是传递闭包，取消一个节点会自动取消所有依赖它的节点。

叶节点完成并通过审查后，AND语义触发自底向上的递归传播：

如果父节点的所有子节点都resolved，父节点自动升级为 completed → accepted → finished，再触发它的父节点检查，一直到项目根节点。

还有一个死锁检测器：如果所有非根节点都处于终态或blocked，但根节点还没解决，项目被标记为失败，防止无声的停滞。

七个形式化保证

整个DAG执行层提供七个不变量：

DAG不变量：图始终无环，插入时强制检测

互斥执行：每个员工同时最多跑一个任务

调度幂等性：重复调度同一节点是空操作，崩溃恢复不会导致重复执行

审查终止性：每个父节点最多触发有限次审查后升级

级联完整性：取消传播到所有传递依赖节点

依赖完整性：每次状态转移都触发前向依赖解析，没有节点会永久pending

恢复正确性：崩溃后，processing节点重置为pending，所有依赖已满足的节点重新调度

有界理性和熔断机制

真实组织不能无限运行。OMC实现了三个熔断机制：

审查轮次限制：默认每个节点最多3轮审查，超过则升级给上级

任务超时：默认3600秒，超时则标记为failed

成本预算：累计成本超过上限则暂停

三个机制都可以配置。

外部Oracle：CEO的介入

每个项目迭代（iter_001, iter_002...）对应一次搜索。

CEO（或外部客户）扮演外部Oracle的角色，可以做三种干预：

策略覆盖：直接拒绝或重定向某个分解策略

需求注入：中途加入新约束，比如"加上SEO支持"

迭代触发：决定什么时候启动新一轮搜索，什么时候停止

这个人在回路的设计有个实际好处：人类可以早早剪掉没希望的分支，注入系统无法获取的外部信息（市场信号、战略优先级），把计算资源集中在高价值区域。

代价是收敛性依赖人类判断质量，而不是形式保证。

第三根柱子：自我进化机制

前两根柱子解决执行问题，第三根柱子解决学习问题。

个体层面进化

每个智能体维护一个持久的、自动更新的档案，包含跨任务进度日志和LLM总结的工作原则。

两个触发点：

CEO一对一：CEO给某个智能体反馈后，智能体进行结构化自我反思，识别预期行为和实际行为之间的差距，更新工作原则。

任务完成后：智能体回顾自己的执行轨迹（做了哪些决策、调用了哪些工具、遇到了哪些障碍），把总结追加到进度日志里。随着任务积累，这个日志变成一条经验轨迹，丰富智能体的未来上下文。

关键点：这些更新修改的是Talent档案（工作原则、指导说明），不是底层基础模型。

持续改进，不需要重新训练。

组织层面进化

项目结束后，COO主持复盘会议：每个参与员工提交自我评估，总结关键决策、遇到的障碍和解决方案。

COO把这些自我评估，加上客观信号（每个任务的重试次数、审查拒绝原因、资源消耗），提炼成两个输出：

个人反馈：更新每个员工的工作原则

组织SOP（标准操作流程）：把有效模式编码成文档，比如"前后端集成前必须先审查API合约"

SOP作为工作流文档持久化保存，在后续项目中自动注入相关智能体的上下文。

组织知识跨项目积累，不局限于单个智能体的记忆。

HR生命周期管理

每三个项目，HR智能体自动对每个参与员工发起定期绩效评估，评估任务完成质量、审查通过率、协作效果。

连续三次评估不合格，进入PIP（绩效改进计划，Performance Improvement Plan），获得针对性辅导、调整后的任务分配和更密切的监督。

PIP期间再次不合格，触发自动离职：Container被注销，工位释放，能力缺口被标记，等待从Talent Market重新招募。

这个生命周期管理，把Talent Market和组织进化连成了一个闭环：表现差的智能体被新招募的替换，表现好的积累经验变得越来越有效。

论文特别指出，他们没有见过其他工作把这套HR流程（绩效评估、PIP、正式离职）应用到AI智能体生命周期管理上。

实验结果

在 PRDBench 上测试，这是一个包含50个项目级软件开发任务的基准，覆盖20多个领域。

每个任务提供需求文档（PRD，Product Requirement Document），配套详细测试计划和可执行评估脚本，端到端评估智能体解读需求、分解任务、实现方案、满足功能约束的能力。

类型

方法

成功率（%）

成本（$）

单智能体

GPT-5.2

62.49

—

单智能体

Claude-4.5

69.19

—

单智能体

Gemini-3-Pro

22.76

—

单智能体

Qwen3-Coder

43.84

—

单智能体

DeepSeek-V3.2

40.11

—

商业工具

CodeX

62.09

—

商业工具

Claude Code

56.65

—

商业工具

Gemini CLI

11.29

—

多智能体

OMC（Claude Code Sonnet 4.6 + Gemini 3.1 Flash Lite Preview）

84.67（+15.48）

345.59

OMC的团队配置是：一个基于LangGraph的Gemini 2.1 Flash Lite Preview创始智能体，加上从Talent Market招募的三个专家：软件工程师（Claude Code + superpowers插件）、软件架构师（Claude Code，来自agency-agents项目）、代码审查员（同上）。

三个设计决策对这个结果贡献最大：

动态任务树，根据中间结果调整分解，不提前锁死流程。

completed → accepted 审查门，没有经过主管批准的子任务结果，不会传播给下游，减少幻觉输出和错误级联。

Container-Talent分离，允许在同一个项目里招募不同家族的智能体，把合适的工具匹配给合适的子任务。

代价是成本：50个任务花了345美元，平均每个任务约6.9美元。

论文也承认这个开销不小，适合复杂项目，简单任务可以走单智能体路径。

OMC因此引入了自适应调度模式，CEO可以根据任务复杂度选择路由方式。

四个跨领域案例

案例一：内容生成

CEO一句话指令：组建搜索写作团队，生成过去一周GitHub上最热门AI Agent仓库的周报，并发邮件给我，所有仓库必须是真实的。

EA把任务拆成两个顺序阶段，HR查询Talent Market，经CEO批准后，招募了一个研究员（GPT-4o）和一个写手（Claude Sonnet 4）。

COO构建动态任务树，研究员收集真实GitHub仓库链接和摘要，写手撰写趋势报告并发送邮件。

全程10分钟，花费4.48美元。

论文团队人工验证了报告里所有仓库链接和Star数，全部真实准确。

案例二：游戏开发

CEO指令：开发一个画面精良的街机格斗网页游戏，有流畅动画和精美UI。

招募了游戏开发者（Claude Sonnet 4）和美术设计师（Gemini 2.5 + NanoBanana工具）。

美术先生成角色动作图（待机、行走、踢击、受伤），开发者等待后集成进游戏代码。

初版发给外部评测员，评测员发现精灵图（sprite sheets，角色动画帧的合集图）没有正确切割，导致动画帧渲染错误。

系统没有打补丁，而是给美术设计师创建了一个新技能，让它学会程序化切割合集图为独立帧。

美术用新技能重新处理所有素材，开发者重新集成，最终版本交付评测员。

这个案例展示了人在回路的迭代，以及系统在遇到问题时选择扩展能力而不是打补丁的策略。

案例三：有声书制作

有声书案例的团队组建、智能体档案、输出文档和成本明细。约156万token，总花费1.57美元。

CEO指令：把《浴血黑帮》第一、二集改编成动物角色版有声书（Tommy是狼，Arthur是熊），保留原始剧情和标志性对白，每集生成8个场景插图配英文旁白，最终合成带背景音乐的视频。

招募了小说写手（Claude Sonnet 4）和AV制作人（Gemini 3.1 Pro，配备图像生成、语音合成、视频合成自定义工具）。两个智能体跑在不同后端，通过共享任务树协调。

输出：16个场景图、16段配音、背景音乐、两集最终视频，加上可复用的执行脚本和验证日志。

总花费1.57美元。

案例四：学术调研

OMC研究团队自动生成的思维导图，覆盖六个主题（基础、基于模型的强化学习、视频/生成模型、语言条件世界模型、Sim-to-Real迁移、前沿架构），约70个节点，引用35篇以上2021-2026年的论文。

CEO指令：调研"具身AI和机器人的世界模型"领域（2021-2026），生成详细的带引用思维导图，提出三个可行的研究方向。

招募了三个专家：研究科学家（Claude Sonnet 4.6，负责文献综述和想法生成）、研究论文科学家（Claude Sonnet 4.6，负责调研结构和文档）、AI工程师（自托管，负责技术基准测试）。

COO把项目拆成两个阶段。

Phase 1三个专家并行：

一个构建调研框架和35篇种子论文列表；

一个审查17篇论文，整理8个开放问题和11种失败模式；

一个对28个系统做部署就绪度基准测试。

Phase 2产出论文纳入协议、931行文献综述框架，以及三个基于Phase 1发现的失败模式的研究想法。

不到一小时完成，总花费16.26美元（15.9M token）。

三个研究想法：

想法

针对的问题

目标会议

核心技术

HiTeWM（分层时序世界模型）

15步以上的累积预测误差

NeurIPS / ICLR

双层架构（50Hz快模型 + 2Hz慢模型），不确定性门控重接地

PhysWM（物理约束潜在世界模型）

视频世界模型中的物理不合理性

ICML / CoRL

可微物理约束注入潜在动态函数

MAWM（元自适应世界模型）

Sim-to-real领域偏移 + 过度自信幻觉

CoRL / ICLR

跨仿真域元学习 + 保形预测校准不确定性

论文作者人工验证了输出质量：所有引用论文都是真实的，失败模式分类结构合理，第三个想法（MAWM）被评价为"有真实新颖性"。

和其他系统的对比

从表可以看出三个结构性差距：

异构性和运行时抽象。

MetaGPT、AutoGen、CrewAI等系统，智能体身份和执行运行时是耦合的，没有正式的可替换合约。

OMC的六个类型化接口填补了这个空白。

动态任务协调。

现有系统要么写死工作流图，要么运行时动态调整但没有形式完成保证。

OMC是对比系统中唯一提供可证明的终止性和死锁自由性的。

自我进化和组织进化。

对比表中没有其他系统同时实现个体自我进化和组织进化。

现有框架把智能体当成无状态执行器，每次任务重新实例化，任何适应都需要用户在外部实现。

局限性

论文坦承了几个限制：

量化评估范围有限。 只在PRDBench（50个软件开发任务）上做了系统评估，非编程领域的系统性基准测试还是未来工作。

自我进化机制没有消融实验。 一对一、复盘、绩效评估各自贡献多少，需要跨多个项目的纵向研究来隔离。

成本开销不小。 平均每个PRDBench任务6.9美元，对简单任务不划算。

这个方向有意思在哪里

OMC把一个工程问题，用一个很有解释力的框架重新定义了。

技能（Skills） 解决"单个智能体能做什么"。

多智能体系统 解决"智能体之间怎么交互"。

AI组织 解决"一支智能体队伍应该怎么被组建、管理和进化"。

三层是不同粒度的问题，以前大家混在一起处理，OMC把它们分开了。

论文最后提到，人类企业的组织结构之所以跨行业通用，是因为它和具体员工的知识解耦了。

同样的管理原则，可以用于软件公司，也可以用于制造业。

OMC的赌注是：这个解耦对AI系统同样成立。

四个案例研究用的是完全不同的模型组合（GPT-4o、Claude Sonnet 4、Gemini 2.5、Gemini 3.1 Pro、自托管智能体），覆盖内容生成、游戏开发、多媒体制作、学术研究四个领域，没有一个需要修改框架本身。

项目主页：one-man-company.com

代码开源: 1mancompany.github.io/OneManCompany

Talent Market: one-man-company.com/market

© 2026

·

向阳乔木