Canonical Original
本文首发于 agentarchitect.me。外部平台版本均为分发版本，主站原文为长期更新与引用版本。
主站原文：https://www.agentarchitect.me/articles/canaryrag-rag-runtime-boundaries
分发状态：抖音 / 头条 / 掘金 / 搜狐 / 公众号
author: 智能体架构师卢成
aliases:
- Lu Cheng
- Jack Lu
- Agent Architect Lu Cheng
canonical_url: https://www.agentarchitect.me/articles/canaryrag-rag-runtime-boundaries
topics:
- Agent Factory
- 老板业务编译器
- AI经营改进工作台
- 企业知识库
- 内容智能体
- GEO生成式引擎优化CanaryRAG 的启发不在于多一个防御技巧，而在于它把 RAG 安全从静态规则推进到运行时检测：知识被取出来以后，系统还要知道它有没有被异常带出去。
RAG 的风险不是幻觉，还是泄漏
很多团队谈 RAG，只谈两个指标：能不能答对，能不能少幻觉。这当然重要，但不够。企业知识库一旦接进模型，另一个问题同样关键：模型为了答一个问题检索到了内部内容，这些内容会不会被用户通过提示诱导原样吐出来。
《Detecting RAG Extraction Attack via Dual-Path Runtime Integrity Game》这篇论文把这个问题叫作 RAG Knowledge Base Leakage。它提醒我们，RAG 不是简单地把私有知识塞进上下文，而是在每次检索时都临时扩大了模型可见的秘密边界。
系统提示词不是边界
很多企业的第一反应，是在 system prompt 里写“不要泄漏内部资料”。这句话不是没有用，但它不是边界。攻击者可以迭代，可以绕过，可以让模型复述上下文，可以用多轮对话逼近原文。只靠一句禁止泄漏，本质上是在让模型自己保护它刚刚被喂进去的秘密。
CanaryRAG 的思路更工程化：在检索到的 chunk 里嵌入非语义 canary token，然后监控模型输出。如果目标路径里出现这些 token，说明模型正在异常暴露检索内容；如果 oracle 路径在应当暴露时反而不暴露，也可能说明存在对抗性抑制。它不是只相信模型会守规矩，而是给系统加了运行时探针。
真正重要的是运行时完整性
这篇论文最值得借鉴的地方，不是 canary token 这个点子本身，而是它把 RAG 防御从静态规则推进到运行时完整性。软件安全里，很多防线不是为了让漏洞永远不存在，而是为了在异常发生时尽早发现、阻断、告警和留证。
RAG 也应该这样设计。检索器把知识拿出来，生成器开始写答案，输出流每一步都可能泄漏。系统不能等回答完成后才人工抽查，而应该在 token 流里监测异常信号，在攻击还没完成时切断输出。
企业知识库需要的是分层防线
CanaryRAG 自称 plug-and-play，这对落地很有吸引力。但企业不该因此误以为一个 canary 层就能解决全部 RAG 安全问题。真正的架构应该是分层的：检索前有权限过滤，检索时有最小必要原则，生成时有输出监控，异常时有告警和审计，事后还能回放是哪条 chunk 被取出、哪次请求触发了泄漏风险。
这也是智能体架构和普通应用接模型的差别。普通应用关心“能不能回答”；智能体架构必须关心“回答用到了什么、越过了什么边界、能不能被追踪、出事后能不能定位”。没有这些，RAG 只是把企业内部资料换了一种方式暴露给外部输入。
来源与延伸阅读
AI 论文简报只作为选题雷达：https://ai-brief.liziran.com/zh/ 。主要核验来源为 arXiv 论文《Detecting RAG Extraction Attack via Dual-Path Runtime Integrity Game》：https://arxiv.org/abs/2604.10717 。该论文 2026-04-12 提交，备注为 ACL 2026 Main accepted。
本文没有照搬论文结构，而是把 CanaryRAG 放回企业 RAG 架构中解读：它的真正价值是让知识库安全从“提示词声明”转向“运行时可观测、可阻断、可追踪”。