本入门指南聚焦于构建真实世界 LLM 应用时最重要的挑战之一：上下文窗口管理。

现代 LLM 技术栈全景。

大型语言模型（LLM）正迅速改变我们构建软件、处理知识及自动化复杂任务的方式。与此同时，LLM 生态演进之快，以至于我们很难把真正有用的工程工具从噪声中分辨出来。

当应用变得越来越复杂时，决定向 LLM 提供哪些信息、省略哪些信息，以及如何结构化并维护上下文，就变得对可靠性、性能和成本至关重要。在本文中，你将学到管理上下文的业界前沿实用方法，包括：上下文选择、压缩、摘要、检索、记忆，以及避免上下文过载和"中途丢失（lost-in-the-middle）“现象的技巧。目标是为你在构建真实世界 LLM 应用时理解并运用上下文窗口管理，提供一个实用的起点。每一节都会介绍相关的博客和实用工具，你可以亲自尝试和使用。

如果你觉得这篇文章有帮助，欢迎关注我，因为我会写更多数据科学的内容！我建议你亲自尝试本文中的动手示例，这能帮你学得更快、理解更深、记得更牢。泡杯咖啡，享受乐趣！

LLM 全景概览

要理解快速演进的 LLM 生态，最好把眼光放到单个 LLM 模型之外，去理解围绕它们构建的工具与工作流。已经很清楚的一点是：这个大型语言模型本身充当着整个系统的"计算核心”，而它的周围需要许多构建模块。下图给出了 LLM 全景的概览，可以看到现代 LLM 技术栈的开发涉及众多组件。本文聚焦于上下文管理以及（外部）数据的处理。在下一节，我们会看到一些帮助我们进行窗口上下文管理的工具与技术。你将学习如何为系统指令和结构化输出构建上下文架构。

现代 LLM 技术栈全景，本文聚焦于上下文管理与（外部）数据。

切勿低估上下文窗口的重要性

与 LLM 协作感觉很直观，这既是优点也是缺点；你随便聊几句，它就能返回结果。 LLM 可以极其强大，但其输出在很大程度上取决于它所收到的系统、指令、上下文、技能与约束。提示工程（Prompting）与其说是找到完美的问题，不如说是与模型一起设计一套可靠的架构。其目标是让 LLM 更可预测、更可靠、更高效。而这一切都要从上下文窗口说起。

提示工程与其说是寻找完美的问题，不如说是与模型一起设计一套可靠的架构。

总上下文窗口大小就是限制

上下文窗口的重要性不容低估；它是你 LLM 流水线中最重要的部分之一，因为它是模型的临时工作记忆。然而，就像真正的记忆一样，上下文窗口空间有限，却需要容纳几十种不同的功能。即便是支持超大上下文窗口（比如 200K token）的模型，也容易被推到实际极限。结果，关键段落（例如文档中的某部分）可能被隐式压缩或忽略，导致推理不完整。下图列出了一些最重要的组成部分，即：密集的系统指令、标准与严格的输出格式 schema，以及以块（chunk）形式存在的文档、聊天历史等等。

可以把上下文窗口看作你拥有的内存（RAM）大小。一旦超出它的极限，它就会崩溃并返回错误。

总上下文窗口概览。

当你使用 OpenAI、Anthropic 或 Kimi K3 时，很可能拥有 1M token 的上下文窗口。这很棒，但在解决庞大而复杂的任务时，把所有信息都塞进聊天窗口（所谓的"单体式 monolithic"方法）有诸多缺点。详细的拆解和其他细节推演可以在<构建个人 Agentic 系统的分步指南>这篇文章里找到。下一节我们会介绍如何有效利用上下文窗口的方法，其中系统和指令是关键。

上下文管理：可靠且高效的 LLM

像 OpenAI 和 Anthropic 这样的领跑者，会大量利用上下文来提升模型性能，综合运用专门化的系统提示词、指令、工具以及其他相关信息来有效引导模型。但 LLM 上下文窗口的内容已不再局限于提示词和用户消息。新技术，尤其是 Agent、记忆、检索和工具使用，正不断改变进入上下文窗口的内容。归根结底，最优的上下文取决于具体任务与使用场景，这使得有效的上下文管理成为构建可靠、高效 LLM 应用不可或缺的一环。下图描绘了上下文窗口中几大知名组成部分的概览。在接下来的小节里，每个部分都会连同最相关的博客和 GitHub 仓库一起介绍。

