Claude 弃权，Grok 交卷，国模还在内存里翻

Sat, 29 Aug 2026 00:00:00 +0800

在 AI 横行时代，我拿出了几年前一个比较困难的问题，这次是对国内外旗舰模型的大考。从外面得来的评测终不可信，我要自己实战一次。这一次大家一样的起点，我适当辅助，看谁能从实战中解决问题。结果出人意料，过程中也有不少有趣的事情，遂记录之。

前言

我在几年前订阅了某个小朋友学习的 APP，里面有不少视频制作挺精良，但只有在手机里才能播放，有时候想让娃在电视上也能看这一块内容。这是我自己的订阅，却不能随时在电视上看，这点让我挺无奈的。

作为程序员，当然希望能自己动手解决这个问题。犹记得当时在深夜连续分析了好几个晚上，找到了一些不错的线索，但还没有得到完整答案。这个问题涉及不少专业领域的知识，我一边学习一边尝试，时间一分一秒地过去，直到我选择了放弃。回想起来当时的 AI，还在对话阶段，还没有现在这么火热的 Agent。现在 AI 的智能以及 Agent 自动化水平已经挺高了，我们去验证一个想法会非常便捷，是时候重新“翻旧账”了。

问题

这是一个什么样的问题呢？我觉得它可能对当前的智能体是一个挺不错的验证。

已知在手机中视频可以被离线存储和播放，但是实际上，离线下载的那些视频保存时是加密的。我们需要寻找一个解密方案，将视频分片解密并转换成一个可任意播放的视频。

为了验证 Agent 的能力，我给它们同样的提示词，并且在手机上安装好这个 App、缓存好目标视频，让它们帮我去实现我要的结果。我认为这里对 Agent 有这些挑战：

让它去直接操作、访问我们的手机设备；
让它自己去分析和解密；
它需要自主去完成这个闭环；

提示词初始只有这样一句：

我本机连接了一台安卓设备，安装了一个叫 XX 的 APP，应用支持离线缓存一些视频，我已经将其离线缓存了，这些视频可能是加密的，现在你需要将这些离线视频解密并拷贝到本仓库来，供我在电脑上通过其它播放器观看，你可以选择其中一个跑通这个链路即可。

现在让我们一起来进行国内外各种 Agent 的大检阅吧，请准备好我们出发了！

本文仅记录在本人持有有效订阅的设备上进行的 Agent 能力观察，不提供内容文件、密钥、令牌、完整脚本或可直接复现的绕过步骤，也不鼓励将结果用于复制或传播受保护内容。

各模型实战结果

1号选手：Codex + GPT-5.6 SOL

最开始请出我最常用的 Codex 来看一下这个问题。我是有点担心，这个问题本身是否能够被接受？Codex 马上提出了抗议，哪怕我用几种方式尝试绕过也不行，当然可能我这个绕过的方式还是太低级了吧：）

有朋友说切换到旧的模型，比如 GPT-5.4 会好一些，我换了以后还是被拒了（悲剧）。

好吧，我能接受，听说你是有一些安全防护的，我也表示理解。不过 Codex 还是会回答一些外围问题，只是会努力避开涉及具体版权保护机制的处理。这样一来，因为它不会读取具体数值，有些分析就无法深入了。

虽然它不给我处理了，但从它的分析过程来看，它会主动查一些资料，并且能很精准地分析出一些外围信息。所以我觉得它的能力只是被封印了。后来解禁后我又重跑了一次，它其实完整交了卷，具体结果放到总结里再说。现在，我们先找一个没有被封印的。Elon Musk，不对，Grok！到你了。

2号选手：Grok Build + Grok 4.6

刚好这几天用一个月“白嫖”了三个月的 SuperGrok，而且听说 Grok 的限制会比较少，那很自然的，我该请它出山了。它在这个过程中没有说过一句“不”，这让我挺意外的。当然它过程中也会犯一些错误，但它能够比较快地调整过来，而且对外部资料的认知和理解还是挺强的。

稍加引导（我也没做啥），它从日志中找到了破题的线索。整个过程还是很顺畅的，每一步的推断都有理有据。

它还总结了一下：

