9 个 AI 工程开源项目：Agent 技能、代码知识图谱、端侧 TTS 与视频工作流

AI 工程工具正在从“单个聊天机器人”走向更工程化的形态：有的项目把科研流程封装成可复用技能，有的项目提前为代码库建立知识图谱，有的项目把 Agent 开发约束成确定性的工程流程，还有的项目把语音和视频生成做成端侧或多 Agent 工作流。

如果只看 GitHub Star，很容易把这些项目混在一起。更好的方式是按问题分类：你到底是要让 AI 做研究、读代码、改代码、搭 Agent 产品，还是生成语音和视频。

科研 Agent：把“会聊天”变成“会按流程做研究”

大语言模型（LLM，Large Language Model）直接接收一个科研任务时，经常会出现两个问题：流程不稳定，输出不容易复现。今天可能先查资料，明天可能先写结论；遇到计算任务时，还可能跳过验证步骤。

Skill 的价值就在这里。它不是单纯的一段提示词，而是一组围绕特定任务组织起来的说明、模板、约束和调用方式。Agent 使用 Skill 时，相当于拿到一份操作手册，知道某类任务应该怎样拆解、怎样检查结果、怎样交付。

flowchart LR
    A[用户提出科研或计算任务] --> B[选择对应 Skill]
    B --> C[按领域流程拆解任务]
    C --> D[调用工具或生成代码]
    D --> E[检查中间结果]
    E --> F[输出报告、数据或草稿]

scientific-agent-skills：科研、计算、数据分析的技能包

scientific-agent-skills 是一套面向 Agent 的科研技能集合，覆盖科研、科学计算、工程、数据分析、金融和写作等任务。它适合用来解决“模型懂一点，但做事没有章法”的问题。

它的重点不是替代某个具体软件，而是给 AI 一套任务执行框架。例如，面对数据分析任务时，Agent 不应该直接写一段结论，而是要先明确数据字段、检查缺失值、选择分析方法，再生成图表和解释。面对工程计算任务时，也需要有假设条件、单位检查和结果验证。

开源地址：

https://github.com/K-Dense-AI/scientific-agent-skills

适合场景：

不适合把它当成“全自动科研机器”。科研结论、实验设计和关键引用仍然需要人工检查，尤其是引用是否真实、计算假设是否成立。

academic-research-skills：论文写作流水线

academic-research-skills 更聚焦论文写作。它面向 Claude Code，把学术研究过程拆成连续阶段：查资料、写草稿、审阅、修改、定稿。

flowchart LR
    A[确定主题和问题] --> B[检索与整理资料]
    B --> C[生成论文结构]
    C --> D[起草章节]
    D --> E[审阅逻辑和证据]
    E --> F[修改表达与引用]
    F --> G[形成定稿]
    
    H[人工检查] -.-> A
    H -.-> B
    H -.-> E
    H -.-> G

这类工具的关键价值是把论文写作从“反复问 AI”变成“围绕管线推进”。每个阶段都有明确产物：资料卡片、章节大纲、段落草稿、审阅意见、修改版本。这样做的好处是可追踪，哪里出问题就回到对应阶段修正，而不是整篇重来。

开源地址：

https://github.com/Imbad0202/academic-research-skills

需要特别注意两点：

代码理解工具：先建图，再让 AI 读代码

AI 编程工具最大的问题之一是上下文不足。一个中大型仓库里，文件、函数、类、配置和调用关系交织在一起，模型如果每次都临时读取，很容易漏掉关键依赖。

代码知识图谱的思路是提前把仓库结构解析出来，把文件、函数、类、接口、调用关系、导入关系等信息组织成图。这样 AI 在回答问题或修改代码时，不再只看当前文件，而是能根据图谱找到相关上下文。

flowchart LR
    A[(代码仓库)] --> B[解析文件、函数、类、依赖]
    B --> C[构建代码知识图谱]
    C --> D[搜索 / 问答 / 可视化]
    C --> E[为 AI 编程工具提供上下文]
    E --> F[生成修改方案]
    F --> G[人工 Review 后提交]

Understand-Anything：把陌生代码库变成可交互地图

Understand-Anything 的定位是代码库理解工具。它能把一个仓库转成可交互知识图谱，支持搜索、提问和可视化浏览。

