企业官网建设流程全解析

Harness Engineering 前沿知识调研：OpenAI 与 Anthropic 的实践案例

分享主题：AI Agent 不只是靠模型变强，更靠工作环境变好

1. Harness Engineering 是什么

我对 Harness Engineering 的一句话理解是：

给 AI Agent 搭一个能长期工作的“工作台”：有资料、有工具、有边界、有检查、有反馈。

举个例子：如果让一个同学帮你做小组作业，只说“帮我做个项目”是不够的。你还要给他需求文档、评分标准、文件目录、进度表、测试方法和返工规则。否则他可能做得很快，但方向错了、漏功能了，甚至自己以为完成了。

AI Agent 也是一样。模型越能干，越需要清楚的工作环境。否则它写代码很快，也可能很快制造混乱。

2. 从 Prompt 到 Context，再到 Harness

AI 工程的变化可以概括成三个阶段：

重点是：当 AI 从“回答问题”变成“自己执行任务”后，光有 prompt 和 context 不够了。它需要能运行、能观察、能纠错的系统。

可以用一个简单公式概括：

Model + Harness = Agent

模型像发动机，Harness 像方向盘、刹车、仪表盘和道路规则。只有发动机不等于一辆可靠的车。

3. Anthropic 实践案例一：长时间运行的 Agent 怎么不中途迷路

Anthropic 的第一篇文章（2025年11月）关注一个非常实际的问题——上下文焦虑：

如果 Agent 要连续工作很久，跨越多个上下文窗口，它怎么知道之前做了什么、接下来该做什么？

这和我们做小组项目很像：如果一个人做到一半换另一个人接手，后者必须知道当前进度、剩余任务、怎么运行项目、哪里有坑。

3.1 Claude 遇到的两个典型问题

Anthropic 发现，Claude 在长任务中容易出现两个问题。

第一个是：想一次做太多。

比如用户说：

做一个类似 claude.ai 的网页应用。

Agent 可能一口气写很多代码，但做到一半上下文快满了，功能半成品、文档没写、下一轮 Agent 不知道发生了什么。

第二个是：过早宣布完成。

后续 Agent 看到项目里已经有一些代码，就误以为“大概完成了”，但其实还有很多功能没做。

这两个问题都说明：长程任务不能只靠模型记忆，必须把状态写到外部。

3.2 Initializer Agent：先搭工作环境，再写功能

Anthropic 设计了一个Initializer Agent。它的任务不是一上来写业务功能，而是先搭好环境。

它会创建：

• init.sh：告诉后续 Agent 如何启动项目；
• claude-progress.txt：记录做了什么、还剩什么；
• 初始 Git commit：留下清晰历史；
• feature list：把大任务拆成很多可检查的小功能。

然后后面的Coding Agent每次只做一小块：

• 开始前读进度文件；
• 查看 Git log；
• 读取 feature list；
• 运行init.sh；
• 先做基础端到端测试；
• 再选择一个未完成功能开始做；
• 做完后测试、提交、更新进度。

类比：

Initializer Agent 像小组长，先把任务表、文件夹、评分标准和运行方法建好；Coding Agent 像组员，每次认领一个任务，做完打勾并写日志。

3.3 用功能清单防止 Agent “自说自话”

Anthropic 让初始化 Agent 生成结构化功能清单。比如：

{"category":"functional","description":"点击 New Chat 后创建新对话","steps":["进入主界面","点击 New Chat 按钮","确认新对话被创建","确认侧边栏出现新会话"],"passes":false}

后续 Agent 只能把passes从false改成true，不能随便删除或改写测试项。

这样做有几个好处：

• 什么叫“完成”更清楚；
• 后续 Agent 不会忘任务；
• 人类也能检查进度；
• Agent 不容易把没做完的功能当成完成。

简单说，功能清单就像项目里的“打卡表”。没通过测试，不能随便打勾。

3.4 Anthropic 长程 Agent 案例的启发

这个案例最重要的启发是：

长程 Agent 的核心不是一次性变聪明，而是能一棒接一棒稳定交接。

所以需要：

• 外部进度文件；
• Git 历史；
• 功能清单；
• 每次开始前先确认当前状态。

这些东西看起来很普通，但对长时间运行的 Agent 非常关键。

4. Anthropic 实践案例二：评估器分离

Anthropic 的另一篇文章（2026年3月）进一步讨论复杂应用开发，重点是另一个问题——自评失真：

