前四层翻译完成后，我们在开发机上跑通了全部 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 编码智能体对失败日志展开系统性诊断，定位根因并设计针对性修复方案。

在上一阶段的深度排障中，我们成功锁定了阻碍函数体通过率跨过 73% 天花板的根本原因——typedef条目产生的空结构体壳在符号层面引发了Ptr<T>泛型参数的类型坍缩。然而，由于此前调试过程中反复修改max_trial参数并遗留了大量交叉引用的缓存文件，导致流水线执行频繁触发超时与依赖混乱。为彻底排除环境干扰，我们决定从零构建一个干净的 EvoC2Rust 工作目录，并在此之前进一步强化 Ope

按核心类型、公共 API、调度器框架、完整集成的顺序，将 gdev_device.c、gdev_api.c 及四种调度策略翻译为 trait Scheduler 的多态实现，并贯通 glaunch、gsync 等核心操作。

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

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