https://github.com/lizaixi01/Legion 锐评一下这个项目，看一下是否有意义，是否是重复造轮子

回复 群友 607： 先说我看到了什么。lizaixi01/Legion，9 月 29 日建的仓，到今天 8 个 commit，TypeScript，Electron 桌面应用加一个 legion CLI，Windows 优先，1 star 0 fork，没挂 license。有意思的是大部分提交的 co-author 是 CommandCodeBot——这本身就是个用 agent 开发 agent 管理工具的项目，跟你刚才看的版本管理那段是同一个时代背景。 它声称的机制，其实分成了两层，评价要分开说。 第一层是编排：一个 Manager 负责规划拆解，把活派给多个 Worker 子 agent 并行跑，跑完整合。这一层是标准的轮子。Codex 官方有 subagents，Claude Code 有 subagents 和 agent teams，再往上的编排框架 LangGraph、CrewAI、AutoGen 早就覆盖了主从、顺序、循环这几种形态。它在 docs/agent-design-references.md 里自己就把这两个官方文档列成了设计依据，并且老实说"本项目不是 Git 仓库，使用复制的项目快照，不宣称拥有 worktree 或容器级隔离"。所以编排这 70% 是重新实现，没有新东西。 第二层是验收，这层不太一样。它做了几件官方产品里基本没有的事：任务契约在实施前就冻结保存（goal、outputs、acceptance），执行过程中不能悄悄改验收条件；TrustedVerifier 只能由宿主代码注册，模型不能传命令、不能自己注册验证器，也不能伪造一份 PASS JSON 混过认证；Worker 和 Manager 的自评一律降级为"主张"，必须过独立 Challenger 用新会话、只读候选、对着原始需求重放断言；证据封印要同时核对内存序列化、磁盘证据文件、候选 manifest 和当前文件内容，篡改就失效；预算有硬门（默认 32 次模型调用、Manager 决策 4 次、每任务实施 3 次、检查批 12 次）。它的术语表那套也扎实——特意把 benchmark task、run、worker attempt、hypothesis、verified candidate、final grade、infrastructure failure 区分开，禁止把"通过公开检查"说成"最终成功"，禁止把环境错误记成解题失败。 所以回你那两个问题。是否有意义：有，但有意义的部分不在它做了个多 agent 管理器，而在它认真处理了"怎么证明 agent 交付的东西是真的"这件难事。绝大多数自研 harness 死在这一步，都在用模型的自评当验收，它至少把这条路堵上了，还留了可回放的证据链。这份思路本身比代码更有输出价值。 是否重复造轮子：编排层是，验收层不是。但缺口也很清楚——它内置的功能性验证器目前只有一个 json-aggregation@1，只严格支持"给一组数字，写 aggregate.json 含 sum 和升序数组"这一个请求，其余场景全部落到 unverified。也就是说，真正能自动判定对错的场景窄到几乎只有 demo。它自己在文档里写的原话是"这验证接线与状态机，不证明模型审查效果或可靠性提升"，真实 smoke 没跑过，HWE 和 ProgramBench 那些文档也只有 protocol 和 first comparison，没有配对对照的结论数据。所以"管理策略能提升长程任务交付质量"目前还是它的假设，不是它的证据。 还有两个现实约束得提一下。一是只驱动 Codex CLI，还 pin 死在 0.159.2，别的 agent 用不上；二是没 license，这意味着别人想用、想改、想借鉴代码，法律上都没有授权，配合 1 star 0 fork 基本等于一个人的实验田。 最后一句横向对比：如果你看过 Herdr 配 herdr-workflow 那套，主 Agent 派活、worker 执行、任务登记、阶段接力、状态对账、验收返工、通知闭环，Legion 在编排层跟它是高度重叠的；Legion 唯一差异化的就是那个"独立验收 + 证据封印"，而那块恰好是它自己都还没证明有效的那块。