A6 · Agent 如何获取和使用外部知识？ - Knowledge

所属知识库：Agent 全栈技术地图
所属领域：02 · Agent
所属章节：02 · Agent 的能力由哪些部分构成？ - Internal Architecture
文档类型：技术原理与工程实践研究
版本：v1.1
更新日期：2026 年 10 月 28 日
核心问题：Agent 如何识别自身的知识缺口，主动选择知识来源与检索策略，从外部信息中提取、验证和整合证据，并将知识转化为推理、决策和行动能力？这一过程涉及哪些技术原理、架构模式与代表性实现方法，又应如何设计、开发和评估一个可靠的 Agent Knowledge 模块？

专题导读

Knowledge（知识获取与利用）是现代 Agent 内部架构中支持外部信息访问、知识补充、证据整合和事实驱动决策的重要能力。对于以大语言模型为认知核心的 Agent 而言，模型参数中虽然包含大量训练阶段形成的知识，但这些知识受到训练数据、知识时效性、信息完整性和事实可追溯性等因素限制。当 Agent 面对实时信息、专业领域资料、企业内部数据或需要严格证据支持的任务时，仅依赖模型自身的参数知识往往不足以完成工作，因此需要通过外部知识系统主动获取和利用信息。

本篇首先从 Agent 的认知过程出发，研究外部知识为什么是 Agent 的重要能力，以及 Knowledge 与 Model、Context、Memory、Tools 和 Planning 之间的关系。在技术原理层面，重点分析知识需求识别、检索决策、查询生成、知识召回、相关性判断、证据验证、信息整合和反馈驱动检索等机制，解释 Agent 如何从一次性的知识查询发展为能够根据任务进展持续调整检索策略的动态知识获取过程。在技术架构层面，研究知识来源、检索器、文档处理器、证据存储、知识状态管理和模型推理模块之间的协同关系，并进一步比较传统 RAG、Agentic RAG、Self-RAG、Corrective RAG 和 ReAct 等代表性技术路线的设计思想、运行机制及适用场景。

在工程实践部分，本篇以研究助理 Agent 为贯穿案例，设计一套能够执行研究问题拆解、资料发现、原文获取、证据提取、来源核验、跨文档比较和研究报告生成的知识处理架构，说明各模块如何实现、数据如何流动、关键接口如何定义，以及如何处理知识不足、证据冲突和检索失败等问题。最后从检索质量、证据准确性、知识利用效率、任务成功率和系统成本等维度建立评估方法，讨论当前 Agent Knowledge 技术的主要局限与发展方向。

本篇的核心观点是：Agent 的 Knowledge 能力并不等于连接搜索引擎或向量数据库，而是使 Agent 能够围绕任务目标，持续判断自己需要知道什么、如何获得这些信息、哪些信息可以相信，以及如何利用这些知识推进任务。

01 · 研究定位：为什么 Agent 需要独立的 Knowledge 能力？

1.1 模型拥有知识，不意味着 Agent 拥有足够的知识

现代大语言模型在预训练过程中接触了大量文本、代码及其他形式的数据，并通过参数学习形成对语言、事实和概念关系的统计表征。这种能力使模型能够回答常识问题、解释专业概念、推断对象之间的关系，也能够在没有外部工具的情况下完成部分知识性任务。

但是，模型参数中的知识存在几个重要限制。首先是知识时效性：模型训练完成之后，外部世界仍在不断变化，新的政策、产品版本、技术文档、研究成果和市场信息不会自动进入已经部署的模型参数。其次是知识覆盖范围：模型不一定掌握某个组织的内部资料、某个项目的最新文件或某个专业领域的全部细节。第三是知识可追溯性：仅凭模型回答通常无法可靠确定某一事实来自哪份原始资料、对应哪个版本，或者是否仍然适用于当前情境。第四是知识可靠性：模型可能混淆相似概念、错误组合不同来源的信息，或者生成缺乏事实依据的内容。

因此，Agent 需要建立独立于模型参数的知识获取机制，使其能够在任务执行过程中主动访问外部信息。但这不意味着 Agent 必须为每个问题检索。对于无需外部事实的文本改写、确定性格式转换或简单推理，检索可能只会增加延迟和成本。真正重要的是根据任务判断什么时候应该依赖已有信息，什么时候必须获取新知识。

1.2 Knowledge 在 Agent 内部架构中的定位

用户任务
   ↓
Model：理解任务、识别知识需求
   ↓
Planning：决定需要解决哪些问题
   ↓
Knowledge：确定知识来源与检索策略
   ↓
Tools：访问搜索引擎、数据库、文件和 API
   ↓
Knowledge：解析资料、提取证据、验证与整合
   ↓
Context：将相关证据提供给模型
   ↓
Model：基于证据推理、生成结论或提出行动
   ↓
Runtime：记录结果、判断任务进展

这个结构表达逻辑职责，而不是要求系统部署七个独立服务。简单 Agent 的知识需求判断、检索规划和证据分析可能由同一模型完成；复杂系统可能将这些能力拆成不同组件甚至由多个 Agent 协作。

