Java反序列化CC链详解：从CC1到CC7的利用链演进与实战-北京尧图网络

把Java安全里值得反复咀嚼的课题排个序反序列化漏洞一定能进我的个人榜单前三。而在反序列化这一大块内容里从CC1到CC7这条完整的利用链演进脉络又是每一个做漏洞研究、做安全开发、做攻防演练的人迟早都要面对的技术课。我最早看CC链时也被那一串类名绕晕过AnnotationInvocationHandler、TransformedMap、LazyMap、ChainedTransformer、InvokerTransformer……直到后来把整条链理解成一趟“入口到执行”的接力跑这堆名词才算真正串起来了。这篇文章我不打算按教科书方式平铺直叙而是以这些年实际调试和实战项目的视角把CC1到CC7这七条链的来龙去脉、构造思路、版本限制、踩坑记录和防守侧的对应思路全部摊开讲。适合刚接触Java反序列化、想在本地复现和理解利用链原理的人也适合已经在做安全研发、想搞清楚为什么CC6更稳定、为什么某些链被修复后还能绕过的人。1. 为什么从CC1到CC7是绕不开的必修课1.1 攻防两端都绕不开的原因CC链的全称核心是围绕Java生态里一个非常普及的工具库——Commons Collections下文统一叫CC库展开的利用链集合。早年大量Java Web应用和中间件都会直接或间接依赖这个库偏偏它里面又存在几个可以被反序列化流程利用的危险类。CC1到CC7本质上就是安全研究者们在不同的库版本、不同的JDK版本、不同的入口类限制下摸索出来的七条能达到相同目标的路径。对防守方来说这份素材的重要性甚至比对进攻方还高。如果只知道“升级CC库版本”或者“封掉几个类”而不理解为什么封掉A类之后还有B类能打进那漏洞就会反复在别的地方以变种形式出现。我见过不少次甲方明明已经更新了依赖结果因为目标环境里某个业务模块自己引了老版本Jar绕过程序包管理直接带病上线最后还是被打穿。只有把利用链的构造逻辑吃透才能在设计检测规则和应急策略的时候有据可依。1.2 一条利用链的三段结构我一直跟团队里的小朋友讲CC链不管编号到多少拆开看都是三段入口触发点、中间转运器、最终执行点。入口触发点是反序列化的发动位置典型如某个类自己的readObject方法被调用后会不自觉地去操作一个Map或者一个排序队列中间转运器负责把“反序列化动作”传导成“对危险方法的调用”比如ChainedTransformer、LazyMap、TiedMapEntry这类组件最终执行点则是真正干坏事的地方最常见的就是InvokerTransformer通过反射调用任意方法或者TemplatesImpl直接加载恶意字节码。打个比方入口是发令枪转运器是一棒接一棒的接力队员执行点就是终点线后等着的人。很多新手容易犯的错是死记完整调用链一旦环境版本变化导致某一棒跑不了就完全不知道该怎么重新接线路。理解了分段结构你就能针对每一段寻找替代类这才是CC1到CC7真正的学习价值所在——它们不只是一堆Payload而是一套“哪里断了就从哪里换接力棒”的动态思维。1.3 七条链的宏观差异速览动手研究之前先看一眼整体版图会省力很多。我整理了一张自己平时参考的表覆盖入口类、中间关键类、执行方式、适用库版本和主要限制。编号入口触发点中间关键类最终执行点库版本要求主要限制CC1AnnotationInvocationHandler.readObjectTransformedMap/LazyMapInvokerTransformer反射执行CC 3.1~3.2.1JDK 8u71后入口失效CC2PriorityQueue.readObjectTransformingComparatorInvokerTransformer反射执行CC 4.0需要CC4的Comparator可序列化CC3AnnotationInvocationHandler.readObjectLazyMap TrAXFilterTemplatesImpl加载字节码CC 3.1~3.2.1同样受JDK版本限制CC4PriorityQueue.readObjectTransformingComparator TrAXFilterTemplatesImpl加载字节码CC 4.0依托CC4的能力CC5BadAttributeValueExpException.readObjectTiedMapEntry LazyMapInvokerTransformer反射执行CC 3.1~3.2.1依赖环境对异常类的允许CC6HashMap.readObjectTiedMapEntry LazyMapInvokerTransformer反射执行CC 3.1~3.2.1 / 4.x通用性最强的链CC7Hashtable.readObjectHashMap LazyMapInvokerTransformer反射执行CC 3.1~3.2.1链长、调试难度稍高这张表不用背关键是怎么读。你会发现所谓“新链”大多数时候只是入口换了、中间某一段换了最后的执行点往往还是那几个老面孔。这就是为什么钻研CC链至今仍有价值——底层思想没有变包装方式一直在变。2. 七条链的逐个拆解从调用关系到版本限制2.1 CC1最经典的开门课CC1是最早被公开完整披露的一批利用链之一。它走的是AnnotationInvocationHandler这个入口该类的readObject方法在读入序列化数据后会对成员变量里的Map执行entrySet操作而这张Map如果被我们替换成TransformedMap或LazyMap这类由CC库提供的Map包装类entrySet操作就会传导到危险Transformer上。经典的CC1调用链大致长这样AnnotationInvocationHandler.readObject - Map.entrySet - TransformedMap / LazyMap.get - ChainedTransformer.transform - ConstantTransformer拿到Runtime.class - InvokerTransformer拿到Runtime实例 - InvokerTransformer执行exec方法这条链的巧妙之处在于ChainedTransformer把一串Transformer串起来前一个transform的输出正好是后一个transform的输入最终用几个反射调用拼出一个完整的Runtime.exec。早期的攻击代码里可以写死一串命令也可以动态拼接原理都一样。不过CC1有个绕不开的坎JDK 8u71之后AnnotationInvocationHandler.readObject不再直接对Map执行entrySet而是先判断成员变量members是否为空逻辑一变原本的入口路径就走不通了。所以后来才有了各种在新版本JDK下仍然可用的链也是CC2到CC7不断迭代的最初动机。我第一次调试CC1是在JDK 8u65环境里当时用了TransformedMap变体Serializable文件生成后丢进目标进程看到命令执行的那一刻确实很有成就感。但同样的Jar换到8u121环境里Payload完全静默这才促使我去关注“为什么”而不是停留在“怎么打”。2.2 CC2绕开入口限制的另一条路CC2的思路和CC1完全不同。它不再依赖AnnotationInvocationHandler而是盯上了PriorityQueue。PriorityQueue是Java自带的优先队列类反序列化时会把队列元素重新排一遍排序过程中会调用Comparator的compare方法。如果我们能把一个危险Transformer包装成一个Comparator反序列化排序动作就等于替我们完成了危险调用。CC2的完整路径大致如下PriorityQueue.readObject - heapify - siftDownUsingComparator - TransformingComparator.compare - ChainedTransformer.transform - InvokerTransformer / Runtime.exec这里有一个关键前提TransformingComparator在CC库的3.x版本中并没有实现Serializable接口没法被序列化所以CC2只适用于CC 4.0及之后版本。正是因为4.0里Comparator相关的几个类被改造成了可序列化才给了这条链生存空间。CC2给我的最大体会是“入口不一定要是readObject里直接调危险方法”。PriorityQueue本身跟命令执行毫不相关但因为它会在反序列化时调用外部传入的Comparator就变成了一个“借刀杀人”的跳板。这种间接性正是利用链设计的核心美学——每个参与者都只做一点点事串起来才致命。2.3 CC3把命令写死换成字节码加载CC3的贡献在于改变了最终执行点的选择。前两条链最终都是通过InvokerTransformer去反射调用Runtime.exec但在实际攻防中“命令执行”这种特征容易被Java进程内的安全审计代码盯上而且碰上命令被过滤的环境就不那么灵光了。CC3换成TemplatesImpl来加载字节码。TemplatesImpl是JDK里处理XSLT模板的类它有内部属性可以存放自定义的字节码并在调用newTransformer方法时触发字节码加载。CC3的思路是先用InstantiateTransformer构造一个TrAXFilter对象而TrAXFilter的构造函数里会调用Templates.newTransformer这样就完成了“构造对象即触发字节码加载”的接力。AnnotationInvocationHandler.readObject - LazyMap.get - ChainedTransformer - ConstantTransformer(TrAXFilter.class) - InstantiateTransformer(TemplatesImpl) - TrAXFilter构造函数 - TemplatesImpl.newTransformer - 加载恶意字节码对比CC1来看CC3只是把最后“反射调用Runtime.exec”这一段换成了“实例化TrAXFilter触发TemplatesImpl”中间段的ChainedTransformer和LazyMap都还能继续复用。这种“只替换最后一棒”的思路特别值得学习做蓝队研究时看到某个执行点被封了第一反应不该是放弃而是寻找另一个能达到同类效果的类。2.4 CC4CC2与CC3的正交组合CC4是一条经常被人忽略、但结构上非常工整的链。它把CC2的PriorityQueue入口和CC3的TemplatesImpl执行点结合在一起中间用TransformingComparator做转运。简单地讲CC4就是用CC2的进场方式跑CC3的终点线。PriorityQueue.readObject - TransformingComparator.compare - ChainedTransformer - ConstantTransformer(TrAXFilter.class) - InstantiateTransformer(TemplatesImpl) - TrAXFilter构造函数 - TemplatesImpl.newTransformer这也解释了为什么CC4必须依赖CC 4.0的TransformingComparator可序列化能力。CC4的实战价值在于它同时绕开了两个方向的限制既不用AnnotationInvocationHandler也不依赖InvokerTransformer直接反射执行命令。很多防守规则如果只针对“CC1特征”或“CC3特征”就容易漏掉这条组合链。我个人的学习建议是把CC2、CC3、CC4放在一起看。CC2解决入口CC3解决执行点CC4证明这两个维度是自由组合的。一旦建立这种意识再面对未来新公开的链时就不会觉得又是什么全新东西本质上还是熟悉的那些积木换了拼法。2.5 CC5从Map入口转到异常类入口CC5的诞生背景是CC1入口失效。它选的入口是BadAttributeValueExpException这是Java标准库里的一个异常类反序列化时它的readObject方法会对传入的val对象调用toString。而TiedMapEntry这个CC库类正好在其toString方法里调用了map.get再配合LazyMap整条链就活了。BadAttributeValueExpException.readObject - valObj.toString - TiedMapEntry.toString - LazyMap.get - ChainedTransformer.transform - InvokerTransformer / Runtime.exec这条链里面的明星是TiedMapEntry它本质上是一个“键值对条目”的包装类内部持有Map和key两个成员变量。toString、hashCode、equals这些最常见的方法它都会转发给内部的Map操作。这种“借力”设计让其成为后续多条CC链通用的中间转运器CC6、CC7里都能看到它的身影。CC5的实战应用场景多在高版本JDK的默认环境中因为BadAttributeValueExpException和TiedMapEntry都不涉及高版本JDK的变更逻辑。不过这条链的限制也很明显反序列化入口是否能触发异常类的toString取决于目标环境的Java安全管理器和类加载策略不同JDK小版本的行为差异也需要逐一验证。2.6 CC6目前最通用也最稳妥的链CC6是我个人平时测试时最常用的链没有之一。它把入口换成了HashMap——这是所有JDK版本都自带、必然可序列化的类。HashMap在反序列化时会对每个key执行hashCode如果把key设计成TiedMapEntry它的hashCode会转发给内部Map.get后面接LazyMap就能一路触发到InvokerTransformer。HashMap.readObject - hash(key) - TiedMapEntry.hashCode - TiedMapEntry.getValue - LazyMap.get - ChainedTransformer.transform - InvokerTransformer / Runtime.execCC6的稳定性来自它对JDK版本的挑剔极少。HashMap从Java 1.2到目前最新版本读入元素后的hash逻辑基本没动过CC库里的TiedMapEntry和LazyMap在3.x和4.x版本中都存在且可序列化。这让它成为跨版本测试时的首选路径也是我在培养新人的时候教的第一条完整可复现链。构造CC6时有个小坑你直接把TiedMapEntry作为key放进HashMap序列化前HashMap会先计算一次hash。如果TiedMapEntry对应的LazyMap里有危险Transformer那么它在本地构造阶段就会提前触发命令执行导致Payload还没发出去自己环境先中招。解决办法是把危险Transformer数组先放进一个空的LazyMap里但放入HashMap时要保证LazyMap的某个标记为未触发状态等反序列化时才真正生效。这块细节等到第三节实操部分我再展开。2.7 CC7利用Hashtable哈希碰撞的神奇路径CC7可能是七条链里最巧妙也最绕的一条。它选的入口是Hashtable这是另一个Java老牌集合类。Hashtable反序列化时会调用reconstitutionPut方法把元素重新放回哈希表这个方法内部会对key做hash和equals比较处理哈希碰撞时还会调用equals。CC7利用的恰恰是两次元素在同一个哈希桶里碰撞时对两个LazyMap包装后的TiedMapEntry执行equals最终push到LazyMap.get。Hashtable.readObject - reconstitutionPut - key.hashCode - TiedMapEntry.hashCode - LazyMap.get - 碰撞时 key.equals - TiedMapEntry.equals - LazyMap.get - ChainedTransformer.transform - InvokerTransformer / Runtime.exec这条链构造复杂因为它需要你先构造出一对哈希值相同但又不完全相等的TiedMapEntry才能让Hashtable在反序列化过程中调用到equals并确保此时加载的Transformer才被赋值到LazyMap里。序列化前和序列化后LazyMap的状态必须被精细控制稍微差一步就会在本地构造阶段提前触发。CC7给我的启发是入口触发点远不只是一堆readObject方法。Java集合类的底层实现细节比如哈希表碰撞处理也能成为反序列化触发链的一部分。研究这类链时重要的已经不是“这个类能不能序列化”而是“这个类的内建逻辑会不会在某个时期调用到我们可控的外部对象”。3. 本地复现与调试从PoC到断点的完整过程3.1 搭建可复现的实验环境复现CC链不需要高性能机器一个干净的操作系统加一个老版本JDK就够了。建议准备JDK 8u65和8u121两个版本前者用于体验CC1等旧链后者用于验证新链在高版本下的表现。然后在IDE里建一个Maven工程引入CC库老版本依赖。dependencies dependency groupIdcommons-collections/groupId artifactIdcommons-collections/artifactId version3.2.1/version /dependency /dependencies如果你还想尝试CC2和CC4需要换成4.0版本。最方便的做法是把两个版本的Jar都下载到本地用IDE里的“添加外部Jar”功能切换避免反复改pom.xml。我自己习惯建两个Module一个用3.2.1一个用4.0调试起来互不干扰。实验环境里还要准备好序列化工具方法。所谓PoC说白了就是先把一个构造好的危险对象通过ObjectOutputStream写进文件再用ObjectInputStream读出来。触发点在反序列化的“读”这一侧。public static void serialize(Object obj, String path) throws Exception { try (ObjectOutputStream oos new ObjectOutputStream(new FileOutputStream(path))) { oos.writeObject(obj); } } public static void deserialize(String path) throws Exception { try (ObjectInputStream ois new ObjectInputStream(new FileInputStream(path))) { ois.readObject(); } }这两个工具方法虽然简单却是几乎所有CC链复现的基础设施。真正研究时你写的主要精力都花在“如何构造成一个Object”上也就是构造阶段。3.2 在断点里读懂一次完整的调用栈我强烈建议所有初学者不要只跑通工具生成的Payload一定要亲手在IDE里下一组断点亲眼看清调用栈是怎么一步步推进的。以CC6为例你可以在这几个位置下断点HashMap.readObject看反序列化开始后第一次进入HashMap的逻辑。TiedMapEntry.hashCode看key的hash计算如何触发到TiedMapEntry。LazyMap.get看get方法里如何判断不存在时触发factory.transform。ChainedTransformer.transform看一串Transformer如何按顺序执行。InvokerTransformer.transform看到达最终反射调用的现场。调试时最震撼的一刻是你在InvokerTransformer的断点里回看完整调用链发现从HashMap到最终命令执行每一层的调用都毫无多余动作。这种直观感受比看任何文档都有用。实践中可以这样构造CC6的核心对象Transformer[] transformers new Transformer[] { new ConstantTransformer(Runtime.class), new InvokerTransformer(getMethod, new Class[] { String.class, Class[].class }, new Object[] { getRuntime, new Class[0] }), new InvokerTransformer(invoke, new Class[] { Object.class, Object[].class }, new Object[] { null, new Object[0] }), new InvokerTransformer(exec, new Class[] { String.class }, new Object[] { open -a Calculator }) }; ChainedTransformer chainedTransformer new ChainedTransformer(transformers);然后包一层LazyMap再包一层TiedMapEntry最后put进HashMap。构造时需要注意在把TiedMapEntry放进HashMap之前先不把真正的chainedTransformer传给LazyMap否则本地会提前执行命令。标准套路是先给LazyMap传一个无害的Transformer等序列化前再通过反射把factory替换成真正的chainedTransformer。利用反射修改私有字段是这条链里最常用的技巧JDK高版本还需要加上setAccessible处理模块限制。3.3 快速识别当前环境的版本约束调试过程中最常见的困惑是“这条链在这个环境里为什么不触发”。排查思路主要看三个维度第一看JDK版本。如果入口走的是AnnotationInvocationHandler这条老路检查当前JDK是否高于8u71如果高于8u71请优先换用CC6这种HashMap入口的链。第二看CC库版本。老版本的TransformingComparator不可序列化的坑已经提过如果你确认目标里CC库是4.x才考虑CC2和CC4如果目标是3.2.1则选择CC1、CC3、CC5、CC6或CC7。第三看目标环境是否启用了反序列化过滤机制。如果JVM启动参数或容器层配置了ObjectInputFilter你会发现连序列化流里的类解析都会被拦截此时需要先确认过滤规则是黑名单还是白名单黑名单通常可以通过寻找未列入名单的入口类绕过白名单则难度大得多。识别这些信息时有个经验不要急着一次就试完全部链而是先构造一个“最小验证”对象比如只反序列化一个自定义类确认反序列化功能本身正常再一步步加中间环节。很多“不触发”其实是环境里反序列化被整体禁用了跟利用链选择毫无关系。4. 防守视角修复、过滤、检测的落地方式4.1 升级版本只是起点不是终点CC库官方对漏洞的回应是逐步封堵高危类。3.2.2版本里InvokerTransformer等类不再实现Serializable等于从根上让依赖反射调用的链失效4.1和4.2中更多中间组件也被加入了黑名单或取消了序列化能力。这个方向是对的但放在真实企业环境里只盯“框架依赖升级”远远不够。我见过太多系统主程序确实升到了最新版本可某个内部业务模块依然以独立的Jar形式引入老版本CC库或者某个自研框架把CC库的低版本逻辑复制了一份内嵌进去。这种依赖下沉的问题用集中升级的方式根本查不出来。应对办法是上线前扫描全部依赖树不只扫描顶层pom文件还要扫描最后打包产物里包含的所有Jar看看有没有低版本类潜伏在里面。4.2 代码层的纵深防御不只是黑名单从代码维度看反序列化过滤是现阶段最有效的手段之一。JEP 290为Java平台引入了对象输入过滤机制可以通过ObjectInputFilter配置允许或拒绝类。白名单策略比黑名单可靠得多因为你只需要列举出业务运行时需要反序列化的合法类其他类一律拒绝这样就算利用链如何变化只要危险类不在白名单里就打不进来。但白名单在真实项目里推行并不容易很多老系统的反序列化数据里混杂着大量动态代理类、第三方框架类列白名单会带来兼容问题。折中方案是分级实施对核心涉密系统采用严格白名单对普通业务系统采用黑名单加RASP兜底。黑名单里的重点关注对象基本上就是CC链里反复出现的那些类InvokerTransformer、InstantiateTransformer、TransformingComparator、TemplatesImpl、LazyMap、TiedMapEntry等等。另外可以考虑对ObjectInputStream做全局子类化比如定义一个安全ObjectInputStream重写resolveClass方法在里面统一执行类过滤逻辑。这种方式改动量小又能集中管控很适合已有项目接入。4.3 检测与溯源如何发现利用行为检测层面最实用的是调用链采样。RASP类产品之所以能抓漏洞利用本质上不是靠正则匹配Payload而是靠方法调用栈里出现了“正常业务不该出现的组合”——例如TemplatesImpl.newTransformer往下跟TrAXFilter构造函数连续出现或者InvokerTransformer.transform往上翻到LazyMap.get。这种基于行为和调用关系的检测比单纯匹配类名准得多也很难被简单混淆绕过。流量侧检测也不可放弃。序列化数据以二进制形式传输但开头通常带有Java序列化流头的特征字节。如果看到某个请求体里出现0xACED 0x0005这样的开头或者经过Base64编码后对应ACED0005字样都要高度警惕。很多企业只盯着HTTP明文流量忽略了二进制体统中大量反序列化入侵这是防守盲区。我自己做检测规则时有个习惯先跑通所有CC1到CC7的本地复现把每条链在关键方法处的调用栈特征记录下来再把这些特征转换成RASP规则。这个工作看起来费时但它能让规则真正贴合利用链的骨架而不是浮在表面匹配类名。5. 常见问题、误区和我的实操体会5.1 实战中踩过的几个大坑第一个坑是CC1在JDK 8u71之后的静默失败。早期我不看JDK版本直接拿现成Payload打内网结果目标毫无反应。排查了大半天最后发现目标JDK版本已经高于8u71入口类行为变了。这件事之后我的习惯就变成了每到一个环境第一件事不是打Payload而是先想办法摸清JDK版本和CC库版本。第二个坑是CC6的构造阶段直接触发命令。有一次我在本地生成Payload时想确认命令是否真的被执行结果序列化还没写完弹出一次命令执行窗口。原因就是构造HashMap时没有把LazyMap里的factory先换成无害Transformer。那时起我就养成了“构造链时必须先把危险组件和集合对象彻底隔离”的纪律。第三个坑是系列化流里的类在目标环境不存在。同一个CC链在本地跑得通到了目标环境就报ClassNotFoundException。原因往往是你的测试依赖里有额外的库而目标环境没有。排查方法是查看异常堆栈里缺少的是哪个类去判断是链本身的问题还是环境依赖的问题。这个教训让我更注重用最小化依赖来测试链避免把无关Jar一并打进Payload。5.2 我平时选择利用链的次序真到复盘排查的时候我不会一条条盲试而是按通用程度排优先级。首选CC6因为它对JDK和CC库版本的容忍度最高HashMap入口基本是百搭如果CC6失败再试CC5考虑BadAttributeValueExpException入口是否被过滤接着试CC2和CC4但前提是确认目标用了CC 4.0及以上版本最后才考虑CC1和CC3因为它们受高版本JDK限制太明显只有在明确是老环境时才值得花时间。这个次序不是固定金科玉律它只是基于“入口类是否受版本影响、中间类是否随处可用、执行点是否容易被拦截”这三条标准的自然排列。你也完全可以按自己的需求做调整但建议每一轮测试都要记录失败原因而不是单纯换一个链继续撞运气。5.3 研究的边界和方法论复盘反序列化研究做久了我最大的心得是危险的不是某个库的某个类而是Java生态里“把对象序列化或反序列化”这件事本身太过隐式。任何能被反序列化且内部逻辑会对外部对象调用方法的地方都可能成为利用链的一环。CC1到CC7虽然已经是有些年头的样本但那种“从一个普通入口一步步编排到命令执行”的思维方式放到今天依然能指导我们发现新型链。还要说一句常被忽略的话做这些研究一定要控制在自有环境或获得授权的测试环境中。利用链本身是安全研究的教学内容但同一条链落在不合适的地方就会变成违法工具。理解攻法是为了更好地防这个边界越清晰技术研究的路才能走得越稳越远。最后再分享一个我自己保留的习惯每研究完一条链我都会在笔记里画一张带注释的调用图把每个类在每个环节里扮演的角色写清楚下一次做检测规则或排查问题时直接翻笔记定位关键节点。这个习惯让我没有陷入“过一段时间就忘”的循环。这个内容后续还可以延伸的方向也不少比如研究其他库与CC库的串联利用、分析不同JDK版本的过滤机制演进或者把精力花在反序列化检测规则的自动化生成上。CC1到CC7只是个入口背后那片海才值得慢慢游。

Java反序列化CC链详解：从CC1到CC7的利用链演进与实战

相关推荐

AI工具选型实战：国产大模型为何在中文场景反超海外模型

AI编程工具：从效率杠杆到工程风险，开发者如何守住质量底线

LangChain、Pi、DeepSeek Harness与Claude Code本质区别解析

更多资讯

eNSP综合组网实验：VLAN、单臂路由与静态路由全流程

企业级Kubernetes集群落地指南：从容器到编排的完整实践

Python家庭财务系统源码实战：从解压到月度结账闭环

ASP.NET WebForms家庭财务系统源码解析与部署指南

YOLOv8魔改与部署实战：从Backbone到TensorRT的完整指南

C#高性能Modbus TCP：零拷贝、内存池与管道化架构实践

今日更新

电商智能运营体系从0到1：架构设计、落地步骤与避坑指南

压缩空气储能与热网热惯性联合优化调度：热电联产系统建模与求解

若依框架AI代码生成不稳定？用Agent Skill三层结构+五步法搞定

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？