EvoPM

我们的作品 EvoPM，是一个让 AI 团队组织结构也能像技能一样被生成、复用和进化的组织进化引擎。 1. 技术实现思路 我们的技术实现是一个三层结构： 最底层是 Paperclip，它负责真正把一家公司式的 Agent Team 跑起来，包括组织架构、Heartbeat、预算和治理规则这些运行时基础设施、它也可以被切换成任意一个未来的更完善的 Agent Runtime；最上层是 EvoMap，它负责单个 Agent 的能力进化，也就是 Gene、Capsule 和 GEP 协议这一套；而我们做的 EvoPM，放在这两者之间，负责“组织层”的进化——也就是用户来了一个新业务需求之后，系统不只是挑一个强 Agent 去硬做，而是先决定“这件事应该组织成什么样的 AI 公司”。这也是我们和普通 Agent 编排器最本质的区别。 具体来说，EvoPM 的核心流程分三步： 第一步是 意图映射层。用户用自然语言描述业务目标，比如“我想做一个跨境电商独立站”，系统通过多轮对话提取关键维度，比如这是 ToC 还是 ToB、行业是什么、规模多大、是否有合规要求。然后系统不是直接从零生成团队，而是先走 Fetch-First 路径：优先去检索已有的 Team Gene 或 Capsule，找到匹配的组织经验就直接实例化，找不到才从零生成一个新的公司配置。输出的不是一句建议，而是一份完整的 Paperclip 公司配置，里面会包含角色、分工、Heartbeat 频率、预算分配和治理规则。 第二步是 组织架构模板库。为了保证 Demo 和 MVP 可落地，我们会至少预置两类差异非常明显的组织模板：一个是面向消费互联网、强调高频协作和快速迭代的 ToC 增长型“蜂巢式”架构；另一个是面向企业服务、强调审批、审计和稳健交付的 ToB “堡垒式”架构。这样做的意义不是偷懒，而是先让系统具备“从业务特征映射到组织结构”的基础能力，再在这个基础上以 EvoMap 为平台做进化。 第三步是 组织进化协议。项目执行完成后，EvoPM 会回收这次运行的数据，比如任务完成率、Token 成本、耗时和失败模式，然后把这次有效的组织模式封装成可复用的组织基因，再发布回 EvoMap。下一次有类似业务场景时，系统就可以优先继承这些组织经验，而不是再次让执行官从头拆解和招人。整个闭环的目标，就是把“组队方式”本身变成一种可积累、可继承、可优化的知识资产。 2. Agent 进化路径 我们的进化路径，不是先让某一个 Agent 变得更聪明，而是让一整个团队的组织方式越来越适配任务。这点非常关键。EvoMap 解决的是“个体能力层”的进化，而 EvoPM 解决的是“组织协作层”的进化。 具体路径可以概括成四步： 第一步，创建组织。 用户给出业务需求后，EvoPM 通过意图映射层生成一个初始团队，或者继承一个历史上表现不错的组织模板。这个阶段的产物，是一家公司级别的团队结构，而不是单个 Agent 的 prompt。 第二步，执行任务。 这家公司在 Paperclip 运行时里实际执行任务。也就是说，评委或用户看到的不是“纸面上的组织图”，而是一个真的会协作、会分工、会审批、会推进工作的 Agent Team。 第三步，提炼经验。 任务结束后，系统会分析这套组织结构的表现：哪些角色冗余，哪些审批过重，哪些协作链路高效，整体的完成率、Token 成本和耗时表现如何。这个阶段不再把结果当成一次性的日志，而是提炼成组织经验。 第四步，沉淀并继承。 有效的组织模式会被封装成 OrgGene / OrgCapsule 并发布到 EvoMap。以后同类任务进来时，系统优先复用这些组织基因，于是团队会从“第一次靠推理硬组织”逐渐进化为“后续靠经验快速组队”。这就是我们所说的 组织智慧积累。 这里还有一个很重要的设计原则，叫 三层归因边界：我们只让 OrgGene 捕获“拓扑与协议层”的知识，不把单个 Agent 太弱、工具不好用这类问题混到组织进化里。这样做是为了保证进化信号干净，不至于把本来是能力问题误判成结构问题。 3. 业务价值说明 EvoPM 的业务价值，核心在于它解决了现在 Agent Runtime 里两个非常现实的结构性问题： 第一个叫 冷启动偏差。一个执行官 Agent 从零开始组建团队时，要自己分析任务、拆角色、招 Agent、配协作方式，这个过程非常耗 Token，也非常慢。第二个叫 路径依赖偏差。如果它已经有一个旧团队，它就会倾向于在旧团队上做最小修改，因为这样最省事，但“最省事”不等于“最优”。结果就是，系统永远在沿用旧结构的小修小补，而不是针对新任务形成最合适的新组织。EvoPM 的价值，就是把这件事从即时推理中剥离出来，变成可复用的组织资产。 从产品价值上看，它至少有三层意义： 第一层，是降本增效。 通过复用历史上验证过的组织模式，新的任务不需要从零试错，Token 成本会下降，启动速度会更快，团队结构也会更合理。项目文档里甚至明确把“v1 无经验”和“v2 进化后”的效率对比作为核心展示内容。 第二层，是可迁移的组织经验。 普通 Agent 项目做完就结束了，而 EvoPM 会把成功的团队组织方式沉淀下来，让一个项目中的组织智慧，可以迁移到下一个类似场景里。这意味着它不只是一个运行器，而是一个会积累“怎么组队”经验的系统。 第三层，是生态价值。 我们不是单纯消费 EvoMap 和 Paperclip，而是在现有生态里补上了一个原本缺失的层次：过去 EvoMap 上主要是单 Agent 的能力 Gene，EvoPM 试图新增一种新的资产类型——组织结构 Gene。这意味着 EvoMap 生态里未来不只能共享技能，还能共享团队形态。 如果要对评委讲得更落地一点，可以这样说： 今天很多人已经在研究“AI 能不能把事做成”，而我们研究的是“AI 团队怎样组织起来，才能更稳定、更低成本地把事做成”。 这就是 EvoPM 的业务价值。 4. 使用 GEP 协议与 Gene Recipes 的具体方式 这一部分是我们和 EvoMap 结合得最深的地方。 我们的思路不是直接把一个 Agent 技能包发布成 Gene，而是把组织架构本身编码成一种新的 GEP 资产类型。也就是说，Gene 不再只描述“某个 Agent 会什么”，而是开始描述“在什么任务条件下，应该采用什么团队拓扑、角色分工和协作协议”。文档里把这类资产命名为 OrgGene / OrgCapsule。 其中： OrgGene 是抽象层，是可复用的组织模式模板，比如“research → planner → executor swarm → reviewer”这种结构化协作范式。 OrgCapsule 是经验层，它带有具体任务上下文、执行记录、变异过程和效果评分，也就是“这套组织方式在什么场景下试过，结果怎么样”。 为了让这种组织资产真正像 Gene/Capsule，而不是一张静态组织图，我们给它定义了五个核心字段： 拓扑：团队的结构形态和汇报关系 角色语义：每个角色的职责、输入输出、决策边界、升级路径 能力约束：角色需要什么工具、允许多少成本、能接受多大时延 协作协议：委派怎么做、审批怎么走、并行探索怎么安排、冲突怎么升级 适用条件与绩效：适用于什么任务分布、成功率如何、Token 成本多少、周期多长、常见失败模式是什么。 至于 Gene Recipe 的具体使用方式，按你们现在这套方案，可以这样讲： 我们先把预置的组织模板，比如 ToC 的蜂巢式架构、ToB 的堡垒式架构，整理成符合上述五字段的数据结构； 然后把这些结构模板封装成 Gene Recipe，发布到 EvoMap； 当新用户提出需求时，EvoPM 先通过 Fetch-First 检索这些 Recipe 对应的 Gene/Capsule； 如果命中，就直接实例化成一家公司配置并部署到 Paperclip； 如果没命中，就从零生成新结构，执行后再把验证过的新组织模式回写成新的 OrgGene / OrgCapsule。 所以你们这里的 GEP 使用方式，不是“拿 EvoMap 当一个展示用接口”，而是把 EvoMap 真的当成了组织知识的进化仓库。Gene Recipe 是“如何生成这种组织基因”的配方，OrgGene 是“可复用的组织模板”，OrgCapsule 是“带验证记录的实战经验”，三者组成闭环。 [ 队伍介绍 ] 我们是大厂背景的创业团队 [ 队伍成员介绍 ] 我们的队伍中有来自阿里淘宝闪购团队的产品开发、快手可灵团队的算法工程师、以及来自合肥工业大学软件工程的一位大二学生，队长目前任职产品经理。大家都经常做vibe coding，甚至部分成员属于AI Native开发者。