AI 知识地图：五条线路的当前理解
AI 主题文章按五条知识线重组：每条线不是链接清单，而是当前理解的蒸馏。完整时间流见 AI 归档页。
| 文章规模 | 40+ 篇（完整时间流） |
|---|---|
| 知识线 | 5 条（见下图） |
| 阅读重心 | LLM 原理 → RAG → Agent 工程 |
| 最新落点 | Agent 流程：循环、恢复与执行边界 |
| 开放问题 | 4 个（见文末） |
这是一页 wiki 概念页。AI 板块的文章散落在时间流里，本页按知识线重组——每条线先给“当前理解”（跨文章蒸馏的判断），再给文章锚点。本 wiki 集合本身就是“知识管理”那条线的实践产物。
知识线全景
mindmap
root((AI 知识地图))
LLM 原理
工作原理入门
参数量演化
经典课程笔记
RAG 与检索
工程深度
独立编码与交互打分
精排输入格式与评分位置
图增强检索
grep 派检索
搜索即代码
证据覆盖评测
表格证据与结构化查询
Wiki 知识沉淀与 OKF
Agent 工程
概念体系
Harness 工程
Loop 工程
长程 Agent
Spec 驱动开发
有类型的语义判断
模型接口与上下文责任
会话历史与执行环境生命周期
流程控制与宿主扩展
Claude Code
源码架构
多 Agent
大代码库
编排实践
行业观察
产品形态
商业模式
组织效率
模型趋势与选型
五条线路的当前理解
LLM 原理：地基线，已封顶
LLM工作原理 和 GPT 参数量的故事 构成主干，早期还有一批课程笔记（机器学习概念、Stanford ML、Stanford CNN 等）。
RAG 与检索：取回证据与复用理解
主干是 RAG 的工程深度（切分、检索、排序、评估、幻觉防护），延伸出 GraphRAG vs LightRAG 的图增强路线。但更有张力的反而是两篇“反 RAG”文章：Claude Code 为什么用 grep 而不是 RAG 和 把搜索当代码来写。
当前理解：检索方式与知识沉淀是可以组合的两个维度。Embedding RAG、关键词搜索和 grep 决定怎样取回内容；Karpathy 的 LLM Wiki 模式决定是否将跨来源的理解维护成持久页面。Wiki 页面仍可被检索，原始资料仍可用于复核。比较方案时，需要同时说明检索方式和检索对象，避免把“预先整理知识”误当成“从此无需检索”。
共同格式把知识交接的验收补齐了。 从 Skill 文件理解 Google OKF将维护方式、文件约定与消费行为分开：LLM Wiki 负责沉淀理解，OKF 统一产物的字段和引用，具体工具负责使用这些信息。结合下文的证据覆盖评测，可以将知识库验收拆成三项：整理后是否保留必要证据，跨工具交换是否保留字段与链接，消费时是否实际检查来源与适用状态。前两项通过并不自动保证第三项；最小文件合规也不能证明可选的核验信号已填写，或计算契约已经得到实现。分别检查这些承诺，比只检查 Markdown 能否打开或回答能否生成，更能定位知识交接中的损失。
比较路线之前，先固定任务需要的知识。 Ragas 与 TREC 的评测思路把标准构建、覆盖判定和失败定位分开。用于比较不同检索与知识沉淀组合时，评测单位应尽量独立于文档数量和切片方式：同一条必要知识可能由原文 chunk、代码片段或 wiki 页面提供，来源改变不应直接改变分母。先确认必要 Evidence，再维护各类来源的支持关系，才能检查不同路线是否把同一组知识交给了 Agent；固定映射适合高频回归，语义评判辅助发现新来源与复核争议，生成答案的完整性再单独验证。
证据的完整性还取决于关系和数据范围。 Excel 与 Markdown 表格 RAG 方案调研对照 Unstructured、Docling、RAGFlow、LangChain、LlamaIndex 和 Azure 的文档与源码，展示结构切块、行级文档、摘要引用和混合检索各自承担的环节。结合证据覆盖评测，检查单位不能停在“命中这一行”：表头、单位、适用范围和例外可能共同构成必要 Evidence；子块命中后是否补齐这些内容，应在最终交给模型的上下文中验证。对于全量筛选与统计，还必须验证查询覆盖范围和计算口径，相关性 top-k 无法证明集合完整。由此，检索路线的比较应同时考察证据语义、依赖关系和集合范围，分别定位解析损失、召回遗漏与计算错误。
选型应逐层核对能力，再比较组合后的证据交付。 支持输入格式、输出表格结构、保留业务上下文、执行完整集合计算，是四个不同承诺。比较解析器与检索框架时，应先固定各自负责的环节和实际版本，再以同一组必要证据检验完整链路；产品层的“支持表格”或摘要中的业务描述，不能直接证明上述承诺都已兑现。
候选规模与表示粒度要一起衡量。 Bi-Encoder、Cross-Encoder 与晚交互的比较解释了单向量复用、联合编码和多向量匹配的不同代价。结合证据覆盖评测与表格上下文的讨论，相同的候选条数并不意味着相同成本，也不意味着证据同样完整：切片长度、Token 向量数量和上下文补齐都会影响结果。比较方案时，应同时记录实际计算与存储成本、必要证据覆盖和最终上下文完整性；保留更多向量或增加候选，仍不能替代对缺失表头、单位和例外条件的核查。
精排的计算预算与评分含义需要分别验收。 Qwen3 Reranker 如何打分说明，相关性分数不仅依赖权重，还依赖任务序列化、读取位置和标签归一化。结合联合编码的成本讨论，同样数量的问题—文档对意味着相近的计算工作量，却不保证正在执行同一种判断；结合证据覆盖评测，即使输入和评分规则一致，也仍需验证最终交付的知识。因此，精排验收应分别检查候选预算、模型输入与评分规则、最终证据覆盖，避免把“请求数量相同”或“分数范围正常”当成判断能力保持不变的证据。
Agent 工程：本板块当前的主线
从概念（Hello-Agents）到工程纪律：Harness Engineering（agent 从能跑到跑稳）、Loop Engineering（瓶颈从 prompt 迁移到 loop）、Agent Loop 工程，加长程任务的系列研究（Anthropic、OpenAI 的 harness 工程、Context Engineering）。
当前理解：行业的瓶颈已经从“模型够不够聪明”迁移到“围绕模型的工程系统够不够稳”——harness、loop、context 三层工程纪律决定 agent 的实际产出。这条线直接影响本博客的维护方式：AGENTS.md 加 skills 的组合就是 harness 工程的个人实践。
Spec Kit 与 Codex 的开发流程把这条线推进到需求与验收：Spec 确定行为，Plan 设计方案，Tasks 拆解并推进实现，Validation 核对证据。虚构相册案例将同一组验收标准贯穿四步，并演示规则变化后怎样修订与复验；独立 reviewer 是验证阶段的可选增强。
交付记录与工具门禁分别承担责任。 Spec Kit 核心没有强制的全局完成标志；未配置额外门禁时，任务未补勾本身不会阻止合并，但最好按实际完成与验证结果同步状态。结合知识库的当前状态维护，收尾记录应让后续协作者能够区分已接受的结果、尚未验证的判断和明确延期的工作；工具允许继续，并不能证明这些信息已经交接完整。
跨主题的维护原则：LLM Wiki 解决“当前知识放在哪里”，Spec 驱动开发解决“当前承诺是什么”，独立验证解决“承诺是否兑现”。三者都需要区分历史材料、当前依据和执行证据；增加文档或 agent 数量，不能替代这三个边界。选择自动化范围时，优先固化有明确验收场景、能够取得证据的步骤，再扩大编排。
流程与知识独立维护，也需要一起回归：Skill 与 OKF 的配合区分了知识复用与交换约定：多个工作流引用普通 Markdown 就能共享定义，OKF 进一步统一字段和引用的语义。结合 Spec 的变更验收原则，回归记录应同时保留技能版本和所用知识版本：相同流程可能因口径更新而产生不同结果，相同知识也可能被新流程错误使用。将这两类变化分开记录，才能定位应修订步骤还是重新确认依据。
并行协作还需要明确引用对象：Spec Kit 的递增编号可能在不同工作区重复，时间戳命名可以减少碰撞；团队应使用完整需求路径或关联 Issue 定位工作，并用代码版本关联验证证据。目录前缀帮助组织材料，不能单独证明任务唯一、先后依赖或验收结果适用于当前实现。
工具接入要区分协议约定、业务契约和客户端策略：MCP 与 REST 对比以 2026-07-28 规范串起 server/discover、tools/list 和 tools/call：每个请求独立声明版本与客户端能力，发现方法是否调用由客户端需求决定，工具定义同时描述输入与可选的结构化输出。Memos 自托管实录则展示适配层如何复用业务 API。接入时应分别确认协议版本、工具 schema 和 Host 的使用策略；程序读取业务结果依赖输出契约，不能从一次响应样本推断固定结构，也不能把某个客户端的启动流程当成所有实现的协议要求。
模型接口兼容之后，还要保留可回放的验证依据。 模型没有 HTTP 路由从 token 计算讲到输入适配和服务契约，说明接口名称并不属于模型权重。结合 Qwen3 Reranker 的格式退化案例与 Spec 的版本化验收，迁移不仅可能替换模型，还可能把模板、截断和历史恢复的责任从客户端移到服务端。因此应记录实际上下文、输入与输出处理配置及任务结果；托管会话 ID 和相同的请求 JSON，都不能单独证明新服务恢复了等价输入。先定位责任在哪一层发生变化，才能决定该修复会话迁移、部署配置还是任务策略。
回放还要区分消息语义、实际序列与界面文字。 从 messages 到 token IDs 的实测显示，同一份消息会因模板开关和截断设置而改变最终序列，解码过滤也只改变显示。结合 API 的上下文托管与精排的评分位置，跨平台迁移应保留结构化消息，平台内复现则还需要模板、tokenizer 版本与实际 IDs。仅保存聊天气泡难以定位格式问题；仅保存旧 IDs 又不能直接迁移到另一套词表。
任务恢复需要同时验证上下文和执行环境。 vLLM 与 Responses API区分历史存储、工具执行和循环控制，并展示会话历史仍在而临时 Python 容器已经销毁的情况。结合 CubeSandbox 的运行环境分层与前述输入回放，可以把恢复验收拆成模型能否重建有效上下文、工具能否取得所需文件与运行状态、控制器能否识别已完成和待处理动作。共享 Redis 只解决其中的历史寻址；恢复聊天记录或恢复容器都不能单独证明任务能够安全续跑。跨副本、重启和失败重试的验证，应以实际下一步能否继续以及是否重复执行动作为准。
恢复能力与流程约束需要交叉验收。 xyz 的 Skill、Hooks 与流程控制展示了宿主执行协议与外部程序编排的不同调用方向。结合会话、环境和执行状态的分工，可以把回归分成两个维度：在压缩、重启或换工作区后，是否仍指向正确任务并避免重复动作；在检查失败或模型漏调接口时，下一项动作是否仍可能发生。前者验证恢复，后者验证控制点覆盖。用这两组故障分别检验实际行为，才能判断应补持久化与归属校验，还是调整执行权限和流程接口；仅增加 Hooks、状态文件或换用 SDK 都不能同时证明两项能力。
流式交互需要分别验证传输和消息处理：同一个 HTTP 响应可以陆续承载多个 SSE 事件，MCP 再定义事件中的进度通知和最终结果。界面迟迟不更新时，应分别检查服务端与代理是否及时刷新、客户端是否增量解析、Host 是否消费了进度通知；HTTP 已经收到字节，并不等于用户已经看到业务进展。
操作发现与业务决策应分别验收：HATEOAS 与 MCP 的对照说明，服务端提供当前可用动作或工具目录，可以减少客户端硬编码，却不会自动赋予调用方业务目标。结合 Harness 的验收思路，应分别验证“能发现并正确调用”“当前对象允许执行”和“所选动作符合用户目标”；前一项通过不能替代后两项。传统程序依赖预先约定的语义，模型可以从描述推断用途，但推断结果仍需在实际任务中验证。
有类型的判断把验收进一步拆成三层：Jev 的接口与精排实践展示了自然语言材料如何变成代码可直接消费的选项、概率和分数。结合工具契约与证据覆盖评测，平台应分别检查返回结构是否合法、局部语义判断是否正确、组合后的工作流是否交付了必要证据或完成了目标。精排分数改善只能说明固定候选中的顺序变化，无法单独证明召回完整或答案完整；同样，工具选择合法也无法证明动作得到授权。将这三层的失败分别记录，才便于判断应调整接口、问题定义，还是召回与控制流程。
模型级效率要换算成工作流的实际代价：Jev 的 SciFact 对照案例中，排序质量更高，却因逐候选调用等实现条件付出更长等待与更高估算费用；绝对阈值过滤又带来证据损失。结合证据覆盖评测，平台选型应在相同候选与覆盖目标下比较整次业务请求，并把排序收益、证据保留和调用预算分别记录。一个局部接口更易消费，不能代替这三项业务验收。
Claude Code 与工具链：从使用到编排
使用层（powerup 教程）→ 原理层（源码架构、大型代码库、多 Agent）→ 编排层（Multica 三 CLI 流水线）。
当前理解：单个 coding CLI 的能力已经够用，下一个台阶是多 agent 的编排与管理——任务分派、进度追踪、互相复查。Multica 实验证明了三棒流水线可行，但 macOS GUI 环境和代理问题说明这条路还没铺平。
行业观察：低频但校准方向
Manus 观察、大模型公司的收入幻觉、AI Coding 到组织效率。这条线文章少，作用是给技术判断加商业现实感：产品收入和项目收入要分开看，agent 落地最终是组织问题。
模型趋势用于筛选候选，迁移验收需要回到同一组任务。 2026 年 10 月模型趋势报告把能力、价格、参数、速度和人类偏好分开观察，并检查跨期评分口径。结合模型接口的输入回放和 Jev 的工作流成本案例，可以把选型拆成两步：先用榜单缩小候选，再固定任务、输入与上下文处理、服务配置，比较任务成功率、证据覆盖、整次请求费用和延迟。评分方法或服务条件改变时，应重新建立对照，不能仅凭同名指标推断进步；单价、总参数量和最大上下文窗口也不能替代业务验收。这让行业快照成为实验入口，并把最终决策保留在可回放的工程证据上。
开放问题
本博客的 wiki 集合正在验证知识沉淀；检索原文、检索 Wiki 与两者组合，应使用同一组问题和必要证据比较。OKF 调研进一步引出交换实验：导出少量概念后，换一个消费者检查来源、链接与过期信息能否保留并被使用。当前仍待实测；持续观察枢纽更新、lint 闭环和开放问题积压，并将维护成本与回答质量分开记录。
Multica 实验跑通了流水线；新的 Spec Kit 开发流程将需求、方案、实现与验收连成主线，并给出独立 reviewer 的可选分工。下一步应在同一需求上记录 reviewer 新发现的问题、未验证项和额外成本，据此判断哪些任务值得固定启用多 agent。常态化编排的收益仍待验证。
零上下文读者原则、frontmatter 约定已经固化了；长程任务系列里的更多实践（上下文压缩、子 agent 分工边界）还在观察哪些真正复用得上。
blog-lint 的定时体检任务是一次试验：agent 从“随叫随到”变成“定期上岗”。如果体检报告持续有价值，更多维护工作（枢纽页更新、死链检查）可能跟进定时化。
维护约定
新 AI 文章发布时归入对应知识线：提供新判断就更新该线的“当前理解”，开新方向就考虑是不是该开第六条线。各线的“当前理解”必须有文章证据支撑，不允许写没有对应文章的推测。完整文章列表以 AI 归档页为准，本页不追求穷举。