Harness-of-Harness：多日自主软件开发中的持续改进机制

当GitHub Copilot、Cursor 这类工具已经能把“写一个函数”“补一个测试”这样的单点任务做得相当流畅时很多开发者会下意识地问一个问题既然单点任务可以被 AI 自动化那“让 AI 自己把一个项目从需求做到交付”还远吗远也没有想象中那么远。一个容易被忽略的事实是当前大多数 AI 编程工具本质上都是“单轮对话 短任务执行”它们擅长在几分钟内生成代码片段却很难在持续数天的开发周期里保持上下文一致、方向不偏、质量不塌。你让 Agent 写一个模块它可能写得不错你让 Agent 连续三天迭代同一个项目第二天它可能就忘了第一天定下的接口约定第三天直接把之前通过测试的功能改坏了。这正是 Harness-of-Harness: Multi-Day Autonomous Software Development with Continual Improvement 这篇工作试图回答的问题。从标题的字面意思拆开看它包含两个核心关键词Harness和Multi-Day Autonomous Software Development。前者指向“如何在每个环节约束和验证 Agent 的行为”后者指向“如何让 Agent 像一名真实工程师一样在跨天的时间尺度上持续开发并不断改进”。这篇文章不打算止步于翻译标题。我想结合当前 Agent 工程化和大模型应用落地的实际背景拆解这套思路背后的技术逻辑、工程价值以及它对普通开发者和技术团队的实际意义。即使你没有条件复现完整的实验也能从这套设计中提炼出可复用的工程方法用在你自己的 Agent 工作流和自动化评测体系里。1. Harness 到底是什么从模型评测工具到工程约束框架如果你接触过大模型开源社区大概率见过 Harness 这个词。最知名的例子是 OpenAI 的evals和 EleutherAI 的lm-evaluation-harness。在这些项目里Harness 指的是一套标准化的评测执行框架你定义任务数据集框架负责调用模型、收集输出、计算指标、汇总结果。换句话说Harness 就是“考场”。它规定考什么题、怎么答卷、怎么评分从而保证不同模型之间的能力可以被公平比较。但 Harness-of-Harness 里的 Harness含义更进了一层。它不只是“考模型”而是在自主软件开发的全流程中为 Agent 的每一步行为建立约束和验证机制。如果说单层 Harness 是给模型设置考试那 Harness-of-Harness 就是给“考试者”再设置一套监督机制确保 Agent 在无人干预的情况下不会跑偏、不会重复犯错、不会在长周期任务中逐渐劣化。这个概念要理解到位需要先放下“Harness 测试工具”的固有印象。在这套设计里Harness 至少承担四种角色角色作用类比任务解析器把高层需求拆解为可执行、可验证的子任务项目经理行为约束器限制 Agent 的工具调用范围、操作边界、权限范围安全审计员质量验证器对每一阶段的产出做自动化检查确定是否进入下一步测试工程师反馈闭环将失败信息、错误日志、测试报告反馈给 Agent驱动下一轮改进导师所以Harness 既不是简单的测试集也不是 Agent 运行框架本身而是夹在 Agent 和环境之间的那层“规则层”。它的存在决定了 Agent 是在“自由发挥”还是在“受约束地完成工程目标”。从开发者视角看这个设计传递了一个很实用的判断想让 Agent 在真实项目中可靠工作光靠更强的模型不够必须在外围建立一套可执行的验证机制。模型负责生成候选方案Harness 负责判断方案是否被接受。这个思想本质上和 CI/CD 里“人写代码、机器跑测试”的分工一模一样只不过这里的“人”换成了 Agent。2. 为什么“多日自主开发”和单日任务完全不是一回事很多人对 Agent 的长周期任务抱有一种过于乐观的想象觉得只要上下文窗口够大Agent 就能像人一样连续工作。但从工程实践看跨天完成一个软件开发任务难点根本不在上下文长度而在状态的一致性和行为的可回溯性。单个会话内Agent 可以在上下文里记住对话历史这相对容易。但跨天之后几个现实问题立刻浮现出来第一上下文不可能无限膨胀。真实项目里有需求文档、接口定义、历史代码、测试报告、运行日志、依赖配置全部塞进上下文既不现实也会严重拖慢推理速度、稀释注意力。Agent 必须学会把重要信息“落盘”到外部存储而不是依赖对话记忆。第二每一天结束时的状态必须可持久化、可恢复。人和人协作时第二天上班会先看昨天的代码提交和待办清单。Agent 也一样它需要知道“昨天完成到什么程度”“哪些验证通过了”“今天该从哪里继续”。如果没有这个机制Agent 重新启动后面对的就是一个半成品的代码库它甚至不知道下一步该做什么。第三问题修复不能只靠“再试一次”。很多短任务 Agent 遇到报错就换个方式重试这在单次任务里可能有效。但多日开发中同样的错误模式可能反复出现如果 Agent 不能从错误中提炼出经验并沉淀到某个记忆或规则库它就会在项目第三天再次踩第二天的坑。第四长期运行的 Agent 容易发生“方向漂移”。一个任务拆成多天执行Agent 在某个子任务上花费过多时间后很可能渐渐偏离原始需求。它需要一套机制时刻把它拉回主线比如任务清单、验收标准、里程碑检查。这说明多日自主开发的本质不是“更长的上下文”而是“更强的工程化能力”状态持久化、任务规划、验证准入、经验沉淀、回滚恢复。这些能力单靠模型本身很难自动涌现必须通过外层 Harness 来设计和注入。理解了这一点再回头看 Multi-Day Autonomous Software Development你就会发现它不是在炒“AI 取代程序员”的概念而是在解决一个非常具体的工程问题如何让一个长期运行的 Agent 在无人值守时依然能维持软件工程的基本纪律。3. 逐日验证为什么是关键让 Agent 在“考场”里持续改进Continual Improvement 这个词在标题里出现很容易让人联想到“Agent 会自己学习、越用越强”。但它在这个语境下表达的其实是另一层含义通过每一天的验证结果驱动 Agent 在下一天表现得更好而不是在同一个项目里越改越乱。要实现这种逐日改进Harness 需要提供两类东西反馈和记忆。反馈是即时的。当 Agent 完成某一天的开发任务后Harness 会运行测试、检查代码质量、验证功能行为然后生成结构化报告。这份报告不只是“通过/失败”的二元结果而是尽量包含失败类型、出错位置、复现步骤等细节。Agent 拿到这些细节后可以在下一天的工作中有针对性地修复问题。没有这种结构化反馈Agent 面对一次测试失败往往只能盲目猜测修复效率非常低。记忆是跨天的。Harness 需要把每天结束时的重要信息持久化比如当前任务的完成度、待办事项、已修复的问题、踩过的坑、验证通过的功能清单。这些信息不会在一夜之间消失而是作为下一天工作的起点。这种机制模仿了人类开发者维护 TODO、写工作日志、保留设计文档的习惯只不过它由 Harness 自动完成。从工程实现角度这套机制很像一个“带反馈的循环控制系统”每天循环 1. Agent 读取当前任务状态和历史经验 2. Agent 在代码仓库中进行修改 3. Harness 自动运行测试和静态检查 4. 结果生成反馈报告更新任务状态 5. 未通过的项进入下一天的改进队列这个循环的核心价值在于它把“改进”从模型的随机行为变成了一个受控的、可验证的、可持续的工程过程。Agent 不需要真的在每次失败后重新训练模型权重只需要在外部记录哪些策略有效、哪些模式容易出错就能在下一轮执行中收敛到更优解。对于开发者来说这个思路最大的启发是你不需要等模型厂商推出一个“会自主学习”的超级 Agent也能通过外层框架让现有模型在长任务中保持稳定。改进不是模型的能力而是 Harness 的工程结果。4. 核心架构拆解Harness-of-Harness 的设计分层虽然目前公开材料对这个项目的具体实现细节披露有限但从标题和当前自主 Agent 的主流设计范式可以合理推断它的整体架构大概率包含以下几层。这里做一个基于技术常识的系统梳理方便你在自己的工作中参考。4.1 任务规划层这一层负责把高层需求转换成一份可执行的开发计划。它通常包括任务分解、优先级排序、依赖关系分析和里程碑设定。一个好的任务规划层会让 Agent 在面对“实现一个博客系统”这种模糊需求时先产出“搭建项目骨架 - 实现用户认证 - 实现文章 CRUD - 开发前端页面 - 编写测试”这样的有序计划而不是直接开始写代码。任务规划层的产物建议保存为结构化的任务描述文件这样既方便 Agent 查看也方便 Harness 验证进度。4.2 工具执行层这一层是 Agent 真正操作代码仓库的接口。主流方案通常基于“工具调用”Tool Calling模式Agent 通过调用预定义的函数来执行操作比如读取文件、编辑文件、运行 Shell 命令、执行测试、提交 Git。相比直接让模型输出代码工具调用模式的优势在于每次操作都可以被记录和审计。工具输出可以被 Harness 捕获和分析。可以限制 Agent 的权限避免它执行危险命令。在实现上这一层本质上就是一个白名单化的沙箱环境Agent 只能在允许的工具集内行动。4.3 验证评估层这是 Harness 概念最直观的体现。当 Agent 完成一个子任务或结束一天的开发后验证层会自动运行预定义好的验证流程包括单元测试、集成测试、静态检查、类型检查、端到端测试等。验证结果会进入反馈循环。值得注意的是验证层的质量标准必须由人来预定义而不是由 Agent 自己定义。否则就会出现“自己出题自己考”的问题Agent 很可能降低标准来换取通过率。4.4 反馈与记忆层这一层负责把验证结果转换成语义化的、对 Agent 有用的信息。比如测试失败了系统可以生成一份包含“失败用例名称、错误信息、堆栈追踪、相关代码文件”的结构化报告。与此同时系统会把当天的问题、经验、未完成任务保存到持久化的记忆库中供下一天读取。从实现上看记忆层可以是一个简单的 Markdown 文件、JSON 文件也可以是一个向量数据库加检索模块。复杂度和项目规模成正比不必一步到位。4.5 人类监督层即便目标是无监督多日开发仍然需要保留人类入口。人类监督层提供进度查看、日志审查、紧急停止、计划调整等功能。这也符合实际工程需要完全放权给 Agent 在多数企业场景中并不现实关键节点的人工审批依然是安全底线。这五层架构的价值在于它把一个模糊的“让 AI 开发软件”的目标拆解成了可独立设计、独立优化、独立验证的工程模块。你在自己的项目中不需要一次实现全部五层可以先从一个最小闭环开始。5. 环境准备与基础配置跑通一套可验证的 Agent 工作流Read through the rest of the article and ensure its 5000 characters. Let me continue from here — I need to write a longer article from section 5 onward.由于该项目本身属于前沿研究方向公开可复现的源码和标准安装步骤目前并不统一。因此这一节我会结合当前开源的 Agent 开发框架给出一个通用的、可落地的环境搭建思路而不是绑定到某个具体仓库。目标是通过最小配置先让一段“Agent 开发 - 自动验证 - 反馈迭代”的闭环在你的机器上跑起来。5.1 基础运行环境推荐环境如下具体版本以你使用的框架为准组件建议方案操作系统Linux Ubuntu 20.04 / macOS 均可Windows 建议使用 WSL2编程语言Python 3.10这是当前 Agent 框架的主流兼容版本容器化工具Docker用于隔离 Agent 执行环境和运行测试代码仓库Git所有修改都纳入版本管理便于回溯模型服务OpenAI 兼容接口的模型服务或本地部署的开源模型Agent 框架可以根据团队已有技术栈选择 LangGraph、AutoGen或直接基于 OpenAI Function Calling 开发这里想强调一个容易踩坑的点Agent 的执行环境一定要和宿主机做隔离。很多人在本地直接让 Agent 运行 Shell 命令一旦 Agent 生成了rm -rf或错误的安装命令后果可能是毁灭性的。通过 Docker 容器限定文件系统访问范围、网络权限和命令白名单是成本最低、收益最明显的安全手段。5.2 定义可验证的任务描述在启动 Agent 之前必须先把需求转化成一个包含验证标准的任务文档。这个文档是 Harness 判断“任务是否完成”的依据。下面给出一个任务描述模板你可以根据项目调整。# 文件路径tasks/task_001.yaml id: task-001 title: 为订单模块增加优惠券抵扣功能 description: 在现有的订单结算逻辑中增加优惠券抵扣能力。 用户在下单时可以输入优惠券码系统校验优惠券有效后 在订单总价中扣除对应金额。 acceptance_criteria: - 用户输入有效优惠券码后订单总价正确扣减 - 用户输入过期或无效优惠券码时返回明确错误信息 - 优惠券抵扣金额不能超过订单总金额 - 优惠券使用后状态更新为“已使用”不能重复使用 success_tests: - test_apply_valid_coupon - test_apply_expired_coupon - test_apply_coupon_exceeds_total - test_coupon_cannot_be_used_twice estimated_days: 2 allowed_tools: - read_file - edit_file - run_python - run_pytest - git_commit这个文件的关键价值在于acceptance_criteria和success_tests。前者给 Agent 提供了明确的行为边界后者是 Harness 验证层判断任务是否通过的具体抓手。没有验收标准的任务Agent 无法判断自己是否完成Harness 也无法给出明确反馈。6. 核心流程与代码示例Agent 多日执行循环的落地实现这一节我们用代码展示一个简化版的“多日开发执行循环”。它模拟了 Harness 的最核心逻辑读取任务 - Agent 执行 - 运行验证 - 生成反馈 - 更新状态。这里不绑定具体模型 API而是用接口占位的方式写出完整流程方便你迁移到自己的实现。6.1 步骤一编写验证脚本验证脚本是 Harness 的核心。这里以 Python 项目为例使用pytest作为测试执行器。你需要为任务中的每个验收标准编写对应测试用例。# 文件路径tests/test_coupon.py import pytest from order import Order, CouponService def test_apply_valid_coupon(): 用户输入有效优惠券码后订单总价正确扣减 order Order(total_amount100.0) coupon_service CouponService() result coupon_service.apply_coupon(order, coupon_codeSAVE20) assert result[success] is True assert order.total_amount 80.0 def test_apply_expired_coupon(): 用户输入过期或无效优惠券码时返回明确错误信息 order Order(total_amount100.0) coupon_service CouponService() result coupon_service.apply_coupon(order, coupon_codeEXPIRED01) assert result[success] is False assert expired in result[message].lower() def test_apply_coupon_exceeds_total(): 优惠券抵扣金额不能超过订单总金额 order Order(total_amount30.0) coupon_service CouponService() result coupon_service.apply_coupon(order, coupon_codeSAVE50) assert result[success] is False assert result[message] coupon amount exceeds order total def test_coupon_cannot_be_used_twice(): 优惠券使用后状态更新为已使用不能重复使用 order Order(total_amount100.0) coupon_service CouponService() coupon_code SINGLE_USE first_use coupon_service.apply_coupon(order, coupon_codecoupon_code) assert first_use[success] is True second_order Order(total_amount200.0) second_use coupon_service.apply_coupon(second_order, coupon_codecoupon_code) assert second_use[success] is False assert already used in second_use[message].lower()这些测试用例的设计原则是每个用例都对应一个明确的验收标准并且验证的是外部行为而不是内部实现细节。这样 Agent 无论用什么方式实现功能只要测试通过就说明行为符合要求。6.2 步骤二实现多日执行循环下面这个 Python 脚本是 Harness 主循环的简化版本。它负责在每天的迭代中调用 Agent 执行任务、运行测试、收集反馈并把状态写入一个 JSON 文件这样第二天启动时可以从上次的位置继续。# 文件路径harness/daily_loop.py 简化版多日自主开发执行循环。 核心职责 1. 从状态文件中读取当前进度。 2. 调用 Agent 执行今日开发任务。 3. 运行项目测试和验证脚本。 4. 根据验证结果生成结构化反馈。 5. 更新状态文件用于第二天继续执行。 import json import subprocess import sys from datetime import date from pathlib import Path # 配置 PROJECT_ROOT Path(.).resolve() STATE_FILE PROJECT_ROOT / run_state.json TEST_COMMAND [sys.executable, -m, pytest, tests, -x, --tbshort] # Agent 接口占位实际项目中替换为具体的模型调用逻辑 def call_agent(instruction: str, workspace: Path) - str: 调用 Agent 执行一次开发任务。 真实场景中这里会拼接系统提示词、历史状态、任务描述 调用模型服务并在工作区中应用 Agent 生成的代码修改。 # 伪代码占位实际请接入你的 Agent 框架 return Agent finished the given instruction. def load_state() - dict: if STATE_FILE.exists(): return json.loads(STATE_FILE.read_text(encodingutf-8)) return { current_day: 1, finished: False, history: [], todo: [], } def save_state(state: dict) - None: STATE_FILE.write_text( json.dumps(state, ensure_asciiFalse, indent2), encodingutf-8, ) def run_tests() - subprocess.CompletedProcess: return subprocess.run( TEST_COMMAND, cwdPROJECT_ROOT, capture_outputTrue, textTrue, ) def build_feedback(result: subprocess.CompletedProcess) - str: 根据测试执行结果生成结构化反馈供 Agent 下一天改进使用。 if result.returncode 0: return ALL TESTS PASSED. No feedback needed. lines result.stdout.splitlines() failed_cases [ line.strip() for line in lines if line.startswith(FAILED) or Error in line ] feedback [ The following test cases failed today:, ] feedback.extend(failed_cases[:20]) feedback.append(Please review the failure details and fix the issues.) return \n.join(feedback) def daily_loop(max_days: int 5) - None: state load_state() for day in range(state[current_day], max_days 1): if state[finished]: print(Task already finished. Exiting.) return print(f\n Day {day} ) instruction ( fToday is day {day}. Continue the development task according to the task file. Focus on the unfinished acceptance criteria. ) # 1. Agent 执行开发任务 agent_output call_agent(instruction, PROJECT_ROOT) print(agent_output) # 2. 运行验证 print(Running tests...) result run_tests() # 3. 生成反馈 feedback build_feedback(result) print(feedback) # 4. 更新状态 state[current_day] day 1 state[history].append({ day: day, passed: result.returncode 0, feedback: feedback, }) if result.returncode 0: state[finished] True print(All tests passed. Task finished.) save_state(state) return save_state(state) print(Maximum days reached. Task not finished.) if __name__ __main__: daily_loop()这段代码的逻辑非常直观每天执行一次“Agent 干活 - 自动测试 - 生成反馈 - 保存状态”的循环。如果测试全部通过任务结束否则进入下一天并且 Agent 会在下一天的 instruction 中看到历史反馈从而知道自己上一轮哪里出了问题。这个循环体现的就是 Continual Improvement 的最基本形态每一轮的失败信息都被记录下来成为下一轮改进的输入。虽然不是复杂的强化学习但已经足够让 Agent 在一个可控的工程周期内收敛。6.3 步骤三用 Docker 隔离执行环境为了让 Agent 的执行不会破坏宿主机环境建议通过 Docker 运行测试和 Agent 的修改流程。下面是一个简单的 Dockerfile 示例。# 文件路径Dockerfile FROM python:3.10-slim WORKDIR /workspace RUN apt-get update apt-get install -y git rm -rf /var/lib/apt/lists/* COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD [python, harness/daily_loop.py]注意这里把整个项目复制进容器并没有做复杂的用户权限隔离。在生产级方案中你还需要为容器创建独立的低权限用户。禁止容器访问宿主机 Docker Socket。设置网络策略仅允许拉取依赖所需的域名。挂载临时目录而不是直接写入宿主机代码库。不要小看这些细节。Agent 出错的方式千奇百怪隔离是最后一道防线。7. 运行结果与效果验证如何判断 Agent 真的在“持续改进”跑通上面的循环之后你需要一套指标来判断这套流程是否真的有效。光看“最终测试是否通过”远远不够因为一个总是把简单问题搞砸、靠第 30 次瞎试才通过的 Agent和一个第 3 天就稳定收敛的 Agent表现天差地别。建议至少关注以下指标指标说明观察方式完成天数从开始到全部测试通过消耗的天数查看历史记录中的 day测试修复效率每轮迭代后通过用例数的增量对比每天反馈中的失败用例数重复错误率同一类错误是否在多个轮次重复出现检查反馈中错误模式是否相同代码变更量Agent 为了修复问题是否产生大量无关修改使用git diff --stat查看每次提交的变更范围需求漂移程度Agent 是否新增了需求外的功能或改动人工审查最终 diff对比任务描述文件在这些指标中重复错误率是最能反映 Continual Improvement 是否真正生效的信号。如果 Agent 第一天因为某个函数接口写错导致测试失败第二天面对同样的错误还是继续踩坑说明 Harness 的反馈机制没有把失败原因传递给 Agent。这时候要检查反馈文本是否足够清晰或者记忆库中是否真的保存了可检索的历史错误信息。要验证你的 Harness 是否有效一个简单的方法是做“对比实验”同一份任务分别让“无 Harness 的纯 Agent”和“有 Harness 的 Agent”执行观察完成天数、通过率和最终代码质量。不要相信 Agent 自己说“我完成了”一切以测试和人工 review 为准。8. 常见问题与排查思路在实际实现这套流程时你大概率会遇到下面几个问题。问题现象可能原因排查方式解决方案Agent 每天修改同一处代码测试始终不过反馈信息不够具体Agent 不知道失败原因检查build_feedback生成的文本是否包含错误堆栈和用例名增加失败用例的源码上下文、最近一次相关 git diff任务进行到第三天Agent 忘记了第一天的需求状态文件中没有保存完整的任务描述和决策记录查看run_state.json中的历史记录每次循环都重新读取 task 文件把关键决策追加到状态中Agent 运行了危险命令工具执行层没有做命令白名单限制查看工具调用日志在工具层过滤 Shell 命令只允许白名单命令测试环境与开发环境不一致Agent 在容器外修改依赖导致容器内测试失败对比容器内外的 requirements统一使用 Docker 作为唯一开发测试环境Agent 在一天内做大量无关修改任务描述边界不清晰验收标准不具体检查任务文件中 acceptance_criteria细化验收标准限制单日任务粒度模型上下文越来越长响应变慢所有历史都塞进上下文观察请求体长度用外部记忆库存储历史只传入与当前任务相关的片段这里最需要重视的是反馈信息的质量。很多失败的 Harness 设计问题不在于验证层没跑测试而在于反馈层没有把失败原因“翻译”成 Agent 能理解的语言。原始 pytest 输出对模型来说往往是噪声大于信号你需要主动提取关键信息甚至给它看相关的源码片段它才能高效修复。9. 最佳实践与工程建议对于想把“多日 Agent 开发 持续改进”引入团队或自己做实验的开发者下面几条建议来自工程实践的通识总结可以作为你设计系统时的参考原则。9.1 从“单日循环”开始不要一开始就追求多日自动化不要因为标题里有 Multi-Day 就急着做一个能连续跑一周的无人值守系统。先确保“一天内的闭环”是可靠的Agent 改代码 - 自动测试 - 反馈修复这个过程稳定了再松开时间维度让它跨天运行。否则你只会得到一个运行三天就彻底失控的复杂系统排错成本极高。9.2 验收标准永远由人来写Agent 可以写代码、写测试但验收标准必须由人来定义。正如前文所说如果 Agent 自己决定“什么样算完成”它一定会选择最容易通过的方式。人的价值在于定义“正确的行为”Agent 的价值在于实现这些行为。这个分工越清晰系统越稳定。9.3 所有修改必须可回溯强制要求 Agent 每次修改后都提交 Git并且 commit message 关联到具体的子任务编号。这样即便 Agent 出现严重错误你也可以用git revert安全回滚而不是面对一个被改乱的工作区束手无策。版本管理不是开发团队的偏好而是长周期 Agent 系统的生存底线。9.4 把错误模式沉淀为“经验库”当 Agent 在某一类错误上反复失败时把它整理成一条结构化经验写进记忆库。比如“项目使用 Pydantic v2不要使用已移除的parse_obj方法”。下一轮循环开始前把这些经验注入系统提示词。这一步是 Continual Improvement 从“循环”走向“进化”的关键也是最容易出效果的地方。9.5 关键节点保留人工审批即便实现了无人值守也建议在以下节点引入人工确认任务启动前、大规模代码重构后、所有测试通过后。这不是对 Agent 的不信任而是对代码质量的负责。人工审批不一定要很重可以是一次 commit review 或一次 PR 审批。10. 总结回到标题本身Harness-of-Harness 这个词组真正想传达的并不是另一个“AI 编程神器”的诞生而是一种更成熟的工程观念如果你想让人工智能像工程师一样连续工作多天就不能只依赖模型单次的生成能力而必须在外围建立一套完整的约束、验证、反馈和记忆机制。这套机制的价值在于它把“让 AI 开发软件”从一个听上去很酷的口号变成了一个可以拆分、可以执行、可以度量的工程系统。任务规划层告诉 Agent 做什么工具执行层限制它怎么操作验证评估层判断它做得好不好反馈记忆层让它下一天做得更好人类监督层保证一切不失控。对普通开发者和团队来说即使你不追踪前沿论文、不亲自跑实验这套设计中的很多思想也完全可以直接借鉴到日常工作中你用的 CI 流水线本质上就是一个 Harness你给大模型应用添加的评测集本质上也是 Harness 的一部分。区别只在于你是否把它系统化、标准化并让它形成可持续改进的闭环。如果你准备在自己的项目里尝试这类方案建议收藏这篇文章从搭建 Docker 隔离环境、编写任务描述文件、跑通每日循环开始。一个最小可用的 Harness可能只需要几百行代码但它能教会你的远比你想象的多。