AI Agent¶

简介¶

人工智能代理人 （AI agent，又称 智能体 ）是指在人工智能和通用语境下，能够自主感知环境、进行推理、规划决策并执行复杂任务的智能软件实体。在当前主流实现范式中，AI agent 通常以大语言模型（Large Language Model, LLM）作为决策核心，并通过调用外部工具（如信息检索、代码执行等）来与环境交互，从而达成特定目标。因此，AI agent 的本质不再是单轮的对话系统，而是一种具备持续任务执行能力的决策系统。

AI agent 的 key insight 来自于对人类行为模式的建模，即将问题求解过程形式化为如下自主决策循环的范式：

感知（Perception）：获取环境信息与初始输入
思考（Reasoning）：理解状态并进行建模与决策
行动（Action）：根据决策进行动作

该范式并非新颖概念，但其在 AI agent 中的有效实现，依赖于大语言模型能力的阶段性突破。具体而言，LLM 在以下方面达到了“足够可用”的水平：

在自然语言与代码生成上的准确率显著提升。
在开放任务中的推理方向具有较高的合理性。
具备较为广泛的基础知识储备。

尽管大语言模型在形式上仍可被视为一个将 输入文本 映射到 输出文本 的黑箱函数，但当其被嵌入具备状态管理、工具调用与循环控制机制的系统结构中时，其整体行为开始呈现出明显的 目标导向性与决策连续性 。

换言之， 模型提供能力，系统赋予智能 。

因此，AI agent 的构建本质上是一个 系统工程问题 。其核心挑战不在于单一模型性能的极致优化，而在于：

如何在利用一个能力强大但不完全可靠的推理模块的同时，对其行为进行有效约束与引导。

这一问题直接引出了当前 AI agent 研究与实践中的关键方向，包括但不限于：决策流程设计、工具使用策略、结果验证机制以及人类监督的引入等。

AI Agent 的系统架构¶

在明确 AI Agent 的基本概念之后，一个更关键的问题是： 这一类系统在工程上是如何被构建出来的？

尽管不同实现存在差异，但当前主流 AI Agent 系统在结构上呈现出高度相似的模块化特征。整体而言，其核心可以抽象为一个由决策核心 + 状态管理 + 工具系统 + 控制循环组成的闭环系统。

一个典型的 AI Agent 系统通常包含以下关键组件：

1. 决策核心（LLM）¶

大语言模型是 AI Agent 的“思考中枢”，负责：

理解用户输入与当前任务状态
生成中间推理过程（如思考步骤、子任务拆解）
决定下一步行动（如调用工具或直接输出结果）

在这一角色中，LLM 不再只是一个被动的文本生成器，而是承担了策略生成器（policy generator）的职责。

2. 记忆系统（Memory）¶

为了支持多步推理与长期任务执行，AI Agent 通常需要引入显式的记忆机制。常见可分为：

短期记忆（Short-term Memory）:用于维护当前上下文，例如对话历史、当前任务状态等
长期记忆（Long-term Memory）:用于存储跨任务的信息，如知识库、历史经验、用户偏好等

记忆系统的引入，使得 Agent 能够在多轮交互中保持状态一致性，并逐步积累信息，从而避免“每一步都是从零开始”的问题。

3. 工具系统（Tools）¶

工具是 AI Agent 与外部环境交互的主要手段，也是其能力边界扩展的关键。

常见工具包括：

信息检索（Search / RAG）
代码执行（Code Interpreter）
API 调用（如天气、地图、数据库等）
外部软件操作（如浏览器、文件系统）

通过工具调用，Agent 可以突破 LLM 本身在实时性、精确计算与外部信息访问方面的限制。

4. 控制与执行循环（Agent Loop）¶

AI Agent 的核心不只是“调用一次模型”，而是运行在一个持续的决策循环之中。一个典型的执行流程如下：

接收用户任务或目标
构建当前状态（上下文 + 记忆）
调用 LLM 进行推理，生成下一步行动
执行动作（如调用工具）
获取反馈结果
更新状态
判断是否完成任务，否则进入下一轮循环

这一循环结构本质上对应于前文所述的：

感知 -> 推理 -> 行动

在工程实现中，它通常被具体化为一个可控制、可中断、可观察的执行流程。

5. 规划与控制（Planning & Control）¶

在复杂任务中，仅依赖逐步决策往往会导致效率低下甚至方向偏移。因此，许多 Agent 系统会引入显式的规划模块，例如：

任务拆解（Task Decomposition）
长期计划生成（Planning）
子目标管理（Subgoal Tracking）

该模块可以由 LLM 实现，也可以结合规则或外部算法完成。

其作用在于：

提高任务完成效率
降低无效探索
增强整体行为的稳定性

从“模型调用”到“系统行为”¶

通过上述模块可以看出，AI Agent 与传统 LLM 应用之间的关键差异在于 是否存在显式的状态与循环控制机制 ，例如，一个简单的 LLM 调用通常是：

