AI Document Retrieval System

What is it（这是什么）

AI Document Retrieval System 是专为 AI Agent 设计的文档解析与检索基础设施。它和传统 RAG 的本质区别在于：传统 RAG 是"无状态"的——每次查询独立处理，不记忆上下文；而 AI Document Retrieval System 引入了有状态检索框架（如 RAFT 提出的方案），让 Agent 在多轮故障排查、连续对话中能记住"我上一轮检索了什么、排除了什么、下一步该查什么"。技术本质是把文档解析、向量检索、状态管理三者打包成 Agent 可直接调用的服务层。商业意义很直接：任何做垂直 Agent 的团队都需要这层基础设施，但自己从零搭建要耗费数月工程资源——这正是独立开发者的切入窗口。

Why now（为什么现在出现）

三个条件在 2026 年 Q3 同时成熟。第一，Agent 从 demo 走向生产：2025 年大量团队做出了能跑的 Agent 原型，2026 年进入"故障排查、工单处理、运维诊断"等需要连续状态的真实场景，无状态 RAG 直接失效。第二，开源文档解析工具链成熟：PDF 解析、表格提取、版面识别的开源方案已经能覆盖 80% 的企业文档格式，独立开发者不必从零造轮子。第三，MCP 协议在 2025 年底被主流 Agent 框架采纳，检索系统可以标准化地"插"进任何 Agent，分发成本骤降。一年前做这个，Agent 需求还没到；一年后做，大厂的基础设施团队已经进场。当前 nascent 阶段正是最佳切入窗口。

Market Evidence（市场证据）

信号质量偏弱但方向明确。从 v2ex 和 arxiv 两个独立信源获得 2 次提及，增长率 100%——但基数只有 2，增长率的意义有限，不能过度解读。v2ex 的出现说明有开发者在实际讨论落地问题（而非纯学术），arxiv 的 RAFT 论文说明学术侧在定义标准框架，两者结合是"技术从论文走向工程"的典型信号组合。当前阶段 nascent，趋势分数 62/100，属于"值得关注但尚未爆发"。判断：这是真实需求的早期信号，不是社区热点——因为驱动力来自 Agent 生产化的硬需求，而非某个大 V 的带货。但 2 个信源不足以确认趋势，需要观察未来 4-8 周是否有更多工程博客和 GitHub 项目跟进。

Who's Behind It（谁在推动）

学术侧是 RAFT 论文的作者团队，他们定义了"有状态检索增强"的框架标准，是这个领域的理论庄家。工程侧目前没有明确的领导者——这正是机会所在。开源社区方面，LlamaIndex 和 LangChain 都在扩展 Agent 检索能力，但它们的定位是"通用编排框架"，不会为 Agent 检索做深度优化。文档解析层有 Unstructured、Docling 等玩家，但它们只做解析不做检索状态管理。真正做"Agent 专用检索基础设施"的玩家几乎空白。大厂方面，OpenAI 的 Assistants API 和 Anthropic 的 MCP 生态都在往这个方向靠，但它们的策略是提供原语而非完整方案。结论：这是一个"有理论、无产品"的窗口期。

TAM & Market Size（市场规模）

潜在用户分三层。第一层是正在做垂直 Agent 的创业团队，全球约 5000-10000 家，每家愿意为检索基础设施付费 $100-500/月，对应年市场 $600万-6000万。第二层是企业内部的 AI 平台团队，规模约 20000 家，付费能力更强但决策周期长。第三层是独立开发者，付费意愿低但传播价值高。需求分 55/100，说明需求真实但尚未被充分验证——用户还在"自己搭"和"买现成"之间犹豫。机会分 58/100 反映的是"市场存在但需要教育"。市场处于增长期，驱动力是 Agent 生产化浪潮。定价锚点：参考 Pinecone（向量库）$70/月起、Unstructured API $0.01/页，Agent 检索层可以定价在 $99-499/月区间。

Competitive Landscape（竞争格局）

