每日一个开源项目（第170篇）：CodeWiki - ACL 2026 论文级代码库自动文档生成，递归多 Agent 架构

引言

"CodeWiki 会给自己生成文档。"

这是"每日一个开源项目"系列的第170篇文章 。今天的主角是 CodeWiki------FPT Software（越南最大 IT 公司）AI4Code 团队开源的代码库级自动文档生成框架，已被 ACL 2026（计算语言学协会年会）收录。

代码库文档是一个几十年没被真正解决的问题。函数级注释解决了"这个函数做什么"，但跨文件、跨模块的架构理解------"这个组件为什么在这里""这条数据流走过哪些层"------一直没有系统性的解法。

CodeWiki 的切入点：用递归多 Agent 架构处理这个规模问题。Tree-Sitter 解析 AST 建依赖图，拓扑排序找处理顺序，底层模块先处理，向上汇总，复杂到单次处理放不下的模块自动派生子 Agent。最终输出带 Mermaid 架构图的完整 Markdown 文档。

你将学到什么

CodeWiki 的三阶段流水线：AST 解析 → 递归多 Agent 生成 → 分层汇总
动态委派（Dynamic Delegation）：Agent 如何判断自己处理不了并拆分
CodeWikiBench 评测框架：如何科学评估 AI 生成的文档质量
与 DeepWiki、deepwiki-open、OpenDeepWiki 的差异
增量更新设计：--update 只重新生成变更的模块

前置知识

了解 AST（抽象语法树）的基本概念
有代码库维护经验，理解文档痛点
了解 LLM 多 Agent 系统的基本概念

项目背景

为什么代码库文档难

函数注释生成已经是解决的问题，GitHub Copilot、各类 AI 辅助工具都能做。困难在更高层次：

arduino 复制代码

函数级（已解决）：
"这个函数接收 user_id，查询数据库，返回用户对象"

模块级（较难）：
"这个认证模块依赖 user_service 和 cache_layer，
 通过 JWT 验证，失败时回退到 session 验证"

仓库级（CodeWiki 要解决的）：
"这个代码库的整体架构是什么？
 数据如何从 API 层流向存储层？
 各模块之间的依赖关系是什么？"

仓库级理解的难点：依赖关系是跨文件的，架构描述需要全局视图，但大型代码库远超单次 LLM 上下文。

作者/团队介绍

组织: FSoft-AI4Code（FPT Software 的 AI 研究团队）
论文: ACL 2026 Findings 收录（aclanthology.org/2026.findings-acl.288）
License: MIT
语言: Python 3.12+

项目数据

⭐ GitHub Stars: 1,500+
🍴 Forks: 218+
📄 License: MIT
🎓 论文: ACL 2026

核心架构：三阶段流水线

阶段一：仓库分析（AST + 依赖图）

python 复制代码

# CodeWiki 用 Tree-Sitter 解析所有源文件
# 提取：函数、类、跨语言依赖关系
# 统一到 depends_on 关系，构建有向图 G=(V, E)

代码库
  ↓
Tree-Sitter AST 解析（支持 9 种语言）
  ↓
识别：函数定义、类定义、模块导入
  ↓
跨文件依赖归一化为 depends_on 有向图
  ↓
拓扑排序 → 找到零入度节点（无依赖的叶子模块）

依赖图的意义：A depends_on B 说明理解 A 需要先理解 B。拓扑排序给出处理顺序------先处理依赖，再处理依赖它的模块。

阶段二：递归多 Agent 文档生成

这是 CodeWiki 最核心的设计。

普通 LLM 处理代码库的问题：

复制代码

大型模块 → 超出 LLM 上下文窗口 → 截断 → 文档质量下降

CodeWiki 的动态委派（Dynamic Delegation）：

markdown 复制代码

处理某模块
    ↓
模块复杂度评估
    ↓
    ├── 可以单次处理 → 直接生成文档
    │
    └── 超出容量 → 派生子 Agent
                   子模块 1 → 子 Agent 1
                   子模块 2 → 子 Agent 2
                   子模块 3 → 子 Agent 3
                       ↓
                   所有子模块完成后，父 Agent 汇总

每个叶子 Agent 拥有：

完整的模块源码访问权
全局模块树视图（知道自己在整体架构中的位置）
依赖图遍历工具（可以查询上下游依赖）
全局注册表（避免重复生成，用引用代替）

阶段三：分层汇总（底部到顶部）

markdown 复制代码

叶子模块文档（底层，无依赖）
        ↓
父模块合并子模块文档 + 生成架构摘要
        ↓
顶层概述（整体架构 + 系统交互图）
        ↓
Mermaid 可视化生成：
    - 架构图
    - 数据流图
    - 时序图

输出结构：

bash 复制代码

./docs/
├── overview.md          ← 顶层架构概述
├── module_A.md          ← 各模块详细文档
├── module_B.md
├── module_tree.json     ← 机器可读的模块树
├── metadata.json        ← 生成元数据
└── index.html           ← --github-pages 选项生成

