1. 前言

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

在更广阔的视野下，C 语言向 Rust 语言的迁移本身就是一个横跨编译技术、程序分析与人工智能的深水区课题。事实上，早在 AI 尚未广泛渗透软件开发流程之前，学术界与工业界便已开始了自动化的 C-to-Rust 翻译工具的探索。纯粹依赖 Skills 与 Rules 约束的通用智能体，若要完成代码量庞大、依赖关系复杂的大型项目翻译，必须遵循一套更加科学严谨的多阶段流水线方法论，而非一步到位的生成式翻译。本文将沿着这一技术脉络进行系统性的梳理与实验。

2. C-to-Rust 自动翻译的技术前史：从规则驱动到 AI 增强的演进

C 语言作为系统软件领域长达数十年的“通用语”，其积累的代码遗产浩如烟海。然而，内存安全漏洞（如缓冲区溢出、UAF 等）始终是悬在 C 生态之上的达摩克利斯之剑。Rust 语言凭借其所有权模型与编译期内存安全保证，被视为根治此类问题的终极方案，由此催生了将海量 C 代码自动迁移至 Rust 的强烈需求。

自动化 C-to-Rust 翻译的研究可追溯至 2016 年。当时，开发者 Jamey Sharp 创建了 Corrode 项目——一个能够读取 C 源文件并生成等价 Rust 语法输出的半自动化工具。Corrode 的理念简洁而富有远见：由机器完成枯燥的语法映射，让人类开发者专注于代码质量的提升与逻辑优化。在此基础上，Galois 与 Immunant 公司经过逾十年的持续投入，将 Corrode 的技术积淀发展为 C2Rust ——一个相对成熟的自动迁移框架。

C2Rust 的核心策略是“功能保真优先”：其转译器（c2rust transpile）将 C99 兼容代码映射为高度贴近原始结构的 unsafe Rust 代码。这被视为迁移的第一步，而非最终形态——后续还需通过半自动化重构逐步消除 unsafe 块，向安全、地道的 Rust 代码演进。这一“先生存、后优化”的两阶段策略深刻影响了后续几乎所有 C-to-Rust 翻译工具的设计哲学。

进入大模型时代，AI 的介入为该领域注入了全新动力。2024 年，DARPA 启动了 TRACTOR (TRanslating All C TO Rust) 项目，旨在利用先进的 AI 技术，将手动迁移 C 代码至 Rust 所需的“数年时间与数十亿美元成本”压缩至可接受的量级。TRACTOR 的创新之处在于将翻译本身定义为一项可重复、可度量、安全驱动的持续过程，而非常规的一次性转译任务。与此同时，研究人员构建了 C2Rust-Bench 基准——一个从真实世界项目中提取的 2,905 个函数的精筛数据集，为评估各类 C-to-Rust 翻译方法提供了标尺。

3. 业界 C-to-Rust 自动化方案的多维审视

3.1 统信软件：“工具链 + AI 双引擎”工程实践

在 2025 年开放原子开源生态大会·Rust 开源生态发展分论坛上，统信软件研发经理、高级工程师张海东分享了团队在 C 转 Rust 领域的系统工程实践。其核心洞察在于：在主流 Linux 操作系统中，C 语言代码占比超 70%，内核中更是超过 90%，而内存安全漏洞的根源恰恰深植于此。

统信团队提出的“工具链 + AI 双引擎”自动化工作流，将传统静态分析工具与 LLM 的生成能力深度耦合，成功将代码转换效率提升了 10 倍以上。该方案已在 utsudo/utpam 等关键组件的 Rust 化改造中落地验证。其技术思路——工具链负责结构分析与模式识别，AI 承担语义理解与代码生成——与学术界日益兴起的“规则 + 学习”混合范式高度契合。张海东强调，构建 Rust 基础组件生态、优先改造高风险关键模块，才是解决内存安全危机的治本之道。

3.2 OpenCode：Skills 与 Rules 加持的可定制编码 Agent

在专业 AI 编码 CLI 工具的生态中，OpenCode 以其灵活的 Skills 与 Rules 机制脱颖而出。与 OpenFang 的强安全约束不同，OpenCode 提供了完整的 CLI 环境继承能力，支持复杂构建脚本的无缝执行。

其 Agent Skills 功能允许开发者通过 SKILL.md 文件定义特定的人设、指令与行为模式。技能文件支持从项目级（.opencode/skills/）到全局级（~/.config/opencode/skills/）的多层配置，并通过原生 skill 工具按需加载，仅在必要时注入上下文窗口。每个 SKILL.md 以 YAML frontmatter 声明其名称、描述与兼容性元数据，Agent 可根据任务需求动态发现并激活相应技能。

与之互补的 Rules 功能则通过项目根目录的 AGENTS.md 或全局配置 ~/.config/opencode/rules 来约束 Agent 的行为边界、工具使用权限与编码风格。AGENTS.md 中的自定义指令会被纳入 LLM 的上下文，实现对特定项目需求的精准定制。这种“Skills 提供能力、Rules 划定边界”的双层治理架构，为构建面向复杂重构任务的专用编码 Agent 提供了成熟且灵活的工程范式。

3.3 EvoC2Rust：骨架引导的项目级 C-to-Rust 自动翻译框架

