你好,这是一篇测试博客
你好,这是一篇测试博客这是一篇由助手代为撰写的测试博客 今天天气不错,适合写点东西 以后会在这里记录一些有趣的想法和学习笔记,欢迎大家多多交流
![你好,这是一篇测试博客]()
2026-09-30鱼鱼
Agent 的重试与换路：失败了再试一次，还是换条路？
Agent 的重试与换路：失败了再试一次，还是换条路？做 Agent 的人，迟早会碰到同一个设计题：工具调用失败了，下一步是原地再试，还是换个策略？ 听起来像工程里的重试策略老话题，放到 Agent 里却更别扭——因为失败的原因经常不是“网络抖了一下”，而是“这条路根本走不通”，或者“模型把错误理解歪了，越重试越执着” 我踩过两边的坑：该重试时太早放弃，任务脆；该换路时死磕重试，账单和日志一起爆炸，最后还是失败 这篇整理一下我现在怎么做判断 不是所有失败都该一视同仁 我大致分成四类： 瞬时故障：超时、限流、连接重置 特征是：同一请求，过一会儿可能就好 输入问题：参数缺了、格式不对、路径不存在 特征是：原样再发，几乎必败 权限/策略拒绝：没权限、被安全策略拦住
2026-10-14鱼鱼
AI大模型定价对比
AI大模型定价对比https://open.bigmodel.cn/pricing 火山方舟也提供端点（GLM3 0.001） https://openai.com/ja-JP/api/pricing/ 出入价格不一样 官网和火山都有 另外有免费版本的
2024-12-18鱼鱼
DDD领域下的架构模式——CQRS架构
DDD领域下的架构模式——CQRS架构//TODO
![DDD领域下的架构模式——CQRS架构]()
2021-06-24鱼鱼
给 Agent 一个草稿本：为什么 scratchpad 比全塞进 prompt 更稳
给 Agent 一个草稿本：为什么 scratchpad 比全塞进 prompt 更稳做长任务 Agent 时，我最早的做法特别朴素：把所有中间结果、计划、反思，一股脑追加进对话上下文 反正模型“看得见”，多写点总没错 错就错在“多写点” 上下文很快又脏又长：旧计划和新计划并存，失败的工具输出还在，模型开始引用过期结论，或者在同一段推理上打转 更麻烦的是，你很难回答一个基本问题——此刻 Agent 到底相信什么？ 后来我给 Agent 加了一个显式的“草稿本”（scratchpad）：工作记忆外置到一块可读写的状态里，prompt 里只放当前需要的摘要和指针 稳定性和可调试性都好了不少 这篇讲讲为什么，以及我怎么划分什么该进草稿本 1. 噪声淹没信号 工具返回动辄几千字，失败堆栈、HTML 片段、长 JSON，全进上下文
2026-10-14鱼鱼
Agent 的安全、权限与沙箱：别让它“闯祸”
Agent 的安全、权限与沙箱：别让它“闯祸”Agent 能调用工具，意味着它能真正改变外部世界：发邮件、删文件、执行命令、花钱 能力越强，风险越大 本文总结 Agent 开发中必须考虑的安全问题与实用的防护手段：先梳理威胁模型，再讲最小权限与分级审批，给出 Python 的统一守卫与路径校验、Java 的权限注解与审批流程，讨论沙箱的配置要点，并用一个具体的注入攻击场景演示防线如何叠加，最后是常见坑、上线检查清单与 FAQ Agent 的安全问题为什么不同于传统应用 传统应用的行为由程序员写死，输入来自用户，风险主要是“用户输入能不能被恶意利用” Agent 多了一层：决定做什么的是模型，而模型的输入里混入了大量不可信内容——网页、邮件、文档、工具返回值、第三方 Server 的描述
2026-10-14鱼鱼
把报错贴给 AI 之前，我先做的三件事
把报错贴给 AI 之前，我先做的三件事以前一看到红字堆栈，我的第一反应几乎是：全选、复制、粘贴进 AI 对话框，然后等它告诉我怎么改 说实话，这个习惯有一段时间挺好用 很多常见错误，它一眼就能看出来，比我自己翻文档快 可后来我发现，有一半以上“贴完还是修不好”的情况，并不是 AI 不行，而是我把一坨还没整理过的信息甩给了它 它只能在这坨信息上猜，猜错了也不奇怪 现在我会强迫自己先做三件小事，再决定要不要问、怎么问 这三件事加起来通常不超过五分钟，但后面少绕很多弯路 不是真的要自己把根因找出来，而是先回答两个很朴素的问题： 这条报错，我看得懂“是什么”吗？发生的位置，离我刚改的代码近吗？ 很多堆栈很长，真正有用的往往就那么几行：异常类型、消息正文、以及“第一次进入我自己代码”的那一帧
2026-10-14鱼鱼
长任务 Agent 的上下文压缩：摘要什么、丢什么、什么必须原样留着
长任务 Agent 的上下文压缩：摘要什么、丢什么、什么必须原样留着我自己写的那个编程 Agent，最早只用来做一些小改动，十几轮对话就结束了，上下文从来不是问题 后来我开始让它做跨很多文件的迁移，比如把一批旧接口的调用换成新接口 这种任务一跑就是几十轮：读文件、搜索、改代码、跑测试、看报错、再改 每一轮的工具输出都往上下文里堆，没多久就逼近了模型的上下文上限 于是我做了第一版“压缩”：上下文超过某个阈值，就让模型把之前的历史总结成一段话，然后用这段总结替换掉原来的历史，继续往下跑 听起来很合理，跑起来问题一大堆 这篇就讲讲我前后几次改动的过程，以及现在比较稳定的做法 都是在我自己这个 Agent 上摸索出来的经验，换个场景未必完全适用 第一版用的是自由发挥式的摘要，提示大概就是“请总结上面的对话，保留重要信息”
2026-10-14鱼鱼
Agent 的 Token 账单怎么省：Prompt Caching、上下文瘦身与模型分级
Agent 的 Token 账单怎么省：Prompt Caching、上下文瘦身与模型分级做 Agent 的人，大概都经历过这么一个时刻：功能调通了，效果也还行，兴冲冲地跑了一批真实任务，然后打开账单页面，沉默了 同样是调用大模型，Agent 为什么比普通聊天贵这么多？钱都花在哪了？能不能在不明显影响效果的前提下省下来？这篇文章想把这笔账算清楚，再聊几种我觉得性价比最高的省钱办法 先声明一下：各家模型的价格和缓存规则变得很快，文中涉及的具体规则，以我写作时（2026 年 10 月）看到的官方文档为准，你落地之前最好再核对一遍 思路是通用的，数字请以官方为准 图片来源：Negative Space / StockSnap（CC0 1.0） 普通聊天，一问一答，输入的就是你的问题加上一些历史
2026-10-14鱼鱼
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），以及带宽紧、延迟高、链路不稳的环境
2026-10-16鱼鱼
给仓库写一份 AGENTS.md：让 AI 编程助手少走弯路
给仓库写一份 AGENTS.md：让 AI 编程助手少走弯路用 AI 编程助手久了，你大概会有一种“祥林嫂”式的疲惫：每开一个新会话，就得把同样的话再说一遍 “我们用 pnpm，不是 npm ”“跑测试要加这个参数，不然会连真实数据库 ”“generated 目录下的代码是自动生成的，别改 ”“提交信息要按这个格式写 ” 说一次两次还好，说到第十次，就会开始怀疑人生 更糟糕的是，你偶尔忘了说，AI 就会理直气壮地按自己的默认习惯来，然后你再花时间收拾 解决这个问题的办法其实很朴素：把这些话写下来，放进仓库，让 AI 每次开工前自己读 这就是 AGENTS.md 要干的事 图片来源：rawpixel.com（CC0 1.0） 一句话：给 AI 看的 README
2026-10-14鱼鱼
工具调用（Function Calling）怎么设计才好用
工具调用（Function Calling）怎么设计才好用Agent 能不能“动手”，取决于工具调用 很多团队发现：模型明明够聪明，却总是选错工具、传错参数 问题往往不在模型，而在 工具设计 这篇文章从背景出发，讲清楚工具调用的完整流程，总结六条实用的设计原则，给出 Python 与 Java 两套防御式代码，并列出常见坑和检查清单 一次 Function Calling 的完整往返：模型只提请求，程序负责执行 大模型只能输出文字 让它“查天气”“下订单”“读数据库”，中间必须有一层翻译：模型用结构化的方式说出“我想做什么”，你的程序把它变成真实的函数调用 这一层翻译的质量，取决于你给模型的“说明书”写得怎么样 可以做个类比：工具定义之于模型，就像 API 文档之于新入职的后端同事
2026-10-14鱼鱼
