Appearance
Agent 什么时候该检索：Pre-Retrieval、Retrieval Tool 与 Failure Modes
多个 chunk 来自同一段文档时可去重；高相关短证据优先，完整文档保留引用供后续 tool 读取。客服 FAQ 每次先检索适合 pre-retrieval；研究 Agent 可以在发现信息缺口后调用 search tool。
Retrieval in Agent Context
Retriever 返回的是候选 evidence，不是最终 Context。ContextManager 还要根据 token budget、重复度、来源、任务阶段和 result policy 做选择；top-K 只说明 Retriever 排名靠前，不代表 K 条都应该无条件注入模型。
Retrieval as Tool vs Pre-Retrieval
区别在于：检索是程序固定发生，还是由 Agent 根据当前证据决定是否发生。
text
Pre-Retrieval:
request → retrieve once → build context → model
Retrieval as Tool:
model → search → observation → decide whether to search again如果几乎每个请求都必须查同一类知识库，Pre-Retrieval 更稳定、容易测，也更容易控制 latency。只有当“是否需要查、查什么、要不要改 query”本身依赖中间结果时，才值得把 Retrieval 暴露成 Tool。
Agentic Retrieval 的代价是多一层 loop：可能重复搜索、查询漂移、成本增加，因此要有 search budget 和停止条件。
Retrieval Failure Modes
Retrieval failure 必须按 pipeline 定位：source/ingestion 缺失、chunk 破坏语义、query mismatch、ACL/filter 错误、embedding domain mismatch、rerank 误排、stale index，或 evidence 虽相关却不支持结论。定位这些故障需要保留检索轨迹，具体应记录哪些字段在后文展开。
选择 Pre-Retrieval 还是 Retrieval Tool，看“检索是否是任务不变量”
如果每个请求都必须基于企业知识库回答，检索是稳定前置条件，可以由 Workflow 在模型前执行；这样路径可预测，也容易保证 grounding。若只有部分步骤需要查资料、query 取决于中间 Observation，则把 Retrieval 暴露为 Tool 更自然。
可以用这组问题判断：
text
每次都必须检索吗？ → 倾向 pre-retrieval
query 能在模型前确定吗？ → 倾向 pre-retrieval
是否需要多轮改写 query？ → 倾向 retrieval tool
检索成本/权限很高吗？ → 需要显式 policy/admission
结果会改变下一步计划吗？ → retrieval tool 更有价值真实系统也可以 Hybrid：先做一个低成本 pre-retrieval 建立基础证据，Agent 发现缺口后再调用更昂贵的专项 Retriever。
Agentic Retrieval 必须留下“为什么搜、搜了什么、用了什么”的轨迹
只保存最终回答无法区分“Retriever 没召回”和“模型拿到证据却没使用”。Trace 至少记录 query/rewrite、filter、候选文档 identity/score、rerank 后选择、最终注入 Context 的 evidence IDs。
故障定位于是可以分层：
text
no candidate → ingestion/index/query 问题
candidate exists but filtered → metadata/permission 问题
candidate ranked low → retrieval/rerank 问题
evidence injected but ignored → model/context 问题这也是为什么 Retrieval Evaluation 和 Agent E2E Evaluation 必须分开。
自测
- 什么任务适合固定 pre-retrieval，什么任务更适合让 Agent 按需调用 retrieval tool？各自的失败成本是什么？
- Agent 连续检索 12 轮仍不结束。除了 token budget，还应该给 agentic retrieval 哪些停止条件或 evidence 约束？