多 Agent 系统的组织困境
过去一年，多 Agent 系统从论文走向了生产。AutoGen、CrewAI、LangGraph 等框架让”组建一个 Agent 团队”变得前所未有的简单——定义角色、分配工具、写好 prompt，一个团队就跑起来了。
但用过一段时间后，你会发现一个根本性的问题：这些系统的组织方式是静态的。
你在 CrewAI 中定义一个 Researcher、一个 Writer、一个 Reviewer，它们就永远是这三个角色。明天来了一类新任务，需要一个 Data Analyst，你要改代码、加 Agent、重新配置协作关系。后天又来一类只需要 Researcher 和 Writer 的简单任务，Reviewer 就在那里空转，白白消耗 token。
这就像一家公司，所有员工都是终身制、岗位固定、不看绩效。听起来很荒谬？但这正是大多数多 Agent 系统的实际运作方式。
2026 年 4 月，arXiv 上出现了一篇 33 页的论文——“From Skills to Talent: Organising Heterogeneous Agents as a Real-World Company”（arXiv:2604.22446）。它提出了一个叫 OneManCompany（OMC）的框架，核心观点只有一句话：把 Agent 系统当成一家公司来管理。
这篇文章从架构设计、核心机制、工程实践三个维度深度拆解 OMC 框架，然后讨论它对现有系统设计的启示。
OneManCompany 的核心理念
OMC 的命名来自一个思想实验：如果一个人要创建一家公司来完成任何任务，他会怎么做？
答案不是”雇一群专家然后固定分工”，而是：
- 先建人才库——收集各种能力的 Agent，每个 Agent 有清晰的能力描述和历史记录
- 任务来了再组建团队——根据任务需求，从人才库中”招聘”最合适的 Agent
- 分层决策——有人做战略拆解，有人做任务分配，有人做具体执行
- 看绩效用人——历史表现好的 Agent 更容易被选中，表现差的逐渐被淘汰
这四点听起来像废话——哪个人力资源教科书不是这么写的？但把它映射到 Agent 系统，每一条都对应着现有框架的痛点。
┌─────────────────────────────────────────────────────────────┐
│ OneManCompany 架构总览 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ │
│ │ Agent Pool │ ◄── 可移植身份 + 历史绩效 │
│ │ (人才库) │ 10~100 个异构 Agent │
│ └──────┬──────┘ │
│ │ │
│ ▼ 动态招聘 │
│ ┌──────────────────────────────────┐ │
│ │ Task Decomposition (CEO Agent) │ │
│ │ 战略拆解：目标 → 子任务列表 │ │
│ └──────────────┬───────────────────┘ │
│ │ │
│ ▼ 团队组装 │
│ ┌──────────────────────────────────┐ │
│ │ Team Assembly (Manager Agents) │ │
│ │ 为每个子任务选择最优 Agent 组合 │ │
│ └──────────────┬───────────────────┘ │
│ │ │
│ ▼ 并行执行 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Worker A │ │ Worker B │ │ Worker C │ ◄─ 从 Agent Pool │
│ │ (代码) │ │ (调研) │ │ (写作) │ 动态选出 │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │ │
│ ▼ 绩效回写 │
│ ┌──────────────────────────────────┐ │
│ │ Performance Evaluation │ │
│ │ 更新每个参与 Agent 的绩效档案 │ │
│ └──────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘四大核心机制详解
机制一：可移植身份（Portable Identity）
在 AutoGen 中，一个 Agent 的”身份”就是它的 system prompt。你写上”You are a Python expert”，它就是一个 Python 专家。这个身份是框架内部的、不可导出的、与其他系统无关的。
OMC 把 Agent 的身份做成了一个可移植的结构化文件。这不只是一个 system prompt，而是一份完整的”简历”：
interface AgentIdentity {
id: string;
name: string;
// 能力描述：不只是"擅长什么"，而是具体到什么粒度
capabilities: {
domain: string; // e.g., "data-analysis"
skills: string[]; // e.g., ["pandas", "sql", "visualization"]
toolPermissions: string[]; // 可以调用哪些工具
constraints: string[]; // 不能做什么
}[];
// 历史绩效：核心差异化要素
performance: {
tasksCompleted: number;
successRate: number; // 0.0 ~ 1.0
avgQualityScore: number; // 0.0 ~ 1.0
avgResponseTime: number; // 毫秒
eloRating: number; // ELO 评分，类比棋手等级分
recentTrend: "improving" | "stable" | "declining";
};
// 领域标签：用于快速匹配
tags: string[]; // e.g., ["python", "backend", "data-pipeline"]
}这个设计的关键在于可移植性。同一个 Agent 可以出现在不同的任务团队中，它的身份和绩效记录是随 Agent 走的，不是某个框架内部的状态。这就像一个员工可以参与不同项目，但他的能力和绩效记录是公司级别的。
为什么这很重要？因为在固定团队模式下，你每次组建新团队，Agent 的历史信息都丢失了。你不知道上次让这个 Agent 写 Python 代码时它表现如何，下次还得重新试探。有了可移植身份，系统可以直接根据历史表现做决策。
机制二：动态团队组装（Dynamic Team Assembly）
这是 OMC 与现有框架最大的区别。
在 CrewAI 中，你预先定义团队：
# CrewAI 模式：静态团队
crew = Crew(
agents=[researcher, writer, reviewer], # 固定三人
tasks=[research_task, writing_task, review_task],
process=Process.sequential
)任务来了，永远是这三个 Agent 按固定顺序执行。即使今天的任务根本不需要 review，reviewer 也会被调用一次。
OMC 的模式完全不同：
# OMC 模式：动态组装
class TeamAssembler:
def assemble_team(self, task: Task, agent_pool: List[AgentIdentity]) -> Team:
# 1. CEO Agent 拆解任务
subtasks = self.ceo.decompose(task)
team = Team()
for subtask in subtasks:
# 2. 根据子任务需求，从 Agent Pool 中匹配最佳人选
candidates = self.match_agents(
required_skills=subtask.required_skills,
agent_pool=agent_pool,
performance_threshold=0.6 # 最低绩效门槛
)
# 3. 按综合评分排序（能力匹配度 × 绩效评分）
ranked = sorted(
candidates,
key=lambda a: (
0.4 * self.skill_match_score(a, subtask)
+ 0.4 * a.performance.eloRating / 2400 # 归一化
+ 0.2 * self.availability_score(a)
),
reverse=True
)
# 4. 选择 Top-N 组成子团队
team.assign(subtask, ranked[:subtask.required_agents])
return team这段代码体现了三个关键设计决策：
第一，匹配是双向的。 不只是任务选择 Agent，Agent 的能力描述也在”声明”自己适合什么。这避免了一个常见问题：让擅长数据可视化的 Agent 去写后端 API。
第二，绩效是权重的一部分。 两个能力匹配度相同的 Agent，绩效更高的那个优先。这形成了正向循环——做得好的 Agent 获得更多机会，做得更多又积累了更多经验。
第三，有淘汰门槛。 performance_threshold=0.6 意味着历史成功率低于 60% 的 Agent 不会被考虑。这防止了”僵尸 Agent”占用资源。
机制三：层级决策（Hierarchical Decision-Making）
OMC 采用三层架构，映射到企业管理中的 CEO → Manager → Worker 层级：
┌────────────────────────────────────────────────┐
│ CEO Agent │
│ 职责：理解高层目标，拆解为可执行的子任务 │
│ 输入："分析竞品并生成市场报告" │
│ 输出：[数据采集, 市场分析, 报告撰写, 质量审查] │
├────────────────────────────────────────────────┤
│ Manager Agent（每个子任务一个） │
│ 职责：为子任务选择 Agent、制定执行计划、监控进度 │
│ 输入：子任务描述 + 可用 Agent 池 │
│ 输出：选中的 Agent 列表 + 详细执行指令 │
├────────────────────────────────────────────────┤
│ Worker Agent（每组 1~3 个） │
│ 职责：执行具体任务，输出结果 │
│ 输入：详细指令 + 工具权限 │
│ 输出：任务结果 + 自评信心分数 │
└────────────────────────────────────────────────┘层级决策的优势是关注点分离。CEO 不需要知道哪个 Agent 适合做什么，它只需要把任务拆解清楚。Manager 不需要理解高层战略，它只需要为具体子任务找到最匹配的人。Worker 不需要理解整体目标，它只需要把手头的活干好。
但这个架构也有代价。论文的消融实验（ablation study）显示，对于简单任务（如”翻译这段话”），三层决策引入的额外 LLM 调用使延迟增加了 2-4 秒，而任务质量没有显著提升。OMC 的论文作者自己也承认，对于低复杂度任务，简单的直接调用可能更优。
机制四：绩效评估（Performance Evaluation）
这是 OMC 最有争议也最有价值的部分。
每个任务完成后，系统自动为参与的 Agent 评分。评分维度包括：
| 维度 | 权重 | 评估方式 |
|---|---|---|
| 任务完成率 | 35% | 是否成功输出了符合要求的结果 |
| 输出质量 | 30% | 由评审 Agent 或人工打分（0-10） |
| 响应效率 | 20% | 从接收任务到完成的时间 |
| 协作配合 | 15% | 下游 Agent 对其输出的满意度 |
评分结果通过一个 ELO-like 算法更新 Agent 的等级分。这个设计借鉴了国际象棋的评分系统——与强 Agent 协作完成任务，比与弱 Agent 协作获得更多加分。
绩效评估的价值在于它形成了一个自适应系统。随着任务的积累，系统越来越了解每个 Agent 的擅长领域和能力边界。新任务到来时，团队组装的准确性会持续提升。
但它也引入了一个风险：绩效固化。如果一个 Agent 因为早期任务难度过高而积累了低评分，它可能永远得不到”翻身”的机会。论文提到了一个”探索系数”（exploration coefficient）来缓解这个问题——大约 10% 的任务会随机选择 Agent，不管绩效如何。这与 Multi-Armed Bandit 问题中的 Exploration-Exploration 平衡是同一个思路。
与主流框架对比
| 特性 | OneManCompany | AutoGen | CrewAI | LangGraph |
|---|---|---|---|---|
| 团队拓扑 | 动态组装 | 固定群聊 | 固定 Crew | 图结构（手动定义） |
| Agent 身份 | 可移植结构化身份 | system prompt | role + goal + backstory | 节点配置 |
| 绩效系统 | ELO 评分 + 历史追踪 | 无 | 无 | 无 |
| 决策层级 | CEO → Manager → Worker | 对话式（GroupChat Manager） | 扁平（Process.sequential/hierarchical） | 用户自定义 |
| 任务匹配 | 基于能力 + 绩效的自动匹配 | 手动路由 | 手动分配 | 手动编排 |
| 适用 Agent 规模 | 10-100 | 2-10 | 2-10 | 2-20 |
| 学习能力 | 有（绩效反馈循环） | 无 | 无 | 无 |
| 开源状态 | 论文 + 代码（研究阶段） | 成熟开源 | 成熟开源 | 成熟开源 |
核心差异一句话总结：AutoGen/CrewAI/LangGraph 是”项目管理工具”——你手动组建团队、分配任务；OMC 是”人力资源管理系统”——系统自动招聘、分配、评估。
工程实现要点
论文目前是研究阶段，但 OMC 的理念完全可以在现有系统中部分引入。以下是我认为最值得借鉴的三个实践：
实践一：给 Agent 加上”简历”
不需要完整的 OMC 框架，只需要在现有 Agent 定义中加入一个持久化的身份文件：
import json
from pathlib import Path
class AgentProfile:
def __init__(self, agent_id: str, profile_dir: str = "./agent_profiles"):
self.path = Path(profile_dir) / f"{agent_id}.json"
self.data = self._load_or_create()
def _load_or_create(self) -> dict:
if self.path.exists():
return json.loads(self.path.read_text())
return {
"id": self.path.stem,
"performance": {
"tasks_completed": 0,
"success_count": 0,
"quality_scores": [],
}
}
def record_task(self, success: bool, quality_score: float):
perf = self.data["performance"]
perf["tasks_completed"] += 1
if success:
perf["success_count"] += 1
perf["quality_scores"].append(quality_score)
# 只保留最近 50 次记录
perf["quality_scores"] = perf["quality_scores"][-50:]
self._save()
@property
def success_rate(self) -> float:
perf = self.data["performance"]
if perf["tasks_completed"] == 0:
return 0.5 # 新 Agent 默认中性评分
return perf["success_count"] / perf["tasks_completed"]
@property
def avg_quality(self) -> float:
scores = self.data["performance"]["quality_scores"]
return sum(scores) / len(scores) if scores else 0.5
def _save(self):
self.path.write_text(json.dumps(self.data, indent=2))有了这个，你就可以在任务路由时加入绩效权重，而不是只看静态的能力描述。
实践二：用 LLM 做任务路由
OMC 的 Manager Agent 本质上就是一个智能路由器。在现有系统中，你可以用一个轻量级的路由 Agent 来替代手动的任务分配：
ROUTER_PROMPT = """你是一个任务路由器。根据任务描述，从候选 Agent 列表中选择最合适的一个。
候选 Agent：
{agents_description}
任务：{task_description}
输出格式：返回 Agent 的 ID 和选择理由的 JSON。
"""
def route_task(task: str, agents: list[AgentProfile]) -> AgentProfile:
agents_desc = "\n".join([
f"- {a.data['id']}: 能力={a.data.get('capabilities', 'N/A')}, "
f"成功率={a.success_rate:.1%}, 平均质量={a.avg_quality:.2f}"
for a in agents
])
response = llm.call(ROUTER_PROMPT.format(
agents_description=agents_desc,
task_description=task
))
selected_id = parse_json(response)["agent_id"]
return next(a for a in agents if a.data["id"] == selected_id)这个路由 Agent 每次消耗约 200-500 tokens，延迟在 0.5-1 秒，远低于 OMC 完整三层架构的开销。但已经能实现”根据历史表现选择 Agent”的核心功能。
实践三：引入后任务评审
绩效评估是 OMC 的灵魂，但你不需要复杂的 ELO 系统。一个简单的双 Agent 评审循环就够了：
async def evaluate_task_output(
task: str,
output: str,
evaluator_agent: Agent
) -> dict:
"""用一个独立的评审 Agent 评估任务输出质量"""
eval_prompt = f"""评估以下任务的完成质量（0-10 分）。
任务描述：{task}
任务输出：{output}
评分标准：
- 正确性（40%）：输出是否准确、无事实错误
- 完整性（30%）：是否覆盖了任务的所有要求
- 清晰度（20%）：表达是否清楚、结构是否合理
- 效率（10%）：是否有冗余内容
返回 JSON: {{"score": <0-10>, "reason": "<简要说明>"}}"""
result = await evaluator_agent.run(eval_prompt)
parsed = parse_json(result)
return {
"quality_score": parsed["score"] / 10.0, # 归一化到 0-1
"reason": parsed["reason"]
}评审 Agent 建议使用与被评审 Agent 不同的模型——比如 Worker 用 Claude，评审用 GPT-4，避免同源偏见。
适用场景与边界
OMC 不是银弹。论文和我的实践都表明，它有明确的适用边界。
适合 OMC 理念的场景：
- Agent 池规模大于 20 个，且能力各异
- 任务类型多变，不同任务需要不同的 Agent 组合
- 需要持续运行、有反馈循环的系统（如持续运营的 AI 平台）
- 组织中有明确的角色层级和职责边界
不适合的场景：
- 5 个以下 Agent 的简单系统，固定团队更直接
- 一次性任务（batch job），不值得建绩效系统
- 对延迟极度敏感的场景（层级决策引入额外 LLM 调用）
- Agent 能力高度同质化（所有 Agent 都能做所有事），动态组装没有意义
一个实用的判断标准：如果你发现自己频繁修改团队配置来适配不同任务，就该考虑引入 OMC 的动态组装理念。如果你的 Agent 团队几个月都不需要变动，固定团队就够了。
总结
OMC 论文的核心贡献不在于它实现了一个完美的框架，而在于它提出了一个正确的隐喻：Agent 系统的组织问题，本质上和人类组织的管理问题是一样的。
可移植身份 = 员工档案和简历。动态团队组装 = 项目制的人员调配。层级决策 = 公司的管理层级。绩效评估 = KPI 和绩效考核。
企业管理经过几百年的演化才形成今天的体系。Agent 系统的”组织管理”才刚刚起步。OMC 做了一个有意义的尝试，但论文中也有明显的未解决问题：Agent 之间的信任机制怎么设计？绩效评估如何防止作弊（Agent 学会”讨好评审”而非真正完成任务）？动态组装的安全边界在哪里——如果 Agent Pool 中混入了一个恶意 Agent 会怎样？
这些问题的答案，可能需要借鉴更多企业管理之外的学科——博弈论、制度经济学、组织行为学。多 Agent 系统的研究正在从”怎么让单个 Agent 更强”转向”怎么让 Agent 群体更有效”。这是一个值得持续关注的方向。