接手陌生项目时，最难的通常不是某一行代码，而是缺少全局结构感：入口在哪里，核心模块有哪些，数据流怎么走，某个函数被谁调用。知识图谱可以把这些关系显式展示出来，让阅读代码从“顺着文件夹猜”变成“顺着依赖关系查”。

开源地址：

https://github.com/Lum1104/Understand-Anything

适合用法：

codegraph：给 AI 编程工具提前准备项目上下文

codegraph 的核心目标是让 AI 编程助手在动手前就理解项目。它会提前把代码库索引成代码知识图谱，再把这些结构化上下文提供给 Claude Code、Codex、Cursor、OpenCode 等工具。

这类工具对大项目更有价值。仓库越大，模型临时读取上下文的成本越高，也越容易忽略隐藏依赖。提前建图后，AI 可以先定位相关模块，再生成修改方案，减少“改了 A，却没发现 B 依赖 A”的情况。

开源地址：

https://github.com/colbymchenry/codegraph

使用时建议把它放在只读分析阶段：

git clone https://github.com/colbymchenry/codegraph
cd codegraph

# 具体安装和索引命令以仓库 README 为准
# 建议先在测试仓库或只读副本里跑索引

生产仓库中使用 AI 自动改代码时，不应该跳过人工 Review。代码图谱能降低漏看上下文的概率，但不能保证业务语义一定正确。

oh-my-pi：终端里的 AI 编程助手

oh-my-pi 是终端 AI 编程助手，特点是把编辑准确性作为重点。它从 Pi 分支出来，加入了 Hashline 编辑系统、语言服务器协议 LSP（Language Server Protocol）、调试适配器协议 DAP（Debug Adapter Protocol）和大量内置工具。

传统 AI 改代码经常依赖“上下文片段 + 替换文本”。这种方式遇到空格、缩进、格式化差异时，容易找不到要替换的位置。Hashline 的思路可以理解为：用内容哈希作为锚点定位代码片段，模型不必重复输出整段上下文，从而减少 token 消耗，也降低空白符不一致导致的编辑失败。

传统编辑：
模型输出：找到这一整段文本，然后替换
问题：空格、缩进、格式化变化后可能匹配失败

Hashline 编辑：
模型输出：基于内容哈希定位代码锚点，再给出替换内容
优势：定位更稳定，重复上下文更少

它还集成了不少开发基础设施：

开源地址：

https://github.com/can1357/oh-my-pi

它适合习惯在终端里完成大部分工作的开发者。如果团队已经深度依赖 IDE 插件式工作流，迁移前需要重点验证编辑准确率、上下文读取方式和现有代码规范是否兼容。

Agent 工程化：让 LLM 负责理解语言，让代码负责控制流程

很多 Agent 项目失败，不是因为模型不会生成文字，而是因为流程不可控：工具调用顺序随机，错误处理靠模型猜，状态混在上下文里，提示词改一次就影响整条链路。

12-factor-agents 借鉴了 12-Factor App 的思想，把 Agent 当成可以工程化交付的系统。它的核心理念很明确：LLM 主要负责把自然语言意图转换成工具调用或结构化决策，流程控制、状态管理、错误处理交给确定性代码。

sequenceDiagram
    participant U as 用户
    participant O as 编排代码
    participant L as LLM
    participant T as 工具/API
    participant S as 状态存储

    U->>O: 提交任务
    O->>S: 读取必要状态
    O->>L: 提供受控上下文和工具定义
    L-->>O: 返回结构化工具调用意图
    O->>O: 校验参数和权限
    O->>T: 执行工具
    T-->>O: 返回结果或错误
    O->>S: 写入状态
    O-->>U: 返回结果

可以从几个工程约束理解它：

开源地址：

https://github.com/humanlayer/12-factor-agents

它还提供工作坊和脚手架工具，适合用来建立 Agent 项目的工程骨架。对于需要审计、回放、测试的业务系统，这种约束比“让模型自己多思考几步”更可靠。

AI 工程学习路线：从数学实现到可交付工件

ai-engineering-from-scratch 不是单一工具，更像一套 AI 工程训练营。它包含 428 节课、20 个阶段，大约 320 小时内容，从线性代数讲到自主多智能体系统。

