上下文引擎的定义与价值主张

Unblocked 构建的是一种“上下文引擎”（Context Engine），旨在解决传统 AI Agent 在缺乏组织背景时的低效问题。在过去，新员工需要耗费大量时间查阅代码、文档以及处理历史遗留的“战斗伤痕”（即组织内部积累的事故历史和隐性知识）。上下文引擎的核心作用是将这些分散在代码库、Notion 文档、Pull Requests（PR）、Slack 对话中的碎片化信息整合起来，输出结构化且相互关联的上下文。这种输出的关键特征在于它是意图特定（intent-specific）、个性化以及感知权限（permissions-aware）的。通过这种方式，引擎不再仅仅是检索内容，而是为 AI 提供经过清洗和关联的背景包。

“你得到的上下文是相互关联的，它是特定于意图的、个性化的并且感知权限。”

成本优化与自动化修复案例演示

在对比实验中，Peter 展示了使用 Unblocked 上下文引擎前后的显著差异。当要求 Claude 制定优化“Source Mark”组件的计划时，未连接上下文引擎的 AI 需要像新员工一样盲目探索代码库，耗时约 3分钟，花费高达 $260。而连接 Unblocked 后，AI 直接获取了包含源代码、架构文档及历史 Slack 讨论的任务特定上下文包。这一改进使得生成计划的时间缩短至 1分30秒，成本降至 $29。这实现了惊人的 50% 的成本降低（从 $260 降至 $29），同时大幅提升了响应速度。另一个案例中，同事 Richie 发现代码审查产品的问题检出率下降，Unblocked 迅速定位到原因是模型从 Opus 4.6 切换到 Opus 4.8，并自动创建了修复 PR。该引擎甚至能理解导致回归的原始 PR 和相关的 Slack 讨论，展现了极强的自动化修复能力。## RAG 的局限性与结构化查询的挑战 尽管 Retrieval-Augmented Generation (RAG) 擅长处理基于语义的内容检索，例如“找到修改了某段代码的 PR”或“查找讨论该问题的 Slack 线程”，但它无法有效处理结构化查询（Structured Queries）。例如，当用户询问“上周合并了哪些 PR？”或“谁审查的支付系统 PR 最多”时，这类问题包含时间维度和聚合统计需求，无法仅通过向量存储中的语义相似度来解决。Richie 曾要求生成自1月1日以来的每周比率图表，这必须通过查询引擎而非语义检索来完成。因此，完整的上下文引擎需要兼顾语义检索和结构化查询转换。生成 SQL 或 GraphQL 等查询语句本身相对容易，真正的难点在于构建围绕它的脚手架（Scaffolding）。这包括让 LLM 理解数据库 Schema，以便生成紧密绑定的查询语句，从而处理那些 RAG 无法覆盖的结构化数据需求。

动态模式发现与身份映射机制

在构建基于大语言模型（LLM）的数据库查询引擎时，首要挑战在于处理非标准化的输入数据。例如，当用户询问“Rashene 提交的 PR”时，系统无法直接识别该身份，因为 GitHub 上的用户名可能与数据库中的真实身份信息不一致。因此，系统必须具备自动模式发现（Automatic Schema Discovery）能力以动态解析数据结构。身份映射（Identity Resolution）则是另一关键环节，用于将不同系统中的用户名或标识符进行关联。虽然 LLM 常被用作通用工具，但在模式推断等看似非确定性的任务中，传统的过程化方法往往比 LLM 更有效且更具确定性。对于身份映射，系统采用模糊匹配技术将不同来源的用户名进行关联；若仍无法确定最终身份，再调用 LLM 作为“决胜局”裁决者。这种分层策略既保证了效率，又确保了准确性。

查询合成与安全验证体系

在获取动态模式后，系统进入查询合成（Synthesis）阶段。这一过程相对简单：系统将动态解析的模式、当前时间戳以及用户上下文信息（如区分“我的 PR”与特定用户的 PR）传递给 LLM，由其生成具体的数据库查询语句。然而，生成的查询是“不可信”的，必须经过严格的验证（Validation）环节。LLM 生成的查询可能包含危险操作，例如在数据库服务器上执行原始 JavaScript 的函数运算符。此外，系统还需防止 LLM 访问或推导隐藏的元数据字段（如租户 ID），以确保多租户隔离性。系统通过在后台注入约束条件，限制 LLM 直接交互敏感字段。如果验证引擎检测到违规操作（如尝试使用正则表达式），它会拒绝执行并返回错误，从而防止潜在的安全风险或数据泄露。

