From Skills to Talent: Organising Heterogeneous Agents as a Real-World Company

Paper: arXiv:2604.22446 Code: 1mancompany/OneManCompany Code reference: main @ 8f880c03 (2026-05-22)

1. Motivation (研究动机)

这篇论文要解决的不是“让单个 Agent 再多会几个 skill”，而是“当任务需要一整个可变化、可管理、可复盘的 Agent workforce 时，系统层应该如何组织”。作者的出发点是：Claude Code、Codex、OpenClaw 这类单体 Agent 已经能通过 skill / tool integration 获得很强的局部能力，但 skill 仍然绑定在单个 Agent 内部；它能扩展“一个 Agent 能做什么”，却不能回答“多个异构 Agent 如何被招聘、调度、审查、替换和长期进化”。

现有 Multi-Agent LLM 系统的主要瓶颈有四类。第一，团队结构常常在执行前固定，例如固定的 role graph / SOP pipeline，遇到新项目时缺少按需招聘与重组能力。第二，协调逻辑与 runtime 强耦合，LangGraph、Claude CLI、script-based executor 等后端往往不能在同一组织内互操作。第三，许多系统用 prompt 描述角色能力，而不是用可执行 contract / tool / benchmark evidence 描述能力，因此容易出现“看起来会做、实际没有工具或权限”的 hallucinated capability。第四，自我改进通常停留在单次会话或单个框架内，任务结束后的经验没有沉淀为可复用的 employee profile、SOP 或 HR lifecycle。

OMC（OneManCompany）的目标是补上一个“组织层”：把 agent workforce 作为类似真实公司的系统来构造。这个组织层需要能在项目过程中招聘 Talent、把 Talent 部署到不同 Container、用任务树分解和审查结果、把个人经验与项目复盘写回组织知识。作者认为这个问题值得研究，因为开放式真实任务往往不是一次 prompt 或固定流水线能解决的；如果组织层成立，multi-agent system 就可以从“静态 pipeline”变成“可按需组队、可长期积累、可替换低效员工”的 AI organisation。

Figure 1 解读：图中展示的是 OMC 的实际运行界面，而不是一个抽象概念图。左侧的 Talent Lifecycle 记录 employee profile、skill、performance 与 configuration；中间的 Task Decomposition 把项目组织成层级任务树和依赖关系；右侧的 Agent Coordination 让员工请求会议、提交结果、等待 review。它说明论文的核心对象是“公司式管理界面 + 后端组织机制”，不是单个模型或单个 planner。

2. Idea (核心思想)

核心 insight 是：Multi-Agent system 缺的不是更多角色 prompt，而是一个类似操作系统 / 公司治理结构的 organisational layer。OMC 把可复用能力从低层 skill 提升为 Talent（带角色、工具、skill、配置、证据的 portable agent identity），再把 Talent 放入 Container（runtime backend + 六类组织接口）中运行，从而把“人是谁”和“在哪个执行后端运行”解耦。

与 CrewAI、AutoGen、MetaGPT / ChatDev 等系统相比，OMC 的差异在于组织结构本身是动态对象：团队可按需从 Talent Market 招聘，任务执行被建模为 Explore-Execute-Review（ $E^{2} R$ ）树搜索，任务结果必须经过 supervisor review gate 才能向下游传播，并且项目结束后会更新 employee working principles 与 organisation SOP。换句话说，OMC 不只是把多个 Agent 接到一张图上，而是把招聘、执行、审查、复盘、淘汰这些“公司行为”形式化为系统机制。

Figure 2 解读：这张 overview 把论文的三根支柱放在同一个循环里：Talent Market 负责供给可验证的 Agent； $E^{2} R$ tree search 负责把项目请求变成可执行、可审查的任务树；Individual / Project review 负责把执行经验回写到 Talent 和 SOP。图中“CEO / client → organisation layer → downstream AI talents”的路径强调，人类 CEO 不是微观控制每个工具调用，而是在组织层进行 policy override、requirement injection 与 iteration triggering。

