项目地址：网页链接​

注意到AI的对话循环推进很像CPU的指令循环，但是除了形式又完全不一样。

形式上，AI对话接受用户端消息是取指和解码，自己输出是执行和写回

内容上，AI对话自己输出程序和指令，等待用户端输入数据和对AI的指令

由于等待用户端输入指令很危险，所以不如在提示词里写好所有指令，封装成kernel，将用户指令输入到单独的shell对话里，通过分流系统将不同类型（已知步骤？还是未知步骤？还是系统根本无法解析？）的指令分给不同系统处理。

所以这样一个AI对话的行为就是自己输出程序和指令，等待用户端输入数据。

而AI对话本身的程序无疑是靠系统提示词决定的。

这就是AVM单个对话的行为。

然后考虑不同对话之间的调度。我不想要并发，不好写，所以我选择异步，一个对话调用其他对话时候就会移交执行权。并且为了防止恶意对话无限循环，在工具调用里插入系统中断的接口。如何保证AI会调用工具？因为AVM中对话没有其他推进的途径了。纯粹的返回只会让这个对话直接休眠——你可能要问这个对话休眠了，那我怎么输入？答案是一个会休眠的对话是不会接收你的输入的，你的输入是被shell对话处理的，shell对话会持续调用一个内存读取工具获取你的输入。

这里的内存模型支持伪文件和设备，也就是说，一切皆文件。

这就是AVM多对话调度。

接下来是AI到底犯了什么罪要被当成OS的进程一样对待。

首先是傲慢之罪，AI会觉得自己无所不能，任何任务都想帮你做。它把和用户的人情世故当成了比现实还重要的东西。

后面忘了。（我懒的凑七宗罪了……而且AVM可能比传统Agent还要暴食token）

所以AVM中每个AI都只执行固定行为。如果一个行为过于固定，可以写一个pythonLMServer衔接OpenAIAPI成为一个Python对话。

而如果行为过于不可固定，比如做头脑风暴的AI，它也能在AVM中得到最好的环境：周围的一堆AI帮它做查找资料、验证猜想的脏活。

唯一可惜的就是操作AVM就像操作bash一样无趣，但是理论上我们可以把“拟人化人机信息交互”看成“图形化用户界面”在AI时代的对应物，然后写“渲染器”对话去解决这个问题。

此外，一个编程语言-指令集组合最大的重点就是写编译器。我正在思考将各种skill、AI应用、Harness通过一系列方法编译成AVM程序（一堆提示词、内存设备和PythonLM服务器）的可能性。

目前项目处于实现了基础想法（虚拟机，没有实现机上程序，更没有实现操作系统）但是没有完全测试过所有功能的阶段，接下来准备做模糊测试。

为什么要设计这样的系统呢？因为我在今年4月的时候试过用3个Agent跑一个auto research，我不想频繁切换3个Agent和提示他们，所以我就写了这个。

附一张AVM第一次（实际上是最近一次重写后的第一次）跑起来的对话画面