2026 年 3 月值得关注的 12 个 AI 开发与 Agent 开源项目

3 月的热门开源项目有一个很明显的方向：AI 编程正在从“把需求丢给模型”变成“给模型配完整工程环境”。

单靠大语言模型生成代码，常见问题是规划不足、上下文不完整、缺少测试、执行环境不安全。于是很多项目开始围绕几个关键环节补能力：让 Agent 会规划、会拆任务、能调用工具、能执行代码、能记住长期上下文，还能理解整个代码仓库的依赖关系。

先用一张表看全貌。

Star 数只能说明关注度，不能直接等同于稳定性。真正选型时，更应该看项目解决的是哪一层问题：提示词、工作流、运行时、上下文、沙箱，还是数据采集。

AI 编程工具正在补齐工程流程

最原始的 AI 编程方式通常是这样的：

flowchart LR
    A[用户描述需求] --> B[大语言模型生成代码]
    B --> C[直接修改项目]
    C --> D{能不能跑}
    D -->|能| E[提交]
    D -->|不能| F[继续让模型修]
    F --> B

这个流程的问题不在于模型不会写代码，而在于它缺少工程约束。一个成熟工程师写代码时，不会一上来就改文件，而是会先确认需求、拆任务、看上下文、写测试、评估影响范围，再动手实现。

更合理的 AI 编程流程应该接近这样：

flowchart TD
    A[需求输入] --> B[澄清目标和边界]
    B --> C[读取代码上下文]
    C --> D[制定实现计划]
    D --> E[设计评审]
    E --> F[编写或更新测试]
    F --> G[修改代码]
    G --> H[运行测试和静态检查]
    H --> I[代码审查]
    I --> J{是否通过}
    J -->|是| K[产出变更说明]
    J -->|否| D

Superpowers、Everything Claude Code、Claude Code Best Practice、Learn Claude Code 都是在补这条链路，只是切入点不同。

Superpowers：把工程师工作方式做成 Skill

Superpowers 的核心思路很直接：不要让 AI 拿到需求就开始写代码，而是把需求讨论、设计评审、测试驱动开发、代码审查等工程动作封装成可自动触发的 Skill。

仓库地址：

https://github.com/obra/superpowers

它更像是给 Claude Code、Cursor、Codex 这类工具装一套“工程习惯插件”。当模型准备处理任务时，Skill 会把它拉回到更稳定的流程里，例如：

Superpowers 适合已经在使用 AI 编程工具的人，尤其适合从零开发新功能、重构模块、补测试这些任务。它不适合替代人做架构决策，因为 Skill 能约束流程，但不能保证业务判断一定正确。

Everything Claude Code：用 Agent、Skill 和命令体系增强 Claude Code

Everything Claude Code 走的是更完整的工作流路线。它提供多个专业 Agent、大量 Skill 和命令，把编码助手拆成不同职责的角色。

仓库地址：

https://github.com/affaan-m/everything-claude-code

它的典型能力可以分成三类：

这个项目比较有特点的是持续学习机制：它可以从编程会话中提取模式和最佳实践，再转换成后续可复用的知识或 Skill。这样做的价值在于，团队的项目约定、目录习惯、测试习惯不必每次都重新解释。

需要注意的是，任何“自动学习”机制都要关注两件事：

1. 会不会把临时错误也沉淀成规则。
2. 会不会把敏感信息写入可复用上下文。

更稳妥的做法是定期审查自动生成的 Skill，把项目约定和个人偏好分开管理。

Claude Code Best Practice：把 Claude Code 用法整理成工程手册

Claude Code Best Practice 更像一份实战手册，聚焦 Claude Code 的提示词、规划、CLAUDE.md、Skills、Hooks 等主题。

仓库地址：

https://github.com/shanraisshan/claude-code-best-practice

如果已经在用 Claude Code，但经常遇到这些问题，可以优先看这个项目：

CLAUDE.md 可以理解为项目级说明文件，里面通常放项目结构、编码规范、测试命令、常见坑和开发约定。它不是提示词魔法，而是让模型每次进入项目时都能拿到稳定上下文。

一个实用的 CLAUDE.md 通常应该包含这些内容：

# Project Guide

## Tech Stack
- Runtime: Node.js 20
- Framework: Next.js
- Test: Vitest

## Common Commands
- Install: pnpm install
- Test: pnpm test
- Lint: pnpm lint