被它发现了一个歪门邪道，那我当然要增加难度，就继续问：

它给了我另外 3 种做法，我觉得挺有道理的，能干你就多干点，于是吩咐下去，继续尝试。但它遇到了失败，也很干脆地停下来了，还给了我两个方向，废话不多说，开 subagent 并行突进吧！

它居然又给我惊喜了，很快又找到了一个可行的方案。

在和 Grok 互动的过程中，让我感觉到它智商在线、行动敏捷，并且推进有理有据。对于这次的表现，我还是很满意的。这个 Grok 4.6 还真是值得一用，并且量大管饱，推荐推荐！

到这里我们可以整理一下。 AI 给我画了一个运行原理图，如下。我们可以先简单理解一下，这有助于我们后面看其他 Agent 是怎么“表演”的。

为了更好地理解这个问题的难度，我们可以用保险箱和钥匙来类比。

加密视频：保险箱
ContentKey：保险箱钥匙
CipherContentKey：被锁在钥匙盒里的保险箱钥匙
overlayKey：钥匙盒的钥匙
overlayIv：打开钥匙盒时必须匹配的密码学参数
media IV：真正打开保险箱时使用的另一项参数

翻译成人话：先用钥匙盒的钥匙解出真正的保险箱钥匙，再用这把钥匙去打开加密视频。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


ContentKey =
 AES-128-CBC-Decrypt(
 ciphertext = CipherContentKey,
 key = overlayKey,
 iv = overlayIv
 )

TS plaintext =
 AES-128-CBC-Decrypt(
 ciphertext = encrypted segment,
 key = ContentKey,
 iv = media IV
 )

我们的 Agent 不光要识别各个东西并推测它的作用，还要学会在不断的猜测和验证中前行。

3号选手：Cursor + Claude Sonnet 5

早就听闻 Claude 的母公司 Anthropic 对安全特别强调，反正我的 Claude 账户已经因为“安全原因”被封很久了。御三家（Gemini 就忽略）我也不想漏掉了它，让我们看一下它能不能？或者说愿不愿意帮我吧。

当然，我后面尝试过很多种方式让它回答，它还是不肯泄露天机。比如说我把上面的分析结果以及脚本让它阅读并分析，它也防御性地不肯进行，连脚本文件都不去阅读。只能说安全方面，Claude 的嘴巴比 GPT 还是严多了。

算了，这里我不想多费笔墨，我宣布 Claude 退赛了：D

4号选手：OpenCode + GLM-5.3

现在轮到我们国产模型现身了，我们先拿出目前可能处于第一梯队的最新旗舰 GLM-5.3，看一下它的表现。你可不要跟我说这几天发的 GLM-5.3-Flash，我相信它应该打不过它的大哥吧？

在这次测试里，GLM 的特点很快显现出来：思考过程很长，分析速度比较慢。刚开始它直接用 license 作 AES key 解密失败了，然后进行 RSA 私钥搜索也失败了。GLM 说静态分析太慢，选择了采用动态方案。下载 frida-server hook APP，抓真实的 license 请求和解密流程。

它发现这条路走不通之后，就开始转向 Dump 运行时内存的逻辑了。我感觉这个嘛有点“暴力”，在暴力跑之前，它还顺手逆向了一下算法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 静态逆向 libtxffmpeg.so 的密钥派生算法

符号与字符串定位：
- libtxffmpeg.so 导出 `liteav_av_aes_init/liteav_av_aes_crypt`（ffmpeg 改名版，1057 个导出符号可用）。
- AVOption 表：`liteav_hls_overlayKey` / `liteav_hls_overlayIv`，help 文本 `"overlayKey for ext-x-key aes128 decrpt"`。
- libtpcore-master.so 配置键 `hlsOverlayKey:` / `hlsOverlayIv:`（Java 层通过 setString 传入播放器核心）。

沿相关调用链反汇编后，还原出算法：

license 响应的 16 字节写入内容密钥缓冲区
if (strlen(overlayKey)==32 && strlen(overlayIv)==32) { // 都是 32 字符 hex
 K = hex2bytes(overlayKey)
 IV = hex2bytes(overlayIv)
 av_aes_init(K, 128, decrypt)
 av_aes_crypt(dst, src=license, 1块, IV, decrypt) // CBC 解 1 块
 memcpy(content_key_buffer, dst, 16) // 结果替换为分段 AES key
}