评测：CodeWikiBench

CodeWiki 为自己的评测问题也做了贡献------CodeWikiBench，一个专门评测 AI 生成代码文档质量的基准。

传统文本相似度指标（BLEU/ROUGE）不适合评测文档质量------一个技术上正确但啰嗦的文档可能得高分，一个精准的简洁文档可能得低分。

CodeWikiBench 的评测思路：

markdown 复制代码

1. 从官方文档中提取分层评测 rubric（打分标准）
   用多模型生成（Claude Sonnet 4、Gemini 2.5 Pro、Kimi K2）
   语义可靠性 73.65%，结构可靠性 70.84%

2. 多个 Judge Agent 做二元判断（通过/不通过）
   只在叶子节点判断，避免模糊的中间评分
   Judge 模型：Gemini 2.5 Flash、GPT OSS 120B、Kimi K2

3. 加权分数从叶子向上汇总
   带标准差置信区间

关键结果：

系统	平均分
OpenDeepWiki（开源）	47.13%
deepwiki-open（开源）	50.05%
DeepWiki（闭源，Cognition AI）	64.06%
CodeWiki	68.79%

CodeWiki 在 Python/JavaScript/TypeScript 上优势明显（TypeScript +18.54%，Python +9.41%）。在 C 和 C++ 上双方都表现一般，论文认为这是"语言特定解析复杂度"问题，和仓库大小关系不大。

快速开始

安装

bash 复制代码

git clone https://github.com/FSoft-AI4Code/CodeWiki.git
cd CodeWiki
pip install -e .

生成文档

bash 复制代码

# 基础用法：为当前目录生成文档
codewiki run . --output docs/

# 指定 LLM 提供商
codewiki run . --provider openai --model gpt-4o

# 使用 Claude
codewiki run . --provider anthropic --model claude-opus-4-6

# 使用 Claude Code 订阅（无需 API Key）
codewiki run . --provider claude-code

# 生成 GitHub Pages
codewiki run . --github-pages

# 增量更新（只重新生成自上次以来变更的模块）
codewiki run . --update

支持的 LLM 提供商

提供商	方式
OpenAI	API Key
Anthropic Claude	API Key
Azure OpenAI	API Key
AWS Bedrock	IAM
Atlas Cloud	API Key
Claude Code	订阅，无需 API Key
Codex CLI	订阅，无需 API Key

项目	Stars	质量	部署	技术栈	适合场景
CodeWiki	1.5k	最高（68.79%）	CLI	Python	大型代码库、追求质量
deepwiki-open	17.1k	中（50.05%）	Web UI	Python/TS	快速部署、Web 界面
OpenDeepWiki	未统计	中（47.13%）	Web UI	C#	.NET 环境
autodoc	较少维护	早期	CLI	Node.js	参考价值

项目地址与资源

🌟 GitHub : FSoft-AI4Code/CodeWiki
📄 论文 : ACL 2026 Findings · arXiv

总结

CodeWiki 的技术贡献是双层的：一个可用的工具，加一个评测基准。

工具层面，动态委派解决了真正的工程问题------大型代码库无法一次塞进 LLM 上下文。在 86K 到 140 万行代码的测试范围内，分层递归汇总保持了文档质量，而不是在边界处截断降级。

评测层面，CodeWikiBench 填了一个空缺：之前没有专门针对代码库文档质量的科学评测框架，这个工作也独立于 CodeWiki 工具本身有价值。

限制是真实的：C 和 C++ 的表现不及 Python/TypeScript；Stars 数量（1.5k）远低于 deepwiki-open（17.1k），说明易用性和社区运营还有差距。

对于需要深入处理大型代码库文档的场景，CodeWiki 的质量数据是目前开源方案里最有说服力的。对于快速部署和 Web 界面，deepwiki-open 是更省事的选择。

探索 PrimeSkills ------ 精选 AI Agent 与技能的市场，每一个都经过真实企业工作流验证，去掉浮夸，留下真正有用的。

欢迎访问我的个人主页，发现更多有价值的见解和有趣的产品。

每日一个开源项目（第170篇）：CodeWiki - ACL 2026 论文级代码库自动文档生成，递归多 Agent 架构

引言

你将学到什么

前置知识

项目背景

为什么代码库文档难

作者/团队介绍

项目数据

核心架构：三阶段流水线

阶段一：仓库分析（AST + 依赖图）

阶段二：递归多 Agent 文档生成

阶段三：分层汇总（底部到顶部）

评测：CodeWikiBench

快速开始

安装

生成文档

支持的 LLM 提供商

同类开源项目对比

deepwiki-open（AsyncFuncAI）

OpenDeepWiki（AIDotNet）

context-labs/autodoc

各方案定位总结

项目地址与资源

总结