## Code Rules
- Do not introduce new state management libraries.
- Keep API clients in src/lib/api.
- Add tests for bug fixes.

## Important Notes
- User permissions are checked in src/server/auth.
- Do not bypass permission checks in route handlers.

重点不是写得长，而是让模型知道哪些规则不能破坏。

Learn Claude Code：从 Agent Loop 理解编码助手

Learn Claude Code 的口号是 “Bash is all you need”。它不是直接给你一个成品工具，而是用递进课程解释 Claude Code 类工具是怎么工作的。

仓库地址：

https://github.com/shareAI-lab/learn-claude-code

一个编码 Agent 的核心并不神秘，最小结构通常是 Agent Loop：

flowchart TD
    A[用户任务] --> B[构造消息和上下文]
    B --> C[调用大语言模型]
    C --> D{模型是否请求工具}
    D -->|是| E[执行工具: 读文件/写文件/运行命令]
    E --> F[把工具结果加入上下文]
    F --> C
    D -->|否| G[返回最终结果]

用伪代码表示，大致是：

messages = [{"role": "user", "content": "修复登录接口的 bug"}]

while True:
    response = llm.chat(messages=messages, tools=available_tools)

    if response.tool_call:
        result = execute_tool(response.tool_call)
        messages.append(response.tool_call)
        messages.append({
            "role": "tool",
            "content": result
        })
        continue

    print(response.content)
    break

真正拉开差距的是外部环境，而不是循环本身：

如果目标是自己实现一个编码 Agent，Learn Claude Code 比直接研究大型框架更适合入门。

DeerFlow：让 Agent 拥有运行时和子 Agent 编排能力

DeerFlow 是字节跳动开源的超级智能体运行框架。它的定位不是单个提示词框架，而是 Agent 运行时。

仓库地址：

https://github.com/bytedance/deer-flow

Agent 要完成复杂任务，只会聊天不够，还需要一个可控的执行环境。DeerFlow 提供的关键能力包括：

• 沙盒文件系统：Agent 可以读写文件，但不直接污染真实环境。
• 代码执行：Agent 能运行脚本、验证结果、生成产物。
• 子智能体：Lead Agent 可以动态创建子 Agent。
• 独立上下文：每个子 Agent 可以拥有自己的上下文和工具。
• 并行执行：多个子任务可以同时推进。

它的结构可以这样理解：

flowchart TD
    U[用户目标] --> L[Lead Agent]
    L --> P[任务拆解和计划]
    P --> A1[子 Agent A<br/>资料检索]
    P --> A2[子 Agent B<br/>代码实现]
    P --> A3[子 Agent C<br/>测试验证]
    A1 --> S[(沙盒文件系统)]
    A2 --> S
    A3 --> S
    A1 --> R[结果汇总]
    A2 --> R
    A3 --> R
    R --> L
    L --> O[最终产出物]

DeerFlow 适合处理多步骤、多工具、多产物的任务，例如自动生成报告、代码改造、数据处理流水线。它不适合简单问答，因为引入运行时和多 Agent 编排会增加系统复杂度。

OpenSandbox：AI 执行代码必须放进隔离环境

当 Agent 具备执行命令、修改文件、运行代码的能力时，安全边界就变得非常重要。不能把模型生成的命令直接放到开发机或生产环境执行。

OpenSandbox 是阿里巴巴开源的 AI 应用通用沙箱平台，目标是为 AI Agent 提供安全隔离的运行环境。

仓库地址：

https://github.com/alibaba/OpenSandbox

它支持多种安全容器运行时，包括 gVisor、Kata Containers、Firecracker microVM 等。不同隔离方案的取舍大致如下：

OpenSandbox 还预集成了 Claude Code、Gemini CLI、OpenAI Codex CLI 等编码 Agent，并提供 Python、Java、JavaScript、C# 等多语言 SDK（软件开发工具包）。

一个典型调用链是：

sequenceDiagram
    participant User as 用户
    participant Agent as AI Agent
    participant Sandbox as OpenSandbox
    participant Runtime as 隔离运行时
    participant FS as 临时文件系统

    User->>Agent: 提交编码任务
    Agent->>Sandbox: 请求创建沙箱
    Sandbox->>Runtime: 启动隔离环境
    Agent->>Sandbox: 写入代码和命令
    Sandbox->>FS: 创建临时工作目录
    Sandbox->>Runtime: 执行测试或脚本
    Runtime-->>Sandbox: 返回 stdout/stderr/退出码
    Sandbox-->>Agent: 返回执行结果
    Agent-->>User: 给出修复结果和说明