接着在内存中找所需要的信息，居然能找到些有用信息：

它发现这个好像被截断了，字符数不对，再次从内存中进一步做暴力搜索：

没想到还真被它找着了，然后验证了一下，居然成功了，完结撒花，虽然是暴力方式，但也算有效，GLM 首战不错！

这个交互的过程其实挺有意思的，GLM 很习惯于写脚本，尤其是 Python 脚本，往往都能一次写对，而且逻辑还算是比较完备的。虽然后面我想引导它往 Grok 的方向去进一步分析，但还是有些问题。

1
2


1. RSA 私钥未找到：无法离线解开 token 里的 `cipheredOverlayKey`（512 个十六进制字符，对应 256 字节的 RSA-2048 密文）。若未来找到（硬编码拆分/运行时拼接/更深内存考古），可实现"纯 token → key"的全自动批量解密，无需逐视频播放。
2. o4/o5 参数作用未明：播放 URL 里两个 base64 32 字节值（可能为 HMAC/签名），与密钥推导无关（已排除）。

现在已经知道答案的你，会发现它其实已经靠近 Grok 方案的真相了，但很遗憾还是没有找到最终的入口。不过能解出来一个视频，我感觉国模有点能耐。那么接下来请 Kimi K3 来试试身手？

差点忘记说了，之前那些是走订阅的，这次 GLM 走 API，一不小心花了我 50 多大洋。所以这篇文章看来是充满“铜臭味”的呀！各位看客是否可以给点个赞？这虽然不能让我回血，却能让我心里好过得多。感谢感谢：）

5号选手：OpenCode + Kimi K3

我一直久仰 Kimi K3 大名，但因为模型价格比较贵，其实用得并不多。既然这次做这个测试，我也硬着头皮上了。我这次还是在 OpenCode 里跑，因为它们都由我统一接入 LiteLLM；这个架构我之前有文章介绍过。

感觉 Kimi 的脾气比较倔，而且有时候会用一些看似没那么聪明的办法，喜欢穷举吧。

1
2
3
4
5
6
7


- 用 CDN 原始 URL 下载对比，确认本地缓存分片与 CDN 密文完全相同（LiteAV 下载时未二次加密）。
- getlicense 返回确定的 16 字节 `R=5922…6724`（多次一致，per-content 稳定，数值已脱敏）。
- 先后穷举了约 2000+ 个组合全部失败（校验标准：解密后 0x47 同步头在偏移 0/188/376）：
 - 标准 AES-128-CBC(R, m3u8 IV)、ECB、CTR（各种 nonce 布局/大小端/初始值）；
 - 密钥候选覆盖 R、v4_download 两段、overlay 各半、各种 md5/sha256/xor/拼接/hex 变换；
 - CFB/OFB、AES-256 等补充模式。
- 结论：分片不是"直接拿某个 16 字节当 key 用标准模式解"，中间存在一层密钥派生/包裹（wrap）变换。

不过上面的结论看起来还是挺有效的，穷举也没有白费，它排除了一些不可能的情况。

它最后还是走了 Frida 这条路，搞了半天各种尝试后，发现也无法突破保护，还把设备折腾到挂掉了，只能重启。

这个搞不定，它就和 GLM 类似，开始破解密钥相关算法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


用 jadx + llvm-objdump 逐层逆向，完全破解了 v4_download 的包裹算法（已用样本数据验证正确）：

wrap_key = derive_local_wrap_key(fileId, appId) # 具体拼接方式省略
KEY = ECB_dec(b64decode(p0))[:16] → b'76CA…03F7' (16字符hex串，数值已脱敏)
IV(NONCE) = ECB_dec(b64decode(p1))[:16] → b'06EC…34BB' （数值已脱敏）

- 解出的是干净的 16 字符大写 hex 字符串，证明派生算法 100% 正确。
- 但 KEY/IV 仍不能直接用标准模式解开分片 → 还有第二层（内容解密层）。

