# 军团的成员、特点、组织方式和实际效果

**军团不是让一堆模型同时回答，而是让不同原生工作台带着同一项目现场，按需要接管、求助或并行，由明确的负责人把原作品做完。**

“有哪些家”和“每家现在都能用”是两件事；“有人参与”和“成果因此变好”也是两件事。下面把名册、设计原因、运行机制与旧案例分别说明，不拿数量替代效果。

## 1. 目前名册里有哪些

本次只读的两份核心登记表共有**38个入口：内置10、外接28**。按它们在Meyo中的角色，分为**执行角色28、工具/能力7、控制平台2、桌面平台1**。这是登记条目，不是独立厂商数，也不是实时在线数。

### 内置执行入口9个

**Claude Code、Codex、Hermes、DeepSeek Harness、DeepAgents、JCode、Penguin、Prime、Omnigent。**

另一个内置条目是**Auto工具库**：工具资产和源码保留，当前执行引擎停用，不进答题、接力或首脑池。历史GAIA研发结果并没有因此被抹掉，但不能把Auto再算成当前多出来的一位答题者。

### 外接执行角色19个

**CowAgent、DeerFlow、Cline、Goose、OpenClaw、pi Coding Agent、nanobot、GenericAgent、OmniAgent、Kimi Code CLI、IronClaw、Qwen Code CLI、Aider、OpenCode、GNHF、Headlong llm、OpenHands、Prime Agent、Penguin Harness。**

这些有各自的CLI、SDK或其他接入声明。是否已安装、依赖与授权是否满足、原生工具能否工作，仍需实际运行证据；不能由role=agent直接宣布可用。

### 工具、能力与平台层

- **工具/能力：**Auto、Browser Use、macOS Harness、Harness Anything、HASS.Agent、LoopX、MobileRun。
- **控制平台：**Paperclip、Aeon。
- **桌面平台：**Grok Bot 0.18 Reconstructed。

这是它们在Meyo中的角色，不是评价其原产品只能做什么。比如DeerFlow的kind叫orchestrator，但规范角色仍是执行agent；Grok重建版则是平台层，**不是Grok官方模型或独立答题成员**。

### 不重复算、不擅自算入

- `prime → prime-intellect`是明确的兼容转接，不算两家独立Prime。
- `penguin`与`penguin-harness`同源，入口/配置与运行版本仍要分别核。
- **Omnigent ≠ OmniAgent**，不能因名字相近合并。
- **Orca**本地有生态IDE源码，但当前两个名册没有登记；目录身份也不自动等于所有叫Orcha的项目。
- **Multica**当前未登记，限定核查尚未找到精确本地源码指针；不是断言全机不存在，也不把它充作已经接入。
- Omnigent的嵌套子后端也不能再与主名册简单相加，凑成更多“已验成员”。

两工作树的key和角色集合一致，但配置指纹不同。页面的接入列是声明，不是当前生产状态；完整38条安全名册和源文件指纹可展开或下载，不含env、凭据和安装令牌。

## 2. 为什么保留不同特点，而不是统一成一种Agent

**家是工作台，模型是它使用的“大脑”。**同一Astra可以被不同Harness使用，区别还在原生工具、文件工作方式、会话、插件、上下文处理与恢复协议。

|入口|保留的可靠特征|对用户可能有什么价值|
|---|---|---|
|Claude Code|CLI事件与原生session resume|延续自己的工作方式与会话，工具进度可回流|
|Codex|原生thread/exec resume与持久工程|接着已有项目做，不只靠短摘要重建|
|Hermes|自己的AIAgent会话、history与工具回调|真正由自己的工具执行，不是挂名后让另一家代答|
|DeepSeek Harness|持久事件session的inspect、resume/create与followup|保留事件化工具循环与恢复入口|
|DeepAgents|当前worker有图thread、todos及SQLite checkpoint|继续未完图节点，而不只是重发消息|
|JCode|run JSON/resume及原生持久状态|保留长任务与工程状态|
|Penguin|首轮run、续作chat resume|沿用原会话的模型和工作目录|
|Prime|兼容入口接Prime原会话格式|旧入口可用，坏checkpoint不伪造恢复|
|Omnigent|会话绑定、子Harness插件与执行入口|在需要时借到其他工作台，而不是全部重写|

这些是有源码位置可查的机制特点，**不是固定职业分工或实力排名**。同一家可能写代码、研究、检查或集成，角色应随任务变化。

也不能说所有原生能力都已完整保留：当前CC的`--bare`会跳过部分扩展；旧DeepAgents manifest仍写`cold_replay`，当前worker却已有`create_deep_agent`与`SqliteSaver`；JCode在两树的声明也不同。源码、声明、安装版本、实际执行不能混成一个“已完成”。

旧profile里的高低、快慢和绝对化标签不作为本页性能事实。没有同题、同模型/预算和真实交付比较，就不声称哪家永远更强。

## 3. 我们为什么需要这些组织特征

1. **保留原生工作方式：**不把各家削成同一个聊天接口，才有机会复用它们的原生长处。
2. **共享同一项目现场：**接手者知道目标、文件、版本、来源和失败，减少搬运与重做；不是共享所有人的私聊。
3. **让原作者真正消费帮助：**同伴回复不是成品，必须回到原任务，发生实际修改或明确取舍。
4. **并行有独立写面和收口者：**共同基线、分离副本、固定差异，再由原负责人集成，避免互相覆盖。
5. **保留失败与全部开销：**知道用了谁、错在哪、是否重做，才能判断有无净收益。