竞争分 45/100，属于中等偏低——意味着有玩家但没形成垄断。主要玩家分三类：第一类是通用 RAG 平台（LlamaIndex、Haystack），优势是生态完整，劣势是 Agent 检索只是它们的一个功能模块，不会做深度优化。第二类是文档解析 API（Unstructured、Reducto），优势是解析质量高，劣势是完全没有状态管理和 Agent 集成。第三类是向量数据库（Pinecone、Weaviate），优势是存储层稳固，劣势是它们不碰检索逻辑。市场空白非常清晰：没有玩家专门做"Agent 专用的有状态检索层"。大公司会不会做？OpenAI 和 Anthropic 会提供原语，但不会做垂直方案——你有 12-18 个月窗口。差异化机会在于：深度集成 MCP 协议 + 针对特定场景（如运维故障排查）做状态模板。

Business Model（商业模式）

推荐开源核心 + 云服务订阅的混合模式。理由：这个领域的用户是开发者，闭源产品获客成本极高；开源能建立信任和技术影响力，云服务承接不想自托管的付费用户。

具体定价：

• 开源版：免费，MIT 协议，包含核心检索和基础状态管理
• Pro 版：$149/月，包含托管服务、10 万页/月额度、MCP Server 托管、优先支持
• Team 版：$499/月，包含多租户、SSO、审计日志、50 万页/月

定价依据：对标 Unstructured（$0.01/页，10 万页即 $1000/月）和 Pinecone（$70/月起），$149 是开发者可自主决策的价格区间，不需要走采购流程。

12 个月收入预测：

• 保守：30 个 Pro 用户 + 5 个 Team = $6,900/月，年收入 $8.3万
• 基准：100 个 Pro + 20 个 Team = $24,800/月，年收入 $30万
• 乐观：300 个 Pro + 80 个 Team = $84,700/月，年收入 $100万

用户获取成本：开发者社区（GitHub、Hacker News、v2ex）自然获客为主，CAC 约 $50-150。回本周期 1-3 个月。

MVP Blueprint（MVP 蓝图）

核心功能（砍到只剩必须的）：

1. 文档上传与解析（支持 PDF/Markdown/HTML，用 Docling 或 Unstructured 做解析）
2. 向量化与存储（用 pgvector，避免引入独立向量库）
3. 有状态检索 API（核心差异化：记录检索历史，支持"基于上次结果继续查"）
4. MCP Server 封装（让 Agent 能直接调用）
5. 一个 CLI 工具做本地测试

砍掉的： 多租户、UI 界面、权限系统、计费系统——这些等有付费用户再做。

技术栈：

• 后端：Python + FastAPI
• 解析：Docling（开源，质量足够）
• 存储：PostgreSQL + pgvector
• 嵌入：OpenAI text-embedding-3-small 或本地 BGE-M3
• 部署：Fly.io 或 Railway，一键部署

最快上线路径： 用 FastAPI 模板起步，第 1-2 天做解析+存储，第 3-4 天做有状态检索逻辑，第 5 天封装 MCP Server，第 6 天写 README 和示例，第 7 天发到 GitHub 和 v2ex。预估开发天数 45 是完整产品，MVP 压缩到 7 天完全可行。

Commercial Opportunities（商业化机会）

方向一：Agent 检索托管服务

• 描述：提供托管的 Agent 专用检索 API，开发者只需上传文档、调用接口
• 目标用户：做垂直 Agent 的创业团队（法律、运维、客服）
• 预期月收入：$5,000-20,000
• 优势：直接对标付费意愿最强的用户群，不需要教育市场

方向二：垂直场景检索模板

• 描述：针对运维故障排查、法律文书检索等场景，提供预配置的状态管理模板
• 目标用户：企业内部 AI 平台团队
• 预期月收入：$10,000-30,000
• 优势：从"通用工具"升级为"解决方案"，客单价高 3-5 倍

方向三：MCP Server 市场分发

• 描述：做多个垂直领域的 MCP 检索 Server，在 MCP 市场上架
• 目标用户：Claude/Cursor 等 MCP 生态用户
• 预期月收入：$2,000-8,000
• 优势：获客成本极低，借力 MCP 生态增长

优先级：方向一 > 方向三 > 方向二。方向一最快验证付费意愿，方向三最省获客成本，方向二需要更多行业积累。

