Harness 工程的基本理解与Multi-Agent系统的区别
- 内容介绍
- 文章标签
- 相关推荐
前篇
【长期贴】开个帖子，分享一下我自己是如何做harness【已更新完成，等待交作业，后续再有新想法再补充】 开发调优据网上传，目前Anthropic的所有产品均为harness模式，不过最近他们推了一个harness产品，原本把我吓了一跳，但实质一看，并不是干货，多少有点恶心人了，好东西都藏起来。我昨晚也成功验证了自己的第二个harness，工程量比是一开始做demo的100倍，平均跑完要30-50M token，10个小时左右(glm-5)，并且效果还挺好。不过还是有很多优化点的，这也正是本贴的由来，在接下来…
说在前面
秉持先上手，再解惑的方式，有了这篇文章，距离上篇文章已经快有半个月了，我想已经有一些佬已有harness成品了，不过大家或多或少肯定有一些问题，希望这篇博客能够回应到你。（回应不了我也不负责了 ）
之前harness 理论是经过50多亿token的实践与各大AI厂商分享的文章总结出来的harness架构设计。距离上面这篇文章已经过去快半个月了，没想到的是，我这是又花了大量的token，这次因为太频繁了，导致我根本没有时间去统计token使用量，光今天就花了近3亿token，当然不是一台电脑。
根据标题可以得知，今天重点讨论的是harness架构与multi-agent的架构的区别，有的佬可能会说，这不是很明显的区别么，这还能有什么分不清的。甚至有的佬可能会说，harness难道不是基于multi-agent之上的架构设计么。
因为众说纷纭，所以我在此也叠个甲，本篇博客仅为个人经验总结，不具备代表性，仅做参考，能帮到佬我就很高兴了。
先说结论：harness架构与multi-agent只是形式相似，而并不是谁基于谁的关系。这一句话已经突破上一段话的两个问题了，也算一个回应，听我娓娓道来。
harness架构本质是一种编程大模型的开发环境
harness架构就是一个编程大模型的IDE，如果java生态中的Eclipse、IDEA，node生态中的vscode、WebStorm等。而编程大模型就相当于程序员，只不过这个程序员能力特别强大，对各种算法、各种语法、各种通信协议都信手拈来。然而IDE提供程序员的方便是什么：
- 便利的依赖引用环境
- 规范的检测地
- 编程过程的可视化
- 调试自测的温床
那同样，harness为编程大模型提供也就是这些内容了。话说到这，想顺便说一句，harness提供了这么多作用，是必要的么。我想说一句，目前来说，肯定是的。为什么，第一，现在编程大模型只具备生成代码能力和架构设计能力和推理能力，但是严重缺乏总结能力，目前我体验的任意编程大模型，即使新出的v4-pro-max也是一样。所谓的总结能力是指什么，换到程序员身上来说，就是编程自嗨，盲目自信，0测试上线，而丢失了其它模块的考虑。
而我们为什么要使用编程大模型呢，其实根本原因也是因为他编程能力足够强大，但是不受约束，所以这里点出来harness的唯一中心思想：对编程大模型进行约束
如何约束呢，到这里，也就开始在解答第二个问题了，请各位佬继续耐心的看下去。
众佬都知，harness是领域型的，harness是不可跨领域复用的。那我们在设计harness的第一要素，就是要确认我们设计的这个harness是应用在哪个领域的，比如我设计是的web应用领域，那我要给大模型上的第一道约束就是，你的能力及知识，以web应用开发为边界，这时让大模型微缩成领域大模型，所有的思想、注意力都需要被限制在该范围内，对比这第一道限制怎么下呢，也就是启动harness架构时，这时映射到上篇博客的command。
再者，聪明的佬肯定就有新问题了，然后呢？
然后当然是再根据大模型的问题进行讨论，由于我们不知道大模型到底是会怎么开始开发一个web应用的，那我们就先不让他自主发挥了，我们按照计科的工程思维来。为啥非要按这个来，因为我们之前在体验vide coding的时候，其实内心已经发现，大模型不具备工程化思维，而聪明的佬肯定知道，如果要做好一个web应用，必须要工程化的完成，要不然就是一坨，但是这里同样也要讲一点。
大模型的工程化不适合复杂化
大模型的工程化不适合复杂化的原因很简单，长上下文会让大模型变成智障。我以往的博客也有说过，为什么我把harness的工程的七个智能体压缩成三个智能化，原因同样也在于此。基于这些经验总结，我们要把现实工程化再度抽象化，我个人抽象的成果就是规划、生成、验证，这恰巧恰巧对应上了Anthropic（骂归骂，别人干货是真的分享）、Close AI、思特沃克对harness架构的思考及总结，我想这可能是大家对于工程化最简洁的具体表现的共识吧。这里就是第二道约束——工程约束
harness架构与multi-agent架构的区别
说到这，我已经自然而然的引出来了三个智能体，不知道各位佬发现没有。不过呢，在harness架构里面，规则、生成、验证，却并非一定要是智能体，这里可是是个skill，可以是个hook，甚至可以是个tool，这里面的三个智能体，只是一个责任体，只是一个worker，可以是任何形式，只要能够利用大模型的能力完成指定职责就OK。目前来说，刚好智能体所具备的能力与当下harness架构的职责体（我先这么定义哈，反正也没人定义过）比较贴近，就顺手主义拿来用了，然而multi-agent的设计思想是agent为主的，区别就是在于这里。
回顾上篇博客，细心佬友肯定能发现，我这智能体定义得一坨，怎么连流程化、思考模型、都不给，完全就是一个执行器，就不是一个智能体。对了，这就是harness需要的，这也就是第三道约束——执行约束。我要求智能体按照我完全预定义的内容进行随意发挥，这句话怎么理解呢，就是我要模型只能按照我的意愿在我指定的范围内，充分发挥他的能力。第一个阶段是规划，我现在需要他帮我规划一个web应用的实现路径了，他比我的优势就是他的灵活思维和庞大的知识库，那好，你就在充分利用你灵活的思维和庞大的知识库，在我指定的什么类型的web应用这个话题上充分帮我设计，同样这句话也可以应用上生成、验证。
以上就是本篇的全部内容了，欢迎佬们再次验证，等佬交作业。
参考资料：
Scaling Managed Agents: Decoupling the brain from the hands
Anthropic is an AI safety and research company that's working to build reliable, interpretable, and steerable AI systems.
https://openai.com/zh-Hans-CN/index/the-next-evolution-of-the-agents-sdk/
网友解答：--【壹】--：
佬友写得很好啊，Harness 就是大模型的 IDE，这个观点很新颖
前篇
【长期贴】开个帖子，分享一下我自己是如何做harness【已更新完成，等待交作业，后续再有新想法再补充】 开发调优据网上传，目前Anthropic的所有产品均为harness模式，不过最近他们推了一个harness产品，原本把我吓了一跳，但实质一看，并不是干货，多少有点恶心人了，好东西都藏起来。我昨晚也成功验证了自己的第二个harness，工程量比是一开始做demo的100倍，平均跑完要30-50M token，10个小时左右(glm-5)，并且效果还挺好。不过还是有很多优化点的，这也正是本贴的由来，在接下来…
说在前面
秉持先上手，再解惑的方式，有了这篇文章，距离上篇文章已经快有半个月了，我想已经有一些佬已有harness成品了，不过大家或多或少肯定有一些问题，希望这篇博客能够回应到你。（回应不了我也不负责了 ）
之前harness 理论是经过50多亿token的实践与各大AI厂商分享的文章总结出来的harness架构设计。距离上面这篇文章已经过去快半个月了，没想到的是，我这是又花了大量的token，这次因为太频繁了，导致我根本没有时间去统计token使用量，光今天就花了近3亿token，当然不是一台电脑。
根据标题可以得知，今天重点讨论的是harness架构与multi-agent的架构的区别，有的佬可能会说，这不是很明显的区别么，这还能有什么分不清的。甚至有的佬可能会说，harness难道不是基于multi-agent之上的架构设计么。
因为众说纷纭，所以我在此也叠个甲，本篇博客仅为个人经验总结，不具备代表性，仅做参考，能帮到佬我就很高兴了。
先说结论：harness架构与multi-agent只是形式相似，而并不是谁基于谁的关系。这一句话已经突破上一段话的两个问题了，也算一个回应，听我娓娓道来。
harness架构本质是一种编程大模型的开发环境
harness架构就是一个编程大模型的IDE，如果java生态中的Eclipse、IDEA，node生态中的vscode、WebStorm等。而编程大模型就相当于程序员，只不过这个程序员能力特别强大，对各种算法、各种语法、各种通信协议都信手拈来。然而IDE提供程序员的方便是什么：
- 便利的依赖引用环境
- 规范的检测地
- 编程过程的可视化
- 调试自测的温床
那同样，harness为编程大模型提供也就是这些内容了。话说到这，想顺便说一句，harness提供了这么多作用，是必要的么。我想说一句，目前来说，肯定是的。为什么，第一，现在编程大模型只具备生成代码能力和架构设计能力和推理能力，但是严重缺乏总结能力，目前我体验的任意编程大模型，即使新出的v4-pro-max也是一样。所谓的总结能力是指什么，换到程序员身上来说，就是编程自嗨，盲目自信，0测试上线，而丢失了其它模块的考虑。
而我们为什么要使用编程大模型呢，其实根本原因也是因为他编程能力足够强大，但是不受约束，所以这里点出来harness的唯一中心思想：对编程大模型进行约束
如何约束呢，到这里，也就开始在解答第二个问题了，请各位佬继续耐心的看下去。
众佬都知，harness是领域型的，harness是不可跨领域复用的。那我们在设计harness的第一要素，就是要确认我们设计的这个harness是应用在哪个领域的，比如我设计是的web应用领域，那我要给大模型上的第一道约束就是，你的能力及知识，以web应用开发为边界，这时让大模型微缩成领域大模型，所有的思想、注意力都需要被限制在该范围内，对比这第一道限制怎么下呢，也就是启动harness架构时，这时映射到上篇博客的command。
再者，聪明的佬肯定就有新问题了，然后呢？
然后当然是再根据大模型的问题进行讨论，由于我们不知道大模型到底是会怎么开始开发一个web应用的，那我们就先不让他自主发挥了，我们按照计科的工程思维来。为啥非要按这个来，因为我们之前在体验vide coding的时候，其实内心已经发现，大模型不具备工程化思维，而聪明的佬肯定知道，如果要做好一个web应用，必须要工程化的完成，要不然就是一坨，但是这里同样也要讲一点。
大模型的工程化不适合复杂化
大模型的工程化不适合复杂化的原因很简单，长上下文会让大模型变成智障。我以往的博客也有说过，为什么我把harness的工程的七个智能体压缩成三个智能化，原因同样也在于此。基于这些经验总结，我们要把现实工程化再度抽象化，我个人抽象的成果就是规划、生成、验证，这恰巧恰巧对应上了Anthropic（骂归骂，别人干货是真的分享）、Close AI、思特沃克对harness架构的思考及总结，我想这可能是大家对于工程化最简洁的具体表现的共识吧。这里就是第二道约束——工程约束
harness架构与multi-agent架构的区别
说到这，我已经自然而然的引出来了三个智能体，不知道各位佬发现没有。不过呢，在harness架构里面，规则、生成、验证，却并非一定要是智能体，这里可是是个skill，可以是个hook，甚至可以是个tool，这里面的三个智能体，只是一个责任体，只是一个worker，可以是任何形式，只要能够利用大模型的能力完成指定职责就OK。目前来说，刚好智能体所具备的能力与当下harness架构的职责体（我先这么定义哈，反正也没人定义过）比较贴近，就顺手主义拿来用了，然而multi-agent的设计思想是agent为主的，区别就是在于这里。
回顾上篇博客，细心佬友肯定能发现，我这智能体定义得一坨，怎么连流程化、思考模型、都不给，完全就是一个执行器，就不是一个智能体。对了，这就是harness需要的，这也就是第三道约束——执行约束。我要求智能体按照我完全预定义的内容进行随意发挥，这句话怎么理解呢，就是我要模型只能按照我的意愿在我指定的范围内，充分发挥他的能力。第一个阶段是规划，我现在需要他帮我规划一个web应用的实现路径了，他比我的优势就是他的灵活思维和庞大的知识库，那好，你就在充分利用你灵活的思维和庞大的知识库，在我指定的什么类型的web应用这个话题上充分帮我设计，同样这句话也可以应用上生成、验证。
以上就是本篇的全部内容了，欢迎佬们再次验证，等佬交作业。
参考资料：
Scaling Managed Agents: Decoupling the brain from the hands
Anthropic is an AI safety and research company that's working to build reliable, interpretable, and steerable AI systems.
https://openai.com/zh-Hans-CN/index/the-next-evolution-of-the-agents-sdk/
网友解答：--【壹】--：
佬友写得很好啊，Harness 就是大模型的 IDE，这个观点很新颖