这些机制最终都要服务同一个结果：**用户少管理，作品更好，或者同质量下全成本更低。**不是为了让一个任务看起来有很多角色。

## 4. 谁规划、谁组织、谁把作品做完

可以理解为五种职责，但不是每个请求都强制走五道工序：

|职责|当前怎样衔接|不能误解成什么|
|---|---|---|
|计划提出|模型读取目标、附件、候选与能力状态，返回任务与关系|并非平台已知道唯一最佳答案|
|负责人选择|用户指定、候选条件、静态偏好、历史信号和提案评分共同作用|不是每次38家全体开会，也不是全自主全生态最优|
|运行执行|调度器管理依赖、绑定、租约、取消、工作目录和状态|调度成功不等于作品完成|
|原生工作|负责人使用自己的工具做事，遇到具体缺口提出帮助或交接|不固定哪一品牌只能做某职业|
|最终收口|原作者核同伴结果、读差异、修改原文件并交付，用户决定采用|不是平台投票后把几段答案拼起来|

当前选负责人还有明确代码规则：候选先排序，默认竞选范围有限，再按`_bid_strength`经`max`选取；分数涉及提案结构、任务/方向/图数量及历史信号。**不能照抄旧注释说“首个完整提案一定当选”，也不能把规则评分当成已经证明选到最强执行者。**

当前也仍有平台侧模型规划和评分逻辑，不能宣传成所有质量决策已经完全下放到原生Harness。图解表达的是职责与可能的连接，实际入口和任务会跳过或调整其中步骤。

### 几种配合方式，不是一回事

- **单家直接做：**完整原生能力足够时，不为了军团而拆队。
- **`need_peer`请教：**提出具体问题，同伴返回原始观察，原负责人真正续作；平台失败回执也要如实带回。
- **`handoff`交接：**换负责人并带上同一工程与现场，不保证任意两家的原生会话历史无损互通。
- **`fork`并行：**共同基线、独立工作副本、收回固定结果与差异，最后由原生父成员集成。两个分支不等于两份成功贡献。
- **失败接力：**某个运行路径失败后补位，同时保留原失败和费用，不能用后来成功遮住前面的缺口。
- **同题比较：**需要时再比较不同方案；不以一致投票或答案融合替代真实作品。

## 5. 实际工作效果：三条可追查的旧记录

### 例一：原工程从Codex交给Hermes

已有2048工程需要撤销快捷键。Codex/Astra留下原版本，Hermes/Astra用自己的原生工具读取和修改同一项目。旧记录有快捷键、采用/恢复、重启保留等结果。

这是**同Astra、跨Harness冷接项目**，不是继续Codex的原生thread，也不是证明异构模型增益。旧记录用时182.35秒，不能与另一任务直接做速度排名；本轮未重跑。

### 例二：同伴意见被原作者真正采用

Hermes/Astra针对原代码提出只读问题，Codex/Astra给出观察；同一个Hermes原生会话读到完整回复，再进行真实工具操作与修改。

旧差异记录只有一个原JS改变，64个原文件保持。旧验收里五类编辑目标不再误动棋盘，正常移动和撤销保留。这比“同伴回答了”更接近有效协作。

但任务明确要求不同视角并限定两家。399.32秒是该记录的三阶段时间，费用未完整单列；不声称无提示自动选优、所有任务更快或更省。

### 例三：并行确实发生，但并不是两家都成功

原Hermes让Hermes与Codex在同一固定基线的独立写面中处理README和手机布局。旧时间窗有重叠，子Hermes的README被父成员实际集成。

**子Codex未完成布局代码，原负责人补做；子Codex和父运行都曾超时。**后来作品的手机说明、操作区和中文使用文档有改善，但不能宣传“两份成功代码自动合并”或“比最强单家更快”。

三例都是旧工程验收，**同Astra**，没有完整的同条件最强单家对照或长期群体净收益证明。三份旧完整ZIP与部分fork子快照原路径本轮未找回，因此只引用保留的原生提取、文件差异与验收记录，不伪造当次版本的即时试玩或下载地址。已有公开作品可另看本页作品区，但版本证据不能混用。

## 6. 失败和未证明的部分也必须说

- **能力借用未闭环：**上下文/JSON传递修过，子原生启动过，但沙箱返回`Operation not permitted (71)`，指定文件读取未证，原作品没改。outer ok/done不能当工具成功。
- **组队不保证胜过单家：**旧10题自述中组队为**4/4/2**，最强单家为**5/10**。不是当前排名，却不支持“多家天然更强”。
- **预检失败回流不等于作品已完成：**有原Codex自行改选Hermes的旧记录，但当时请求者仍在工作；只证明失败事实与选择回到原作者，不作为第四个作品成功例。
- **在目录不等于可用：**依赖、平台、权限、工具、原目录与会话都要成立；工具能力和控制平台不应混进答题池。
- **有记忆不等于群体进化：**要看下一次实际采用与效果，不拿注入次数或源代码被读过一次代替长期增强。

下一步应跟住一条已获准的真实任务，记录实际成员和模型、计划变更、工具、原文件变化、失败与全部成本。只在结果、可靠性或管理负担出现净改善时，才把方法继续推广。不能为了凑名单或给报告提分新跑一轮。

本次只更新分享网页：未安装成员、逐家探活、调用业务模型、重跑基准、操作浏览器、修改生产配置或部署服务。名册、源码、旧运行与当前线上状态分别说明。