这次我们来看一个编码 Agent 领域的开源新成员华为开源的 openJiuwen 编码 Agent harness。这个项目一出来就直接把 SWE-bench Verified 刷到了 82.6%和目前头部闭源产品或顶尖开源方案已经处在一个层级上。如果你关注 AI Agent、编码助手、SWE-bench 评测或者想自己搭一套“给机器人派单修代码”的测试框架这篇文章可以直接收藏。先说这个项目最值得关注的点第一它是标准 harness 工程重点不是模型本身而是怎么把一个编码 Agent 的完整循环跑起来包括问题理解、代码修改、测试执行、结果评估第二在 SWE-bench Verified 上 82.6% 的成绩说明它的流程设计是有效的不是玩具第三它开源意味着你可以基于它去评测自己的模型、自己的提示词策略甚至接入自己的私有代码库做实验。文章会按这个顺序展开先说 openJiuwen 到底是什么、SWE-bench Verified 82.6% 是什么概念然后讲清楚这类 harness 的使用场景再给出一套完整的本地部署与验证流程最后落到接口调用、批量任务、资源占用和常见问题上。无论你是想复现成绩、评估模型还是想借鉴它的 agent 流程设计都可以按这篇文章的步骤走一遍。1. 核心能力速览能力项说明项目类型编码 Agent harness / 评测框架开源方华为评测成绩SWE-bench Verified 82.6%主要功能驱动编码 Agent 完成代码任务支持测试执行、结果评估、任务闭环评测基准SWE-bench Verified真实 GitHub issue 测试用例支持平台以 Linux 服务器为主macOS / Windows 可尝试但需调整依赖启动方式命令行启动是否支持 API取决于接入的底座模型harness 本身通常通过模型 API 或本地模型接口驱动 Agent是否支持批量任务支持多个 issue 可批量跑推荐硬件GPU 服务器具体显存取决于底座模型适合场景模型评测、Agent 策略实验、代码库自动化修复测试、编码能力对比需要说明的是82.6% 这个成绩是项目发布时给出的 benchmark 数据具体数值会随模型版本、评测配置和数据子集不同而波动。复现时不要把它当作固定结果重点是它的 harness 流程和评测方法论。2. SWE-bench Verified 82.6% 是什么概念先解释一个关键背景SWE-bench 是目前编码 Agent 领域最常用的评测基准之一。它从真实开源项目里抽取 GitHub issue然后把问题描述、相关代码仓库快照、以及隐藏的测试用例一起交给 Agent。Agent 需要先读懂 issue定位相关代码修改文件最后跑测试用例验证。整个过程模拟的是一个真实程序员修 bug 的工作流比单纯问“这段代码哪里错了”要难得多。SWE-bench Verified 是从完整 SWE-bench 里人工筛选并验证过的一批任务去掉了描述不清或者测试环境有问题的样本结果更可信。目前业内看一个编码 Agent 强不强基本都会先看它在 SWE-bench Verified 上的通过率。openJiuwen 在这个基准上达到 82.6%意味着什么简单说如果把 100 个真实 GitHub issue 交给它大约 82 个能成功完成代码修改并通过隐藏测试。这个水平已经可以和目前第一梯队的编码 Agent 正面比较。更重要的是它不是靠单一模型硬撑而是通过一个可扩展的 harness 工程来实现这就给开源社区留下了很大的改进空间。另外从近期热词来看deepseek harness、codex harness、hermes agent、agent 开发、agent 框架这些词频繁出现说明编码 Agent 赛道已经进入“框架和流程竞争”的阶段。openJiuwen 走的正是这个方向把 Agent 循环、测试执行、结果评估标准化换模型、换提示词、换工具都可以在这个框架里快速实验。3. 适用场景与使用边界3.1 适合谁用第一类是模型评测人员。如果你在做一个开源代码模型或者微调了一个私有编码模型想知道它在真实 issue 修复场景里的表现openJiuwen 可以直接作为评测框架避免自己写一堆繁琐的 Agent 循环和测试执行代码。第二类是 Agent 应用开发者。无论你是用 OpenAI API、Claude API还是本地部署的 Qwen、DeepSeek 系列模型只要模型具备对话和工具调用能力就可以把它接到 openJiuwen 里然后观察不同 prompt 策略、不同 Agent 流程对最终修复率的影响。第三类是研发效能团队。如果你的团队想尝试自动修 bug、自动补测试openJiuwen 提供了完整的“问题 - 代码修改 - 测试验证”闭环可以基于它做内部代码库的自动化修复实验。但要注意私有代码库和开源 benchmark 的差距很大直接迁移到生产环境前需要做严格验证。3.2 不适合什么场景它不适合直接当成普通编码助手来用。你输入“帮我写一个快速排序”然后期望它直接给你一段代码——这不是它的工作方式。openJiuwen 更关注的是完整 Agent 循环理解 issue、操作文件、执行测试、迭代修复。如果你只是想找个“AI 补全代码”的插件可以不用考虑它。它也不适合没有测试用例的代码库。SWE-bench 之所以可信是因为每个 issue 都绑定了隐藏测试。如果你要修的代码库完全没有测试覆盖那 Agent 改完代码后缺少“验证”效果很难保证。3.3 使用边界与合规提醒openJiuwen 是评测和研究工具使用时必须注意几点只能用它处理你有权修改的代码库。不要拿第三方私有代码库跑 Agent 修复更不能把结果用于未授权的商业场景。如果接入了云端模型 API注意代码内容会发送给模型服务方。涉及商业机密或用户隐私的代码建议先用脱敏数据测试或者选择本地部署的模型。模型生成代码可能存在许可证风险。Agent 修复后生成的代码片段如果参考了其他开源项目发布前需要做版权审查。不要用这个工具去批量扫描、窃取或未授权分析他人代码。4. 环境准备与前置条件openJiuwen 本身是一个 Python 工具链部署前需要确认以下环境4.1 操作系统优先选择 Linux。SWE-bench 的测试环境大多基于 Docker 运行Linux 下 Docker 兼容性最好。如果你在 macOS 或 Windows 上测试需要自行解决 Docker Desktop 依赖和路径兼容问题建议还是用一台 Linux 服务器。4.2 Python 环境建议使用 Python 3.10 及以上版本。项目依赖较多推荐用 conda 或 venv 建独立环境避免污染系统 Python。conda create -n openjiuwen python3.10 -y conda activate openjiuwen4.3 模型接入方式openJiuwen 需要一个底座模型来驱动 Agent。这里有两种情况调用云端 API你需要准备对应模型服务的 API Key例如 OpenAI、Anthropic、国内大模型平台的 key。本地部署模型如果你使用 Qwen、DeepSeek 这类开源模型需要额外部署一个兼容 OpenAI 格式的推理服务比如 vLLM、SGLang然后在 harness 配置里指向本地服务的 base_url。不同模型的编码能力差异很大SWE-bench Verified 82.6% 这个成绩和它当时使用的模型组合、prompt 策略强相关。如果你换了一个本地小模型成绩可能大幅下降这属于正常现象。4.4 Docker 环境SWE-bench 的测试用例需要在特定容器环境里执行。安装 Docker 后确保当前用户有权限运行 docker 命令sudo usermod -aG docker $USER newgrp docker docker run hello-world4.5 磁盘空间SWE-bench 数据集本身不大但每个测试任务可能需要构建 Docker 镜像、下载依赖。按常见经验预留 50GB 以上可用磁盘比较稳妥。4.6 获取官方仓库git clone https://github.com/huawei/openjiuwen.git cd openjiuwen pip install -r requirements.txt注意以上命令中的仓库地址和安装步骤是通用模板实际路径和分支名以项目官方 README 为准。5. 安装部署与启动方式5.1 安装依赖进入项目根目录后先安装 Python 依赖cd openjiuwen pip install -e .这里用了-e参数即开发模式安装方便后续改代码调试。如果你只是跑评测不加-e也可以。5.2 配置模型接入以 OpenAI 兼容接口为例一般需要在环境变量或配置文件中设置 API Key 和模型名export OPENAI_API_KEYyour-api-key export OPENJIWEN_MODELyour-model-name export OPENJIWEN_BASE_URLhttps://api.openai.com/v1如果你接的是本地 vLLM 服务OPENJIWEN_BASE_URL指向本地地址例如export OPENJIWEN_BASE_URLhttp://127.0.0.1:8000/v1不同模型的 prompt 格式可能不同openJiuwen 的配置文件里通常会区分模型类型。实际使用时建议先跑一个最小任务验证连通性。5.3 启动服务openJiuwen 核心入口一般是命令行。启动一个评测任务的通用流程是python run.py --dataset swebench --split test --model your-model-name这个命令是示意真实参数要依据项目 README 调整。更稳妥的做法是看项目提供的示例配置通常在configs/目录下修改成你自己的模型名称和数据集路径。5.4 验证启动是否成功启动后观察日志如果看到模型 API 连接成功、数据集加载成功、Agent 开始处理第一条 issue说明启动正常。如果日志在数据加载阶段卡住多半是网络问题或数据集下载失败。如果日志报 API 连接错误优先检查 API Key、base_url 和模型名。6. 功能测试与效果验证跑通一个完整任务是验证 openJiuwen 是否可用的关键。这里给出一套通用测试流程具体参数需要按你下载的仓库文档调整。6.1 单条 issue 测试测试目的确认 Agent 能读 issue、改代码、跑测试、给出结果。操作步骤在配置文件中指定 SWE-bench 数据集路径。选择 SWE-bench Verified 中的一个 issue 作为测试样本。启动 Agent 循环。等待 Agent 完成修改并执行测试。查看输出目录中的 patch 文件和测试结果。预期结果生成一个 patch 文件记录 Agent 对代码的修改。输出 PASS 或 FAIL 标记。测试日志能清晰看到构建环境、执行测试、评分的过程。判断成功的标准Agent 能在限定步数内完成修改。测试用例能够正常执行而不是因为环境错误直接崩溃。最终结果能被 harness 正确解析。6.2 测试用例设计测试维度测试内容预期结果基础连通性输入一个简单 issueAgent 能定位相关文件并生成 patch测试执行修改代码后跑隐藏测试能正常输出 PASS / FAIL上下文长度输入长 issue 和大量项目文件不崩溃能基于关键信息定位问题多轮交互Agent 第一次测试失败后自我修复能看到多轮修改和重新测试稳定性同一 issue 跑多次结果波动可接受日志无异常中断6.3 常见失败原因数据集没下载成功SWE-bench 数据集体积较大网络不稳定会导致下载中断。建议手动下载后放到本地目录再在配置里指定路径。Docker 镜像构建失败测试环境依赖旧版本 Python 或系统库可能拉取失败。检查 Docker 源、网络和镜像缓存。模型上下文超限issue 描述加仓库代码可能超过模型上下文窗口Agent 会在中途截断。可尝试减小输入范围或换成支持更长上下文的模型。API 限流批量跑多个 issue 时容易触发限流。需要在配置中调低并发或者增加重试间隔。7. 接口 API 与批量任务7.1 单任务 API 调用思路openJiuwen 本质上是一个 Agent 调度流程底层的模型调用通常走 OpenAI 兼容接口。假设你本地已经启动了一个推理服务可以直接用 Python 请求测试连通性import requests url http://127.0.0.1:8000/v1/chat/completions payload { model: your-model-name, messages: [ {role: user, content: Read the issue and identify the bug.} ], max_tokens: 2048, temperature: 0 } response requests.post(url, jsonpayload, timeout180) print(response.json()[choices][0][message][content])这个请求只验证模型服务是否可用实际 Agent 运行时会由 harness 自动组装完整上下文和工具调用。如果你把 base_url 指向云端 API流程也一样只是要处理好鉴权和网络延迟。7.2 批量任务设计SWE-bench 评测天然是批量任务。你可以把多个 issue 组成一个队列逐个交给 Agent 处理。通用的批量调度脚本可以这样写import json import subprocess from pathlib import Path issues [ {id: issue_001, repo: owner/repo, description: ...}, {id: issue_002, repo: owner/repo, description: ...}, ] output_dir Path(./outputs) output_dir.mkdir(exist_okTrue) for issue in issues: command [ python, run.py, --dataset, swebench, --issue, issue[id], --output, str(output_dir / issue[id]) ] result subprocess.run(command, capture_outputTrue, textTrue) status PASS if result.returncode 0 else FAIL print(json.dumps({issue: issue[id], status: status}))实际使用时请把run.py和参数替换成项目真实入口。批量任务的重点是做好输出隔离和日志记录每个 issue 的结果单独保存方便失败后单独重跑。7.3 失败重试建议单条 issue 失败后不要立即重跑先看日志是环境错误、API 错误还是 Agent 生成错误。API 限流类错误可以加指数退避重试失败后等待 5 秒、10 秒、20 秒再重新请求。Agent 生成 patch 格式错误时可以把错误信息重新喂给 Agent让它按正确格式重新生成。Docker 构建失败的任务建议先手动构建镜像再跑 harness避免每次重复拉取。8. 资源占用与性能观察8.1 显存占用openJiuwen 本身的显存消耗可以忽略不计真正吃显存的是底座模型。如果你接云端 API本地只需要很小的显存甚至纯 CPU 也能跑 harness 流程。如果你本地部署底座模型显存占用完全取决于模型参数量。以常见的 7B 到 72B 模型为例显存占用可以从 16GB 到 100GB 不等需要根据模型推理框架和量化方式确定。观察显存可以用 nvidia-sminvidia-smi -l 5这个命令每 5 秒刷新一次显存和 GPU 利用率。批量任务跑起来后重点看显存是否持续增长、是否出现 OOM。8.2 性能影响因素上下文长度Agent 每轮都会把相关代码片段交给模型上下文越长推理越慢token 成本也越高。并发数同时跑多个 Agent 会大幅提升吞吐但也会成倍增加显存和 API 费用。测试执行时间SWE-bench 的 Docker 环境构建和测试执行非常耗时性能瓶颈往往不在模型推理而在测试环境准备。步数限制Agent 允许的迭代轮数越多消耗越大。建议先用小步数跑通流程再逐步增加。8.3 如何降低资源占用用更小的底座模型做流程测试确认 harness 跑通后再换大模型。控制 Agent 的单次最大文件读取量避免把整个仓库都塞进上下文。批量任务设置最大并发数例如同时跑 2 到 4 个 Agent避免显存突增。复用 Docker 镜像避免重复构建同样的测试环境。8.4 端口冲突与进程残留在大规模批量任务中容易出现端口冲突或残留进程。建议在启动脚本里统一管理端口结束时检查进程ps aux | grep run.py发现残留进程可以按需 kill。如果使用了本地推理服务充分释放端口也能避免下次任务失败。9. 常见问题与排查方法问题现象可能原因排查方式解决方案数据集加载失败网络不稳定或数据集路径错误检查日志和磁盘目录手动下载数据集并指定本地路径API 连接超时网络问题或接口地址配置错误curl 测试 base_url 连通性检查 API Key、base_url、网络代理设置Docker 镜像构建失败依赖源不可用或源镜像缺失查看 Docker 构建日志更换可用镜像源或手动构建显存不足 OOM底座模型过大或并发过高nvidia-smi 观察显存占用降低并发、使用量化模型或换小模型Agent 生成内容不合法模型输出不符合 JSON 格式要求查看原始模型输出在 prompt 中强化格式要求或加格式修正逻辑测试结果解析失败测试脚本输出格式不符合预期检查测试日志原始输出调整 harness 里的正则或评分逻辑批量任务中途卡住API 限流或单条任务陷入死循环检查任务超时设置和日志增加超时控制失败后自动跳过或重试换模型后成绩下降不同模型指令遵循能力差异对比基准模型成绩调整 prompt 模板或换回原模型10. 最佳实践与使用建议第一第一次跑通之前不要优化。先选一条 SWE-bench Verified 样本小步快跑确认整个链路完整。很多人在数据集下载和 Docker 构建阶段就卡住了这时候优先解决环境问题不要急着换 prompt。第二保留一套最小可运行配置。把 API 地址、模型名、数据集路径、输出目录全部写在配置文件里至少保证“换台机器也能快速复现”。这个配置就是一个基线后续任何改动都可以对照它来评估。第三输入、输出、模型文件分目录管理。建议目录结构如下openjiuwen/ ├── configs/ # 配置文件 ├── dataset/ # SWE-bench 数据集 ├── runs/ # 每个任务的日志和结果 │ ├── issue_001/ │ ├── issue_002/ └── patches/ # 生成的补丁文件第四批量任务必须加日志和失败重试。不要裸跑几百个 issue一旦中途断掉很难定位是哪个任务导致的。正确的做法是每个任务独立目录、独立日志重跑时只针对失败项。第五接口服务要限制访问范围。如果你的本地推理服务暴露在局域网要设置访问白名单。API Key 不要写死在代码里建议通过环境变量或密钥管理服务注入。第六涉及人脸、声音、版权素材时必须确认授权。openJiuwen 主要是代码分析和修改不涉及这些内容但如果你后续把 Agent 能力扩展到其他领域同样的合规原则仍然适用。第七发布或商用前要做效果复核。Agent 自动生成的 patch 不代表可以直接合入仓库。代码风格、命名规范、边界条件处理、安全漏洞都要人工检查。评测分数高不代表生产环境可以直接用。11. 总结与下一步openJiuwen 最值得尝试的点是它把编码 Agent 的评测和迭代标准化了。SWE-bench Verified 82.6% 的成绩说明这套 harness 的流程设计是有效的而且因为开源你可以把它当作实验底座搭配不同模型、不同 prompt、不同工具策略来对比效果。建议最先验证的是单条 issue 的完整闭环读 issue、改代码、跑测试、出 patch。这一步跑通之后再做批量评测和流程优化。最容易踩的坑是环境问题。SWE-bench 的 Docker 测试环境、模型 API 的上下文长度限制、批量任务时 API 限流这三个问题会消耗大量排查时间。建议先准备好稳定的 Docker 镜像再跑任何批量任务。后续可以继续扩展的方向包括把 openJiuwen 接到私有代码库做自动化修复实验、基于它开发自己的 Agent 评测集、优化 prompt 模板提高通过率、尝试用本地部署的开源模型替代云端 API 以降低调用成本。如果想系统化提升编码 Agent 能力这个项目值得作为起点持续跟下去。