context-infra 检查与复盘infra.guiming.net · 全内容自包含呈现 · 生成于 2026-07-21 16:28 UTC

large_context_extraction_methodology_20260407_manual

Z3 全文↑ Z2 条目

方法论库 · 实跑 · none

← 返回方法论库索引 · 返回方法论区

本页是 <code>contexts/methodology/large_context_extraction_methodology_20260407_manual.md</code> 的逐字投影（仅隐私清洗，零改写）。

时点提示：本页是仓内文件 contexts/methodology/large_context_extraction_methodology_20260407_manual.md 的逐字投影（仅做隐私清洗：仓库根绝对路径→相对路径、家目录→~/；除此零改写）。若源文件后续有修订，以仓内真源为准。

报告元数据（frontmatter）
name: large_context_extraction_methodology_20260407_manual
description: 提取核心方法论（F1-F5 失败模式）
domain: infra
consumption:
  surface: none
  trigger: ""
  consumer: orchestrator
status: library
promoted_to: null

大 Context 信息提取方法论：从实践失败到系统性最佳实践

调研日期：2026-04-07

数据源：24 个并行 sub-agent 调研，覆盖 95 个 JSONL 对话文件、6 天 daily records、20+ 份 survey sessions、4 层记忆管道代码、TODO 全量扫描、外部文献

触发场景：用户在架构重构、Git 工具构建、Codebase Explorer 大仓库分析等多个任务中反复遭遇 Agent 信息提取不完整或方向错误的问题

一、问题定义

"大 context 信息提取"指的是：面对大量文件、大型代码库、长对话历史、多轮调研产出等超出单次 LLM context window 处理能力的信息源，如何让 AI Agent 准确地找到、理解并提炼出用户真正需要的关键信息。

这个问题在以下场景中反复出现：

场景信息源规模核心挑战相关 TODO
Codebase Explorer 分析 Scrapy186 文件, 8 层 DAG, ~80K 行代码Sonnet 200K context window 不够T024, T033, T042
Git 版本控制工具构建5 轮调研 + 12 轮设计迭代 + 18 条外部痛点从分散信息中提炼一致的需求基线T043, T044, T045
Context-Infra 架构重构整个 monorepo + grapeot 原始架构理解每个目录的隐式职责和数据流T019, T070, T088
"最少修改"接入 grapeot 架构两套目录结构 + 设计哲学差异以目标框架为准正推，而非从已有实现倒推T089, T090
每日对话日志提取 TODO/Observation单日日志可达 622KB / 10752 行在噪声中找到可操作的信息T083, T062

二、已识别的失败模式

从 19 个真实的用户不满事件（跨 10 个 session）中归纳出 5 类系统性失败模式。

模式 F1：锚定偏差导致方向性错误（占比 21%）

定义：Agent 先读到熟悉或体量大的信息源，以此为锚点推理，即使用户明确要求以另一个信息源为准。

典型案例：Session f0187cfb（2026-04-01）。用户要求"以鸭哥的框架为基准，把我的内容填充进去"。Agent 先读了用户已有的 contexts/ 目录（熟悉、文件多、结构清晰），后读 grapeot 的 context-infra（模板、空目录多），结果以前者为锚点做映射，方向完全反了。用户同一条纠正消息发了 3 次、Agent 被 interrupt 2 次，耗费 5 小时才校正。

根因分析（来自 thinking trace 分析）：

验证：f018 Lines 82-110 连续 3 次"重新理清"都没有产生结构性变化，第三次才说出根因（"倒推 vs 正推"）。对比 d848（Git 工具 session）被纠正"过于专业化"后，立即重构了思路框架（从方案导向转为痛点导向），后续输出质量明显提升。

模式 F2：大 context 下的信息衰减（占比 32%，最高频）

定义：当处理大量文件或长对话时，Agent 的信息提取能力显著下降，表现为批量任务中跳过部分数据、context 过载导致提取不完整、评估走捷径。

典型案例：

根因分析：

模式 F3：浅尝辄止后自认完成（占比 16%）

定义：Agent 完成了浅层分析或部分执行后，直接标记任务为"完成"，没有自我审视结果是否真正达标。

典型案例：

根因分析：

模式 F4：创造性过剩 / 过度工程化（占比 16%）

定义：Agent 在被要求"最小修改""只做基础设施"时，仍然自行发明新概念、添加评分系统、创建不必要的工具。

典型案例：

根因分析：

模式 F5：Sub-agent 上下文断裂（占比 15%）

