Context Engineering-探索式理解

随着大型语言模型（LLMs）的快速发展，其上下文窗口已显著扩展，有些模型甚至支持超过100万个标记的上下文。然而你如果经常使用的话会发现当上下文超过一定阈值的时候，模型的回答质量开始恶化。虽然更多的信息有利于模型的理解，然而这些上下文中存在很多 垃圾/无效 信息，导致模型答非所问，因此一个有效的解决方法是更好的索引上下文。

“探索式理解”的意义不在于换一套工作流程，而在于在面对不确定、复杂、稀疏信息时，用一种主动、递进、元认知的方式从片段走向可靠的整体认知。让 Agent 可以从零散的信息中构建起一个完整、稳健且具有深度的知识体系。

目录：

• 上下文管理方法

• 检索增强生成
• 探索式理解

• 实现探索式理解

• 探索式理解方案解析

• 我对探索式理解的看法

上下文管理方法

检索增强生成

传统的上下文管理方法，如检索增强生成（RAG），通过预先索引所有上下文并根据查询检索相关内容来解决问题。然而，这种方法在处理复杂或动态信息空间时可能显得低效。一种新兴的替代方法——“探索式理解”（exploratory understanding）——通过动态、迭代的方式管理上下文，展现出更高的灵活性和效率。RAG的工作流程如下：

1. 索引：将所有上下文内容编码为向量，存储在数据库中。
2. 检索：根据用户查询，找到与查询向量最相似的文档。
3. 生成：将检索到的文档与查询一起输入模型，生成最终回答。

但它存在一些局限性：

• 上下文污染： 检索出的文档片段，即便在向量空间上与问题“接近”，也可能包含大量与解决问题无关的“噪音”，甚至是有误导性的信息。模型需要耗费额外的注意力去甄别和过滤这些“垃圾信息”。
• 上下文割裂： 将文档强行切片，本身就可能破坏信息的完整性和上下文关联。传统的RAG很难理解跨越多个文档片段的复杂逻辑。
• 被动式理解： RAG是一个被动的过程。它像一个尽职但缺乏思考的图书管理员，只能根据你给的关键词（问题向量）递上几本书（文本块），而无法主动地去探索、推理和验证信息。

探索式理解

与RAG这种“地毯式轰炸”后被动整合信息的方式相对，一种更主动、更智能的范式应运而生，我们称之为“探索式理解”。

“探索式理解”借鉴了人类专家解决未知问题的认知过程。它不试图一次性消化所有信息，而是将LLM封装成一个能够与环境交互的智能体（Agent），让它带着问题主动地、迭代地去探索信息源，在“探索-思考-再探索”的循环中，逐步构建起对问题的完整理解。这就像一位经验丰富的开发者被要求去理解一个陌生的代码库。他不会从头到尾阅读每一行代码，而是会：

1. 提出问题： “这个功能的核心入口在哪里？”
2. 使用工具探索： 使用 grep 搜索关键函数名，使用 find 或 ls 查看目录结构。
3. 分析结果并形成假设： “看起来 main.py 调用了 api_handler.go，这个可能是关键链路。”
4. 迭代探索： 深入 api_handler.go 文件，继续搜索和阅读，验证或推翻自己的假设。

这种方法类似于人类在探索新领域时的“边学边做”过程，强调灵活性和适应性。

与RAG相比，探索式理解具有以下特点：

• 动态性：无需预先索引所有上下文，模型可以根据当前任务需求动态检索信息。
• 效率：通过专注于最相关的信息，减少处理无关内容的计算负担。
• 适应性：适合处理动态或开放式任务，如探索性研究或实时数据分析。

例如，在代码分析场景中，RAG可能需要索引整个代码库，而探索式理解允许模型通过搜索工具（如代码搜索API）查找特定函数或模块，逐步构建对代码的理解。这种方法在处理大型代码库或快速变化的数据集时尤为有效。

实现探索式理解

实现“探索式理解”的关键，在于将LLM的能力从单纯的“文本生成”提升到“工具使用”和“任务规划”。

• 赋予LLM使用工具的能力：这是最核心的一步。我们需要让LLM能够调用外部工具，就像人类使用软件一样。在代码库理解的场景下，这些工具就是命令行指令，如grep(文本搜索),ls(列出文件),cat(查看文件内容),find(查找文件) 等。实现方式通常是向LLM提供一个工具列表及其功能描述，LLM在需要时可以生成特定格式的指令（如JSON或函数调用），由外部的执行器来执行，并将结果返回给LLM。
• 任务规划与分解（Planning & Decomposition）：对于复杂问题，LLM需要具备将其分解为一系列可执行子任务的能力。例如，对于“解释用户认证功能的完整流程”这个问题，Agent可能会将其分解为：

• Task 1: Find the entry point for user login.
• Task 2: Trace the function calls from the entry point.
• Task 3: Identify the database or service used for authentication.
• Task 4: Summarize the entire flow.