3. Method (方法)

3.1 Overall framework：把 Agent workforce 当作公司来运行

OMC 的总体框架由三层组成。第一层是 workforce layer：Employee 是最小执行单元，由 Talent 与 Container 组合而成；Talent 保存认知身份与能力包，Container 提供 runtime 和组织接口。第二层是 project execution layer：CEO 或外部客户给出项目后，系统通过 $E^{2} R$ tree search 逐步探索 decomposition strategy，并把选中的 strategy 交给 DAG scheduler 执行。第三层是 evolution layer：个人层通过 one-on-one 与 post-task reflection 更新 working principles；组织层通过 retrospective、SOP、HR review、PIP / offboarding 更新组织知识和员工生命周期。

直觉上，这种设计有效是因为它把 multi-agent coordination 中最容易失控的部分拆成了三类明确 contract：能力供给 contract（Talent Market 说明谁能做什么）、执行接口 contract（Container 说明如何 dispatch、存储、通信和生命周期管理）、质量传播 contract（task FSM + review gate 说明什么结果能流向下游）。如果没有这些 contract，系统要么退化成固定 pipeline，要么变成自由聊天式协作，很难保证任务不会卡住、能力不会虚构、错误不会层层传播。

3.2 Talent–Container Architecture：Employee = Talent + Container

Figure 4 解读：图中左侧 Talent 是可迁移的身份包，包含 role、skills、tools、domain knowledge、LLM / agent family configuration 等；右侧 Container 是执行后端和六个组织接口的集合。相同 Talent 可以部署到 LangGraph、Claude Code 或 script-based backend；相同 Container 也可以承载不同 Talent。这种拆分使 OMC 可以把来自不同 agent family 的员工放入同一组织，而不需要为每个后端重写调度、事件、存储和生命周期逻辑。

论文把 Container 的组织接口分成六类：Execution 负责把 task dispatch 到后端并返回 result / cost；Task 维护 per-employee queue 和 mutual exclusion；Event 提供 publish / subscribe 组织事件；Storage 保存 profile、progress log、memory；Context 将 Talent role、working principles、guidance、memory 组装为执行上下文；Lifecycle 运行 pre-hook / post-hook，用于 guardrail、input validation、自反思和 skill refinement。对应 released code 中，src/onemancompany/core/vessel.py 的 _build_dependency_context、build_role_identity、_build_tree_context 体现了 Context/Task/Dependency 注入，src/onemancompany/core/vessel_config.py 和 src/onemancompany/core/default_vessel.yaml 定义 Vessel / Container 配置。

3.3 Digital Talent Market：按需招聘而不是预先固定团队

Talent Market 是 Container 抽象的供给端。每个 Talent 是一个 ready-to-deploy package，而不是一段角色描述：它可以包含 profile.yaml、manifest.json、launch.sh、run_worker.py、skills/、tools/manifest.yaml、benchmark results 与 source repo evidence。论文区分三类供给：Type 1 从成熟开源 agent repository 包装出 curated repository agents；Type 2 从 Agency-Agents 等 prompt repository 出发，通过 SkillsMP 检索并装配 tool / skill；Type 3 则面向缺口能力做 AI-recommended assembly。

released code 中，src/onemancompany/agents/recruitment.py 的 CandidateProfile、HireRequest、search_candidates、submit_shortlist 对应“搜索候选人 → 生成 shortlist → 提交招聘”的流程；src/onemancompany/talent_market/talent_spec.py 明确规定 Talent package 的目录结构和 manifest fields。这个设计的关键价值是把“能力声明”落到可检查的 artifact 上：工具、skill、repo、benchmark、hosting mode、auth method、cost 都进入候选人 profile，减少 prompt-only role assignment 的能力幻觉。

3.4 $E^{2} R$ tree search：Explore → Execute → Review