组件	核心职责	与 Knowledge 的关系
Model	理解、推理、生成与提出行动建议	判断知识需求并解释检索结果
Context	管理本次模型调用可见的信息	承载被选中的知识与证据
Memory	保存可供后续复用的历史信息	保存知识获取过程中的项目经验或决策
Knowledge	获取、组织、验证和利用外部知识	本篇研究对象
Tools	执行搜索、读取文件、访问数据库等操作	为 Knowledge 提供实际访问能力
Planning	分解任务并决定执行顺序	决定知识获取活动何时发生
Runtime State	保存任务的权威执行状态	记录哪些问题已解决、哪些证据已核实

例如，研究助理 Agent 可以通过搜索工具获取论文，通过 Knowledge 模块提取技术机制，将关键证据装配进 Context，由 Model 比较分析，再把已核实的技术差异写入项目状态。后续需要复用时，可按用途保存为项目知识资产或相关记忆。这些组件相互配合，但不应混为一谈。

1.3 Knowledge 的能力边界

Agent Knowledge 是 Agent 围绕当前任务，对外部信息进行需求判断、来源选择、获取、解释、验证、整合和使用的一组能力与机制。

Knowledge Capability
  = 知识需求识别
  + 知识来源选择
  + 信息检索与获取
  + 知识表示与证据提取
  + 可信度与适用性判断
  + 知识整合与使用
  + 反馈驱动的知识更新

知识获取是输入环节，知识利用才是最终目的。即使能够搜索数千份文档，如果无法识别哪些内容与任务有关、哪些证据能够支持结论，也不能认为具备可靠的 Knowledge 能力。

02 · 知识需求识别：Agent 如何知道自己缺少什么知识？

知识获取的第一步不是搜索，而是识别知识缺口。普通搜索系统通常接收已经形成的查询，例如“LangGraph checkpoint persistence”；Agent 面对的可能是“比较 LangGraph、AutoGen 和 CrewAI 的状态恢复机制，判断哪种更适合长时间运行的研究系统”。用户给的是任务而不是检索词，Agent 必须先判断完成比较需要哪些信息。

2.1 从用户任务到知识需求

以比较三种框架的状态恢复机制为例，需要分层确定：对象信息，包括框架及版本；概念信息，明确状态恢复究竟指会话历史、工作流检查点、进程异常后的恢复、人工中断后的继续、跨机器恢复，还是外部副作用的恢复；事实信息，需要从官方文档、源代码或可靠资料确认实现；评价信息，判断适用场景、限制与成本；缺口信息，识别哪些结论已有证据、哪些仍待验证。

若不先定义比较维度，Agent 很容易把三个框架中名称相似但能力不同的功能放进同一张表。知识需求应是一组与任务目标对应的可验证问题，而不只是关键词。

2.2 知识缺口的识别机制

工程上可以分为任务分解、已有信息检查和缺口判断三个步骤。

任务：比较三个 Agent 框架的状态恢复能力

Q1：三个框架分别如何定义持久化？
状态：缺少现行官方定义 → 需要检索

Q2：哪个框架支持人工中断后恢复？
状态：已有两个框架的官方证据，第三个缺失 → 定向补检

Q3：哪种方案最适合当前项目？
状态：技术事实基本齐全，但缺少项目运行约束 → 先询问用户

并非所有缺口都通过搜索解决。知识缺口可能需要外部检索、内部数据访问、用户澄清、实验验证，也可能暂时无法可靠解决。把用户意图缺失误判为文档检索任务，只会产生更多无用信息。

2.3 是否需要检索的决策器

Knowledge Need Evaluator 可以接收当前目标、子问题、已有证据、时效性要求、风险、可用来源和剩余预算，并输出：

ANSWER_WITH_EXISTING_EVIDENCE
RETRIEVE_EXTERNAL_KNOWLEDGE
QUERY_INTERNAL_DATA
ASK_USER
RUN_VERIFICATION
REPORT_UNRESOLVED

这能避免两种极端：对每个问题都检索的过度检索，以及缺乏可靠信息时直接凭参数知识作答的检索不足。模型可以提出检索需求，但重要任务的证据充分性不应仅依据模型自报信心。

03 · 知识来源与访问：Agent 应该去哪里寻找信息？

Agent 面对的是异构信息环境。不同来源具有不同数据结构、更新频率、访问方式和可信边界。

3.1 知识来源的主要类型

知识来源	典型内容	访问方式	主要特点
公开互联网	网页、新闻、公开报告、技术博客	搜索 API、浏览器、网页抓取	覆盖广、变化快、质量不一致
专业文献库	论文、标准、专利、学术资料	专业检索 API、文献数据库	结构较规范，但需理解研究条件
组织内部知识库	项目文档、制度、会议记录	企业搜索、文件系统、知识库 API	与业务高度相关，访问受权限限制
结构化业务系统	CRM、ERP、订单、项目状态	SQL、REST API、GraphQL	适合精确查询，依赖业务数据模型
实时信息服务	天气、市场数据、系统监控	实时 API、事件流	时效性强，通常有明确接口

