企业官网建设流程全解析

这次我们来看一个很有意思的研究项目：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）。

从材料来看，这个项目更适合有一定 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 操作系统与基础环境

推荐使用 Linux（Ubuntu 20.04 或 22.04）或 macOS，Windows 可通过 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~6GB，FP16 权重约 14GB；70B 模型需要多张 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 或独立虚拟机中运行，防止误操作影响宿主机。

至少准备以下内部依赖：

• git
• python3-pip
• build-essential
• docker（可选，用于沙箱隔离）
• jq（解析 JSON 输出）
• tree（查看目录结构）

3.4 环境变量配置

在项目根目录创建.env文件，配置模型接口：

# 云 API 方式 LLM_API_KEY=your_api_key LLM_BASE_URL=https://api.openai.com/v1 LLM_MODEL=gpt-4o-mini # 或者本地模型 LLM_BASE_URL=http://127.0.0.1:8000/v1 LLM_MODEL=local-model LLM_API_KEY=EMPTY

具体变量名需要以项目代码为准。如果项目使用 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 gitpython

4.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.log

5. 功能测试与效果验证

要判断 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 一个会失败的测试用例，看它能否从测试日志中提取报错信息并修复代码。

典型流程：

1. Agent 修改源码
2. Agent 运行pytest
3. 测试失败，Agent 读取 traceback
4. Agent 定位到出错行，修改代码
5. 重新运行测试直到通过

可以从运行日志里检查是否出现两次及以上代码修改。如果只改了一次就通过，说明任务太简单，可以加大难度。

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

注意，如果服务运行在开放网络，必须加鉴权。最简单的方式是配置静态 Token：

uvicorn 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_code=401, detail="unauthorized")

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_output=True, text=True) with open("queue.log", "a") as f: f.write(json.dumps({**task, "returncode": result.returncode}) + "\n")

6.3 失败重试建议

批量任务长时间运行后，可能遇到模型 API 限流、网络超时、仓库冲突。建议采用以下策略：

1. 每个任务记录开始时间和结束时状态。
2. 超时任务自动标记失败，不无限重试。
3. 失败任务最多重试 2 次，重试前清空上一次的临时分支。
4. 使用单独的 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 --memory=4g --cpus=2 harness-runner

7.3 如何降低资源占用

• 使用小模型做初步验证，让 Agent 先跑通流程，再切换大模型。
• 关闭日志中的 debug 输出，减少磁盘写入。
• 限制上下文长度，不要把整个仓库都塞进 prompt，而是让 Agent 自行 grep 关键文件。
• 降低迭代轮次，先跑 1~2 轮观察结果。

7.4 端口与进程残留

如果 API 服务或本地模型服务运行时间过长，可能会出现端口占用。启动前检查：

lsof -i :8000

结束残留进程：

kill -9 $(lsof -t -i :8000)

如果使用 Jupyter 或 VS Code 调试，注意保存任务上下文文件，避免进程崩溃后丢失进度。

8. 常见问题与排查方法

排查时优先看日志。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/auth

9.5 接口服务要限制访问范围

如果你把 Harness-of-Harness 封装成 API 给团队用，务必做三件事：加身份验证、限制每用户并发任务数、设置单任务最大执行时间。否则一个误操作可能让整个服务卡死。

9.6 涉及版权与合规

如果要处理 GitHub 上的真实项目，先确认许可证是否允许自动化修改和重新分发。如果 Agent 生成的代码要进入生产环境，必须走安全扫描和人工 Review。涉及用户数据时，禁止将真实数据直接上传到外部模型 API，除非你确认数据合规边界。

10. 总结与下一步

Harness-of-Harness 最有价值的点，不是让 AI 写一段漂亮代码，而是让 AI 在“写出代码 -> 测试失败 -> 反思调整 -> 继续修改”的长循环里逐步逼近真实研发流程。这个方向对自动化运维、持续集成、代码生成质量评估都有参考意义。

建议你先从一个小仓库开始，手动构造一个带错误的任务，观察 Agent 能否自主完成修复循环。最容易踩的坑是任务描述含糊导致 Agent 反复修改无关代码，所以第一轮实验一定要把验收标准写清楚。

后续可以尝试的方向包括：将 Agent 接入 GitHub Actions 实现夜间自动修复；用本地模型配合量化推理降低运行成本；或者增加“经验库”机制，让 Agent 在多个仓库之间共享学习到的改法。如果你已经跑通了单轮任务，建议直接进入多日模拟，毕竟这个项目的核心就是持续改进。建议收藏备用，后面研究多 Agent 协作时再回来看。