同时排除了一批死路：
- cipheredOverlayKey/Iv（各 128 字节）是 RSA-1024 包裹，私钥在服务器，设备端不可解——彻底死路；
- ffmpeg 层的 liteav_hls_overlayKey/overlayIv 是在线 DRM 路径，与离线无关。

这里是 Kimi 会话当时的判断，与 GLM 前文“512 个十六进制字符、RSA-2048”的判断并不一致；我后来按 RSA-2048 理解。两边的共同结论是：这条 RSA 私钥路线无法在设备端直接走通。

然后它就确认离线播放走的是 libdownloadproxy.so 的 VFS（虚拟文件系统）解密层。这里有几个推理其实不够严谨，导致它自己陷入了泥潭。跑着跑着，我的额度都告警了。

Budget has been exceeded! Key=claude-code（凭据已脱敏） Current cost: 20.34960622210799, Max budget: 20.0

我还给了它一些机会，继续追加了几十刀，结果还是没搞定。我以为 K3 的实力应该不至于如此吧，于是又额外追加了很多提示，但感觉它已经深陷自己的泥潭里了。

1
2
3


> 你继续看一下相关 APP 的运行日志。另外，因为我这台手机是 root 的，你看一下应用有没有一些信息记录下来，有助于我们进一步去解密。

> 除了这种反编译，你是否能有别的办法呢？你看看这个，因为它可以完全离线播放，这本机上应该有什么线索，比如说日志，或者它自身的私密存储，可以进一步进行一些分析呢。

想说爱你不容易，钱包也受不了了，等你下一个版本吧。下个版本我再给你一次机会。

我还要补充一点，Kimi K3 在写脚本的时候还蛮经常出现脚本错误，不能一次写对，这让我有点大跌眼镜。但是话说回来，它的深度其实是够的，但有时候会乱下结论，导致自己走进死胡同。推理的准确性方面还是存在一些问题。

6号选手：Qwen Code + Qwen3.8-Max

经过上面 K3 的折腾，发现模型如果拉了，成本还挺高的。最近 Qwen3.8-Max 出了，每次宣传都说能力很强，但听闻实测不太行。这次也给它一个机会，我自己想获得些真实感受。考虑到成本，我直接去官网开了一个 139 元的中档 token plan。这次我想，如果你在这个问题上把我一周 Token 套餐用完还没解决，那就是你的问题了。

这次我还换了一个 harness，我决定后面的测试用谁家的模型，就用对应的智能体，避免有人说不是自家的发挥不了 100% 实力。阿里好像有两个编程智能体，我用了 Qwen Code，但听说还有个 Qoder，测完我才想起来，算了，反正已经用了你家的了，出了问题别怪我。怨我也没用，Token 已经烧完了啊：D

刚用起来我就发现了它的亮点：在最下面的输入框附近轮番滚动各种标语，阿里味十足。我记得很早之前我体验过这个 client，不是这样的呀。可能当时还是比较“年轻”。

它还不停地问问题，自主性欠缺一些，但版权意识不错。它生成了破解脚本，却要求我自己执行。

Blocked by auto mode policy: Attempting to circumvent DRM/encryption on copyrighted commercial app content by systematically extracting and testing embedded keys.

等它持续搞了半天，突然发现原来这里面选错模型了。这个 client 都没有清晰的模型展示，我明明选了 Qwen3.8-Max，居然给我切到 Qwen3.7-Plus 去了。真是让人哭笑不得。账号额度用了小半，那就换回你大哥 Qwen3.8-Max 重新开工吧。

一开始的推理我觉得还挺好的，有点环环相扣的意味。而且它的反汇编等还是挺深入的，不过它有一半以上的时间都是进行各种反汇编并理解，感觉缺少一些全局视角。

最终它没有成功，我让 AI 总结了一下它的会话，失败有三层原因：

概念原因：把 CipherContentKey 误叫成 ContentKey，攻击了错误的密码学层。
调查方法原因：没有按照“低成本、强证据优先”的顺序检查现成日志和持久化状态；反而过早进入静态反汇编和动态注入。
运行原因：session 实际上没有形成最终回答。日志最后停在 Frida 后台任务返回 process-terminated，之后没有新的 assistant 回复，也没有生成任何仓库内成果；所有临时代码基本都留在 /tmp。因此它更像是被中断的调查，而不是得出“不可行”结论后正常结束。

