企业官网建设流程全解析

1. RepoMaster 和 GitTaskBench 到底在解决什么问题

复现一份发布没多久的基准评测，其实比跑通一个 Demo 折磨人得多。我这个月的大部分时间耗在 RepoMaster 和 GitTaskBench 这个组合上——RepoMaster 是一个面向仓库级代码任务的 Agent 框架，GitTaskBench 则是配套的评测基准，里面每一条任务都对应一个真实 git 仓库的历史 issue、期望补丁和验证测试。把这个组合完整跑通的意义在于：只有拿到和论文接近的指标，后面换模型、改检索策略、调 prompt 才有可比性，否则你根本分不清收益来自你的改动，还是评估协议本身变了。

先解释一下这两个东西解决什么问题。传统代码生成基准大多是"单文件、单函数"级别的，给一段函数签名和 docstring，让模型补全实现。GitTaskBench 这类仓库级基准完全不是这个玩法：它给你一个真实仓库的某个历史提交点（base commit），再给你一条 issue 描述，比如"修复某个边界条件下列表索引越界的问题"或者"给某个模块加上缓存机制"，你需要让 Agent 在完整的仓库上下文里定位相关文件、生成修改 diff、然后跑真实测试来验证。RepoMaster 就是干这个活儿的编排框架：把仓库索引、上下文检索、规划、补丁生成、验证循环串成一条流水线，GitTaskBench 则是这条流水线对标的考卷和判卷标准。

把这两个放一起复现，最直接的理由是做消融实验。RepoMaster 里每一个模块都有可替换性：检索用 BM25 还是用 embedding？验证循环让模型重试几轮？这些改动分别能带来多少收益，必须有 GitTaskBench 的数值作为标尺。如果连官方的基线数字都复现不出来，后面所有实验都站不住脚。这篇东西适合三类人看：准备做代码生成或 Agent 方向研究的研究生、想评估本地开源模型在真实仓库任务上几斤几两的算法工程师、以及纯粹想搞清楚"仓库级基准的评估到底是怎么算的"的实践者。

2. 复现之前先确认的四件事

2.1 版本锁定：论文、数据集、代码仓库的三维对应

复现基准评测最怕的一件事，就是你跑出来的东西和论文里描述的已经不是同一个东西了。GitTaskBench 这类数据集通常有版本迭代，RepoMaster 作为框架也在不断改代码，论文表格里的数字对应的往往是某个特定 commit 加某个特定数据集版本。

我给你的实操建议是：开工之前先建一个reproduce_env.md，把下面三组信息全部记进去：

• 论文或者 README 中报告的指标，对应的是数据集哪个版本（v0.1、v1.0 之类）；
• RepoMaster 代码仓库的 commit hash，最好用git log找到发布论文时的 tag；
• 评测脚本的版本号，别小看它，patch 解析逻辑和测试集合的判定方式一改，数值就变了。

我踩过的具体版本陷阱是这样的：第一次复现时我直接从主分支拉了最新代码，结果评测脚本对 diff 的解析逻辑已经重写过，原来能正确识别的git apply格式补丁，在新版本里被判定为"应用失败"。一个晚上跑出来的结果比官方数字低了十几个点，排查到最后才发现是脚本版本问题，数据本身完全没毛病。所以版本锁定不是洁癖，是复现工作的第一条生命线。

2.2 数据集长什么样：先看一条任务再说

拿到数据集后别急着跑全量，先打开任务文件看一条样本。GitTaskBench 这类数据集的结构通常是这样的：

git-task-bench/ ├── tasks.jsonl # 每条任务一行，包含全部元信息 ├── repos/ # 所有涉及的仓库镜像 │ └── {repo_name}/ ├── golden_patches/ # 官方修复补丁，用于验证和参考 ├── tests/ # 测试用例或测试描述 └── meta/ # 运行脚本、环境描述等辅助文件

tasks.jsonl里一条典型任务长这样（字段名大致如此，不同版本会略有差异）：

{ "instance_id": "python-repo-1234", "base_commit": "7f2a9d1c3b...", "problem_statement": "When the input list is empty, the function raises IndexError...", "golden_patch": "diff --git a/src/foo.py b/src/foo.py\n...", "FAIL_TO_PASS": ["test_foo_empty", "test_foo_single"], "PASS_TO_PASS": ["test_foo_normal", "test_bar_basic"], "install_command": "pip install -e .", "test_command": "pytest tests/test_foo.py -k test_foo" }

