--- layout: post.njk source: https://blog.qiaomu.ai/managing-ai-agents-as-a-company speaker: 向阳乔木 title: AI也要做绩效考核？这个框架给智能体安排了HR、PIP和末位淘汰 · 乔木博客 date: '2026-04-29' summary: 本文介绍了OMC框架，它将多智能体AI系统视为一家“AI组织”，具备HR、生命周期管理和进化机制。通过“Talent-Container”架构和“E2R”任务执行，实现异构智能体的高效协作与系统性管理，并引入人才市场和绩效考核，以解决现有AI系统管理和协作的挑战。 area: tech-engineering category: ai-application tags: - multi-agent-systems - ai-organization - framework - agent-lifecycle people: - 乔木 companies_orgs: - Huawei Noah's Ark Lab - UCL - University of Liverpool products_models: - OMC - Claude Code - Gemini - GPT-4o - LangGraph - AutoGen media_books: [] draft: true status: evergreen --- 乔木博客 全部 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 · 向阳乔木