上下文窗口管理是一项新任务，需要用心经营才能让 LLM 更可靠、更高效。

系统提示词：模型的行为

系统提示词（system prompt）是上下文窗口中定义模型行为的那一部分。也就是说，从助理的语气和专业度，到它如何处理不确定性、使用工具，乃至如何拒绝请求，都可以由它来定义。理解它们能为设计更可靠的 AI 系统提供宝贵经验。很长一段时间里，外界都不清楚 OpenAI、Anthropic 的 AI 助理是如何设计的。System Prompt Leaks 这个仓库<GitHub — asgeirtj/system_prompts_leaks：从 Anthropic 提取的系统提示词>收集了从主流 AI 助理中提取出的系统提示词，记录下引导这些模型行为的隐藏指令，包括它们的规则、限制、个性、工具使用和应答策略。

这个仓库展示了几个重要的理念：

  • 提示工程就是软件工程：系统提示词正日益成为应用逻辑的关键组成部分。
  • 塑造模型行为：措辞上的微小改动就能显著影响模型的输出。
  • 透明很重要：理解 AI 助理的配置方式，能帮助研究者评估它们的行为。
  • 提示安全很重要：暴露或操纵隐藏指令可能引发意想不到的行为。

优化你的指令

Andrej Karpathy 是 AI 研究员、OpenAI 创始成员之一，他指出了使用 LLM 时存在的各种问题，并在 GitHub 上开源了他的指令文件（见下方链接）。这个仓库很受欢迎，拥有 20 万+ star 和 2 万+ fork。 请注意，这个仓库不只是提示技巧；它让 LLM 在使用 agentic 编程方式（如 Claude）修改代码库时表现得更加有效。

他在使用 agentic 编码时指出的三个问题如下：

1. 模型会替你自作主张地做出错误假设，并且不加以核实就一路照做。它们不管理自己的困惑、不主动澄清、不暴露不一致之处、不摆出取舍权衡、在该提出异议时也不反驳。

2. 它们真的很喜欢把代码和 API 复杂化，让抽象膨胀、不清理死代码……能用 100 行解决的事，却实现出一个 1000 多行臃肿的结构。

3. 它们有时仍会改动/删除自己理解不透彻的注释和代码，即使这些改动与任务无关，也会作为"副作用"发生。

GitHub — multica-ai/andrej-karpathy-skills：一份用于改进 Claude Code 的单一 CLAUDE.md 文件…

为解决这些问题，Andrej Karpathy 创建了一个 CLAUDE.md 文件，用四项原则来应对（见图），下面代码块中给出了精确的 markdown 文本。

固件指令。Karpathy 代码库规则。

你可以在本地环境中轻松应用这些指令。1. 在你的工作仓库根目录下新建一个文件，命名为 CLAUDE.md。2. 把下面的代码块加进去（或者从该仓库获取，或创建你自己的定制版）。3. 从此以后，你启动时 Claude 会自动把 CLAUDE.md 作为项目级指令使用。你也可以把这个文件放到全局系统路径，比如 \Users\<用户名>\.claude\CLAUDE.md，那么每次新开一个 Claude 会话它都会被加载。你的仓库目录结构会像这样：

# 将 CLAUDE.md 加入你的本地项目

my-project/
├── CLAUDE.md
├── src/
├── tests/
└── ...
# 或者把 CLAUDE.md 放到全局
 ~/.claude/
├── CLAUDE.md
└── ...

---
name: karpathy-guidelines
description: Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria.
license: MIT
---

