这次我们来看一个很有意思的研究项目Harness-of-Harness一个面向“多日自主软件开发”的框架思路。它强调的不是单轮对话里让 AI 写一段代码而是让 AI 像真正的工程师一样在几天时间里持续维护一个代码仓库完成需求迭代、bug 修复、测试补强和自我改进。如果你平时关注 AI 编程、Agent 开发、自动化测试或 DevOps 流水线这个方向非常值得花时间研究。先说这个项目最值得关注的点它把“带工具的 AI Agent”和“持续改进机制”结合起来核心卖点不是某一个模型有多强而是让多个 Agent 在长时间任务中不断反思、调整、优化自己的行为。换句话说它解决的是“AI 写代码能跑一次”到“AI 能长期维护项目”的跨越问题。这种能力对自动化需求拆分、自动生成 PR、自动补测试、自动回归验证都有明显价值。这篇文章会围绕 Harness-of-Harness 的思路展开实操性拆解它大概解决什么问题、需要什么样的运行环境、怎么理解它的工作流、如何搭建一个可复现的多日开发环境、如何验证持续改进效果、以及批量任务和接口接入的通用方案。由于该方向涉及具体模型权重、Agent 框架版本和评测指标如果没有提前声明本文给出的命令和配置都属于通用模板需要按实际项目路径替换。1. 核心能力速览Harness-of-Harness 不是一个单一的可执行文件更像一个“持续自主软件开发”的研究范式或框架。从标题和热词看它的核心关键词有三个多日Multi-Day、自主软件开发Autonomous Software Development、持续改进Continual Improvement。能力项说明项目定位面向多日周期的自主软件开发 Agent 框架/研究项目核心机制Agent 在跨天任务中通过反馈循环持续改进代码和策略主要功能自动需求理解、代码生成、测试执行、错误修复、自我反思、策略更新运行方式命令行启动通常需要配置 LLM API 或本地模型服务硬件要求取决于接入的模型纯文本 Agent 任务 CPU 也可跑本地大模型需要 GPU显存占用不确定需按实际模型版本测试常见 7B~70B 模型范围差异很大是否支持 API通常以 Python 库或 REST 服务方式暴露具体看实现版本是否支持批量任务支持多仓库、多任务队列但需要自行设计调度和去重适合场景研究实验、开源项目维护、自动化代码审查、回归测试、教学演示从材料来看这个项目更适合有一定 Python 基础、了解 LLM Agent 基本概念的开发者。如果你是第一次接触 AI 编程助手先跑通一个单次生成任务再进入“多日持续改进”会更容易理解。2. 适用场景与使用边界Harness-of-Harness 的应用场景可以分成三层第一层是自动化开发。给 Agent 一个 GitHub Issue 或需求描述让它自动修改代码、运行测试、生成提交信息。相比普通 Copilot 补全代码它能完成更长的任务链分析仓库结构、定位相关文件、修改多处代码、执行测试、根据失败信息继续修复。第二层是持续维护。这就是“多日”的核心。真实项目不是一次改完就结束而是会不断收到新需求、新 bug 报告。Harness-of-Harness 的思路是让 Agent 记住之前的经验和失败教训在后续任务中调整策略。比如第一天的某个测试总是失败第二天 Agent 会避开某种改法或者优先补充单元测试。第三层是质量保障。通过在环境中加入“运行时反馈”Agent 可以自动生成更多测试用例并用持续集成流水线验证结果。这对大型仓库的回归测试很有帮助能减少人工审核重复劳动。同样要注意使用边界不适合完全无人监督的生产环境Agent 的修改可能引入安全问题、依赖漏洞或逻辑错误必须配合人工 Code Review。不适合即时响应的低延迟场景多日自主开发通常要跑几十轮模型推理、测试命令不是秒级返回。需要合规授权如果你用 GitHub 上的真实仓库做实验要遵守仓库 License如果要让 Agent 修改私有代码或处理敏感业务数据先确认权限边界。不能绕开安全测试AI 生成的代码同样要做依赖安全检查、漏洞扫描、性能测试。另外涉及人物肖像、声音、隐私数据等敏感信息时本项目并不直接涉及但如果你在构造多日任务数据集不要使用未授权的个人数据。3. 本地部署环境准备Harness-of-Harness 的具体安装步骤需要以项目 README 为准这里给出一套通用检查清单适合大多数 Agent 类项目。3.1 操作系统与基础环境推荐使用 LinuxUbuntu 20.04 或 22.04或 macOSWindows 可通过 WSL2 运行。需要确保以下基础命令可用git --version python3 --version pip3 --version建议 Python 版本在 3.9 及以上但不要盲目装最新版本有些 Agent 框架对 3.12 的兼容性还不稳定。3.2 LLM 推理服务这是运行 Harness-of-Harness 的关键依赖。有两种方案使用云 API如 OpenAI、Anthropic 或其他兼容 OpenAI 格式的大模型 API。优点是部署简单适合快速验证框架流程。本地模型服务用 vLLM、Ollama、llama.cpp 等启动本地模型然后通过 OpenAI 兼容接口暴露给框架。本地部署需要确认 GPU 型号、显存大小、磁盘空间。例如一个 7B 模型量化后大约 4~6GBFP16 权重约 14GB70B 模型需要多张 24GB 显存显卡或者用 CPU 大内存跑低量化版本。建议先测试本地模型是否正常响应curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: your-model-name, messages: [{role: user, content: say hi}], temperature: 0.7 }3.3 工具链与沙箱自主软件开发意味着 Agent 会在你的环境里执行命令、修改文件、运行测试。强烈建议在 Docker 或独立虚拟机中运行防止误操作影响宿主机。至少准备以下内部依赖gitpython3-pipbuild-essentialdocker可选用于沙箱隔离jq解析 JSON 输出tree查看目录结构3.4 环境变量配置在项目根目录创建.env文件配置模型接口# 云 API 方式 LLM_API_KEYyour_api_key LLM_BASE_URLhttps://api.openai.com/v1 LLM_MODELgpt-4o-mini # 或者本地模型 LLM_BASE_URLhttp://127.0.0.1:8000/v1 LLM_MODELlocal-model LLM_API_KEYEMPTY具体变量名需要以项目代码为准。如果项目使用 LangChain、LlamaIndex 等框架还会有对应配置。4. 安装部署与启动方式4.1 克隆项目与安装依赖先把项目拉取下来git clone https://github.com/your-org/Harness-of-Harness.git cd Harness-of-Harness python3 -m venv venv source venv/bin/activate pip install -r requirements.txt如果项目没有写明具体依赖可以手动安装最常用的几个库pip install openai python-dotenv docker gitpython4.2 准备一个测试仓库Harness-of-Harness 需要目标仓库来执行任务。你可以创建一个本地测试仓库mkdir test-repo cd test-repo git init echo # Test Repo README.md git add . git commit -m init然后给 Agent 一个任务。任务格式通常是 markdown 文件或 JSON。4.3 启动一个开发周期假设项目入口类似run_harness.py启动示例python run_harness.py \ --repo-path ./test-repo \ --task ./tasks/task1.md \ --cycles 3 \ --output ./results参数说明--repo-path目标仓库路径。--task任务描述文件包含需求描述和验收标准。--cycles迭代轮次每轮跑完测试后进入下一轮改进。--output日志和结果输出目录。如果项目没有提供类似入口就需要自己写一个调度脚本来循环调用 Agent。4.4 日志监控启动后观察输出目录。每一轮迭代应该记录本轮生成的代码 diff执行的测试命令测试通过/失败情况Agent 的自我反思内容下一轮计划tail -f results/run.log5. 功能测试与效果验证要判断 Harness-of-Harness 是否跑通重点验证以下五个维度。5.1 任务理解测试给 Agent 一个明确但包含歧义的任务例如“给这个仓库添加一个计算斐波那契数列的函数并用 pytest 写测试。”看输出是否包含修改了哪个文件新增了哪个函数是否创建测试文件是否执行了 pytest如果 Agent 只输出代码但没有实际修改文件说明工具调用链路有问题。5.2 代码生成测试在测试仓库中放入一个已有的 Python 文件要求 Agent 添加新功能并确认原有功能不被破坏。python run_harness.py \ --repo-path ./test-repo \ --task 在 calculator.py 中新增乘法函数 multiply(a,b) \ --cycles 1成功后应看到calculator.py中出现multiply函数且git diff只包含预期修改。5.3 测试执行与修复循环这一步是“持续改进”的核心。给 Agent 一个会失败的测试用例看它能否从测试日志中提取报错信息并修复代码。典型流程Agent 修改源码Agent 运行pytest测试失败Agent 读取 tracebackAgent 定位到出错行修改代码重新运行测试直到通过可以从运行日志里检查是否出现两次及以上代码修改。如果只改了一次就通过说明任务太简单可以加大难度。5.4 多轮反思测试多日开发的本质是 Agent 能记住前一天的经验。在两轮任务之间检查它是否产生了类似“经验笔记”的文件并在第二轮调用这些经验。例如第一轮任务让 Agent 修改某个函数并故意在项目说明中记录“该模块禁止使用全局变量”。第二轮任务再让它修改同一个文件看它是否仍然使用全局变量。如果第二轮输出中引用了第一轮的经验文件说明持续改进机制生效。5.5 显存与资源观察如果你使用本地模型启动后观察 GPU 显存占用nvidia-smi观察点包括模型加载完成后显存占用生成长代码时是否触发显存溢出多轮连续推理后显存是否持续增长可能有内存泄漏显存占用需要以实际模型版本和推理参数为准不同量化方式差异很大不要照搬别人的数据。6. 接口 API 与批量任务Harness-of-Harness 如果要接入现有 CI/CD 或自动化平台通常需要封装成 API 服务。这里给出一套通用设计方案。6.1 简单 REST 服务使用 FastAPI 包装启动入口from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class TaskRequest(BaseModel): repo_path: str ./test-repo task: str fix the bug cycles: int 3 app.post(/run_task) def run_task(req: TaskRequest): # 这里调用 harness 的核心逻辑 result { task: req.task, cycles: req.cycles, status: started } return result启动服务uvicorn api_server:app --host 0.0.0.0 --port 8000注意如果服务运行在开放网络必须加鉴权。最简单的方式是配置静态 Tokenuvicorn api_server:app --host 0.0.0.0 --port 8000 --header Authorization:your_token更稳妥的做法是在代码里写依赖检查from fastapi import Header, HTTPException app.post(/run_task) def run_task(req: TaskRequest, authorization: str Header(None)): if authorization ! Bearer your_token: raise HTTPException(status_code401, detailunauthorized)6.2 批量任务队列多日开发往往对应多个仓库或多个 issue。可以写一个简单队列脚本顺序执行任务import subprocess import json tasks [ {repo_path: ./repo1, task: add login api, cycles: 2}, {repo_path: ./repo2, task: fix payment bug, cycles: 3}, ] for task in tasks: cmd [ python, run_harness.py, --repo-path, task[repo_path], --task, task[task], --cycles, str(task[cycles]), --output, f./results/{task[repo_path].strip(./)} ] result subprocess.run(cmd, capture_outputTrue, textTrue) with open(queue.log, a) as f: f.write(json.dumps({**task, returncode: result.returncode}) \n)6.3 失败重试建议批量任务长时间运行后可能遇到模型 API 限流、网络超时、仓库冲突。建议采用以下策略每个任务记录开始时间和结束时状态。超时任务自动标记失败不无限重试。失败任务最多重试 2 次重试前清空上一次的临时分支。使用单独的 git 分支执行每个任务避免并发修改主分支。7. 资源占用与性能观察运行 Harness-of-Harness 时资源消耗取决于三个部分LLM 推理、工具执行、日志存储。7.1 LLM 推理资源如果是云 API本机资源消耗较小主要占用网络带宽和内存。如果是本地模型显存占用直接受模型大小影响7B 量化模型通常可以在 6GB 显存量级运行但长上下文会显著增加显存。13B 模型建议 12GB 以上显存。70B 模型需要多卡或使用 CPU 内存跑低量化。实际占用需要通过nvidia-smi或nvtop观察同一模型在长代码生成时显存可能波动。7.2 工具执行资源Agent 会频繁调用 git、pytest 等命令。如果测试仓库较大编译型项目会占用大量 CPU 和磁盘。建议在容器内设置资源限制docker run --memory4g --cpus2 harness-runner7.3 如何降低资源占用使用小模型做初步验证让 Agent 先跑通流程再切换大模型。关闭日志中的 debug 输出减少磁盘写入。限制上下文长度不要把整个仓库都塞进 prompt而是让 Agent 自行 grep 关键文件。降低迭代轮次先跑 1~2 轮观察结果。7.4 端口与进程残留如果 API 服务或本地模型服务运行时间过长可能会出现端口占用。启动前检查lsof -i :8000结束残留进程kill -9 $(lsof -t -i :8000)如果使用 Jupyter 或 VS Code 调试注意保存任务上下文文件避免进程崩溃后丢失进度。8. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后报 ModuleNotFoundError缺少依赖或 Python 版本不匹配查看完整 traceback重新安装 requirements.txt切换 Python 3.10/3.11Agent 不修改文件只说“我修改了”工具调用返回格式错误查看模型输出原始 JSON检查工具的 FC 定义降低温度参数测试总是失败Agent 反复修复但不成功任务理解偏差或模型能力不足查看 agent 的反思日志任务拆小降低上下文重叠换更强的模型pytest 找不到模块路径配置错误在仓库内运行pytest复现调整工作目录修改系统路径或增加__init__.py显存溢出模型太大、上下文过长或并发推理观察 nvidia-smi 峰值显存降低上下文、使用量化模型、限制并发数API 调用超时网络问题或请求体过大curl 手动调用接口增大超时时间减少单次生成 tokens使用流式输出批量任务中途卡住某个子进程阻塞或等待用户输入查看进程树使用timeout命令给每个子进程限制运行时间提交代码到 git 后无法推送权限问题或分支冲突检查 remote 和本地分支配置 SSH key任务前先 pull 最新代码排查时优先看日志。Harness-of-Harness 这类框架的日志一般会区分三个层级模型调用日志、工具执行日志、内部决策日志。保存完整的 JSON 输出对定位问题很重要。9. 最佳实践与使用建议结合自主软件开发 Agent 的常见坑给出下面几条工程化建议。9.1 把任务写细让 Agent 有章可循多日任务不是一句话需求文档。要给 Agent 提供需求背景修改范围或文件列表验收标准例如“新增函数 x 必须传入 int”禁止事项例如“不要改动已有测试文件”任务文件建议采用 Markdown 或 YAML 格式存放在tasks/目录方便版本管理。9.2 先小参数跑通再上长时间任务第一次运行把 cycles 设为 1只测一个函数改动。确认工具链正常后再尝试跨天数任务。所谓“多日”不一定真的要跑 48 小时可以压缩成多轮迭代只要每一轮能记录经验并影响下一轮即可。9.3 用独立分支隔离 Agent 的修改不要在 main 分支直接让 Agent 提交。建议每次任务新建分支git checkout -b agent-task-$RANDOM任务结束后人工审核 diff再合并到主分支。9.4 给 Agent 留一个“经验库”持续改进的实现方式可以很简单在仓库里维护一个EXPERIENCE.md每轮任务结束后把关键失败原因和解决方案追加进去。后续任务开始时让 Agent 读取该文件。这比依赖隐式记忆更可靠。示例## 2025-01-01 - 任务修复登录接口 500 错误 - 失败原因未处理数据库空值 - 解决办法在查询结果返回后检查 None - 适用模块user/auth9.5 接口服务要限制访问范围如果你把 Harness-of-Harness 封装成 API 给团队用务必做三件事加身份验证、限制每用户并发任务数、设置单任务最大执行时间。否则一个误操作可能让整个服务卡死。9.6 涉及版权与合规如果要处理 GitHub 上的真实项目先确认许可证是否允许自动化修改和重新分发。如果 Agent 生成的代码要进入生产环境必须走安全扫描和人工 Review。涉及用户数据时禁止将真实数据直接上传到外部模型 API除非你确认数据合规边界。10. 总结与下一步Harness-of-Harness 最有价值的点不是让 AI 写一段漂亮代码而是让 AI 在“写出代码 - 测试失败 - 反思调整 - 继续修改”的长循环里逐步逼近真实研发流程。这个方向对自动化运维、持续集成、代码生成质量评估都有参考意义。建议你先从一个小仓库开始手动构造一个带错误的任务观察 Agent 能否自主完成修复循环。最容易踩的坑是任务描述含糊导致 Agent 反复修改无关代码所以第一轮实验一定要把验收标准写清楚。后续可以尝试的方向包括将 Agent 接入 GitHub Actions 实现夜间自动修复用本地模型配合量化推理降低运行成本或者增加“经验库”机制让 Agent 在多个仓库之间共享学习到的改法。如果你已经跑通了单轮任务建议直接进入多日模拟毕竟这个项目的核心就是持续改进。建议收藏备用后面研究多 Agent 协作时再回来看。