第三届 TCH，第 60 名，以及最近对 Agent 的一点想法

原创

yhy0
yhy0

谁不想当剑仙

2026年10月20日 23:59
湖北

去阅读

第三届腾讯云 TCH 比赛结束了。

成绩呢，第 60 名。模型用的是 DeepSeek Flash，消耗了接近 3 亿 Token，成本七十来块钱。

https://tsecbench.zc.tencent.com/events

本来不想再写复盘的，成绩太差了，没脸写，写出来感觉也是失败者的哀嚎。

TCH 已经发展到第三届了。我的 Agent 也从 ChYing、ChYing V2，到现在的 TaiE，说实话目前也没什么特别值得介绍的。底层就是一个 Pi，极简的 Agent，搭配 Bash、文件读写这些最基础的工具。

从第二届结束到现在，我放弃了之前的 ChYing，另起炉灶做了 TaiE。

统计了一下 Git 提交：

762 次 Commit，时间跨度 2026-06-08 到 2026-10-20，约 135 天，平均每天 5.6 次提交。

前前后后折腾了很多东西，也尝试过不少思路，但最终还是选择了 Pi 作为底层，只保留它最基础的核心能力，然后在外面加了一层 Task 系统。

就拿这次 TSEC 解题来说，整个执行过程其实很简单：

1. 脚本一次性拉取平台所有题目，每道题创建一个独立的 Task。
2. 同时运行 3 个 Worker Agent，分别认领题目、独立解题。比赛限制最多同时运行 3 道题。
3. 每次 Worker 的解题时间限制为 20 分钟。能解出来就提交 Flag；解不出来，到时间强制结束，并由独立的 Agent 整理交接文档（Handoff）。
4. 优先让所有题目至少尝试一遍。第一轮没解决的题目，等后续轮次再由一个全新的 Worker 认领，读取之前留下的交接文档，重新分析、继续解题。
5. 就这样不断循环，直到比赛总时间结束。

基本就这些了。

没有什么复杂的多 Agent 组织结构，也没有预先设计好每道题应该怎么解，更没有什么知识库、Skills，只有一份 Kali 环境说明。

一道题就是一个 Task，Worker 领走，做完验收，没做完就交接，后面换一个 Agent 再来。

最终成绩如上所述，一般，没达到预期。

所以我也没什么底气证明下面这些对 Agent 的认识是正确的。你可以一笑而过，也可以当作一个比赛失败者的犬吠。

先看看比赛数据

让 CodeBuddy 统计了这次比赛前 100 名的 Token 消耗和得分情况。

第一名得分率 80.18%，第一百名 57.40%。

按照 Token 消耗区间统计：

还有两个极值：

• Token 消耗最多的队伍：45.82 亿 Token，得分率 79.29%。
• Token 消耗最少的队伍：1.85 亿 Token，得分率 65.38%。

前十名的 Token 消耗也很有意思：

5 支队伍超过 20 亿 Token，另外 5 支在 10～20 亿之间。

从这份数据看，Token 消耗较高的队伍整体成绩也确实更好一些。

通过这些数据，我有了个比较直观武断的看法：

在这次比赛使用的模型能力相对接近的情况下，只要给模型足够的时间、尝试次数和计算资源，这次比赛的未解出来的一部分题目应该是有机会解出来的。

我跟前面队伍的差距，可能就在这里：

TaiE 目前一道题同时只有一个 Worker 在解，而那些消耗十几亿、几十亿 Token 的队伍，我猜测可能会有更多并发探索、多个 Agent 同时推进同一道题的情况。

当然这只是猜测，我也没看过其他队伍的具体实现。

姑妄言之：大力出奇迹。

比赛结束到现在也到了第二天了，目前还没看到类似第二届淚笑师傅“黑板架构”那样让我眼前一亮的设计分享，也可能大家都在等决赛结束后再公布。

我现在对 Agent 的看法

这几个月折腾下来，我越来越觉得，随着模型能力不断发展，Agent 自身的架构已经没那么重要了。

一个足够简单的脚手架，给模型最基础的外部环境操作能力，比如读取文件、编辑代码、运行 Bash，就已经够了。

其他的什么架构之类的都是无关紧要的了，对于现在的模型能力来说，大部分的设计架构就是在拖后腿。

TSEC 本身有一个模型能力测评，基础 Agent 使用的就是 Pi。

https://tsecbench.zc.tencent.com/#leaderboard

在 TSEC 平台上，如果跑分不接近对应模型的分数，而且你的 Token 消耗还多出了几个量级，那就说明你的架构可能在拖大模型的后腿，模型的能力被你的架构束缚了，我认为你的 agent 设计差不多可以丢掉了。