定义：主 Agent 将任务分发给 sub-agent 时，关键约束、文件上限、用户偏好等信息没有完整传递。

典型案例：

根因分析：

三、已验证的成功模式

模式 S1：分层压缩 + 确定性预处理 + LLM 语义提取

来源：context-infra 的四层记忆管道（extract_claude_conversations → observer → reflector → axioms）

核心逻辑：

  1. L0→L1 确定性预处理（零 LLM token）：从原始 JSONL 中只保留 5 种内容类型（用户输入、thinking、AI 输出、sub-agent prompt/result），丢弃所有工具调用的机械性输出。这一步将 MB 级的 JSONL 压缩为 KB 级的可读日志
  2. L1→L2 LLM 语义提取（observer，日频）：给 LLM 一份 SOP（KNOWLEDGE_BASE.md）和日志路径，让它自主决定读什么、读多少，按交通灯分级提炼观察
  3. L2→L3 LLM 反思与晋升（reflector，周频）：从观测中提炼跨项目通用的方法论，晋升到 thought_review/ 草稿
  4. L3→永久规则（人工审阅）：最后一步是人工审阅，防止 AI 自行修改核心规则

为什么有效：每一层都压缩信息密度，每一层的输入都是上一层的产物。这比"直接从原始数据提取最终结论"可靠得多。确定性预处理做粗过滤（零成本），LLM 做语义判断（高精度），形成"先筛后炼"的分工。

关键度量：prompt 质量决定"提取什么"，token 管理决定"能不能跑起来"。工程层面的 token 管理（预估、路由、fallback、分段）是系统稳定运行的决定性因素。

模式 S2：逆向提取 + 外部证据交叉验证

来源：Git 工具构建过程的需求基线形成

核心逻辑：

  1. 正向收集（边对话边记录）：在 12 轮对话中，Agent 将用户的散碎表达归纳为 12 个痛点（P1-P12）
  2. 外部验证：Agent 4 的 delta research 从 GitHub issues、Reddit、HN 搜索了 18 条额外痛点（D1-D18），每条附带原始证据链接
  3. 逆向提取：回到 claude_logs 原始对话记录中，逐行扫描用户的每句话，提取出 9 条需求声明和 17 条痛点，去重后归纳为 10 条核心需求
  4. 差距分析：每条核心需求标注当前实现状态（DONE/PARTIAL/GAP）

为什么有效：正向收集容易遗漏用户在不同时间点的发言。逆向提取从完整的对话记录出发，确保无遗漏。外部证据让需求从"Agent 觉得应该做"变成"真实用户在真实场景中遇到过"。

关键证据：D2（rollback 语义陷阱）引用了 Claude Code issue #17190，直接催生了 git_safety.md 的第 2 条规则。这种外部验证将主观需求转化为有实证支撑的设计决策。

模式 S3：全量验证 > Spot-check

来源：Codebase Explorer 的 Judge 改革

核心逻辑：

为什么有效：验证系统比被验证的系统更重要。修复 Judge 本身（全量验证）的影响超过修复任何单个功能 bug。

方法论原则：对于可量化的维度（覆盖率、section 完整性），用确定性脚本；对于需要语义判断的维度（内容质量、架构理解），用 LLM。两者结合形成二重验证。

模式 S4：设计反转是最强信号

来源：Git 工具构建中的 3 次关键设计反转

核心逻辑：每次用户推翻 Agent 方案的时刻，都伴随用户的原话表达。这些原话是最高优先级的需求信号。BUILD_LOG 的做法是逐字记录用户在反转时刻的发言，而不是记录 Agent 的总结。

三次反转的价值：

  1. Worktree 从"不适合"到"默认方案"：揭示了用户对工程可行性的判断优于 Agent
  2. Commit 从"可选"到"daemon 式全自动"：揭示了用户对自动化程度的要求
  3. 语义 refactor 工具被全部砍掉：揭示了用户对过度工程化的零容忍

方法论原则：在信息提取过程中，用户的否定比肯定更有信息量。用户说"不对"的地方是 Agent 理解偏差最大的地方，也是提取到的信息与实际需求差距最大的地方。

模式 S5：Sub-agent context 隔离 + 50% Overlap

来源：multi_agent_analysis skill + 架构审计实践

核心逻辑：

为什么有效：上下文窗口隔离是解决大 context 问题的根本路径。每个 agent 在干净的信息环境中工作，交叉区域的不一致是最有价值的发现。

