这次我们来看一个偏研究向的 AI 智能体项目Harness-of-Harness: Multi-Day Autonomous Software Development with Continual Improvement。从项目标题就能看出这个工作的重点不是“让模型写一段代码”而是把 AI 软件开发从“单次生成”推进到“多日自主运行”的状态。它描述了一套以持续改进为核心的自动化软件开发框架智能体可以跨天运行通过任务执行积累经验再把这些经验反馈到后续任务里形成一条完整的自优化循环。不管你是做 AI Agent 应用开发还是做 LLM 工程化的落地或者正在研究“大模型如何稳定完成长周期任务”这个项目都值得花时间拆解一遍。这篇文章会围绕项目实现的核心机制、部署运行思路、任务编排方式、效果验证路径以及常见踩坑点展开尽量让读者看完之后能判断这类“多日自主开发”框架到底适合什么场景怎么把它跑起来又该怎么评估它是否真的在变强。1. 核心能力速览能力项说明项目类型AI 智能体 / 自主软件开发框架核心方向多日持续运行的 autonomous software development关键机制Continual Improvement即从历史任务中持续学习并优化后续行为主要功能任务拆解、代码编写、命令执行、测试验证、经验积累、跨任务复用运行模式以 Agent 循环为主支持长时间、多轮次任务执行大模型接入常见方案支持 OpenAI API 或本地 LLM 服务具体以项目文档为准推荐环境Linux 服务器 / 高性能开发机建议具备 Docker 或沙箱环境显存需求取决于接入的模型规格若使用 API 模式则本机显存压力较低启动方式命令行启动 / 配置文件驱动暂不确定是否提供一键 WebUI是否支持 API多数同类型框架会暴露任务提交接口但本文不编造具体路径需按项目实际文档确认是否支持批量任务支持以任务队列方式调度多项开发任务具体容量需实测适合场景研究实验、自动化代码修复、长期维护型任务、Agent 自我改进方向验证以上表格是站在通用立场归纳的能力视角。如果项目仓库已提供更精确的表格、版本号或脚本请以实际文档为准。2. 适用场景与使用边界这类项目的价值是把“大模型写代码”升级为“大模型长时间自主维护代码”。这对特定场景很有用但也不是万能的。适合的场景包括夜间自动修复积压的 issue把一批简单 bug 按优先级排入任务队列由智能体在无人值守时逐个尝试修复并提交 MR。自动化重构辅助对指定模块做重命名、拆分、调整接口签名等重复性改动智能体可以批量处理并运行测试。研究 Agent 长期记忆机制观察模型在多轮任务后是否能积累项目级上下文并减少重复犯错。CI 流水线失败自动分析拿到失败日志后智能体自动定位代码位置并提出修复方案。不合适的场景同样要讲清楚高复杂度架构设计跨模块、跨团队的政治性技术决策目前模型难以独立完成。涉及生产环境直接修改没有沙箱保护时让智能体直接操作生产库或线上服务器风险极高。需要强业务判断的需求验收模型不太理解“这个按钮应该放在哪更符合用户体验”这类主观判断。对外交付硬性承诺自主开发结果仍需人工复核不能直接把 Agent 输出作为最终交付物。使用边界方面必须强调几点。代码生成类 Agent 会执行命令要尽量放在 Docker 容器或隔离虚拟机里运行防止恶意依赖或异常命令影响宿主机。涉及读取私有仓库、访问云端 API、修改认证信息时要确保已获得明确授权。如果开发过程中涉及人脸、声音、肖像、版权素材等敏感数据必须确认在合规前提下使用。智能体的输出内容、日志信息、生成代码都可能保留模型训练数据的模式商用前要做版权与合规审查。3. Harness-of-Harness 本地部署环境准备虽然我们还没有拿到完整仓库的安装脚本但按照同类“多日自主软件开发 Agent”框架的通用部署实践环境准备可以从这几块入手。3.1 操作系统与硬件推荐使用 Linux 环境Ubuntu 22.04 或更新版本是稳妥选择。Windows 本地开发建议通过 WSL 2 或 Docker Desktop 来模拟 Linux 环境避免命令兼容性问题。硬件方面如果计划接入云端大模型 API那么本机只需要一个能跑 Agent 循环的 CPU 开发机内存 16GB 起步磁盘预留 50GB 以上用于代码仓库、运行日志和虚拟环境文件。如果计划本地部署 7B 到 14B 规模的开源模型建议至少准备一张 24GB 显存的显卡如果是 70B 以上模型则需要多卡或量化方案。显存需求不写死以实际运行的模型规格为准。3.2 软件依赖通用的依赖项包括Git用于拉取代码和提交变更。Python 3.10 或更高版本多数 Agent 框架会基于 Python 编写。pip 和虚拟环境工具venv / conda用于隔离依赖。Docker 或 Podman用于创建隔离的任务执行沙箱。Node.js部分项目前端或脚本工具链需要。Git LFS如果仓库中包含大文件。CUDA / cuDNN / PyTorch仅本地推理时需要。安装基础工具的命令模板如下# Ubuntu / Debian 基础依赖示例 sudo apt update sudo apt install -y git curl wget python3 python3-venv python3-pip docker.io # 启动 Docker 并设置当前用户权限 sudo systemctl enable --now docker sudo usermod -aG docker $USER newgrp docker3.3 模型服务与 API 密钥如果使用 OpenAI 风格接口需要准备 API Key 并配置环境变量。本地部署开源模型时可以使用 vLLM、Ollama 或 llama.cpp 启动一个 OpenAI 兼容服务。模型服务的地址通常是http://127.0.0.1:8000/v1具体端口需要按实际启动方式确认。环境变量通用示例export OPENAI_API_KEYyour-api-key export OPENAI_BASE_URLhttps://api.example.com/v1 export AGENT_WORKSPACE/data/agent_workspace export AGENT_LOG_LEVELINFO需要注意OpenAI API Key 属于敏感凭证不要写进 Git 仓库或分享到公开笔记中。3.4 工作目录规划长期运行的 Agent 会产生大量中间文件建议按以下结构组织目录/agent_root/ ├── config/ # 项目配置文件 ├── repos/ # 克隆下来的目标代码仓库 ├── tasks/ # 任务描述文件 ├── logs/ # 运行日志与审计记录 ├── outputs/ # 最终产物与补丁文件 └── memory/ # 跨任务经验存储将输入、输出、日志分开存放后面的批量任务和问题排查都会轻松很多。4. 安装部署与启动方式这里给出一套通用的部署流程具体命令要以项目仓库的 README 或安装脚本为准。4.1 安装依赖# 克隆项目 git clone https://github.com/example/harness-of-harness.git cd harness-of-harness # 创建虚拟环境 python3 -m venv venv source venv/bin/activate # 安装依赖具体以 requirements.txt 或 pyproject.toml 为准 pip install -r requirements.txt如果项目提供 Docker 镜像推荐直接使用容器方式运行依赖隔离更彻底# 构建镜像 docker build -t harness-of-harness . # 运行容器挂载工作目录 docker run -it --rm \ -v $(pwd)/config:/app/config \ -v $(pwd)/tasks:/app/tasks \ -v $(pwd)/outputs:/app/outputs \ -e OPENAI_API_KEYyour-api-key \ harness-of-harness --config /app/config/config.yaml4.2 配置文件示例多数 Agent 框架会采用 YAML 配置文件来声明任务和运行参数。这里给出一个通用模板字段需要按真实项目做调整# config.yaml 示例字段名需按实际项目文档修改 agent: model: gpt-4o temperature: 0.2 max_iterations: 50 timeout_seconds: 3600 workspace: repo_dir: ./repos/my-project memory_dir: ./memory output_dir: ./outputs task: entry_file: ./tasks/task_001.md auto_commit: false run_tests: true test_command: pytest -x -q sandbox: enabled: true use_docker: true container_name: agent-task-runner logging: level: INFO file: ./logs/agent.log需要注意auto_commit建议先设为false等确认 Agent 生成的代码逻辑正确后再开启自动提交。4.3 启动服务# 命令行启动示例实际参数必须参考项目文档 python main.py --config config/config.yaml --task tasks/task_001.md如果服务支持常驻模式或 WebUI启动后通常会有如下提示控制台输出任务执行进度。生成日志文件agent.log。在outputs目录写入补丁文件或修改后的代码。如果项目提供了可视化界面访问地址通常是http://127.0.0.1:7860或类似端口但这里不编造以实际项目输出为准。5. 功能测试与效果验证跑通启动只是第一步重点是验证这套“多日自主开发 持续改进”的框架是否真的有效。下面给出一套通用测试流程可以用于评估同类 Agent 框架。5.1 基础任务测试简单 Bug 修复测试项内容测试目的确认 Agent 能完成最基本的代码修改任务输入素材一个小型 Python 项目包含一个可复现的 bug任务描述修复calculate_average函数在空列表时的除零错误预期结果生成代码补丁并通过项目既有测试判断标准运行 pytest 全部通过代码 diff 最小化操作步骤准备一个最小的 Python 项目包含buggy.py和test_buggy.py。把任务描述写入tasks/task_001.md。启动 Agent让它运行到任务完成。检查outputs目录中的 diff 文件。# 在任务运行后查看生成的补丁 git diff --stat cat outputs/task_001.diff如果 Agent 能在 10 到 30 分钟内完成这个简单修复说明基本链路是通的。如果长时间卡住优先检查模型 API 的响应速度、上下文长度是否超限以及沙箱环境是否能正常执行测试命令。5.2 多轮任务测试连续修复多个 Issue这类框架的核心卖点就是长周期运行所以必须测多任务连续执行能力。任务设计在同一个代码仓库中预埋 5 个不同难度的 bug。分别写成 5 个独立任务文件。观察 Agent 是否能在串行或并行模式下逐个处理。记录每个任务的处理时长、成功率和上下文切换成本。一个简单轮询脚本可以帮助追踪任务状态import time from pathlib import Path task_dir Path(./tasks) output_dir Path(./outputs) while True: for task_file in sorted(task_dir.glob(*.md)): output_file output_dir / f{task_file.stem}.result.json if output_file.exists(): print(f[DONE] {task_file.name}) else: print(f[PENDING] {task_file.name}) time.sleep(60)从实际材料来看多日运行的框架必须重点解决“任务间上下文污染”和“长期记忆一致性”两个问题。所以在测试中要特别观察第 5 个任务是否还记得第 1 个任务里约定好的代码风格是否会在不相关的任务里错误复用之前的解决方案长时间运行后日志和 memory 目录是否会产生大量冗余经验5.3 持续改进能力测试对比前后轮次表现continual improvement 是这个项目的重要关键词测试时要有对照实验。实验设计第一轮让 Agent 从零开始修复 5 个 issue记录成功率、平均耗时、测试通过率。第二轮同一组 issue 重新执行但在运行前保留第一轮的 memory 和总结经验文件。第三轮继续保留前两轮的经验再执行同样任务。判断标准第二轮和第三轮的修复速度是否提升重复犯错次数是否下降Agent 是否能主动复用第一轮总结的“如何运行测试”“如何定位 bug”等信息如果三轮测试结果差异不大说明该框架的 continued improvement 机制没有真正生效或者经验读取逻辑存在设计缺陷。这是评估本项目时最关键的实验维度。5.4 稳定性测试长时间无人值守运行长周期任务的最大风险是“跑着跑着就坏了”。稳定性测试要覆盖以下维度维度测试方式API 断连中断网络 2 分钟观察 Agent 是否能自动重试上下文超长连续执行 20 个以上长任务观察是否超出模型上下文限制沙箱崩溃手动重启 Docker 容器观察任务状态是否能恢复日志爆炸长时间运行时检查日志文件是否占用过多磁盘内存泄漏使用htop或free -h监控内存占用趋势# 后台运行 Agent 并记录日志 nohup python main.py --config config/config.yaml --task tasks/task_001.md logs/task_001.log 21 # 监控资源占用 watch -n 10 free -h df -h ps aux | grep python main.py | grep -v grep如果任务在某个环节卡死需要给 Agent 设置总超时时间并开启失败重试机制。一次性任务卡死超过 2 小时的多半是上下文碎片化或沙箱执行异常而不是模型能力不够。6. 接口 API 与批量任务这类框架通常会把任务提交、状态查询、结果获取暴露成 API 服务。虽然当前输入材料没有给出具体接口路径但按通用实践可以设计如下调度流程。6.1 批量任务队列设计一个可行的任务队列结构如下{ tasks: [ { task_id: TASK-001, repo_url: https://github.com/example/demo-repo.git, description: Fix division by zero in calculate_average, priority: high, max_attempts: 3 }, { task_id: TASK-002, repo_url: https://github.com/example/demo-repo.git, description: Update README with new API usage, priority: medium, max_attempts: 2 } ] }批量任务的关键设计点包括任务级别超时、失败重试上限、输出文件命名规范、日志与任务 ID 的一一对应。一个通用的批量调度伪代码import time import requests API_BASE http://127.0.0.1:8080 HEADERS {Authorization: Bearer your-token} def submit_task(task): resp requests.post(f{API_BASE}/tasks, jsontask, headersHEADERS, timeout30) return resp.json()[task_id] def wait_for_task(task_id, timeout7200): start time.time() while time.time() - start timeout: resp requests.get(f{API_BASE}/tasks/{task_id}, headersHEADERS, timeout30) if resp.json()[status] in [succeeded, failed]: return resp.json() time.sleep(30) return {status: timeout, task_id: task_id} # 批量提交任务并等待结果 for task in task_list: task_id submit_task(task) result wait_for_task(task_id) print(task_id, result[status]) if result[status] failed: # 记录失败任务稍后重试 failed_tasks.append(task)注意真实项目的 API 路径、鉴权方式、字段命名都需要以项目文档为准。上面这段代码是通用的机器人调度模板不能直接当成目标项目的 API 用法。6.2 curl 调用示例# 提交任务 curl -X POST http://127.0.0.1:8080/tasks \ -H Content-Type: application/json \ -d { repo_url: https://github.com/example/demo-repo.git, description: Fix failing unit test in test_parser.py }如果接口服务需要鉴权请自行添加Authorization头。默认情况下不要让 API 服务监听公网地址只绑定内网或本机地址。6.3 批量任务的失败重试策略批量任务一定会遇到失败建议采用以下策略每个任务最多重试 3 次达到上限后标记为failed。重试前清理上一次运行产生的临时目录。使用指数退避控制重试频率第一次等待 30 秒第二次 5 分钟第三次 30 分钟。将失败任务单独写入failed_tasks.json方便后续人工分析和重新入队。7. 资源占用与性能观察对于长周期 Agent 框架资源占用观察不像图像生成那样只看一张卡的显存而是要同时关注进程、网络、磁盘和模型服务吞吐。7.1 本机 Agent 进程资源Agent 框架本身属于轻量级应用主要资源消耗在网络请求和沙箱容器上。CPU 占用不会太高除非进行代码解析或向量化索引。观察命令# 查看 Agent 进程 ps aux --sort-%mem | grep -E python|node|java | grep -v grep # 查看 Docker 容器资源占用 docker stats --no-stream如果发现 Docker 容器数量不断增加但无法自动回收需要调整沙箱生命周期管理策略。7.2 模型推理资源本地模型推理时显存占用主要取决于模型参数量、量化方式和上下文长度。7B 模型在 FP16 精度下通常需要约 14GB 显存采用 4-bit 量化后约 6GB 到 8GB但这只是大致的工程经验不同模型架构差异很大。观察方式# 查看 GPU 显存占用 nvidia-smi # 每 5 秒刷新一次 watch -n 5 nvidia-smi如果使用云端 API 模式本机显存压力会小很多但需要关注 API 请求频率和 token 消耗。长周期任务的 token 消耗是一个容易忽视的成本项。7.3 上下文窗口的影响多日运行最大的性能瓶颈往往不是 GPU而是上下文窗口。任务执行时间越长积累的对话历史越多继续新增任务时可能会出现上下文截断导致逻辑丢失。token 消耗呈线性甚至超线性增长。模型响应速度变慢。解决办法包括定期清理不重要的中间对话将关键经验抽取为结构化记忆并压缩到独立文件中只在需要时重新加载而不是一直保留在上下文中。7.4 降低资源占用的建议目标建议降低显存使用量化模型、限制并发任务数、缩短单次上下文长度降低 token 消耗关闭过多工具的冗长输出设置日志只保留摘要降低磁盘占用定期清理旧容器、旧日志、临时补丁文件降低 API 延迟增加重试与超时配置避免同一请求重复发送8. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后任务一直不执行模型 API 配置错误或网络不通查看启动日志检查 API 链接和 Key修复环境变量确认能直接调用模型服务Agent 频繁重复同一操作上下文超出窗口或状态未保存查看日志中工具调用序列清理上下文开启状态持久化Docker 沙箱启动失败容器镜像不存在或权限不足运行docker ps查看错误日志重新拉取镜像检查当前用户 Docker 权限生成的代码无法通过测试模型对项目结构理解不足检查是否提供了足够的项目上下文在任务描述中补充项目结构说明长时间运行后内存持续增长存在内存泄漏或日志积累使用free -h监控趋势增加定时清理与重启策略多日运行后任务结果质量下降记忆库膨胀或经验冲突检查 memory 目录中的总结文件手动清理低质量经验重写关键规则任务执行过程中断网网络异常导致 API 请求失败查看错误日志中的超时记录增加请求重试和任务断点恢复机制API 服务端口被占用已有进程监听同一端口lsof -i :8080查看占用进程更换端口或终止旧进程从实际材料来看最容易踩的坑是三块一是没有单独分配沙箱环境导致 Agent 执行命令时污染宿主机二是没有给任务设置总的超时时间遇到循环调用会无限耗下去三是没有做经验库版本管理多日运行后旧经验和新任务互相打架。9. 最佳实践与使用建议把这类多日自主开发框架真正用到项目里有一些工程经验值得提前沉淀下来。9.1 第一次跑通不要追求复杂先拿一个小仓库、一个简单 bug、一个明确任务去验证链路。不要一上来就把整个微服务仓库丢给 Agent 去重构。最小化验证路径跑通后再逐渐加大任务复杂度。9.2 任务描述要像给新同事写说明Agent 没有你脑子里的项目背景任务描述里最好包含这些信息仓库位置、涉及文件、期望行为、验收标准、禁止触碰的模块。任务描述写得越具体成功率越高。一个高质量任务描述的模板## 任务目标 修复 src/calculator.py 中 divide 方法在除数为 0 时崩溃的问题。 ## 背景 divide 方法当前使用 Python 默认的 ZeroDivisionError 异常 会导致 API 返回 500。项目希望返回 400 和友好提示信息。 ## 验收标准 1. 调用 divide(1, 0) 返回 None 并记录一条警告日志。 2. 现有单元测试全部通过。 3. 不修改 src/api.py 中的任何内容。 ## 参考信息 - 相关测试文件tests/test_calculator.py - 错误日志样本见 logs/error_sample.log9.3 经验库要人工干预持续改进机制不是“跑得越久越好”。每周或每轮任务结束后建议人工检查一遍 memory 目录中的总结文件删除那些错误、过时或过于具体的经验条目。保留一套核心规则比如“项目使用 pytest 而非 unittest”“不要修改 database.py”等帮助 Agent 少走弯路。9.4 命令执行必须在沙箱里凡是涉及代码执行的任务一定要放在 Docker 容器中运行。不要在工作目录里直接用宿主机 Python 执行 Agent 生成的代码。容器可以放心恢复快照而宿主机一旦被装了恶意依赖清理成本会非常高。9.5 日志保留与任务 ID 关联日志命名建议包含任务 ID例如logs/task_001_execution.log。批处理时将每轮任务的状态记录到results.csv中方便对比不同版本模型、不同 prompt 策略的成功率。task_id,status,attempts,tokens_used,duration_seconds,test_result TASK-001,passed,1,15230,1240,pytest: 12 passed TASK-002,failed,3,40600,5380,pytest: 2 failed9.6 合规与安全红线虽然智能体能自动开发但使用者和部署者必须承担最终责任。涉及私有代码、用户数据、生成内容的场景要遵守相关法律法规与授权要求。不要向 Agent 暴露真实生产环境的数据库密码、云服务密钥或个人敏感信息。如果 Agent 会读取人脸图像、声音样本等数据务必确认已获得相关权利人的明确授权并在符合隐私保护规范的前提下使用。所有自动生成的代码在合入主干前都要经过人工 code review。10. 总结与下一步Harness-of-Harness 这个项目最值得关注的地方不是它能把单次任务完成得有多好而是它把“持续运行”和“持续改进”这两个问题正式地放到了自动驾驶软件开发框架的设计核心位置。对做 Agent 应用开发的人来说这套设计思路有直接的借鉴价值经验如何沉淀、任务如何拆解、多日运行如何保持稳定都是真实的工程痛点。如果你准备上手实验建议第一步先验证基础链路准备一个小型仓库给一个简单 issue让 Agent 串行跑 5 个任务记录每轮的成功率和耗时。第二步再启动多日运行测试重点观察 memory 目录的增长和任务质量的变化。最容易踩的坑就是沙箱隔离不到位、任务没有总超时、经验库没有清理机制这三个问题建议在首次运行前就解决。后续可以沿着这几个方向继续扩展接入本地开源模型做私有化部署、把任务队列接到 CI/CD 流水线里、对记忆模块做向量化检索、以及设计更细粒度的“经验质量评分”来控制持续改进的方向。这个领域还在快速演进把一套任务跑通只是开始真正有价值的部分是观察它能否在长周期里稳定地越用越好。
多日自主软件开发框架解析：AI智能体的持续改进与工程实践
这次我们来看一个偏研究向的 AI 智能体项目Harness-of-Harness: Multi-Day Autonomous Software Development with Continual Improvement。从项目标题就能看出这个工作的重点不是“让模型写一段代码”而是把 AI 软件开发从“单次生成”推进到“多日自主运行”的状态。它描述了一套以持续改进为核心的自动化软件开发框架智能体可以跨天运行通过任务执行积累经验再把这些经验反馈到后续任务里形成一条完整的自优化循环。不管你是做 AI Agent 应用开发还是做 LLM 工程化的落地或者正在研究“大模型如何稳定完成长周期任务”这个项目都值得花时间拆解一遍。这篇文章会围绕项目实现的核心机制、部署运行思路、任务编排方式、效果验证路径以及常见踩坑点展开尽量让读者看完之后能判断这类“多日自主开发”框架到底适合什么场景怎么把它跑起来又该怎么评估它是否真的在变强。1. 核心能力速览能力项说明项目类型AI 智能体 / 自主软件开发框架核心方向多日持续运行的 autonomous software development关键机制Continual Improvement即从历史任务中持续学习并优化后续行为主要功能任务拆解、代码编写、命令执行、测试验证、经验积累、跨任务复用运行模式以 Agent 循环为主支持长时间、多轮次任务执行大模型接入常见方案支持 OpenAI API 或本地 LLM 服务具体以项目文档为准推荐环境Linux 服务器 / 高性能开发机建议具备 Docker 或沙箱环境显存需求取决于接入的模型规格若使用 API 模式则本机显存压力较低启动方式命令行启动 / 配置文件驱动暂不确定是否提供一键 WebUI是否支持 API多数同类型框架会暴露任务提交接口但本文不编造具体路径需按项目实际文档确认是否支持批量任务支持以任务队列方式调度多项开发任务具体容量需实测适合场景研究实验、自动化代码修复、长期维护型任务、Agent 自我改进方向验证以上表格是站在通用立场归纳的能力视角。如果项目仓库已提供更精确的表格、版本号或脚本请以实际文档为准。2. 适用场景与使用边界这类项目的价值是把“大模型写代码”升级为“大模型长时间自主维护代码”。这对特定场景很有用但也不是万能的。适合的场景包括夜间自动修复积压的 issue把一批简单 bug 按优先级排入任务队列由智能体在无人值守时逐个尝试修复并提交 MR。自动化重构辅助对指定模块做重命名、拆分、调整接口签名等重复性改动智能体可以批量处理并运行测试。研究 Agent 长期记忆机制观察模型在多轮任务后是否能积累项目级上下文并减少重复犯错。CI 流水线失败自动分析拿到失败日志后智能体自动定位代码位置并提出修复方案。不合适的场景同样要讲清楚高复杂度架构设计跨模块、跨团队的政治性技术决策目前模型难以独立完成。涉及生产环境直接修改没有沙箱保护时让智能体直接操作生产库或线上服务器风险极高。需要强业务判断的需求验收模型不太理解“这个按钮应该放在哪更符合用户体验”这类主观判断。对外交付硬性承诺自主开发结果仍需人工复核不能直接把 Agent 输出作为最终交付物。使用边界方面必须强调几点。代码生成类 Agent 会执行命令要尽量放在 Docker 容器或隔离虚拟机里运行防止恶意依赖或异常命令影响宿主机。涉及读取私有仓库、访问云端 API、修改认证信息时要确保已获得明确授权。如果开发过程中涉及人脸、声音、肖像、版权素材等敏感数据必须确认在合规前提下使用。智能体的输出内容、日志信息、生成代码都可能保留模型训练数据的模式商用前要做版权与合规审查。3. Harness-of-Harness 本地部署环境准备虽然我们还没有拿到完整仓库的安装脚本但按照同类“多日自主软件开发 Agent”框架的通用部署实践环境准备可以从这几块入手。3.1 操作系统与硬件推荐使用 Linux 环境Ubuntu 22.04 或更新版本是稳妥选择。Windows 本地开发建议通过 WSL 2 或 Docker Desktop 来模拟 Linux 环境避免命令兼容性问题。硬件方面如果计划接入云端大模型 API那么本机只需要一个能跑 Agent 循环的 CPU 开发机内存 16GB 起步磁盘预留 50GB 以上用于代码仓库、运行日志和虚拟环境文件。如果计划本地部署 7B 到 14B 规模的开源模型建议至少准备一张 24GB 显存的显卡如果是 70B 以上模型则需要多卡或量化方案。显存需求不写死以实际运行的模型规格为准。3.2 软件依赖通用的依赖项包括Git用于拉取代码和提交变更。Python 3.10 或更高版本多数 Agent 框架会基于 Python 编写。pip 和虚拟环境工具venv / conda用于隔离依赖。Docker 或 Podman用于创建隔离的任务执行沙箱。Node.js部分项目前端或脚本工具链需要。Git LFS如果仓库中包含大文件。CUDA / cuDNN / PyTorch仅本地推理时需要。安装基础工具的命令模板如下# Ubuntu / Debian 基础依赖示例 sudo apt update sudo apt install -y git curl wget python3 python3-venv python3-pip docker.io # 启动 Docker 并设置当前用户权限 sudo systemctl enable --now docker sudo usermod -aG docker $USER newgrp docker3.3 模型服务与 API 密钥如果使用 OpenAI 风格接口需要准备 API Key 并配置环境变量。本地部署开源模型时可以使用 vLLM、Ollama 或 llama.cpp 启动一个 OpenAI 兼容服务。模型服务的地址通常是http://127.0.0.1:8000/v1具体端口需要按实际启动方式确认。环境变量通用示例export OPENAI_API_KEYyour-api-key export OPENAI_BASE_URLhttps://api.example.com/v1 export AGENT_WORKSPACE/data/agent_workspace export AGENT_LOG_LEVELINFO需要注意OpenAI API Key 属于敏感凭证不要写进 Git 仓库或分享到公开笔记中。3.4 工作目录规划长期运行的 Agent 会产生大量中间文件建议按以下结构组织目录/agent_root/ ├── config/ # 项目配置文件 ├── repos/ # 克隆下来的目标代码仓库 ├── tasks/ # 任务描述文件 ├── logs/ # 运行日志与审计记录 ├── outputs/ # 最终产物与补丁文件 └── memory/ # 跨任务经验存储将输入、输出、日志分开存放后面的批量任务和问题排查都会轻松很多。4. 安装部署与启动方式这里给出一套通用的部署流程具体命令要以项目仓库的 README 或安装脚本为准。4.1 安装依赖# 克隆项目 git clone https://github.com/example/harness-of-harness.git cd harness-of-harness # 创建虚拟环境 python3 -m venv venv source venv/bin/activate # 安装依赖具体以 requirements.txt 或 pyproject.toml 为准 pip install -r requirements.txt如果项目提供 Docker 镜像推荐直接使用容器方式运行依赖隔离更彻底# 构建镜像 docker build -t harness-of-harness . # 运行容器挂载工作目录 docker run -it --rm \ -v $(pwd)/config:/app/config \ -v $(pwd)/tasks:/app/tasks \ -v $(pwd)/outputs:/app/outputs \ -e OPENAI_API_KEYyour-api-key \ harness-of-harness --config /app/config/config.yaml4.2 配置文件示例多数 Agent 框架会采用 YAML 配置文件来声明任务和运行参数。这里给出一个通用模板字段需要按真实项目做调整# config.yaml 示例字段名需按实际项目文档修改 agent: model: gpt-4o temperature: 0.2 max_iterations: 50 timeout_seconds: 3600 workspace: repo_dir: ./repos/my-project memory_dir: ./memory output_dir: ./outputs task: entry_file: ./tasks/task_001.md auto_commit: false run_tests: true test_command: pytest -x -q sandbox: enabled: true use_docker: true container_name: agent-task-runner logging: level: INFO file: ./logs/agent.log需要注意auto_commit建议先设为false等确认 Agent 生成的代码逻辑正确后再开启自动提交。4.3 启动服务# 命令行启动示例实际参数必须参考项目文档 python main.py --config config/config.yaml --task tasks/task_001.md如果服务支持常驻模式或 WebUI启动后通常会有如下提示控制台输出任务执行进度。生成日志文件agent.log。在outputs目录写入补丁文件或修改后的代码。如果项目提供了可视化界面访问地址通常是http://127.0.0.1:7860或类似端口但这里不编造以实际项目输出为准。5. 功能测试与效果验证跑通启动只是第一步重点是验证这套“多日自主开发 持续改进”的框架是否真的有效。下面给出一套通用测试流程可以用于评估同类 Agent 框架。5.1 基础任务测试简单 Bug 修复测试项内容测试目的确认 Agent 能完成最基本的代码修改任务输入素材一个小型 Python 项目包含一个可复现的 bug任务描述修复calculate_average函数在空列表时的除零错误预期结果生成代码补丁并通过项目既有测试判断标准运行 pytest 全部通过代码 diff 最小化操作步骤准备一个最小的 Python 项目包含buggy.py和test_buggy.py。把任务描述写入tasks/task_001.md。启动 Agent让它运行到任务完成。检查outputs目录中的 diff 文件。# 在任务运行后查看生成的补丁 git diff --stat cat outputs/task_001.diff如果 Agent 能在 10 到 30 分钟内完成这个简单修复说明基本链路是通的。如果长时间卡住优先检查模型 API 的响应速度、上下文长度是否超限以及沙箱环境是否能正常执行测试命令。5.2 多轮任务测试连续修复多个 Issue这类框架的核心卖点就是长周期运行所以必须测多任务连续执行能力。任务设计在同一个代码仓库中预埋 5 个不同难度的 bug。分别写成 5 个独立任务文件。观察 Agent 是否能在串行或并行模式下逐个处理。记录每个任务的处理时长、成功率和上下文切换成本。一个简单轮询脚本可以帮助追踪任务状态import time from pathlib import Path task_dir Path(./tasks) output_dir Path(./outputs) while True: for task_file in sorted(task_dir.glob(*.md)): output_file output_dir / f{task_file.stem}.result.json if output_file.exists(): print(f[DONE] {task_file.name}) else: print(f[PENDING] {task_file.name}) time.sleep(60)从实际材料来看多日运行的框架必须重点解决“任务间上下文污染”和“长期记忆一致性”两个问题。所以在测试中要特别观察第 5 个任务是否还记得第 1 个任务里约定好的代码风格是否会在不相关的任务里错误复用之前的解决方案长时间运行后日志和 memory 目录是否会产生大量冗余经验5.3 持续改进能力测试对比前后轮次表现continual improvement 是这个项目的重要关键词测试时要有对照实验。实验设计第一轮让 Agent 从零开始修复 5 个 issue记录成功率、平均耗时、测试通过率。第二轮同一组 issue 重新执行但在运行前保留第一轮的 memory 和总结经验文件。第三轮继续保留前两轮的经验再执行同样任务。判断标准第二轮和第三轮的修复速度是否提升重复犯错次数是否下降Agent 是否能主动复用第一轮总结的“如何运行测试”“如何定位 bug”等信息如果三轮测试结果差异不大说明该框架的 continued improvement 机制没有真正生效或者经验读取逻辑存在设计缺陷。这是评估本项目时最关键的实验维度。5.4 稳定性测试长时间无人值守运行长周期任务的最大风险是“跑着跑着就坏了”。稳定性测试要覆盖以下维度维度测试方式API 断连中断网络 2 分钟观察 Agent 是否能自动重试上下文超长连续执行 20 个以上长任务观察是否超出模型上下文限制沙箱崩溃手动重启 Docker 容器观察任务状态是否能恢复日志爆炸长时间运行时检查日志文件是否占用过多磁盘内存泄漏使用htop或free -h监控内存占用趋势# 后台运行 Agent 并记录日志 nohup python main.py --config config/config.yaml --task tasks/task_001.md logs/task_001.log 21 # 监控资源占用 watch -n 10 free -h df -h ps aux | grep python main.py | grep -v grep如果任务在某个环节卡死需要给 Agent 设置总超时时间并开启失败重试机制。一次性任务卡死超过 2 小时的多半是上下文碎片化或沙箱执行异常而不是模型能力不够。6. 接口 API 与批量任务这类框架通常会把任务提交、状态查询、结果获取暴露成 API 服务。虽然当前输入材料没有给出具体接口路径但按通用实践可以设计如下调度流程。6.1 批量任务队列设计一个可行的任务队列结构如下{ tasks: [ { task_id: TASK-001, repo_url: https://github.com/example/demo-repo.git, description: Fix division by zero in calculate_average, priority: high, max_attempts: 3 }, { task_id: TASK-002, repo_url: https://github.com/example/demo-repo.git, description: Update README with new API usage, priority: medium, max_attempts: 2 } ] }批量任务的关键设计点包括任务级别超时、失败重试上限、输出文件命名规范、日志与任务 ID 的一一对应。一个通用的批量调度伪代码import time import requests API_BASE http://127.0.0.1:8080 HEADERS {Authorization: Bearer your-token} def submit_task(task): resp requests.post(f{API_BASE}/tasks, jsontask, headersHEADERS, timeout30) return resp.json()[task_id] def wait_for_task(task_id, timeout7200): start time.time() while time.time() - start timeout: resp requests.get(f{API_BASE}/tasks/{task_id}, headersHEADERS, timeout30) if resp.json()[status] in [succeeded, failed]: return resp.json() time.sleep(30) return {status: timeout, task_id: task_id} # 批量提交任务并等待结果 for task in task_list: task_id submit_task(task) result wait_for_task(task_id) print(task_id, result[status]) if result[status] failed: # 记录失败任务稍后重试 failed_tasks.append(task)注意真实项目的 API 路径、鉴权方式、字段命名都需要以项目文档为准。上面这段代码是通用的机器人调度模板不能直接当成目标项目的 API 用法。6.2 curl 调用示例# 提交任务 curl -X POST http://127.0.0.1:8080/tasks \ -H Content-Type: application/json \ -d { repo_url: https://github.com/example/demo-repo.git, description: Fix failing unit test in test_parser.py }如果接口服务需要鉴权请自行添加Authorization头。默认情况下不要让 API 服务监听公网地址只绑定内网或本机地址。6.3 批量任务的失败重试策略批量任务一定会遇到失败建议采用以下策略每个任务最多重试 3 次达到上限后标记为failed。重试前清理上一次运行产生的临时目录。使用指数退避控制重试频率第一次等待 30 秒第二次 5 分钟第三次 30 分钟。将失败任务单独写入failed_tasks.json方便后续人工分析和重新入队。7. 资源占用与性能观察对于长周期 Agent 框架资源占用观察不像图像生成那样只看一张卡的显存而是要同时关注进程、网络、磁盘和模型服务吞吐。7.1 本机 Agent 进程资源Agent 框架本身属于轻量级应用主要资源消耗在网络请求和沙箱容器上。CPU 占用不会太高除非进行代码解析或向量化索引。观察命令# 查看 Agent 进程 ps aux --sort-%mem | grep -E python|node|java | grep -v grep # 查看 Docker 容器资源占用 docker stats --no-stream如果发现 Docker 容器数量不断增加但无法自动回收需要调整沙箱生命周期管理策略。7.2 模型推理资源本地模型推理时显存占用主要取决于模型参数量、量化方式和上下文长度。7B 模型在 FP16 精度下通常需要约 14GB 显存采用 4-bit 量化后约 6GB 到 8GB但这只是大致的工程经验不同模型架构差异很大。观察方式# 查看 GPU 显存占用 nvidia-smi # 每 5 秒刷新一次 watch -n 5 nvidia-smi如果使用云端 API 模式本机显存压力会小很多但需要关注 API 请求频率和 token 消耗。长周期任务的 token 消耗是一个容易忽视的成本项。7.3 上下文窗口的影响多日运行最大的性能瓶颈往往不是 GPU而是上下文窗口。任务执行时间越长积累的对话历史越多继续新增任务时可能会出现上下文截断导致逻辑丢失。token 消耗呈线性甚至超线性增长。模型响应速度变慢。解决办法包括定期清理不重要的中间对话将关键经验抽取为结构化记忆并压缩到独立文件中只在需要时重新加载而不是一直保留在上下文中。7.4 降低资源占用的建议目标建议降低显存使用量化模型、限制并发任务数、缩短单次上下文长度降低 token 消耗关闭过多工具的冗长输出设置日志只保留摘要降低磁盘占用定期清理旧容器、旧日志、临时补丁文件降低 API 延迟增加重试与超时配置避免同一请求重复发送8. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后任务一直不执行模型 API 配置错误或网络不通查看启动日志检查 API 链接和 Key修复环境变量确认能直接调用模型服务Agent 频繁重复同一操作上下文超出窗口或状态未保存查看日志中工具调用序列清理上下文开启状态持久化Docker 沙箱启动失败容器镜像不存在或权限不足运行docker ps查看错误日志重新拉取镜像检查当前用户 Docker 权限生成的代码无法通过测试模型对项目结构理解不足检查是否提供了足够的项目上下文在任务描述中补充项目结构说明长时间运行后内存持续增长存在内存泄漏或日志积累使用free -h监控趋势增加定时清理与重启策略多日运行后任务结果质量下降记忆库膨胀或经验冲突检查 memory 目录中的总结文件手动清理低质量经验重写关键规则任务执行过程中断网网络异常导致 API 请求失败查看错误日志中的超时记录增加请求重试和任务断点恢复机制API 服务端口被占用已有进程监听同一端口lsof -i :8080查看占用进程更换端口或终止旧进程从实际材料来看最容易踩的坑是三块一是没有单独分配沙箱环境导致 Agent 执行命令时污染宿主机二是没有给任务设置总的超时时间遇到循环调用会无限耗下去三是没有做经验库版本管理多日运行后旧经验和新任务互相打架。9. 最佳实践与使用建议把这类多日自主开发框架真正用到项目里有一些工程经验值得提前沉淀下来。9.1 第一次跑通不要追求复杂先拿一个小仓库、一个简单 bug、一个明确任务去验证链路。不要一上来就把整个微服务仓库丢给 Agent 去重构。最小化验证路径跑通后再逐渐加大任务复杂度。9.2 任务描述要像给新同事写说明Agent 没有你脑子里的项目背景任务描述里最好包含这些信息仓库位置、涉及文件、期望行为、验收标准、禁止触碰的模块。任务描述写得越具体成功率越高。一个高质量任务描述的模板## 任务目标 修复 src/calculator.py 中 divide 方法在除数为 0 时崩溃的问题。 ## 背景 divide 方法当前使用 Python 默认的 ZeroDivisionError 异常 会导致 API 返回 500。项目希望返回 400 和友好提示信息。 ## 验收标准 1. 调用 divide(1, 0) 返回 None 并记录一条警告日志。 2. 现有单元测试全部通过。 3. 不修改 src/api.py 中的任何内容。 ## 参考信息 - 相关测试文件tests/test_calculator.py - 错误日志样本见 logs/error_sample.log9.3 经验库要人工干预持续改进机制不是“跑得越久越好”。每周或每轮任务结束后建议人工检查一遍 memory 目录中的总结文件删除那些错误、过时或过于具体的经验条目。保留一套核心规则比如“项目使用 pytest 而非 unittest”“不要修改 database.py”等帮助 Agent 少走弯路。9.4 命令执行必须在沙箱里凡是涉及代码执行的任务一定要放在 Docker 容器中运行。不要在工作目录里直接用宿主机 Python 执行 Agent 生成的代码。容器可以放心恢复快照而宿主机一旦被装了恶意依赖清理成本会非常高。9.5 日志保留与任务 ID 关联日志命名建议包含任务 ID例如logs/task_001_execution.log。批处理时将每轮任务的状态记录到results.csv中方便对比不同版本模型、不同 prompt 策略的成功率。task_id,status,attempts,tokens_used,duration_seconds,test_result TASK-001,passed,1,15230,1240,pytest: 12 passed TASK-002,failed,3,40600,5380,pytest: 2 failed9.6 合规与安全红线虽然智能体能自动开发但使用者和部署者必须承担最终责任。涉及私有代码、用户数据、生成内容的场景要遵守相关法律法规与授权要求。不要向 Agent 暴露真实生产环境的数据库密码、云服务密钥或个人敏感信息。如果 Agent 会读取人脸图像、声音样本等数据务必确认已获得相关权利人的明确授权并在符合隐私保护规范的前提下使用。所有自动生成的代码在合入主干前都要经过人工 code review。10. 总结与下一步Harness-of-Harness 这个项目最值得关注的地方不是它能把单次任务完成得有多好而是它把“持续运行”和“持续改进”这两个问题正式地放到了自动驾驶软件开发框架的设计核心位置。对做 Agent 应用开发的人来说这套设计思路有直接的借鉴价值经验如何沉淀、任务如何拆解、多日运行如何保持稳定都是真实的工程痛点。如果你准备上手实验建议第一步先验证基础链路准备一个小型仓库给一个简单 issue让 Agent 串行跑 5 个任务记录每轮的成功率和耗时。第二步再启动多日运行测试重点观察 memory 目录的增长和任务质量的变化。最容易踩的坑就是沙箱隔离不到位、任务没有总超时、经验库没有清理机制这三个问题建议在首次运行前就解决。后续可以沿着这几个方向继续扩展接入本地开源模型做私有化部署、把任务队列接到 CI/CD 流水线里、对记忆模块做向量化检索、以及设计更细粒度的“经验质量评分”来控制持续改进的方向。这个领域还在快速演进把一套任务跑通只是开始真正有价值的部分是观察它能否在长周期里稳定地越用越好。