AI 自己评价自己，往往会太宽容。

这很像学生自己批改自己的作文。自己写的时候觉得不错，但老师一看会发现结构、逻辑、细节都有问题。

4.1 生成者和评价者分开

Anthropic 设计了三个角色：

• Planner：想清楚做什么、怎么拆、怎么算完成；
• Generator：负责生成代码或界面；
• Evaluator：负责打开应用、测试功能、打分、指出问题。

这比让同一个 Agent 自己写、自己评更可靠。

4.2 主观质量也要拆成可评分标准

比如对于前端设计来说，简单问：

这个界面好看吗？

Agent 很可能回答“很好看”。这是自评估的系统性缺陷，而工程化一个独立的严格 Evaluator 远比教会 Generator 自我批评要容易得多。

Anthropic 把主观质量拆成几个维度：

• 设计整体性：颜色、字体、布局是否像一个整体；
• 原创性：是不是模板味、AI 味太重；
• 工艺质量：间距、层级、对比度是否合格；
• 功能可用性：用户能不能完成任务。

这样 Evaluator 就有标准可依，而不是凭感觉夸。

4.3 Sprint Contract：每轮开始前先定义“完成”

在复杂应用里，Anthropic 让 Planner、Generator 和 Evaluator 围绕每一轮开发任务先达成合约：

• 这一轮做什么；
• 做到什么程度算完成；
• 怎么测试；
• 哪些行为必须通过。

然后 Generator 再开始写代码，Evaluator 再按约定测试。

类比：

小组作业每一周先定计划：这周做登录页，验收标准是能输入账号密码、错误时提示、成功后跳转。否则很容易大家各做各的，最后拼不到一起。

4.4 Harness 必须匹配模型的能力

Anthropic 的实践里有一个很重要的观点：Harness 不是越复杂越好，而是要和模型能力匹配。

如果模型能力还不够稳定，复杂一点的 harness 是有必要的。比如让 Planner 先拆任务，让 Generator 负责实现，让 Evaluator 独立检查，再用 Playwright 做浏览器测试。这样虽然成本更高、流程更长，但能减少 Agent 自己误判完成、漏掉功能、界面不可用等问题。

但随着大模型的更新迭代，模型本身已经能比较稳定地完成某些任务，过度复杂的 harness 反而会变成负担。它可能带来：

• 更多调用成本；
• 更长运行时间；
• 更多中间文件；
• 更复杂的调试过程；
• 不必要的 Agent 分工。

所以 Anthropic 的经验不是“永远堆更多 Agent、更多检查、更多流程”，而是持续判断：

哪些 harness 组件是真正承重的，哪些只是临时模块？

4.5 Anthropic 评价者案例的启发

这个案例说明：

1. 让 AI 自评是不够的，最好有独立评价者。
2. 主观质量也可以拆成可检查标准。
3. 复杂任务要先定义完成标准，再开始生成。
4. Harness 复杂度要根据任务难度调整，不是越复杂越好。

5. OpenAI 实践案例：Codex 如何构建百万行代码项目

OpenAI 的案例是目前 Harness Engineering 最典型的公开实践之一。这是一次真实产品开发实验。

5.1 他们做了什么

OpenAI 介绍了一个内部实验：

• 团队从一个空 Git 仓库开始；
• 使用 Codex 构建一个真实内部产品；
• 极端约束：0行手写代码；
• 应用代码、测试、CI （持续集成）配置、文档、可观测性、内部工具都由 Codex 生成；
• 约 5 个月后，代码规模接近百万行；
• 约 1500 个 PR 被打开和合并；
• 团队从最初 3 名工程师扩展到 7 名；
• OpenAI 估计开发速度约为手写代码的 10 倍。

OpenAI 的核心理念可以概括为：

Humans steer. Agents execute.
人类掌舵，Agent 执行。

5.2 人类工程师的新角色

在这个实验里，人类工程师更像：

• 产品负责人：说清楚到底要做什么；
• 架构师：规定系统边界；
• 平台工程师：把规则做成工具；
• 教练：发现 Codex 容易犯什么错；
• 质检负责人：只在关键判断点介入。

举个例子：

如果 Codex 总是把 UI 层直接连到数据库，传统做法可能是直接提醒大模型：

不要这样写，下次注意。

但 Harness Engineering 的做法是：