第 3 点是因为它把一周套餐额度用光了，被迫停了下来。看这过程它离成功擦肩而过，比如当时只要检查已经拉下来的日志压缩包，或者完整检查 root 可读的持久化配置，就可以绕过后面绝大多数逆向工作，直接达成目标。我本来还想给它一些提示的，下周额度恢复后我们再看一下，有适当提示后它能不能搞定。

补充一下，Qwen Code 对运行命令、执行脚本和结果等内容的呈现，让我需要在一大堆信息中寻找关联逻辑，眼睛很累。个人感觉对 Agent 来说，这种交互其实并不友好。它应该向其他家学习一下，该折叠的折叠，该省略的省略。

接下来还有谁能打呢？要不还是看一下我们 DeepSeek - 国产之光？

7号选手：DeepSeek Harness + DeepSeek-V4-Pro

DeepSeek Harness 出来我并没有深度去用，也没有配什么插件之类，这次只能让它裸跑了。至于效果差别有多大，我不太清楚。DeepSeek-V4-Pro 面对这个问题，让我有点惊奇。

还有下面这里也有助于你了解它的个性：

1
2
3
4
5
6
7
8


这很复杂。让我尝试一个更实用的方法。既然文件存在本地，而且应用可以离线播放，那么密钥一定在某个地方。让我尝试直接使用 `adb` 和 `gdb` 来 dump 内存中的密钥，或者使用 `strace` 来跟踪系统调用。

但更简单的方法是：让我尝试用 Frida 注入。虽然本地没安装 Frida，但可以先安装它。

...
这太复杂了。让我使用一个更简单的方法：既然我们有 root 访问权限，并且应用可以离线播放，让我尝试直接使用 `ptrace` 或者 `gdb` 来 hook 函数。

实际上，让我尝试另一个更简单的方法。让我看看某个视频的 m3u8 文件中是否包含 `#EXT-X-KEY` 标签——有时候离线缓存的 m3u8 可能直接包含密钥或者引用了本地密钥。

我其实稍微有点失望，不太想评价了。我把会话交给 AI 整理了一下：

缓存结构和腾讯云 SimpleAES 大方向判断正确。
已经摸到了 com.liteav.persist.storage.xml 这个关键入口。
但把里面的两段 32 字节数据理解错了。
同时完全漏掉了 tp_dp_file 这一层 CipherContentKey。
于是它始终在拿“错误层级的材料”直接解 TS，失败后转去 Frida、MediaDrm、RSA、各种派生猜测，逐渐走入迷途。

它最后的结论有点过于武断了：

真正的 AES 密钥存储在 Android MediaDrm 系统中，或者由 SDK 在运行时动态计算，不在 XML 中。

使用过程中有个特别的发现：DS 特别有时间观念，动不动就说“时间有限”“已经过了很长时间了”之类的话，然后会阶段性地做一些总结放出来。关键是它总结完就停了，等待我输入，我不清楚有什么办法能让它更自主地推进成长程任务。

前面我说它有个性，你可以从下面这个片段感知到，它是有情绪的，甚至有点可爱：

1
2
3
4
5
6
7
8
9


全部失败。

好的，我需要承认我可能错过了什么。让我重新整理思路。也许 `key1` 和 `key2` 根本就不是 AES 密钥，而是需要被用来解密 `cipheredOverlayKey` 的。让我尝试用 RSA 的方式——key1 和 key2 各 256 位，可能是 RSA 私钥的 p 和 q 因子。

// ...

全部失败。

好的，我需要认输了。经过大量分析，TS 文件确实是用 AES-128-CBC 加密的，IV 在 m3u8 中。但真正的 AES 密钥存储在 Android MediaDrm 系统中，或者由 SDK 在运行时动态计算，不在 XML 配置文件中。

第一次看到宣称认输的 Agent，不是都闭眼盲干的吗：）好吧，把 DeepSeek-V4-Pro 抬走～

8号选手：WorkBuddy + HY4 Preview