论文把组织决策建模为动态树 $T = (V, E_{t ree}, E_{d e p})$ 。每个节点 $v \in V$ 对应一个组织状态 / 任务决策点，携带： $(d_{v}, e_{v}, s_{v}, r_{v}, c_{v}, W, R)$ 其中 $d_{v}$ 是 task description， $e_{v}$ 是被分配 employee（可为空）， $s_{v}$ 是任务状态， $r_{v}$ 是执行结果， $c_{v}$ 是累计 cost， $W$ 是 workforce state， $R$ 是 token / cost / time 等 resource state。树中有两类边：decomposition edge $E_{t ree}$ 表示父任务被拆成哪些子任务；dependency edge $E_{d e p}$ 表示某个任务必须等另一个任务 accepted 后才能开始。整体图 $G = (V, E_{t ree} \cup E_{d e p})$ 必须是 DAG，插入时通过 cycle detection 保证。

动作空间写作： $A = A_{d eco m p ose} \cup A_{a ss i g n} \cup A_{recr u i t} \cup A_{re v i e w} \cup A_{i t er a t e}$ 其中 decompose 增加子任务，assign 绑定员工，recruit 从 Talent Market 补齐能力，review 接受或拒绝结果，iterate 以新 strategy 开启下一轮。和 MCTS 的类比只在结构上成立：OMC 不做 simulated rollout，也不用 UCB；Execute 阶段是真实员工产出 deliverable，Review 信号来自 supervisor evaluation 和 human oracle。策略更新也不是梯度训练，而是把执行历史 $H_{k} = {(v, r_{v}, c_{v}, q_{v})}$ 、employee profile、SOP 等加入后续上下文： $π_{k + 1} = U (T_{k}, π_{k}, H_{k})$

3.5 DAG execution 与 review gate：防止 silent stall 和错误传播

Figure 5 解读：图中 task lifecycle 的关键不是状态数量，而是 completed → accepted → finished 的显式 review gate。employee 完成执行后只进入 completed，下游依赖不会自动放行；必须由 supervisor 执行 accept_child() 才能进入 accepted，依赖它的任务才会看到可用结果。若 review 失败，任务进入 failed 或重新回到可执行状态，避免错误结果在 DAG 中静默传播。

每次 $E^{2} R$ 搜索迭代与一次 DAG execution cycle 结合为： $(r, c, q) = I (T, a) = S_{D A G} (T (T, a))$ $T (T, a)$ 是应用 decomposition action 后的 successor tree， $S_{D A G}$ 负责调度 ready nodes、解析 dependency、传播 review signal。论文定义 AND-tree resolved 语义：叶节点需要处于 accepted / finished，内部节点需要所有非系统子节点 resolved；因此父任务不能在子任务被遗漏时完成。bounded rationality 由三类 circuit breaker 实现：review round limit $n_{re v} (v) > k_{re v}$ 时 escalation（默认 $k_{re v} = 3$ ），execution timeout $t_{e x ec} (v) > T_{ma x}$ 时 failed（默认 $T_{ma x} = 3600 s$ ），以及总 cost 超过预算 $\sum_{v \in V} c_{v} > B$ 时 pause。

released code 与公式基本对齐：TaskPhase 在 src/onemancompany/core/task_lifecycle.py 中包含 pending / processing / holding / completed / accepted / finished / failed / blocked / cancelled，UNBLOCKS_DEPENDENTS 只包含 accepted 和 finished；dispatch_child() 的默认 timeout_seconds=3600 与论文默认超时一致。论文公式与 released code 实现差异：论文中的 $E^{2} R$ policy update 是概念化的组织策略更新，repo 中没有单独的 MCTS / policy class；实现落在 tree_tools.py、task_tree.py、vessel.py、SOP / workflow documents 和 employee profile persistence 上，由 LLM supervisor 结合上下文执行策略选择。

3.6 Self-evolution：个人经验与组织 SOP 的双层沉淀

个人层面，每个 agent 维护 persistent profile：cross-task progress log 与 LLM-summarised working principles。触发器有两个：CEO one-on-one 后进行 structured self-reflection，比较期望行为与实际行为；task completion 后回看 execution trace（决策、工具、障碍），把总结写入 progress log。重要的是，更新对象是 Talent artifact（principles / guidance notes），不是 foundation model 参数，因此可以在不训练模型的情况下跨任务累积。