实证：T019 架构清晰性审计使用 5 个并行 sub-agent 完成，产出了高质量的 repo_architecture_audit_20260406_manual.md。T070 三路考古整合产出了"聊天记录检索四步法+五条反模式"。

四、核心方法论：大 Context 信息提取的八条原则

综合所有证据，提炼出以下八条可操作的原则。

原则 1：分层压缩，永远不要一步到位

规则：原始数据 → 确定性粗过滤 → LLM 语义提取 → 人工验证。每一层只做一种认知操作，每一层的输入都是上一层的产物。

反模式：把 622KB 的原始对话日志直接喂给 LLM 要求"提取所有 TODO"。正确做法是先用正则过滤掉工具调用噪声（零成本），再用 LLM 对清洗后的内容做语义判断。

实现参考：context-infra 的 extract_claude_conversations.py（L0→L1）+ observer.py（L1→L2）+ reflector.py（L2→L3）。

原则 2：Token-aware 路由是基础设施，不是优化

规则：在派出任何 LLM 任务之前，先用字符启发式或 tokenizer 估算输入体积，根据估算结果选择模型（150K 以下用 Sonnet，超过 150K 用 Opus 1M）。失败时自动降级到下一层。

反模式：盲目把大文件塞给 200K 模型，触发 context overflow 后才发现问题。

实现参考：CliAgentRouter 的三层 fallback（opencode:glm-5.1 → claude-zai → claude:opus）+ 6 个 overflow indicator string 的运行时检测。

原则 3：先理解目标框架，再引入源数据（Anti-Anchor Protocol）

规则：当任务是"以 A 为准理解 B"时，必须先单独分析 A 的结构、形成独立的认知模型，然后再引入 B 做映射。避免先读 B（熟悉的、体量大的）导致锚定。

反模式：先读了用户的旧实现（大量文件、结构清晰），后读目标框架（模板、空目录多），以前者为锚点做映射。

实现建议：在 thinking 开始时，显式列出用户的硬约束（如"最小侵入""以 X 为准"），在每个决策点强制检查是否违反。这类似于 pre-commit hook 的机制。

原则 4：全量验证可量化维度，LLM 只做语义判断

规则：对于覆盖率、section 完整性、文件数等可量化维度，用确定性脚本（grep、count、diff）做全量验证。LLM 只负责需要语义理解的判断（内容质量、架构合理性、需求满足度）。

反模式：让 LLM Judge 做 spot-check 几个文件就宣布整体 PASS。这是 Goodhart's Law 的典型表现。

实现参考：CE 的 count_sections.py + Appendix G 注入模式。确定性验证的覆盖率从 spot-check 的 8%（3/37 文件）提升到 100%。

原则 5：Sub-agent 隔离 context，50% Overlap 暴露盲区

规则：

反模式：

原则 6：逆向提取比正向收集更可靠

规则：正向收集（边做边记录）完成后，必须做一次逆向提取（回到原始数据源逐行扫描），对比两者发现遗漏。

反模式：只做正向收集就认为需求完整。Git 工具构建的经验表明，正向收集的 12 个痛点在逆向提取后扩展为 9 条需求声明 + 17 条痛点。

适用场景：需求提取、架构审计、对话摘要、代码变更回溯。

原则 7：用户否定是最强信号，反转时刻逐字记录

规则：在信息提取的每个阶段，用户说"不对""不是这样""不需要"的地方，是 Agent 理解偏差最大的地方。这些反转时刻的用户原话应该被逐字记录，作为最高优先级的需求信号。

实现参考：Git 工具 BUILD_LOG 逐字记录了用户在 3 次设计反转时的原话，每次反转都直接修改了系统设计方向。

原则 8：收敛信号驱动，而非固定轮次

规则：不要预设做 N 轮提取，而是监控四个收敛信号：

  1. 新发现的修改指令可以直接执行（无需进一步拆解）
  2. 预测力达标（提取的信息能预测未覆盖区域的内容）
  3. 反例类型开始重复（不再发现新的反例种类）
  4. 关系图稳定（新一轮不再改变核心结构）

满足 3/4 即可停止迭代。

反模式：预设"做 11 轮迭代"，即使第 3 轮就已经收敛（Flask），或第 11 轮仍未收敛（Scrapy）。

五、具体场景的应用指南

场景 A：大型代码库架构提取（Codebase Explorer 场景）

前提约束：超过 150 文件的仓库需要 Opus 1M context 或 batch splitting。

