1

核心目标是通过约束验证保证质量吧，因为人的注意力在 ai coding 中是无法提升的瓶颈，要放弃 review

2

@mooncakeSec 我看到的实践都是哪里是卡在人类的就用 AI 介入，如果不能完全介入就是人类和 Agent 协助。
从工具层来看還是需要人类精心安排吧？

4

@momogzp 对的，这个也有看过，可以对整个 Agent 的處理流有更深入的了解。同时我在想，如果现在有新的业务要做新的项目，該怎样可以让 Agent 在预期来完成需求（而不是有 人类介入 vibe 这種）

5

6

1

还是 TDD 那一套，要将需求边界、测试用例确定后再进行开发

7

@NoobNoob030 我的了解不知道是不是这样子的，請大佬指点业下：
我觉得是这个概念不能是从工具出发，是从原来的软件工程通过 AI 来介入。
人类在 harness 相当于一个布道者，前期理多的是在工具是怎样配置，如在 github actions 中配置好相关的 Agent 介入，如果有测式工具就接入；
所以我在想当于有一个新的需求时，把需求定义好，分 里程->phase->PR 这个處理，人类做功能的验证：说白了就是做在测試，按界面/数据事件触发看看是否已对齐

11

@kenshinhu #7 我理解 harness 是能让 AI 更好的完成任务的一套架构，针对不同需求，架构的内容也不同。如果理解成字面意义上的“马具”，那么“需求定义”“自动化执行”“多 agent 交互”这些就相当于“缰绳、马鞍”，你提到的“把需求定义好，分 里程->phase->PR ”也能算是 harness 。

13

14

15

我来回答你把，在这个概念火之前，有个 cursor 的工程师来做分享。说他们内部做了大量的工程来实现 harness 。这个东西在我看来就是一套“规则说明” 他不是某个具体的框架或者技术，而是说一系列的包括提示词 prompt ，边界约束，工具描述等。一系列相关的东西来对 agent 进行 规则说明。 你要做的不是 直接告诉他 帮我实现 xxx 功能，而是详细的描述这个功能是什么样的，怎么测试他是否正常。通过一系列的 精雕细刻的设置说明和限制以及你的期望。他就能工作的更好

16

@Clannad0708 对这个我也想过是否是通过 prompt 来驱动，但这样整 个 LOOP 還是需要 人类介入，就如描述 好了让 Agent 處理，把他的结果看一下，再把瑕疵的地方再輸入新的 Prompt 再處理最后这样好像又变化
人类 -> Agent -> 人类 -> Agent 这相环节；

17

openai 是站在商业公司的立场，宝玉是在站在高级打工人的立场。

18

19

22

@sqlNice 有感而发，旧项目使用 harness 才有价值，新项目使用 harness 就好像有點带偏。可能 specs + TDD 也够。 旧项目的话更多是需要对旧有的代碼和业务 有个归纳，这个过程 中肯定 会有一些细节的损失，需要好次迭代才能也旧项目拉到一个新的高度，当然旧有的项目是意大利面条这種的就另说了，可能 重新再做会更快

23

Harness 本质还是围绕构建稳定可靠 Agent 的工程，和 web 开发没很大关系。
新的 web 应用开发范式主要是基于现有的 Claude Code 、Codex 之类 Coding Agent 构建而生的 SDD TDD 之类的概念。

24

我的理解以及实践是，harness 是针对 llm 驱动的 agent ，langgraph 这种始终是 workflow 框架，束缚 llm 。
loop 要由 agent 管理，让它自己管理 subagent 。我把有些 agent 做成了 cli 的形式，给到 agent 自己去管理运用，而不是 agent 编排。自行管理记忆，保存 trace 。agent 自己观测，然后自进化。
按照业务进行深耕，在有限的上下文内，优化 cli 和记忆，agent 获取到更相关的东西。
而 harness 就是针对这种形式的最小化约束，比如合适的控制模式、渐进式披露、更合适的 cli(agent-friendly)，引导约束 agent 在规范内自主运行，能获得很意外的智能涌现。

27

感觉概念都是看的云里雾里的，目前学到的一个点就是强约束若约定。简单说就是你对 ai 提的要求它未必遵守，所以所有的要求都要有对应的约束去限制，
比如要保证生成的代码可用，加个 hook ，修改完代码自动编译启动。
要求代码质量就是改完代码走一次类似的 sonar 之类的检测。
hook 执行失败直接把错误信息提交给 ai ，让去修改直到问题解决。

28

宝玉的文章不错，上次和他吃火锅，还是 2008 年时候的事儿了

29

楼上说得对，harness 是用在 agent 上的，有个公式是：agent = harness + model 。不过我还是不太清楚如何工程实践它，挺模糊的

30

@darksword21 我也这么理解的，就是围绕 prompt 和软件工程实践做的升级和打包概念。即在上下文窗口的约束之下，通过 prompt 管理来让 llm 践行软件工程最佳实践。

32

@Huyii 因为我一直在想，harness + model 是怎样處理需求精细化的，就像 前端 （ APP / H5 ） 里有很多细节，这種還是需要人类介入比例比较 重的，但对于像 agent 这種就真的控制 好边界就可以了

33

@YanSeven 所以我在想，未来如果 上下文窗口 可以有现在好几百倍的容器，是否现在的 Agent 理论都仅是过渡式

34

@kenshinhu #31
hook 都是自动触发的，错误信息可以在 function call 的过程中以结果的形式反馈给 llm 。
这个和开发者在 vibe coding 中的比重没啥关系吧，比重这个东西和你的规则和项目的适配度有关，最开始规则不够适配，只能边写边调。

36

对于大部分人来说，你什么都不用做，等待 agent 自己升级就行，你做什么大概率都会被快速追赶。
爱折腾的，最多装一下比如 superpowers ，on-my-xxx 系列开源封装好的 harness

37

我已经做了两套 harness 了，
- 第一套去年 9 月开始做的，跟 2 月 codex 的文章 90%相似
- 第二套上个月做的，已经上生产了。

39

规则约束，行为验证，任何结果都给反馈。

40

我理解 harness 就是在一定程度上践行 PDCA 循环