Agent OS（智能体操作系统）是一个专为 AI Agent 设计的软件平台，提供运行时执行、任务调度、资源治理、工具集成和安全隔离能力，让 Agent 能够自主、可靠地完成复杂工作。对比维度传统 OSAgent OS调度对象进程/线程AI Agent 请求与任务核心能力CPU 调度、内存管理、文件系统Agent 调度、上下文管理、工具调用、多 Agent 协同交互方式CLI / GUI，精确指

OpenFang 的基础部署、权限模型调优及 MCP 服务集成验证已阶段性完成。后续将进一步探索更多 MCP Skill 工具的能力边界与应用场景。更关键的是，下一步将深入 OpenFang 源码层面进行架构分析，重点评估其作为纯 Rust 技术栈实现的 AgentOS 方案在工程可行性、性能特性及安全模型方面的实际表现，为 Agent 基础设施的技术选型提供实证依据。

前面四个 Layer 翻译完成，14 个集成测试全部通过，甚至在 QEMU 上完成了安全性和性能的 A/B 对比实验。一切看起来都非常完美。直到有一天，我们做了一个底层原生 API 的基准测试——不经过 SDAA Runtime 那一层封装，直接调用最底层的 gmalloc/gmemcpy_to_device/gsync 来测 DMA 带宽。出现了一个非常荒谬的结果。Rust 版的 DMA 耗时只

C 版本中普遍存在的无边界检查、错误码类型混淆、空指针解引用等问题，在 Rust 版中通过Option<T>RAII DropMutex串行化、newtype等机制被彻底根除。Rust 的类型系统与所有权模型不是在写“更好的 C”，而是在编译器层面强制实施内存安全与并发安全，将原本需要人工审查的约束变成了机器可验证的规则。从 C 到 Rust，SDAA 运行时在安全性上有较大提升——8 类内存与并

前四层翻译完成后，我们在开发机上跑通了全部 196 个单元测试。但在 QEMU 验证机（CentOS 7, glibc 2.17, 4 块 aicard 设备）上，最初只是用一个在用户态模拟设备内存，内核启动也在 CPU 上软件完成——数据从未真正进入 AI 加速卡。为了验证翻译的正确性，必须让 Rust 运行时像原版 C 库一样，通过 ring buffer 协议将操作码和参数推入，由内核模块a

四层翻译完成：L1 AIDEV ioctl 封装、L2 gdev 核心抽象、L3 SDAA Driver API、L4 Ocelot Runtime（惯用 Rust 重设计）。31 个 .rs 文件，~10,300 行，196 个单元测试 0 失败。cargo build --release 产出 libgdev_layer2.so + libgdev_layer4.so，对标原版 C 写的 li

本次实验验证了利用 OpenFang Hands 机制构建垂直领域 Harness 的技术可行性，成功定制了一个具备基础 C→Rust 重构意识的专用智能体。然而，实验数据同时表明：OpenFang 在应对需要极高工具自由度与大规模迭代次数的“生产级代码重构”场景时，其基于安全优先的强沙箱模型反而成为效率瓶颈。

在前一阶段的实验中，我们基于 OpenFang 的 Hands 机制成功构建了面向 Gdev/SDAA 加速卡驱动重构的专用智能体。然而，实际压力测试揭示了 OpenFang 作为通用 Agent 操作系统在面对生产级代码重构任务时的结构性瓶颈——其 Shell 沙箱对管道符、重定向等原语的严格过滤，以及默认的 50 次自主迭代上限，使得大规模源码分析与构建流程的执行极为受限。官方文档亦表明，Op

在上一阶段的实验中，我们成功驱动 EvoC2Rust 完成了元数据提取与 LLM 翻译两大流水线，将示例项目中的 29 个宏、95 个类型定义、200 个函数签名及 200 个函数体从 C 映射为 Rust 中间表示，并转入了编译修复流程。本文将深入剖析修复阶段的三级串行机制、验证环节的缓存一致性问题，以及最终 Rust 项目的生成与编译验证结果。

在上一阶段的实验中，EvoC2Rust 的三级修复流水线将项目的函数体编译通过率从 54.50% 提升至 73.00%，但仍有 54 个函数体未能通过翻译验证。这挡在通往全自动 Rust 化路径前的 27%，其核心障碍并非翻译能力的缺失，而是更深层的。本章我们将使用 OpenCode 编码智能体对失败日志展开系统性诊断，定位根因并设计针对性修复方案。