linux.do

Harness 工程的最终理解——如何让AI大模型正常工作

先叠个甲，由于这个目前没有任何定义，相对来说比较敏感，本文仅为个人经验总结，不具备任何学术或名词篡夺。

模型使用：deepseek-v4-flash-high[1m]

BTW，关于harness的内容这就是最后一篇，不会再写关于harness的任何内容了，后续就看各人能力能出什么作品了。

书接前文：Harness工程的二次理解——弥补大模型的缺陷

通俗理解

大家近半年来，关于harness的言论想必听了少说两万字起了（我自己也写了差不多快1万字了），避免理解不到位，请大家暂停忘掉他家言论，先听我说。

Harness的通俗理解其实就一句话，如何让AI大模型代替自己【完整】地做一件事。

举个例子，我是一名程序员，程序员的工作包含：需求接收、需求理解、初设、详设、架构、编码、单测、集测、部署、归档，这差不多就是程序员工作时的全生命周期了。相信各位单拎任意一个环节出来，自己+AI大模型，都能胜任单项工作，可毕竟自己的工作并不是其中一项，而是需要一整个串联起来，才算是一项工作。那就再深度尝试点，写一个agent专职其中一个工作细节，再写一个agent leader，管理这些职责agent，是不是就搞定了。在理想情况下，这确实是可以，可是工作从来就是不是顺风顺水的。

卡点一逆流程化操作

单测之后的bug，如何回到上一个节点让编码来修复。

这个问题相对来说比较简单，我们在单测agent最后，加上一句“如果发现有bug，就拉起编码agent来修复”，这样其实就解决了这个问题。可是有这样一问题，单测如何知道这是个Bug？编译、打包异常这肯定是Bug，可除此之外的问题呢，又如何定义为问题？

卡点二角色该怎么定义

这个问题问出来，大家感觉可能就有点难回答了，这时大家应该有点感觉了，好像让AI大模型来代替我们工作并不是写个提示词就完了。

这时我们要解决这个问题，就需要想想，人和AI大模型在工时的区别是什么，我认为有以下几点：

● AI大模型是无状态的，人是有状态的
● AI大模型是不具备全局意识的，人是具备全局意识的
● AI大模型的3Q是不可成长的，人的3Q是可成长的

我个人总结大致为以上三点，我们来对症下药。这里说得这么吓人，甚至感觉都快扯上哲学了，不过对于我们这帮老coder们，原因找到了，解决起来就很简单了。

不过为了方便大家能够更好地理解，我这里再举个例子，方便大家套概念。

原先我们传统编程时代，使用RESTful接口时，要保证接口是无状态的。但是接口总跟业务相关，业务就跟用户相关，而我们又不能为每个用户设计一个接口，所以我们就做了一层设计，接口传入认证凭证或userId，后台通过AOP技术或filter/interceptor技术等等，设计一个全局缓存层，当识别到接口有这个参数传入，将特有标识转化成全量信息存入线程变量中，这时，进来的是一个无状态的接口请求，到服务端运行时，就是一个具备全局视野的请求对象，服务端很清楚，是哪个用户在处理什么业务，他的权限是什么，他的用户状态是不是可用的等等，业务在处理时，顺其自然的就知道这时应该怎么处理才是正确的。

好的，回到原有话题，角色该如何定义。这时我们也明白了，角色要知道全局才能知道对错，不光是单测角色，即使是编码角色也应该是知道全局，要不然怎么就知道这个编码就是一定是对的呢。而大家都知道，不管是编码也好，还是测试也好，都是依赖需求和架构来实现和验证的，所以我们需要将需求和架构结果转存为一份文件，放在某个目录，列为共识，在需求、架构等启发性角色提示将结果存进该目录，在编码、测试等认知型角色去读取。

写到这都快赶上一篇软考架构的论文了，可是还有内容要写，有点累。

到这里，我们清楚了在harness中，角色怎么定义才是有效，流程怎么回溯，那到这里，我们可以完整的使用agent的形式实现需求接收、需求理解、初设、详设、架构、编码、单测、集测、部署、归档这些角色，他们既有全局视角处理当前职责，又有方式可以回溯，不过随着流程化内容越来越复杂化，一个新问题的诞生了。

