AI Applications

Evidence Packet: Agentic RAG 的上下文编译接口

Misaya Yang 2026-05-31T00:20:00.000Z

RAG 的难点不止是找几个 chunk，而是让检索结果在进入 Agent 前变成可引用、可裁剪、可复盘的证据包。

Agentic RAG, RAG, Knowledge Base, Context Compiler, Hybrid Search, Agent Systems, Context Engineering, Evaluation, Observability

Evidence Packet: Agentic RAG 的上下文编译接口 RAG 很容易被理解成一条直线：用户问一句话，系统把相似 chunk 找出来，塞进 prompt，模型回答。这个版本能跑 demo，但接到真实 Assistant 流程后，问题会立刻暴露。模型会问：这些 chunk 为什么进来了？前端会问：来源卡片应该指向哪篇文章、哪个小节？调试时会问：这是 query rewrite 错了，BM25 错了，rerank 错了，还是上下文裁剪把关键句删了？这些问题都不是“再换一个向量库”能解决的。Agentic RAG 的关键不只是“如何检索到相关 chunk”，而是“如何把知识库结果变成 Agent 可以稳定消费、可以引用、可以复盘的上下文对象”。一个更可落地的切口是 Evidence Packet 。它是 Assistant 与 KB 之间的结构化中间表示。KB 不再只是向量搜索服务，而是一个面向 Agent 的 Context Compiler ：把原始文档、召回信号、来源元数据、token 预算和引用约束编译成可执行上下文。这条链路可以压成：重点不是发明新的检索算法，而是把 RAG 从“搜索结果列表”提升为“Agent runtime 的上下文接口”。先限定边界 Evidence Packet 不是“已经做完一套企业级 RAG 平台”的包装词。它更像一个工程接口：当博客 Agent、文档助手或通用 Assistant 从原型走向产品时，知识如何被检索、裁剪、授权、引用和评测。下面提到 Qdrant、BM25、rerank、MMR、GraphRAG 等组件时，它们都只是可替换路线。真正重要的不是选哪一个库，而是检索结果在进入模型前，有没有变成一个可观察、可治理的对象。 1. Problem Boundary 传统 RAG 接口通常接近：这个接口适合原型，但对 Agent 不够。Agent 需要的不只是文本，还需要围绕文本的证据结构：候选是 dense 召回、BM25 召回，还是二者融合得到的。结果是否经过 rerank，是否为了多...