到这里，索引与查询优化这个阶段就讲完了。从第 04 篇的索引模型，到第 11 篇的慢查询排查闭环，中间穿过了索引类型、ESR 原则、explain、覆盖查询。这些不是孤立的知识点，而是一条连贯的主线—

线上 MongoDB 慢了，最本能的反应是「加个索引试试」。但这是排查慢查询里最坏的开局——既可能加错索引（没解决根因），又可能加多索引（拖慢写入）。正确的做法是先定位慢查询，搞清楚它慢在哪一层，再有

前面两篇讲了索引类型和 ESR 原则，但所有这些设计到底有没有生效，只有一个验证手段：explain。问题是，很多人用 explain 的方式是「跑一下，看有没有 IXSCAN 字样」，看完就走了。这

上一篇讲 explain 时，提到一个理想状态：totalDocsExamined = 0。意思是查询根本没回表读文档，所有需要的数据都在索引里拿到了。这个状态叫覆盖查询（covered query）

用于 AI Agent 服务的项目模版，基于 FastAPI + LangChain + LangGraph 构建，支持多子代理协作、路由代理协作和人工审批流程。

上一篇把索引讲成了 WiredTiger 里的独立 B-tree，回答了「索引是什么、为什么查得快写得慢」。但那只解决了索引的「共性」，没解决最实际的问题：我的查询到底该建哪种索引。 MongoDB

find 被讲成「查文档」，但一条查询要从 driver 穿过网络层、解析、优化器、执行计划，再落到 WiredTiger 的 B-tree。本文讲清楚这条链路每一段在做什么，以及慢查询最可能卡在哪。

复合索引是 MongoDB 性能优化里最常用、也最容易用错的工具。很多人建复合索引的方式是「查询用到哪几个字段，就按想到的顺序建一个」，结果发现索引只用了第一个字段，查询照样慢。问题不在「有没有建索引

刚从 MySQL 迁到 MongoDB 的人，最容易把关系建模那一套照搬过来：每个实体建一个集合，用 userId、orderId 这种字段做关联，查询时再 $lookup 拼。这种写法能跑，但它把

「MongoDB 不需要建表，加字段直接存就行」——这句话是 MongoDB 最出圈的卖点，也是最容易被误解的一条。它听起来像是「结构可以随便长」，但真实情况是：schemaless 不是「没有结构」

MongoDB 的索引被讲成「给字段建个索引就快了」，但底层它是 WiredTiger 里独立的一棵 B+-tree。本文讲清楚索引条目长什么样、为什么查得快写得慢，以及索引数量怎么放大写入成本

模型本身只知道训练时见过的知识。 如果你问它最近发生的事情，或者企业内部文档里的内容，它通常并不知道。更麻烦的是，它有时不会直接说“不知道”，而是编一个看起来很像真的答案。 这就是常说的幻觉。 RAG

Runnable 是 LangChain 里统一的执行协议。 Prompt、Model、Output Parser、普通函数、分支逻辑、并行逻辑，都可以被看成 Runnable。 先记住一句话：Run

langchain 提供的 InMemoryVectorStore 适合学习 RAG 流程，但它的数据只存在内存里。 真实项目需要一个可以持久化、可以索引、可以被多个服务连接的向量数据库。Milvus

该篇解决 Agent 开发里最基础的问题：怎么用 Python 通过 LangChain 调用一个聊天模型。 先抓住主线： Agent 看起来复杂，但底层离不开模型调用。后面学 Tool、RAG、Me

感知模块第三讲：Agent 探索陌生代码库时，grep + read + follow imports 比 RAG 更直接。渐进发现的三阶段循环，本质是信息觅食理论在 Agent 场景的工程化。

感知模块最后一讲：多模态融合的核心不在模型层，在数据形态层。工程师要做的不是调 vision API，而是判断每种数据该变成什么形态进入 Agent。

当你使用claude -c 命令的时候 claude code agent 可以自动加载出来最近一次session的完整对话记录，你有没有好奇 claude code agent是怎么回忆起来的

大家好，我是十三！欢迎来到十三Tech。 上一讲聊了上下文分诊——信息进 Context 之前先排优先级。这一讲接住它的下一阶段：信息进来之后，Agent 只要跑得足够久，上下文一定会膨胀。 对话历史