看了好几个内容：
https://openai.com/zh-Hans-CN/index/harness-engineering/
https://github.com/walkinglabs/learn-harness-engineering/blob/main/README-CN.md
還有最近 宝玉也有和原作有争论的内容
https://baoyu.io/blog/2026-04-13/ai-first
这几个内容后，該怎样实践 Harness ？ 有别于 specs, vibe 这種 现有些项目可以尝试进行 Harness 工程？
对于后端 API 服务的话我可以理解怎样做，我认为 有需求，让 AI 處理需求，在提交 PR 时可以做单元测試，再加个定时器做全量的测試，
但是像 前端 项目这種又是怎样做的？
带着好奇心恳请教各位 V2 的大大 ORZ
https://openai.com/zh-Hans-CN/index/harness-engineering/
https://github.com/walkinglabs/learn-harness-engineering/blob/main/README-CN.md
還有最近 宝玉也有和原作有争论的内容
https://baoyu.io/blog/2026-04-13/ai-first
这几个内容后，該怎样实践 Harness ？ 有别于 specs, vibe 这種 现有些项目可以尝试进行 Harness 工程？
对于后端 API 服务的话我可以理解怎样做，我认为 有需求，让 AI 處理需求，在提交 PR 时可以做单元测試，再加个定时器做全量的测試，
但是像 前端 项目这種又是怎样做的？
带着好奇心恳请教各位 V2 的大大 ORZ
 |
1
mooncakeSec 18 小时 9 分钟前
核心目标是通过约束验证保证质量吧，因为人的注意力在 ai coding 中是无法提升的瓶颈，要放弃 review
|
 |
2
kenshinhu OP @mooncakeSec 我看到的实践都是哪里是卡在人类的就用 AI 介入，如果不能完全介入就是人类和 Agent 协助。
从工具层来看還是需要人类精心安排吧？ |
 |
3
momogzp 18 小时 3 分钟前
https://github.com/shareAI-lab/learn-claude-code/blob/main/README-zh.md
这个, 看完理解了一些 AI 的操作. 然后在此基础上可以更容易搞一些, 比如 subagent,task 啥的. |
|
4
kenshinhu OP @momogzp 对的，这个也有看过，可以对整个 Agent 的處理流有更深入的了解。同时我在想，如果现在有新的业务要做新的项目，該怎样可以让 Agent 在预期来完成需求（而不是有 人类介入 vibe 这種）
|
 |
5
NoobNoob030 17 小时 49 分钟前
我之前遇到了跟你一样的困惑： https://www.v2ex.com/t/1202411
我在阅读了许多相关文章和项目之后，看的云里雾里，似懂非懂。然后我带着模糊的概念，直接进入实战，尝试各种框架（ superpowers ，gstack ，gsd ，openspec ，omo ......），用过才知道咸淡。 我建议直接实践一个项目，只是问和看却不做，很难构建出清晰的认知 |
 |
6
glacer 17 小时 48 分钟前
还是 TDD 那一套，要将需求边界、测试用例确定后再进行开发
|
|
7
kenshinhu OP @NoobNoob030 我的了解不知道是不是这样子的，請大佬指点业下：
我觉得是这个概念不能是从工具出发，是从原来的软件工程通过 AI 来介入。 人类在 harness 相当于一个布道者，前期理多的是在工具是怎样配置，如在 github actions 中配置好相关的 Agent 介入，如果有测式工具就接入； 所以我在想当于有一个新的需求时，把需求定义好，分 里程->phase->PR 这个處理，人类做功能的验证：说白了就是做在测試，按界面/数据事件触发看看是否已对齐 |
 |
9
mangmaimu 17 小时 30 分钟前
最后这篇不错，符合我对 ai 构想
|
|
10
mooncakeSec 17 小时 29 分钟前
@kenshinhu 是的，人的角色从开发变成为 ai 搭建开发环境，业务约束，验收标准这些
|
|
11
NoobNoob030 17 小时 28 分钟前
@kenshinhu #7 我理解 harness 是能让 AI 更好的完成任务的一套架构，针对不同需求，架构的内容也不同。如果理解成字面意义上的“马具”，那么“需求定义”“自动化执行”“多 agent 交互”这些就相当于“缰绳、马鞍”，你提到的“把需求定义好，分 里程->phase->PR ”也能算是 harness 。
|
 |
