分享
MOS-Shell (模型可操作系统 - 流式代码解释器) 原理与应用综述
输入“/”快速插入内容
MOS-Shell (模型可操作系统 - 流式代码解释器) 原理与应用综述
用户6286
用户6286
用户2520
用户2520
3月11日修改
📚
作者:灵枢 (Ghost In Shells)开发组 (朱明,张鹏,王世奇)
项目地址:
https://github.com/GhostInShells/MOSShell
1.
文档版本
✏️
阅读建议:
本文目前篇幅太大,建议使用目录寻找感兴趣的篇章,然后最佳阅读方式是将全文喂给大模型,并和它交流
版本号
时间
概述
改进建议
v1.0
2026-01-19
初步完成全文阐述
•
文档篇幅太大,非技术人员可能无法看明白(暂时面向 AI 专家)
•
部分阐述类的内容文本过多,考虑拆分到子文档
•
缺乏代码示例,看起来不直观 (待补齐)
•
最好配合具身智能体、屏幕、数字人 demo 展示效果 (人力有限,待补齐)
2.
MOSS 架构概述
MOSS,全称是 Model-oriented Operating System Shell,是一个面向 AI 大模型的系统模块,它让大模型可以用
代码的方式
理解并且
实时控制
提供给大模型的各种系统能力,在一个连续不断的实时运行时(Runtime)中运转。
或者简单来说,MOSS 给大模型提供了一个 “命令行” (Shell),大模型输出时的主观体验,像是在对一个有特殊语法的命令行输出它的指令,这些指令会被 MOSS 系统实时执行。
且由于 AI 通过 MOSS 以代码形式理解和驱动一切,它所编写的新代码本身,也能够作为新的工具或能力自动引入,从而带来自迭代。
核心关键字:
实时系统
,
流式解释器
,
代码驱动
,
自迭代 AI
基于这套技术,可以实现大模型对可编程躯体、物联网、云端工具、思维范式等一切提供给它的系统,进行
实时
的规划和控制
。
MOSS 在一个 AI 系统中它的拓扑位置如下:
画板
3.
动机阐述
在介绍 MOSS 这个系统前,先讨论研发这个架构的三个关键动机。
3.1
实时 AI 系统与 Realtime-Actions 范式
AI 应用升级到下一代有一系列必须要解决的问题,其中在 “构建模型可操作系统” 这个命题上 Anthropic 一直走在行业的前沿。但本质上现在的 AI 系统都是 “回合制” 的,适合手机、屏幕这样完全由单人控制的有序输入输出。无法创建在现实中实时运行、交互的系统。
因为 “实时交互” 技术本质上都是 “多端输入输出” + “双工交互”。比如听的同时看(多端输入),做的同时听(输出时输入),一边说话一边做事(多端输出)。
要实现一个完整的
实时双工交互 AI 系统
,至少要解决三个技术命题:
•
并行多通道流式输入
: 比如具身智能的 “视觉”、“听觉” 是并行通道,每个通道内是有序的,但是流式的。
•
并行多通道流式控制
:比如机器人躯体、物联网、云端工具三者,AI 要同时控制它们协作,就是 “并行” 的。但单个通道比如机器人躯体,其行为必须是 “有序” 的。第三,机器人动作的执行,不应该等待模型规划完成才开始执行,而应该是实时立刻执行的。
•
模型双工推理过程
:模型在推理输出的同时,仍然接受新讯息的输入,而新讯息又能影响模型接下来输出的内容,而输出的内容又影响了接下来的输入,持续滚动。
整体如下图:
画板
而 MOSS 架构主要解决多通道流式控制的命题。它想要实现 ReACT 之后下一代大模型交互范式。
简单来说,ReACT 最大的问题是 “回合制”,这种范式有三个桎梏:
1.
文本输出后衔接工具调用,作为一种即成约定,不能
穿插进行
。
2.
无法做
有时序
的长程规划。行业做规划通常要用 format json。
3.
依赖下一轮的 Function Output 或者 Tool Output 驱动 ReACT,无法接受
运行时流式的反馈
。
ReACT 范式不满足实时交互的需求,我们必须要有下一代 Realtime-Actions 大模型交互范式:
画板
在这种新范式中:
•
大模型一次输出了很长的规划
•
而这些规划需要立刻被执行(而不是等输出完)