研究算法理论优先寻找原始论文；查询订单状态应调用业务 API；确认框架当前参数应查看对应版本官方文档；分析复杂 PDF 表格需要具备结构恢复能力的解析器。同一种检索策略无法适用于所有来源。

3.2 Source Router：知识来源路由

Knowledge Need
      ↓
Source Router
      ├── 公开事实 → Web Search
      ├── 学术问题 → Academic Search
      ├── 项目内部问题 → Internal Knowledge Base
      ├── 结构化业务问题 → Database / API
      └── 实时状态问题 → Live Data API

规则路由按任务类型、数据类型和关键词选择来源，简单、可解释且成本低；模型路由通过语义理解选择来源，适合开放任务，但可能误判；混合路由先由确定性规则限制允许访问的来源，再由模型选择策略。对于长期运行的研究 Agent，混合路由值得优先评估，因为它同时提供灵活性和明确的访问边界。

3.3 来源选择不等于来源可信

来源评价至少涉及权威性、直接性、适用性、可验证性。框架官方文档可能是 API 行为的重要来源，但旧版本文档可能不适用；学术论文可能设计严谨，却只覆盖特定实验条件。判断框架是否支持断点恢复，不能仅凭博客声称“支持持久化”，还应检查官方接口、存储机制和恢复前提。知识系统需要判断来源对当前问题的适用范围，而非只给来源一个固定可信分数。

04 · 信息检索的技术原理：Agent 如何找到相关知识？

4.1 关键词检索：基于词项匹配

BM25 是经典词法检索方法之一，综合查询词在文档中的出现频率、语料库中的稀有程度及文档长度等因素。在 checkpoint_id、thread_id、interrupt_before、HTTP 429 等精确术语、参数或错误码检索中，词法匹配具有明显优势。但用户可能用“程序退出后继续之前的工作”描述文档中的 durable execution、checkpoint recovery 或 resume execution；措辞差异可能导致漏召回。

4.2 向量检索：基于语义相似性

向量检索利用 Embedding 模型将查询和文档映射到向量空间，并根据相似度检索候选：

用户问题 → Embedding Model → Query Vector → Vector Index → 相似文档候选

它擅长处理不同措辞之间的语义关联，例如“任务中断后恢复”和“工作流持久化与执行恢复”。但向量相似度不等于事实相关性。两段文本可能概念相似，却对应不同框架、版本或技术机制；数字、函数名和否定条件尤其需要精确检查。向量检索适合作为候选召回，而不是最终证据判定。

4.3 混合检索：结合词法与语义

                  Query
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
     BM25 Search         Vector Search
          │                   │
          └─────────┬─────────┘
                    ▼
             Result Fusion
                    ▼
                Reranking
                    ▼
              Final Evidence

混合检索将词法和语义候选融合。常见方法 Reciprocal Rank Fusion（RRF）根据文档在不同检索列表中的名次融合，而非直接比较不可比的原始评分：

$$RRF(d)=\sum _{r\in R}\frac{1}{k+{\mathrm{rank}}_r(d)}$$

其中 $d$ 是候选文档，$R$ 是检索结果列表集合，${\mathrm{rank}}_r(d)$ 是文档在某列表中的名次，$k$ 是平滑参数。BM25 可捕获 API 参数，向量检索可找到语义解释；融合可以互补。但如果任务完全是精确字段查询，混合检索也可能引入噪声，应通过领域数据评测。

4.4 Reranking：为什么召回之后还需要重排？

第一阶段检索侧重不漏掉重要资料，但候选可能只是“看起来相关”。重排器可以通过交叉编码器或模型判断，对问题—文档对做更细致的相关性评价。例如，询问“checkpoint 能否在进程重启后恢复”时，checkpoint 数据结构、内存型示例、数据库持久化配置和对话历史管理可能都被召回；重排器应优先选择能直接回答“进程重启后恢复”的资料。重排只能重新排序已有候选，无法恢复第一阶段完全漏掉的文档。 因而召回率与重排质量必须分开测量。

05 · 从 RAG 到 Agentic Retrieval：知识获取为什么需要动态决策？

5.1 传统 RAG 的基本工作机制

Retrieval-Augmented Generation（检索增强生成，RAG）将外部检索结果提供给生成模型。典型流程为：

用户问题 → 生成查询 → 检索文档 → 选择片段 → 构建 Context → 生成回答

对于“根据员工手册，年假如何计算”一类边界明确、少量文档足以回答的问题，单次检索可能已经足够。但复杂研究任务往往需要在阅读第一批材料后发现新的问题。

5.2 为什么复杂任务需要多轮知识获取？

例如研究三个 Agent 框架的长期任务恢复能力。第一轮检索找到概览；阅读后发现“长期恢复”涉及状态持久化、中断恢复、外部副作用、失败重试、幂等执行和版本兼容。第二轮定向查找持久化后端与恢复接口；第三轮进一步检查恢复时的工具重复执行风险。这不是预先固定的流水线，而是新证据持续改变后续知识需求。

