AI时代软件开发的新思路
回想OpenClaw刚发布时，有人将其称为AI操作系统。
如果确实如此，那我可以这样理解：
Harness本质上就是操作系统的CPU调度与内存管理理论的延伸。
顺便提一下，Deepseek4的发布正如其标题所示，这套操作系统的运行内存从200K时代跃升至1M时代，虽然海外早已达到2M水平。
要知道，如今的计算机也是从64K内存起步的。
前阵子研究Harness理论，感觉有些领悟了，就想着手边的几台服务器，不如顺手开发一个AI运维平台。
源码发布地址：http://senvon.x3322.net:53000/corp/ai-ops ，有心人自取
都是利用业余时间完成的，大约耗时3周。
系统能够运行后，还是有些心得想记录下来。
简言之：Harness就是内存调度器。
主要实现方法就是以下三点
一些基础概念就不在此赘述了，哪里都能查到。
如果从计算机从64K到目前16G内存的发展历程来看，当前的Harness理论还处于萌芽阶段，今后必然会出现Harness1.1、Harness2.0等版本。
如果跟不上理论的更新，也就无法适应AI时代。
虽然概念清晰，但Harness的实现却异常困难。主要原因在于以下几点：
加上子agent的调度，Harness的实现其实很复杂。
在AI时代，软件作为工具，需求非常模糊。而Harness本身的复杂性，又加剧了这种问题。
举个简单的例子，运维系统肯定需要记录日志，这里有两个问题
上述两个问题，随便一个做运维的同事，都有自己的见解，而且都有道理。那么问题来了，系统只能做一种决策，上面任何一个答案的修改，对于之前的实现，都会造成大范围的修改。比如，记录日志可以在AI运行结束时记录，但是如果在执行结束记录，Harness的剪枝和压缩在执行完以后，就会丢失部分信息；如果在过程中记录，是通过agent控制，还是应用程序控制，agent的执行过程是如果不嵌入ReActagent的流程，几乎无法被打断，那怎么找到那个触发点？
很简单，本来希望通过提示词完成的功能，最后发现提示词缺少步骤，比如中间结果需要存储，而当前提示词的后续部分又是程序运行，那么提示词的修改，就会导致程序运行流程的修改，导致Harness的实现会频繁修改。
由于AI的运行特点，目前几乎不存在中断指令的说法。所以，就算在任务阶段实现多线程，AI还是会等待线程执行完成，再继续往下做。目前整体的AI理论完全与传统计算机线程模型不沾边。
这种指令的缺失，对于AI来说，如果要执行一个等待通知的任务，大模型只能通过调用bash中的sleep 30来实现等待30秒的逻辑，而在这30秒的等待过程中，工具调用的线程一直等待工具返回，虽然大模型在工具调用过程中是闲置的，但是agent的执行线程一直处于等待状态，会导致agent的请求线程无法接受新的指令。
上述现象也可以通过目前的agent之间的通讯来验证。之前Claude工程师有一个难题，是各个agent之间的通讯问题，他们的解决方案是通过类似邮件的方式来完成。我之前一直在想，为什么在这么多通讯手段下，最后选择的是类似邮件的方式，直到看到这边，我才想明白。
由于Harness内部压根没有线程机制，所以这种通讯方式的实现就只剩下2个切入点
压根不会有我们常见的类似MQ的消息异步通知方式。
虽然AI运维的小系统可以转起来了，还没高兴多久，在一次吃饭被噎住的时候，突然一个想法在我脑袋里出现
为什么要自己写一个系统？如果使用Opencode为基础，写一个智能运维的Opencode插件，成本会远比单独写一套系统要低很多。
在需求基本确定的情况下，经过一天，就开发出了Opencode的插件，能满足执行脚本的需求。
在不考虑脸是否漂亮的情况下，仅仅考虑基本需求，也就是说，3周的时间没有1天有效果。
如果运维是这样，那么其他的AI软件，是不是后续也会这样？
这就是当前为什么搞AI编码的核心逻辑，因为当前的AI编码工具，本质上是通用AI在编码领域的一个投影而已。是在通用AI外面包了一层AI编码的皮而已。
这就是一个天大的问题了，是不是后续的工具类软件，只能在通用agent的边缘运行了，仅仅作为通用agent的外围辅助来实现？
按照这个逻辑来看的话，后续的AI软件，更多的会是以插件的形式存在，比如以Opencode、浏览器插件为主，主要功能会依托于一个主体程序，使用插件的方式完成外围功能。
在观察现阶段的Harness实现时，我发现一个有趣的问题：
使用大模型的方式有以下两种：
这两种方式，哪一种会更好地运行？
在Opencode上，确实2是正确答案，2的运行准确率高于1。至于为什么，这边给看到这边的读者去想想，结合剪枝和压缩，可以问问Opencode的源码。
而在ClaudeCode上，其实没有太大的区别。
我想这才是后Harness时代的方向。