推荐流程：

  1. MCP 做确定性分析：只做"文件到功能模块"分类（R1），不输出函数名/签名（避免 token 膨胀）
  2. Token 预算驱动的任务分配：FFD bin-packing，单 sub-agent 不超过 30 文件 / 150K tokens
  3. 层级化文档结构：超过 3 层 DAG 的模块生成多层嵌套 INDEX/DETAIL，而非扁平两层
  4. MCP 渐进式披露：三级分层返回（模块列表 → 模块内文件列表 → 文件详情），避免一次性返回全部数据
  5. 全量验证：用确定性脚本（count_sections.py）做覆盖率检查，LLM 做语义质量评判

场景 B：从大型对话 Session 中提取需求（Git 工具、架构重构场景）

推荐流程：

  1. 确定性预处理：从 JSONL 中只提取 [U]（用户输入）、[A]（AI 输出）、[S>]（sub-agent prompt），丢弃工具调用噪声
  2. 正向收集：边阅读边结构化用户需求，归纳为痛点列表
  3. 外部验证：搜索 GitHub issues、Reddit、HN，寻找相同痛点的外部证据
  4. 逆向提取：回到原始对话，逐行扫描用户的每句话，对比正向收集的结果
  5. 差距分析：每条需求标注实现状态（DONE/PARTIAL/GAP），形成需求基线
  6. 反转记录：所有用户否定的地方逐字记录，作为最高优先级信号

场景 C：架构迁移中的目录职责理解

推荐流程：

  1. Anti-Anchor Protocol：先单独分析目标框架的每个目录，形成独立的认知模型
  2. 数据流追踪：从代码（.py 文件）中追踪每个目录的输入来源和输出去向，识别隐式数据流
  3. 最后才引入源数据：理解了目标框架后，再逐个对应源数据的放置位置
  4. First-class constraint checking：在每个决策点检查是否违反用户的硬约束（如"最小侵入"）

场景 D：每日对话日志的信息提炼

推荐流程：

  1. 确定性预过滤：丢弃 tool_use/tool_result、system-reminder 标签、短于 5 字符的消息
  2. Token-aware 路由：估算日志体积，超过 150K 自动升级到 Opus 1M
  3. Pull 模式：给 LLM SOP 和路径，让它自主决定读什么、读多少，而非把全部内容推给它
  4. 交通灯分级：红灯（跨项目通用）、黄灯（项目相关）、绿灯（日常细节），不同级别有不同的保留周期
  5. 幂等性保障：检查 OBSERVATIONS.md 是否已有当日条目，存在则跳过

六、与现有 Skill 体系的集成

现有 skill 体系已具备大 context 信息提取所需的几乎所有方法论要素，但分布在不同 skill 中，尚未被组合成端到端的提取工作流。

组合架构

Phase 0: 数据准备
  工具: token_estimator.py (预估) + extract_claude_conversations.py (预过滤)
  方法: knowledge_flywheel (接受起点不完美，先跑起来)
  公理: T07 隔离-处理-验证闭环 (冻结输入快照)

Phase 1: 广泛扫描
  工具: workflow_parallel_subagents (3-5 个 sub-agent 并行)
  方法: workflow_deep_research_survey Phase 1 (Claim 提取)
       + workflow_cognitive_profile_extraction Phase 1 (五维度正交扫描)
  公理: X06 抓大放小 (先找最大决策点), T03 上下文隔离
  分割策略: bestpractice_multi_agent_analysis (50% overlap, 综合+专题双层)

Phase 2: 深度验证
  工具: parallel_subagents + semantic_search
  方法: cognitive_profile_extraction Phase 2 (核心验证 + 跨源对比)
       + deep_research_survey Phase 3 (交叉验证)
  关键约束: 去重 (前一轮已引用的证据不要重复)
  公理: X05 精度级联 (前置验证), M06 连接胜过孤立知识

Phase 3: 压力测试
  方法: cognitive_profile_extraction Phase 3 (互斥性检验 + 反例狩猎)
       + bestpractice_autoresearch_loop (Modify→Verify→Keep/Discard)
  反模式防御: Goodhart 陷阱、抽样验证陷阱、代理指标陷阱

Phase 4: 整合定稿
  方法: cognitive_profile_extraction Phase 4 (写作不 delegate)
       + bestpractice_architecture_doc_design (渐进式披露 + 交叉引用)
  收敛标准: 四信号收敛 (见原则 8)
  公理: T05 认知是资产 (固化结构性理解)

角色分工