5.3 Agentic Retrieval 的基本控制循环

当前任务与知识状态
         ↓
判断知识缺口
         ↓
选择检索策略与来源
         ↓
执行检索、读取资料
         ↓
提取证据并更新状态
         ↓
评估知识是否充分
    ┌────┴────┐
  不充分      充分
    │          │
调整查询     进入推理
    │
  再检索

关键不是“能够重复搜索”，而是每次搜索之后都更新知识状态。如果连续搜索十次却不记录哪些问题已解决，Agent 只是在堆积结果。

5.4 Knowledge State：动态检索的数据基础

{
  "task_id": "research_001",
  "questions": [
    {
      "question_id": "Q1",
      "question": "框架 A 如何持久化任务状态？",
      "status": "verified",
      "evidence_ids": ["E1", "E2"]
    },
    {
      "question_id": "Q2",
      "question": "框架 A 是否支持异常重启恢复？",
      "status": "partially_supported",
      "evidence_ids": ["E3"],
      "missing_information": ["缺少对实际恢复条件的确认"]
    }
  ],
  "retrieval_rounds": 3,
  "remaining_budget": 5
}

这是示意性设计，不是某个框架的标准格式。其价值是把临时语言描述转化为可检查、可更新的任务状态。下一轮检索应优先解决 Q2 的缺口，而不是重复搜索已核实的 Q1。

06 · 代表性技术路线：ReAct、Self-RAG 与 Corrective RAG

不同研究从不同角度处理知识获取与使用的问题，三种路线的目标和实现并不相同。

6.1 ReAct：将推理与外部行动交替组织

ReAct（Reasoning and Acting）由 Yao 等人提出，发表于 ICLR 2023。其核心是让语言模型交替进行推理与环境行动：

Reason → Action → Observation → Reason → Action → Observation → Final Answer

在知识任务中，Reason 判断当前需要什么信息；Action 调用搜索或读取工具；Observation 返回外部结果；模型再依据观察调整判断。例如先查官方持久化文档，发现 checkpoint 机制后再查恢复条件，最后形成有条件的结论。

ReAct 的重要贡献是组织模型推理与外部交互，但它本身不提供完整的知识库管理、来源验证或证据治理。工程上可将其作为知识获取循环的控制范式，另外接入检索器、证据存储和运行时管理。

6.2 Self-RAG：学习何时检索与如何评价生成

Self-RAG（Self-Reflective Retrieval-Augmented Generation）由 Asai 等人提出。其研究重点是传统 RAG 经常固定检索，而不同问题、不同生成阶段对外部知识的需求不同。原始方法通过训练模型使用特定的反思标记（reflection tokens），支持检索需求判断、检索内容相关性评价、生成内容的证据支持评价及回答实用性评价。

当前生成状态
    ↓
是否需要检索？
    ├── 否 → 继续生成
    └── 是 → 获取文档 → 评价相关性 → 生成候选 → 评价证据支持

Self-RAG 不只是给普通模型加一句“请检查证据”。 原始研究涉及针对反思行为的训练设计；用提示词模拟类似流程，并不等于复现其训练机制。其工程启发是让检索成为可选择、可评价的行为，而不是固定前置步骤。

6.3 Corrective RAG：检索不可靠时如何纠偏？

Corrective Retrieval-Augmented Generation（CRAG）由 Yan 等人提出，关注检索结果质量不佳时的处理策略。传统 RAG 容易默认检索片段可直接用于生成；CRAG 引入检索结果质量评价，并根据评价采用不同路径。

用户问题 → 初始检索 → 结果评价
                       ├── 质量较好 → 利用相关知识生成
                       ├── 质量不足 → 补充检索与纠偏
                       └── 存在不确定性 → 结合不同知识处理路径

原始研究还涉及对检索内容进一步处理和使用外部搜索补充知识。其价值是把质量评价置于生成之前。研究 Agent 遇到官方文档无法直接回答的问题时，应识别证据不足，而不是根据相似文本强行推出确定结论。

6.4 三种路线的区别

维度	ReAct	Self-RAG	Corrective RAG
核心问题	如何结合推理与外部行动	何时检索、如何评价生成	检索结果不可靠时如何纠偏
主要机制	推理—行动—观察循环	反思标记与自适应检索生成	检索评价与纠正策略
关注重点	Agent 行动过程	检索和生成决策	检索结果质量
是否涉及专门训练	不以专门训练为必要前提	原始方法涉及训练	原始方案涉及检索评价器等组件
工程启发	动态工具调用	按需检索与证据支持判断	低质量检索的检测与恢复
主要局限	不直接解决证据真实性	自我评价仍可能出错	依赖可用来源与评价质量

三者并不互斥。研究 Agent 可以采用 ReAct 风格循环、检索质量评价和生成前证据支持检查，但这样的工程组合不能直接称为对三篇论文原始方法的完整复现。

07 · 从检索结果到知识证据：为什么找到资料还不够？