组织层面，项目完成后 COO 组织 retrospective：参与员工提交 self-assessment，COO 聚合 retry counts、review rejection reasons、resource consumption 等信号，输出 individual feedback 和 organisation SOP。HR lifecycle 则每三项目触发 periodic review；连续三次 review 失败进入 Performance Improvement Plan；PIP 下再失败则 offboarding，释放 Container / desk 并重新从 Talent Market 补缺口。这个闭环让 Talent Market 不只是招聘入口，也成为淘汰和再招聘的反馈端。

3.7 Pseudocode（基于 released code 的实现级抽象）

from dataclasses import dataclass
from enum import Enum
 
class TaskPhase(str, Enum):
    PENDING = "pending"
    PROCESSING = "processing"
    HOLDING = "holding"
    COMPLETED = "completed"
    ACCEPTED = "accepted"
    FINISHED = "finished"
    FAILED = "failed"
    BLOCKED = "blocked"
    CANCELLED = "cancelled"
 
UNBLOCKS_DEPENDENTS = {TaskPhase.ACCEPTED, TaskPhase.FINISHED}
 
@dataclass
class TaskNode:
    id: str
    parent_id: str
    employee_id: str
    description: str
    acceptance_criteria: list[str]
    status: TaskPhase = TaskPhase.PENDING
    result: str = ""
    depends_on: list[str] = None
    timeout_seconds: int = 3600
 
 
def dispatch_child(tree, parent_id, employee_id, description, criteria, depends_on=None):
    parent = tree.get_node(parent_id)
    assert parent is not None
    assert tree.load_employee(employee_id) is not None
    child = tree.add_child(
        parent_id=parent.id,
        employee_id=employee_id,
        description=description,
        acceptance_criteria=criteria,
        timeout_seconds=3600,
        depends_on=depends_on or [],
    )
    parent.status = TaskPhase.HOLDING
    if all(tree.get_node(d).status in UNBLOCKS_DEPENDENTS for d in child.depends_on):
        tree.enqueue_for_execution(child)
    return child

def build_employee_context(tree, node, employee_profile):
    role_identity = build_role_identity(employee_profile)  # role, level, department, archetype
    dependency_results = []
    for dep_id in node.depends_on or []:
        dep = tree.get_node(dep_id)
        if dep and dep.status in UNBLOCKS_DEPENDENTS:
            dependency_results.append((dep.employee_id, dep.description, dep.result[-2000:]))
 
    task_chain = tree.collect_ancestors(node, full_depth=1, skeleton_after=1)
    child_review_context = tree.collect_children(node, include_results_when_done=True)
    return {
        "role_identity": role_identity,
        "dependency_results": dependency_results,
        "task_chain": task_chain,
        "current_task": node.description,
        "acceptance_criteria": node.acceptance_criteria,
        "children": child_review_context,
    }

def run_container_task(container, talent, tree, node):
    if container.has_running_task(talent.employee_id):
        container.enqueue(node)
        return {"status": "queued"}
 
    context = build_employee_context(tree, node, talent.profile)
    context = container.pre_hook(node, context)          # validation / guardrail / enrichment
    node.status = TaskPhase.PROCESSING
    result, cost = container.execute(
        task=node.description,
        context=context,
        tools=talent.tools,
    )
    node.result = result
    node.cost_usd += cost
    node.status = TaskPhase.COMPLETED
    container.post_hook(talent.employee_id, node, result)  # memory / principle update
    container.publish_event((node.id, "processing->completed", talent.employee_id))
    return {"result": result, "cost": cost}

