AI导哈

AI操作系统

ACOS是一个基于Rust微内核的AI优先操作系统，所有系统接口均为MCP服务，由AI Guardian监督整个系统并通过本地LLM做出决策。适用于需要AI原生操作系统的开发者和研究人员。

  • by MKheru
  • Rust
  • 本地部署
  • 更新于
在 GitHub 查看 MKheru/ACOS

使用说明

ACOS

一个操作系统，其中 一切都是MCP，以及 AI守护者是大脑.

ACOS是一个基于Rust微内核的AI优先操作系统，其中每个系统接口——网络、文件、进程、显示——都是一个MCP服务。AI Guardian监督整个系统，并通过本地LLM做出决策。没有云，没有API密钥，一切都在你的机器上运行。

以人工智能为中心的操作系统的想法在我脑海中已经存在了很长时间，但有两个项目使它变得具体： Redox操作系统，一个完全用Rust编写的微内核，为我提供了一个干净而现代的基础 Karpathy的自我研究 该框架向我展示了迭代式人工智能辅助开发可以应用于雄心勃勃的系统工作，而不仅仅是机器学习实验。ACOS就诞生在这个十字路口。

这是一个更大项目的第一阶段：构建一个人工智能可以完全运行的操作系统，以便人工智能最终能够推理出什么硬件架构最适合自己。自成立以来，当前的计算硬件并没有发生根本性的变化——ACOS是从操作系统开始重新思考堆栈的一步。

        Guardian (brain)
           |
    +------+------+
    |      |      |
   net    ai    talk
    |      |      |
  Ollama  tools  conversation
    |
  19 MCP services — all discovered at runtime, zero hardcoded

状态

ACOS目前作为 QEMU中的虚拟操作系统所有19个MCP服务都正常工作，AI可以调用工具，Guardian咨询LLM做出决策，整个系统启动并运行。

一旦功能集稳定下来，下一阶段就是将ACOS移植到真实硬件上启动。

它是什么样子的

登录ACOS，每个系统资源都是可以查询的MCP服务：

root:~# mcp list
19 services [live]: system, process, memory, file, file_write, file_search,
config, log, echo, net, llm, ai, guardian, konsole, display, talk, command, service, net_status

root:~# mcp-query system info
{"hostname":"acos","kernel":"ACOS-0.5.12-x86_64","memory_total":2147483648,"uptime":0}

root:~# mcp-query echo ping
{"result":"pong"}

AI可以使用工具。问它一些问题，它会调用MCP服务来找到答案：

root:~# mcp-query ai ask "What is the hostname?"
{"text":"The hostname is acos.","tool_calls_made":1}

root:~# mcp-query ai ask "How much free memory?"
{"text":"1.93 GB free out of 2.0 GB total.","tool_calls_made":1}

LLM通过Ollama在本地运行（phi4-mini用于生成，qwen2.5用于工具调用）：

root:~# mcp-query llm generate "Say hello"
{"text":"Hello! How can I assist you today?","model":"phi4-mini","finish_reason":"stop"}

Guardian监视系统并向LLM咨询决策：

root:~# mcp-query guardian consult '{"description":"High CPU usage"}'
{"action":"monitor","ai_consulted":true,"reasoning":"CPU usage alone is not critical..."}

或者只是聊天 mcp-talk，具有完整工具访问权限的对话界面：

root:~# mcp-talk
ACOS Terminal — AI-Native Interface
Type naturally. The AI is your shell.

acos> what processes are running?

  Here is the list of running processes on ACOS:
  | PID | Name                         | Memory  |
  |-----|------------------------------|---------|
  | 21  | /scheme/initfs/bin/redoxfs   | 65 MB   |
  | 32  | /usr/bin/mcpd                | 3 MB    |
  | 38  | /usr/bin/ion                 | 4 MB    |
  ...

大局

ACOS遵循一个简单的原则，灵感来自Unix的“一切都是文件”：

一切都是MCP。

每个系统接口（网络、显示器、文件系统、进程、AI）都是可通过以下方式访问的MCP服务 mcp: 内核方案。Guardian不是您启动的监控应用程序，它是一个内核级服务，可以监控所有其他服务，始终处于活动状态。

这种设计的存在是有原因的：如果人工智能可以通过统一的协议完全控制操作系统，它最终可以推断出最佳的系统架构是什么样子的。ACOS是实现这一目标的软件层。

