从上下文、工具、权限、计划、恢复、可观测性和结果验证出发，解释 Harness Engineering 如何把模型能力转化为可运行的系统能力。

比较 MCP、Skill 与 CLI 的工具半径和工程成本，说明本地确定性任务为何适合 Skill + CLI，以及跨系统复用时 MCP 的价值。

解释 Agent Skill 怎样把重复任务中的经验、流程、规则、脚本和模板打包复用，并梳理它与 Prompt、Tool 和 MCP 的职责差异。

从“AI 的 USB-C 接口”这个常见类比出发，拆解 MCP 在工具发现、协议连接和资源访问中的作用，以及权限、安全和治理仍需解决的问题。

回顾 RunLens 当前闭合的 Agent 工程链路、测试与部署范围，并整理异步执行、严格 Schema、事件存储、插件安全和多 Agent 等后续方向。

通过 Feedback Analysis 与 File Summary 两个插件，说明新业务怎样声明输入、Skill、工具、Plan 和产物，并复用同一套 Agent Runtime。

拆解 Events、Trace、Metrics 与 Manifest 如何共享统一事件时间线，让一次 Agent Run 的执行过程可以排查、聚合、回放并安全展示。

从模型 final answer 之后的 validating 阶段出发，介绍 RunLens 怎样用产物契约、Stop Hook 和证据索引检查文件结构、内容格式与引用真实性。

围绕状态机、错误分类、恢复预算与终止策略，说明 Agent Runtime 如何修正有价值的失败，同时识别重复调用、超时和无效循环。

跟踪一次 ToolCall 从模型输出到真实执行的全过程，拆解 Schema 校验、权限裁决、生命周期 Hook、Handler 与结果回流构成的安全管线。

解释 Skill、Prompt、Plan 与 Tool 在 Agent 工作台中的不同职责，以及 RunLens 如何通过能力快照让任务方法、推进顺序和真实动作保持一致。

沿一次 Feedback Analysis Run 的时间线，梳理请求、插件、能力解析、模型循环、工具调用、产物落盘与最终验证之间的完整交接过程。

拆解 RunLens 的接口层、业务插件层与通用 Runtime，解释为什么业务能力应通过契约声明，而执行、权限、恢复和观测由统一底座承接。

从一份用户反馈 CSV 分析任务出发，说明 RunLens 为什么把模型调用扩展成一条可执行、可限制、可恢复、可验证的 Agent 运行链路。

到上一篇为止，NexaRAG 的普通 RAG 证据链已经有了一个比较完整的闭环：

前面讲完了评测体系。到这里，NexaRAG 已经有了一条比较完整的普通 RAG 证据链：能入库，能切 chunk，能检索，能 rerank，能构造 evidence，能引用和校验，也能用 Golden Set 做回归。

前面几篇已经把 RAG 证据链补到了答案校验：文档有身份，chunk 有结构，检索有 trace，候选能 rerank，上下文能形成 evidence，答案要引用证据，verifier 还会检查事实支持。

前面已经把候选片段整理成了 [E1]、[E2] 这样的 evidence block。到这里，RAG 链路看起来已经很完整：文档有身份，chunk 有结构，检索有候选，rerank 有排序，上下文有证据编号。

上一篇讲到混合检索：Query Rewrite、BM25、向量检索、RRF 和 metadata filter 共同负责把正确证据送进候选池。

前面几篇把证据链的前半段铺好了：请求有 trace，文档有身份，chunk 有结构。接下来进入真正的检索阶段。

上一篇讲文档入库和 metadata。那一步解决的是“知识进入系统之前先有身份”：文档有 docid，版本有 documentversionid，chunk 有 chunkid，后续检索、引用、删除和回滚才有东西可以追踪。

RAG 的很多问题，表面发生在检索阶段，根子常常在入库阶段。

做 RAG 项目时，很容易一上来就想调 chunk 大小、换 embedding 模型、加 rerank、改 prompt。NexaRAG 的施工路线里，第一步却是 Retrieval Trace。

GitHub项目链接：chenyu-hao/NexaRAG

前面十篇基本把普通 RAG 的工程链路拆完了。从文档处理、chunking、embedding、向量检索，到 Query Rewrite、Hybrid Search、Rerank、上下文工程、幻觉治理、评测体系，再到知识库动态更新、权限、版本和回滚，这些内容组成了一套相对完整的生产级 RAG 视角。

上一篇讲 RAG 评测体系时，重点是如何证明系统变好了。评测解决的是“当前效果是否可靠”，这一篇继续往生产系统推进：知识库本身会不断变化。