你必须弄清楚每个字段的含义再往后走。base_commit决定 Agent 在哪个历史状态上工作；FAIL_TO_PASS是"应用正确补丁后必须从失败变为通过"的测试；PASS_TO_PASS是"原本通过且修补后也必须保持通过"的测试。这两个集合直接决定了什么算"修复成功"，后面评估环节完全依赖它们。

我强烈建议你花一小时把数据集中几十条样本的problem_statement和golden_patch人工过一遍。这一步会帮你建立对任务难度的直觉：有些任务只涉及一个文件里的几行改动，有些要跨模块修改五六个文件。你只有亲眼看过真实样本，才能在后面判断"Agent 生成不出来"到底是模型能力问题，还是任务本身就不是一个 7B 模型能解决的。

2.3 评估指标到底怎么算：resolved 不是"能跑"

在仓库级基准里，"解决"（resolved）判定看起来简单，实际有许多细节。标准定义是：把 Agent 生成的补丁应用到base_commit对应的代码上后，FAIL_TO_PASS集合里的测试全部通过，并且PASS_TO_PASS集合里的测试也全部通过，这个实例才算 resolved。

但这里有三个容易在复现时搞错的地方。

第一，测试的执行环境必须干净。你不能在自己已经改了依赖的机器上直接跑，得用隔离环境。否则测试之间互相影响，或者装到了新版本依赖，结果就不可信。

第二，pass@1 和 pass@k 的口径不一样。pass@1 是每个任务只让模型生成一次，看成功率；pass@k 是让模型生成 k 次候选补丁，只要有一个能通过测试就算解决。RepoMaster 这类框架里常见的设计是"验证循环"：Agent 先自己把补丁放到沙盒里跑一遍测试，失败了就根据测试输出再改再跑，最多重试 N 轮。这个机制会让"实际调用模型次数"和"最终提交的补丁"之间产生统计口径差异。有些论文把"含验证循环的成本"和"不含验证循环的 pass@1"分别报告，复现时一定要看清楚自己统计的是哪一种。

第三，跳过测试（skip）的处理。有些任务的某些测试在特定平台上没法跑，评估脚本可能会允许标记 skip。如果你的复现里允许的 skip 规则和官方不一致，结果会有几分的浮动。

我自己的建议是：评估部分尽量用官方脚本，不要自己写"看起来差不多"的判定逻辑。diff 是否成功应用、测试输出怎么解析、skip 怎么处理，这些细节自己重新实现很容易埋坑。

2.4 算力与时间账：先做小规模冒烟测试

仓库级基准的复现成本比普通代码生成基准高得多，因为每个实例都涉及克隆仓库、构建环境、跑真实测试。开工前先算一笔账，免得跑到一半发现资源不够。

以我复现时的配置为例，按模型规模粗估如下：

这个单实例耗时是"检索 + 生成 + 验证"的总和，而且还没算上环境构建时间。如果数据集有 500 个实例，用单张 24G 显卡跑 7B 模型，满打满算需要几十个小时，中间一旦某个任务卡住，整个队列可能停摆。

所以我的建议是：永远先抽 10 条任务做冒烟测试，把全链路跑通、确认评估脚本输出正常，再决定是跑全量还是按预算采样。冒烟测试能救命的场景我后面会专门讲。

3. 环境搭建：依赖版本比论文更贴近结果

3.1 我最终定下来的软件栈

RepoMaster 这类框架的依赖通常很重，涉及模型推理、代码解析、git 操作和测试执行。我的第一步是建独立的 Python 环境：

conda create -n repomaster python=3.10 -y conda activate repomaster

Python 版本不建议直接上 3.12，因为不少代码解析库（比如 tree-sitter 的某些语言包）对 Python 3.12 的 wheel 支持滞后，遇到编译报错会浪费大量时间。3.10 兼容性最好，跑这类框架基本没有幺蛾子。

再往下是深度学习栈。我的经验是不要追新，直接参考框架 README 里锁定的版本，这里给一份我实测稳定的组合：

安装顺序也有讲究。先装 torch 再装 vLLM，让 vLLM 检测到已有的 CUDA 运行时，不然它可能试图重新拉一套 torch，版本冲突直接让环境烂掉。我当时图省事用一条pip install -r requirements.txt，结果 torch 被 vLLM 的依赖解析器升级到了 2.3，FlashAttention 和 CUDA 版本对不上，模型推理直接报算子不匹配。最后是重建环境、按顺序安装才解决。