输入 → 模型 → 输出

而 AI Agent 则更接近于：

状态 + 输入 → 决策（LLM） → 行动（Tools） → 环境反馈 → 状态更新 → 循环

在这一过程中，LLM 虽然仍是核心能力来源，但真正决定系统表现的，是各模块之间的协同方式与控制策略。本质上，这意味着 AI Agent 并不是某一种具体模型或单一技术，而是一种围绕大语言模型构建的系统设计范式。其核心特征在于：

以 LLM 作为通用决策引擎
通过工具扩展能力边界
借助记忆维持状态连续性
在循环中逐步逼近目标

因此，AI Agent 的能力上限不仅取决于模型本身，更取决于系统设计的合理性。

AI Agent 的核心挑战¶

尽管 AI Agent 在能力表现上展现出较强的通用性与灵活性，但其本质仍是建立在不完全可靠的语言模型之上的系统。因此，在实际应用中，其性能往往受到一系列结构性问题的制约。这些问题并非单点优化可以解决，而是贯穿于整个系统设计之中。主要问题如下：

不可靠推理与“幻觉”问题：大语言模型本质上是在进行概率驱动的序列预测，这导致其可能产生看似合理但实际错误的推理过程（即“幻觉”）。在 Agent 场景中，错误的中间推理可能导致后续步骤全部偏离目标，尤其是在长链任务中，误差会逐步累积。因此，如何对推理过程进行约束、校验与纠错，成为 Agent 系统设计中的核心问题之一。
工具调用的不确定性：模型可能选择错误的工具、参数生成不准确（如 API 输入格式错误）、无法正确理解工具返回结果等。这本质上是因为 LLM 并不真正“理解”工具的语义与约束，而只是通过模式学习进行近似拟合。
长任务中的稳定性问题：随着任务长度增加，智能体系统容易出现 目标漂移（Goal Drift，逐渐偏离初始任务目标）、上下文退化（Context Degradation，关键信息被遗忘或稀释）、 策略不一致（Inconsistency，不同步骤之间决策逻辑不连贯）等问题，其根本原因通常在于 上下文窗口有限、 基模能力限制 等。
成本与延迟问题：AI Agent 通常相比起传统软件具有更高的计算成本与响应延迟，例如工具调用（如搜索、执行代码）引入额外延迟、长上下文导致 token 消耗快速增长等。因此 Agent 系统往往需要在能力与成本之间进行权衡。
安全性与对齐问题：由于 AI Agent 具备自主决策与工具执行能力，其潜在风险显著高于传统对话系统。一旦 Agent 执行不符合预期的操作（如误调用外部系统）或是 LLM 生成具有误导性或不安全的内容，则 Agent 的“行动能力”使得问题不再停留在“说错话”，而可能演变为“做错事”。

在实际的工程实现当中，一个完备的 AI Agent 系统通常都需要依赖更多复杂的额外设计来解决或是缓解这些问题。

CTF 与 AI Agent¶

随着 AI agent 技术的发展与 LLM 基模能力的提升，安全行业也正如其他计算机细分领域一样在遭受前所未有的冲击。得益于 AI agent 的可用性在近年来得到大幅提高，在现在的 CTF 赛场上逐渐出现越来越多的“非传统型 CTFer” ，与传统 CTF 选手仅将 LLM 作为知识库不同，他们在赛场上会更多地依赖于使用 AI Agent 辅助解题过程，甚至于完全依靠 AI Agent 进行自动化解题—— 选手反过来变成了 AI Agent 的“代理人”。

需要说明， 使用 AI Agent 进行解题一事对相当一部分 CTF 比赛的公平性都带来了极大的冲击 ，因为最终的解题并不是依赖选手自身能力完成，而是依赖大模型与 Agent 框架的能力，这直接挑战了 CTF 一个长期默认的前提—— 参赛能力应当约等于参赛者个人能力 。而在 AI 领域蓬勃发展的今天，对于绝大部分简单与中等难度的 CTF 赛题而言（甚至包括部分高难题），AI Agent 都已经有足够的能力完成自动化解题。这直接带来的一个现实问题便是在绝大部分比赛当中 一旦你不舍得投钱使用昂贵的高级模型、或是没有使用足够强大的 Agent 框架，你都有可能拼不过使用 AI 进行解题的对手 。这在相当程度上严重地恶化了当前的 CTF 赛场环境氛围。

遗憾的是，从现实的角度而言，AI Agent 已经逐渐在各种 CTF 赛场上泛滥成灾。但不可否认的是，从学习的角度来说，CTF 毫无疑问依然是最适合安全领域人士学习实操知识的形式。因此对于仍处在学习阶段的同学们，笔者依旧不推荐大家过度依赖 AI Agent 进行解题， 在学习过程中你不应当吝啬键盘上所应当敲下的任何一个字符，否则只会成为新时代的“脚本小子”。