• 迭代循环与自我反思（ReAct/ReWOO）：Agent的探索过程是一个循环。经典的ReAct (Reasoning and Acting)框架很好地描述了这个过程：LLM首先进行思考（Thought），分析当前情况，决定下一步行动（Action）（即调用哪个工具），然后执行行动，观察结果（Observation），并基于结果进行新一轮的思考。这个循环不断持续，直到任务完成。这种机制允许Agent从错误中学习，并动态调整其探索策略。

探索式理解方案解析

一个比较好的例子是 Claude-Code ，虽然其只提供了一个空的 github 仓库但是我们仍然可以通过逆向工程分析，解析其探索式理解方案。这个过程模仿了人类进行研究或调试时的思维方式，有显式假设（hypotheses）、证据积累与关联（evidence）、自我反省（think prompt 里的支持/反驳）、动态决策（选假设去搜）、再探索与终止判断，结构清晰，能够支撑一个 agentic search 过程。

关键子函数 / 策略说明

• generate_initial_hypotheses(question): 用 LLM 基于问题生成 3~5 个不同角度的“在哪儿可能实现”、“调用链可能是什么”之类的假设，附带初始低置信度。
• select_hypothesis_to_explore(belief): 选择置信度提升潜力最大或当前证据最稀缺的假设（例如用信息增益估计）。
• formulate_search_queries(hypo): 从假设中抽关键词、推导出目录/函数名模式（如从“feature X 可能在handler系列文件里，用process_*函数实现”生成 grep 模式）。
• build_think_prompt(...): 把当前 best hypothesis、已有证据、前一次 LLM 自检结果包装成链式思考提示，例：

系统：你是探索式理解 Agent。请基于以下假设和证据进行自我校验并决定下一步。
假设：{hypo_desc}（当前置信度: {confidence}）
已有证据：{list evidence snippets}
要求：列出这个假设成立的三条核心证据，以及最多两条反例/疑点。如果证据不够，生成更细化的搜索 query 或修正假设。

• interpret_llm_output(...): 解析出新的假设、需要进一步搜索的子问题、初步答案、是否需要反例验证等。
• should_terminate(...): 结合：

• 最高置信度假设达到阈值（比如 >0.85）
• 反例检测没有发现致命冲突
• LLM 在 “请总结最终理解” 中能给出结构化、完整的答案

• synthesize_answer(...): 整合所有高置信度证据，生成“实现位置 + 调用流程 + 关键参数/依赖 + 可能的边界条件 / 未验证点”的最终报告。

提示词设计

系统提示词

你是一个有工具能力的探索型智能体 (Exploratory Agent)。
每轮要做三件事：
1. 基于当前假设与证据“思考”（列出支持/反驳、未覆盖的证据缺口）。
2. 决定下一步最有信息增益的探索动作（搜索、细化假设、反例验证）。
3. 生成结构化状态更新（假设更新、证据打分、推荐的子问题）。
你的回答要明确区分：当前最可信假设、证据摘要、下一步行动建议、是否可以终止。

任务提示词（动态）

目标：找出代码库中实现 feature X 的模块/函数，并解释其调用流程。
当前已知：{自动填入已采集的证据片段摘要}
请执行：
1. 评估现有假设（列出 top-2 假设及每个置信度/薄弱点）。
2. 基于现有证据列出支持和反驳每个假设的关键点。
3. 如果信息不足，提出最有价值的下一个搜索 query（包含关键词、路径、工具建议）。
4. 如果已有足够证据，请给出结构化解释（实现位置、调用链、依赖、未解的疑问）。
格式化输出：
- Hypotheses: ...
- Evidence Summary: ...
- Next Actions: ...
- Final Answer (如果可终止): ...

我对探索式理解的看法

“探索式理解”代表了我们与AI交互方式的一次深刻转变，它标志着我们正从将AI视为一个静态的“知识库”转向一个动态的“问题解决伙伴”。

• 效率与精准性的飞跃： 相较于RAG的“大海捞针”，探索式理解是“精确制导”。它通过聚焦于解决问题直接相关的最小信息集，极大地减少了上下文的噪音，提升了模型注意力的利用效率，从而获得更精准、更深入的答案。
• 通往真正“推理”的阶梯： RAG的本质是模式匹配，而探索式理解则包含了初步的规划、假设和验证。这种动态的探索过程，是通向更高级别机器推理能力的必经之路。
• 未来的挑战与机遇： 当前，构建和调试这类Agent仍然具有挑战性，需要精心设计的Prompt、可靠的工具集和对失败情况的良好处理机制。然而，随着模型能力的增强和框架的成熟，我们有理由相信，“探索式理解”将成为处理复杂、长上下文任务（尤其是代码理解、法律文档分析、科学研究等领域）的标配。

总而言之，当整个行业还在为上下文窗口的“长度”而焦虑时，“探索式理解”提醒我们，真正的智能在于如何高效地利用信息，而不在于能一次性“吞下”多少。这不仅是一种技术路线的演进，更是一种哲学上的回归——回归到人类解决问题时那种最自然、最高效的探索式思维。