OrionAgent OS

中国研究生操作系统开源创新大赛参赛作品 赛题：面向多智能体的操作系统级执行时（Agent Runtime） · 参赛队伍：喵喵队

让 Agent 成为操作系统的一等公民。

OrionAgent OS 是运行在 openEuler、openKylin 等 Linux 系统之上的多智能体执行时。它在多 Agent 应用与模型、工具及操作系统资源之间增加统一 Runtime，将 Agent 从应用层函数提升为可调度、可隔离、可观测、可恢复的系统级执行单元。

项目关注的不是“如何再造一个 Workflow”，而是解决 Workflow 运行起来之后的系统问题：谁先运行、资源如何分配、上下文如何复用、工具如何受控、故障如何隔离、全过程如何追踪。

核心问题 · 系统方案 · 赛题要求映射 · 关键机制 · 实验结果 · 快速开始 · 仓库结构

---

一、核心问题

传统多 Agent 框架擅长描述角色、节点与流程，但当任务规模和并发度上升后，仅靠应用层编排难以统一管理模型请求、上下文、工具进程和底层资源。

系统瓶颈	传统应用层方式	OrionAgent OS 的回答
多 Agent 争用资源	各 Agent 独立调用模型和工具，排队无序	Runtime 统一接收系统调用，按依赖、优先级与资源状态调度
上下文重复复制	反复拼接完整历史，Token、内存与传输开销持续增长	将上下文视为运行时资源，通过句柄复用、分层空间、压缩和权限隔离管理
模型、工具、资源割裂	每个框架各自封装，缺少统一生命周期与控制接口	统一 LLM、Memory、Storage、Tool Syscall，并由 Runtime 管理执行状态
单点故障扩散	错误结果沿任务链传播，容易触发级联失败	以 Agent 为隔离边界，结合超时、重试、检查点、故障围栏和降级策略
执行过程不可见	只能看到零散日志或最终答案	统一记录 Agent 状态、调用链、上下文变化、资源与异常恢复过程

项目边界

OrionAgent OS 不要求修改 Linux 内核。项目采用用户态 Runtime Daemon agentd，在国产开源操作系统上复用进程、线程、队列、文件系统、IPC、cgroup、namespace 和系统日志等基础能力，以操作系统的资源管理视角重新组织多 Agent 执行。

应用层继续负责“做什么”，Runtime 负责“如何稳定、高效、可控地运行”。

---

二、系统方案

2.1 总体架构

