我为什么构建开源的AI上下文层

AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

我最近刚刚将 Holo 开源。它是一个可自托管的共享上下文层，用于 AI 代理，这是那种我希望六个月前就能找到的项目。

这篇文章部分讲述了我为什么构建它，部分讲述了塑造它的工程决策，部分反思了我从将作为内部工具开始的基础设施开源中学到了什么。如果您是现在正在将 AI 代理投入生产的技术创始人，我们遇到的问题可能会听起来很熟悉。

1、我不断看到的模式

在 Kombo（我负责工程团队的 YC 公司），我们内部发布了 AI 代理。其中好几个。一个 Slack 支持机器人、一个面试准备代理、一个起草回复的客户成功助理、一个合规问卷响应器。

每一个都是从小项目开始的。每一个最终都重新实现了同样的事情：一个自定义的连接器堆栈、一个定制的检索器、一堆关于如何处理 Slack vs. GitHub vs. Notion 的提示。三个代理意味着三个 Linear 集成、三个 GitHub 集成、三个不同的 ACL 故事、三个漂移轨迹。

当您开始构建代理时，没有人警告您这部分。困难的部分不是代理循环。困难的部分是每个代理都需要相同的上下文，只是在稍微不同的时间、以稍微不同的形状、以稍微不同的过滤器。

因此我们构建了将成为 Holo 的内部版本。一个镜像公司连接数据的 GitHub 仓库，使用 Cursor 作为驱动循环的代理。销售和客户解决方案团队几个月来每天通过 Slack 使用它。交易准备、支持回复、合规问卷，所有都通过一个拥有上下文的后端路由。

在看到那个东西实际工作了几个月之后，我一直问同样的问题：为什么它不存在作为开放基础设施？每个发布多个代理的团队都会遇到这堵墙。市场有 Onyx 用于企业搜索、Dust 用于聊天助手、半打 RAG-as-a-service 产品。但是位于所有代理之下并代表它们摄取一次的共享上下文层？没有人为空托管者构建那个。

因此我们开始公开重建它。从头开始。泛化。

2、Holo 实际上是什么

Holo 是一个 MCP 服务器（带有并行的 REST 接口），它：

• 今天从 20 个连接器 摄取数据，包括 GitHub、GitLab、Slack、Notion、Linear、Jira、Confluence、Google Drive、HubSpot、Salesforce、Pylon、Zendesk、Grain 等常见来源。
• 将所有内容索引到具有 ACL 感知的单一 Postgres 存储（带 pgvector） 中。无需操作单独的向量数据库。
• 向任何兼容 MCP 的代理暴露两个原语：用于混合检索的 search，以及用于每个同步工件的只读虚拟文件系统的 bash。
• 记录每次调用。谁请求了、哪些工具触发了、哪些上下文支持了答案。
• 在 docker compose up -d 上运行。第一天就支持多租户组织。

宣传很简单：连接一次，为每个代理服务。相同的块、相同的 ACL、相同的审计跟踪，为 Claude、Cursor、您的内部代理提供支持，所有都通过一个后端。

但我想谈论的不是功能列表。它是我们沿途做出的设计赌注，因为我认为这些部分可以泛化到现在正在构建代理基础设施的任何人。

3、赌注 #1：Bash 和虚拟文件系统

而不是 20 个类型化的 MCP 工具。

当我们开始时，显而易见的事情是给每个连接器自己的类型化 MCP 工具。get_pr、get_thread、get_doc、get_call、get_ticket。每个来源都有一个带有定制参数（GitHub 为 owner+repo+number，Slack 为 channel+timestamp，Grain 为 recording_id）和定制返回形状的获取器。

我发布了那个。它有效。然后它就无效了。

每个新连接器意味着添加一个工具，这意味着向每个代理提示添加关于它的内容。二十个连接器很快变成了模型必须记住的二十个工具，每个都有自己的参数形状，每个都有自己的怪癖。提示变得更长。代理变得更慢。维护负担成倍增加。

我们用一个在确定性虚拟文件系统上的 bash 沙箱替换了整个工具动物园。每个同步工件都位于您可以猜到的路径：

• Slack 线程位于 /slack/#<channel>/<date>/thread-<ts>.md
• GitHub PR 位于 /github/<owner>/<repo>/pulls/<n>.md
• Pylon 票证位于 /pylon/tickets/<id>.md
• Notion 页面位于 /notion/<workspace>/<page>.md

代理获得 ls、cat、grep、find、head、tail、wc、sort、uniq、tree 和 echo。仅此而已。没有 eval、没有网络、没有 shell 逃逸。

我们的赌注是前沿模型已经知道如何驱动文件系统。它们已经在数百万行 shell 脚本上进行了训练。它们不需要提示工程来弄清楚 grep -r "stripe" /github/kombo/api/pulls/ | head 是一个合理的尝试。它们只是这样做。

我们在内部 Slack 机器人上测量了这一点。旧路径（搜索，然后读取 N 个块，然后调用 LLM 总结）端到端花费了 38.6 秒。新路径（代理直接导航文件系统）花费了 9.7 秒。大约快 4 倍，并且答案更有根据，因为模型可以提取它想要的确切字节，而不是得到一堆混乱的块。

