RAG 在 Coding Agent 里：什么时候有用，什么时候添乱
RAG 在 Coding Agent 里：什么时候有用，什么时候添乱一提到让 Agent “懂我们的代码库”，很多人的第一反应是上 RAG：把仓库切块、嵌入、丢进向量库，提问时先检索再生成 听起来理所当然，我自己也做过 用下来的感受是：RAG 在 coding agent 里不是默认答案，而是一种有代价的缓存与索引策略 用对了能省上下文、提高命中；用错了会检索到似是而非的片段，把模型带进沟里 这篇文章想尽量说人话：哪些场景我愿意上 RAG，哪些场景我宁愿用“直接读文件 / 搜符号 / 开测试”的工具，以及怎么判断它在添乱 图片来源：原创示意图 Coding Agent 跟“企业内部知识问答”不一样 它通常已经有这些能力： 列出目录、按路径读文件；
2026-10-14鱼鱼
IO多路复用模型：select、poll、epoll对比
IO多路复用模型：select、poll、epoll对比我们平时提到的I/O几乎都是同步 阻塞模型，譬如网络请求的socket IO，在数据返回前，相应的线程或是进程将会一直 阻塞直到数据返回，比较直接的处理便是针对IO流一对一的监听，但在IO返回前，相应的系统资源会平白无故的浪费，这种处理方式会大大降低服务器的吞吐 如果我们用很少的线程来监听这些IO，就能实现对系统资源的更好利用，在相应的socket有数据返回时才去读取数据 这种方式被称作IO多路复用，在Linux系统中，实现IO多路复用的方式（从古老到新）有select、poll和epoll 现在很多中间件都使用epoll IO多路复用模型才因此有着很高的性能和吞吐 此处简单描述三种方式的实现和区别
2020-08-11鱼鱼
给 Agent 设超时和步数预算：别让它无限跑
给 Agent 设超时和步数预算：别让它无限跑第一次把 Agent 接到真实仓库时，我犯过一个很土的错：只盯着“它能不能做完”，没盯着“它最多能跑多久、最多能走几步” 结果某次工具调用卡在外部接口，它一边重试一边换策略，token 和墙钟时间一起烧，最后我手动杀掉，现场还一堆半成品文件 从那以后，我把超时和步数预算当成和权限同级的安全项 不是为了虐待 Agent，而是承认：自动化一旦没有硬上限，失败模式会从“报错”变成“悄悄耗尽” Agent 的轨迹很会制造希望：每一步都有日志，每一步都像在进步 可进步不等于收敛 常见假象包括： 同一类错误换着措辞重试 在几个文件间来回改，测试始终红 搜索范围越扩越大，上下文越来越脏
2026-10-14鱼鱼
Java的SPI机制
Java的SPI机制SPI（Service Provider Interface） 是JDK内部提供的一种用于服务能力扩展的机制 在服务中通过不同的下沉方法实现能够加载不同的接口实现类，从而实现功能的热插拔 相比一些类似的设计模式（例如策略模式）， SPI作为Java自带的实现特性，相对更加灵活和开放 我们常见的JDBC、日志框架slf4j、JavaMail、Spring等组件都基于 SPI实现（例如JDBC针对不同数据源的驱动） 之所以说区别于Java的一些设计模式，因为Java有一些实现能实现 SPI的动态加载 首先让我们定义 SPI对外提供抽象能力的接口类，这里为了便于理解展示包路径：
2024-10-14鱼鱼
给 Agent 一个草稿本：为什么 scratchpad 比全塞进 prompt 更稳
给 Agent 一个草稿本：为什么 scratchpad 比全塞进 prompt 更稳做长任务 Agent 时，我最早的做法特别朴素：把所有中间结果、计划、反思，一股脑追加进对话上下文 反正模型“看得见”，多写点总没错 错就错在“多写点” 上下文很快又脏又长：旧计划和新计划并存，失败的工具输出还在，模型开始引用过期结论，或者在同一段推理上打转 更麻烦的是，你很难回答一个基本问题——此刻 Agent 到底相信什么？ 后来我给 Agent 加了一个显式的“草稿本”（scratchpad）：工作记忆外置到一块可读写的状态里，prompt 里只放当前需要的摘要和指针 稳定性和可调试性都好了不少 这篇讲讲为什么，以及我怎么划分什么该进草稿本 1. 噪声淹没信号 工具返回动辄几千字，失败堆栈、HTML 片段、长 JSON，全进上下文
2026-10-14鱼鱼
阻塞队列与Protobuf的Udp通信 - 基于Cat的代理(Agent)项目拆解
阻塞队列与Protobuf的Udp通信 - 基于Cat的代理(Agent)项目拆解CAT是美团点评的一个基于Java开发的异常和性能监控项目，github地址：https://github.com/dianping/cat 本篇文章不是对CAT本身的源码拆解，而是基于本人依赖CAT client开发的代理项目进行拆解，但是并不会纰漏任何技术细节 CAT当前已有很多不同语言的Client，当然暂且是不 CAT本身是通过CAT client收集数据并上报至CAT server，server会进行并，共有六种常见数据格式：Transaction、Event、Problem、Metric、HeartBeat、调用链标记，其实如果不考虑复杂的处理（譬如Metric是可以基于指标生成折线图，Problem可以根据具体的异常类型追溯到相应的会话Track）除去Transaction剩余的数据格式都可以理解为特殊的Event
2020-07-19鱼鱼
并发之AQS全解析
并发之AQS全解析我们知道juc(java.util.concurrent)包下有很多实用的类，提供了很多并发工具，例如线程池、原子类、并发工具、信号量工具、锁等，可以说基本实现都为悲观锁，底层原理基本都使用了AQS(AbstractQueuedSynchronizer)，AQS不是一种概念，是并发中实打实的工具类 本篇文章针对AQS做解析 AQS是多线程访问共享资源的同步器框架 AQS的资源可以是独占的也可以是共享的 我们先来简单看一下它的使用方式和ApI（因为是抽象类，是不能直接使用的）,下图是AQS的整体脉络 AQS核心就是一个状态值state，同时维护了一个线程的阻塞队列，队列的节点为有两种状态：SHARED(共享)和EXCLUSIVE(独占)，节点状态有五种：
![并发之AQS全解析]()
2021-03-12鱼鱼
提示词工程与上下文工程：让模型看到“对的信息”
提示词工程与上下文工程：让模型看到“对的信息”写 Agent 时，很多人把精力放在“提示词怎么写得更花哨”上 实际上，更影响效果的往往是：在每一步，模型的上下文里究竟放了什么 这就是近来常被提起的“上下文工程（Context Engineering）” 本文先区分提示词工程与上下文工程，再讲系统提示的结构、上下文的选择/压缩/隔离/外置四种手段，提供一个带 token 预算的上下文组装器（Python）与结构化输出校验（Python + Java），最后总结常见错误、检查清单与 FAQ 上下文窗口里的六个组成部分 很多团队有过这样的经历：换了更强的模型，效果只提升了一点；而把检索结果排序调整了一下、把冗长的工具输出裁剪了一下，效果反而明显改善
2026-10-14鱼鱼
把报错贴给 AI 之前，我先做的三件事
把报错贴给 AI 之前，我先做的三件事以前一看到红字堆栈，我的第一反应几乎是：全选、复制、粘贴进 AI 对话框，然后等它告诉我怎么改 说实话，这个习惯有一段时间挺好用 很多常见错误，它一眼就能看出来，比我自己翻文档快 可后来我发现，有一半以上“贴完还是修不好”的情况，并不是 AI 不行，而是我把一坨还没整理过的信息甩给了它 它只能在这坨信息上猜，猜错了也不奇怪 现在我会强迫自己先做三件小事，再决定要不要问、怎么问 这三件事加起来通常不超过五分钟，但后面少绕很多弯路 不是真的要自己把根因找出来，而是先回答两个很朴素的问题： 这条报错，我看得懂“是什么”吗？发生的位置，离我刚改的代码近吗？ 很多堆栈很长，真正有用的往往就那么几行：异常类型、消息正文、以及“第一次进入我自己代码”的那一帧
2026-10-14鱼鱼
Agent 并行调用工具：哪些能一起跑，哪些必须排队
Agent 并行调用工具：哪些能一起跑，哪些必须排队现在不少模型接口都允许模型在一轮回复里同时发起多个工具调用 对写 Agent 的人来说，这是个很诱人的能力：读五个文件不用等五轮，查三个接口可以一起发，整体耗时一下子降下来 我第一次给自己的 Agent 打开并行执行时，体感确实快了不少 然后就开始出怪事：有一次它在同一批调用里既改了一个文件，又跑了测试，测试跑的却是改之前的代码，结果它看着“通过”的测试，宣布任务完成 还有一次，两个写文件的调用同时改同一个配置文件，后写的把先写的覆盖了，日志里两个调用都显示成功 这些问题让我明白：模型愿意并行，不代表这些调用适合并行 模型给出的只是“我想做这几件事”，至于能不能同时做，得由执行层来判断
2026-10-16鱼鱼
AI 补全和整段生成，我什么时候用哪种
AI 补全和整段生成，我什么时候用哪种用 AI 写代码久了，我会下意识把它分成两种节奏：一种是编辑器里那个“跟着你敲”的补全；另一种是对话框里“给我写一整段 / 一整文件”的生成 表面上都是 AI 在写，体感完全不一样 补全像有人在旁边帮你把下一句顺出来；整段生成像你把需求扔出去，过一会儿收回来一份成品 我早期几乎只用后者，觉得效率高；后来越写越觉得：很多时候，补全才是更省心的那一个 这篇就聊聊我现在怎么选 补全的好处很直观——上下文就在光标周围，你刚写的函数名、变量名、注释，它都能“看见” 你按 tab 接受一行，再敲两下，它继续跟 这种节奏很接近自己写，只是手变快了一点 我特别喜欢在这些场景用补全： 写样板代码：DTO 字段、简单的 getter/mapper、重复的校验
2026-10-14鱼鱼
Agent 记忆系统：短期记忆、长期记忆与向量库
Agent 记忆系统：短期记忆、长期记忆与向量库大模型本身是“无状态”的：每次请求都是一次全新的开始 Agent 之所以看起来“记得”你，是因为工程上做了 记忆系统 这篇文章梳理记忆的分类、常见实现方式、存储选型，并用可运行的代码演示短期记忆的摘要压缩与长期记忆的写入、召回，最后总结踩坑点和检查清单 记忆的三个层次：短期、长期与经验记忆 先看三个很常见的场景： 场景 A：用户上周说过“我的项目用 Java 17，不要给我 Java 8 的写法” 这周开新会话，Agent 又给出了 Java 8 的代码 用户会觉得“它根本不记得我” 场景 B：一个长任务跑了 40 步，到后半段 Agent 忘了最开始的约束“不要修改生产配置”
2026-10-14鱼鱼