以前我总在想，应该怎样设计一个更强的 Agent。

现在我反而觉得，Agent 应该逐渐成为一种基础的执行单元。

它可以是 Pi，可以是 Codex，也可以是其他 Agent。我们不一定要关心它内部怎么思考，只需要给它一个明确的任务、合适的工具和执行环境，让它尝试解决问题。

真正值得花时间的，可能是另外一件事：

那些以前需要人来完成、很难完全自动化的事情，应该怎样拆出来，交给 Agent 去做？

AI First，Tools First

Yakit 的 V1ll4n 师傅之前在群里说过一句话，对我的启发很大：

AI First，Tools First。

我之前一直想着让一个 Agent 系统做所有事情。

从收集信息，到执行工具，再到分析、验证、生成报告，所有工作都交给 Agent 自己决定。

但发现，这种方式存在一个很现实的问题。

现阶段的 AI 还没有发展到 AGI。它确实已经很擅长像人一样，根据已知信息思考、判断、行动，但这些行动本身仍然带有不稳定性和概率性。

同样的任务，这次它可能会调用一个关键工具，下次就忘了；这次会仔细验证某个问题，下次可能只看了几眼就觉得可以结束。

我之前却总想让这样一个概率性的系统，稳定、完整地执行一整套复杂工作。

这是不合理的，这是 AI 时代的人类幻觉。

所以最近我开始调整思路。

能用传统代码和工具稳定完成的事情，为什么一定要交给 Agent？

例如资产收集、端口扫描、指纹识别、CodeQL 建库、静态扫描，这些都有成熟的工具和确定性的执行流程。

让 Agent 反复决定要不要调用、什么时候调用、调用什么参数，真的有必要吗？

Agent 更适合做的，可能是那些需要理解信息、分析线索、提出假设、尝试验证的工作。

而其他部分，就交给原本已经足够成熟的工具系统。

从一个万能 Agent，到多个专业系统

以 SRC 讨饭为例。

我最开始的想法其实很简单。

我输入一句话：

“去 HackerOne 赚钱。”

然后希望 Agent 自己完成资产收集、漏洞挖掘、验证、报告、提交。

为了实现这个目标，我给 Agent 内置了大量工具、SRC Skills，设计了各种工作流程。

但实际运行下来，结果非常不稳定。

一些工具这次会调用，下次可能就不用了。一个目标这次分析得很深入，下次却很早就结束了。

更重要的是，有些工作本来就不应该让 Agent 每次从头做。

于是最近我把之前做的 SRC 资产管理系统重新复活了，并起了一个新的名字叫 青萍·QPing。

它是一个独立的系统服务，有自己的数据库、执行流程 和 Web 界面。

资产收集、子域名发现、端口探测、指纹识别、持续扫描、资产变化追踪，这些事情交给 QPing 自己完成。

然后根据扫描结果，自动挑选有研究价值的资产，通过 API 创建一个个 Task，提交给 TaiE。

TaiE 不需要再从头做一遍资产收集，只需要从 Task 系统中认领研究任务，根据已有信息去分析、验证。

做完了就返回结果，没做完就留下交接文档，等待下一次继续。

这样一来，资产收集是否完整，不再取决于某次 Agent 有没有记得调用某个工具。

最后

这几个月折腾下来，我越来越觉得，我们可能一直低估了基础工具的价值。

模型越来越强，通用 Agent 的底座也越来越成熟。继续给 Agent 增加更多角色、流程和 Prompt，带来的提升还能有多少？相比之下，那些真正好用、稳定可靠的专业工具和基础服务，反而更加值得投入。

「君子生非异也，善假于物也。」

以前总想着让 Agent 自己完成所有事情，现在反而觉得，工具决定了 Agent 探索世界的边界，而我们应该做的，是不断拓展这个边界。

这也是我最近重新做SRC 资产管理系统青萍·QPing，以及代码审计系统纯钧·ChunJun 的原因。

至于 TaiE，就继续保持简单。让专业系统做好专业的事情，让 Agent 在需要的时候接手，专注于解决某一个具体的任务。

最后，也感谢腾讯云鼎实验室举办比赛，并提供 TSecBench 这样一个评测平台。虽然这次成绩一般，但能有这样一个环境，让大家拿自己的 Agent 真正跑一跑、比一比，还是挺难得的。

这几届比赛下来，也确实推动了国内 AI 安全攻防方向的发展。出现了好几位“百万撤离”的选手，也有一些国际上引起广泛关注的事件。

TSecBench：https://tsecbench.zc.tencent.com/