3.2 模型服务与采样参数

RepoMaster 的下游是模型推理。如果经费允许用商业 API，省事很多；但做复现实验的人大多需要反复调用，本地部署更划算。本地起服务我推荐 vLLM，因为它支持 OpenAI 兼容接口，RepoMaster 只需要配一个base_url就能对接，不需要改框架代码：

VLLM_CACHE_SIZE=0 \ CUDA_VISIBLE_DEVICES=0 \ python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-Coder-7B-Instruct \ --served-model-name repomaster-coder-7b \ --max-model-len 32768 \ --gpu-memory-utilization 0.90

注意max-model-len这个参数，仓库级任务的 prompt 经常超过 32k token。如果设小了，超长上下文会被静默截断，模型看到的仓库信息不完整，生成出来的补丁自然残缺。这个坑我在第 5 节会详细讲。

采样参数方面，我复现时用的是 temperature 0.2、top_p 0.95，并且固定 seed。这样做的原因是保证实验可复现：同一组 prompt 在相同 seed 下会得到同样的输出，排查问题时能精准定位是哪一步变了导致结果不同。如果你在跑消融实验，seed 不固定会引入随机噪声，最后 1% 的指标差异会很难归因。

3.3 权重下载与磁盘规划

模型权重从 Hugging Face 下载，如果网络访问比较慢，可以把环境变量指向国内镜像服务，速度会明显改善：

export HF_ENDPOINT=https://hf-mirror.com

下载完成后别急着开始，先检查文件完整性。safetensors 的索引文件会在加载时报错，如果你发现safetensors文件大小和页面显示不一致，多半是下载中途断了，删掉重新下。

磁盘规划也要提前做。7B 模型的权重差不多要 15GB，但真正的空间大头是数据集的仓库克隆。GitTaskBench 里涉及的仓库如果含大文件历史，一个仓库克隆占十几个 GB 很正常。我建议给整个工作目录至少留 200GB 的余量。用df -h检查磁盘，别等到跑到第 300 个任务时系统盘满了，那真是欲哭无泪。

3.4 Git 操作层面容易忽略的小事

复现中大量操作围绕 git 展开，有几个细节看似琐碎，实际影响很大。

第一，GitPython 在切换分支、应用补丁时会以系统身份执行 commit 操作，如果全局没配置user.name和user.email，某些操作会直接失败，报"Please tell me who you are"。在环境里预设好：

git config --global user.name "reproducer" git config --global user.email "reproducer@example.com"

第二，仓库克隆后要做一次git checkout base_commit，但这里有个坑：如果目标 commit 不在默认分支上，你需要先确认它属于哪个分支，或者直接git checkout <hash>进入 detached HEAD 状态。我见过有人因为 clone 了默认分支，base_commit切不过去，生成的补丁应用的却是错误的代码版本，结果全盘作废。

第三，每个任务的工作目录要独立。不同任务可能共用同一个仓库镜像，但必须保证在隔离的工作副本里 checkout 到各自任务对应的base_commit。你可以在每轮任务开始前列一个检查清单：仓库是否 clone、commit 是否正确、工作区是否干净、补丁文件是否存在。

4. 主流程拆解：从一条 issue 到一个 resolved

4.1 数据准备：克隆、切分支、建环境

主流程第一步是数据准备。写一个数据加载器，读取tasks.jsonl，过滤掉没有golden_patch或测试集合为空的实例——这类实例没法判定 resolved，留着只会干扰统计。

接着按任务批量克隆仓库。我的做法是这样的：先建一个 repos 镜像目录，每个仓库只 clone 一次，然后为每个任务从镜像 clone 出一份独立副本，或者直接用git worktree add在独立目录 checkout 出base_commit。用 worktree 的好处是快，复用同一份 .git 对象库，不占额外磁盘。

git clone <repo_url> repos/<repo_name> cd repos/<repo_name> git worktree add ../../work/<task_id> <base_commit>

然后是环境构建。这一步是成本大头。每个任务可能要求不同的安装命令和依赖，我建议不要为每个任务都重新建一个虚拟环境或容器，而是先把所有任务的install_command做个聚类：依赖相似的归一组，共用一份基础镜像或基础环境。这样至少能把构建时间压缩一半。