12
DICK23 17 小时 2 分钟前
看的云里雾里
|
 |
13
darksword21 PRO 只能说老外挺能发明概念的
我理解所谓的 harness 是不是就是之前就有的帮助 llm 处理的东西，现在把他们打包称为 harness ？ |
|
14
kenshinhu OP @NoobNoob030
是的，我在思考是否需要把工具体系从“人类使用”转为“Agent 可编排”的视角重新设计。 例如测试工具如果具备完善的 CLI 接口，就可以被纳入 CI/CD 流程， 并进一步作为 Agent 的可调用能力，由 Agent 进行调度和控制。 从工程结构来看，这一层本质上就是 harness ， 即对工具、执行流程和反馈机制的统一编排系统，而不是单一工具本身。 它不是前期任务，而是 Agent 能否稳定运行的基础设施。 還是通过一个 todos h5 的 webapp 試試过，還需要是实践一下才知道是怎么一回事 |
 |
15
Clannad0708 16 小时 53 分钟前
我来回答你把，在这个概念火之前，有个 cursor 的工程师来做分享。说他们内部做了大量的工程来实现 harness 。这个东西在我看来就是一套“规则说明” 他不是某个具体的框架或者技术，而是说一系列的包括提示词 prompt ，边界约束，工具描述等。一系列相关的东西来对 agent 进行 规则说明。 你要做的不是 直接告诉他 帮我实现 xxx 功能，而是详细的描述这个功能是什么样的，怎么测试他是否正常。通过一系列的 精雕细刻的设置说明和限制以及你的期望。他就能工作的更好
|
|
16
kenshinhu OP @Clannad0708 对这个我也想过是否是通过 prompt 来驱动，但这样整 个 LOOP 還是需要 人类介入，就如描述 好了让 Agent 處理，把他的结果看一下，再把瑕疵的地方再輸入新的 Prompt 再處理最后这样好像又变化
人类 -> Agent -> 人类 -> Agent 这相环节； |
 |
17
huaweii 15 小时 10 分钟前 via Android
openai 是站在商业公司的立场，宝玉是在站在高级打工人的立场。
|
 |
18
sqlNice 14 小时 16 分钟前
我最近也在实践，目前项目是微前端架构。
1.完善所有的 ts+ tslint + eslint 2.统一所有应用的基建层 3.各种业务 skill 4.skill 生成的文件增加 skill-artifacts.json 文件做索引，后续 AI 修改过程中涉及到对应的文件则提示用户 [是否迭代 skill] 5.增加 hook （强制 lint 校验） 6.完善 doc 以及子应用之间常用的业务关系 总结：如果在使用 AI 过程中产生了手动修改代码的行为，那么这个行为都视为应该改为 skill 或增加自动化流程。 缺陷：vue2 项目没法做单元测试，目前只能把报错扼杀在发布之前。 |
|
19
sqlNice 14 小时 12 分钟前
我是如何开始的：
- 我大概搜罗了七八篇 harness 相关的文章，openAI cc vercel 等官方的 blog - 参考 x 比较火的 LLM wiki ，总结这些文章，出一个在前端项目中如何探索 harness - 列 plan 一项项去实施 - 旧项目改造了四五天，目前还没完 后续： - 想着增加 jenkins 后反馈，基建/类型报错就直接让他改，业务相关的没办法只能人来 |
 |
20
beimenjun PRO |
 |
21
fennu2333 13 小时 53 分钟前
正好我昨天也发了一篇自己的实践： https://v2ex.com/t/1205752
我的理解是 Harness 在于给 Agent 构造外部环境和约束，让 Agent 能在你制定的规则下满足你某个垂直领域的需求，写 Skill ，CC 插件 等等手法最终的目的还是让 Agent 能更好地遵从你的工作流程来真正创造价值 有兴趣也可以看下最近比较火的一篇 Harness 综述 https://v2ex.com/t/1206029 |
|
22
kenshinhu OP @sqlNice 有感而发，旧项目使用 harness 才有价值，新项目使用 harness 就好像有點带偏。可能 specs + TDD 也够。 旧项目的话更多是需要对旧有的代碼和业务 有个归纳，这个过程 中肯定 会有一些细节的损失，需要好次迭代才能也旧项目拉到一个新的高度，当然旧有的项目是意大利面条这種的就另说了，可能 重新再做会更快
|
 |
