Agent 的规划与任务分解：让复杂任务可控
Agent 的规划与任务分解：让复杂任务可控简单问题一两步就能搞定，但“调研三个竞品并写一份对比报告”这类任务，如果让模型边想边做，很容易跑偏、遗漏或重复 规划（Planning） 就是让 Agent 在动手之前，先把大任务拆成可执行的小步骤 本文从动机讲起，比较三种常见规划模式，给出结构化计划的数据格式，以及一个带依赖调度、失败重试和重规划的完整 Python 示例，并附上 Java 版的计划模型、常见坑和检查清单 三种规划模式：ReAct、Plan-and-Execute 与层次化分解 回忆一下 ReAct：模型每一步只决定“下一步做什么” 这在短链路任务里很灵活，但当任务变长，会出现几类典型问题： 目标漂移：做到第 10 步，模型被中间的工具结果带偏，开始回答另一个问题；
2026-10-14鱼鱼
JEV 是什么：一个不写字、只做判断的模型（附我的调试台 jev.fishmaple.cn）
JEV 是什么：一个不写字、只做判断的模型（附我的调试台 jev.fishmaple.cn）先放链接：jev.fishmaple.cn 这是我前两天搭的一个小调试台，叫 Jev Lab 打开就能用，填一个 OpenRouter 的 Key，就可以直接在浏览器里调 JEV 这篇想聊聊 JEV 到底是个什么东西，它跟传统分类器、重排序差在哪，以及九月它出来之后，OpenAI、微软、Cloudflare、阿里、Perplexity 这些大厂怎么对标的 九月中旬刷 OpenRouter 的模型列表，看到一个叫 typesafe/jev-1.13 的东西，上线日期是 2026 年 9 月 18 日 价格那栏把我看愣了：输入每百万 token 0.042 美元，输出是 0 输出免费？我第一反应是标错了
2026-10-14鱼鱼
给 Agent 设超时和步数预算：别让它无限跑
给 Agent 设超时和步数预算：别让它无限跑第一次把 Agent 接到真实仓库时，我犯过一个很土的错：只盯着“它能不能做完”，没盯着“它最多能跑多久、最多能走几步” 结果某次工具调用卡在外部接口，它一边重试一边换策略，token 和墙钟时间一起烧，最后我手动杀掉，现场还一堆半成品文件 从那以后，我把超时和步数预算当成和权限同级的安全项 不是为了虐待 Agent，而是承认：自动化一旦没有硬上限，失败模式会从“报错”变成“悄悄耗尽” Agent 的轨迹很会制造希望：每一步都有日志，每一步都像在进步 可进步不等于收敛 常见假象包括： 同一类错误换着措辞重试 在几个文件间来回改，测试始终红 搜索范围越扩越大，上下文越来越脏
2026-10-14鱼鱼
并发之AQS全解析
并发之AQS全解析我们知道juc(java.util.concurrent)包下有很多实用的类，提供了很多并发工具，例如线程池、原子类、并发工具、信号量工具、锁等，可以说基本实现都为悲观锁，底层原理基本都使用了AQS(AbstractQueuedSynchronizer)，AQS不是一种概念，是并发中实打实的工具类 本篇文章针对AQS做解析 AQS是多线程访问共享资源的同步器框架 AQS的资源可以是独占的也可以是共享的 我们先来简单看一下它的使用方式和ApI（因为是抽象类，是不能直接使用的）,下图是AQS的整体脉络 AQS核心就是一个状态值state，同时维护了一个线程的阻塞队列，队列的节点为有两种状态：SHARED(共享)和EXCLUSIVE(独占)，节点状态有五种：
![并发之AQS全解析]()
2021-03-12鱼鱼
AI 写的代码，我是这样 Review 的：一份不太体面的清单
AI 写的代码，我是这样 Review 的：一份不太体面的清单AI 生成的代码有一个很“坑人”的特点：它读起来太顺了 命名规整，注释齐全，结构对称，连日志格式都统一 人写的代码出问题，往往在外观上就有迹可循，比如命名乱、缩进歪、注释写着“TODO 先这样” AI 写的代码出问题，外表通常是光鲜的 这就导致一个很尴尬的局面：越是看起来没毛病的代码，我们越容易放松警惕 所以这篇想聊聊我自己 Review AI 代码时的一份清单 说它“不太体面”，是因为里面很多条看着很基础，甚至有点小心眼 但在我看来，Review AI 代码，恰恰需要一点小心眼 图片来源：John 'Pathfinder' Lester / Flickr（CC BY 2.0）
2026-10-14鱼鱼
分布式系统一致性的分类
分布式系统一致性的分类在分布式系统中的CAP理论中有C(一致性)，大郅表示分布式系统中节点状态或数据具有一致的特性 但一致性有着不同的分类，例如常见的用于取代CAP理论的BASE中的E，最终一致性，不同于强一致性，他强调着事务最终状态趋于一致，但中间态可能不一致，利用此篇文章总结一下分布式系统的一致性分类 根据实际系统的要求，分布式系统的一致性可以大致分为四类： 严格一致性 强一致性（线性一致/原子一致） 顺序一致性 弱一致性（最终一致性） 一个理想概念上的一致性，节点间数据完全一致，对外可表现为单个节点 由于网络延迟和通信等因素的存在，现实中这种一致性不可能存在 强一致性要求在全局时钟相同的条件下，对任何节点的读都相同且等于最后一次写成功的数据，这也就意味着仅仅在所有节点同步到数据后才会被标记为同步成功
2021-03-13鱼鱼
第一次用 AI 改 bug 的真实节奏
第一次用 AI 改 bug 的真实节奏第一次认真用 AI 改 bug，不是那种“帮我写个排序”的玩具题，是线上真出了问题：某个接口偶发超时，日志里只有一句 Read timed out，复现不稳 我那会儿把堆栈和一段相关代码扔给 AI，它很快给了一版“优化建议”——加超时、加重试、换连接池参数 看起来很专业，我差点就合进去了 后来自己又翻了半小时才发现：真正的原因是下游在高峰时返回了一个空 body，客户端按固定 schema 去解析，偶发抛异常，异常被上层吞掉，最终表现为超时 AI 那套建议能“缓解症状”，但治不了病，还可能把问题藏得更深 这篇文章想写的，是我后来慢慢摸出来的一套节奏：怎么描述现象、给什么上下文、什么时候该自己看代码
2026-10-14鱼鱼
Agent 的工具返回太长怎么办：截断、分页与摘要的取舍
Agent 的工具返回太长怎么办：截断、分页与摘要的取舍自己写 Agent 的时候，我最早关心的是工具怎么定义、参数怎么描述、调用失败怎么处理 工具返回什么，反而想得很少：命令跑完了，stdout 拿回来，原样塞进上下文，不就行了？ 后来有一次让 Agent 排查一个线上问题，它调了一下读日志的工具 那个日志文件几十兆，工具老老实实全读回来了 结果要么是请求直接超出上下文上限报错，要么是在我加了粗暴截断之后，它看到前面几千行正常日志，得出结论“日志里没有发现异常” 真正的报错在文件末尾，它根本没看到 这件事让我意识到：工具返回多长、怎么变短，是 Agent 设计里一个独立的问题，而且没有银弹 常见的三种办法——截断、分页、摘要——各有各的代价
2026-10-16鱼鱼
让 AI 写正则表达式：我现在一定先要它给反例
让 AI 写正则表达式：我现在一定先要它给反例正则大概是我最早放心交给 AI 的活 原因很简单：我自己写正则也是边查边试，每次写完都不太敢相信它 AI 张口就来，还附带逐段解释，看上去比我靠谱多了 用了一阵之后我发现，AI 写的正则有个很稳定的特点：它几乎总能匹配上你给的例子 问题是，正则真正出事的地方从来不在“该匹配的没匹配上”，而在“不该匹配的也匹配上了” 而后者，你不主动问，它不会告诉你 所以我现在有个死规矩：让 AI 写正则，先别要正则，先要反例 那次是要从一堆构建日志里提取版本号，格式是“主版本.次版本.修订号” 我给了 AI 三个例子，它很快给出 \d+\.\d+\.\d+，解释也清清楚楚 我跑了一下，三个例子全中，就提交了
2026-10-16鱼鱼
Redis原理-源码解析：数据结构1 字符串操作&SDS及预分配的实现验证
Redis原理-源码解析：数据结构1 字符串操作&SDS及预分配的实现验证所有原理实现基于Redis版本6.0.9 SDS(Simple Dynamic String)简单动态字符串，是Redis中字符串所采取的数据结构，SDS并不是Redis的独创，只是被Redis采纳的一种数据结构，用以替换C语言原生的字符串类型：sds仓库传送门 使用方法与原生的C语言字符串类似，并能提供很多类似的API SDS经过了两个版本，目前的解析大都基于v1 v1版本的sds数据结构很简单： 比起C语言中单一的字符数组构成的字符串，sds具有以下优势： 存储了字符串长度，相比C语言遍历获取长度，将时间复杂度由O(n)变为O(1); 当SDS每次发生修改时，会为其分配冗余空间，在字符串空间小于1MB时，每次分配实际长度2倍的空间，而在大于1MB时则是分配多1MB的空间，是在空间不足时才会触发分配
2020-11-16鱼鱼
长任务 Agent 的上下文压缩：摘要什么、丢什么、什么必须原样留着
长任务 Agent 的上下文压缩：摘要什么、丢什么、什么必须原样留着我自己写的那个编程 Agent，最早只用来做一些小改动，十几轮对话就结束了，上下文从来不是问题 后来我开始让它做跨很多文件的迁移，比如把一批旧接口的调用换成新接口 这种任务一跑就是几十轮：读文件、搜索、改代码、跑测试、看报错、再改 每一轮的工具输出都往上下文里堆，没多久就逼近了模型的上下文上限 于是我做了第一版“压缩”：上下文超过某个阈值，就让模型把之前的历史总结成一段话，然后用这段总结替换掉原来的历史，继续往下跑 听起来很合理，跑起来问题一大堆 这篇就讲讲我前后几次改动的过程，以及现在比较稳定的做法 都是在我自己这个 Agent 上摸索出来的经验，换个场景未必完全适用 第一版用的是自由发挥式的摘要，提示大概就是“请总结上面的对话，保留重要信息”
2026-10-14鱼鱼
日常 Coding Agent 里的提示注入：不夸张，但真会踩
日常 Coding Agent 里的提示注入：不夸张，但真会踩一提「提示注入」，容易联想到演示视频里的戏剧桥段：网页藏白字、模型突然泄露密钥 真实日常 Coding Agent 里，更多是另一种样子——不夸张，但真会踩：issue 正文里一句「请忽略之前的指示」，日志里一段看起来像指令的异常信息，README 里抄来的「安装后请执行」…… 这篇文章按工程实践写：我在日常用 Coding Agent 时，把提示注入当成什么风险、怎么降危，以及哪些防护值得做、哪些不必神话 目标不是制造焦虑，是把卫生习惯写清楚 Coding Agent 常见外源： 网页 / 文档抓取内容 GitHub issue、PR 描述、评论 报错日志、测试输出、构建日志
2026-10-15鱼鱼