我踩过的一个教训是：环境构建时一定要用锁文件固定依赖版本，不要跑pip install -e .让它自己解析最新依赖。因为仓库的历史状态对应的是当时的依赖环境，装到最新版依赖后，一些老代码可能直接崩，或者测试结果被新版本行为改变。复现仓库级基准的核心精神就是"还原历史现场"。

4.2 RepoMaster 的推理管线：四层结构

RepoMaster 的核心是一条四层流水线，我按实际操作顺序拆解如下。

第一层叫仓库理解。它读取仓库目录树，用 tree-sitter 之类的解析器生成 AST 索引，让后续检索能快速定位类、函数、变量定义。这一层输出的就是"这个仓库里有什么"的结构化描述。实测下来，AST 索引对跨文件改动特别重要，因为它能建立符号引用关系：issue 里提到"某个函数崩了"，索引能帮你顺藤摸瓜找到调用它的上层函数。

第二层是任务定位。给定 issue 描述，先用问题里的关键词做候选文件筛选。最稳的基线是 BM25 检索，它不需要额外服务，速度极快，而且对代码关键词的命中效果不错。我当时先跑了 BM25 基线拿到一个数字，再换成 embedding 向量检索，发现检索质量高的情况下可以带来三到五个百分点的提升，但也需要自己部署一个 embedding 服务，维护成本更高。

第三层是补丁生成。把候选文件内容、项目结构摘要、issue 描述组装成一个结构化 prompt，要求模型输出 unified diff。这一步有几个实操经验：一是提示词里必须明确"只输出 diff，不要解释"，否则模型容易写一大段分析然后给个残缺的补丁；二是要告诉模型它改动的文件路径和函数名，让它定位准确；三是把检索到的文件按相关度从高到低排列，因为上下文窗口有限，排在后面对文件很容易被截断。

第四层是验证循环。补丁生成后先做一个静态应用检查，把 diff 应用到干净副本，如果git apply失败，先用--whitespace=fix重试，还不行就尝试 fuzzy 匹配。应用成功后运行FAIL_TO_PASS里的测试，如果没全部通过，把测试输出反馈给模型再补一轮修复。这个循环最多跑 N 轮，超过之后即使测试没过也强行提交，避免成本无限膨胀。这里的 N 是重要超参，N 越大指标越高但成本线性上涨，我通常用 3。

4.3 验证器：最容易被低估的一环

验证器是整个管线里最不性感、却最容易偷走分数的一环。它的职责是：在隔离环境里应用补丁，运行测试，判定哪些测试通过哪些失败。

我的具体写法是这样：每个任务起一个独立的沙盒目录，把补丁应用进去，设置两分钟到五分钟的测试超时（不同任务差异很大）。测试命令统一用subprocess执行，并限制 CPU 和内存资源：

subprocess.run( test_command, shell=True, cwd=workdir, timeout=test_timeout, capture_output=True, text=True, env={**os.environ, "PYTHONDONTWRITEBYTECODE": "1"} )

必须禁止测试过程访问网络。原因很简单：如果一个测试用例依赖某个在线服务或者会联网拉取数据，它的行为就会随外部环境漂移，你今天跑通过明天跑失败，根本无法稳定复现。最稳妥的做法是在容器或沙盒里直接切断网络，这样测试行为才完全由代码状态决定。

个测试输出解析也是一个细节密集的地方。pytest 可以直接解析退出码，但有些仓库用的是自定义测试框架，输出格式乱七八糟。我的做法是把原始输出完整保存下来，再用正则或 JUnit XML 解析器提取测试用例级结果。这里千万要保存原始日志，后面排查 flaky test 时全靠它。

还有一点容易被忽略：测试之间的状态污染。有些测试会修改全局状态或者写文件，如果并行执行，一个用例的副作用会影响另一个用例的结果。所以验证阶段优先顺序执行，即使慢一点也比结果波动强。

4.4 指标汇总：用官方脚本，别自己发明解析逻辑

最后一步是汇总。把每个任务的最终状态记录成一张表：instance_id、使用的模型、生成的补丁路径、验证结果、是否 resolved。然后调用评测脚本输出整体指标。