Product Ideas（产品创意）

🥇 StatefulDocs

• 价值主张：给 AI Agent 用的有状态文档检索 API，记住每一次查询的上下文
• 目标用户：做运维 Agent、客服 Agent 的创业团队
• 时机：Agent 生产化浪潮 + 无状态 RAG 痛点已显现
• 为什么现在：MCP 协议刚成熟，分发通道打开，竞品空白

🥈 MCP-Retrieve

• 价值主张：一键把任意文档库变成 MCP Server，5 分钟接入 Claude/Cursor
• 目标用户：独立开发者、小团队
• 时机：MCP 生态爆发期，工具稀缺
• 为什么现在：借 MCP 生态增长红利，获客成本接近零

🥉 TroubleshootRAG

• 价值主张：专为运维故障排查设计的检索框架，内置状态机和排查流程模板
• 目标用户：SRE 团队、DevOps 平台团队
• 时机：RAFT 论文刚定义了故障排查场景的标准框架
• 为什么现在：垂直场景竞争几乎为零，可以建立行业标准

SEO Opportunity（SEO 机会）

搜索量趋势：上升，但基数小。SEO 难度 30/100，属于容易拿排名的领域。

推荐长尾关键词：

• "agent document retrieval API"
• "stateful RAG framework"
• "MCP server document search"
• "AI agent troubleshooting retrieval"
• "RAFT retrieval augmented"

内容策略：优先做技术教程 + 对比页面。"如何为 Claude Agent 接入文档检索"这类教程最容易拿排名，因为竞品内容稀缺。其次做"Stateful RAG vs Traditional RAG"对比页，承接概念教育流量。GitHub README 和文档站的 SEO 权重会被 Google 优先收录，投入产出比最高。

Risk Assessment（风险评估）

判断可能错的情况： 如果 Agent 生产化进度慢于预期，或者大厂（OpenAI/Anthropic）直接提供完整的有状态检索方案，这个窗口就会关闭。

三大风险：

1. 技术风险：有状态检索的工程复杂度被低估，MVP 可能做不到"真的有用"。缓解：先用最简单的方式实现，验证用户是否真的需要状态。
2. 市场风险：用户可能觉得"自己用 LangChain 搭就行"，不愿意付费。缓解：开源核心，靠托管服务变现。
3. 执行风险：45 天开发周期对独立开发者偏长，容易中途放弃。缓解：7 天 MVP 先验证，再决定是否投入完整开发。

最低成本验证： 写一篇"为什么 Agent 需要有状态检索"的技术博客发到 v2ex 和 Hacker News，看反馈。如果 48 小时内获得 50+ 真实讨论，就值得做。

放弃信号： 如果 3 个月内没有 10 个付费用户，或者大厂发布了直接竞品，立即转向。

Action Plan（行动建议）

第一步（今天）： 在 GitHub 创建仓库 stateful-retrieval，写一份 500 字的 README 说明"Agent 专用有状态检索"的定位，发到 v2ex 和 Hacker News 看反应。

低成本验证： 用 FastAPI + pgvector 在 3 天内做出最小 demo，支持"上传文档 → 检索 → 记住上次结果"的核心流程。录一个 2 分钟演示视频。

信号确认后第二步： 封装 MCP Server，发布到 MCP 市场，同时写 3 篇技术教程做 SEO。

时间线：

• 第一周：完成 MVP demo，发布到社区，收集 20 个反馈
• 第一个月：上线托管服务，定价 $149/月，目标 10 个付费用户
• 第三个月：扩展到 50 个付费用户，月收入 $7,500，开始做垂直场景模板

Related Terms（相关趋势）

• RAFT — 直接依赖关系，RAFT 论文定义了有状态检索的理论框架，是本趋势的学术基础
• MCP Server — 互补关系，MCP 是分发通道，AI Document Retrieval System 是 MCP 生态中的关键能力模块
• Vector Database — 底层依赖关系，向量库是检索系统的存储层，两者通常一起出现但定位不同
• Agentic RAG — 子领域关系，Agentic RAG 是更宽泛的概念，AI Document Retrieval System 是其基础设施层