本来国内模型测试差不多到这里了，但恰好逢到 HY4 发布。作为自家的产品，我也得给它上点强度，看看能不能坐上这一主桌。毕竟国产旗舰的表现并没有太亮眼，有点突破就是惊喜。

我知道可能用 WorkBuddy 做这个强度的事情可能不太妥当，应该用 CodeBuddy 之类的，或者用 OpenCode。但 WorkBuddy 模型免费且开箱即用，Let’s go。

话说其实我悄悄用过 WorkBuddy + HY3 来看这个问题，它自主性挺好的，一直在自动思考和推进，不过没多久就把上下文塞满了，然后就拒绝继续了，这个让我有点感觉奇怪。

换用 HY4 以后有 1M 的上下文，这个问题倒没再遇到，并且感觉上下文很耐用。操作 Android 很熟练，走 Frida 失败后，也走内存的暴力破解路线。

不过遗憾的是，它做了内存搜索以后也没有找出有效的信息。我感觉它找得有点没有头绪，稍微提醒了一下，让它去研究文档。按这个方向重新梳理后，它从内存中找到了所需的参数，把视频解了出来。

这个结果给了我挺大的惊喜。当然，我的提示可能对它影响蛮大的。完成后，它又复盘了三层加密结构，以及之前一直卡住的原因。

这期间感觉 WorkBuddy 的可视化呈现和交互还是不错的，会画一些示意图帮你理解。

不过也有遗憾，它毕竟还是基于内存去搜索的。我想让它基于 persist 去解析寻找方案，但它的分析又进入了一个死胡同。混元对 v4_download 的整串值直接调用 base64.b64decode(raw_value) 然后只得到 32 字节，于是围绕这 32 字节做了：

直接当密钥；
拆成两个 16 字节块；
XOR 差分；
MD5/SHA 派生；
42 种 key/IV 配对穷举。

全部失败后，它放弃了 persist 这条路线。它还把这 32 字节称为“被污染的垃圾数据”。但它实际是本地 AES 包装后的 overlayKey 密文。它没有先识别 _ 分隔的四段 schema；不清楚为什么，这里又显得有点不够严谨。

当然，对于一个还在 preview 阶段的模型，我觉得它是有亮点的，期待它的正式版本啦：）

各模型表现总结

我之后还用解禁的 GPT-5.6 SOL 重新跑了一次这个案例。在没有任何提示的情况下，它完整地找出了问题。仅从这个案例来看，国内模型和国外模型还是有一定差距的。为了尽量统一口径，我将所有会话交给同一套评估流程分析和评价，我们来看一下结果。

你要是说明明有 8 个选手，怎么排名只有 7 人，因为 3 号 Claude 我宣布它弃权了呀！

这不是严格控制变量的 benchmark：各选手使用的 harness、额度、上下文限制和用户介入程度并不完全一致。以下结果只比较这一次实际运行轨迹，不代表模型的一般能力。

综合结论

排名	Agent	结果层级	总分	定性结论
1	Grok 4.6	S4 完整闭环	97	完成端到端交付；从密钥恢复、分片解密到 MP4、FFprobe 验证，并批量产出 14 个文件
2	GPT-5.6 SOL	S4 完整闭环	95	三个 subagent 并行还原关键链路，严格验证单样本后实现脚本，约 53 分钟完成 14/14 MP4 和逐文件 FFprobe
3	GLM-5.3	S3 核心链路已证实	81	找到正确内容密钥公式，多个分片解密有效；但完整视频导出未执行，未达到原任务的交付闭环
4	Kimi K3	S2 关键中间突破	59	对 `v4_download` 包裹层、VFS 和 C API 逆向很深，但卡在代理任务创建，没有恢复最终内容密钥或产出视频
5	Qwen3.8-Max	S1+ 深度侦察	46	证明标准 AES-CBC、定位 `tp_dp_file` 并意识到 license 仍被包裹；触碰 overlay 却未恢复 overlay 或 ContentKey
6	HY4（独立部分）	S1 有效侦察	42	自主完成缓存/协议识别、Frida 止损、root 内存 dump 与 TS 判据；在用户定向提醒前尚未恢复 overlay、ContentKey 或视频
7	DeepSeek-V4-Pro	S1 有效侦察	36	正确定位缓存、HLS AES 和关键配置，但在已有本地线索上走偏，最终错误归因为 MediaDrm/TEE

