一个关于harness大胆预测
- 内容介绍
- 文章标签
- 相关推荐
最近harness各位是不是很迷茫，上一秒我还在到处跟同事吹SDD,spec-kit,bmad还没缓过来它就一下子跳出来了；harness似乎当下只是一个工程化方法论，至少目前我还没看到一个成熟的体系框架；按照我个人理解，完整harness需要拥有以下的东西，大胆预测以下，未来会不会把下面的东西做成插件，每一个都可以动态加载与替代，毕竟harness是属于工程化的东西，是需要经过实践才知道哪种最好最适合，不是一层不变的。举个例子就是，调度核心可以使用crewAI，工具系统使用daytona，记忆系统可以使用mem0；甚至甚至调度核心里面的任务拆分可以换成不同SDD，例如bmad spec-kit，然后比对不同的方案效果
- 调度核心 任务规划与协调，决策加载什么上下文（包括别的任务记忆），跨任务协作。 例如 CrewAI Temporal
- 工具系统 维护工具动态注册表 （mcp skill hook tool）与工具权限系统 沙箱环境。例如虚拟机沙箱 E2B
- 状态管理 记忆的分层管理，长期记忆 项目记忆 任务过程记忆 任务会话记忆 代码规范 安全规范 架构设计 执行文档 规划文档 产品文档。例如 mem0 Zep
- 可观测和评估 这一个往往是大伙不注重的 包含一个评估任务完成与否的规则与体系和记录观测日志。例如 Arize Phoenix
- 差错恢复 差错恢复的时候是整体任务重新执行还是只是对任务中某个工具调用恢复
对了，对了，对了，各位老友上面都只是我个人对harness的理解，大伙有不同意见的一定要在下面评论。让佬友们一起研究讨论，还有还有我觉得还有一点很重要驾驭工程不仅仅用于coding，可用于任何领域；加油各位马车夫们！！！！！！
网友解答：--【壹】--：
我只要不学 这些概念和名词就会自己淘汰/被后来者覆盖
我这种除了read 所有都要approve的用法 我就是ai最严厉的奴隶主（不是
--【贰】--：
我觉得约束是要规定好agent可以完成什么任务，允许修改的范围，进行代码修改时需要遵循的规则，通过这三个方面来划定agent的能力边界，同时也可以使得宝贵的注意力资源能够针对性的全部用在开发者所期望的实现目标上。我觉得应该不止在上下文工程的范畴，比如工具链的调用也可以进行设计。
--【叁】--：
确实啊，其实如果要写是有一大堆东西的，不知道佬跟我理解的约束是一个东西不，我理解的约束是属于上下文工程里面的范畴，比如智能体设计方面的，我这里只写了harness新增的东西
--【肆】--：
没有未来，只有当下。就好像从前围绕模型开展的所有工程修补，新一代模型会把有效的吸收掉，或者模型公司会直接下场接管约束条件，然后卖出去。国外优秀的工程师会被模型公司收入员工名单。国内研究这个的，一点好处都捞不着。看着用就好，别花心思。模型迭代太快。
--【伍】--：
约束还是太重要了，不仅为了安全，还为了防止初期定下来可能还有呲漏的目标在多轮执行后逐渐偏离。这是我最近很想了解的方向。
--【陆】--：
我最近给自己的工程加上了很强的约束，主要是边界治理、代码体积控制和评测，质量提升不少，但有时候Agent还是会忘记一些规则需要我重新强调
--【柒】--：
我是新手小白，但是我觉得框架应该不会做的这么重。
--【捌】--：
其实我觉得可以考虑一下做好上下文隔离、优化工具描述或者使用multi-agent架构。Anthropic的这篇文章中描述到三种使用multi-agent的场景可能是符合你所担忧的。
When to use multi-agent systems (and when not to) | Claude
Most teams don't need multi-agent systems. Learn the three scenarios where they consistently outperform single agents—and how to implement them effectively.
image716×259 28.3 KB
--【玖】--：
感觉现在最大的问题就是任何agent长期跑下来，都慢慢的不听话了，或者动作行为跑偏了…… 约束多了，一轮下来就要多烧5-20万的token……
--【拾】--：
感觉可以补充一个约束，明确agent的能力边界以及禁止触摸的内容，保证安全性
--【拾壹】--：
大伙不都在研究中么，只不过harness只是提出了理论，就是只告诉我们要什么和目标，至于怎么搞，怎么做？好像没有很正确的说法，都是各方提出自己的实现甚至有好多硕士论文实践，等待开源社区百花齐放，就好像之前的SDD，有多个实现openspec spec-kit bmad等…
--【拾贰】--：
其实就算上下文没有瓶颈，llm也会很容易忘了前面的东西
--【拾叁】--：
我也经常遇到你说的agent忘记一些我设置的规则，这个真的好麻烦
--【拾肆】--：
其实这也是harness工程的目标，让agent能够长期稳定执行长项目 复杂项目，需要调度器去选择动态加载的需要的记忆给到当前会话中
--【拾伍】--： 野人不吃野菜:
决策加载什么上下文
感觉上下文会成为瓶颈，这会是比较重要的方向。我现在的做法是，使用子agent做为旁观者，在每个小的任务节点，不断用预期（需求文档）对比当前阶段产出，避免跑偏。就是比较浪费token。
最近harness各位是不是很迷茫，上一秒我还在到处跟同事吹SDD,spec-kit,bmad还没缓过来它就一下子跳出来了；harness似乎当下只是一个工程化方法论，至少目前我还没看到一个成熟的体系框架；按照我个人理解，完整harness需要拥有以下的东西，大胆预测以下，未来会不会把下面的东西做成插件，每一个都可以动态加载与替代，毕竟harness是属于工程化的东西，是需要经过实践才知道哪种最好最适合，不是一层不变的。举个例子就是，调度核心可以使用crewAI，工具系统使用daytona，记忆系统可以使用mem0；甚至甚至调度核心里面的任务拆分可以换成不同SDD，例如bmad spec-kit，然后比对不同的方案效果
- 调度核心 任务规划与协调，决策加载什么上下文（包括别的任务记忆），跨任务协作。 例如 CrewAI Temporal
- 工具系统 维护工具动态注册表 （mcp skill hook tool）与工具权限系统 沙箱环境。例如虚拟机沙箱 E2B
- 状态管理 记忆的分层管理，长期记忆 项目记忆 任务过程记忆 任务会话记忆 代码规范 安全规范 架构设计 执行文档 规划文档 产品文档。例如 mem0 Zep
- 可观测和评估 这一个往往是大伙不注重的 包含一个评估任务完成与否的规则与体系和记录观测日志。例如 Arize Phoenix
- 差错恢复 差错恢复的时候是整体任务重新执行还是只是对任务中某个工具调用恢复
对了，对了，对了，各位老友上面都只是我个人对harness的理解，大伙有不同意见的一定要在下面评论。让佬友们一起研究讨论，还有还有我觉得还有一点很重要驾驭工程不仅仅用于coding，可用于任何领域；加油各位马车夫们！！！！！！
网友解答：--【壹】--：
我只要不学 这些概念和名词就会自己淘汰/被后来者覆盖
我这种除了read 所有都要approve的用法 我就是ai最严厉的奴隶主（不是
--【贰】--：
我觉得约束是要规定好agent可以完成什么任务，允许修改的范围，进行代码修改时需要遵循的规则，通过这三个方面来划定agent的能力边界，同时也可以使得宝贵的注意力资源能够针对性的全部用在开发者所期望的实现目标上。我觉得应该不止在上下文工程的范畴，比如工具链的调用也可以进行设计。
--【叁】--：
确实啊，其实如果要写是有一大堆东西的，不知道佬跟我理解的约束是一个东西不，我理解的约束是属于上下文工程里面的范畴，比如智能体设计方面的，我这里只写了harness新增的东西
--【肆】--：
没有未来，只有当下。就好像从前围绕模型开展的所有工程修补，新一代模型会把有效的吸收掉，或者模型公司会直接下场接管约束条件，然后卖出去。国外优秀的工程师会被模型公司收入员工名单。国内研究这个的，一点好处都捞不着。看着用就好，别花心思。模型迭代太快。
--【伍】--：
约束还是太重要了，不仅为了安全，还为了防止初期定下来可能还有呲漏的目标在多轮执行后逐渐偏离。这是我最近很想了解的方向。
--【陆】--：
我最近给自己的工程加上了很强的约束，主要是边界治理、代码体积控制和评测，质量提升不少，但有时候Agent还是会忘记一些规则需要我重新强调
--【柒】--：
我是新手小白，但是我觉得框架应该不会做的这么重。
--【捌】--：
其实我觉得可以考虑一下做好上下文隔离、优化工具描述或者使用multi-agent架构。Anthropic的这篇文章中描述到三种使用multi-agent的场景可能是符合你所担忧的。
When to use multi-agent systems (and when not to) | Claude
Most teams don't need multi-agent systems. Learn the three scenarios where they consistently outperform single agents—and how to implement them effectively.
image716×259 28.3 KB
--【玖】--：
感觉现在最大的问题就是任何agent长期跑下来，都慢慢的不听话了，或者动作行为跑偏了…… 约束多了，一轮下来就要多烧5-20万的token……
--【拾】--：
感觉可以补充一个约束，明确agent的能力边界以及禁止触摸的内容，保证安全性
--【拾壹】--：
大伙不都在研究中么，只不过harness只是提出了理论，就是只告诉我们要什么和目标，至于怎么搞，怎么做？好像没有很正确的说法，都是各方提出自己的实现甚至有好多硕士论文实践，等待开源社区百花齐放，就好像之前的SDD，有多个实现openspec spec-kit bmad等…
--【拾贰】--：
其实就算上下文没有瓶颈，llm也会很容易忘了前面的东西
--【拾叁】--：
我也经常遇到你说的agent忘记一些我设置的规则，这个真的好麻烦
--【拾肆】--：
其实这也是harness工程的目标，让agent能够长期稳定执行长项目 复杂项目，需要调度器去选择动态加载的需要的记忆给到当前会话中
--【拾伍】--： 野人不吃野菜:
决策加载什么上下文
感觉上下文会成为瓶颈，这会是比较重要的方向。我现在的做法是，使用子agent做为旁观者，在每个小的任务节点，不断用预期（需求文档）对比当前阶段产出，避免跑偏。就是比较浪费token。