这里更深层次的教训：当您为 LLM 设计工具时，优先考虑模型已经理解的界面。不要发明新的词汇表。使用它成长起来的那个。

4、赌注 #2：仅限 Postgres

没有单独的向量数据库。

现在每个 AI 基础设施架构指南都会告诉您运行专用的向量数据库。Pinecone、Weaviate、Qdrant、Chroma。选择一个。

我们走了另一条路。Holo 在具有 pgvector 用于嵌入和 pg_trgm + tsvector 用于关键词搜索的单一 Postgres 实例内运行混合搜索。两者在一个具有倒数排名融合的 SQL CTE 中融合。

操作简单性是原因。我知道的大多数自托管团队无论如何都在运行一个 Postgres。添加第二个专用数据库意味着第二个备份策略、第二个认证边界、第二个监控故事，以及第二个可能以您不知道如何在凌晨 2 点调试的方式失败的东西。对于大多数团队所处的规模，pgvector 足够快，并且在 SQL 中与您的 ACL 连接一起进行检索的人体工程学是巨大的。

如果我们以后遇到障碍，我们可以交换向量层。但当一个数据库就可以时从两个数据库开始是那种过早的复杂性，会花费您六个月的您没有的时间。

5、赌注 #3：审计一切

不重放任何神奇的东西。

每次 Holo 调用都会被记录。谁请求了、哪些工具触发了、代理读取了哪些文件、哪些上下文支持了最终答案。仪表板有一个重放视图，显示记录的查询和结果差异。

这不在原始路线图上。它是在客户成功部门有人问我"代理为什么这么说？"而我没有干净答案时添加的。代理拉取了正确的文档，但提示路径是不透明的，从三个系统的日志中重建它花费的时间比手动重写响应更长。

如果您正在构建生产代理，您需要与您的 Web 应用程序结构不同的可观察性。堆栈跟踪没有帮助。延迟图没有帮助。您需要记录哪些上下文片段流入了哪些决策。在第一天就构建它，否则您会希望您已经构建了。

一个诚实的警告：重放显示记录的查询和记录的结果。它不是针对当前状态的实时重新执行。这是一个有意的权衡，而不是疏忽。实时重放听起来在演示中很干净，但在实践中一旦您的底层数据发生转变就是一场噩梦。

6、为什么开源，为什么 AGPL

许可问题得到的关注超出了我的预期。我桌上有三个选项：MIT、AGPL 和像 BSL 这样的公平源代码许可证。

我为社区版选择了 AGPL-3.0，为企业版选择了单独的商业许可证。与 Cal.com、Plausible 和 Mattermost 使用的模型相同。在公司内部自由自托管。如果您想将 Holo 包装成托管商业产品，请与我联系。

推理很简单。Holo 是基础设施。当团队可以阅读源代码、分叉它并在自己的环境中运行它而无需请求许可时，基础设施就会被采用。MIT 在理论上会使这变得更容易，但它也会让任何资金充足的公司转售 Holo 作为托管产品而不回馈。AGPL 不会阻止这一点，但它使义务变得明确：如果您向第三方提供 Holo 作为网络服务，您必须发布您的修改。

这就是保持社区资助基础设施项目活力的交易。

7、我从发布这个中学到了什么

过去几周有几件事脱颖而出。

将内部工具泛化是其自己的项目。 我们在 Kombo 运行的版本有一千个假设。频道命名约定、ACL 快捷方式、只对我们的团队有意义的提示调整。将这些拿出来并以适用于任何团队的方式重建相同的原语花费的时间比我预期的更长。如果您正在考虑将某些内部的东西开源，请预算两倍于您认为需要的时间。

MCP 生态系统正在快速发展。 当我们开始时，MCP 中 OAuth 2.1 的动态客户端注册 (RFC 7591) 几乎不是人们正在实现的规范。到我们发布它时，它已经是与最新客户端互操作的必要条件。如果您正在构建此领域的任何东西，请假设您下面的协议在您启动之前会改变两次。

不要预建市场。 我们原始设计有一个完整的技能/市场 UI，用于在团队之间共享过程。我们发布了 v0.1，该界面返回 501 Not Implemented。管道在仓库中，但路由已关闭。过程合成只有在有足够来自实际使用的跨连接器信号来引导它时才有意义。在网络效应存在之前构建市场是 2021 年每个 Web3 项目的 dotcom 时代错误。

小团队发布速度比您预期的快，但仅限于您确定的赌注。 我在几周内重建了 Kombo 团队在内部构建的核心。这只有在我们已经在实际生产流量上验证了设计选择的情况下才可能。我们不是在探索。我们是在泛化。

8、接下来是什么

Holo 是预 alpha 版本。仓库是公开的。Slack 机器人路径有效。bash 沙箱有效。二十个连接器已上线。仪表板功能正常。有粗糙的边缘，我明天不会将其放在客户面前。

现在发布关于这个的诚实原因不是它已经完成。而是设计假设已经深深地融入其中，以至于以后打破它们将花费昂贵，我想在发生这种情况之前找出它们错误的地方。如果您是正在生产中运行多个 AI 代理的技术创始人，重复痛苦对您来说可能也是真实的。我很想知道它最痛的地方以及我们选择的界面是否感觉正确。

原文链接: Why I Built Holo (AI Context Layer) and Open-Sourced It

汇智网翻译整理，转载请标明出处