为什么强调用官方脚本？因为"补丁是否被正确应用"和"测试是否属于 PASS_TO_PASS"这类判定，不同人实现的标准差异很大。我自己试过用朴素方式统计：只要 FAIL_TO_PASS 全过就算 resolved，结果发现某几个任务里 PASS_TO_PASS 测试被改了行为，官方判定是失败，我的统计却把它算成了成功。那一次直接让指标虚高了两个点。

所以指标汇总这步别贪快，先对着官方 README 把输入输出的格式搞清楚。通常就是一行命令的事：

python -m git_task_bench.evaluate \ --predictions /path/to/predictions.json \ --dataset /path/to/tasks.jsonl \ --output /path/to/results.json

输出里通常包含每个任务的 resolved 标记、整体 resolved rate，以及按仓库或按难度分组的子指标。这些子指标非常有用，后面分析差异来源时可以直接定位到具体类别。

5. 完整排查链路：我踩过的四个坑

5.1 坑一：环境构建反复失败

我的复现之旅第一晚就栽在环境构建上。现象是：每个任务跑之前都要构建依赖环境，构建过程总是间隔几分钟后超时或失败，日志里提示 pip 下载慢、某个系统包找不到。

排查链路是这样的：先看构建日志，发现耗时集中在 pip 下载依赖阶段，基本可以判定是网络源的问题；于是把 pip 源换成内部镜像，构建时间立刻缩短到原来的四分之一。然后发现另一个任务需要安装某个系统级依赖，但基础镜像里没这个包，而且我老是忘记先装系统包就装 Python 包，导致编译失败。修复方式是修改构建脚本：先统一处理系统依赖，再装 Python 依赖，分层的顺序下来基本就稳定了。

最浪费时间的其实是另一个隐性因素：构建缓存没有复用。每个任务都从头开始装同一套依赖，纯纯的重复劳动。解决方案是把"基础环境安装"和"任务特定安装"分开，基础环境只构建一次并缓存成镜像，后面所有任务直接复用。

5.2 坑二：结果差五个点，真凶是 flaky 测试

第二晚遇到的坑更隐蔽。我跑完冒烟测试一看，resolved rate 比官方基准低了五个点，第一反应是模型能力不行。但我随手把一个失败实例的补丁手工重放了一遍，测试居然全部通过了。这说明要么是验证器有 bug，要么是测试本身不稳定。

排查链路：我把同一个补丁在同样环境下重复跑了五次，发现其中两个 PASS_TO_PASS 用例有时候过有时候挂。细看测试代码，一个涉及随机数生成，另一个依赖 Unix socket 的临时端口分配，都属于典型的 flaky 场景。再仔细看，发现并行执行的验证任务之间共享了机器上的临时目录，某个用例写出的临时文件干扰到了另一个任务的同名用例。

修复方案有三层：一是每个验证沙盒完全隔离临时目录；二是对涉及随机和并发的测试固定 seed；三是对全部测试做三次重复执行、取多数结果作为最终判定。做完这三件事，指标立刻回到了正常区间。这个坑给我的教训是：评估环境的不稳定性，比模型的波动更能毁掉你的数字。

5.3 坑三：长上下文截断导致补丁残缺

第三个坑出现的场景是：模型生成的 diff 只改了问题涉及的前两个文件，第三个文件原样没动，导致测试直接失败。乍一看像是模型能力不够，但仔细看日志才发现，prompt 里的文件内容一共有四万多个 token，而我设置的max-model-len只有 32768，排在最后的两个文件在输入阶段就被截断了，模型根本没见过它们。

排查链路：打开每轮请求的日志，统计输入 token 数和实际送入模型的内容范围，问题一目了然。修复方式有三条路可以选：一是提高max-model-len，但显存占用会随之增加；二是减少检索喂给模型的文件数量，把候选从十个压缩到五个，只留最相关的；三是把单 prompt 拆成两段，主文件用详细内容，次要文件压缩成摘要。我最终采用的是第二条加第三条的组合，效果最稳定。

这个坑说明一个道理：上下文预算的分配策略，有时候比模型本身的推理能力更影响结果。给模型喂太多无关文件，它记不住重点；喂太少，它没有足够信息定位问题。这个平衡点需要你在自己的数据集上实测。

5.4 坑四：并行任务把整机 OOM

第四个坑是资源管理问题。为了赶时间，我一口气把四十个任务的验证容器同时启动，结果不到十分钟，整台机器内存被打满，vLLM 的推理进程直接被系统 OOM killer 杀掉，所有正在跑的任务全部中断，还污染了几个共享目录。