它的课程结构比较工程化：先明确问题，再解释概念，然后从数学原理实现一遍，再使用 PyTorch 或 sklearn 实现一遍，并把结果封装成可复用工件。

flowchart LR
    A[问题] --> B[概念]
    B --> C[数学原理实现]
    C --> D[框架实现]
    D --> E[交付 AI 工件]
    E --> F[Prompt / Skill / Agent / MCP Server]

项目支持 Python、TypeScript、Rust、Julia 四种语言。每节课都会产出一个可复用 AI 工件，例如 Prompt、Skill、Agent 或 MCP Server。MCP（Model Context Protocol，模型上下文协议）用于把外部工具和数据源以标准方式接入模型生态，适合做 AI 编程工具和 Agent 系统的扩展。

开源地址：

https://github.com/rohitg00/ai-engineering-from-scratch

如果已经会调用 API，但对模型原理、训练流程、Agent 工程缺少系统理解，这类项目适合补基础。它不适合只想快速复制一个 Demo 的场景，因为课程体量较大，需要按阶段投入时间。

端侧 TTS：文本转语音不一定要走云端

Supertonic 是一个端侧 TTS（Text-to-Speech，文本转语音）系统，参数量约 99M，基于 ONNX Runtime 运行，可以在 CPU 上离线完成实时语音生成。

端侧 TTS 的关键优势是隐私和延迟。文本不需要上传到云端，适合桌面助手、本地阅读器、车载设备、离线工具等场景。对于敏感文本，例如会议纪要、内部文档、私人消息，本地合成也能降低数据外传风险。

flowchart LR
    A[输入文本] --> B[本地 TTS 引擎]
    B --> C[ONNX Runtime 推理]
    C --> D[生成语音]
    D --> E[本地播放或保存音频]

Supertonic v3 支持 31 种语言，并加入 Expression Tags，可以用标签控制语音表达效果。它还提供多个平台的软件开发工具包 SDK（Software Development Kit），包括 C++、Node.js、Python、Rust 等，方便集成到不同类型的应用里。

开源地址：

https://github.com/supertone-inc/supertonic

选型时要重点测试三件事：

AI 视频工作流：把一个模型拆成一个剧组

ViMax 来自港大数据智能实验室 HKUDS，它把视频制作拆成多个 AI 角色协作：导演、编剧、制片、视频生成器等。相比单模型直接“输入一句话生成视频”，这种方式更接近真实制作流程。

flowchart LR
    A[输入: 灵感 / 剧本 / 小说] --> B[解析故事和角色]
    B --> C[编剧 Agent 生成脚本]
    C --> D[导演 Agent 规划镜头]
    D --> E[制片 Agent 组织场景和素材]
    E --> F[视频生成器生成片段]
    F --> G[一致性检查与合成]
    G --> H[输出视频]

它支持三种输入模式：

ViMax 还有 AutoCameo 功能，可以上传照片，把指定人物作为角色嵌入视频，并尽量保持外观一致。技术流程上，它使用多层流水线，从输入解析到视觉合成都自动化处理，并模拟多机位拍摄，以维护角色位置和背景一致性。

开源地址：

https://github.com/HKUDS/ViMax

这类多 Agent 视频系统适合探索复杂内容生产，但也有明显成本：流程越长，中间错误传播越难排查；角色一致性、镜头连续性、版权素材和生成内容审核都需要额外机制兜底。

选型建议：按瓶颈选工具，不按热度选工具

这些项目可以按工程瓶颈分成四组：

上手评估可以按这个顺序做：

# 1. 克隆目标项目
git clone <repo-url>

# 2. 在隔离环境或测试仓库中运行
cd <project>

# 3. 阅读许可证、安装步骤、模型依赖和数据处理方式
# 不同项目的安装命令差异很大，具体以各自 README 为准

# 4. 用一个小任务验证核心能力
# 科研工具：让它处理一组真实文献
# 代码图谱：让它索引一个中等规模仓库
# 编程助手：让它修一个可回滚的小 bug
# TTS：测试目标语言和设备
# 视频工具：测试短脚本和角色一致性

真正落地时，Star 数只能说明关注度。更关键的是：它是否解决当前流程里的具体瓶颈，能不能接入现有工具链，失败时是否容易回滚，输出结果是否能被人类检查。对于 AI 工程项目来说，可控性通常比“自动化程度”更重要。