写一个架构检查工具。以后只要 UI 层越界访问数据库，CI 直接失败，并告诉 Codex 应该走 Service 层。

也就是说，把一次人工提醒，变成以后每次都自动生效的规则。

5.3 AGENTS.md：给 Codex 一张地图，而不是一本百科全书

OpenAI 发现，不能把所有规则都塞进一个巨大AGENTS.md文件。

因为：

• 文件太长会占满上下文；
• 重点会被淹没；
• 文档很容易过期；
• Agent 不知道哪些规则最重要。

他们的做法是：

AGENTS.md：短地图，告诉 Codex 去哪里找资料 docs/：存放详细的产品、架构、质量文档 CI/lint：检查规则有没有被遵守

也就是说：

AGENTS.md就像校园导览图。它不需要写完整本教材，只要告诉你教室、图书馆、实验室在哪里。

这也说明一个关键点：对 Agent 来说，不在仓库里、读不到、查不到、验证不了的知识，基本等于不存在。

5.4 让 Codex 能“看见”应用运行状态

OpenAI 很重视让应用对 Codex 可读。

他们让 Codex 能够：

• 启动隔离的本地应用实例；
• 用 Chrome DevTools 控制浏览器；
• 查看 DOM、截图、导航状态；
• 查询日志、指标和 trace；
• 复现 bug；
• 修复后再次验证。

如果 Codex 只能读代码，它其实是在猜：

这个按钮大概能用吧。

如果 Codex 能打开浏览器点按钮，它就能验证：

我点了按钮，页面真的跳转了吗？日志有没有报错？接口有没有超时？

可以类比成：

以前是让学生只看菜谱判断菜好不好吃；现在是让他真的做一遍、尝一口、再改配方。

5.5 Harness 自改进闭环：把失败变成下一轮规则

OpenAI 的实践里，一个很关键的点是：当 Codex 出错时，团队不是简单地让它“再试一次”，而是把错误当成信号，反过来改进 harness。

原文中提到，Codex 失败时，人工程师会问：

当前缺少什么能力？怎样让这个能力对 Agent 可见，并且能被强制执行？

也就是说，问题不是停留在一次评论里，而是会被沉淀到仓库、文档、工具或检查流程中。

这形成了一个自改进闭环：

Agent遇到困难 ↓ 识别缺失能力 ↓ 编写修复代码 ↓ Harness改进

这个闭环的价值在于：人类不是反复提醒同一个问题，而是把一次判断转化为长期有效的系统能力。

并且，后台 Agent 会定期扫描偏离规则的地方、更新质量评分及时清理过期文档。这有点像“垃圾回收”：不是等技术债堆到很严重再人工大清理，而是持续、小步地清理，让代码库保持对后续 Agent 可读、可维护。

所以这里的 harness 不只是静态工具箱，而是一个会被不断改进的工程系统。Codex 做得越多，暴露的问题越多；这些问题被沉淀进 harness 后，下一轮 Codex 就更不容易犯同样的错。

5.6 OpenAI 案例的启发

OpenAI 的实践说明：

1. AI 编码的关键不只是模型强，而是环境强。
2. 仓库要变成 Agent 的知识中心。
3. 规则要从“口头提醒”升级为“自动检查”。
4. 日志、指标、浏览器状态要对 Agent 可见。
5. 人类注意力最稀缺，应尽量交给高价值判断。

6. OpenAI 和 Anthropic 的共同点与差异

6.1 共同点

两家公司虽然实现方式不同，但有几个共同判断：

1. 不能只靠模型本身

模型再强，也需要环境、规则、工具和反馈。

2. 长期任务必须有外部状态

只靠聊天上下文不够，必须有进度文件、Git 历史、功能清单、文档。

3. Agent 必须能验证真实结果

只读代码不够，要能跑测试、看日志、打开浏览器、观察真实页面。

4. 减少人工检查干预

不能让人类盯每一个细节，要让系统自动发现和反馈问题。

5. Harness 会随模型进步而变化

Anthropic 特别强调：模型变强后，某些模块可能不再需要。Harness 不是越复杂越好，而是要持续调整。

6.2 差异

OpenAI 的重点像是在建设一座“AI 软件工厂”：Codex 可以读文档、写代码、跑测试、看日志、开 PR、修复问题。

Anthropic 的重点像是在设计一套“长跑接力机制”：Claude 一轮接一轮工作时，不会忘记进度，不会过早宣布完成，也能通过独立评价者获得更严格反馈。

