evo — 代码库自动研究编排器
将代码库转变为自动研究循环：自动发现优化指标、搭建基准测试，并通过并行子代理执行树搜索。
证据显示：README 提到遥测（可关闭）、代码审查钩子信任（--no-trust-hooks）、门控机制（gates）可防止意外更改。但未提供权限最小化的详细说明，用户确认机制仅提及可暂停，数据流透明性仅部分描述，敏感数据处理未明确，依赖安全未列出具体依赖版本或漏洞扫描，外部影响（如远程沙箱）未充分说明，回滚机制仅提及 git worktree 和 revert，来源归属仅通过 README 和 LICENSE 声明。扣分原因：缺乏具体实现细节和证据。
证据显示：CI 工作流包含单元测试、SDK 测试、构建和发布流程，测试覆盖了 SDK 的基本功能，但未提供完整的测试结果或覆盖率。依赖可用性方面，列出了多个后端（Modal、E2B 等），但未验证其可用性。失败消息方面，测试中有错误处理，但未提供用户可见的失败消息示例。扣分原因：测试未执行，依赖可用性未验证，失败消息未充分展示。
证据显示：README 描述了多种使用场景（不同宿主、远程后端），能力边界通过 gates 和策略说明，触发精度通过命令和自然语言示例说明，环境适配通过支持多种操作系统和 Python 版本。但未提供详细的配置选项或限制说明。扣分原因：部分描述较简略，缺乏具体配置示例。
证据显示：README 结构清晰，包含安装、使用、升级、遥测等章节，安装说明详细，命名稳定（evo 命令），示例和 FAQ 部分有示例但无 FAQ，已知限制未明确列出，许可证为 Apache-2.0，版本控制通过 CI 和发布流程体现，维护责任未明确。扣分原因：缺少已知限制和明确的维护责任声明。
证据显示：输出可用性通过 SDK 和 CLI 提供，边际价值通过树搜索和并行子代理体现，成本效益未提供具体数据。扣分原因：成本效益缺乏量化证据。
证据显示：README 中的声明部分有测试和 CI 支持，但未提供独立的验证来源，事实与推断未明确区分。扣分原因：缺乏交叉验证和明确的区分。
- 该仓库的发布者身份未经验证，应视为未知，不要基于品牌信任。
- 静态审查无法验证实际运行行为，所有关于功能、安全性和可靠性的结论都基于源代码和文档，置信度低。
- 远程沙箱后端（如 Modal、E2B）涉及外部代码执行，需仔细审查其权限和数据流。
- 遥测功能默认开启，虽然可以关闭，但用户应了解其数据收集范围。
这个 Agent 能做什么，适合哪些场景？
evo 是一个开源（Apache-2.0）的自动研究编排器，它接受任意代码库，自动发现要优化的指标，并设置评估基准，然后循环运行实验以改进代码。它扩展了 Karpathy 的自动研究概念，引入了树搜索、并行半自主子代理、共享状态、门控和可观测性。它是为 Claude Code、Codex、Cursor、Kimi、OpenClaw、Hermes、Opencode 和 Pi 等代理框架设计的插件，实验可在本地 git worktree 或通过远程后端（如 Modal、E2B、Daytona、AWS、Azure）运行。evo 提供仪表盘以监控实验，并可通过 `evo` CLI 安装和更新。项目在 evo-hq/evo 仓库中，并附有 DOI 和引用信息。
evo 通过两个主要命令操作：/evo:discover 和 /evo:optimize。discover 通过提示或命令行种子输入来确定优化目标、基准命令和指标方向。它创建 gates 以防止意外变更，并启动仪表盘。optimize 运行循环：编排器启动并行子代理，每个在一个单独的工作区（git worktree）中运行，它们读取共享状态（故障 traces、注释、废弃假设），形成假设，编辑代码，运行基准测试，并根据分数保留或丢弃更改。编排器在每轮后选择要扩展哪些分支，使用诸如 argmax、top_k、epsilon_greedy、softmax 或 pareto_per_task 等策略。交叉扫描子代理基于 RLM 分析 traces 并识别复合故障模式。Gates 作为通过/失败检查，即使实验分数超过当前最佳，如果失败也会丢弃实验。仪表盘提供配置和监控。
- 希望在提交前自动优化代码库性能而不手动管理实验的开发者。
- 希望探索多个优化方向而不在单个贪心路径上收敛的团队。
- 希望将代码优化与回归测试和安全检查集成的研究人员，而不会破坏现有功能。
- 需要监控正在进行的优化实验并调整策略参数（如 argmax 或 softmax）的工程经理。
- 希望使用远程云资源（如 Modal 或 AWS）并行运行实验，而无需本地 GPU 的用户。
- 希望对已经存在基准测试的代码库进行优化，以了解哪些更改能真正提升性能。
这个 Agent 有哪些优点和局限？
- 自动发现基准测试并创建 gates 以防止正确性回归，提高实验安全性。
- 通过并行子代理和树搜索，比贪心爬坡探索更多方向。
- 支持多个主机（Claude Code、Codex、Cursor 等）和远程后端（Modal、E2B、AWS、Azure），提供灵活性。
- 提供仪表盘以实时监控实验和配置策略。
- 安装需要 uv 和主机 CLI，可能需要网络访问以获取包。
- 远程后端需要额外的云凭据和设置，增加采用成本。
- 实验可能资源密集，具体取决于基准测试，需要适当的计算资源。
- 依赖特定的代理框架钩子；不同主机的语法差异可能要求用户适应。
如何安装或部署这个 Agent？
- 安装 evo CLI：
uv tool install evo-hq-cli。2. 安装主机 CLI（如果需要）：例如，npm install -g @anthropic-ai/claude-code用于 Claude Code，或npm install -g @openai/codex用于 Codex。3. 安装插件和主机钩子：evo install <host>，其中 <host> 可以是 claude-code、codex、cursor、hermes、kimi、opencode、openclaw 或 pi。4. 对于远程后端，使用额外的包安装，如uv tool install 'evo-hq-cli[modal]'。
如何使用这个 Agent？
初始化后，在代码库中运行 /evo:discover（或在某些主机上使用等效语法）来发现基准。你可以通过种子输入指定目标，例如 /evo:discover make the JSON parser at src/parser.py faster。然后通过 /evo:optimize 运行优化循环。仪表盘会自动启动并打印 URL（通常为 http://127.0.0.1:8080）。你可以手动启动仪表盘：uv run --project /path/to/evo/plugins/evo evo dashboard --port 8080。使用 evo update 更新。
这个 Agent 与同类方案有什么区别？
evo 扩展了 Karpathy 的 autoresearch 思想，后者是一种简单的贪心爬坡。evo 添加了树搜索、并行子代理、共享状态和门控。它还受 GEPA 和 RLM 论文的启发，分别用于 Pareto 策略和交叉扫描。
常见问题
evo 是否支持使用我的现有基准测试？
discover 可以检测到它，gates 是可选的。如果没有，discover 会帮助创建基准测试并自动附加一个包含验证集的分数下限 gate。我可以限制实验并行度吗？
evo 收集哪些遥测数据？
evo telemetry off 全局关闭，或使用 EVO_TELEMETRY=0 为单个命令关闭。