👋 Welcome

前言 大模型有三个先天局限：知识有截止日期、无法访问私有数据、信息不足时可能幻觉。 RAG 的思路很简单：先从外部知识库检索相关资料，再让模型基于这些资料回答。 本质上就是给模型配了一个「外挂知识库」。 本文按 RAG 的完整流程展开——切块、向量化、存储、检索、生成。 1. 总览：两阶段流水线 RAG 可以拆成一条清晰的流水线，分两阶段： 离线阶段。提前把知识库里的文档全部处理一遍，与用户无关： 文档 → 分块 → 向量化 → 存入向量库 分块：长文档切短，既保证每块信息密度够高，又不超出 Embedding 模型的输入上限 向量化：把每块文字转换成一串数字（向量），语义相近的文字向量坐标也相近 存入向量库：把向量存起来，后续按相似度查找 在线阶段。用户提问时才触发，链条很短： 提问 → 向量化 → 相似度搜索 → 拼进提示词 → LLM 生成 向量化：用同一个模型把问题也转成向量 相似度搜索：在库里找和问题向量距离最近的 K 个文档块 拼进提示词：把搜到的文档块和原问题组装成一条完整的提示词 LLM 生成：模型基于检索到的资料回答问题 两阶段设计的关键在于，重活（向量化全部文档）在离线做完了，在线只需向量化一个问题、做一次近邻搜索，延迟很低。 本质上，RAG 把检索问题变成了数学问题。你不再需要理解文档内容来搜索——只需算向量之间的余弦相似度，在向量空间里找距离最近的几个点。 2. 分块：化整为零才搜得准 分块的核心矛盾很简单：块太大则信息稀释，块太小则上下文割裂。下面四种策略，从简单到复杂，覆盖了绝大多数场景。 2.1 固定大小分块 按字符数或 token 数等距切，最简单的方案，三行代码搞定。可以在相邻块之间加 overlap（滑动窗口），防止关键句被边界切断。 固定: [=======|=======|=======|=======] 带重叠: [=======|===]→[===|=======|===]→ 优点是实现零成本、chunk 大小均匀方便批处理。缺点也很明显：可能从句子中间切断，无视表格、列表等文档结构。适合日志、纯数据等结构均匀的文本，或作为快速验证的基线。 2.2 递归字符分割 这是工业界公认的最佳起点，80% 的通用 RAG 场景用它就够了。原理是用优先级递减的分隔符逐层尝试切割： 段落("\n\n") → 换行("\n") → 句号("。") → 词边界(" ") → 字符("") 先尽量在段落边界切，不行退到句子，再不行退到词——始终落在最自然的断点上。 ...

前言 过去两年，AI Agent 经历了从概念到落地的快速演进。编码 Agent 率先成熟——Claude Code、Codex、OpenCode 等工具已经成为很多开发者的日常。 这些系统的底层架构有很多共通之处：LLM 调用、工具执行、上下文管理、会话持久化、扩展机制……但如果你想深入理解一个 Agent 是怎么跑起来的，去读 Claude Code 或 OpenCode 的源码并不现实——前者闭源，后者规模庞大且耦合度高。 pi 是一套开源的 Agent 开发包，涵盖 LLM 抽象、Agent 引擎、终端 UI 等核心能力，其中的编码助手只是它的一种产品形态。它适合作为学习 Agent 架构的入口，原因很简单：pi 的设计哲学是最小核心 + 扩展优先。Agent Loop、Context、工具、会话树和扩展系统这些基础层都放在明处，子代理、Plan Mode、权限确认这类更具体的“做事方式”则不硬塞进核心，而是留给扩展去实现。 这篇博客会逐层深入 pi 的架构，不只看"能做什么"，更关注"为什么这样设计"。 1. Agent Loop：LLM 与工具的循环 1.1 Tool Call 循环 当 LLM 的回复中包含 ToolCall 时，循环不会停止。pi 会： 从 LLM 回复中提取所有 ToolCall 执行工具，拿到 ToolResult 把 ToolResult 加入上下文 再次调用 LLM，让它看到工具结果并决定下一步 这个循环会一直转，直到 LLM 的回复中不再包含 ToolCall 为止。这就是 Agent 的核心——LLM 不只是生成文本，它通过工具与外部世界交互，根据结果自主决定下一步操作。 ...

Agent上下文管理。

探寻AI时代下，人的重点转移。

Cursor中Rules、Commands、Skills、SubAgents介绍和使用场景。