CocoIndex
让 AI 应用以增量方式持续获得新鲜、可追溯的数据上下文。
- Star 数
- ★ 12k
- 最近更新
- 今天
- License
- Apache-2.0
- 主语言
- Rust
- FA 评分
- 49/100 · 缺口较多
30 秒速览
- 运行形态
- 可在哪里用
- 通用 · 跨平台
- 费用
- 软件免费，模型调用费用自付
- 上手难度
- 中 · 需要几步配置
- 开始前需要
- 典型场景
- 开发团队希望把本地文档目录写入 PostgreSQL 向量表，并在文档改动后更新相应文本块时使用。
- 不适合
- 需要开箱即用、无需自备数据库和嵌入服务的团队
- 希望用命令行或容器一键部署、无需编写 Python 代码的团队
这个 Agent 能做什么，适合哪些场景？
CocoIndex 是一个以 Python 声明数据转换流程、由 Rust 核心支撑的增量数据处理框架。它面向代码库、文档、会议记录等数据，为 RAG、向量检索、知识图谱和其他 AI 应用持续维护目标数据。开发者通过 @coco.fn 定义转换，通过 coco.App(...).update_blocking() 执行同步；框架的示例将本地文件拆分、生成嵌入并写入 PostgreSQL 表。带 memo=True 的函数会按输入和代码哈希缓存，README 将其定位为只重新处理变化数据及受影响输出的执行模型。它作为嵌入应用程序的 Python 库运行，而非独立聊天代理；示例的最终存储边界是外部 PostgreSQL，且嵌入函数和连接配置由使用者提供。
示例先用 localfs.walk_dir(src).items() 枚举本地目录中的文件，再在 index_file 中调用 await file.read_text() 读取文本。RecursiveSplitter().split(...) 把文本切成块，table.declare_row(text=chunk.text, embedding=embed(chunk.text)) 为每个块声明文本和嵌入行。main 通过 postgres.mount_table_target(PG, table_name="docs") 挂载 PostgreSQL 目标表，使用 table.declare_vector_index(column="embedding") 声明向量索引，并以 coco.mount_each(index_file, ..., table) 将每个文件交给转换函数。最后 coco.App(coco.AppConfig(name="docs"), main, src="./docs").update_blocking() 运行更新；README 说明再次运行时会重新嵌入已改变的文件。
- 开发团队希望把本地文档目录写入 PostgreSQL 向量表，并在文档改动后更新相应文本块时使用。
- 构建代码检索或编码助手的工程师，需要对 Git 仓库中的源码进行 AST 感知切分、嵌入和增量索引时使用。
- 负责 PDF 问答系统的团队，需要将 PDF 提取、分块和向量写入流程做成可重复更新的 RAG 索引时使用。
- 运营或研究团队需要从 Hacker News 线程及评论中提取主题、计算加权提及次数并保存到 PostgreSQL 时使用。
- 处理会议转录、Slack 对话或播客内容的团队，需要抽取人员、主题、决策和行动项并写入 Neo4j 或 Kuzu 图数据库时使用。
- 数据工程师需要监视 CSV 文件并将变更行以 JSON 消息发布到 Kafka 主题时使用。
如何安装或部署这个 Agent？
运行环境为 Python 3.10–3.13。安装命令：
pip install -U cocoindexREADME 没有提供 PG 的连接值或凭据格式，也没有给出 embed 的实现、模型配置或密钥；因此无法仅依据现有材料给出可直接完成写入的数据库凭据配置。
如何使用这个 Agent？
README 提供的首个执行入口是：
coco.App(coco.AppConfig(name="docs"), main, src="./docs").update_blocking()其中 main 需要调用 postgres.mount_table_target(PG, table_name="docs")，而 index_file 需要调用 embed(chunk.text)。要按该示例成功运行，使用者必须自行提供 PG 和 embed；材料未说明这两个值的定义方式、所需凭据或完整可运行脚本。示例的输入目录为 ./docs，输出为名为 docs 的 PostgreSQL 目标表及其 embedding 列上的向量索引。
这个 Agent 有哪些优点和局限？
- 增量执行模型明确：README 说明重复运行时只重新处理已改变的文件，而 @coco.fn(memo=True) 按输入与代码哈希缓存结果。
- Python 转换代码可直接组织为异步函数，并用 coco.mount_each 将单文件处理函数映射到来源条目，无需在示例中单独编排 DAG。
- 示例展示了从本地文件读取、文本分块到 PostgreSQL 向量表和向量索引的一条完整声明式链路。
- README 还列出了代码索引、PDF RAG、知识图谱、结构化抽取和 CSV 到 Kafka 等不同目标形态。
- 最小示例并不完整：PG 连接配置和 embed 函数均未定义，不能原样作为可运行的首次部署。
- 实际使用通常需要外部目标系统；示例至少依赖 PostgreSQL，其他示例还涉及 Neo4j、Kuzu、Kafka 或模型服务。
- README 宣称 Rust 核心具备重试、退避、死信队列和无数据丢失特性，但未给出这些机制的配置接口或运维流程。
- 没有提供 CLI 部署流程、容器配置或生产环境凭据管理说明，团队需自行确定运行、调度和密钥管理方案。
这个 Agent 与同类方案有什么区别？
相较于定期全量重跑的批处理数据管道，CocoIndex 的定位是根据来源或转换代码的变化，仅重新计算受影响的数据与输出。
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | 形态 / 费用 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|---|
| CocoIndex 当前 | 49 · 缺口较多 | 代码库 / SDK免费 + 模型费 | ★ 12k | 今天 | Rust | — |
| Telegram Search | 58 · 缺口较多 | 自托管服务免费 + 模型费 | ★ 4.1k | 1 天前 | TypeScript | — |
| M-flow 认知记忆引擎 | 36 · 缺口较多 | 命令行工具免费 + 模型费 | ★ 4.5k | 3 个月前 | Python | OpenAI API · Claude API |
| Mnemosyne | 59 · 缺口较多 | 命令行工具免费 | ★ 3.6k | 2 天前 | Python | Codex · Claude Code |
FollowAgents 如何评估这个 Agent？
查看各维度的扣分理由
证据显示：项目采用Apache-2.0许可证，依赖列表明确，但未提供安全审计或漏洞扫描证据。数据流透明度方面，README描述了数据流和增量处理，但未详细说明数据如何被处理、存储或传输。敏感数据处理未明确提及。外部影响方面，项目涉及外部API调用（如LLM、数据库），但未说明权限控制或用户确认机制。回滚机制未明确。来源归属方面，作者信息明确，但发布者未验证。扣分原因：缺乏用户确认、敏感数据处理细节、外部影响控制、回滚机制和来源验证。
证据显示：项目有CI工作流，依赖版本固定，但未提供故障消息的详细说明。自一致性方面，README和代码示例一致，但未提供完整的错误处理文档。扣分原因：故障消息不明确，依赖可用性未充分验证。
证据显示：README提供了多个使用场景和示例，能力边界通过示例说明，但未明确触发条件。环境适配方面，支持多种数据库和存储，但未说明特定环境要求。扣分原因：触发精度不足，环境适配细节有限。
证据显示：README结构清晰，安装说明简单，许可证明确，但缺少版本变更日志和已知限制的详细说明。维护责任方面，作者信息明确，但未提供维护计划。扣分原因：命名稳定性未明确，版本变更日志缺失，已知限制未充分说明。
证据显示：README强调增量处理带来的成本效益，示例展示了输出可用性。边际价值方面，项目提供了独特的增量引擎功能。扣分原因：成本效益数据未量化，输出可用性未充分验证。
证据显示：README中的声明有示例支持，但未提供独立的验证来源。事实与推断分离方面，未明确区分。扣分原因：声明可追溯性不足，交叉来源验证有限。
- 源码中未见：执行前用户确认开启或自行加上执行前确认；先在沙箱或测试环境跑通，确认行为后再接入真实数据。
- 发布者身份未验证，需谨慎评估供应链风险。
- 未提供安全审计或漏洞扫描证据，依赖安全性需进一步验证。
- 敏感数据处理和外部影响控制细节不足，部署前需评估数据保护措施。
- 缺少版本变更日志和已知限制说明，升级前需自行验证兼容性。
最近版本
来自该项目 GitHub Releases 的最新发布记录，说明为上游原文摘录，未经本站改写或测试。
-
发布说明摘录
What's Changed * fix(engine): a live component that calls operator.update() before any update_full() no longer loses what it mounted on its first run. Its existence row was only written at its parent's commit, so the first child's eager existence write filed it as a directory node, and the parent's commit then tombstoned every child mounted so far. Watch-only feeds (Kafka, Iggy, any LiveMapFeed with only watch()) hit this on a first run against a backlog; later runs were unaffected. Items a first run lost come back when the source delivers them again by @georgeh0 in https://github. …在 GitHub 查看 ↗ -
发布说明摘录
What's Changed Connector key fixes: no more collisions or lost writes Every source item and target state has a key. CocoIndex uses the key to match an object with its previous run, and to decide what to create, update or delete. Prompted by the Google Drive fix in #2485, this release audits how every Python connector builds its keys. It fixes each case where the connector gave two different objects one key, or where a key that changed for the same object made CocoIndex delete that object. Two keys you choose can also reach one object, such as overlapping directories or two `ContextKey …在 GitHub 查看 ↗ -
发布说明摘录
What's Changed * Security: exclude litellm 1.107.0, which was published to PyPI with a credential stealer and backdoor, from every litellm requirement (the litellm, entity_resolution_llm and all extras, and the examples). The locked version stays 1.96.2, which is unaffected by @georgeh0 in https://github.com/cocoindex-io/cocoindex/pull/2576 * Preview works on real pipelines and writes nothing …在 GitHub 查看 ↗