检索结果是原始材料，真正用于结论的应是经过定位、解释和适用性检查的证据。必须区分 Source（来源）、Evidence（具体证据） 和 Claim（准备输出的主张）。例如，某框架官方持久化文档是 Source；其中描述状态可写入持久化存储的段落是 Evidence；“该框架支持持久化保存任务状态”是 Claim。如果将 Claim 扩展为“能够在任何异常情况下自动恢复全部任务”，就超出了证据范围。

7.1 证据提取的基本流程

获取原始材料并保存来源标识；解析标题、章节、表格、脚注、页码和版本；定位与问题有关的内容；提取事实并区分原文与解释；关联研究问题。示例：

{
  "evidence_id": "E-102",
  "question_id": "Q-03",
  "source": {
    "document_id": "DOC-17",
    "document_type": "official_documentation",
    "version": "vX",
    "locator": "section/persistence"
  },
  "original_text": "<原始证据片段>",
  "extracted_fact": "文档描述了持久化状态的配置方式",
  "verification_status": "pending_review"
}

extracted_fact 是对原文的解释，不应覆盖 original_text。解释有误时，系统必须能回到原文重新核查。

7.2 证据支持关系不是简单的引用关系

某文档介绍数据库持久化配置，可以支持“框架支持将状态保存到数据库”，却不足以支持“所有工具调用恰好执行一次”。即使两者技术上相关，后者仍缺少必要证据。可用关系包括：

SUPPORTS
CONTRADICTS
PARTIALLY_SUPPORTS
CONTEXT_ONLY
INSUFFICIENT

有引用不代表引用支持结论。证据系统需要显式记录支持关系，而非仅保存文档链接。

7.3 多来源交叉验证

来源冲突可能来自不同软件版本、定义、理论与部署条件、转载关系、时效性或实验条件。技术博客说“支持自动恢复”，官方文档说明“需要配置持久化后端”，两者未必完全矛盾：博客可能省略了前提。正确整合是说明“在配置相应持久化机制的条件下，支持某类恢复行为”，保留条件、范围与不确定性，而不是简单投票选一个来源。

08 · 知识整合：Agent 如何从多份资料形成新的理解？

检索与证据提取解决“获得信息”，Knowledge Synthesis 解决“如何把信息组织成对任务有用的认识”。研究 Agent 往往需要跨文档建立事实依赖，而不是分别生成摘要。

8.1 从文档摘要到跨文档综合

假设文档 A 介绍状态持久化，B 介绍人工中断与恢复，C 介绍工具失败重试。用户真正需要判断的是：这个框架是否适合持续数周、允许人工审核、并能从故障恢复的研究工作流？

持久化机制：能否保存任务状态？
       │
人工中断机制：能否暂停等待用户？
       │
恢复执行机制：能否继续之前的执行？
       │
工具执行语义：是否存在重复副作用？
       ↓
长期研究任务适用性判断

最终判断不仅需要抽取事实，还要建立条件、依赖和限制之间的关系。

8.2 使用中间知识表示

{
  "framework": "Framework-A",
  "capability": "execution_recovery",
  "conditions": ["requires_persistent_state_backend"],
  "limitations": ["external_side_effects_require_separate_handling"],
  "evidence_ids": ["E1", "E2", "E3"],
  "verification_status": "partially_verified"
}

结构化表示支持跨框架比较、条件过滤、证据追踪、冲突检测和结论更新，也能减少反复阅读长文的成本。但提取会造成信息损失，原文中的例外或限定可能被遗漏，因此关键事实必须保留回链。

8.3 知识整合与推理的关系

获取证据 → 初步判断 → 发现推理缺口 → 补充检索 → 修正判断
                        ↑                        │
                        └──── 生成新的研究问题 ──┘

复杂任务中，推理本身会产生新的知识需求。例如发现某项技术的性能优势依赖特定硬件，Agent 就需要进一步研究这些条件是否适用于目标项目。Knowledge 与 Planning & Reasoning 因而形成持续反馈关系。

09 · 工程架构：如何构建一个 Agent Knowledge 模块？

9.1 建议的模块架构

Agent Runtime（任务状态、执行控制）
       ↓
Knowledge Need Planner（研究问题、知识缺口）
       ↓
Source Router（来源与检索策略）
       ├── Web Search
       ├── File Search
       └── Database
              ↓
Document Processor（获取、解析、分块）
              ↓
Evidence Extractor（事实提取、原文定位）
              ↓
Evidence Store（证据记录、来源关联）
              ↓
Evidence Evaluator（相关性、支持性、冲突）
       ├── 知识不足 → 继续检索
       └── 知识充分 → Context Assembler → Model → 结论/行动

这是参考逻辑架构，不是唯一实现。早期可将 Need Planner 与 Source Router 合并到一次模型调用；Document Processor 使用现成解析库；Evidence Store 先使用关系数据库；Evaluator 结合规则与模型判断；Context Assembler 作为 Runtime 的一部分。重点是明确职责，不是一开始部署微服务。

9.2 四种核心数据对象

Knowledge Question：需要回答的问题。

{"question_id":"Q1","task_id":"T1","question":"框架是否支持持久化恢复？","required_evidence":"官方文档或可复现测试","status":"open"}