排查链路：先看dmesg确认进程是被 OOM 杀掉，再统计每个容器的内存占用，发现光验证容器就吃掉了八十多个 G。修复方式是给并行度加信号量：统一控制在四到八个并发任务，并且给每个验证进程设置内存上限。另外加了一个硬性超时——每个任务十分钟跑不完就杀掉重新调度，防止个别任务卡死拖垮整个队列。

这类问题对复现效率的威胁最大，因为往往是在你睡了觉之后悄悄发生，第二天醒来发现任务队列全部失败，浪费一整个晚上的算力。

6. 数字对不上时怎么判断复现是否成功

6.1 先做一张官方与复现的对照表

复现实验最紧张的时刻就是看结果的那一刻。我建议把所有指标整理成一张对照表，不要只看一个总数。示意如下：

如果差异在正负两个点以内，基本可以认为复现成功。如果有明显偏差，就按下面的顺序排查。

6.2 差异来源的排查顺序

第一优先级：模型权重和采样参数。你是不是用了和官方完全一致的模型版本？有些模型会有 base 和 instruct 的差异，量化版本和全精度版本结果完全不同。再检查 temperature、top_p、seed 是否一致。

第二优先级：评测脚本版本。打开数据集的 release 记录，看你下载的评测脚本和官方报告指标时用的是不是同一个版本。patch 解析逻辑、skip 规则、测试超时参数，任何一项改动都会影响结果。

第三优先级：环境依赖漂移。你安装依赖时用的是不是当时的锁文件版本？测试依赖的最新版本可能改变测试行为，这会让 PASS_TO_PASS 集合里的用例产生和官方环境不同的表现。

第四优先级：flaky 测试和硬件差异。CPU 核数、内存大小、文件系统性能都会影响超时敏感的测试用例。如果一个用例两秒能跑完但在你的机器上跑了两分半，恰好超过超时阈值，它就会从通过变成失败。

排查的时候不要猜，打开单个任务的日志去对：生成补丁是否一致、测试输出差异在哪一步出现、是模型没做对还是评估没算对。逐类抽样五到十个实例，基本就能定位问题所在。

6.3 什么误差范围可以接受

我的实操体会是：仓库级任务基准因为涉及真实测试执行，误差阈值比纯代码生成指标要宽容一些。正负两个点可以视为复现成功；超过五个点就需要认真查原因，而不是简单安慰自己"可能环境不一样"。

如果数字差异大，还有个非常有效的办法：人工检查抽样实例的补丁质量。把 Agent 生成的 diff 和 golden patch 对比，看它是不是做到了相似的功能。有些时候是模型生成了正确的修复但验证器误判失败，有些时候是模型完全在复述 issue 里的描述，根本没改代码。这两种情况需要的处理方式完全不同：前者修环境，后者换模型。

7. 给后来者的几条实操经验

最后分享几点这段时间积累下的实操经验，每一条都是用时间换来的。

先跑小规模冒烟测试再放量。十到二十条任务足够覆盖全链路：数据加载、仓库克隆、模型推理、补丁应用、测试执行、指标输出。全链路通了，再决定全量任务的并行度和资源规划。

一定要做 checkpoint 和断点续跑。仓库级基准跑全量动辄几十个小时，中途机器重启、显存报错、磁盘满了都可能中断。把每个任务的完成状态实时写入一个状态文件，下次启动自动跳过已完成的任务，这能帮你省掉至少一个无效的周末。

日志写法按"每条任务一个 JSON 行"来组织。记录时间戳、任务 ID、模型输入输出长度、检索文件列表、重试轮数、测试结果、最终 resolved 状态。后续排查差异时，这些日志是唯一的证据链，越详细越好，别嫌多。

成本控制上有个性价比顺序：先用小模型把管线验证正确，再上大模型跑正式实验；先跑 BM25 检索基线，再考虑部署 embedding 服务；先跑一个模型的一个配置，把整套流程吃透，再铺开多模型多配置的矩阵。

复现这件事，最容易被低估的是评估协议细节。我这次最大的收获不是把 RepoMaster × GitTaskBench 的数字跑及格，而是把"resolved 到底怎么定义"这一层彻底搞清楚。以后做任何仓库级 Agent 实验，我都会先把评估脚本读一遍、把数据集样本人工看一遍再开始调模型。这个习惯，能帮你省下无数个怀疑人生的下午。