一个TypeScript项目，想解决企业AI的"上下文危机"

八年前，RAG（检索增强生成）还只是个学术概念。今天，几乎每个想在大模型里用内部数据的企业，都在重复造同一套轮子。

开发者Anmol Sharma最近开源了一个叫ORAG的项目。不是什么大模型，也不是新算法——而是一个用TypeScript写的组织级RAG和MCP平台。他的出发点很直接："每个团队在用内部数据做AI功能时，都会撞上同一堵墙。"

这堵墙是什么？大模型不知道你的数据意味着什么。不知道谁拥有它，不知道它是否可信，更不知道某个AI代理该不该访问它。结果是：AI给出自信但错误的答案——这比没有答案更糟。

Sharma认为这是上下文层的问题，而非模型问题。模型本身没问题，缺的是让模型"理解"组织数据的中间层。ORAG的架构分成三层：连接层、协议层、治理层。

连接层负责接入Notion、Confluence、S3、GitHub等数据源，处理分块、嵌入和向量检索。Sharma给检索延迟定的目标是50毫秒以内。协议层把检索能力暴露为MCP（模型上下文协议）服务器——一个配置文件，就能让任何AI代理以结构化、带权限的方式访问组织知识库。治理层则处理角色权限、审计日志、团队工作区和SSO单点登录。

技术选型上，ORAG完全基于TypeScript生态。连接层用Ingestion SDK，向量数据库选的是Pinecone，MCP服务器层用FastMCP，治理层则依赖Clerk做认证、Prisma做ORM、PostgreSQL持久化数据。

Sharma特别强调了MCP的价值。没有它，每个新代理、每个新数据源都要写定制胶水代码：定制连接器、定制认证、定制错误处理。MCP给AI代理提供了一个标准接口，"一个配置，你的代理就能像调用其他类型化API一样调用你的知识库，自带流式传输、认证和可观测性"。

这也是ORAG"可组合性"的来源：数据源只接一次，需要它的代理直接指向MCP服务器即可。

不过Sharma坦承，真正耗时的不是搭架子，而是生产环境的细节。笔记本里能跑的RAG很简单，生产环境能用的RAG很难。分块策略比多数人想象的更重要，检索评分需要可观测，延迟必须在负载下可预测。

他在可观测层投入的时间最多：完整的请求追踪，覆盖检索、工具调用和补全；延迟分解和检索质量评分，集成在一个视图里。"没有这些，性能下降时你就是在盲飞。"

权限控制是另一个关键战场。Sharma的判断很直接："企业AI真正崩掉的地方，不是模型，不是检索，而是'这个代理能不能看这份数据'。"审计追踪、工作区隔离——这些才是区分演示项目和可信生产系统的分界线。

ORAG目前已上线，GitHub仓库也开放。Sharma的定位很明确：大多数AI工具聚焦模型层，但他想建的是上下文层的基础设施——让模型拿到"可信、受控、相关"的上下文。这是个"更难、更不起眼的问题"。

企业AI的竞争，正在从"谁的模型更强"转向"谁能让模型用对数据"。ORAG的赌注是：后者才是基础设施的缺口。