Source Record：获取到的知识来源。

{"source_id":"S1","source_type":"official_documentation","title":"Persistence Documentation","version":"vX","retrieved_at":"2026-10-28T00:00:00Z"}

Evidence Record：来源中的具体证据。

{"evidence_id":"E1","source_id":"S1","question_id":"Q1","locator":"section-3","content":"<证据内容>","verification_status":"pending"}

Knowledge Claim：基于证据形成的事实主张。

{"claim_id":"C1","claim":"框架支持某种持久化恢复方式","supporting_evidence":["E1"],"conditions":["需要配置持久化后端"],"status":"partially_supported"}

对象关系为 Task → Question → Source / Evidence / Claim，Claim 再引用 Evidence。相比只保存搜索结果和最终回答，这种表示更适合长期迭代、核验和更新。

9.3 为什么 Evidence Store 不应只是向量数据库？

向量数据库擅长语义相似性检索，但证据管理还需要唯一标识、文档版本、精确定位、状态、主张关系、撤销和历史变更。一种实用架构是：

Object Storage：保存原始文档
       ↓
Relational Database：保存来源、证据和主张关系
       ↓
Search Index：提供关键词和语义检索

原始文档负责回溯，关系数据库记录事实对象与状态，搜索索引负责发现。小规模项目也可用单一数据库实现；是否拆分取决于数据量、查询复杂度和维护成本。

10 · 工程实践：研究助理 Agent 如何完成一次知识研究任务？

任务：研究 LangGraph、AutoGen 和 CrewAI 在长时间任务执行与恢复方面的技术机制，形成可供项目选型使用的比较报告。 本节描述工作流程，不对三个框架截至当前日期的实际功能作未经核验的结论。

10.1 阶段一：建立研究问题

Q1：三个框架如何保存执行状态？
Q2：是否支持人工中断与恢复？
Q3：进程终止后能否继续执行？
Q4：如何处理工具执行失败？
Q5：恢复时如何避免重复副作用？
Q6：这些机制对长期研究工作流有什么影响？

每个问题应具有明确证据需求。例如 Q3 需要持久化和恢复机制的直接说明，不能仅凭“支持 Memory”得出结论。

10.2 阶段二：制定检索计划

Q1 优先官方架构文档与源代码；Q2 优先人工审批和中断文档；Q3 优先持久化、恢复接口，必要时设计实验；Q4 优先错误处理与重试文档；Q5 优先执行语义与幂等性资料，必要时故障注入。计划不是固定关键词列表，第一轮发现新概念后可以调整后续查询。

10.3 阶段三：执行检索

系统使用官方文档搜索、代码仓库搜索、论文检索、版本发布记录及示例代码。每轮至少记录 Query ID、Question ID、Source、Search Query、Retrieved Documents 和 Retrieval Time，以便追踪结论经过的知识获取步骤。

10.4 阶段四：解析与提取证据

假设官方文档结构为：

Persistence
 ├── Checkpointing
 ├── Storage Backend
 ├── Resume Execution
 └── Configuration

Agent 应按研究问题定位相关章节，从原文提取具体事实，而不是直接生成“具备完整恢复能力”的概括。若文档只说明 checkpoint 存储方式，结论必须限制在相应范围。

10.5 阶段五：建立比较矩阵

研究维度	框架 A	框架 B	框架 C
状态持久化	待证据填充	待证据填充	待证据填充
人工中断	待证据填充	待证据填充	待证据填充
进程恢复	待证据填充	待证据填充	待证据填充
工具重试	待证据填充	待证据填充	待证据填充
副作用处理	待证据填充	待证据填充	待证据填充

每个单元格还应关联证据 ID、适用版本、限定条件和验证状态。例如“框架 A / 进程恢复：在配置持久化后端的条件下支持某类恢复；证据 E11、E12；文档支持，尚未实验验证”。这样报告可随证据更新。

10.6 阶段六：识别剩余知识缺口

假设 Q1—Q3 已解决，Q4 部分解决，Q5 尚未解决。系统应明确当前主要风险是缺少恢复时重复执行行为的证据。若官方文档不足，可继续查源码或设计实验。知识模块指出缺口，规划模块决定下一步方法。

10.7 阶段七：形成研究结论

最终报告应区分：已确认事实（来源和条件明确）、基于事实的工程判断（结合项目需求形成的评价）、尚未验证的假设、建议进一步验证的事项。“框架提供持久化状态机制”可能是可核验技术事实；“更适合我们的长期研究系统”则是综合任务约束形成的工程判断，不能混同。

11 · 最小实现：如何编写知识获取控制器？

Knowledge Controller 读取知识状态、判断缺口、选择工具、处理资料、更新证据并决定是否继续。以下是框架无关的概念性伪代码，不是可直接运行的完整实现：

