CocoIndex:让 AI Agent 告别全量重算的增量引擎

现在 AI Agent 项目最大的坑不是写不出来,而是改不动——一篇文档改了一个字,你就要全量重新 embedding 一次,几百 G 的向量库一晚上炸掉,索引、数据、上下文全乱套。这种”全量重算”的旧范式,在长周期 Agent 时代已经彻底失灵了。

今天要聊的 CocoIndex,直接对准这个痛点:它是一套面向 AI 工作负载的增量计算引擎,用声明式 Python 把数据转换流程写出来,然后引擎自动只算”差量”,代码改了、文件新增了、API 返回值变了——它只重新处理真正受影响的那一小段。Star 已经 9.2k+,GitHub Trending 长期霸榜。

为什么 Agent 特别需要”增量”

传统数据 pipeline 是批处理思维:每天凌晨全量跑一次 ETL,早上拿结果。但 Agent 不一样——它 7×24 小时在线,边跑边消费数据、边修改上下文。一个 RAG Agent 可能一边读 Notion、一边写 Postgres、一边响应用户,任何一步的数据变化都必须秒级反映到下游,否则就会出现”AI 引用了已经改过的文档””向量库和源文件不一致”这种灵异 bug。

CocoIndex 的解法很优雅:每个函数用 @coco.fn(memo=True) 装饰,引擎自动按 hash(输入) + hash(代码) 做缓存。代码没变、输入没变——直接复用上次结果;输入变了——只重算这一个函数及其下游。这就是 React 那种”声明式 + 自动 diff”的思路,被他们搬到了数据层。

5 行代码搭一个生产级 RAG

官方文档给了个让人震惊的极简示例:扫描本地文件夹、切块、embed、灌进 Postgres 向量库,5 行 Python 就完事:

• 声明目标:用 table.declare_row() 描述最终表长什么样
• 声明数据源:localfs.walk_dir() 一行扫目录
• 声明处理逻辑:RecursiveSplitter + embedding 函数
• 声明存储目标:postgres.mount_table_target() + 向量索引
• 挂载编排:coco.mount_each() 把处理函数和数据源接上

跑一次全量 backfill,之后任何时候再跑都只算 Δ。增删改文件,不需要写 diff 逻辑、不需要 cron、不需要监听文件事件——引擎自己判断依赖图,自动重算最小子图。

和传统 ETL 框架的代差

用 Airflow、Prefect、dbt 这些老牌框架,你要写 DAG、调调度器、处理失败重试、跑对账脚本。CocoIndex 把这些全免了——它内置并行调度、自动持久化、Postgres 状态恢复。你只关心”数据应该长什么样”,剩下的脏活全交给引擎。

更狠的是它对 AI 编程 Agent 友好到极致:仓库里直接附了一个 CocoIndex Skill(SKILL.md 标准格式),Claude Code / Cursor / Codex 等 70+ 工具一条命令就能装上,装完 Agent 就能写出 v1 就能跑的代码,不用反复 debug API。

适用场景

• 持续同步代码库 / Notion / Slack / Gmail 到 RAG 知识库
• 多模态数据 pipeline(视频、PDF、音频转结构化 + 向量化)
• Agent 的长周期 memory 层,实现”跨会话的累积式学习”
• 替代笨重的 Airflow,部署到 serverless 环境

如果你的 Agent 项目正在被”数据同步不及时””向量库和源文件对不上””增量逻辑写到怀疑人生”这三个问题折磨,真的该看看 CocoIndex。它代表了 2026 年 AI Infra 的一个新方向:把 React 思维带到数据层,让增量计算成为 LLM 应用的默认范式,而不是高级优化技巧。

GitHub 仓库:https://github.com/cocoindex-io/cocoindex

GitHub: https://github.com/cocoindex-io/cocoindex