4 个 AI 开源项目：图表重建、具身智能、代码智能体与桌面助手

AI（Artificial Intelligence，人工智能）开源项目越来越多，但真正适合拿来学习或落地的项目，通常不只是“接了一个大模型接口”，而是把模型能力放进了明确的工程场景里。

这 4 个项目覆盖了 AI 落地的 4 个方向：

Edit Banana：把截图和 PDF 图表变成可编辑文件

很多技术资料里的图表都是图片或 PDF（Portable Document Format，可移植文档格式）里的静态内容。问题在于，图里的节点、箭头、文字看起来很清楚，但无法单独选中，也不能直接拖动修改。

普通 OCR（Optical Character Recognition，光学字符识别）只能把文字识别出来，解决不了“图形结构不可编辑”的问题。Edit Banana 的目标更进一步：它尝试恢复图表里的形状、文本、连接线和逻辑关系，再导出为 Draw.io XML（Extensible Markup Language，可扩展标记语言）或 PPTX（PowerPoint 演示文稿格式）。

它处理的不是“截图上覆盖一层文字”，而是把图表重新拆成可编辑对象。

flowchart LR
    A[图片或 PDF 图表] --> B[版面与组件识别]
    B --> C[文本识别]
    B --> D[形状识别]
    B --> E[连线与层级关系识别]
    C --> F[结构化图表模型]
    D --> F
    E --> F
    F --> G[Draw.io XML]
    F --> H[PPTX]
    G --> I[继续编辑]
    H --> I

它和 OCR 的区别

这组示例展示了它要解决的问题：输入是一张不可编辑的图，输出则变成了可单独选中、移动和修改的图形对象。

输入图里所有内容都被压在一张图片中，想改某个文本或调整某条连接线，只能重新画。

重建后的版本会把文字、形状和连接关系拆出来，适合继续在 Draw.io 或 PowerPoint 里修改。

适合的使用场景

Edit Banana 适合处理这类任务：

• 论文、报告里的流程图需要二次编辑；
• 旧 PPT 只剩截图，需要恢复为可修改版本；
• 架构图来自 PDF，想改文字、换颜色、调整布局；
• 团队内部资料只有图片，没有源文件。

它不适合把任意复杂图片都转换成设计稿。比如真实照片、复杂海报、带大量渐变和装饰元素的图片，本身没有稳定的“图表结构”，重建效果会受限制。

上手方式

开源地址：

https://github.com/bit-datalab/edit-banana

可以从一个简单流程开始验证效果：

1. 找一张清晰的流程图或架构图截图；
2. 上传到 Edit Banana 的 Web 界面；
3. 选择导出 Draw.io XML 或 PPTX；
4. 打开导出文件，检查文字、形状、箭头是否能独立选中；
5. 对识别错误的部分手动修正。

更推荐用线条清楚、文字水平、背景简单的图做第一次测试。图片分辨率太低、字体太小、连接线交叉太多时，重建难度会明显升高。

Xiaomi-Robotics-0：面向机器人的视觉-语言-动作模型

Xiaomi-Robotics-0 是小米机器人团队 Xiaomi Robotics 开源的具身智能模型，参数规模为 47 亿。它属于 VLA（Vision-Language-Action，视觉-语言-动作）模型，核心目标是让机器人把“看到的环境”“听懂的指令”和“要执行的动作”连接起来。

普通大语言模型主要处理文本，最多再扩展到图像理解；机器人模型还要处理动作输出。机器人不能只回答“应该拿起杯子”，它还要生成能驱动机械臂或机器人本体执行的控制信号。

这类模型的关键在于把感知、指令理解和动作生成放在同一条链路里：视觉输入提供环境状态，语言输入提供任务目标，模型输出动作序列，机器人执行后再从环境中获得新的观测。

sequenceDiagram
    participant U as 用户
    participant R as 机器人传感器
    participant M as VLA 模型
    participant A as 执行机构

    U->>M: 给出语言指令
    R->>M: 输入视觉观测
    M->>M: 融合环境与任务目标
    M->>A: 输出动作控制
    A->>R: 改变环境并产生新观测
    R->>M: 返回新的视觉状态

VLA 模型解决什么问题

机器人执行任务通常会遇到三个难点：

Xiaomi-Robotics-0 的定位就是在这些问题之间做平衡：既要具备泛化能力，能理解不同视觉场景和语言指令，又要控制推理延迟，让动作生成足够接近实时执行需求。

适合和不适合的场景

机器人系统里，模型只是其中一环。真正接入硬件时，还需要处理传感器同步、动作安全边界、急停机制、仿真验证和控制频率等问题。尤其是物理机器人，不能把模型输出直接无保护地交给执行机构。

开源地址：

https://github.com/XiaomiRobotics/Xiaomi-Robotics-0

MyCodeAgent：从工程角度拆解代码智能体

MyCodeAgent 是一个从 0 开始开发 Claude Code 类代码智能体的开源项目。它的价值不只是“能不能让模型写代码”，而是展示了代码 Agent 在工程上为什么需要约束、协议、工具和上下文管理。

代码智能体通常会经历这样的循环：

1. 用户提出任务；
2. 模型理解任务并规划操作；
3. Agent 调用工具读取文件、搜索代码、执行命令或修改文件；
4. 工具返回结果；
5. 模型根据结果决定下一步；
6. 循环直到任务完成。

