生产 Agent 接私有数据前，先补 6 个数据接入边界
生产 Agent 接私有数据前，先补 6 个数据接入边界
这两周国内关于 Agent、MCP、Codex、Claude Code 的讨论还在升温，但一旦系统准备接入企业内部知识库、CRM、工单、支付、设备台账或运行日志，问题就不再只是“检索效果够不够好”。
真正决定这类 Agent 能不能进生产的，往往是：
它拿到私有数据之后，边界是不是先立住了。
很多团队的第一版方案都会这样起步：
- 把文档接进向量库；
- 把业务表接成查询工具；
- 让模型根据检索结果给建议或直接触发下一步动作。
demo 很容易跑起来，但一旦进入真实业务，风险会很快暴露：
- 检索到的内容不是当前版本；
- 不同角色看到了不该看的字段；
- 模型给出结论，却说不清依据来自哪一段证据；
- 脱敏没做好，输出把敏感字段带了出去；
- 缓存或 fallback 逻辑把旧数据当成新数据继续用了。
所以我更建议把“接私有数据”当成一条受控数据链路来设计，而不是一个简单的 RAG 接口集成。
下面这 6 个边界，是我认为 production AI agent systems 在接真实私有数据前至少该补齐的。
1. 先把数据源分级，不要默认都能接
很多系统一开始把“企业内部数据”当成一个统一概念处理，这是最容易出问题的地方。
真实环境里至少应该先分清：
- 公共知识和低敏文档；
- 内部运营文档和项目资料；
- 客户数据、交易数据、设备控制数据；
- 合规、财务、权限、审计这类高敏数据。
这几类数据不该走同一套默认检索和暴露规则。
如果连分级都没做，后面所谓权限控制、脱敏、日志留痕，基本都只能停留在口头上。
2. 没有版本和时效标记的数据，不要直接给模型用
很多 Agent 的问题，不是“查不到”，而是“查到了旧数据还继续用”。
生产里至少要让每条关键证据带上：
- 数据源名称；
- 更新时间；
- 版本号或快照标记；
- 是否来自缓存；
- 是否已过可用窗口。
例如：
- 工单状态是 5 分钟前还是 2 小时前同步的；
- 设备配置是当前版本还是上一次发布版本；
- 制度文档是正式生效版，还是历史草稿。
如果这些字段没有结构化暴露给系统，模型即使回答得像对，也只是把过期信息包装得更像正确答案。
3. 检索权限要按角色、对象和字段收紧
“能查到内部数据”不代表“所有内部数据都能给当前任务看”。
更稳妥的默认设计通常要同时限制三层：
- 角色能看什么；
- 当前任务能查哪个对象范围；
- 返回结果里哪些字段可以被模型消费或输出。
例如售后 Agent 可以查工单进度，但不一定能看合同折扣；设备运维 Agent 可以看运行状态，但不一定能读取全部客户标识字段。
如果权限只做到“工具能不能调”，没有细到对象和字段，越权通常只是时间问题。
4. 结论必须能回指到具体证据片段
很多团队做了 citations，但只是把“来源列表”挂在答案后面，这还不够。
真正可审查的证据链，至少应该回答：
- 这次结论引用了哪几个数据源；
- 关键判断对应哪一段文本、哪条记录、哪个字段；
- 如果有多条候选证据，为什么选了这一条；
- 证据之间有没有冲突。
也就是说，系统不仅要有 citations，还要有可复盘的证据选择过程。
否则排障时看到的只是“答案像是有依据”，但没人能判断依据到底够不够支撑这次动作。
5. 敏感字段要在检索层和输出层双重收口
很多泄露问题不是模型主动“越狱”，而是数据管道默认把不该暴露的字段一起送进来了。
比较常见的风险字段包括：
- 身份证号、手机号、邮箱、住址；
- 交易金额、账户标识、风险标签；
- API key、设备密钥、内网地址、凭证片段；
- 合同价格、内部审批意见、审计备注。
比较稳妥的做法通常不是只在最后一步做字符串替换，而是：
- 检索前先按字段级策略裁剪；
- 检索后再做输出策略检查；
- 命中高敏字段时直接转人工或改成摘要模式。
这样系统即使检索到了相关记录，也不会默认把整段敏感上下文直接暴露给模型和最终用户。
6. 没有证据或证据冲突时，默认停住，不要让 fallback 硬补
很多 demo 为了“看起来总能回答”，会在检索失败时自动走：
- 更宽松的检索；
- 更旧的缓存；
- 泛化知识回答；
- 另一套低质量备用数据源。
这在生产里往往很危险。
因为当系统已经在用私有数据回答时，用户默认会把它当成“企业真实信息”，而不是“模型的合理猜测”。
所以更稳妥的默认规则通常是：
- 没命中足够证据就明确说查不到；
- 证据冲突就提示需要人工确认；
- 高风险流程里禁止用通用知识补真实业务结论；
- fallback 命中后不允许直接触发写操作。
这不是降低可用性，而是承认“无证据时停住”比“猜一个继续跑”更像生产系统。
为什么数据接入边界比“再堆一个更强模型”更优先
因为只要开始接私有数据，最贵的问题通常不是回答普通了一点，而是：
- 旧数据被当成新依据；
- 不该看的字段被看到了；
- 不够硬的证据支撑了真实动作；
- 敏感数据通过答案或日志泄露出去；
- 事后无法判断这次结论到底是基于哪条记录做出的。
这些都属于数据接入控制面，不属于单纯的模型效果问题。
一个够用的落地顺序
如果团队最近准备把 Agent 接进真实私有数据，我更建议按这个顺序补：
- 先做数据源分级和敏感度标记；
- 再补版本、时效和快照字段；
- 再把角色、对象、字段三级权限收紧；
- 再把 citations 做到字段或片段可回指；
- 再把脱敏和输出策略做成默认规则；
- 最后才优化召回率、模型成本和回答流畅度。
这样做的好处是，团队讨论的不再只是“Agent 能不能查到更多东西”，而是“它在什么条件下，才有资格使用这些私有数据给出结论甚至推进动作”。
如果最近在做 AI Agent Production-Readiness Review，这类项通常也会被优先检查：私有数据接入有没有分级、citations 和 audit logs 能不能落到具体证据、tool-calling 和输出策略有没有把越权与泄露风险真正拦下来。重点不是把能力讲得更大，而是让系统在真实客户和业务数据面前更可控、更可追溯。