def review_child(tree, parent_id, child_id, passed, notes):
    child = tree.get_node(child_id)
    if passed:
        child.status = TaskPhase.ACCEPTED
        child.acceptance_result = {"passed": True, "notes": notes}
        for dependent in tree.nodes_depending_on(child.id):
            if all(tree.get_node(d).status in UNBLOCKS_DEPENDENTS for d in dependent.depends_on):
                tree.enqueue_for_execution(dependent)
    else:
        child.status = TaskPhase.FAILED
        child.acceptance_result = {"passed": False, "notes": notes}
 
    parent = tree.get_node(parent_id)
    if all(tree.get_node(c).status == TaskPhase.ACCEPTED for c in parent.children_ids):
        parent.status = TaskPhase.COMPLETED
    return child.acceptance_result

def search_and_hire(talent_market, job_description, company_defaults):
    raw_candidates = talent_market.search(job_description)
    shortlist = []
    for raw in raw_candidates:
        profile = normalize_market_candidate(raw)  # id, role, skills, tools, score, costs
        if profile.jd_relevance >= 0.0:
            shortlist.append(profile)
 
    selected = submit_shortlist(shortlist)          # CEO / HR approval path
    vessel_config = create_vessel_yaml(
        talent_id=selected.talent_id,
        api_provider=selected.api_provider or company_defaults.provider,
        model=selected.llm_model or company_defaults.model,
        tools=selected.tools,
        hosting=selected.hosting,
        auth_method=selected.auth_method,
    )
    employee = onboard_employee(selected, vessel_config)
    return employee

def retrospective_and_hr_lifecycle(project, employees, hr_state):
    self_assessments = [e.write_self_assessment(project.trace) for e in employees]
    objective_signals = collect_signals(
        retry_counts=project.retry_counts,
        rejection_reasons=project.review_rejections,
        resource_costs=project.costs,
    )
    sop_updates, individual_feedback = coo_distill_retrospective(self_assessments, objective_signals)
    persist_sops(sop_updates)
    for employee in employees:
        employee.profile.working_principles += individual_feedback.get(employee.id, [])
        if hr_state.projects_since_review(employee.id) >= 3:
            review = hr_periodic_review(employee, project.history)
            if review.failed_three_times:
                employee.status = "PIP"
            if employee.status == "PIP" and review.failed_again:
                offboard(employee)
                flag_capability_gap_for_recruitment(employee.role)

Code reference: main @ 8f880c03 (2026-05-22) — pseudocode and mapping based on this commit

Paper Concept	Source File	Key Class/Function
Talent package specification	`src/onemancompany/talent_market/talent_spec.py`	`SettingField`, `ManifestPrompts`, Talent directory schema
Candidate / hiring pipeline	`src/onemancompany/agents/recruitment.py`	`CandidateProfile`, `HireRequest`, `search_candidates`, `submit_shortlist`
Employee runtime / context assembly	`src/onemancompany/core/vessel.py`	`_build_dependency_context`, `build_role_identity`, `_build_tree_context`, `_trigger_dep_resolution`
Task lifecycle FSM	`src/onemancompany/core/task_lifecycle.py`	`TaskPhase`, `VALID_TRANSITIONS`, `UNBLOCKS_DEPENDENTS`, `transition`
Dynamic task tree	`src/onemancompany/core/task_tree.py`	`TaskNode`, `TaskTree.add_child`, dependency fields, persistence helpers
Dispatch and review tools	`src/onemancompany/agents/tree_tools.py`	`dispatch_child`, `accept_child`, `reject_child`, `create_project`
SOP / organisation memory	`company/operations/sops/.md`, `company/human_resource/workflows/.md`	project execution, task lifecycle, retrospective, hiring/offboarding workflows
Vessel configuration	`src/onemancompany/core/vessel_config.py`, `src/onemancompany/core/default_vessel.yaml`	`VesselConfig`, execution limits, hooks, context settings

4. Experimental Setup (实验设置)

实验主 benchmark 是 PRDBench，包含 50 个 project-level software development tasks。评测采用官方 DEV mode：每个系统接收 PRD 作为一次性输入，不能依赖 iterative feedback 或外部人工干预，最终输出由自动脚本评估。主要指标是 Success Rate，即成功完成任务的比例；论文额外报告 OMC 的 Cost Overhead（token/API cost），用于反映 zero-shot project execution 下的系统开销。论文没有给出 GPU 型号或训练硬件，因为 OMC 不是一个需要梯度训练的新模型，而是基于 LLM / agent backend 的组织与执行框架。