今天，Guardian通过以下方式依赖外部LLM 奥拉玛 在主机上运行——AI大脑生活在操作系统之外。这是一块垫脚石。ACOS的目标是 在内核的核心拥有自己的内部AI守护者，本机运行，不依赖于外部主机。然后，Guardian会将专门的任务委托给建模的代理层 龙虾的架构——不仅为ACOS提供了智能，还为操作系统本身提供了一个完全自主的代理框架。

路线图：

  • 第一阶段 （当前）：ACOS作为一个虚拟操作系统——AI是一等公民，MCP总线工作，Guardian通过Ollama咨询外部LLM。
  • 第2阶段：Rust原生LLM运行时通过 mistral.rs + 杰玛4然后是内部Guardian——嵌入ACOS的设备上AI引擎，没有外部依赖性。Web GUI仍然存在 doc_only / awaiting WS11 直到 observability.recent 暴露在MCP上；在依赖关系出现之前，没有仪表板实现被认为是完整的。 龙虾-受启发的代理委托，其架构模式借鉴自 赫尔墨斯代理.
  • 第三期：真正的硬件启动——ACOS在裸机上运行，而不仅仅是QEMU。
  • 阶段4：AI分析并设计针对AI工作负载优化的硬件架构。

组件

组件 功能 线条
mcpd MCP守护进程--注册 mcp:// 内核方案，将JSON-RPC路由到服务处理程序 ~400
mcp方案 19个服务处理程序（系统、进程、内存、文件、网络、llm、ai、guardian、konsole……） ~8000
mcp_query CLI工具： mcp-query <service> <method> [params] ~340
mcp-talk 具有工具调用和多回合上下文的对话式人工智能 ~500
acos_监护人 自主健康监测——异常检测+LLM咨询 ~720
acos_mux 终端多路复用器 ~4000
llm发动机 设备上GGUF推理（SmolLM-135M） ~600
离子内置物 mcp 和 guardian Ion shell的shell命令 ~2300

快速开始

您需要：带KVM的Linux、带Podman的Ollama phi4-mini + qwen2.5:7b-instruct-q4_K_M，约8 GB磁盘，约4 GB RAM。

# 1. Clone
git clone https://github.com/MKheru/ACOS.git && cd ACOS

# 2. Set up ACOS (downloads base kernel, applies patches, links components)
./scripts/setup-acos.sh

# 3. Build the disk image
cd base
CI=1 PODMAN_BUILD=1 REPO_BINARY=1 make all CONFIG_NAME=acos-bare

# 4. Cross-compile and inject ACOS binaries
cd .. && ./scripts/build-inject-all.sh --rebuild

# 5. Boot
qemu-system-x86_64 \
  -machine q35 -cpu host -enable-kvm -smp 4 -m 2048 \
  -vga std -serial mon:stdio \
  -drive file=base/build/x86_64/acos-bare/harddrive.img,format=raw,if=none,id=drv0 \
  -device nvme,drive=drv0,serial=ACOS \
  -nic user,model=e1000 \
  -bios /usr/share/edk2/ovmf/OVMF_CODE.fd \
  -no-reboot

登录： root / password。然后键入 mcp list 你加入了。

运作原理

ACOS注册内核级别 mcp: URL方案。当任何进程打开时 mcp:system，内核将文件描述符路由到 mcpd，它解析JSON-RPC并分派给适当的服务处理程序。

process                    kernel                     mcpd
  |                          |                          |
  |-- open("mcp:system") --> |                          |
  |                          |-- fd to mcpd ----------> |
  |-- write(json-rpc) -----> |                          |
  |                          |-- route to handler ----> |
  |                          |                          |-- SystemHandler
  |                          |                          |   .handle()
  |<- read(response) ------- | <-- response ---------- |

AI服务(mcp:ai)通过网络服务向Ollama发送提示，接收工具调用请求，通过分派给其他MCP服务来执行这些请求，并返回最终答案。LLM可以致电 system_info, process_list, file_read, net_dns_resolve等等。--全部通过同一MCP总线。

Guardian作为内核级服务运行。它轮询系统指标，检测异常，并咨询LLM以决定是否 ALLOW, MONITOR，或 BLOCK.

项目结构

