开源仓库的价值几乎全在「用」上，但「用」这件事仍然靠人：读 README、装依赖、下权重、写胶水代码。 EnvX 分三步把仓库变成能听懂人话、能被别的智能体调用的 agent——读文档生成 TODO 装环境、绑定成仓库智能体、用 A2A 名片互通。 效果是全表最高，但要把「最高」读到小数点后，才能看清它赢在哪、赢多少。
论文把「仓库即工具」往前推了一步：仓库即同事。环境初始化不再只看 requirements.txt，而是让 agent 读 README 和手册，自己列 TODO 去装包、下数据和模型、准备验证数据，出错再回改 TODO。
第二阶段把 meta-agent 与这个环境、以及代码知识图谱绑在一起，得到只能干这一家仓库活的「仓库智能体」；第三阶段给它生成 agent card + skills，走 A2A 协议，让路由器智能体按名片挑人组队。
数字层面：GitTaskBench 18 个仓库、54 个任务，4 个框架 × 3 个骨干模型全矩阵。EnvX 在 Claude 3.7 下 ECR 74.07%、TPR 51.85%，两项都排第一；但相对 OpenHands 的 72.22% / 48.15%，ECR 只领先 1.85 个百分点。真正的差距出现在较弱骨干上（见 06）。
读完这节要知道：EnvX 要自动化的不是「写代码」，而是「把仓库跑起来并调对它」。
要点亮一个 GitHub 项目，真实流程远比「pip install -r requirements.txt」复杂：有的仓库权重要从网盘或 Hugging Face 拉，有的要先跑预处理脚本生成数据，有的对 CUDA 版本挑剔，README 里还可能藏着没进依赖文件的隐式依赖。论文把这一整套称为环境，并明确列成三件东西（§3.2）：
第三项是论文的独到之处：环境装完必须能被验证跑通，才能把「装好了」和「看起来装好了」区分开。
而现有 LLM 方案要么把仓库当知识源（自然语言 → 新代码），要么当修改对象（修 bug、解 issue）。论文 §1 的判断是：这两类都没有把仓库变成「用户可以用自然语言直接交互的 agent」。仓库本身还只是被动资源，不是能接活的实体。
前者考的是代码生成能力；后者考的是环境工程 + 入口理解 + 协议设计。EnvX 的整套方法都在回答后者。
读完这节要知道：三个基线各自强在哪，论文认为它们缺的是什么。
把仓库当静态知识，目标是写出调用它的代码。
缺：仓库里已有的成熟功能被重新实现一遍，可靠性和 token 成本都吃亏。
带沙箱或终端，擅长编辑、调试、修 bug。
缺：论文 §2.2 的原话是它们「treat repositories as targets for modification rather than as interactive partners」——把仓库当修改靶子，而不是交互伙伴。
自动分析结构与依赖，做上下文感知的代码执行。
缺：仍是围绕「执行代码」，没有多仓互联的通信层。
论文对这三条路的共同判断是：单仓可用，但仓库与仓库之间是断开的。A2A 协议（Google 2025）已有标准可借，缺的是「谁来把每个仓库变成符合这个标准的 agent」。EnvX 的三阶段就是在补这一环。
读完这节要知道：每个阶段交出去的东西是什么，以及为什么「按 token 扣分」能算出排名全翻转。
EnvX Agent 读 README / 技术手册，生成结构化 TODO；TODO 管理工具逐条执行（装包、下载数据与权重、生成验证数据），遇到执行错误就回改 TODO。论文称这带来「goal clarity and decomposition」与「monitoring and self-reflection」。
把带通用开发工具（读写文件、执行脚本等）的 meta-agent，与阶段 1 的环境、从代码里抽出的仓库上下文（代码知识图谱 CKG）绑定，得到只服务这一家仓库的仓库智能体。用户给自然语言任务，它调工具、调仓库功能、产出答案与产物。
A2A 生成工具为仓库智能体识别 skills、起服务、生成实现代码与 agent card。拿到卡的路由器智能体就能知道「谁会干什么」，按 task 把多个仓库智能体串成工作流。
为什么值得做这个交互：论文的核心卖点不是「TPR 最高」——51.85% 比 OpenHands 的 48.15% 只高 3.70 个百分点；卖点是同样的分数花了多少 token。Claude 3.7 下 OpenHands 的输入 token 是 EnvX 的 16.89 倍（9501.25k vs 562.56k），输出是 14.95 倍（85033.05 vs 5686.89）。把 token 折成成本后，排名就不是按 TPR 排了。
公式（与 JS 的 score() 逐字一致）：
score = a_tpr × TPR + a_ecr × ECR − λ × Input_tokens(k) / 10
输入 token 单位千，每 10k 扣 λ 分，故除以 10。三项都是加权求和/线性扣分，没有标准差，不涉及 ÷N / ÷(N−1)。分数 toFixed(2)，排序用未截断的精确值。
第 1 组：Claude 3.7，atpr=1、aecr=0.5、λ=0.3（页面默认）
1×12.96 + 0.5×16.67 − 0.3×7.48/10 = 12.96 + 8.335 − 0.2244 = 21.0706 → 21.071×42.59 + 0.5×64.81 − 0.3×552.79/10 = 42.59 + 32.405 − 16.5837 = 58.4113 → 58.411×48.15 + 0.5×72.22 − 0.3×9501.25/10 = 48.15 + 36.11 − 285.0375 = −200.7775 → −200.781×51.85 + 0.5×74.07 − 0.3×562.56/10 = 51.85 + 37.035 − 16.8768 = 72.0082 → 72.01排序：EnvX 72.01 > SWE-Agent 58.41 > Aider 21.07 > OpenHands −200.78。
第 2 组：GPT-4o，atpr=2、aecr=1、λ=0.1
2×1.85 + 1×5.56 − 0.1×10.67/10 = 3.70 + 5.56 − 0.1067 = 9.1533 → 9.152×10.19 + 1×17.58 − 0.1×275.53/10 = 20.38 + 17.58 − 2.7553 = 35.2047 → 35.202×14.82 + 1×21.30 − 0.1×760.53/10 = 29.64 + 21.30 − 7.6053 = 43.3347 → 43.332×33.33 + 1×42.59 − 0.1×811.02/10 = 66.66 + 42.59 − 8.1102 = 101.1398 → 101.14排序：EnvX 101.14 > OpenHands 43.33 > SWE-Agent 35.20 > Aider 9.15。
第 1 组演示了「换把尺子排名会翻」：λ=0.3 时 Claude 3.7 下的 OpenHands 因 9501.25k 输入 token 被扣 285.04 分而垫底。
覆盖：Table 1 的 ECR / TPR / 输入 token 三列，12 行全部逐字转录；分数式按页面自定的线性组合计算。
未覆盖：表里的输出 token 列只用正文引用、不进打分；论文没有给任何综合分或成本公式，这个 score 是简化模拟，不是原文规则；也没有模拟 EnvX 三阶段本身，只是对结果的再解读。TPR 本身在第一次算完时已截断到满足 ECR 前提（见 04）。
读完这节要知道：实验里所有框架共用同一批骨干模型，差异全在「每轮一个 function call、最多 200 步」这套流程上。
论文 §4.2.2 的实现细节只有四句，但每一句都会改变 token 曲线：
骨干模型：论文 §4.2.1 声称三个骨干（GPT-4o、GPT-4.1、Claude 3.7 Sonnet）对本文和基线全部共用；但 Table 1 中 Aider 的第三行实为 Claude 3.5（16.67 / 12.96 / 7.48 / 534.00）——原文两处并列，本页不作调和。所以 Table 1 横向读是「框架差」，纵向读是「模型差」。
论文 §4.1 原文：「TPR: Computed on top of ECR to quantify task-level performance quality.」ECR 只查「输出文件在不在、非空、官方脚本能不能处理」；TPR 再比对内容正确性。所以 TPR ≤ ECR 是定义决定的。
但论文没有给出 TPR 的具体分母。若按字面「54 个任务的通过率」，51.85% × 54 = 28.00 个任务，54 个任务里不可能「通过 28 个」，最接近的整数口径（29/54 = 53.70%）也不是 51.85%；推断（依据：54 × 0.5185 不是整数，且 §4.1 未再说明分母）。若按 GitTaskBench 常见的「先过 ECR 再判内容」两阶段口径、以 54 为分母，51.85% × 54 同样对不上整数任务数。表中的百分比按原样引用，本节不替它换算成任务个数。
另一处值得留意的，是 §4.3 的口径用词：同一句里，Claude 3.7 的「improves upon prior work by 7.6%」没说是相对还是绝对；而 GPT-4.1 明确写「percentage points」；GPT-4o 写「relative improvements」。按 Table 1 反算，7.6% 既不等于 TPR 相对 SWE-Agent 的 21.74%（9.26 / 42.59），也不等于相对 OpenHands 的 7.68%（3.70 / 48.15，一位小数四舍五入为 7.7%）。推断（依据：对这行的 ECR/TPR 与两个基线做加减比反复算，没有组合落在 7.6 附近）。页面不替原文改数，06 里仍按原句引用并标出这一点。
读完这节要知道：图 2 的案例里三个仓库智能体各自负责什么，路由器只做分发与拼接。
图 2 里三张名片长这样（转录自图中文字，略去换行）：
| Agent card | description（原图措辞） | skills |
|---|---|---|
| MediaCrawlerAgent | A multi-platform social media crawler agent supporting platforms like Xiaohongshu, Douyin, Kuaishou, Bilibili, Weibo, Tieba, and Zhihu. | search_posts, fetch_post_details, crawl_creator_homepage |
| PromptOptimizerAgent | Prompt Optimizer Agent provides advanced prompt engineering and optimization skills for AI models, allowing users to optimize user prompts to improve LLM performance. | optimize_user_prompt |
| AnimeGANv3Agent | AnimeGANv3 Agent exposes photo-to-anime style transfer using pretrained ONNX models. | photo_to_anime, video_to_anime |
注意图 2 的 prompt 里写的是「Mixue and the Oriental Pearl Tower」——蜜雪冰城，不是人名。这是该案例里唯一的跨仓库协作示例，论文没有给出它在 54 个任务中的位置。
读完这节要知道：哪一列是真领先、哪一列只是险胜，以及论文正文的两处口径。
Table 1（完整转录，12 行）：GitTaskBench，18 个开源仓库、54 个人工验证任务；ECR / TPR 为百分比（↑），token 单位为千（Input）与个（Output，↓）。加粗行是 EnvX。
| Framework | LLM | ECR (%) ↑ | TPR (%) ↑ | Input Tokens (k) ↓ | Output Tokens ↓ |
|---|---|---|---|---|---|
| Aider | GPT-4o | 5.56 | 1.85 | 10.67 | 492.67 |
| GPT-4.1 | 11.11 | 7.41 | 14.83 | 734.17 | |
| Claude 3.5 | 16.67 | 12.96 | 7.48 | 534.00 | |
| SWE-Agent | GPT-4o | 17.58 | 10.19 | 275.53 | 1282.70 |
| GPT-4.1 | 38.89 | 31.48 | 301.11 | 2098.33 | |
| Claude 3.7 | 64.81 | 42.59 | 552.79 | 807.63 | |
| OpenHands | GPT-4o | 21.30 | 14.82 | 760.53 | 3990.31 |
| GPT-4.1 | 55.56 | 42.59 | 465.94 | 1535.47 | |
| Claude 3.7 | 72.22 | 48.15 | 9501.25 | 85033.05 | |
| EnvX | GPT-4o | 42.59 | 33.33 | 811.02 | 4506.83 |
| GPT-4.1 | 68.52 | 46.30 | 380.20 | 1648.43 | |
| Claude 3.7 | 74.07 | 51.85 | 562.56 | 5686.89 |
Aider 一组的第三个骨干在 Table 1 里写「Claude 3.5」，其余全部是「Claude 3.7」——照表原样转录，未作修正。这与 §4.2.1「三个骨干对本文和基线全部共用」并列：原文两处不一致，本节只并列、不调和。
| 骨干 | EnvX ECR | OpenHands ECR | ECR 绝对差 | EnvX TPR | OpenHands TPR | TPR 绝对差 | TPR 相对差 |
|---|---|---|---|---|---|---|---|
| Claude 3.7 | 74.07 | 72.22 | 1.85 pp | 51.85 | 48.15 | 3.70 pp | 7.68% |
| GPT-4.1 | 68.52 | 55.56 | 12.96 pp | 46.30 | 42.59 | 3.71 pp | 8.71% |
| GPT-4o | 42.59 | 21.30 | 21.29 pp | 33.33 | 14.82 | 18.51 pp | 124.90% |
全部数字来自 Table 1；「相对差」= 绝对差 ÷ OpenHands 值，如 3.70 / 48.15 = 7.68%。
结论有三条：
把这句和 Table 1 并排读：7.6% 不是 TPR 相对任何单一基线的差（相对 SWE-Agent 是 21.74% = 9.26 / 42.59），也不是相对 OpenHands 的 7.68% = 3.70 / 48.15（四舍五入到一位是 7.7%）。原文没在句内声明口径，页面不替它折算。
按 Table 1 复算：GPT-4.1 下 ECR 绝对差是 12.96 个百分点（68.52 − 55.56），TPR 绝对差是 3.71 个百分点（46.30 − 42.59）。原句写的是「percentage points」，但这 23.40 在表里找不到对应：ECR 相对提升按表算是 23.33%（12.96 / 55.56），TPR 相对提升是 8.71%（3.71 / 42.59），而 TPR 绝对差是 3.71 个百分点。原文句与 Table 1 并列于此，不做调和；页面引用时保留原文，复算值另列，供读者自行判断。
第三处冲突（骨干版本）：§4.2.1 写「We use three widely adopted LLMs: GPT-4o …, GPT-4.1 …, and Claude 3.7 … Sonnet as the backbone models for both our system and the baselines」；而 Table 1 中 Aider 的第三行为 Claude 3.5（16.67 / 12.96 / 7.48 / 534.00）。原文两处并列于此，本页不作调和；上表按 Table 1 原样转录。
GPT-4o 的 100% / 124.90% 按 Table 1 复算为 99.95%（(42.59 − 21.30) / 21.30，原文取整为 100），124.90% 按表复算为 (33.33 − 14.82) / 14.82 = 124.90%，与原文数值相同。
还有一个细节：TPR 与 ECR 的差能看出「能跑」到「跑对」还剩多少。EnvX 在 Claude 3.7 下是 74.07 − 51.85 = 22.22 个百分点，OpenHands 是 72.22 − 48.15 = 24.07，SWE-Agent 是 64.81 − 42.59 = 22.22。EnvX 和 SWE-Agent 持平，说明 EnvX 省下来的 token 换来的是「环境装得更稳」，而不是「内容更对」。
读完这节要知道：哪几条限制是作者自己承认的，哪几条是数据里读出来的。
「our current evaluation primarily relies on scripted oracles and curated tasks, which leaves important gaps in coverage for long-horizon coordination, robustness under distribution shift, and security-in-the-loop failure modes.」（§5）
第二、三段展望里补了两句：「验证信号仍较粗」（verification signals are still coarse-grained），以及要把 agent card 与 skill schema 做到「explicit contracts, versioning, and provenance logging」。
54 / 18 = 3 个任务/仓库。多仓协作只有 §4.4 一个案例（图 2，三个仓库），它在 54 个任务里的权重论文未给。从这个样本外推到 GitHub 上「数百万项目」的异质性，是论文没做也无法从这批数据推出的。推断（依据：§4.1 的 18/54 与 §3 所述 GitHub heterogeneity 在规模上不对等）。
Table 1 只有 token 数，没有延迟、没有会话轮数、没有环境构建耗时。§4.3 说「larger models plan more effectively and make fewer erroneous steps」，即 token 随规模下降，但仍未给出墙钟时间。用它做生产系统时，「one function call per round」会放大延迟，论文没量化这一点。
阶段 1 让 agent 按文档执行「装包、下载、跑脚本」。恶意或过时的 README 可以引导危险操作；论文 §5 把 security-in-the-loop failure modes 列为「覆盖缺口」，没有在方法里给出沙箱、权限、回滚机制。