OMC 的 agent setup 如下：founding agent 是 LangGraph-based agent，使用 Gemini 2.1 Flash Lite Preview；在第一个 PRD project 开始时，HR 从 Talent Market 招募三个专业员工：Software Engineer（Claude Code-based agent，带 https://github.com/obra/superpowers plugin）、Software Architect（Claude Code-based agent，来自 https://github.com/msitarzewski/agency-agents）、Code Reviewer（同样来自 agency-agents）。论文主表中 OMC 的方法行写作 “Claude Code Sonnet 4.6 + Gemini 3.1 Flash Lite Preview”；这与 setup 文本中的 “Gemini 2.1 Flash Lite Preview” 存在版本表述不一致，笔记保留两处原文并把它视为论文内部命名差异，而不是 released code 可验证的训练配置。

比较 baselines 来自 PRDBench 同一 setting。Minimal agent 包括 GPT-5.2、Claude-4.5、Gemini-3-Pro、Qwen3-Coder、Kimi-K2、DeepSeek-V3.2、GLM-4.7、Minimax-M2；Commercial agent 包括 CodeX、Claude Code、Gemini CLI、Qwen Code。成本方面，PRDBench baseline 未报告 cost，所以论文只能报告 OMC 总成本，不能做严格 cost-efficiency 对比。

Figure 6 解读：这是游戏开发 case 的任务树，展示 COO 如何把开放式项目拆成多层子任务，并在中途加入 human-in-the-loop feedback。它不是 PRDBench 主表的一部分，但能说明实验与 case study 想验证的能力：OMC 能在真实项目中动态生成树结构、分配员工、等待 review，而不是只执行预定义 workflow。

5. Experimental Results (实验结果)

5.1 PRDBench 主结果

Agent Type	Method	Success Rate (%)	Cost ($)
Minimal	GPT-5.2	62.49	-
Minimal	Claude-4.5	69.19	-
Minimal	Gemini-3-Pro	22.76	-
Minimal	Qwen3-Coder	43.84	-
Minimal	Kimi-K2	20.52	-
Minimal	DeepSeek-V3.2	40.11	-
Minimal	GLM-4.7	38.39	-
Minimal	Minimax-M2	17.60	-
Commercial	CodeX	62.09	-
Commercial	Claude Code	56.65	-
Commercial	Gemini CLI	11.29	-
Commercial	Qwen Code	39.91	-
Multi-agent	Ours (Claude Code Sonnet 4.6 + Gemini 3.1 Flash Lite Preview)	84.67 (+15.48)	345.59

OMC 在 PRDBench 上达到 84.67% success rate，比最强 baseline Claude-4.5 的 69.19% 高 15.48 percentage points。总成本是 $345.59 ， 50 个任务平均约$ 6.91 / task。作者把收益归因于三点：动态任务树能根据中间结果调整 decomposition；completed → accepted review gate 降低 hallucinated outputs 和 error cascade；Container–Talent separation 允许同一项目混用 LangGraph、Claude CLI、script-based 等异构后端。

5.2 Case studies：跨域应用证据

Figure 8 解读：这张任务分解树展示 OMC 如何把一个复杂请求拆成多级节点，并为不同分支分配执行与 review。它与 §3 的 $T = (V, E_{t ree}, E_{d e p})$ 对应：树边负责 decomposition，依赖边和状态机负责执行顺序与验收。对读者来说，它比公式更直观地展示了“组织策略”实际长什么样。

Figure 7 解读：三张 sample frame 来自 generated audiobook video，展示 OMC 不只做代码任务，也能组织 image generation、text-to-speech、video composition 等工具链。论文在 audio book case 中使用 Gemini 3.1 Pro 和自定义工具生成动物角色场景与 narration overlays，强调组织层可以跨 creative production pipeline 调度员工。