在学术前沿，由上海交通大学与华为联合研发的 EvoC2Rust 具备当前项目级 C-to-Rust 自动翻译的较高技术水平。该研究成果已被 ICSE 2026 SEIP（Software Engineering In Practice）收录。

EvoC2Rust 的核心创新在于其**“骨架先行”（Skeleton-guided）的演化式翻译策略**，将原本端到端的翻译任务解耦为三个结构清晰、彼此协同的阶段[reference:19]：

• 第一阶段——骨架构建（Skeleton Construction）：将 C 项目分解为功能模块，利用基于特性映射增强的 LLM 转换结构定义与宏，生成类型检查通过的函数桩（Function Stub），从而构成一个可编译的 Rust 项目骨架。

• 第二阶段——增量翻译（Incremental Translation）：在骨架之上，逐步翻译函数体实现，逐一替换占位桩代码，保持项目在翻译全周期的持续可编译性。

• 第三阶段——编译修复（Compilation Error Repair）：融合 LLM 生成能力与静态分析工具，对翻译过程中产生的编译错误进行迭代修复。

该框架通过结合基于规则的语法转换与LLM 驱动的语义生成，在语法正确性、语义保真度和安全性的三维目标空间中取得了显著的均衡表现[reference:21]。这种分阶段、可验证、渐进式的设计，为我们后续的本地化部署实验提供了坚实的理论参照。

项目目录结构

.
├── data/                                   # 数据主目录
│   ├── default/                            # 脚本执行的默认数据目录
│   │   ├── project/                        # 待翻译的 C 项目存放处
│   │   ├── cache/                          # 生成结果缓存
│   │   ├── c-metadata/                     # 存储解析后的 C 元数据
│   │   └── rust-metadata/                  # 存储解析后的 Rust 元数据
│   ├── increment/                          # 增量编译数据目录
│   ├── fill/                               # 填空测试数据目录
│   └── project_template/                   # 示例项目模板
│       ├── safelevel-0/                    # 通用项目框架
│       └── safelevel-test/                 # 含单元测试的框架
├── scripts/                                # 翻译流水线运行脚本
├── experiment_scripts/                     # 实验复现脚本
├── src/                                    # 主要源代码目录
│   ├── config/                             # 全局设置与提示词配置
│   ├── cache/                              # 代码缓存管理模块
│   ├── code_optim/                         # 错误修复与优化模块
│   ├── entity/                             # 核心数据结构与项目管理
│   ├── llm/                                # LLM API 交互模块
│   └── metadata_extraction/                # 基于 tree-sitter 的 C/Rust 元数据提取

EvoC2Rust 的设计哲学深刻揭示了纯粹依赖通用智能体的单步生成式翻译是无法胜任大型项目迁移的。科学的 C-to-Rust 翻译必须建立在“元数据提取 → 结构映射 → 分模块翻译 → 迭代修复”的多阶段流水线之上，每一阶段由最合适的工具（语法解析器、类型检查器、LLM、静态分析器）各司其职。

4. EvoC2Rust 本地化部署与实验验证

基于上述理论分析，我们在本地环境中部署 EvoC2Rust 框架，以验证其在真实 C 项目翻译中的执行效果。

4.1 环境准备与 API 集成

拉取 EvoC2Rust 源码并安装必要依赖后，首先配置外部 LLM API 密钥，以对接远程大模型服务。配置完成后，实验环境如下图所示。

在 data/default/project/ 目录下可观察到框架自带的一个纯 C 语言示例项目 c-algorithms，我们将以其为测试对象，触发完整的 C→Rust 翻译流水线。

4.2 第一阶段：元数据提取（Metadata Extraction）

执行第一步元数据提取脚本时，系统报错提示缺少 config 模块。经排查发现，标准的 pip install 并未覆盖项目内部模块的结构依赖。尝试切换到 pdm install 后，依赖完整性得到修复。

此后再次运行元数据提取脚本，仍提示 config 模块无法定位。根因在于 Python 的 import 机制默认仅搜索当前工作目录与 site-packages 路径，而项目的 src/config/ 目录并不在该搜索范围内。因此必须借助 pdm run 命令来启动脚本，使项目源码路径正确注入 PYTHONPATH。修正调用方式后，元数据提取流程顺利执行完成。

4.3 第二阶段：LLM 翻译（Function Translation）

元数据准备就绪后，流转入第二阶段——调用外部 LLM 对项目中的 C 代码进行逐模块翻译。脚本将翻译结果按类别存入指定的缓存目录中。由于涉及数百个函数和类型定义的逐一翻译，该阶段运行时间较长，但其间无需人工干预。

翻译完成后，系统自动生成如下统计报表：

类别	数量	翻译状态
宏 (macro)	29	✅ 完成
宏函数 (macro_function)	0	✅ 完成
类型定义 (definition)	95	✅ 完成
函数签名 (dummy_function)	200	✅ 完成
函数体 (function)	200	✅ 完成

翻译缓存保存于 data/default/cache/evo-c2rust-v2-ds-gen-only/ 路径下，为后续修复阶段提供了可复用的中间产出。

4.4 第三阶段：编译修复（Error Repair）

第三步进入修复阶段，首先运行括号修复（bracket fix）子流程。

这里的修复分三部分，运行时间也是比较长，消耗的api相当的恐怖，这一步花掉了十块钱的api，后边再继续补充试验。