Agent 的安全、权限与沙箱：别让它“闯祸”
Agent 的安全、权限与沙箱：别让它“闯祸”Agent 能调用工具，意味着它能真正改变外部世界：发邮件、删文件、执行命令、花钱 能力越强，风险越大 本文总结 Agent 开发中必须考虑的安全问题与实用的防护手段：先梳理威胁模型，再讲最小权限与分级审批，给出 Python 的统一守卫与路径校验、Java 的权限注解与审批流程，讨论沙箱的配置要点，并用一个具体的注入攻击场景演示防线如何叠加，最后是常见坑、上线检查清单与 FAQ Agent 的安全问题为什么不同于传统应用 传统应用的行为由程序员写死，输入来自用户，风险主要是“用户输入能不能被恶意利用” Agent 多了一层：决定做什么的是模型，而模型的输入里混入了大量不可信内容——网页、邮件、文档、工具返回值、第三方 Server 的描述
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鱼鱼
让 AI 起变量名和函数名，我留下的几条品味规矩
让 AI 起变量名和函数名，我留下的几条品味规矩命名一直是我写代码时最磨蹭的环节之一 名字起糊了，后面读代码的人（包括一个月后的我）会一直付税 AI 很擅长甩出一串候选名，也很容易甩出看起来专业、读起来空洞的名字 这篇文章记我让它起名时留下的几条规矩——不是语法规范全文，是品味上的取舍 我愿意让 AI 起名，前提是： 我已经能用一句话说明“这个东西在业务里干什么” 我要的是 3–5 个候选，不是一个“最佳答案” 最终选定权在我，尤其是会进公共 API、表字段、事件名的那些 一上来就说“给个好名字”，它常会给你 handleUserData、processInfo、manageService 这类语法正确但语义稀释的词 候选机模式能逼它发散，也逼我比较
2026-10-14鱼鱼
AI 补全和整段生成，我什么时候用哪种
AI 补全和整段生成，我什么时候用哪种用 AI 写代码久了，我会下意识把它分成两种节奏：一种是编辑器里那个“跟着你敲”的补全；另一种是对话框里“给我写一整段 / 一整文件”的生成 表面上都是 AI 在写，体感完全不一样 补全像有人在旁边帮你把下一句顺出来；整段生成像你把需求扔出去，过一会儿收回来一份成品 我早期几乎只用后者，觉得效率高；后来越写越觉得：很多时候，补全才是更省心的那一个 这篇就聊聊我现在怎么选 补全的好处很直观——上下文就在光标周围，你刚写的函数名、变量名、注释，它都能“看见” 你按 tab 接受一行，再敲两下，它继续跟 这种节奏很接近自己写，只是手变快了一点 我特别喜欢在这些场景用补全： 写样板代码：DTO 字段、简单的 getter/mapper、重复的校验
2026-10-14鱼鱼
AI 生成测试我怎么取舍：哪些让它写，哪些必须人写
AI 生成测试我怎么取舍：哪些让它写，哪些必须人写用 AI 写业务代码越来越顺手之后，下一件很自然的事就是：让它把测试也补上 说实话，这一步的爽感很强——几分钟冒出一堆 should_xxx，覆盖率数字往上跳，CI 绿灯 问题也正好出在这里：绿灯不等于有保险 我经历过一次挺丢脸的事 AI 帮我补了十几个单测，覆盖率从 40% 拉到 75%，合并后第三天生产就炸了 回头看测试，几乎每个都在验证“mock 对象有没有按我设定的方式被调用”，真正的业务不变量一个都没钉住 测试在保护 mock，不在保护系统 这篇文章想说清楚三件事：哪些测例我愿意交给 AI；哪些我坚持人手写；以及怎么减少“假绿” 图片来源：原创示意图 我不想装清高
2026-10-14鱼鱼
工具调用（Function Calling）怎么设计才好用
工具调用（Function Calling）怎么设计才好用Agent 能不能“动手”，取决于工具调用 很多团队发现：模型明明够聪明，却总是选错工具、传错参数 问题往往不在模型，而在 工具设计 这篇文章从背景出发，讲清楚工具调用的完整流程，总结六条实用的设计原则，给出 Python 与 Java 两套防御式代码，并列出常见坑和检查清单 一次 Function Calling 的完整往返：模型只提请求，程序负责执行 大模型只能输出文字 让它“查天气”“下订单”“读数据库”，中间必须有一层翻译：模型用结构化的方式说出“我想做什么”，你的程序把它变成真实的函数调用 这一层翻译的质量，取决于你给模型的“说明书”写得怎么样 可以做个类比：工具定义之于模型，就像 API 文档之于新入职的后端同事
2026-10-14鱼鱼
Agent 的工具调用日志：出了问题我先看哪几行
Agent 的工具调用日志：出了问题我先看哪几行Agent 一跑起来，日志可以很热闹：思考摘要、工具名、参数、返回、重试、最终回答……出了问题时，若从头通读，既慢又容易被模型的“自信叙述”带偏 我逐渐养成一个习惯：先不看它怎么说，先看它调用了什么、参数是否离谱、返回是否被误解 这篇文章记我排查 Agent 故障时的日志阅读顺序 偏工程经验，不是某家产品的官方手册 失败时我最想看的其实不是最终答复 答复是渲染后的故事，故事会把中间的错误抹平 更常见的情况是： 所以我把最终答案降级成线索，把工具轨迹升级成证据 图：先证据后故事：工具轨迹优先于最终答复（原创示意图） 只看序列：读文件 → 搜代码 → 改文件 → 跑测试 这种骨架
2026-10-14鱼鱼
长任务 Agent 的断点续跑：Checkpoint、幂等与人工审批怎么落地
长任务 Agent 的断点续跑：Checkpoint、幂等与人工审批怎么落地一个 Agent 跑到第 37 步，这时候部署系统滚动发布，Pod 被重启了 或者模型接口突然开始返回 429，重试几次之后放弃了 又或者它走到“给客户发邮件”这一步，按规定要等主管审批，而主管这会儿在开会，三个小时后才能看手机 这些时候你该怎么办？从头再跑一遍吗？ 前 36 步花掉的 token 和时间先不说，更要命的是，前面那些步骤里，如果有“发了邮件”“建了工单”“扣了款”这种动作，从头再跑就意味着再发一次、再建一次、再扣一次 Demo 阶段的 Agent 很少考虑这些，因为 Demo 跑一次也就几十秒 但只要你的 Agent 开始处理真实的长任务，这个问题迟早会找上门 这篇文章想聊聊我对这个问题的理解，以及一个能落地的最小实现
2026-10-14鱼鱼
用 AI 学新技术时，我怎么避免“看完就觉得自己会了”
用 AI 学新技术时，我怎么避免“看完就觉得自己会了”前阵子我想补一块还不熟的中间件知识 打开文档、丢给 AI 一句“帮我讲讲原理和常见坑”，它讲得很顺，例子也漂亮 读完我心里有种熟悉的错觉：好像已经懂了 第二天动手搭一个最小示例，卡在配置项和错误信息上 再回头看昨晚的“懂”，其实只是跟着叙述走了一遍，脑子里没有自己踩过的脚印 这种“看完就觉得自己会了”，是我用 AI 学习时最常踩的坑 这篇文章不是反 AI，而是记我现在怎么用它学新技术，又怎么强制自己露馅、再补洞 写的都是个人习惯，不保证适合每个人，但对我自己很管用 AI 很擅长把陌生概念讲成一条平滑的故事线 平滑本身没问题，危险在于：故事线会掩盖你还不知道自己不知道的地方
2026-10-14鱼鱼
AI 自动补全抢方向盘：什么时候该关掉它
AI 自动补全抢方向盘：什么时候该关掉它AI 补全（或行内建议）最迷人的地方，是它常常「猜对你下一句」 最烦人的地方也是这个——它猜对下一句时，也可能把你带离本来要开的那条路 我不是补全黑名单派 体力活、重复模式、测试样板，我开着很香 但这篇文章想写清楚：哪些时刻我会主动关掉或忽略它，以及为什么「一直开着」会偷偷伤到设计质量 写给那些已经习惯 Tab，却说不清「这段到底是我想的还是它推的」的人 典型场景： 你正要抽一个接口，光标停在名字上，它已经按旧习惯补出一个「很大很全」的方法签名 你在探索两种方案，它持续把你推向仓库里更常见的那一种 你想写个丑但明确的临时实现，它不停建议「更优雅」的抽象 命名还没想清，它已经用空心词把名字钉死了
2026-10-15鱼鱼
Agent 的评估、测试与可观测性：上线前后都要看得见
Agent 的评估、测试与可观测性：上线前后都要看得见Agent 的输出具有不确定性：同一个输入，两次运行的路径可能不同 传统的“写几个单元测试就放心”在这里行不通 本文介绍如何给 Agent 建立 评估（Evaluation） 与 可观测性（Observability） 体系：怎样拆解评估维度、构建评测集、选择打分方式、记录 Trace，并顺带讨论成本与延迟的护栏 文中给出 Python 的回归评测与 Trace 记录代码、Java 的埋点示例，以及常见坑和检查清单 评估分三层：结果层、过程层、效率层 传统软件的行为大多是确定的：相同输入得到相同输出，单元测试通过就有较强的信心 Agent 有三点不同： 非确定性：模型本身有随机性，同一任务可能走不同路径，甚至有时成功有时失败；
2026-10-14鱼鱼
