一个扎心问题：Agent强了，项目却还乱
我读完这篇 OMC 论文，最大的反应不是“又一个多 Agent 框架来了”，而是：我们可能把问题看小了。过去一年，大家习惯往单个 Agent 身上塞技能、工具、插件、工作流，仿佛只要工具箱够大，它就能独自干完整个项目。可真实项目不是刷题，里面有分工、依赖、返工、验收，还有一堆没人愿意负责的灰色地带。
论文《From Skills to Talent》做了一件很有戏剧感的事：把多 Agent 系统直接组织成一家公司。这个系统叫 OneManCompany，简称 OMC。里面有 CEO、EA、HR、COO，有人才市场，有任务树，有项目复盘，还有员工绩效和离职机制。听起来像玩梗，但我觉得它击中了多 Agent 最尴尬的地方：Agent 不一定缺技能，它缺同事、经理和验收制度。
我更愿意把 OMC 看成一次“组织层”的补课。很多多 Agent demo 看起来热闹，本质是几个角色在聊天，最后谁对结果负责并不清楚。OMC 的判断更硬：如果一个 Agent 产物没被上级接受，它就不能往下游传；如果团队缺能力，就去招聘；如果员工连续表现差，就进入改进计划，甚至下线重招。这比“让 Agent 互相讨论一下”更接近项目交付。
这里有一个很现实的钩子：当任务变成“做一个可运行产品”而不是“回答一个问题”，Agent 的短板会瞬间暴露。谁来决定任务拆多细？谁来发现缺一个设计师？谁来判断一个子模块够不够好？谁来把失败经验写进下次项目？OMC 的答案不是再塞一个超长提示词，而是把这些动作变成组织制度。
从技能到人才，复用单位变大了
这篇论文最关键的词不是 Agent，而是 Talent。Skill 更像工具函数，帮单个 Agent 多做一件事；Talent 则是一个完整员工身份包，里面有角色、提示词、工具、技能、工作原则和资源。换句话说，过去你下载的是扳手，现在你招聘的是会用扳手、知道职责、能被考核的人。
这个变化很重要。技能市场解决“我能调用什么”，人才市场解决“我该找谁来负责”。论文里的 Talent Market 不是简单的工具库，而是一个可招聘的 Agent 池。它可以来自社区验证的开源 Agent，也可以来自高质量角色提示词加技能装配，还可以在冷门领域临时从技能市场拼出一个新角色。CEO 会看到候选名单并做选择，系统再完成入职、分配容器、授权工具、加入组织结构。
更工程化的一刀，是 Talent 和 Container 分开。Talent 管“这个员工是谁”，Container 管“它跑在哪里”。同一个 Talent 可以跑在 LangGraph、Claude Code 或脚本执行器里；同一个组织也能混用不同后端的 Agent。我的判断是，这比单纯写一堆角色 prompt 更有基础设施味道，因为它开始处理异构运行时这个脏活。
Container 还要遵守六类组织接口：执行任务、管理队列、发布事件、读写存储、装配上下文、处理生命周期钩子。论文把它类比为操作系统内核，我觉得这个比喻并不夸张。操作系统不关心每块硬件的脾气，组织层也不该关心每个 Agent 后端的怪癖。只要接口稳定，招聘新员工、替换旧员工、插入新运行时，才不会把平台改成一锅粥。
我尤其看重“生命周期钩子”这个设计。它让 Agent 做完任务后不只是吐出文件，还会更新记忆、记录进度、调整工作原则。换成人话说，公司不只关心这次交付有没有过，还关心这个员工下次会不会少犯同样的错。这个方向比单次对话评分更有长期价值。
如果把它放到团队协作软件里看，Talent 甚至有点像“带履历的插件”。它不只是声明自己会写代码或会画图，还带着来源、工具权限、过去表现和可替换关系。这个粒度一旦成立，Agent 市场的竞争点就会从“谁的提示词更漂亮”变成“谁能稳定交付、谁能被安全接入、谁能在组织里合作”。
它不是让Agent聊天，而是逼它走流程
多 Agent 最危险的地方，不是某个 Agent 犯错，而是错误结果被下游当成真相继续加工。OMC 的 E2R 任务树就是冲这个问题来的。Explore 阶段拆任务和派工，Execute 阶段让员工真实产出，Review 阶段由上级接受或拒绝。被拒绝就重新拆、重新派、重新做，而不是在聊天记录里假装问题已经解决。
这套机制里，我最喜欢的是“完成不等于通过”。一个子任务可以显示完成，但只有主管评审接受后，依赖它的下游任务才会解锁。系统还给失败重试、超时、预算、升级处理设置了边界，避免任务无限循环或安静卡死。很多 Agent 项目失败时并不会轰然报错，而是停在某个没人看的中间状态；OMC 至少正面承认了这个工程痛点。
论文里的网页格斗游戏案例很能说明问题。CEO 只给一句需求：做一个画面精致、动作流畅的街机格斗网页游戏。系统招聘了游戏开发 Agent 和美术 Agent。美术先出角色动作素材，开发再集成。人类评测发现问题：生成的精灵图没有正确切分，导致动作帧在游戏里渲染错误。
普通多 Agent 流程可能会让美术“再试一次”。OMC 的处理更像团队复盘：COO 和 EA 讨论后，决定给美术 Agent 增加一个程序化切图技能，把复合精灵图切成正确编号的单帧，再让开发重新集成。我对这个细节印象很深，因为它不是简单重跑，而是在失败后补组织能力。
另一个场景是自动研究综述。CEO 只要求调研具身智能和机器人里的世界模型，产出思维导图和三个可行研究想法。OMC 招聘了研究科学家、论文研究员和 AI 工程师，生成了十七份结构化文档、约七十个节点的思维导图，还产出三个研究方向。论文说整个项目不到一小时，成本十六点二六美元。这个案例当然还不能等同于真正研究员，但作为“从一句话到一组交付物”的演示，已经足够让人警觉：Agent 编排正在从问答工具变成项目机器。
还有一个小案例也很适合理解它的野心：GitHub AI Agent 周趋势报告。CEO 只提交需求并从 HR 给出的候选名单里选人，系统招聘 GPT 系研究员和 Claude 写作者，前者查真实仓库与链接，后者写成报告并发邮件。论文说整个流程不到十分钟，花费约四点四八美元，并人工核验了链接和 star 数。这个场景不炫技，但非常贴近日常知识工作。
成绩很亮，但我更关心成本和边界
实验成绩确实好看。论文在 PRDBench 上测了五十个项目级软件开发任务，要求系统一次读入产品需求文档，不能靠人类多轮反馈修修补补。OMC 拿到百分之八十四点六七的成功率，比表中最强基线高十五点四八个百分点。总成本三百四十五点五九美元，平均每个任务约六点九一美元。
我愿意承认，这个结果说明“组织层”不是纯概念包装。动态任务树、评审门、异构 Agent 招聘，这些设计确实可能提升项目级任务成功率。尤其在软件开发这种依赖关系很重的场景里，让代码、架构、评审分角色推进，比一个 Agent 从头莽到尾更合理。
但我也不想把它吹成“AI 公司已经成了”。成本是第一个现实问题。平均六点九一美元做一个 benchmark 任务，对复杂项目可能划算，对普通单轮需求就太重了。论文也承认基线没有报告成本，所以无法严肃比较性价比。我的判断是，OMC 更适合高价值、长链路、强验收任务，而不是替代日常小助手。
第二个疑问是评估边界。严格量化主要发生在软件开发任务上，内容生成、游戏、有声短剧、研究综述更像案例展示。自我演化、项目复盘、PIP、离职这些设定很抓眼球，但论文还没有用长期消融证明每个机制到底贡献多少。Talent Market 的质量控制、权限治理、恶意 Agent 防范、跨项目信誉，也都还需要更硬的证据。
还有一个我会持续担心的问题：组织越像公司，失败也越可能被包装得像“流程正常”。如果评审者本身判断错了，如果 HR 推荐的人才市场质量参差不齐，如果某个 Agent 学到的是坏习惯，系统可能会把错误沉淀成经验。真正可用的 AI 组织，不只要会复盘，还要能发现复盘本身是否错了。
这也是我不愿意只看成功率的原因。组织系统一旦开始长期运行，治理质量会和模型能力一样重要，甚至更重要。
所以我对 OMC 的态度是：值得盯，而且要认真盯。它给了一个很清晰的信号，Agent 生态可能不会停在“给模型装更多工具”，而会走向“招聘可交付的数字员工”。只是，在真正把它叫作 AI 公司之前，我还想看到更长周期、更低成本、更开放领域的验证。现在最有价值的结论是：多 Agent 的下一步，可能不是更会聊天，而是更会被管理。
关于多Agent组织架构的更多设计思路，欢迎到云栈社区和一群人深入切磋。
发表于 3 小时前
|
查看: 4|
回复: 0