# Karpathy Guidelines
Behavioral guidelines to reduce common LLM coding mistakes, derived from [Andrej Karpathy's observations](https://x.com/karpathy/status/2015883857489522876) on LLM coding pitfalls.
**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
## 1. Think Before Coding
**Don't assume. Don't hide confusion. Surface tradeoffs.**
Before implementing:
- State your assumptions explicitly. If uncertain, ask.
- If multiple interpretations exist, present them - don't pick silently.
- If a simpler approach exists, say so. Push back when warranted.
- If something is unclear, stop. Name what's confusing. Ask.
## 2. Simplicity First
**Minimum code that solves the problem. Nothing speculative.**
- No features beyond what was asked.
- No abstractions for single-use code.
- No "flexibility" or "configurability" that wasn't requested.
- No error handling for impossible scenarios.
- If you write 200 lines and it could be 50, rewrite it.
Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
## 3. Surgical Changes
**Touch only what you must. Clean up only your own mess.**
When editing existing code:
- Don't "improve" adjacent code, comments, or formatting.
- Don't refactor things that aren't broken.
- Match existing style, even if you'd do it differently.
- If you notice unrelated dead code, mention it - don't delete it.
When your changes create orphans:
- Remove imports/variables/functions that YOUR changes made unused.
- Don't remove pre-existing dead code unless asked.
The test: Every changed line should trace directly to the user's request.
## 4. Goal-Driven Execution
**Define success criteria. Loop until verified.**
Transform tasks into verifiable goals:
- "Add validation" → "Write tests for invalid inputs, then make them pass"
- "Fix the bug" → "Write a test that reproduces it, then make it pass"
- "Refactor X" → "Ensure tests pass before and after"
For multi-step tasks, state a brief plan:
```
1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]
```
Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.

添加 Skills 来教会你的 LLM 完成特定任务

Skills 是按需动态加载、用于提升特定任务表现的指令、脚本和资源文件夹。Skills 教你的 LLM 以可重复的方式完成特定任务——无论是按你公司的品牌规范创建文档、用你组织专有的特定工作流分析数据，还是把个人任务自动化。在下面两个仓库中，你可以下载从创意应用（艺术、音乐、设计）到技术任务（Web 应用测试、MCP 服务器生成），再到企业工作流（沟通、品牌等）的各类 Skills。

GitHub — anthropics/skills: Public repository for Agent Skills

GitHub — agentskills/agentskills: Specification and documentation for Agent Skills

每个 skill 都应当自包含在 skills 文件夹中，内含一个 SKILL.md 文件，其中写着模型会用到的指令和元数据。你可以把这些 skills 加到全局系统路径，例如 \Users\<用户名>\.claude\skills\，那么每个新的 Claude 会话都会加载它们。请注意，直接把 skills 复制进 skills 目录也能用，但如果你希望 skill 能自动更新，最好使用 marketplace 安装方式。

# 在 Claude Code 内部，运行：
/plugin marketplace add anthropics/skills

# 然后安装文档类 skills：
/plugin install document-skills@anthropic-agent-skills

# 它会为 Claude 提供类似下面的技能：
# PDF
# Word / DOCX
# PowerPoint / PPTX
# Excel / XLSX

你也可以手动复制 skills。

# Claude 全局目录里 skills 的示例。
# 每个 skill 都应有自己独立的目录，里面放着 skill 文件/脚本。

~/.claude/
└── skills/
    ├── pdfs/
    │   └── SKILL.md
    ├── docs/
    │   └── SKILL.md
    ├── spreadsheets/
    │   └── SKILL.md
    └── slides/
        └── SKILL.md

防止上下文膨胀（Context Bloat）

现代 LLM 应用带来一个新挑战：上下文膨胀。系统指令、对话历史、检索到的文档、工具输出和示例很容易就消耗掉几千个 token。因此，管理上下文窗口至关重要：过度膨胀的上下文会降低准确率、增加 token 用量、推高成本。更多的上下文并不总是更好。

其中一个原因是 Lost in the Middle（丢失在中间）现象：LLM 倾向于最有效地利用出现在上下文开头或结尾的信息，而放在中间的信息则更可能被忽略。这给检索增强生成（RAG）带来一个重要的实践考量：检索到的信息所处的位置很关键。 简单地把块（chunk）按检索得分从高到低排序并不一定是最优做法。相反，最相关的块应该放在靠近末尾、靠近问题的地方。较不相关的块应放到中间。这样，排序能提升答案的质量。

你应当检索的块的数量也有一个最优值。随着添加更多文档，准确率并不必然上升。超过某个临界点后，额外的块会把最相关的信息推向上下文中间，同时增加 token 和噪声。换句话说，top-k 存在一个最优区间，而不是"越多越好"的关系。这也凸显出 重排（reranking）与排序（ordering） 之间的一个重要区别：重排决定哪些块能存活，排序则决定这些块被放到上下文的哪个位置。因此，一个 RAG 流水线即使拥有出色的重排器，如果最相关的那个块最终被埋在上下文中间，表现也可能很差。

“丢失在中间"现象示意。

更多的上下文并不总是更好。Lost in the Middle 现象表明，随着上下文增长，重要信息可能被淹没。

Token 优化

Token 优化与上下文管理正成为不可或缺的工程技能。Headroom 是一个 GitHub 库，设计用于在 LLM 应用中减少不必要的 token 使用，办法是在发送给模型之前自动压缩和优化提示词。其目标是在不显著改变输出质量的前提下，让工作流更快、更便宜、更易扩展。如果你在用 Claude，可以输入 /context 查看上下文被填充的情况，用 /compact 压缩上下文窗口里的信息。见下方我用刚加载的 Gemma4 26BA4B 模型时截取的图。它已经有 16% 的上下文被填满了。

在 Claude 中使用 /context 的示例。

GitHub — headroomlabs-ai/headroom: Compress tool outputs, logs, files, and RAG chunks before they…

How I Cut Claude Code Token Usage by 90%+ With 5 Tools, Custom Hooks, and Enforcement

结构化输出

结构化输出正成为 LLM 应用的基础组成部分。Agent、API、检索系统和自动化工作流，常常依赖 LLM 返回可预测的 JSON 对象。尽管 LLM 很擅长生成结构化信息，但它们并不能保证严格遵守格式规则。一些非常常见的毛病包括：缺少引号、结尾多余逗号、括号不闭合、转义错误、单引号代替双引号、JSON 周围多出的解释性文字，以及生成到一半的响应。

这些错误对于开发者来说通常很容易修复，但当你身处一个自动化流水线中时，它们会弄坏下游应用。JSON repair 这个库专为解决将 LLM 集成到软件系统时最常见的一个实际问题而设计：模型常常产出"几乎正确、但不足以用于自动化处理"的 JSON。

GitHub — mangiucugna/json_repair: Repair malformed JSON from LLMs, APIs, logs, and user input in…

初始化新项目

当你启动一个新项目时，你的编码 Agent 需要先理解这个仓库，这就要打开文件、研究目录结构等等。这通常是一个开销很大的过程，因为会消耗大量 token。

使用 Claude 时，/init 会为每个新项目初始化项目结构、分析你的代码库，并写出全面的 CLAUDE.md 文件，包含项目摘要、架构决策、编码规范、关键依赖与搭建说明。不过还有其他各种工具，比如 Graft，它会构建当前工作目录的图景，并以一文件夹相互链接的 markdown 文件形式写进你的仓库——每个系统、API 或概念对应一个节点。仅就初始化仓库而言，Graft 显示它可以便宜多达 4 倍、快多达 3 倍，正确性持平甚至无损，因为它避免了反复探索（见表）。

GitHub - NanoNets/Graft: Turbocharge Claude Code, Cursor, Codex, Gemini & every coding agent…

效率是一项 162 次运行的受控基准（同一 Agent、同一套文件工具，只有上下文不同）。正确性用 SWE-bench Verified、由官方评测框架打分；Graft 解决了测试实例的 66%，而冷启动的 Claude Code 为 54%。效率方法 ↓ · SWE-bench ↓ · 逐仓库数字 ↓ 来源：https://github.com/nanonets/graft

Graft 的安装很简单：

图片来源：https://github.com/nanonets/graft

如何向上下文窗口添加数据？

LLM 内部包含大量预学到的信息，但最重要的是，它并不知道你使用场景的信息。你的笔记、文档、代码、研究以及组织知识，往往是你的场景所需要的。在本节中，我们将探索把 LLM 与外部知识连接起来的工具。我们会考察各种方法，让海量信息对你的 LLM 变得有用。

挑战不仅在于构建一个更好的模型，还在于在正确的时机把正确的知识提供给模型。

数据处理与可视化组件概览。

抽取：把输入文本转化为结构化知识

在大多数使用场景中，信息是以非结构或半结构化的文档存储的，例如 PDF、Word 文件、PowerPoint 演示文稿、Excel 表格、HTML 页面和图片。在从这些来源抽取知识之前，我们首先需要把它们转成 LLM 能可靠处理的格式。这时候像 MarkItDown 和 Anydoc（arXiv 论文）这样的工具就很有用了。两者都是开源 Python 工具，能把多种多样的文件格式转换成 Markdown**。** 而 Markdown 是原本异构的文档在 LLM 面前更友好的表现形式。下表中对各种方法连同其准确率做了比较。如果你不想用 Python 快速试跑一下，就在这里试试 Anydoc 的在线工具。

AnyDoc 基准测试，

GitHub — microsoft/markitdown: Python tool for converting files and office documents to Markdown.

GitHub — firecrawl/anydoc: Convert Word, PowerPoint, Excel, OpenDocument, RTF, EPUB, CSV, and PDF…

一旦文档被转换成文本，就可以用 LangExtract 借助 LLM 从中抽取结构化信息了。与其让 LLM 反复解读整份文档，你可以定义想抽取哪些信息，然后让 LangExtract 产出结构化记录，包括实体、关系以及其它相关事实。请注意，LangExtract 这一步并非必须，但它能很好地完成从非结构化文件到结构化格式的过渡。把这两者合并起来，就组成了流水线中非常实用的第一步：

文档 → MarkItDown/Anydoc → LangExtract → 结构化知识

举个例子，与其给 LLM 一份 100 页的 PDF 然后问**“哪些是重要的实体和关系？”**，不如先用 MarkItDown 把文档转换成一致的文本表示，之后 LangExtract 就能系统地识别并结构化你所需的信息。

Introducing LangExtract: A Gemini powered information extraction library

GitHub — google/langextract: A Python library for extracting structured information from…

结构化：构建知识图谱

到这一步，我们已经从一个库里拿到了结构化信息（例如 LangExtract），现在可以用它来构建我们知识更有用的表示。在把这些信息变成知识图谱之前，值得先思考知识本身是如何被表示和组织的。这时由 Google 开发的 开放知识格式（Open Knowledge Format，OKF） 登上了舞台。OKF 提供了一种用普通 Markdown 文件来表示知识的简单方式，这些文件带有结构化元数据、概念之间的链接、来源（provenance）以及新鲜度信息。其理念是：知识不必被锁死在某个特定数据库或应用里。相反，它可以被表示成一种人类、LLM、搜索系统、知识图谱以及其他工具都能消费的可读格式。这个 GitHub 仓库有 8000+ star 和 700+ fork。

Stop Wasting LLM Tokens: Building a Self-Updating Codebase Knowledge Graph with OKF

How the Open Knowledge Format can improve data sharing | Google Cloud Blog

GitHub — GoogleCloudPlatform/knowledge-catalog: Google Cloud Knowledge Catalog Tools and Samples

因此，OKF 定义了知识可以被如何表示和组织，这与知识图谱不同——知识图谱定义的是这些知识之间的关系可以被如何探索。

这就把我们带到了 Graphify。它能把信息变成真正可查询的知识图谱。区别在于：OKF 定义了知识如何被表示和组织，而 Graphify 定义了这些知识之间的关系可以被如何探索。Graphify 是个热门工具，拥有 10.4 万+ star 和 1 万+ fork。 用法非常简单：在 AI 编码助手里输入 /graphify，它就会把你整个项目（代码、文档、PDF、图片、视频）映射成一个你可以查询的知识图谱，而不必再去文件中 grep。见下方代码块了解如何安装 Graphify 并运行。请注意，在我这台只有 16GB 显存、120K 上下文窗口并跑着 google/gemma-4-26b-a4b-qat 的本地机器上，它先是耗尽 token，压缩之后又花了 2 个多小时才处理完 bnlearn 库。提示：开始之前先清理一下目录。

# 安装
pip install graphify

# 启动你的 claude 会话
claude

# 启动 Graphify
/graphify

GitHub — Graphify-Labs/graphify: Turn any codebase, with its docs, SQL schemas, configs, and PDFs…

每个节点都是一个概念；颜色表示检测到的社区（communities）。

Graphify 的 GitHub 主页这样描述：

  • 免费的代码地图，完全本地运行。 代码用 tree-sitter AST 解析：确定性强、不需要 LLM、不会有什么内容离开你的机器。（文档、PDF、图片和视频则使用你助手的模式）
  • 每条边都有解释。 每个连接都被标记为 EXTRACTED（源码中显式存在）或 INFERRED（推断得出），这样你能区分哪些是直接读到的、哪些是推断出来的。
  • 不是向量索引。 无需嵌入（embeddings）、无需向量库：这是一个你可以遍历的真实图谱。问一个问题、追踪两样东西之间的路径，或者解释一个概念。

什么时候用 Graphify？ 当信息之间的"关系"与"信息本身"同等重要时，它尤其有用。也就是说，它不把文档当作孤立的文本块，而是把实体及其连接表示成一张图。这为探索知识提供了一种更结构化的方式，也能给 LLM 应用提供一份更丰富的、它们所需处理的信息表示。

存储：数据库与搜索

处理嵌入（embeddings）时，向量数据库需要一种高效的办法来查找与查询相近的向量。HNSW（Hierarchical Navigable Small World，分层可导航小世界） 是实现这一目标使用最广泛的方法之一。HNSW 不是把查询与每个存储向量都比较，而是构建一个基于图的索引，让搜索能快速导航到相近的向量，在速度、内存占用和检索准确率之间取得良好权衡。因此 HNSW 是一种索引算法，而不是数据库本身。对于更小、完全本地的应用来说，你不一定需要专门的向量数据库。SQLite 是一个轻量、无服务器的关系型数据库，它能存储这些嵌入（数值向量）。合在一起，这说明向量搜索并不总是需要复杂的数据库基础设施。对许多应用而言，一个轻量数据库加上一个高效的向量索引，就能为本地语义搜索和 RAG 提供所需的一切。

GitHub — nmslib/hnswlib: Header-only C++/python library for fast approximate nearest neighbors

检索：构建生产级 RAG

LLM 不可能在你每次提问时都把整个知识/数据库读一遍。想想上一节讲的那个受限的上下文窗口。即便你拥有非常大的上下文窗口，把所有可得信息都发给模型也是低效、昂贵，而且常常适得其反的。因此，挑战在于先检索出相关信息，然后把这份上下文提供给 LLM。

这正是 检索增强生成（Retrieval-Augmented Generation，RAG） 背后的思想。RAG 系统会先在外部知识库中搜索与用户问题相关的信息，把检索到的内容加进提示词，然后让 LLM 基于这些信息生成答案。这让 LLM 能够处理私有、领域特定且持续变动的信息，而无需重新训练模型。

实现 RAG 的方式有很多，从简单的向量搜索和关键词检索，到混合搜索、重排、元数据过滤，以及基于知识图谱的检索。每种方法各有长处，但构建一套完整的 RAG 流水线，需要把文档处理、索引、检索和生成结合起来。

一个流行的工具是 RAGFlow，它拥有 8 万+ star 和 1 万+ fork。 RAGFlow 把这些组件汇聚到一个开源平台中，让构建和试验完整 RAG 应用变得容易得多。它接手处理了流水线中的大部分工作——从文档处理和索引，到检索和生成——而无需你从零实现整个 RAG 技术栈。

GitHub — infiniflow/ragflow: RAGFlow is a leading open-source Retrieval-Augmented Generation (RAG)…

可视化

一旦信息被抽取并连接起来，可视化就提供了另一种理解它的途径。D3Blocks 提供交互式网络可视化，能展现所生成知识结构中的关系、聚类和重要节点。它与 Graphify 的一点不同在于：其关系、节点和边都是完全可配置的。这让你能在不必背负额外开销的情况下创建知识图谱。尤其是 RadialGraph，它很适合围绕某个中心节点探索网络，而 D3graph 则提供更通用的交互式网络表示。D3Blocks 拥有 750+ star 和 65+ fork。

from d3blocks import D3Blocks

# 初始化
d3 = D3Blocks(frame=False)

# 示例数据集
df = d3.import_example('socialmedia')
df = df[0:2000]

# radialgraph
d3.radialgraph(df, expand_all_on_load=False, edge_minmax=[0.5, 20])

# radialgraph
d3.d3graph(df)

D3Blocks: The Python Library to Create Interactive, Standalone, and Beautiful D3.js Charts

RadialGraph 示例。用 D3Blocks 创建的图。

RadialGraph: A New Way To Explore Large Networks Without the Hairball.

下方是 D3Graph 的一段动画 GIF。

D3Graph 示例。用 D3Blocks 创建的图。

How to Turn Any Network Into an Interactive Knowledge Graph To Discover Hidden Insights.

这些工具可以被看成同一流水线的不同阶段。LangExtract 把非结构化文档变成结构化信息；Graphify 把那些信息连接成知识图谱；RAGFlow 让相关知识与 LLM 相通；而 D3Blocks 让底层的关系变得可见。

文档 → LangExtract → (Graphify) → RAGFlow → D3Blocks → 理解

Claude 提示与技巧

如果你是 Claude 用户，这里有一些很棒的小技巧，能让你从新手进阶为高手。最棒的几条是：

  1. /init 每个新项目都用一次初始化开始。它会添加项目结构、分析你的代码库，并写出全面的 CLAUDE.md 文件，内含项目摘要、架构决策、编码规范、关键依赖和搭建说明。
  2. /memory 如果你有任何（个人）约定（函数式编程模式、错误处理等），把它们加入 memory，之后就不用再重复了。
  3. /model 在不同模型之间切换。
  4. /fast 用同一个模型切换出更快的响应，只是为速度而非深度做了优化。适合头脑风暴、小重构和调试。
  5. /review 系统地审查代码，找出 bug、逻辑错误、代码清晰度、性能问题以及安全隐患等。
  6. /btw 工作中不要打断 Claude 会话；用 btw 并行地提问。
  7. /compact 在不丢失信息的情况下，自动为你的上下文窗口腾出空间。它会自动总结并保留关键决策、编码部分等内容。
  8. /cost 时刻留意你花了多少钱。
  9. /pr_comments 针对代码评审（pull request）：每个 PR 都会把评论直接带进你的 Claude 会话，让你完全清楚评审者指出的问题。
  10. /clear 一种软重置，会清掉对话但保留你的设置不变。
  11. /doctor 当你的 Claude 环境感觉出了问题时的求助工具。
  12. /help 列出全部 Claude 命令并附简短说明。

更多细节可以在这里找到：

I Wasted 6 Months Using Claude Code Wrong. Here Are the 14 Commands That Changed Everything.

收尾总结

LLM 最大的挑战不再是四处找关于它们的信息，而是跟上节奏，并且越发重要的是——一开始就弄清楚该给模型提供哪些信息。随着上下文窗口扩大、应用变得更复杂，有效的上下文窗口管理正成为 LLM 工程的核心部分。挑战不仅在于往上下文里塞进更多信息，更在于挑选正确的信息、对它们加以有效结构化，并持续管理模型在每个步骤到底需要什么。我希望这篇综述能让你对上下文窗口管理不断演进的方法形成一种实操性的理解——从系统提示词和指令，到检索、记忆、压缩与工具使用。 这个领域前进得很快，但有一条原则始终重要：更好的上下文并不必然意味着更多的上下文；它意味着在正确的时机给出正确的信息。

注意安全，保持冷静（Be Safe, Stay Frosty）。

Cheers E.

希望你喜欢这篇博客。欢迎关注我，我会写更多数据科学的内容！也请务必亲手试试这篇博客里的示例，能帮你学得更快、理解更深、记得更牢。

延伸阅读

智慧物流 订单配送规划海报

参考资料

  1. Andrej Karpathy 关于 LLM 操作系统（LLM OS）的帖子——Andrej Karpathy
  2. Andrej Karpathy 的课程：https://karpathy.ai/zero-to-hero.html
  3. E. Taskesen，《构建个人 Agentic 系统的分步指南》，2026 年 6 月，Data Science Collective (DSC), Medium.
  4. Asgeirtj，System Prompts Leaks。从 AI 助手与 LLM 应用中提取的系统提示词合集，可用于研究系统级指令如何塑造模型行为。 GitHub
  5. Andrej Karpathy Skills，一套基于 CLAUDE.md、用于落实 Karpathy 氏改善编码 Agent 行为原则的实现：编码前思考、简洁优先、外科手术式改动、目标驱动执行。 GitHub
  6. Anthropic，Agent Skills，官方可复用 skill 合集，展示专门的指令、脚本和资源如何扩展 AI Agent。 GitHub
  7. Graft，https://github.com/nanonets/graft。 GitHub
  8. Headroom AI，开源上下文优化与压缩工具，用于减少 LLM 应用中不必要的 token 使用。 GitHub
  9. Abid Abdul Gafoor，《我如何用这些方法把 Claude Code Token 用量减少 90% 以上》，2026 年 4 月，Medium
  10. Mangiucugna，json_repair，用于修复 LLM 和其它自动化系统生成错误 JSON 的 Python 库。 GitHub
  11. Microsoft，markitdown，把文件和 Office 文档转换成 Markdown 的 Python 工具。。 GitHub
  12. Jiawei Lin 等人，AnyDoc：通过大规模 HTML/CSS 数据合成与高度感知强化优化增强文档生成，arXiv，2026 年 3 月
  13. Anydoc，把 Word、PowerPoint、Excel、OpenDocument、RTF、EPUB、CSV 和 PDF 转成干净的 Markdown。用 Rust 构建，带 Node.js 和 Python 绑定。 GitHub
  14. Google，LangExtract，开源 Python 库，用 LLM 从非结构化文本中抽取结构化信息，并带来源锚定。 GitHub
  15. Google，《Introducing LangExtract：一个由 Gemini 驱动的信息抽取库》
  16. Google Cloud，开放知识格式（OKF），Google 开放知识格式介绍。 GitHub
  17. Google Cloud Platform，Knowledge Catalog，内含 Google Cloud Knowledge Catalog 工具和示例的仓库。 GitHub
  18. Udaykiran Estari，《停止浪费 LLM Token：用 OKF 构建一个自更新的代码库知识图谱》，Medium
  19. Udaykiran Estari，《Agent 记忆标准化：用谷歌 OKF 构建一个自更新的代码库知识图谱》，Medium
  20. Graphify Labs，把代码库、文档、schema、PDF、图片等其它信息变成一个可查询知识图谱的工具。 GitHub
  21. Infiniflow，RAGFlow，整合文档处理、检索与生成的开源检索增强生成平台。 GitHub
  22. Taskesen, E. D3Blocks：用于创建交互式、独立、美观 D3.js 图表的 Python 库，Data Science Collective，Medium.
  23. Taskesen, E. RadialGraph：一种不绕成毛线团就能探索大规模网络的新方法，Data Science Collective，Medium.
  24. Taskesen, E. 《如何把任何网络变成一个交互式知识图谱，以发现隐藏洞见》，Data Science Collective，Medium。
  25. Taskesen, E. D3graph，交互式网络可视化库。 GitHub
  26. Taskesen, E. D3Blocks，用于创建交互式 D3.js 可视化的 Python 库。 GitHub
  27. Shanraisshan，Claude Code 最佳实践，社区维护的 Claude Code 工作流、命令、Agent、skills、hooks、MCP 服务器及其它技巧合集。 GitHub
  28. Nelson F. Liu 等人，《迷失在中间：语言模型如何使用长上下文。》 2024 年 2 月，MIT Press Direct。