且听风吟

RAG 两段式切块 + 四级检索流水线 — 设计文档日期： 2026-07-03状态： 待实现作者： 协作设计（用户 + Claude） 目标优化现有 RAG 管道的检索质量与上下文完整性。现有管道单一固定切块（1000字/300重叠），检索命中后直接送 LLM，存在两个问题： 上下文割裂 — 命中的 chunk 可能正好切断了一个完整景点介绍，LLM 拿到的是残缺上下文 检索粗放 — 只有 BM25→向量→reranker 三级，早期级无门控，低质量查询会浪费昂贵的 reranker API 调用 本设计通过 两段式文档切块 + 四级检索流水线 + 多级检索门控 解决上述问题。 非目标 不改 TravelRAG 的对外接口（query() / query_with_metrics() / get_rag() 签名不变） 不引入新的外部依赖（继续用 jieba / rank-bm25 / sentence-transformers / qwen3-rerank / DeepSeek） 不做磁盘持久化缓存（用...

从 Team Protocol 到 MCP：Claude Code Harness 后半程架构演进分析前面十几个章节里，我们已经完成了一个 Agent 的基本能力： Tool Calling Hook Todo Memory Task System Background Task Scheduler Team 看到这里会发现一个变化。 最开始的 Agent 其实只有一个循环： 123while True: response = llm(...) execute_tool(...) 但到了 Team 阶段之后，系统已经不再是一个 Agent。 而变成了： 1234Lead├── Alice├── Bob└── Charlie 这时候很多以前不存在的问题开始出现： Agent 之间如何协作？ Agent 如何自己找任务？ Agent 之间如何避免修改同一个文件？ 如何接入外部系统？ s16～s19 实际上都在解决这些问题。 一、s16：为什么 Team 需要协议s15 里面已经有 Team 了。 Lead 可以给 Alice 发消息： 12345BUS.se...

从 Background Tasks 到 Cron Scheduler 再到 Agent Teams：Agent Harness 的异步化与多 Agent 协作演进在前面的章节中，Agent 已经具备： Tool Calling Hooks Todo Planning Subagent Skill Loading Context Compact Memory Error Recovery Task System 此时的 Agent 已经能够独立完成复杂任务。 但还有三个明显瓶颈： 问题一：等待Agent 执行： 1npm install 可能需要 5 分钟。 执行： 1pip install torch 可能需要十几分钟。 这期间 Agent 什么都做不了。 问题二：只能手动触发Agent 只能这样工作： 123用户说一句↓Agent 做一次 无法做到： 12每天 9 点跑测试每隔 5 分钟检查服务 问题三：单 Agent 注意力有限当任务变成： 123456重构整个后端重构数据库修改鉴权修改 API补测试写文档 一个 Agent 的上下文根本装不下。 因此：...

从 System Prompt 到 Error Recovery 再到 Task System：Agent Harness 的工程化构造前面几个阶段里，Agent 已经具备了工具调用、Hook 扩展、Todo 规划、Subagent 拆任务、Skill 按需加载、Context 压缩和 Memory 长期记忆。 做到这里，Agent 已经不再是一个简单聊天程序，而是逐渐变成了一个可以处理复杂开发任务的系统。 但是如果继续往工程化方向走，还会遇到三个问题： system prompt 越来越长，不能再硬编码； API 调用可能失败，Agent 不能一报错就崩； Todo 只能管当前会话，不能管理跨会话、带依赖的大任务。 所以这三个章节继续补齐 harness 的三层能力： s10：System Prompt，运行时组装 prompt； s11：Error Recovery，错误恢复和重试； s12：Task System，持久化任务系统。 一、s10 System Prompt：Prompt 应该运行时组装，而不是硬编码1. 问题：硬编码 SYSTEM 会越来越难维护最开始...

从 Skill Loading 到 Context Compact 再到 Memory：Agent Harness 的持续运行能力构造前面几个阶段里，Agent 已经具备了基础工具调用、Hook 扩展、Todo 规划、Subagent 拆任务等能力。 但做到这里还不够。 一个真正能长期工作的 Agent，还会遇到三个更现实的问题： 项目知识太多，不能全部塞进 system prompt； 上下文会越来越长，最终超过模型窗口； 压缩会丢失细节，新会话也无法记住用户偏好。 所以这三个章节继续增强 harness： s07：Skill Loading，按需加载知识； s08：Context Compact，压缩上下文； s09：Memory，长期保存重要信息。 一、s07 Skill Loading：知识不要全塞进 Prompt，要按需加载1. 问题：system prompt 不是垃圾桶假设项目里有很多规范文档： React 组件规范； SQL 编写规范； API 设计规范； 代码审查规范。 最直接的做法是把它们全部塞进 system prompt： 123456SYS...

