AI时代软件的看法
AI时代软件的看法
AI操作系统
还记得OpenClaw推出的时候,有人说,这个东东是AI操作系统.
如果真的是操作系统,那么我可以这么推断:
- 大模型就是运行操作系统的CPU
- 大模型的上下文就是运行操作系统的内存
- 大模型的记忆就是运行操作系统的磁盘
Harness,正是操作系统的cpu调度理论和内存清理理论.
说句题外话,Deepseek4的发布,就像它的发布标题一样,这套操作系统的运行内存,从200k的时代进入到了1M时代,虽然国外早就到2M了.
要知道,现在的计算机,也是从64k内存开始起步的.
AI 运维系统实践
前段时间研究 Harness 理论，感觉有点通了，就想想自己还有几台服务器,要不顺手写个AI运维系统。
源码发布地址：http://senvon.x3322.net:53000/corp/ai-ops ,有心人自取
都是业余时间搞的,时间大概在3周左右.
东西能转起来以后,还是有点感想要记录一下.
Harness 的核心本质
一句话总结：Harness 就是内存调度器。
主要实现手段就是下面3点
- 上下文剪枝（Context Pruning）
- 上下文压缩（Context Compression）
- 子agent
一些概念就不再这边啰嗦了,哪边都能查到.
如果按照计算机从64K到目前的16G内存的发展角度看,目前harness的理论,还处于萌芽状态,今后一定会出现harness1.1,harness2.0
如果跟不上理论的跟新,也就会跟不上AI时代.
Harness 实施的难点
虽然概念清晰，但 Harness 的实现却异常困难。主要原因在于以下几点：
加上子agent的调度,harness的实现其实很复杂.
- 需求模糊导致的频繁重写
在AI时代,软件作为工具,需求非常模糊.而Harness本身的复杂,又加剧了这种问题.
举个简单的例子,运维系统肯定是需要记录日志的,这边有2个问题
- 什么时候记录
- 记录什么日志
上面的2个问题,随便一个做运维的同学,都有自己的理解,关键是都会有道理.那么问题来了,系统只能做一种决策,上面任何一个答案的修改,对于之前的实现,都会造成大范围的修改.比如,记录日志可以在AI运行结束时候记录,但是如果在执行结束记录,Harness的剪枝和压缩在执行完以后,就会丢失部分信息,如果在过程中记录,是通过agent控制,还是应用程序控制,agent的执行过程是如果不嵌入ReActagent的流程,几乎无法被打断,那怎么找到那个触发点?
- 提示词在运行过程中需要大量调试,如果程序的运行流程是AI+程序的组合,那么Harness的实现就非常困难。
很简单,本来希望通过提示词完成的功能,最后发现提示词缺少步骤,比如中间结果需要存储,而当前提示词的后续部分,又是程序运行,那么提示词的修改,就会导致程序运行流程的修改,导致Harness的实现会频繁修改.
- 由于大模型的特性,导致所谓的CPU,是缺少中断指令的.而中断指令,是软件在实现异步,多线程的底层基础.
由于AI的运行特点,目前几乎不存在有中断指令的说法.所以,就算在任务阶段实现多线程,AI还是会等待线程执行完成,再继续往下做.目前整体的AI理论完全对于传统的计算机线程模型完全不沾边.
这种指令的缺失,对于AI来说,如果要执行一个等待通知的任务,大模型只能通过调用bash中的sleep 30 来实现等待30秒的逻辑,而在这30秒的等待过程中,工具调用的线程是一致在等待工具返回,虽然大模型在工具调用过程中是闲置的,但是agent的执行线程是一直处于等待状态,会导致agent的请求线程无法接受新的指令.
上述的现象,也可以通过目前的agent之间的通讯来验证.之前claude工程师有一个难题,是各个agent之间的通讯问题,他们的解决方案是通过类似邮件的方式来完成.我之前一直在想,为什么在这么多通讯手段下,最后选择的是类似邮件的方式,直到看到这边,我才想明白.
由于Harness内部压根没有线程机制,所以这种通讯方式的实现就只剩下2个切入点
- ReactAgent 在循环之间读取邮件
- 通过特制的tool 来读取邮件
压根不会有我们常见的,类似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时代的方向.