Agent 的安全、权限与沙箱：别让它“闯祸”
Agent 的安全、权限与沙箱：别让它“闯祸”Agent 能调用工具，意味着它能真正改变外部世界：发邮件、删文件、执行命令、花钱 能力越强，风险越大 本文总结 Agent 开发中必须考虑的安全问题与实用的防护手段：先梳理威胁模型，再讲最小权限与分级审批，给出 Python 的统一守卫与路径校验、Java 的权限注解与审批流程，讨论沙箱的配置要点，并用一个具体的注入攻击场景演示防线如何叠加，最后是常见坑、上线检查清单与 FAQ Agent 的安全问题为什么不同于传统应用 传统应用的行为由程序员写死，输入来自用户，风险主要是“用户输入能不能被恶意利用” Agent 多了一层：决定做什么的是模型，而模型的输入里混入了大量不可信内容——网页、邮件、文档、工具返回值、第三方 Server 的描述
2026-10-14鱼鱼
用 AI 学新技术时，我怎么避免“看完就觉得自己会了”
用 AI 学新技术时，我怎么避免“看完就觉得自己会了”前阵子我想补一块还不熟的中间件知识 打开文档、丢给 AI 一句“帮我讲讲原理和常见坑”，它讲得很顺，例子也漂亮 读完我心里有种熟悉的错觉：好像已经懂了 第二天动手搭一个最小示例，卡在配置项和错误信息上 再回头看昨晚的“懂”，其实只是跟着叙述走了一遍，脑子里没有自己踩过的脚印 这种“看完就觉得自己会了”，是我用 AI 学习时最常踩的坑 这篇文章不是反 AI，而是记我现在怎么用它学新技术，又怎么强制自己露馅、再补洞 写的都是个人习惯，不保证适合每个人，但对我自己很管用 AI 很擅长把陌生概念讲成一条平滑的故事线 平滑本身没问题，危险在于：故事线会掩盖你还不知道自己不知道的地方
2026-10-14鱼鱼
接手陌生代码库的第一周，我让 AI 当向导
接手陌生代码库的第一周，我让 AI 当向导前阵子我接手了一个老服务 说它老，不是说技术栈有多古早，而是它经历过好几拨人：最早写它的人早就转岗了，中间有人加过功能，也有人做过“临时方案”，README 停留在两年前的某次重构之前 给我的熟悉时间大概是一周，之后就要开始接需求 以前遇到这种情况，我的套路是从启动类开始一路点进去，点到头晕，再去翻提交记录，看看谁改得最多，厚着脸皮去问 这次我换了个方式：让 AI 陪我读 一周下来，感受挺复杂的——它确实让我快了不少，但也有几次差点把我带进沟里 这篇就记一下我是怎么用的，哪些地方好用，哪些地方我后来学乖了 我犯的第一个错，就是一上来问它：“帮我介绍一下这个项目的整体架构 ”
2026-10-14鱼鱼
分布式系统中的一致性算法和问题解决
分布式系统中的一致性算法和问题解决在撰写脑裂问题相关的博客时发现脑裂问题的产生原因在不同算法下的分布式系统各不相同，需要先大致了解一致性算法并针对性的解决 市面上有很多开源的分布式系统，他们的数据一致性算法不尽相同，例如k-v系统的祖师爷——zookeeper采用的是ZAB的算法，而最近流行的Consul是raft算法，不同数据中心server沟通的方式则是gossip协议 不同的协议和方式对选举和数据同步有不同的处理机制，利用这篇文章来对比常见的分布式一致性算法 一个系统可能会使用多个不同的一致性算法，以便于在不同的业务环节上有着各自更贴切的处理 ps：有种观点是一致性算法不是很准确，因为replica也能保证数据某种程度上具有一致性，有人称之为共识算法
2021-03-13鱼鱼
Agent 的流式输出与“停止”按钮：用户点了停止之后，到底该发生什么
Agent 的流式输出与“停止”按钮：用户点了停止之后，到底该发生什么给内部做的一个小 Agent 加“停止”按钮，我原本以为是半天的活：前端加个按钮，点了以后断开流式连接，完事 上线第二天就有同事反馈：他点了停止，文件却还是被改了 我去翻日志，发现事情是这样的：他点停止的时候，模型刚刚生成完一个写文件的工具调用；前端确实停止了渲染，连接也断了，但后端的 Agent 循环根本不知道用户已经喊停，照样把工具执行完了，甚至还又调了一次模型，生成了一段没人看的总结 那之后我才意识到，“停止”这件事远比一个按钮复杂 这篇就聊聊我后来是怎么重新设计的，主要讲三件事：取消信号怎么传到底、中断落在不同阶段该怎么处理、以及中断之后对话历史怎么写 我后来把“停止”拆成了三层，每一层都要单独处理：
2026-10-14鱼鱼
JVM源码解析(2) ContextClassLoader与ClassUtil.forName()方法浅析
JVM源码解析(2) ContextClassLoader与ClassUtil.forName()方法浅析在Spring获取Context的源代码中，我们看到了对ClassUtil的方法调用，通过给定ClassName和ClassLoader进行Class的加载： ClassUtil.forName是仅供于Spring内部使用的获取Class对象的方法，来看一下源码： 首先 对于缓存的Class一块，在类的静态块中就能看出其逻辑： 在上面的resolvePrimitiveClassName方法中，先对长度做了一个判断，因为较长的packagename会影响执行的性能： 最终加载Class依旧是通过ClassLoader的，先来看一下获取ClassLoader的方法实现： 此处优先使用了ContextClassLoader作为 类加载器而非默认的AppClassLoader，在JVM源码解析 从 Launcher类浅谈ClassLoader中，提到了关于 类加载器的相关知识，使用ContextClassLoader是为了弥补双亲委派加载机制的对于自定义 类加载器的缺憾：那些自定义的 类加载器并没有机会上场，在使用了AppClassLoader后我们的自定义ClassLoader所加载的Class是无法被加载进去的，使用ContextClassLoader，我们可以在定义线程时，通过Thread的init方法(子线程调用，私有方法)或是setContextClassLoader直接指定使用自定义的ClassLoader
![JVM源码解析(2) ContextClassLoader与ClassUtil.forName()方法浅析]()
2020-08-16鱼鱼
Java的SPI机制
Java的SPI机制SPI（Service Provider Interface） 是JDK内部提供的一种用于服务能力扩展的机制 在服务中通过不同的下沉方法实现能够加载不同的接口实现类，从而实现功能的热插拔 相比一些类似的设计模式（例如策略模式）， SPI作为Java自带的实现特性，相对更加灵活和开放 我们常见的JDBC、日志框架slf4j、JavaMail、Spring等组件都基于 SPI实现（例如JDBC针对不同数据源的驱动） 之所以说区别于Java的一些设计模式，因为Java有一些实现能实现 SPI的动态加载 首先让我们定义 SPI对外提供抽象能力的接口类，这里为了便于理解展示包路径：
2024-10-14鱼鱼
Spring源码解析(1) 基于SSM看Spring的使用和Spring启动监听
Spring源码解析(1) 基于SSM看Spring的使用和Spring启动监听查看源码的顺序就见仁见智了，比较普遍的做法是从IoC入手，了解容器注入的每一个环节，掌握大致的流程 由于使用的是Spring，所以在这里我们引入比较古老的xml配置文件进行bean的配置，首先定义一个bean: 配置描述bean的xml，核心只有一行： 这样一来就可以使用BeanFactory这个容器来注入bean并使用了： 本来有封装好的XmlBeanFactory，这一类现在已经被弃用了，所以采用了他的父类DefaultListableBeanFactory;当然，也可以使用更加方便和常用的ApplicationContext： 当然从xml文件读取bean的配置只是其中一种目前用的不多的加载方式，还有基于包扫描等加载bean的方法，此处仅为理解IoC的基本使用
2020-08-04鱼鱼
Java中的协程（虚拟线程）探究
Java中的协程（虚拟线程）探究在Java最新的LTS版本 21中，终于实装了协程这一特性 当然，在这些诸如python、golang等轻量级语言中被称为协程的东西，在Java中有个全新的代号——虚拟线程，为了将协程与线程做区分，在Java21中，原Thread被称之为平台线程 下文中，将统一使用线程/协程的方式称呼 我们都知道，Java中引入了线程的概念，区别于系统中的进程 作为并发执行的最小单元，在一定的条件下，使用多个线程同时运作可以有效提高程序的运转效率 而线程这一能力源于系统本身而并非JVM 之所以说是在一定条件下，是因为受限于机器配置情况（CPU的运作机制、核心数），线程的同时运作并不能线性的提升运行性能，单个cpu并不能同时处理多线程任务，实际的运作方式是基于时间片分片，各个线程抢占式执行代码，这样能减少一些无效的io等待（例如网络io、磁盘io实际是会阻塞等待io结果），同时在多核心场景下也能有效利用cpu
![Java中的协程（虚拟线程）探究]()
2024-10-28鱼鱼
多轮对话里的「目标漂移」：Agent 跑着跑着忘了你要什么
多轮对话里的「目标漂移」：Agent 跑着跑着忘了你要什么和 Agent 多轮协作久了，会遇到一种安静的失败：它一直很忙，工具也在调，中间步骤看起来都“合理”，可收工时你发现——干的已经不是你起初要的那件事 我把这叫目标漂移（goal drift） 不是偶发幻觉那么简单，更像是上下文变长后，约束被一步步冲淡 这篇文章记我怎么发现漂移、怎么在过程中拉回，以及设计 Agent 时能做哪些防漂 常见几种面孔： 每一步单独看都有道理：重构有益、修复积极、干净也好 合起来却违背委托 危险在于局部合理、全局偏航 图：目标漂移四种脸：膨胀、替换、偷换、遗忘（原创示意图） 我的个人理解（含推测）： 所以漂移不完全是“模型不听话”，也是交互方式与系统设计的结果
2026-10-14鱼鱼
AI 编程工程化迭代中的混沌风险：从规格熵到四个工程控制面
AI 编程工程化迭代中的混沌风险：从规格熵到四个工程控制面过去两年，我们团队把 AI 编程工具真正用进了日常研发：补全式的 Copilot、IDE 里的对话助手，以及能自己读写文件、跑命令的 Agent 收益是实打实的，样板代码、单元测试、脚本、联调、陌生框架的第一版实现，速度都明显提升 但用得越深，我越确信一件事：AI 工程化迭代最危险的地方，不是它“不会写代码”，而是它太会写了 在缺少稳定工程约束的时候，它会持续、高速地产出“单独看都挺合理，放在一起却彼此矛盾”的局部方案 这些矛盾的方案不会立刻表现为一个 Bug 它们表现为一种缓慢累积的混乱：同一个纠正反复被推翻，数据库越改越别扭，代码里一个概念长出两三个名字，线上出事时拼不出一条完整的因果链
2026-10-14鱼鱼
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方法进行初始化和配置项的读取
2020-08-09鱼鱼