23
joyyu 13 小时 31 分钟前
Harness 本质还是围绕构建稳定可靠 Agent 的工程，和 web 开发没很大关系。
新的 web 应用开发范式主要是基于现有的 Claude Code 、Codex 之类 Coding Agent 构建而生的 SDD TDD 之类的概念。 |
 |
24
qianxaingmoli 12 小时 42 分钟前
我的理解以及实践是，harness 是针对 llm 驱动的 agent ，langgraph 这种始终是 workflow 框架，束缚 llm 。
loop 要由 agent 管理，让它自己管理 subagent 。我把有些 agent 做成了 cli 的形式，给到 agent 自己去管理运用，而不是 agent 编排。自行管理记忆，保存 trace 。agent 自己观测，然后自进化。 按照业务进行深耕，在有限的上下文内，优化 cli 和记忆，agent 获取到更相关的东西。 而 harness 就是针对这种形式的最小化约束，比如合适的控制模式、渐进式披露、更合适的 cli(agent-friendly)，引导约束 agent 在规范内自主运行，能获得很意外的智能涌现。 |
 |
26
wangxinpier 11 小时 27 分钟前
这个太好了，还在学习中，感谢你的提问
|
 |
27
NizumaEiji 11 小时 21 分钟前
感觉概念都是看的云里雾里的，目前学到的一个点就是强约束若约定。简单说就是你对 ai 提的要求它未必遵守，所以所有的要求都要有对应的约束去限制，
比如要保证生成的代码可用，加个 hook ，修改完代码自动编译启动。 要求代码质量就是改完代码走一次类似的 sonar 之类的检测。 hook 执行失败直接把错误信息提交给 ai ，让去修改直到问题解决。 |
 |
28
xiaomushen 11 小时 20 分钟前
宝玉的文章不错，上次和他吃火锅，还是 2008 年时候的事儿了
|
 |
29
Huyii 11 小时 15 分钟前
楼上说得对，harness 是用在 agent 上的，有个公式是：agent = harness + model 。不过我还是不太清楚如何工程实践它，挺模糊的
|
 |
30
YanSeven 11 小时 14 分钟前
@darksword21 我也这么理解的，就是围绕 prompt 和软件工程实践做的升级和打包概念。即在上下文窗口的约束之下，通过 prompt 管理来让 llm 践行软件工程最佳实践。
|
|
31
kenshinhu OP @NizumaEiji 这就是人机协助的情況吧，仅是人类做了指导员，整个 LOOP 人类的比重還是高于 AI 的
|
|
32
kenshinhu OP @Huyii 因为我一直在想，harness + model 是怎样處理需求精细化的，就像 前端 （ APP / H5 ） 里有很多细节，这種還是需要人类介入比例比较 重的，但对于像 agent 这種就真的控制 好边界就可以了
|
|
34
NizumaEiji 10 小时 39 分钟前
@kenshinhu #31
hook 都是自动触发的，错误信息可以在 function call 的过程中以结果的形式反馈给 llm 。 这个和开发者在 vibe coding 中的比重没啥关系吧，比重这个东西和你的规则和项目的适配度有关，最开始规则不够适配，只能边写边调。 |
 |
35
OXOYO 10 小时 30 分钟前
我浅薄了
|
 |
36
meeop 9 小时 34 分钟前
对于大部分人来说，你什么都不用做，等待 agent 自己升级就行，你做什么大概率都会被快速追赶。
爱折腾的，最多装一下比如 superpowers ，on-my-xxx 系列开源封装好的 harness |
 |
37
bytesfold 8 小时 15 分钟前 via iPhone
我已经做了两套 harness 了，
- 第一套去年 9 月开始做的，跟 2 月 codex 的文章 90%相似 - 第二套上个月做的，已经上生产了。 |
Select Language