flowchart TB
    APP["多 Agent 应用
自动软件开发 / 科研分析 / 运维协同"]
    SDK["Cerebrum Agent SDK
Agent 定义 · 任务提交 · 结果获取"]

    subgraph RT["OrionAgent Runtime · agentd"]
        API["Runtime API / Agent Control Block"]
        SCH["Agent Scheduler"]
        CTX["Context & Memory Manager"]
        BUS["Runtime Bus"]
        TOOL["Tool Manager"]
        FAULT["Fault Supervisor"]
        OBS["Observability"]
        SYS["统一 Syscall 层"]
    end

    OS["OS 适配层
process · IPC · filesystem · cgroup · namespace · procfs"]
    MODEL["模型服务
Ollama · vLLM · OpenAI-compatible API"]
    DEVICE["Tool Device
搜索 · 文件 · 终端 · 代码执行 · MCP"]

    APP --> SDK --> API
    API --> SCH
    SCH --> SYS
    CTX <--> SYS
    BUS <--> SYS
    TOOL <--> SYS
    FAULT -.监控与恢复.-> SCH
    OBS -.采集.-> API
    SYS --> OS
    SYS --> MODEL
    SYS --> DEVICE

系统分为五层：

1. 应用层：承载自动软件开发等复杂多 Agent 场景。
2. SDK 层：通过 Cerebrum 定义 Agent、提交任务并调用 Runtime 能力。
3. Runtime 层：负责调度、上下文、记忆、存储、工具、通信、容错和观测。
4. OS 适配层：将 Linux 进程、文件、IPC 与隔离能力映射为 Agent 可用资源。
5. 模型与工具层：连接本地模型、远程 API、MCP 服务和外部工具。

2.2 核心抽象：Agent Control Block

OrionAgent OS 借鉴操作系统的进程控制块，为每个 Agent 建立 Agent Control Block（ACB）。ACB 不仅记录调度元数据，也保存 Agent 特有的上下文、工具权限与执行轨迹。

ACB 字段	作用
agent_id / role	唯一标识与角色能力
state / priority	生命周期状态与调度优先级
dependency	前置、后继任务及动态任务依赖
resource_quota	CPU、内存、GPU、工具并发和最长执行时间
context_handle	私有或共享上下文的引用句柄
tool_acl	可调用工具及权限边界
message_queue	Agent 消息与 Runtime 事件队列
checkpoint	状态快照、回滚与恢复点
trace_id / metrics	跨模块追踪标识与运行指标

stateDiagram-v2
    [*] --> Created
    Created --> Ready
    Ready --> Running
    Running --> Waiting
    Running --> Blocked
    Waiting --> Ready
    Blocked --> Ready
    Running --> Completed
    Running --> Failed
    Running --> Killed
    Failed --> Retrying
    Retrying --> Ready
    Completed --> [*]
    Killed --> [*]

2.3 从应用调用到系统执行

一次 Agent 请求不再直接访问模型或工具，而是经过统一链路：

Agent App
   ↓  Cerebrum SDK
Runtime API / agentd
   ↓  创建执行记录并进入请求队列
Scheduler
   ↓  分派 LLM / Memory / Storage / Tool Syscall
Runtime Manager
   ↓  调用模型、存储或受控工具
结果回传 → 状态更新 → 轨迹记录

这条链路将模型调用、工具调用和系统资源纳入同一控制面，是项目区别于普通多 Agent 编排框架的关键。

---

三、赛题要求映射

赛题要求	OrionAgent OS 的实现思路	代码与验证入口
国产开源操作系统	基于 Linux 通用能力构建用户态 Runtime；参考实验环境为 openEuler 22.03 LTS 兼容环境，并面向 openKylin 适配	AIOS/runtime、技术报告第 2、4 章
多 Agent 调度	任务依赖触发、动态任务图、就绪/等待队列；系统调用层提供 FIFO 与 Round Robin 调度，方案进一步引入资源感知评分与 aging	AIOS/aios/scheduler、AIOS/aios/hooks/modules/scheduler.py
统一执行抽象	以 ACB 管理 Agent 标识、状态、优先级、资源、上下文、权限和轨迹；由 agentd 统一接管执行	AIOS/runtime/launch.py、AIOS/aios/hooks/modules/agent.py
故障隔离与容错	以单 Agent/单任务节点为故障边界，结合超时、结构化异常、重试、检查点、回滚与降级，阻断错误向共享上下文传播	AIOS/aios/syscall、AIOS/aios/scheduler、技术报告第 2.3、4.3 节
上下文优化	上下文句柄、共享/私有空间、摘要压缩、权限隔离；内核支持自动记忆提取、检索与注入	AIOS/aios/context、AIOS/aios/memory、Cerebrum/docs/shared-memory-experiment-report.md
复杂应用验证	构建 Planner、Architect、Coder、Tester、Reviewer、Fixer、Document 七类 Agent 的自动软件开发链路	orionagent-web/codegen_server.py、orionagent-web/app.js
Agent 高效通信	通过 Runtime 队列、事件和共享上下文引用解耦 Agent；Web 场景使用 SSE 实时输出执行事件	AIOS/aios/hooks/stores/queue.py、orionagent-web/codegen_server.py

面向评分细则的交付重点

评分维度	本项目重点
系统设计与机制创新（30%）	Agent 一等公民、ACB、上下文资源化、工具设备化、控制面与执行面分离
功能完整性与实现深度（25%）	Kernel + SDK + Web Console 三层贯通，统一覆盖 LLM、Memory、Storage、Tool Syscall
性能优化效果（20%）	资源感知调度、并发队列、上下文复用与压缩，并与串行/普通工作流进行对照实验
工程实现质量（15%）	模块化内核、可替换调度器、多模型后端、MCP 工具生态与测试目录
实验与分析质量（10%）	自动软件开发任务、调度对比、上下文消融、异常注入及共享记忆实验

---

四、关键机制

4.1 三层调度：从依赖到资源

1. 任务图调度：依据任务依赖判断节点是否可运行，并支持运行期生成新任务。
2. 就绪队列调度：综合优先级、关键路径、等待时间和 aging，降低饥饿风险。
3. 资源感知调度：在执行前检查 CPU、内存、GPU、模型队列和工具并发，决定立即执行、等待、降级或迁移。

设计中的综合评分函数为：

Score(A) = αP(A) + βD(A) + γW(A) - δR(A) - εC(A)

其中 P 为任务优先级，D 为依赖关键路径权重，W 为等待时间，R 为资源需求，C 为上下文切换成本。内核当前提供 FIFO 与 Round Robin 调度器及统一扩展接口，便于继续接入新的策略。

4.2 上下文资源化：复用与隔离并重

Context Manager 将上下文划分为五类：

• System Context：系统提示词、权限和输出约束。
• Task Context：全局目标、计划与中间结论。
• Agent Private Context：单 Agent 的局部状态和未经验证的中间结果。
• Shared Context：已验证、可被多个 Agent 复用的事实与产物。
• Compressed Context：对长历史、日志和工具输出生成的摘要。

关键策略包括引用复用、按需加载、摘要压缩、访问控制、版本管理和热上下文缓存。多个 Agent 共享信息时优先传递 context_handle，避免重复复制完整历史；中间结果先写入私有空间，校验通过后再进入共享空间，降低污染与错误传播风险。

4.3 统一 Syscall：模型与工具都由 Runtime 管

系统把 Agent 对外部能力的访问归一为四类调用：

• LLM Syscall：统一模型请求、路由、队列和返回结构。
• Memory Syscall：保存、检索、更新和共享长期记忆。
• Storage Syscall：统一结构化数据、文件和向量存储访问。
• Tool Syscall：经权限、参数、并发、超时与审计后调用外部工具。

工具被抽象为 Tool Device。搜索、文件、终端、代码执行器和 MCP 服务不再由 Agent 无约束直连，而是通过 Tool Manager 受控执行，为后续接入进程、容器或 namespace 沙箱提供统一边界。

4.4 通信、容错与可观测性

• Runtime Bus：支持点对点消息、事件分发和共享上下文引用，使用 trace_id 串联跨 Agent 调用。
• Fault Supervisor：处理超时、工具异常、输出错误和模型服务短暂不可用；按错误类型执行重试、回滚、跳过、降级或终止。
• Observability：记录任务状态、Agent 生命周期、模型/工具调用、上下文变化和异常轨迹；Web Console 实时展示内核状态与代码生成阶段。

---

五、实验与结果

5.1 验证场景：自动软件开发多 Agent 系统

flowchart LR
    U["用户需求"] --> P["Planner"] --> A["Architect"] --> C["Coder"]
    C --> T["Tester"]
    C --> R["Reviewer"]
    T --> G{"测试通过？"}
    R --> G
    G -- 否 --> F["Fixer"] --> T
    G -- 是 --> D["Document"] --> O["代码 · 测试 · 文档"]

该场景同时覆盖任务依赖、动态反馈、模型调用、工具执行、失败修复、共享上下文与执行追踪，可集中检验赛题要求的关键能力。

5.2 参考实验结果

技术报告在 openEuler 22.03 LTS 兼容环境下，以 Qwen3-4B 和自动软件开发任务进行了串行、普通应用层工作流与 OrionAgent OS 三组对照。核心结果如下：

指标	应用层工作流	OrionAgent OS	变化
平均任务完成时间	152.1 s	74.8 s	降低 50.8%
Agent 平均等待时间	9.8 s	3.1 s	降低 68.4%
模型调用平均排队时间	8.2 s	2.7 s	降低 67.1%
上下文 Token 总量	59.2 K	34.6 K	降低 41.6%
工具调用成功率	94.6%	97.4%	提升 2.8 个百分点
任务完成率	88.0%	94.0%	提升 6.0 个百分点
异常恢复成功率	71.2%	92.8%	提升 21.6 个百分点

异常注入实验覆盖 Agent 超时、工具失败、输出格式错误、上下文写入冲突和模型服务短暂不可用，共注入 100 次异常，综合恢复成功率为 **93.0%**。上下文消融实验中，重复上下文比例由 38.7% 降至 12.4%，平均模型输入构造时间由 1.42 s 降至 0.81 s。

上述数据来自仓库根目录的 喵喵队+技术报告.pdf 第 4 章，代表报告所述软硬件与任务集下的参考实验结果，不等同于所有环境下的固定性能。共享记忆的 30 轮补充实验、评测方法与复现命令见 Cerebrum/docs/shared-memory-experiment-report.md。

---

六、快速开始

6.1 环境要求

• openEuler、openKylin 或其他主流 Linux 发行版
• Python 3.10 或 3.11
• 本地模型方案：Ollama；也可配置 vLLM 或远程模型 API
• 可选：Redis、Docker/虚拟机环境，用于持久化、回滚或高风险工具隔离

6.2 安装 Kernel 与 SDK

在仓库根目录执行：

python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip

python -m pip install -r AIOS/requirements.txt
python -m pip install -e Cerebrum

cp AIOS/aios/config/config.yaml.example AIOS/aios/config/config.yaml

默认配置使用 Ollama 的 Qwen3 模型：

ollama pull qwen3:1.7b
ollama pull qwen3:4b

如需使用其他后端，请修改复制后生成的 AIOS/aios/config/config.yaml；可参考 AIOS/aios/config/config.yaml.example 中的 Ollama、vLLM、OpenAI、Gemini、Anthropic 等配置示例。

6.3 启动 Runtime Kernel

cd AIOS
python -m uvicorn runtime.launch:app --host 127.0.0.1 --port 8000

验证内核：

curl http://127.0.0.1:8000/status
curl http://127.0.0.1:8000/core/status

启动后可访问 http://127.0.0.1:8000/docs 查看 Runtime API。

6.4 启动终端界面

保持 Kernel 运行，在另一个终端执行：

source .venv/bin/activate
cd AIOS
python scripts/run_terminal.py

终端支持 /chat、/file、/auto 三种路由模式，并展示 Runtime 控制面的核心模块。

6.5 启动 Web Console 与自动软件开发场景

代码生成服务需要一个 OpenAI-compatible 模型接口：

source .venv/bin/activate
export ORIONAGENT_API_KEY="your-api-key"
export ORIONAGENT_BASE_URL="https://your-endpoint.example.com/compatible-mode/v1"
export ORIONAGENT_MODEL="your-chat-model"
python orionagent-web/codegen_server.py

再启动静态页面：

source .venv/bin/activate
python -m http.server 5173 --bind 127.0.0.1 --directory orionagent-web

浏览器打开 http://127.0.0.1:5173。Web Console 会连接：

• 127.0.0.1:8000：OrionAgent Runtime Kernel
• 127.0.0.1:8001：多 Agent 代码生成与 SSE 事件流服务

请勿提交真实 API Key。orionagent-web/.env、运行产物和日志已通过 .gitignore 排除。

---

七、仓库结构

OrionAgent OS/
├── AIOS/                       # Runtime Kernel
│   ├── runtime/launch.py       # agentd / FastAPI 入口
│   ├── aios/scheduler/         # FIFO、Round Robin 与调度扩展接口
│   ├── aios/syscall/           # LLM / Memory / Storage / Tool 系统调用
│   ├── aios/context/           # 上下文管理
│   ├── aios/memory/            # 记忆、检索与上下文注入
│   ├── aios/storage/           # 文件与向量存储
│   ├── aios/tool/              # Tool Manager、MCP 与虚拟环境
│   └── tests/                  # Kernel 模块测试
├── Cerebrum/                   # Agent SDK、Agent/Tool 示例与评测
│   ├── cerebrum/               # SDK 实现
│   ├── benchmarks/             # 共享记忆、OSWorld、SWE-bench 等实验
│   └── tests/                  # SDK 与基准测试
├── orionagent-web/             # Runtime Web Console 与七 Agent 开发场景
├── 喵喵队+技术报告.pdf          # 设计、实现、实验与分析
├── 喵喵队答辩PPT-7月30日最新版.pptx # 项目答辩演示文稿
└── README.md                   # 项目总览

进一步阅读

• AIOS/README.md：Kernel 的完整安装、模型后端和 API 说明。
• Cerebrum/README.md：Agent SDK、Agent/Tool 开发与运行方法。
• Cerebrum/docs/system_wide_personalization.md：系统级个性化与内核自动上下文注入。
• Cerebrum/docs/shared-memory-experiment-report.md：共享记忆实验设计、结果与复现步骤。
• orionagent-web/README.md：Web Console 启动说明。
• 喵喵队+技术报告.pdf：大赛技术报告全文。
• 喵喵队答辩PPT-7月30日最新版.pptx：项目答辩演示文稿。
• 演示视频：「喵喵队-演示视频.mp4」通过百度网盘分享，提取码：rru7。

---

八、项目总结

OrionAgent OS 的核心贡献可以概括为一句话：

以操作系统的方法管理多智能体执行，把 Agent、上下文、模型和工具纳入统一 Runtime。

在这一抽象下，Agent 不再只是被 Workflow 调用的应用对象，而是具有生命周期、资源配额、上下文空间、工具权限、消息队列和执行轨迹的系统级任务单元。项目由 AIOS Kernel、Cerebrum SDK 与 Web Console 共同构成，形成从底层执行机制、开发接口到复杂场景验证的完整链路，为 AI Native OS 中多智能体执行时提供可运行、可扩展的实践基础。

致谢

项目基于 AIOS 与 Cerebrum 开源生态进行面向赛题的系统集成和扩展，并使用 FastAPI、Pydantic、Ollama、vLLM、Redis、Docker 等开源技术。感谢 openEuler、openKylin 及相关开源社区提供的系统软件基础。