从 Hooks 到 TodoWrite 再到 Subagent：一个 Claude Code 风格 Harness 的构造过程一、什么是 Harness？在 Agent 系统里，LLM 本身只负责“思考”和“决定下一步”。但真正让它能稳定工作的，不只是模型，而是模型外面那层控制结构，也就是 harness。 可以把 harness 理解成： 包住 Agent 的运行外壳，负责接收用户输入、调用模型、分发工具、拦截危险操作、记录状态、控制循环退出，以及在复杂任务中帮 Agent 维持方向。 这三个文件刚好按顺序展示了一个 harness 的逐步增强过程： s04：加入 Hooks，让循环可扩展； s05：加入 TodoWrite，让 Agent 先规划再执行； s06：加入 Subagent，让复杂任务拆出去，用干净上下文处理。 第一部分：s04 Hooks —— 不要把扩展逻辑写死在循环里1. 问题：agent_loop 会越来越臃肿在 s03 里，Agent 已经能调用工具，也能做权限检查。 但是问题来了：如果后面还想加这些功能： 每次 bash 调用都写日志； 写...

Claude Code 下载与安装指南前提条件 1. 安装 Node.js（版本 ≥ 18）Windows / macOS 直接前往( Node.js 官网) ，点击获取node.js 选择x64，点击windows安装程序，下载好后一路点击安装程序后，点击next直至安装完毕 接着按win键搜索cmd，打开命令提示符，输入： 1node -v 出现版本号代表安装完毕（如下） 顺便设置一下国内镜像源，不然接下来可能安装失败，在命令提示符中输入： 1npm config set registry https://registry.npmmirror.com/ 回车后安装 2. 安装 Git（推荐）Claude Code 的文件操作和提交功能依赖 Git。 Git 官网下载 并安装 或者在浏览器中搜索git，点击进入官网，移动到底端找到在windows上安装，打开(https://git-scm.com/install/windows) 打开后选择x64 setup 之后安装步骤按照node.js来 完成后打开终端/命令提示符验证： 12Bashgit -...

HTML、CSS、JavaScript 与 Vue：从零到一的知识结构前端的学习路径有一个独特的问题：每个知识点单独学都不难，但把它们组装成一个能跑的应用时，脑子里的知识是散的。这篇文章的目的是帮你建立一套从 HTML 到 Vue 的连贯认知，知道每个技术在前端体系里的位置，以及工作中真正用到的是什么。 HTML：内容的骨架HTML 不是编程语言。它是一个声明式的文档格式——告诉浏览器”这里有个标题”、”这里是个按钮”，浏览器负责把它们画出来。 你真正需要掌握的就三件事： 文档流。块级元素（div、section、p）独占一行；行内元素（span、a）跟在同一行。理解这个区别是理解一切 CSS 布局的前提。之后学 Flexbox 和 Grid，本质上是在改变默认的文档流行为。 语义化。用 <header>、<nav>、<main>、<article> 而不是一律 <div class="xxx">。不只是为了 SEO，更实际的好处是你的代码结构一眼就能看懂。 表单。<form>、<i...

Spring 常用注解：你真正需要理解的那些Spring 的注解体系很庞大，但日常开发中高频使用的其实就二十来个。这篇文章从实际项目出发，按使用频率和重要性排列，聊清楚每个注解它实际干了什么、背后的机制是什么、以及哪些地方容易踩坑。 一、Bean 管理：让 Spring 替你创建对象这组注解是 Spring 容器的基础设施。没有它们，依赖注入和 AOP 都无从谈起。 @Component / @Repository / @Service / @Controller / @RestController这五个注解在 Spring 容器层面的行为是一样的——标记一个类，让 Spring 通过组件扫描发现它，创建单例实例，放进容器管理。 它们的区别纯粹是语义分层，外加 @Repository 有一个额外功能：自动将数据库异常翻译为 Spring 的 DataAccessException。 @RestController 是 @Controller + @ResponseBody 的组合。在前后端分离的项目里，你几乎只会用 @RestControl...

SpringBoot+MyBatis 开发手记这篇文章来自一个员工管理后台接口项目的实际开发记录。不追求面面俱到，只写那些真正在代码里反复出现、出了问题需要深刻理解才能排查的知识点。 一、PageHelper 分页的底层发生了什么MyBatis 本身不做分页MyBatis 只管 SQL 与 Java 对象的映射。你写的 SELECT * FROM employee，它完整地发给数据库，数据库返回全部结果。数据量小的时候无所谓，百万级别的时候数据库 IO 和内存会直接打满。 分页靠的是在 SQL 尾部追加 LIMIT offset, size，这件事由 PageHelper 插件完成。 两行代码的背后12PageHelper.startPage(pageNum, pageSize); // 第一行employeeMapper.pageQuery(dto); // 第二行 第一行做的事极其简单：创建一个 Page 对象（包含 pageNum 和 pageSize），放进当前线程的 ThreadLocal。它不发任何 SQL，不发任何网络请求，只做了一件事——...