一段时间之后，我们在不断完善上述agent的能力和流程时，最终发现，一个agent的流程化内容居然还要比职责内容要长，聪明的传统coder们，这时脑子里就已经蹦出来一句话了，这逼东西怎么耦合这么严重啊。肯定随之就出来一个经典面向对象设计的方法了，这特么要走单一职责啊，高内聚、低耦合啊。

为了防止其它行业的牛马们看不懂，这里再做一个通俗的解释，好比我们开个饭馆，有一个大的储物柜，一开始只卖热干面，就只放热干面，后面为了吸引更多客户，又增产卖细粉，这个柜子就变成又放热干面又放细粉了，但是店里面忙起来的时候，两个师傅经常去柜子拿粉面的时候，一次只能一个师傅拿，这样效率不高，于是就再准备了一个柜子，一个放粉，一个放面，两个师傅拿东西不冲突，效率提高，就是这个意思。

好的，回到正题，来到harness的最后一步，AgentFlow

卡点三 AgentFlow

好了，一个harness的所有元素我们都已经有了，各个职责agent，共识目录，我们现在要做的工作是把这些职责agent的流程化理清楚，比如编码完了应该测试，测试完了有问题就回到编码，没有问题就再走下一步，我们只需要把流程化梳理清楚，也是定义成一个agent，只不过这个agent的角色为team leader，也就是代表的你本人，其它职责agent全部为subagent，是你本人的具体工作逻辑，而在这个subagent下，你可以为了让agent更好的做某个事，给加skill、mcp、tool等，而在整个harness之外，你想再做一些异步的事，就是加hook。

----------------------

ADVANCE

这里为高级内容，看不懂也没关系，工程化相对来说比较简单的就完成上面内容即可，这里为复杂工程化的优化。

上面所有的内容，已经能够解决所有的简单工程化的工作了，但是承着工程化的复杂化，就会暴露出来一个问题，上面只是简单的将各个agent的流程化内容剥离出来而已，甚至这步工作都可以不做了，只是为了后续更好的优化和维护，剥离出来更好调控。

当流程复杂化后，这个角色的内容将会被无限拉长，拉到过长后，会导致文件部分内容为AI大模型忽略，这是我们不想看到的，一旦内容忽略，等于流程缺失，恒等于工程失败。

前面我们提到了共识目录，这时我们也需要在agentFlow也要用起来，我们需要把所有流程化进行结构化抽象，比如：当前节点，子节点，子节点中再包含子节点进入条件，子节点入参，这里就是走BPMN的那一套了（关于BPMN的的资料可自行查阅，这里不再扩展），然后将agentFlow的职责转为更好的维护这个流程文件，把流程描述以树状或有向无环图的形式表达清楚，把流程式维护进流程文件存进共识目录中，这里就正式变成一个无状态流程agent，而不是简单的流程化描述，通过加载流程共识文件，即可知道工程全局，然后交给大模型，发挥AI大模型的逻辑能力，自动处理下一步。

到这里，就是真正的让AI大模型继承自己的工作思想，代替自己完整地完成一项工作。

话尾

大家可能担心，因为AI大模型的能力越来越强，自己的可替代性也会越来越高，我个人理解其实完全不需要担心。

在工程化理论里，有一个经典四级公民理论，一等、二等、三等、四等，我们以往的日常工作其实就是位列于四等公民，然而由于AI大模型的出现，我们可以操作AI大模型，代替我们成为四等公民，而我们将自动上升为三等公民，负责脑力工作，起管理作用。

我们当时被聘用是因为我们的专业性，我们现在的不可替代性就会自动上升为专业能力管理，我们当时的专业性是可以用专业性完成上级领导的下发的任务，我们如今的专业性是可以管理一帮跟我们一样的专业性智能体完成领导下发的任务，并且效率更快，质量更高。

2 个帖子 - 2 位参与者

阅读完整话题

via LINUX DO - 最新话题 (author: coldingcode)

26 views03:48