自我纠错与全文搜索集成

当查询验证失败时，系统并非直接报错终止，而是利用自我纠错（Self-Correction）机制。系统将验证错误反馈给 LLM，形成一个带有最大重试次数的循环，让模型根据错误信息调整查询逻辑。例如，当用户询问“标题包含认证的 PR”时，初始生成的精确匹配查询可能因无完全匹配的文档而失败。此时，系统引入全文搜索（Full Text Search）功能以增强匹配能力。

“Validation is cool. But what do we do with that? you know, we got an error... take that error and just loop it back in to the LLM and have the LLM kind of self-correct.”

通过多次迭代，系统最终能够生成包含全文搜索逻辑的正确查询。这种架构不仅处理了结构化数据的过滤和聚合，还实现了时间范围限定和自我修正能力。该开源项目（Document Query Engine）展示了如何构建一个能够处理 RAG 中“另一半”任务的引擎，即针对结构化数据的复杂查询。它不仅能生成精确的 SQL 或 NoSQL 查询语句，还能作为聊天代理的后端引擎，支持如“上周我们在认证方面做了哪些工作”等自然语言交互。

“This is all open source. So you can take a look at how it's implemented and play around with it yourself.”

结构化可查询上下文的可视化与推理过程

在演示的最后阶段，系统展示了其内部运作的全貌。用户可以看到所有生成的查询语句以及具体的执行动作，这种透明度让开发者能够清晰地追踪系统行为。当数据加载完毕后，引擎开始在后台进行隐式的逻辑推理。这一过程最终呈现出一种全新的交互形态：为智能体（Agents）和人类用户提供结构化的、可查询的上下文环境。这种设计不仅提升了数据的可用性，还确保了信息传递的精准性。

"Now you get this whole thing that will show you exactly what it's doing, all the queries that it creates."

本地化上下文引擎模拟器与开源方案

针对那些因环境限制而无法立即接入Unblocked平台的用户，团队提供了一个完全本地运行的开源项目。该项目的核心功能是构建一个上下文引擎模拟器（Context Engine Simulator）。它允许开发者在本地环境中独立操作，无需依赖外部服务。通过这一工具，用户可以针对特定任务创建上下文包（Context Bundle），并将其应用于智能体的处理流程中。这种本地化的解决方案降低了技术门槛，使得在没有实时联网或特定约束的环境下也能验证上下文增强的效果。

基于A/B测试的效果验证机制

该模拟器的核心价值在于其内置的对比实验能力。开发者可以将生成的上下文包应用于同一任务，并运行A/B测试（AB Test）。通过对比使用增强上下文前后的结果，用户可以直观地看到拥有全方位上下文支持所带来的具体收益。这种验证方式不仅量化了技术带来的价值，还为优化智能体的表现提供了数据支持。对于希望深入理解上下文增强效果的团队来说，这是一个极具实用价值的工具。

"take that context bundle and run an AB test against the same task and show you the benefits of having all of that context at your fingertips for your agents."

开源代码获取与活动互动

最后，团队提供了相关项目的PR（Pull Request）代码链接，方便感兴趣的技术人员直接获取源码并进行二次开发或研究。此外，在演示的结尾处还穿插了轻松的互动环节，邀请观众前往展台领取椰子（coconuts）作为纪念品。这一部分不仅展示了技术落地的开放性，也体现了团队与社区互动的亲和力。

"And that's the uh PR code for that if you want that."

结论

Unblocked 上下文引擎通过整合语义检索与结构化查询，有效解决了传统 RAG 在处理组织隐性知识和复杂数据聚合时的局限。实证数据显示，该方案能将 AI 任务响应时间缩短一半以上（3分钟至1分30秒），并实现高达89%的成本削减（$260降至$29）。其核心优势在于意图特定的上下文包、自动化的回归修复能力以及基于自我纠错机制的安全验证体系，显著提升了 Agent 的精准度与安全性。

然而，该架构高度依赖对数据库 Schema 的理解及身份映射的准确性。虽然采用分层策略（传统算法优先，LLM兜底）提升了确定性，但在处理非标准化输入时仍面临挑战。此外，该方案目前主要验证了其在优化代码任务中的效能，其泛化能力及大规模多租户环境下的长期稳定性尚需更多数据支撑。