Agent 的流式输出与“停止”按钮:用户点了停止之后,到底该发生什么

Agent 的流式输出与“停止”按钮:用户点了停止之后,到底该发生什么给内部做的一个小 Agent 加“停止”按钮,我原本以为是半天的活:前端加个按钮,点了以后断开流式连接,完事 上线第二天就有同事反馈:他点了停止,文件却还是被改了 我去翻日志,发现事情是这样的:他点停止的时候,模型刚刚生成完一个写文件的工具调用;前端确实停止了渲染,连接也断了,但后端的 Agent 循环根本不知道用户已经喊停,照样把工具执行完了,甚至还又调了一次模型,生成了一段没人看的总结 那之后我才意识到,“停止”这件事远比一个按钮复杂 这篇就聊聊我后来是怎么重新设计的,主要讲三件事:取消信号怎么传到底、中断落在不同阶段该怎么处理、以及中断之后对话历史怎么写 我后来把“停止”拆成了三层,每一层都要单独处理:
Agent 的流式输出与“停止”按钮:用户点了停止之后,到底该发生什么2026-10-14鱼鱼

浅谈锁机制、主流锁设计方案

浅谈锁机制、主流锁设计方案本文旨在探讨通用的锁机制实现逻辑,以Java中常见的锁实现为例 本文提到的锁,是指通过限制并发/并行访问所添加的安全措施,本质上是通过限制线程/进程同时更改数据或是读取数据与写入数据产生时序差从而造成数据问题 锁机制中,有一些常见特性: 可重入性 指同一线程/进程携带相同的标识可以反复多次加锁,每次加锁和释放锁对应的重入次数+1/-1; 读写锁/独享共享 是锁的不同运作模式,分为读写锁,读锁与写锁、写锁与写锁是互斥的,但多个线程/进程可以同时对一个逻辑添加读锁,独享共享是另一种叫法 公平性 锁分为 公平锁和非 公平锁, 公平锁指锁释放和获取的顺序严格按照索取的顺序,非 公平锁则是等待锁的对象共同进行锁释放机会的争抢
浅谈锁机制、主流锁设计方案2024-10-15鱼鱼

Spring源码解析(3) IoC容器配置读取和容器refresh

Spring源码解析(3) IoC容器配置读取和容器refresh在文章Spring源码解析(I) 基于SSM看Spring的使用和Spring启动监听中,讲述了web容器启动后会触发的方法实现中生成Context的部分,回顾下核心方法: 我们已经分析到了0.处,他对我们生成的容器做了一个判断,对于web.xml监听初始化的Context,其生成的WebApplicationContext都是ConfigurableWebApplicationContext的子类,所以必然会进入if分支 首先通过loadParentContext先加载了父容器,默认是null 然后调用了configureAndRefreshWebApplicationContext方法进行初始化和配置项的读取
Spring源码解析(3)  IoC容器配置读取和容器refresh2020-08-09鱼鱼

用 AI 写代码越久,我越怕自己“手生”

用 AI 写代码越久,我越怕自己“手生”先说一个可能很多人都有过的瞬间:公司网络抽风,或者 AI 插件突然登录失效,你对着一个空白文件准备写点东西,然后发现自己卡住了 不是不会写,是那种“这个方法的参数顺序是啥来着”“这个异常该在哪一层处理来着”的卡顿 以前这些东西是肌肉记忆,现在得想一想 我第一次意识到这件事的时候,心里咯噔了一下 倒不是怕失业,那个话题太大了,轮不到我在这儿焦虑 我怕的是更具体的东西:当 AI 给出的代码出了问题,我还看不看得出来 这篇文章不打算劝谁少用 AI 我自己每天都在用,而且用得挺开心 我只是想把这种“手生”的感觉拆开看看,它到底是错觉还是真的,以及我目前摸索出来的一些应对办法 说是办法,其实也就是一些习惯,不一定对,供参考
用 AI 写代码越久,我越怕自己“手生”2026-10-14鱼鱼

AI 建议装新依赖时,我怎么查验再动手

AI 建议装新依赖时,我怎么查验再动手结对写代码时,AI 很爱给一种“干净解法”:装一个库,三行调用,问题消失 有时这确实是正道;有时则是把一个五分钟能写完的小函数,换成十年后还要付账的依赖 我吃过亏:当时图省事装了包,后来发现维护停滞、传递依赖一堆、许可证也不理想 卸载比安装痛 所以现在但凡 AI 说“建议安装某某”,我会先走一套很短的查验,再决定装不装 查验的第零步不是搜包,而是判断需求本身 若是加密、图像处理、成熟协议实现——自己造轮子风险更大,倾向用维护良好的库 若是拼接查询字符串、简单重试、薄封装——先看标准库或现有工具能不能扛 我会明确问 AI:“不用新依赖,用标准库怎么写?代价是什么?”它若给不出合理的无依赖方案,只是单方面推销某个包,我反而更警惕
AI 建议装新依赖时,我怎么查验再动手2026-10-14鱼鱼

AI 生成测试我怎么取舍:哪些让它写,哪些必须人写

AI 生成测试我怎么取舍:哪些让它写,哪些必须人写用 AI 写业务代码越来越顺手之后,下一件很自然的事就是:让它把测试也补上 说实话,这一步的爽感很强——几分钟冒出一堆 should_xxx,覆盖率数字往上跳,CI 绿灯 问题也正好出在这里:绿灯不等于有保险 我经历过一次挺丢脸的事 AI 帮我补了十几个单测,覆盖率从 40% 拉到 75%,合并后第三天生产就炸了 回头看测试,几乎每个都在验证“mock 对象有没有按我设定的方式被调用”,真正的业务不变量一个都没钉住 测试在保护 mock,不在保护系统 这篇文章想说清楚三件事:哪些测例我愿意交给 AI;哪些我坚持人手写;以及怎么减少“假绿” 图片来源:原创示意图 我不想装清高
AI 生成测试我怎么取舍:哪些让它写,哪些必须人写2026-10-14鱼鱼