flowchart TD
    A[用户任务] --> B[任务规划]
    B --> C[大语言模型]
    C --> D[工具路由]
    D --> E[读取文件]
    D --> F[搜索代码]
    D --> G[执行命令]
    D --> H[修改文件]
    E --> I[观察结果]
    F --> I
    G --> I
    H --> I
    I --> J[上下文管理]
    J --> C
    C --> K[生成最终结果]

代码 Agent 的难点不在“会不会调用模型”

LLM（Large Language Model，大语言模型）本身具有不确定性。让它直接操作代码仓库，会出现很多工程问题：

MyCodeAgent 的工程思想可以概括为一句话：不要把模型的自由发挥当作系统可靠性的来源，而要用工具边界、协议格式和上下文治理把模型能力限制在可控范围内。

工具调用为什么要结构化

如果模型随便输出自然语言，比如“我想读一下 main.py”，程序很难稳定解析。更可靠的做法是让模型输出结构化工具调用：

{
  "tool": "read_file",
  "args": {
    "path": "src/main.py"
  }
}

工具层只接受白名单里的工具名和参数格式。这样做有几个好处：

• 参数能被程序校验；
• 不存在的工具会被拒绝；
• 危险操作可以加确认；
• 日志里能清楚记录每一步动作；
• 出错时能定位是模型决策问题，还是工具执行问题。

适合的学习方式

开源地址：

https://github.com/YYHDBL/MyCodeAgent

更适合用一个小型测试仓库来跑它，例如只包含几个 Python 或 JavaScript 文件的项目。不要一开始就把大型生产仓库交给 Agent 操作，也不要默认允许它执行删除文件、提交代码、安装依赖这类高风险动作。

一个比较安全的验证流程是：

git clone https://github.com/YYHDBL/MyCodeAgent

然后按仓库 README 配置环境，再准备一个独立测试目录：

sandbox-project/
  src/
  tests/
  README.md

测试任务可以从低风险操作开始：

• 解释某个函数的作用；
• 为一个小函数补测试；
• 查找重复代码；
• 修改一个明确范围内的 bug；
• 生成变更 diff，但先不自动写入主项目。

Accomplish：把 AI 放进本地桌面工作流

Accomplish 是一个开源 AI 桌面助手，它把模型能力接入本地文件、文档和浏览器任务。它关注的不是单次问答，而是把重复性桌面操作变成可复用的自动化流程。

典型任务包括：

• 根据文件内容自动分类、重命名、移动或清理；
• 总结长文档、改写报告、生成草稿；
• 从散乱笔记中提取信息，整理会议准备材料；
• 执行网页调研、填写表单等浏览器流程；
• 将固定工作流保存成 Skill，之后重复调用；
• 与 Notion、Google Drive、Dropbox 等工具配合使用。

它的工作方式可以理解为“AI 理解任务 + 本地工具执行动作”。

flowchart LR
    A[用户目标] --> B[选择或创建 Skill]
    B --> C[AI 理解任务]
    C --> D{任务类型}
    D --> E[文件操作]
    D --> F[文档处理]
    D --> G[浏览器自动化]
    D --> H[外部工具集成]
    E --> I[用户确认结果]
    F --> I
    G --> I
    H --> I

桌面 AI 助手和聊天机器人的区别

桌面助手的优势在于能接触真实工作流，但风险也更具体。它可能移动文件、改写文档、填写网页表单，所以权限设计和操作确认非常重要。

使用时要特别注意的边界

开源地址：

https://github.com/accomplish-ai/accomplish

如果只是想试用，建议从一个临时目录开始，例如放入几十个测试文件，让它按文件名和内容分类。确认行为符合预期后，再考虑接入真实工作目录。

4 个项目怎么选

这几个项目代表了不同层面的 AI 工程实践，选择时可以按任务类型来判断。

从学习路径看，MyCodeAgent 更适合理解 Agent 的底层工程结构；Edit Banana 更适合立即解决图表重建问题；Accomplish 更接近日常桌面自动化；Xiaomi-Robotics-0 则偏机器人和具身智能研究，需要更强的硬件、数据和实验环境支撑。

上手前的通用检查清单

无论试哪个项目，都建议先检查这些内容：

• License 是否允许你的使用场景；
• README 是否提供清晰安装步骤；
• 是否需要 GPU、机器人硬件或特定系统权限；
• 是否会读取本地敏感文件；
• 是否支持 dry-run 或人工确认；
• 输出结果是否方便回滚；
• 项目 issue 和 commit 是否活跃。

4 个仓库地址集中列在这里：

Edit Banana:
https://github.com/bit-datalab/edit-banana

Xiaomi-Robotics-0:
https://github.com/XiaomiRobotics/Xiaomi-Robotics-0

MyCodeAgent:
https://github.com/YYHDBL/MyCodeAgent

Accomplish:
https://github.com/accomplish-ai/accomplish

AI 工具真正有价值的地方，不是把模型包装成一个新入口，而是让模型进入具体流程：图表重建要能产出可编辑结构，机器人模型要能生成动作，代码智能体要能安全调用工具，桌面助手要能在权限边界内执行任务。能不能把“不确定的模型能力”变成“可验证、可回滚、可控制的工程流程”，才是判断这类项目是否成熟的关键。