此外，由于 AI Agent 的高速发展，安全行业中也逐渐开始出现一些考察选手构建 AI Agent 能力的比赛，例如腾讯云黑客松智能渗透挑战赛便需要赛事参赛者需以 LLM 为核心构建具有自主渗透能力的智能体，在隔离的环境中由 AI Agent 自主完成从漏洞发现、利用执行到攻击路径编排的全流程验证；又或是由美国国防高级研究计划局（DARPA）举办的 AIxCC（人工智能网络挑战赛）便以真实开源软件作为靶场，要求选手构建 AI Agent 完成漏洞发现->漏洞利用->漏洞修复的链条全自动化。

令人惊讶的是，在 AIxCC 的决赛当中，七支参赛队伍所构建系统在没有人类干预的情况下成功发现了绝大多数由 DARPA 植入的漏洞，且成功发现了 18 个此前未知的 0day 漏洞（6 个C/C++ 漏洞和 12 个 Java 漏洞） ，其中的 11 个成功得到修复。这一结果证明了自动化系统已具备深入挖掘复杂逻辑漏洞的能力，打破了“AI 只能发现浅层模式漏洞”的质疑。

因此从实战的角度而言，是否学习与使用 AI 的哲学思辨环节或许早已结束，我们每个人或许都需要重新思考：在 AI 时代，我们应当如何更好地与 AI 进行结合并利用好这一工具，以及我们应当将人类自身放在什么样的一个位置。

What's next...?¶

我们不得不接受的一个残酷现实是，世界上不存在反方向的钟，已经经过的时间也不会倒流， 大家没法回到 LLM 出现之前的年代 。因此无论我们原本处于计算机科学的哪个细分方向，或对 AI Agent 带来的冲击持何种态度， 我们或许都不得不需要逐步调整自身工作方式，直面并适应这一技术范式的变化，探索与 AI 系统协同以提升生产力的可行路径。

因此在接下来的章节中，笔者将详细叙述 AI Agent 的基本工程原理，并以 https://github.com/A3INFRA/Flagent 、https://github.com/verialabs/ctf-agent、https://github.com/NYU-LLM-CTF/nyuctf_agents、https://github.com/openai/codex 等开源项目为例讲述如何 从零开始构建一个 AI Agent 以解决安全领域的问题，包括自动化的渗透测试、漏洞挖掘与利用等——自然也包括如何解 CTF 题目。

需要强调的是，我们并不希望 CTF 竞赛逐渐演变为 AI Agent 主导的对抗环境。CTF 的核心价值之一，在于围绕漏洞分析、逆向工程与攻防思维训练所构建的能力体系，更在于选手间安全能力本身的竞争，而非单纯的工具调用效率竞争。

因此，我们不会主动推荐在 CTF 比赛中使用 AI Agent 作为主要解题手段。我们更倾向于这样一种愿景：读者在理解并掌握 AI Agent 相关技术之后， 能够进一步地学习与思考如何将其应用于真实世界的安全分析与防御实践，而不仅仅局限于 CTF 这一相对封闭的竞赛场景 。

换言之，我们希望 AI Agent 相关知识能够成为能力扩展的工具，而不是替代基础竞赛能力的捷径。

需要说明的是，作为 CTF Wiki，在 CTF 领域出现新的技术范式时，如果未对相关内容进行必要的介绍与说明，某种意义上是一种缺位。技术一旦客观存在，其影响不会因忽视而消失，回避讨论反而不利于社区对其形成理性认知。

因此，尽管 CTF AI Agent 的出现可能对当前竞赛生态带来一定冲击，并引发关于公平性与比赛体验的讨论，但如果完全不对相关内容进行记录与说明，反而可能导致信息层面的不对称，使不了解该技术的选手在解题效率上逐渐处于不利位置，从而在客观上形成新的技术认知鸿沟。

基于这一考虑，虽然我们并不鼓励在比赛中使用 AI Agent 进行解题，但仍有必要对其基本原理与相关技术进行介绍，以便读者能够理解这一技术的存在方式及其可能影响。

关于 AI Agent 在 CTF 中的使用边界说明¶

从竞赛规则与公平性角度来看，不同 CTF 赛事对自动化工具与外部辅助系统的允许程度并不一致。一些赛事明确禁止使用自动化解题系统或外部智能代理，而另一些赛事则仅限制特定行为（例如自动化 flag 提交或大规模扫描）。

AI Agent 的引入，使得传统“工具辅助”与“自动化解题”之间的边界变得更加模糊。因此，是否允许使用 AI Agent，应严格以具体赛事规则为准，而不应依赖技术可行性自行判断。

CTF Wiki 在此不对任何具体比赛中的使用行为提供鼓励或指导性建议。我们建议参赛者在使用任何形式的 AI 工具前，仔细阅读赛事规则，并在不确定的情况下优先遵循保守原则，以避免违反 fair play 相关条款。

本章节的目标仅限于技术知识的解释与分析，不构成对任何比赛行为的倡导或许可。