Agent 按需加载工具说明、规则和上下文的渐进式披露架构下，是否还需要 RAG？二者如何分工与协同？

60 秒回答模板

渐进式披露不会替代 RAG。它解决的是 Agent 在每一步该展开哪些能力、工具 schema、规则和上下文，避免一次性塞满 Prompt；RAG 解决的是当前任务需要外部事实时如何检索、过滤和引用证据。工程上通常是先披露能力，再判断是否检索知识。 渐进式披露管能力上下文：Agent 不应一开始加载所有工具文档、规则、技能和记忆。它先根据意图加载高层能力目录，再按当前步骤展开具体工具 schema、调用规则、少量示例和必要短期状态，减少 token 浪费和上下文污染。 RAG 管外部事实证据：当问题依赖产品文档、代码库、业务知识、用户历史或实时资料时，需要 RAG 检索证据。没有 RAG，Agent 只能依赖模型先验和已披露规则，容易在事实更新、长尾文档和私有知识上编造。 协同链路要可执行：典型链路是 intent routing -> 加载相关工具 schema 和规则 -> 判断是否需要外部知识 -> 做权限过滤的 RAG 检索 -> 把证据摘要注入当前步骤 -> 输出答案、引用和知识版本。这样既不把全量知识常驻上下文，也能在需要时拿到证据。 按任务决定边界：只依赖固定流程、用户当前输入和已知工具返回的任务，可以只用渐进式披露；涉及政策、文档、代码、历史记录或时效事实的任务必须接 RAG。边界应由评测集按任务类型验证，而不是靠架构口号决定。 权限时效和失败策略：渐进式披露加载能力时要遵守用户角色和租户边界，RAG 检索也要做 ACL 过滤、版本标注和更新时间检查。检索低置信、证据冲突或权限不足时，应追问、降级、拒答或转人工，而不是继续生成确定结论。 最后要把方案落到可验证的指标、失败兜底和迭代闭环上。面试里不要只讲概念名词，要说明边界、取舍、数据来源、线上观测和出问题后的回滚或人工介入。