当前缺口

  1. 没有专门面向"代码库"的信息提取 skill（deep_research_survey 面向外部调研，cognitive_profile_extraction 面向对话数据）
  2. Reflector 没有使用 CliAgentRouter（缺少 token 预检和 fallback）
  3. 分段策略是 advisory 而非 mandatory（KNOWLEDGE_BASE.md 建议用 sub-agent，但代码层面没有强制）
  4. 缺少提取质量的闭环验证（提取完成后，应随机采样 2-3 条回溯原始数据确认准确性）

七、外部方法论综述

外部研究 agent 产出了两份独立的调研报告（见附录），核心发现如下。

学术前沿（2025-2026）

  1. Lost in the Middle 是架构固有属性：RoPE 位置编码导致 U 型注意力曲线，中间位置信息准确率下降 30%+。ICLR 2026 论文证明这在随机初始化模型上就存在。实操对策：关键信息放 context 前 20% 或后 20%，提取指令放末尾。
  1. 三噪声分解框架（ICLR 2026）回答了"何时分割、何时全量"：
  1. 2026 共识：Hybrid 是正解。小而稳定的文档集用 Long Context；大而变化的语料库用 RAG；多步骤多文档推理用 Hybrid（先检索缩小范围，再用长 context 做跨文档综合）。

工业实践

技术路线代表工具核心机制Trade-off
Agentic SearchClaude Code零索引，模型通过 grep/glob/read 自主搜索实时性强，但 token 消耗高
RAG/EmbeddingCursortree-sitter chunking + 向量库 + 增量同步语义搜索准确率提升 12.5%，需要构建维护
结构化图谱Aider Repo Map, SocratiCodeAST + PageRank/Louvain 社区检测Token 效率极高（仅传签名），需要构建
两阶段流水线SWE-AdeptLocator Agent 先定位 + Fixer Agent 再深入定位准确率提升 5.4%，token 消耗显著降低

行业方向正在走向 Hybrid：轻量本地索引 + 模型驱动的查询精化。LSP 集成是被低估的能力（零 token 成本的精确导航）。Progressive Disclosure 在所有成功方案中反复出现。

与本方法论的对齐

本报告提出的八条原则与外部研究高度一致：

本方法论原则外部验证
分层压缩三噪声分解证明：分层处理在 Model Noise > Task Noise 时优于全量
Token-aware 路由Claude Code 内部实现了 5 种 context 压缩策略（Auto/Reactive/History/Collapse/Micro）
Anti-Anchor ProtocolLost in the Middle 研究证明位置影响注意力，先读的信息确实有锚定效应
Sub-agent 隔离SWE-Adept 的两阶段架构验证了分离 Locator 和 Fixer 的有效性
渐进式披露多篇独立文献收敛到同一设计：三层信息暴露（Metadata→Structure→Content）

尚无人做的事

目前没有一个统一的端到端框架把理论层（三噪声分解）、工程层（Context Engineering）、Agent 层（两阶段定位）和信息架构层（Progressive Disclosure）整合起来。本方法论的八条原则和四阶段流程可能是这个方向的一个初步尝试。

详细调研报告见：

本方法论与用户的底层思想体系高度一致：

用户哲学在方法论中的体现
熵控制论（好的设计就是在合适的层级约束熵）分层压缩，每层只做一种认知操作，子节点的零熵（确定性预处理）限制整体复杂性
数据共处原则（AI 的智能上限取决于它与数据的距离）Pull 模式（让 AI 自己决定读什么），而非把所有数据推给它
认知资产观（代码生成成本趋零后，真正有价值的是理解和认知结构）提取的目标不是保存原始数据，而是捕获被提炼出来的结构性理解
渐进式披露（信息应分层组织，从全局到细节）INDEX→README→Detail 的导航结构，MCP 三级分层返回
底层同构论（如果两个事物在某些地方表现相似，它们在底层一定共享某种结构）分层压缩 ≅ CPU 多级缓存，50% overlap ≅ 冗余 RAID，逆向提取 ≅ 编译器的验证 pass

九、附录：数据源索引

直接相关的 TODO（10 个）

T024, T033, T042, T088, T089, T090, T091, T083, T077, T078

核心 JSONL Session

调研报告

代码实现

公理映射

T03 上下文隔离, T05 认知是资产, T07 隔离-处理-验证闭环, X05 精度级联, X06 抓大放小, M06 连接胜过孤立知识, V02 可验证性是信任的地基, A05 文档即长期记忆

← 返回方法论库索引 · 返回方法论区