上一篇讲幻觉治理时，重点放在引用、拒答、证据约束和答案后校验。治理手段设计出来以后，还会遇到一个更现实的问题：怎么证明系统真的变好了。

上一篇讲 Rerank 与上下文工程时，重点放在候选证据如何进入 Prompt。检索把材料找回来，Rerank 判断证据优先级，上下文工程把证据整理成模型可以使用的形态。到了这一篇，问题继续往后推进：即使模型已经拿到了外部知识，RAG 仍然可能产生幻觉。

上一篇讲检索增强时，重点放在 Query Rewrite、Hybrid Search 和多路召回。它们共同解决的是证据入口问题：让正确证据尽量进入候选池。

上一篇把一次在线 RAG 请求从用户问题进入系统，到最终答案返回完整串了一遍。放在整条链路里看，检索层承担的是一个很朴素但很关键的职责：让正确证据进入候选池。

前面几篇已经把离线侧的基础拆开了：原始文档要经过解析、清洗、结构化和 metadata 标注，随后按合适的粒度切成 chunk，再通过 embedding 和向量索引进入可检索状态。到这里，知识库具备了被系统调用的基础。

上一篇讲 chunking 时，重点是文档以什么粒度进入索引。chunk 决定了知识块的边界，决定了检索系统后面能找回什么样的证据。

上一篇讲的是文档进入知识库之前的处理。解析、清洗、结构化和 metadata 解决的是资料以什么质量进入系统。

上一篇讲 RAG 的边界时，核心结论是：RAG 适合解决模型回答时缺少外部证据的问题。到了这一篇，问题往前推进一层。

上一篇把 RAG 放在了一条更完整的证据链里看：它更像一套让模型回答时能拿到外部证据的工程系统。“向量数据库 + 大模型”只是最小 demo 里的表层形态。

这个系列是重新梳理RAG流程与在每一个流程中的问题与解决，对于具体的技术实现不会写的很细。

前面 11 篇，我基本是按模块拆 Claude Code：Agent Loop、工具、提示词、记忆、上下文、计划、权限、观测、恢复、扩展和 subagent。

上一篇写 Hooks & Extension 时，我把 Claude Code 的扩展系统理解成一组 runtime 入口：command 管任务入口，skill 管可复用能力，MCP 把外部系统变成工具，hook 接在执行事件上。

上一篇写 Fallback & Recovery 时，我把 Claude Code 的失败处理拆成两条线：fallback 处理当前这一步怎么换路，recovery 处理任务走坏以后怎么回到可继续的位置。

上一篇把 Observability 理解成 Agent 的证据层。

上一篇把 Permission & Safety 理解成动作裁决层。

上一篇讲 plan，重点是 Claude Code 怎样先把任务整理成一条行动路线。

上一篇讲 Context Management，重点是：Claude Code 每一轮到底让模型看见什么。

上一篇讲 Memory System，重点是：哪些经验值得跨会话留下，下一次还能被 Claude Code 召回。

上一篇把 Prompt System 理解成 Claude Code 的行为协议装配层。

上一篇把工具系统当成 Claude Code 的执行层来看。

上一篇把 Agent Loop 当成 Claude Code 的运行时主线来看。主循环负责维护任务状态，判断下一步该观察、行动、验证，还是询问用户。

上一篇先把 Claude Code 放回工程系统里看。它更像一个能进入仓库、观察环境、调用工具、处理风险、验证结果的 coding agent。

后面这个系列，我准备把 Claude Code 当成一个真实的 coding agent 来拆。

这个系列一开始想解决的是博客上传里的重复劳动。Markdown 写完后，复制正文、调整格式、保存草稿，这些动作做一两次还能接受，文章一多就会变成稳定摩擦。

上一篇写的是扩展规划：单篇知乎草稿跑通之后，下一步要接上批量上传、CSDN、博客园，以及统一的 blog-publisher。

上一篇把失败路线收住了：发布按钮交给人，脚本先把文章稳定放进草稿。

第二篇已经跑通了第一条链路：检查、生成、导出、预检，再把文章稳定放进知乎草稿箱。

前两篇把问题拆开了：博客上传脚本需要入口、规则、脚本、模板和人工确认点。

上一篇写到，博客自动上传脚本的起点很小：少复制粘贴几次，把 Markdown 稳定放进平台草稿箱。

我开始做这个系列，起点其实很小：写完一篇 Markdown 博客后，希望少走一遍打开平台、复制标题、粘贴正文、检查格式、保存草稿的流程。