Figure 12 解读：Automated research survey case 中，OMC 招募/组织多个研究相关员工完成 world model survey。图中展示团队组成和任务协作结构，说明 Talent Market + task tree 不局限于 software engineering，而能扩展到 research workflow：搜索论文、整理 repository links、生成 survey material、由 reviewer 检查输出。

Figure 13 解读：该 mind map 由 OMC research team 自动生成，覆盖 Foundations、Model-Based RL、Video/Generative、Language-Conditioned、Sim-to-Real、Frontier Architectures 六个主题，约 70 个节点并引用 35+ 篇 2021–2026 年论文。它是论文展示“组织式研究能力”的主要定性证据：不只是把资料堆在一起，而是形成结构化 taxonomy 和问题空间。

5.3 研究想法与架构比较

论文 Table 3 给出 OMC 从 world model survey 中自主生成的三个 research ideas：HiTeWM 针对超过 15 steps 后的 compounding prediction error，提出 50Hz / 2Hz 双层 architecture 和 uncertainty-gated re-grounding；PhysWM 针对 video-based world model 的 physical implausibility，把 differentiable physics constraints 注入 latent dynamics；MAWM 针对 sim-to-real domain shift 和 overconfident hallucination，结合跨仿真域 meta-learning 与 conformal prediction。它们不是 benchmark 分数，但展示了 OMC 能把 survey 产物转化为 proposal-level idea。

Table 4 的架构比较中，OMC 被标为 Organisation paradigm、On-demand execution、6 typed interfaces、Disk state management、Multi-family execution、Talent Market source，并同时支持 individual self-evolution 与 organisation-level evolution。MetaGPT / ChatDev、AutoGen / LangGraph、CrewAI / Agno、OpenHands、AIOS、AgentScope、Paperclip 等系统在这些列上通常缺少 multi-family execution 或双层 evolution。这个比较支持作者的主张：OMC 的新意在组织层，而不是在某个单独 planner / executor。

5.4 局限性与结论

作者明确承认两点局限。第一，定量评测只覆盖 PRDBench 的 50 个 software development tasks；content generation、game development、audiobook production、academic research 只是 case studies，尚未在非代码 benchmark 上系统量化。第二，self-evolution 机制（one-on-one、retrospective、performance review）虽然已经实现和部署，但没有做定量 ablation；每个机制单独贡献需要长期、多项目 longitudinal study。

成本也是实际约束：OMC 的多 Agent 协调带来显著开销，约 $6.91 / PRDBench task。论文认为这适合复杂 project-level task，而不适合简单 single-turn query；因此系统引入 adaptive dispatch mode，让 CEO 将简单任务路由给单个 Agent，只在任务超过复杂度阈值时启用多 Agent coordination。总体结论是：如果任务需要跨领域专家、长程依赖和可审查交付物，组织层可以显著提升成功率；但它的收益必须和成本、benchmark 范围、长期演化效果一起评估。

Paper Notes

探索

From Skills to Talent: Organising Heterogeneous Agents as a Real-World Company

From Skills to Talent: Organising Heterogeneous Agents as a Real-World Company

1. Motivation (研究动机)

2. Idea (核心思想)

3. Method (方法)

3.1 Overall framework：把 Agent workforce 当作公司来运行

3.2 Talent–Container Architecture：Employee = Talent + Container

3.3 Digital Talent Market：按需招聘而不是预先固定团队

3.4 E2R tree search：Explore → Execute → Review

3.5 DAG execution 与 review gate：防止 silent stall 和错误传播

3.6 Self-evolution：个人经验与组织 SOP 的双层沉淀

3.7 Pseudocode（基于 released code 的实现级抽象）

4. Experimental Setup (实验设置)

5. Experimental Results (实验结果)

5.1 PRDBench 主结果

5.2 Case studies：跨域应用证据

5.3 研究想法与架构比较

5.4 局限性与结论

目录

3.4 $E^{2} R$ tree search：Explore → Execute → Review