文章总结： 文章复盘了阿里云CTF2026中承影Agent的失败经历。核心在于过度复杂的工程架构导致多Agent决策冲突及上下文管理失效，致使0解题。对比极简方案发现简单结构更有效。作者总结出当前阶段单一决策优于多层协作，上下文管理是底座而非优化项，AI生成代码必须人工Review，且人机协同上限高于完全自动化。 综合评分： 88 文章分类： AI安全,CTF,实战经验
阿里云 CTF 2026 失败复盘：当我试图用复杂架构”驾驭”承影 Agent
原创
yhy0 yhy0
谁不想当剑仙
2026年2月1日 23:10 湖北
阿里云 CTF 2026 结束了。
我的 承影 Agent（CHYing-Agent）26 道题，一道都没解出来。
https://www.aliyunctf.com/leaderboard/
这个结果说实话有点刺眼。
更刺眼的是： 在不久前的腾讯云黑客松上，几乎同一套思路的架构，拿到了第 9 名。 而这一次，我还让 AI 帮我”优化”了不少代码。
7天Top 9：我如何让 Claude 手搓一个全自动 CTF 选手
结果反而更差了。
这篇文章不是甩锅模型，也不是抱怨题目难，而是一次彻底的失败复盘。 现在回头看，这次失败不是”没调好参数”，而是我在 Agent 设计上，走了一条当下并不适合我的路。
一、这次失败，到底是什么性质的失败？
先说结论，但这个结论只对我自己成立：
这不是模型能力不够的问题，也不是运气问题，而是我试图用工程复杂度去换 Agent 能力，结果复杂度反过来吃掉了能力。
换句话说： 承影 Agent 不是被题目打败的，而是被我亲手加上的系统复杂度”拖死”的。
二、V2 架构：Main Agent + Advisor 的”参谋制”
最早的设计，是一个我当时觉得”很合理、也很优雅”的参谋结构：
┌─────────────────┐ 建议 ┌─────────────────┐
│ Advisor │ ──────────────▶│ Main Agent │
│ (顾问 Agent) │ │ (主执行者) │
│ 专业化 Prompt │◀────────────── │ 决策 + 执行 │
└─────────────────┘ 咨询 └─────────────────┘
当时的设想是：
- Advisor 负责”专业判断”（Web / Pwn / Reverse）
- Main Agent 负责综合决策和执行
- 像一个人类团队：有人出主意，有人拍板
但真正跑起来之后，问题很快暴露。
问题不在于 Advisor 不够聪明
而在于：我让两个 LLM 同时参与了同一层级的决策。
LLM 不是函数调用，它有自己的推理路径和判断偏好。
实际表现是：
- Advisor 给了明确建议
- Main Agent 依然”有自己的想法”
- 两套判断在不断互相覆盖
本质上，我是在让两个不可预测的系统，彼此制衡彼此的不可预测性。
这直接导致：
- 行为不稳定
- 难以复现
- Debug 成本极高
现在回头看，这种多 Agent 协作的难度，远超我当时的预估。
三、我亲手制造的”Agent 失忆”
V2 里还有一个问题，比”不听建议”更致命：上下文压缩。
当时我担心上下文爆炸，让 AI 帮我实现了一个”压缩机制”。 想法没错，但实现非常粗糙。
主要问题包括：
- 拍脑袋定压缩阈值，没有对齐真实上下文窗口
- 人工剪裁信息，但我并不知道哪些信息对 LLM 是关键
- 压缩逻辑本身缺乏充分验证
直接后果是：
承影 Agent 会在同一道题里，反复执行已经失败过的操作。
不是它笨，是我让它忘了。
当 Agent 连”刚刚试过什么、为什么失败”都记不住时， 推理能力再强，也无从发挥。
这件事让我第一次非常清楚地意识到：
在 Agent 系统里，记忆不是优化项，是底座。
四、V3：比赛第一天晚上，断剑重铸
为了解决这些问题，我在比赛第一天的晚上临时重构了一版架构（V3）。
某种意义上，这是一次”断剑重铸”—— 不是为了让承影更锋利，而是让它至少还能握在手里。
核心改动只有两点：
- 只保留一个决策者
- 不再自己管理上下文
┌──────────────────────────────────────────┐
│ Brain (Claude SDK) │
│ 唯一决策者，直接分发任务 │
│ （复用 Claude 的上下文管理能力） │
└──────────────────────────────────────────┘
│
┌───────────┼───────────┐
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│PoC Agent│ │Docker │ │C2 Agent │
│Python │ │Kali工具 │ │MCP工具 │
└─────────┘ └─────────┘ └─────────┘
思路很直接：
- 决策只发生在一个地方
- 工具只负责执行
- 上下文交给成熟 SDK，而不是继续自己造轮子
我还保留了一个”止损”思路： 当 Agent 明显卡死时，引入反思环节，强制跳出当前路径。
class ReflectionAgent:
def reflect(self, attempt_history):
"""
分析失败原因，强制打断当前思路
"""
但这版架构，真的解决问题了吗？
说实话，我现在无法给出答案。
比赛已经结束，而官方是否会在赛后开放题目，目前也不确定。 如果题目不开放、环境不复现，这一版架构就没有被真正验证的机会。
从我自己的判断来看，它至少在方向上试图解决的是结构性问题： 减少决策层级、避免上下文被人为破坏，而不是继续往系统里堆复杂度。
但这不是结论，只是判断。
也借这个机会想提一个建议： 对于 Agent 选手来说，如果比赛结束后能开放题目或提供 Docker 镜像，复盘价值会非常高。
另外，如果比赛期间能提供一个官方 API 获取题目信息和靶场状态，而不是需要选手手动打开靶场、获取信息，会对于 Agent 参赛选手更加友好。
否则，很多失败，连复盘的起点都不存在。
五、另一个更隐蔽的问题：AI 写的代码，我没看
这次比赛还暴露了一个更现实的问题：
我让 AI 帮我写了很多代码，但我没有认真 review。
原因也很直接：
- 每次完整测试都需要烧 token，费钱
- 为了快，我选择”先信它”
- 改动多了之后，自己逐渐失去了对系统行为的掌控
赛后回头看代码，问题非常多：
- 旧逻辑残留，新架构名存实亡
- 防御性代码堆积，执行路径复杂
- 实现细节和我脑子里的设计并不一致
这是一次非常典型的 AI Coding 技术债——代码是 AI 写的，但债是我欠的。
我一边在”设计承影 Agent”， 一边在”用 Agent 写承影 Agent”， 但我只盯着前者。
这是一个必须承认的失误。
六、对比：极简方案 vs 多 Agent 协同
一个小插曲
比赛第一天下午，挫败感很强，我去财大小吃街散心、吃饭。
走之前，我随手给 CodeBuddy 布置了一道题[RAG-投毒挑战]——只提供了题目的最基本信息，没有任何提示。
回来一看：它解出来了。
说实话，这比承影 agent 0 解本身更让人心里发凉。
朋友的极简方案
有意思的是，我一个朋友用的方案极其简单：
- 一个 Agent
- 完全放权，让它自己理解、自己执行、自己调整
┌─────────────────────────────────────────┐
│ Agent │
│ │
│ 理解题目 → 制定策略 → 执行 → 复盘 │
│ │
│ 工具：Shell / Python / 文件系统 │
└─────────────────────────────────────────┘
结果：解出了 4 道题。
他的 Agent 并不比我的“聪明”， 但它有一个明显优势：
它没有被我亲手绑住手脚。
- 所有信息都在一个上下文里
- 没有协作损耗
- 决策路径清晰、可追踪
这一点，比任何所谓“多 Agent 协同”的理论优势都更直观。
多 Agent 也不是错
赛后我进一步了解，本次比赛第三名使用的，是一个多集群交互的 Agent 协同系统。
围观地址：https://www.aliyunctf.com/teams/113177574959487123
但和我原先理解的不完全一样：
人本身也是系统的一部分。
在他的这次比赛方案里：
- 人参与关键决策
- 人判断策略是否继续执行
- Agent 更多承担辅助执行、信息整理和路径扩展的角色 (猜测)
换句话说，这是一套“人 + Agent”协同系统，而不是“完全无人化”的自动化解题机器。
这件事让我意识到一个之前被我低估的问题：
在现阶段，完全不引入人的 Agent，分数上限是明显偏低的。
回看承影 Agent V2，它本身就是一个多 Agent 系统：
- Advisor 负责专业判断
- Main Agent 负责决策和执行
- 各模块之间需要协调和信息传递
问题在于：
我没能让这套多 Agent 系统稳定运转。
所以问题不在于”多 Agent 对不对”，而在于：
- 决策权是否被正确地保留在合适的位置
- 复杂性是被结构化吸收，还是变成系统噪声
- 人机协同的边界是否清晰
七、总结
这次失败不是白输的。
它至少让我非常确定几件事（只对当前的我成立）：
- 多 Agent 协作在决策层面极其考验工程能力
- 上下文管理是 Agent 系统的底座，而不是优化项
- AI 写的代码，必须 review
- 在我目前的实践阶段，简单结构更容易转化为有效战斗力
这次输了，但问题大约看清了。等待断剑重铸之日。
时维乙巳，序属季冬，十四日记于阿里云 CTF 赛后
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：谁不想当剑仙 yhy0 yhy0《阿里云 CTF 2026 失败复盘：当我试图用复杂架构”驾驭”承影 Agent》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论