OpenSandbox 可以本地 Docker 运行，也可以部署到 Kubernetes 做大规模调度。它更适合团队级 Agent 平台，而不是个人随手跑一个脚本。

GitNexus：把代码仓库索引成知识图谱

AI 编程助手经常出错，并不是因为不会写某个函数，而是看不到足够完整的依赖关系。比如一个返回类型被 47 个调用方依赖，模型只看当前文件就直接改，很容易引入连锁 bug。

GitNexus 的思路是把代码仓库索引成知识图谱，追踪依赖关系、调用链和执行流程。

仓库地址：

https://github.com/abhigyanpatwari/GitNexus

知识图谱给 AI 提供的是“架构地图”：

flowchart LR
    A[API Handler] --> B[UserService]
    B --> C[PermissionChecker]
    B --> D[UserRepository]
    D --> E[(Database)]
    B --> F[AuditLogger]
    G[AdminService] --> B
    H[BillingService] --> B

如果模型要修改 UserService，它应该知道 API Handler、AdminService、BillingService 都可能受到影响。GitNexus 在索引阶段提前完成聚类、追踪和评分，查询时可以直接返回相关上下文，减少模型在仓库里来回搜索的成本。

它支持 14 种以上编程语言，并提供 CLI（命令行界面）和 Web UI 两种使用方式。Web UI 可以在浏览器端运行，拖入 ZIP 文件就能生成交互式知识图谱，这对快速理解陌生项目很有帮助。

适合使用 GitNexus 的场景：

OpenViking：给 Agent 准备上下文数据库

传统 RAG（Retrieval-Augmented Generation，检索增强生成）系统常见的问题是记忆太碎：向量库里放一部分，文件系统里放一部分，提示词里又塞一部分，Agent 很难稳定管理自己的长期知识。

OpenViking 是火山引擎推出的 Agent 上下文数据库，目标是统一管理 Agent 的记忆、资源和技能。

仓库地址：

https://github.com/volcengine/OpenViking

它采用类似文件系统的范式来组织上下文。开发者可以像管理目录一样管理 Agent 的“大脑”：

flowchart TD
    A[Agent Context Root] --> B[Memory<br/>长期记忆]
    A --> C[Resources<br/>文档和数据]
    A --> D[Skills<br/>可复用能力]
    B --> B1[用户偏好]
    B --> B2[项目事实]
    C --> C1[接口文档]
    C --> C2[业务规则]
    D --> D1[代码审查 Skill]
    D --> D2[测试生成 Skill]

OpenViking 的关键设计是三级分层上下文加载。不是每次都把所有信息塞给模型，而是按任务需要加载：

它还支持上下文自迭代：从会话中提取长期记忆，再写回上下文库。可视化检索轨迹也很重要，因为 Agent 出错时，很多问题不是模型不会答，而是检索到了错误资料或漏掉关键资料。

OpenViking 支持豆包、Claude、DeepSeek、Gemini、Ollama 等多种模型后端，适合需要长期记忆和可调试检索链路的 Agent 系统。

Scrapling：网站改版后也能定位目标元素

爬虫维护最麻烦的地方不是写第一版，而是目标网站一改版，CSS 类名、DOM 层级、按钮位置全变，原来的选择器直接失效。

Scrapling 是一个自适应 Python 爬虫框架，核心能力是通过相似度算法重新定位目标元素。

仓库地址：

https://github.com/D4Vinci/Scrapling

普通爬虫通常依赖固定选择器：

price = page.css(".product-price").text()

一旦网站把类名改成 .item-price-v2，这段代码就会失效。Scrapling 的自适应解析器会参考元素文本、结构、属性、相对位置等特征，尝试找到“最像原目标”的新元素。

flowchart LR
    A[历史目标元素] --> B[提取特征]
    B --> C[页面改版]
    C --> D[扫描候选元素]
    D --> E[计算相似度]
    E --> F[重新定位目标元素]

它还提供统一 API，覆盖简单请求和大规模并发抓取，并支持 MCP（Model Context Protocol，模型上下文协议），可以和 Claude、Cursor 等 AI 工具集成，用于 AI 辅助抓取。

