MQTT 是什么:我把 pub/sub、QoS、遗嘱和 5.0 记一记

MQTT 是什么:我把 pub/sub、QoS、遗嘱和 5.0 记一记最近又有人问我「MQTT 到底干啥的」,我也发现自己讲的时候经常跳着说:一会儿 QoS,一会儿遗嘱,一会儿又冒出 5.0 的共享订阅 这篇就把常用概念按我自己理解串一遍 协议细节以 OASIS 规范为准,我没拿真机逐条抓包,标了「我推断」的地方别当标准条文 MQTT 全称历史上叫 Message Queuing Telemetry Transport 标准化过程里有人提过:名字里的 Message Queuing 容易让人联想到企业消息中间件,OASIS 后来更常直接叫它 MQTT,不再强调展开 事实是:它是一套 客户端—服务器 的 发布/订阅(publish/subscribe) 传输协议,设计目标就是报文小、实现简单,适合机器对机器(M2M)、物联网(IoT),以及带宽紧、延迟高、链路不稳的环境
MQTT 是什么:我把 pub/sub、QoS、遗嘱和 5.0 记一记2026-10-16鱼鱼

Agent 并行调用工具:哪些能一起跑,哪些必须排队

Agent 并行调用工具:哪些能一起跑,哪些必须排队现在不少模型接口都允许模型在一轮回复里同时发起多个工具调用 对写 Agent 的人来说,这是个很诱人的能力:读五个文件不用等五轮,查三个接口可以一起发,整体耗时一下子降下来 我第一次给自己的 Agent 打开并行执行时,体感确实快了不少 然后就开始出怪事:有一次它在同一批调用里既改了一个文件,又跑了测试,测试跑的却是改之前的代码,结果它看着“通过”的测试,宣布任务完成 还有一次,两个写文件的调用同时改同一个配置文件,后写的把先写的覆盖了,日志里两个调用都显示成功 这些问题让我明白:模型愿意并行,不代表这些调用适合并行 模型给出的只是“我想做这几件事”,至于能不能同时做,得由执行层来判断
Agent 并行调用工具:哪些能一起跑,哪些必须排队2026-10-16鱼鱼

Agent 的工具返回太长怎么办:截断、分页与摘要的取舍

Agent 的工具返回太长怎么办:截断、分页与摘要的取舍自己写 Agent 的时候,我最早关心的是工具怎么定义、参数怎么描述、调用失败怎么处理 工具返回什么,反而想得很少:命令跑完了,stdout 拿回来,原样塞进上下文,不就行了? 后来有一次让 Agent 排查一个线上问题,它调了一下读日志的工具 那个日志文件几十兆,工具老老实实全读回来了 结果要么是请求直接超出上下文上限报错,要么是在我加了粗暴截断之后,它看到前面几千行正常日志,得出结论“日志里没有发现异常” 真正的报错在文件末尾,它根本没看到 这件事让我意识到:工具返回多长、怎么变短,是 Agent 设计里一个独立的问题,而且没有银弹 常见的三种办法——截断、分页、摘要——各有各的代价
Agent 的工具返回太长怎么办:截断、分页与摘要的取舍2026-10-16鱼鱼

让 AI 把 Python 脚本改写成 Java:跨语言迁移时它最容易丢的东西

让 AI 把 Python 脚本改写成 Java:跨语言迁移时它最容易丢的东西组里有不少“历史脚本”:某个同事几年前用 Python 写的数据清洗、对账、报表生成,跑在一台机器的定时任务里,没人敢动 最近要把其中几个并进 Java 服务,统一部署、统一监控 这种活交给 AI 再合适不过了:输入输出都明确,代码量不大,几百行 Python,它几分钟就能吐出一份结构工整的 Java 第一份迁移我差点直接合进去 代码能编译,单测能过,命名比原脚本还讲究 后来是跑了一遍真实数据对比,才发现有几十行结果和老脚本对不上 查下来,没有一处是“写错了”,全是两门语言默认行为不一样,AI 按字面翻译了语法,却没翻译语义 这篇整理一下我踩到的这些差异,以及现在怎么让 AI 做迁移才比较放心
让 AI 把 Python 脚本改写成 Java:跨语言迁移时它最容易丢的东西2026-10-16鱼鱼

让 AI 写正则表达式:我现在一定先要它给反例

让 AI 写正则表达式:我现在一定先要它给反例正则大概是我最早放心交给 AI 的活 原因很简单:我自己写正则也是边查边试,每次写完都不太敢相信它 AI 张口就来,还附带逐段解释,看上去比我靠谱多了 用了一阵之后我发现,AI 写的正则有个很稳定的特点:它几乎总能匹配上你给的例子 问题是,正则真正出事的地方从来不在“该匹配的没匹配上”,而在“不该匹配的也匹配上了” 而后者,你不主动问,它不会告诉你 所以我现在有个死规矩:让 AI 写正则,先别要正则,先要反例 那次是要从一堆构建日志里提取版本号,格式是“主版本.次版本.修订号” 我给了 AI 三个例子,它很快给出 \d+\.\d+\.\d+,解释也清清楚楚 我跑了一下,三个例子全中,就提交了
让 AI 写正则表达式:我现在一定先要它给反例2026-10-16鱼鱼

用 AI 读英文技术文档:我怎么防它“翻译腔”和悄悄漏译

用 AI 读英文技术文档:我怎么防它“翻译腔”和悄悄漏译我英文阅读不算差,但读长篇官方文档还是累 尤其是那种配置参考页、迁移指南、RFC 风格的规范,一页几十屏,读到后面前面的全忘了 所以这两年我读英文文档,基本都会拉上 AI 一起:整段丢进去,让它翻成中文,或者干脆让它讲给我听 一开始我觉得这是纯赚的事 直到有一次按译文改了配置,上线前同事问我:“文档里不是说这个参数只有在另一个开关打开时才生效吗?”我回去翻原文,还真有那么一句 unless 从句,而 AI 给我的中文里,这半句干干净净地消失了 译文读起来非常顺,顺到我完全没怀疑 从那以后我对“AI 翻译技术文档”的态度变了:它很好用,但它的错不是乱码式的错,而是读起来很通顺的错
用 AI 读英文技术文档:我怎么防它“翻译腔”和悄悄漏译2026-10-16鱼鱼

日常 Coding Agent 里的提示注入:不夸张,但真会踩

日常 Coding Agent 里的提示注入:不夸张,但真会踩一提「提示注入」,容易联想到演示视频里的戏剧桥段:网页藏白字、模型突然泄露密钥 真实日常 Coding Agent 里,更多是另一种样子——不夸张,但真会踩:issue 正文里一句「请忽略之前的指示」,日志里一段看起来像指令的异常信息,README 里抄来的「安装后请执行」…… 这篇文章按工程实践写:我在日常用 Coding Agent 时,把提示注入当成什么风险、怎么降危,以及哪些防护值得做、哪些不必神话 目标不是制造焦虑,是把卫生习惯写清楚 Coding Agent 常见外源: 网页 / 文档抓取内容 GitHub issue、PR 描述、评论 报错日志、测试输出、构建日志
日常 Coding Agent 里的提示注入:不夸张,但真会踩2026-10-15鱼鱼
网站地图
1
首页 博客 {{screen}} 第 {{page}} 页
博客索引
{{blog.createDate}} ◔ {{blog.timeline}} 小头像 {{blog.author}} {{tag}}
{{blog.likeCount}}{{blog.commentCount}}
分类下暂时没有文章哦!
主题分类
{{taggroup.label}} 

{{tag.value}}