class KnowledgeController:
    def __init__(self, planner, retriever, extractor, evaluator, evidence_store):
        self.planner = planner
        self.retriever = retriever
        self.extractor = extractor
        self.evaluator = evaluator
        self.evidence_store = evidence_store

    def research(self, task, max_rounds=10):
        state = self.planner.initialize(task)
        for _ in range(max_rounds):
            assessment = self.evaluator.assess(state)
            if assessment.is_sufficient:
                return {"status": "completed", "knowledge_state": state}

            next_question = self.planner.select_gap(state, assessment)
            query = self.planner.build_query(next_question, state)
            documents = self.retriever.search(query)
            evidence = self.extractor.extract(documents, next_question)
            self.evidence_store.save(evidence)
            state = self.planner.update_state(state, evidence)

        return {"status": "incomplete", "knowledge_state": state}

select_gap() 选择最影响任务质量的未解决问题，不一定选择最容易检索的；build_query() 结合研究对象、术语、同义词、已发现文档及来源约束改写查询；extract() 提取证据并保留原文位置；assess() 检查关键问题覆盖、证据支持、版本适用、重大冲突和实验需求。重要任务不能只凭模型回答“已充分”就终止。

12 · 知识检索策略：什么时候继续，什么时候停止？

动态知识获取必须在质量、时间和成本之间权衡。可以用概念性边际价值函数表示每轮检索的增量：

$$\mathrm{\Delta }{V}_t=V(K_{t+1})-V(K_t)$$

其中 $K_t$ 是第 $t$ 轮后的知识状态，$V(K_t)$ 是该状态对任务的价值。这是概念性函数，不意味着系统能直接准确计算。第一轮解决三个关键问题可能收益很高，第二轮补充重要版本限制仍有价值，第三轮只找到重复资料则收益很低。

实际停止判断可结合关键问题覆盖率、证据支持情况、重大冲突、时效性和预算。停止检索不等于宣称所有问题已解决：预算耗尽或可靠来源缺失时，可以停止，但必须报告未解决事项。

失败类型	可能原因	处理策略
没有结果	查询过窄或来源不合适	改写查询、扩大来源范围
大量重复	查询缺乏区分度	加入实体、版本或子问题
相关但不回答问题	目标不够精确	进一步拆分问题
来源冲突	版本、定义或条件不同	检查适用性
解析失败	格式复杂或扫描质量差	更换解析方式并标记不确定性
缺少权威来源	信息尚未公开等	保留未验证状态
需要实验	文档不足以证明实际行为	转入实验验证流程

不同失败不能全部通过“再搜索一次”解决。

13 · Agent Knowledge 的质量评估

Knowledge 质量不能仅通过搜索到的文档数量判断，应该分层评价。

13.1 检索质量

Recall@k 衡量前 k 个结果中召回多少相关文档；Precision@k 衡量前 k 个结果的相关比例；MRR 关注首个相关结果的位置；nDCG 考虑相关程度和排名。它们需要标注过的参考数据，不能只凭模型自评计算。

13.2 证据质量

Evidence Relevance：证据是否直接相关；Evidence Support Accuracy：证据是否支持主张；Source Applicability：时间、版本、地域和对象是否匹配；Conflict Detection Rate：能否识别重要来源冲突。找到正确官方文档但引用错误章节，可能检索合格而证据不合格。

13.3 知识利用质量

关注是否遗漏限定条件、把推测当事实、正确综合多个来源、根据新证据修正判断，以及能否明确指出无法回答的问题。可通过人工标注的研究任务集评估。

13.4 端到端任务质量

最终需要回答是否形成可用于技术选型的报告，综合研究问题覆盖、技术事实准确性、结论可追溯性、比较公平性、未验证事项说明和项目适配性，并测量成本与延迟。高检索质量但需数百轮调用的系统未必适合生产。

13.5 如何验证 Agentic Retrieval 的实际收益？

在相同模型、任务集和知识来源条件下比较：A 单次检索 RAG、B 固定多轮检索、C 动态 Agentic Retrieval。指标包括任务成功率、证据支持率、重大事实错误率、平均检索轮次、工具调用成本、完成时间和人工返工率。只有动态检索在目标任务上产生足够收益，新增复杂度才有工程依据。

14 · 当前技术局限与值得关注的发展方向

14.1 知识需求判断仍不稳定

模型可以提出合理问题，但不一定知道自己缺少某个专业领域的重要概念或限制条件，导致检索计划一开始就有盲点。复杂任务可能需要领域知识结构、任务模板或专家辅助。

14.2 语义相关性不等于事实可靠性

Embedding 和 Reranker 能找到相关材料，但不能证明其真实。多个来源表达同一观点，也可能共同转述一个错误来源。来源独立性、原始证据和事实支持关系仍需检查。

14.3 长链条整合容易累积错误

检索 → 解析 → 提取 → 摘要 → 比较 → 推理 → 生成

每一步都可能丢失限定条件或引入解释错误；若中间结果没有来源回链，错误会在后续被放大。结构化证据和阶段性验证是重要控制点。

14.4 自我评价不能保证正确性

Self-RAG 等研究展示模型评价检索和生成的潜力，但模型可能误判证据支持关系。重要任务仍需独立证据检查、确定性验证或人工复核。

14.5 动态检索可能带来高成本