ES快速入门(2)——Tokenizer、Reindex

ES快速入门(2)——Tokenizer、Reindex本篇介绍es提供的几种分词分析器和常用的开源分词分析器 es默认的分词器,中规中矩的按照 Unicode Standard Annex #29分词,一般的小写符号会忽略,对于中文等字符会逐字分割,参数max_token_length表示最大的字符长度,再切分后会继续按此切分 譬如: 会分词为: 一个无视语义,按照字符尽量收集全索引的分词方式,会前后叠加的按符号位分词,参数: 会分词为: nGram的分词很全面,但如此夸张的方式用不好会导致索引doc过大,同时使查询效率偏低 分词规则很简单,无其余规则的按空格分词: 会分词为: 在standard的基础上能够有效拆分出邮箱和url地址的格式,同样有max_token_length这一参数:
ES快速入门(2)——Tokenizer、Reindex2020-09-05鱼鱼

多轮对话里的「目标漂移」:Agent 跑着跑着忘了你要什么

多轮对话里的「目标漂移」:Agent 跑着跑着忘了你要什么和 Agent 多轮协作久了,会遇到一种安静的失败:它一直很忙,工具也在调,中间步骤看起来都“合理”,可收工时你发现——干的已经不是你起初要的那件事 我把这叫目标漂移(goal drift) 不是偶发幻觉那么简单,更像是上下文变长后,约束被一步步冲淡 这篇文章记我怎么发现漂移、怎么在过程中拉回,以及设计 Agent 时能做哪些防漂 常见几种面孔: 每一步单独看都有道理:重构有益、修复积极、干净也好 合起来却违背委托 危险在于局部合理、全局偏航 图:目标漂移四种脸:膨胀、替换、偷换、遗忘(原创示意图) 我的个人理解(含推测): 所以漂移不完全是“模型不听话”,也是交互方式与系统设计的结果
多轮对话里的「目标漂移」:Agent 跑着跑着忘了你要什么2026-10-14鱼鱼

AI大模型定价对比

AI大模型定价对比https://open.bigmodel.cn/pricing 火山方舟也提供端点(GLM3 0.001) https://openai.com/ja-JP/api/pricing/ 出入价格不一样 官网和火山都有 另外有免费版本的
AI大模型定价对比2024-12-18鱼鱼

扫盲——加密那些事

扫盲——加密那些事扫盲加密解密算法 日常开发中我们经常接触MD5算法,以此进行简单的文件完整性校验或者是后台密码验证,MD5是最常见也是最简单快捷的散列算法,常用于参数或文件完整性校验,譬如网络请求发起方与接收方分别对参数做MD5编码,一旦不一致便判断请求被篡改从而拒绝该请求,从而保证信息安全,编码后的字符串是编码前文本的一个简要梗概,因此它也被称作是信息摘要算法 这个算法的特点就是不可逆,只用于信息准确性和防篡改的校验,当然,MD5作为老牌的散列算法,很多经典的编码已经可以被反向解码出来(依靠正向的暴力穷举)以及被碰撞模仿(王小云院士团队的"破解"能够根据MD5编码后串码模拟原始消息,即使它可能与原信息不同),类似的还有SHA1,因此衍生了SHA224、SHA256、SHA512等更多安全的散列算法
扫盲——加密那些事2021-05-14鱼鱼

ELK实战(Ⅰ) 基于ELK整合分布式业务日志

ELK实战(Ⅰ) 基于ELK整合分布式业务日志大多情况下,我们可能都习惯了使用linux指令查看日志,很多时候一句简简单单的tail、grep能定位绝大多数问题 但是面临复杂的目录结构和分布式系统产生的“分布式日志文件”,如果还要我们一个一个去查日志,就会耗费很多没必要的时间 可以利用ELK这套组件快速搭建一个日志系统 注意此文仅针对可能很多情况下格式不确定的业务日志,对于某些组件日志我们有更好的可视化实践方式,可以参考此系列的其他文章 对于一个日志系统,我们要确认我们的诉求,在不同的场景下采用不同的收集方式: 是否是分布式系统需要合并多个节点的日志 如果需要,则需要用分布式组件收集并合并日志,这也是一个日志系统最基本的要求;
ELK实战(Ⅰ) 基于ELK整合分布式业务日志2020-03-14鱼鱼

mysql前缀索引

mysql前缀索引有时候需要索引很长的字符列,这会让索引变得大且慢 通常可以索引开始的部分字符,这样可以大大节约索引空间,从而提高索引效率 但这样也会降低索引的选择性 前面已经说过,使用前缀索引,定义好长度,就可以做到既节省空间,又不用额外增加太多的查询成本 2.1因为前缀索引无法完全等于判断,只是前缀匹配,所以可能需要扫描的所以数会增加 2.2在特殊的查询里面 select id,email from SUser where email='zhangssxyz@xxx.com'; 前缀索引需要回到 id 索引再查一下,因为系统并不确定前缀索引的定义是否截断了完整信息 select count(distinct left(email,4))as L4,
mysql前缀索引2020-05-15yangwcn
网站地图
1
首页 博客 {{screen}} 第 {{page}} 页
博客索引
{{blog.createDate}} ◔ {{blog.timeline}} 小头像 {{blog.author}} {{tag}}
{{blog.likeCount}}{{blog.commentCount}}
分类下暂时没有文章哦!
主题分类
{{taggroup.label}} 

{{tag.value}}