ACOS/
  mcpd/                 Core daemon workspace (Rust)
    src/main.rs           Daemon entry point — registers mcp: scheme
    mcp_scheme/           19 service handlers + router + protocol
    mcp_query/            CLI query tool
    mcp_talk/             Conversational AI interface
    acos_guardian/         System health monitor
    acos_mux/             Terminal multiplexer
    llm_engine/           On-device GGUF inference
  ion-builtins/          MCP + Guardian shell builtins for Ion
  config/                ACOS image config + build recipe
  patches/               6 kernel patches + 2 Ion patches
  docs/                  Architecture docs + session journals
  scripts/               Build, test, QEMU automation
  harness/               Evaluation harness

目前的情况以及未来的发展方向

ACOS在23天内建成。我不是一名操作系统开发人员，但在2026年，像Claude Code这样的工具终于让我获得了将动力转化为工作原型的杠杆。Redox OS提供了内核基础，Karpathy的AutoResearch框架激发了迭代开发循环，AI编码工具弥合了我的愿景和技能之间的差距。

基础就在那里：19个MCP服务、LLM工具调用、Guardian智能、一个可用的虚拟操作系统。但这只是一个原型，还有很长的路要走——真正的硬件引导、安全强化、多进程守护者、适当的驱动程序支持、OpenClaw集成，以及最终推动整个项目的硬件设计问题。

我需要帮助。 如果这个愿景能引起你的共鸣——一个为人工智能构建的操作系统，一切都是MCP——我很想让你参与进来。无论你是操作系统开发人员、Rust工程师、人工智能研究人员，还是只是对人工智能成为一等公民时的计算样子感到好奇的人：我们都欢迎你的贡献、反馈、想法和批评。

这 docs/ 文件夹包含完整的构建日志，显示每个步骤、每个决定和每个错误。没有什么是隐藏的。

构建日志亮点：

  • WS1：ACOS内核+引导加载程序品牌重塑
  • WS2-3：配备12个系统服务的MCP总线
  • WS4：设备上LLM推理（SmolLM-135M GGUF）
  • WS5：具有工具调用功能的AI主管
  • WS7：虚拟控制台系统（konsole）
  • WS9：监护人自主监控+法学硕士咨询
  • WS10：终端多路复用器
  • 最终：Ollama集成，19个实时服务，全网络堆栈

路线图上的下一步（参见 docs/ROADMAP.md 完整计划）：

  • WS11——Rust原生LLM运行时：将Ollama/phi4 mini替换为 mistral.rs （Rust原生，内置MCP客户端）和 杰玛4 E4B（Apache 2.0，本机函数调用）。将所有19个MCP服务公开为 tools/list 代理循环可使用的定义。 LlmBackend 这种特性使模型可以互换。通过 agentskills.io 网站 技能格式。看 docs/HERMES_EVALUATION.md 与hermes agent进行比较分析。
  • WS12——Redox中的本地LLM：交叉编译mistral.rs（仅限CPU，纯Rust）为 x86_64-unknown-redox，暴露为 mcp://llm 从mcpd内部运行Gemma 4 E2B（4 GB Q4） 里面 VM。主机端LLM依赖关系结束。迈向“LLM作为内核”的第一个具体步骤。
  • WS13——Web GUI远程优先：状态 doc_only / awaiting WS11架构注释和架构/管道工作可能会继续，但阶段1仪表板将被阻止，直到WS11公开 observability.recent 通过MCP。在验证依赖关系之前，不要将此工作流视为完整/设计或装运的模拟仪表板数据。

需求

  • 主机：带KVM的Linux（在Fedora 43上测试）
  • 构建：Podman，GNU Make，约8GB磁盘
  • LLM: 奥拉玛 随着 phi4-mini 和 qwen2.5:7b-instruct-q4_K_M
  • 运行时：带OVMF（UEFI）的QEMU，~4 GB RAM
  • 网络：QEMU用户模式网络(-nic user,model=e1000)前往Ollama的路线

致谢

  • Redox操作系统 --Rust微内核是ACOS的基础。如果没有这个干净、现代、文档齐全的操作系统，ACOS就不会存在。
  • Karpathy的自我研究 --迭代式人工智能研究框架启发了ACOS的开发方法和评估工具。
  • 人类克劳德密码 --人工智能开发工具，使得在没有内核工程师团队的情况下构建一个可用的操作系统原型成为可能。
  • 奥拉玛 --为ACOS的人工智能服务提供动力的本地LLM推理。

许可证

Apache 2.0。看 许可证.

内核基础： Redox操作系统 （MIT许可证）。

相关 MCP