7. 思考

7.1 未来重要的不是“让 AI 写更多”，而是“让 AI 写得可控”

很多人看到 AI 写代码很快，会兴奋于速度。但速度越快，风险也越大。

如果一个 Agent 一小时生成几千行代码，却没有测试、没有文档、没有边界，那可能不是生产力，而是技术债制造机。

Harness Engineering 给我的提醒是：

AI 时代的工程能力，不只是生成能力，而是控制生成结果的能力。

7.2 工程师角色会更像“教练 + 架构师 + 质检负责人”

未来工程师可能不一定亲手写每一行代码，但要会：

• 定义任务；
• 设计目录；
• 写清验收标准；
• 设计自动测试；
• 规定架构边界；
• 分配 Agent 权限；
• 判断哪些问题必须人工确认。

这其实要求更高，而不是更低。

7.3 很多 AI 产品正在长得越来越像

视频里还有一个有趣观察：很多 AI 产品都在往类似形态收敛。

例如：

• Cursor 让多个 coding agent 在同一工作区协作；
• Claude Code / Managed Agents 提供长期运行和托管能力；
• Codex 强调代码仓库、工具、PR、测试循环；
• 企业产品都开始接入记忆、工具、权限、评估和日志。

原因是：当 AI 从聊天变成做事，大家都需要类似的核心循环：

目标 -> 上下文 -> 模型推理 -> 工具执行 -> 观察结果 -> 反馈修正 -> 继续执行

所以 Harness Engineering 不只是一个技术词，它也反映了 AI 产品形态的变化。

7.4 学生项目也可以有最小 Harness

Harness Engineering 不只是 OpenAI、Anthropic 这样的大公司才做。学生项目也可以做一个小版本。

一个最小 harness 可以很简单：

README.md：项目是什么，怎么运行 TASKS.md：当前任务和完成状态 AGENTS.md：AI 需要遵守的规则 tests/：最基本的自动测试 scripts/check.ps1：一键检查命令 progress.md：每次修改记录

这样即使换一个同学或换一个 AI，也能接着做。

7.5 Harness 本身也要迭代

Anthropic 提醒我一个很重要的点：Harness 不是越复杂越好。

当模型变强，某些规则可能过时；当任务变简单，复杂 evaluator 可能浪费成本。

所以要持续问：

• 这个检查真的有用吗？
• 这个文档 Agent 真的会读吗？
• 这个流程是不是太重了？
• 哪些错误反复出现，值得写成工具？

8. 总结

Harness Engineering 不是一个玄学概念，它解决的是一个很现实的问题：

当 AI 从“回答问题”变成“长期做事”，我们怎么保证它不迷路、不乱改、不自我感觉良好？

Harness Engineering 就是给 AI Agent 搭工作台。以前我们关注 Prompt，后来关注 Context，现在 Agent 能自己写代码、跑测试、查日志、改 bug，所以我们更要关注它周围的系统。OpenAI 用 Codex 证明：当仓库、文档、架构边界、测试和反馈循环都围绕 Agent 设计时，AI 可以参与真实产品级开发。Anthropic 则证明：长程 Agent 要想可靠工作，必须有进度记录、功能清单、浏览器验证和独立评价。未来会用 AI 的人，不只是会提问的人，而是会设计 AI 工作环境的人。

参考资料

1. YouTube,Harness Engineering 101
   https://www.youtube.com/watch?v=Xq-s_hAjADw

2. OpenAI,Harness engineering: leveraging Codex in an agent-first world
   https://openai.com/index/harness-engineering/

3. Anthropic,Effective harnesses for long-running agents
   https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

4. Anthropic,Harness design for long-running application development
   https://www.anthropic.com/engineering/harness-design-long-running-apps

5. 微信文章资料
   https://mp.weixin.qq.com/s/N7DkjXVoz4QIstMZSxRCcg

6. 新浪财经转载，刺猬公社，《火爆全网的 Harness Engineering 到底是个啥》
   https://finance.sina.com.cn/wm/2026-04-16/doc-inhuryef7804816.shtml

7. bilibili，最近爆火的 Harness Engineering 到底是啥？一期讲透！
   https://www.bilibili.com/video/BV1Zk9FBwELs/?spm_id_from=333.337.search-card.all.click&vd_source=87eaca25baffc2daf328728a1189acdd