动态策略增加模型调用、检索请求、状态管理、延迟和恢复成本。重要方向之一是以更少步骤获取足够可靠的知识，而非无限增加工具调用。

14.6 从文档检索走向多种验证方式协同

“某框架能否在数据库断连后恢复执行”可能需要阅读官方文档、检查源码、编写测试、模拟故障、记录恢复结果并解释差异。复杂 Agent 的 Knowledge 能力因此可能结合文档检索、数据库查询、代码分析、程序执行、实验验证和多模态理解，但必须明确执行控制与验证机制。

15 · 核心结论：Knowledge 如何成为 Agent 的实际能力？

第一，Knowledge 的核心不是存储，而是任务驱动的信息获取与利用。 知识库和搜索引擎是基础设施，Agent 需要识别知识需求并决定如何使用信息。

第二，知识获取是动态过程。 检索、推理和行动并非严格线性，新证据改变判断，新判断又产生新的检索需求。

第三，检索结果不能直接等同于知识证据。 可靠系统区分 Source、Evidence 和 Claim，并记录支持关系。

第四，Agentic Retrieval 的价值来自反馈驱动的决策，而不是更多调用。 动态检索应根据缺口调整策略，并在证据充分或预算受限时停止。

第五，Knowledge 需要独立的数据结构和状态管理。 研究问题、来源、证据和结论应具有明确标识与关联，支持长期任务更新、核验和复用。

第六，Knowledge 能力必须通过任务效果验证。 检索准确率、证据支持率和任务成功率属于不同层次，复杂架构应以实际质量、效率或可靠性收益证明价值。

从内部架构看，Model 提供理解与推理，Planning 决定任务推进，Tools 提供外部访问与执行，Context 管理本轮可见信息，Knowledge 则使 Agent 能在任务过程中持续获得和利用新的事实依据。最终目标是让 Agent 不仅依据已有信息回答，还能够主动发现未知、获取证据、修正认识，并在知识变化的环境中完成任务。

参考资料与延伸研究

以下资料用于支撑本文涉及的主要技术路线。本文对论文机制的描述基于既有研究知识，未在本次修订中逐项在线核验论文最新版本、代码实现或后续修订；具体复现应以原始论文及其公开实现为准。

1. Lewis et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. RAG 代表性基础研究。https://arxiv.org/abs/2005.11401
2. Karpukhin et al. (2020). Dense Passage Retrieval for Open-Domain Question Answering. 稠密向量检索。https://arxiv.org/abs/2004.04906
3. Robertson & Zaragoza (2009). The Probabilistic Relevance Framework: BM25 and Beyond. BM25 与概率相关性检索经典综述。
4. Cormack, Clarke & Büttcher (2009). Reciprocal Rank Fusion Outperforms Condorcet and Individual Rank Learning Methods. RRF 排名融合代表性研究。
5. Yao et al. (2023). ReAct: Synergizing Reasoning and Acting in Language Models. 推理与行动交替。https://arxiv.org/abs/2210.03629
6. Asai et al. (2023/2024). Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection. 自适应检索与反思。https://arxiv.org/abs/2310.11511
7. Yan et al. (2024). Corrective Retrieval Augmented Generation. 检索结果质量评价与纠偏。https://arxiv.org/abs/2401.15884
8. Gao et al. (2023/2024). Retrieval-Augmented Generation for Large Language Models: A Survey. RAG 技术综述。https://arxiv.org/abs/2312.10997
9. Liu et al. (2023/2024). Lost in the Middle: How Language Models Use Long Contexts. 长上下文信息利用限制。https://arxiv.org/abs/2307.03172
10. Anthropic. Building Effective Agents. https://www.anthropic.com/engineering/building-effective-agents
11. OpenAI. A Practical Guide to Building Agents. https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/

研究声明

研究与验证说明：本文围绕 Agent Knowledge 的技术原理、代表性研究与工程架构进行综合分析。对 RAG、ReAct、Self-RAG、Corrective RAG、BM25 和 RRF 等技术的描述旨在解释其主要机制，不构成对原始论文所有实验细节的完整复现。“Knowledge Need Planner”“Source Router”“Evidence Store”“Knowledge Controller”等模块名称及组合方式属于参考工程架构，不代表统一行业标准，也不意味着所有 Agent 框架采用相同设计。

最新性状态：本文更新于 2026 年 10 月 28 日。本次修订未逐项在线核验参考论文的最新修订、开源项目当前实现、各框架最新 API 或产品功能。因此，涉及具体技术选型和框架能力时，仍需查阅相应版本的官方文档与源代码。

实验与适用边界：本文未执行真实 Agent 检索实验、模型 API 调用、检索基准测试或端到端性能评估。JSON 结构和 Python 伪代码用于说明架构与数据流，不能直接视为经过验证的生产实现。本文主要适用于以语言模型为认知核心、能够访问外部知识来源的 Agent；对于不依赖外部检索的确定性工作流，或需要严格实时性和形式化正确性保证的系统，应根据具体要求采用更直接的查询、计算或验证机制。