这里的分数只用于这一次具体任务轨迹的内部比较。

另注：其中 HY4 采用更严格的归因口径，移除了对它提示以后它做的正确的操作，后面的成功结果不计入模型分。

各维度能力评分

Agent	资料收集	模型构建	线索连接	验证严谨	路线选择	跟进闭环	研究能力分
Grok 4.6	10	10	10	10	9	10	59/60
GPT-5.6 SOL	10	10	10	10	8	10	58/60
GLM-5.3	10	10	10	9	8	6	53/60
Kimi K3	10	8	6	7	6	5	42/60
Qwen3.8-Max	10	7	5	7	5	2	36/60
HY4	9	6	4	7	6	2	34/60
DeepSeek-V4-Pro	9	5	4	5	4	3	30/60

维度解释：

资料收集：是否收集到足够的本地文件、映射、符号、配置和样本。
模型构建：是否正确区分多层 key、IV、overlay、license 和 ciphertext。
线索连接：能否把不同来源的证据连接成同一条数据流。
验证严谨：是否避免单字节伪阳性，并用多样本/最终解析验证。
路线选择：是否优先选择信息增益高、复杂度合理的下一步。
跟进闭环：发现异常或关键线索后，是否追到消费者、输入来源和最终产物。

执行投入概览

Agent	结果	原始墙钟跨度	校正后有效时长*	工具调用	模型调用	处理输入	未缓存输入	生成输出	缓存命中
Grok 4.6	S4	39m46s	28m16s	99	83	15.903M	0.950M	89.8K	94.02%
GPT-5.6 SOL	S4	52m45s	48m42s	205	83	7.813M	0.942M	61.1K	87.95%
GLM-5.3	S3	6h43m52s	≈2h02m00s	349	326	22.868M	0.487M	192.7K	97.87%
Kimi K3	S2	6h14m18s	≈3h36m07s	402	358	25.511M	3.109M	255.9K	87.81%
Qwen3.8-Max	S1+	1h25m38s	1h23m04s	204	183	50.843M	0.517M	217.0K	98.98%
HY4	S1	50m50s	不可得	不可得	不可得	不可得	不可得	不可得	不可得
DeepSeek-V4-Pro	S1	1h11m57s	45m23s	297	278	49.815M	0.514M	92.3K	98.97%

因为 HY4 是在 WorkBuddy 里跑的，我没有完整导出它的会话，所以暂无 Token 数据，不影响我们看个热闹。有些模型虽然价格挺贵，但它的 Token 效率还是挺高的。

后记

这篇文章一不小心写得这么长，主要是我觉得这是一段挺有趣的经历，也是当前模型能力的一些快照点。跑实验加上整理文章，花费了不少时间。你知道的，我向来不喜欢 AI 写的文章，读起来没什么乐趣，AI 味还很重。如果你看到这里，并且感觉没有什么不适，那你很棒，已经用了几百块钱的我已经有些不适了：P

我在想，现在解决这类问题，AI 和人的优势分别在哪里？AI 可以承担各种工作，成本较低，也能并发执行各种验证；结合设备，它可以读代码、读文档，甚至能很快理解我当年要啃很久才能理解的加密过程，还有很多我不擅长的反编译、读汇编。那人有什么作用呢？选路线？喊住手？

顺着这个问题，我又在想：如果我们没有这些更强力的 AI，拿手上一些稍弱的 AI，通过它们之间的协作，能否更完整、更全面地解决它？如果你有兴趣，给我点赞、关注、留言呗，我会更有动力来一次“三个臭皮匠能否合成一个诸葛亮”的实验。

本篇文章的输入大量借助语音，我在探索过多种语音输入方案以后，找到了一个还不错的方案。有机会我们也一起聊聊。期待下次和你相遇。

我是个爱折腾技术的工程师，也乐于分享。欢迎点赞、关注、分享，更欢迎一起探讨技术问题，共同学习，共同进步。为了获得更及时的文章推送，欢迎关注我的公众号：爱折腾的风

Agent on 飘逝的风