需要强调的是，爬虫应在合法授权、遵守网站协议和隐私规范的前提下使用。绕过反机器人系统可能违反服务条款，生产环境使用前必须确认合规边界。

Lightpanda：为服务器自动化重写无头浏览器

Chrome 很强，但用它做无头自动化时资源消耗不低。爬虫、自动化测试、AI Agent 网页操作这些场景，很多时候并不需要完整图形渲染，只需要加载页面、执行 JavaScript、读取 DOM、处理网络请求。

Lightpanda 是一个用 Zig 语言从零编写的无头浏览器，目标是比传统浏览器更轻。

仓库地址：

https://github.com/lightpanda-io/browser

它兼容 CDP（Chrome DevTools Protocol，Chrome 开发者工具协议），因此 Playwright、Puppeteer 这类工具的迁移成本会低很多。

Lightpanda 适合高并发网页处理，尤其是需要大量浏览器实例的任务。它仍处于 Beta 阶段，生产使用前要验证目标网站的兼容性，特别是复杂前端框架、浏览器 API 和反自动化检测相关逻辑。

Project AIRI：让 AI 不只聊天，还能互动和玩游戏

Project AIRI 的目标是构建开源 AI 虚拟生命。它不只是聊天机器人，还支持实时语音、虚拟形象和游戏交互。

仓库地址：

https://github.com/moeru-ai/airi

AIRI 的能力可以拆成几层：

它已经能玩 Minecraft，也验证过 Factorio 场景。和纯聊天平台相比，AIRI 的关键差异是“行动闭环”：AI 不只是生成回复，还能根据游戏状态做决策，再通过接口影响环境。

flowchart LR
    A[用户语音/文本] --> C[对话上下文]
    B[游戏状态] --> C
    C --> D[大语言模型]
    D --> E[行为决策]
    E --> F[语音回复]
    E --> G[虚拟形象表情]
    E --> H[游戏操作]
    H --> B

AIRI 适合虚拟主播、AI 陪伴、游戏 Agent 实验等方向。如果目标只是做客服问答，它会显得过重，因为语音、形象、游戏动作都不是必需组件。

RuView：用 WiFi 信号变化感知人体状态

RuView 是一个利用 WiFi 信号进行人体感知的项目。它通过分析 WiFi 的 CSI（Channel State Information，信道状态信息）来推断人体位置、呼吸频率和心率等信息。

仓库地址：

https://github.com/ruvnet/RuView

WiFi 信号在室内传播时，会受到人体移动、胸腔起伏、姿态变化的影响。CSI 记录的是无线信道的细粒度变化，经过处理后可以提取出和人体活动相关的模式。

flowchart LR
    A[WiFi 发射和接收] --> B[采集 CSI 信道状态信息]
    B --> C[滤波和去噪]
    C --> D[特征提取]
    D --> E[位置估计]
    D --> F[呼吸频率估计]
    D --> G[心率估计]
    E --> H[本地结果输出]
    F --> H
    G --> H

它的特点是硬件成本低，可以在 ESP32-S3 微控制器上运行，并且不依赖云服务，数据可以在本地处理。WiFi 信号具备一定穿透能力，因此也可能做到隔墙感知。

这类技术必须重视隐私和授权。任何人体感知系统都应该在被感知者知情同意的前提下使用，并且要明确数据保存、处理和访问边界。

从选型角度看这些项目

这些项目可以按技术层级放到一张图里：

flowchart TD
    A[AI 编程和 Agent 应用] --> B[工作流层]
    A --> C[运行时层]
    A --> D[上下文层]
    A --> E[执行安全层]
    A --> F[外部环境层]

    B --> B1[Superpowers]
    B --> B2[Everything Claude Code]
    B --> B3[Claude Code Best Practice]
    B --> B4[Learn Claude Code]

    C --> C1[DeerFlow]
    E --> E1[OpenSandbox]

    D --> D1[GitNexus]
    D --> D2[OpenViking]

    F --> F1[Scrapling]
    F --> F2[Lightpanda]
    F --> F3[AIRI]
    F --> F4[RuView]

如果不知道从哪个开始，可以按需求选：

更稳妥的试用顺序是：先在小项目里验证，再接入真实工作流；先限制权限，再开放写文件和执行命令；先跑测试和静态检查，再让 Agent 改核心模块。AI 工具越强，越需要工程边界来约束它。