AI安全审计智能体核心方法论(第二部分)

如果第一部分主要是关于方法论的主干，那么第二部分则是关于已经生长出来、但尚未完全定型的分支。

这些问题比第一部分的问题更分散、更犀利。它们可能还没有完全定论，但很可能决定了未来两三年内 AI for Security 的实际走向。

第一部分主要关注为什么旧的重框架、重预处理路线正在成为一个糟糕的默认选择，以及如果你今天想构建自己的 AI 安全工具，正确的起点是什么。

但仍有几个问题悬而未决。例如：如果我们真的希望 Agent 实现自我进化，这种进化的真正关键是什么？为什么最难的部分往往不是让中间产物可观察，而是设计一个能够干净进化的 Harness？技能是为人类编写的，还是为大语言模型 (LLMs) 编写的？一旦发现漏洞，去重、验证和 Proof of Concept (PoC) 应该如何融入工作流？

这些问题看起来不如框架选择那么显眼。但很多时候，它们正是决定最终系统仅仅是一个 Demo 还是实用工具的关键。

1. Agent 真正实现自我进化意味着什么？

第一部分只部分回答了一个问题：如果我们想要一个 Agent 真正实现自我进化，进化的关键是什么？常见的反应是：只要清晰记录中间过程，收集数据，且每一步都可观察，那就足够了。

但更深层次的问题是稳定性。我不再认为最大的危险仅仅是某次 偏离航向。自然界的进化从未遵循完美的直线。对于 Agent 来说，单次偏差或一些暂时无用的增加并不是最可怕的。

真正的麻烦通常源于以下两种结果之一：

1. 回归 (Regression)：系统以前能做的事情变得不能做了，以前能捕获的问题消失了。
2. 不受控制的膨胀 (Uncontrolled Bloat)：Prompt 变得越来越长，工作流变得越来越重，系统变成了一个脆弱的、缝补在一起的庞然大物。

进化的三大支柱

如果从进化的视角来看，一个能够持续进化的系统需要：

• 变异 (Variation)：不断尝试新的 Prompt、技能和策略。
• 选择 (Selection)：通过 Benchmark、人工评审或明确的反馈来判断价值。
• 继承 (Inheritance)：有用的经验必须被保留和追踪，而不是从零开始重建。

自我进化不仅仅是“多次改变”。它是要在变化、评估和保留之间创建一个稳定的闭环。一个可行的系统不是一个永不犯错的系统，而是一个能够检测、回滚、修订并继续进化的系统。

模型能力 vs. 系统边界

有时“无法解决”并不意味着方法错误。许多看起来像是系统能力边界的东西，实际上只是当前模型的能力边界。一个好的系统应该为明天模型能力的提升留出空间。

伪进化的风险

系统存在一种风险，即变得非常擅长“考试”而不是工作。在 AI for Security 中，系统可能会学习公开数据集的分布，而不是真正的能力。成熟的自我进化不能围绕显眼的公开 Benchmark 进行；真实世界的案例才是告诉你它能否应对未知的关键。

2. 设计一个真正能够进化的 Harness

真正的困难不在于观察发生了什么，而在于了解为什么系统可以持续以稳定的方式进行修改。你需要 决策产物 (decision artifacts) —— 了解为什么要采取某种策略，激活了哪些规则，以及某项更改旨在修复哪一类 Bad Case。

Prompt 的组合与隔离

自然语言 Prompt 本质上不是模块化的。增加一句话就可能改变整个推理路径。因此，“电路化 (circuit-ness)”应该来自围绕 Prompt 的 Harness —— 即 Prompt 如何组装、激活和验证 —— 而不是文本本身。

真正的隔离意味着只有在真正需要时才读取某些内容。将 Prompt 拆分为块只是维护端的隔离。模型端的隔离需要一个选择器 (Selector) 或门控层 (Gating layer)，仅在与当前回合相关时才加载规则。

工程方向：内核与协议

一种稳健的工程方法包括：

• 内核 (Kernel)：一个小的、冻结的 Prompt，包含稳定元素（目标、工具协议）。
• 协议/规则 (Protocols/Rules)：具有明确元数据（触发器、范围、预算）的小型、进化单元。
• 选择器 (Selector)：根据当前阶段和上下文决定加载哪些协议。
• 验证器 (Verifier)：在代码中而非 Prompt 中处理输出验证、Schema 合法性和冲突检测。

3. 技能是为人类编写的，还是为 LLM 编写的？

技能和 SOP 正在使人类经验显性化。但今天的技能正越来越多地为 LLM 执行而编写。人类使用手册来复现经验；LLM 使用技能来复现执行模式。

自然语言程序

未来真正有效的经验表达可能并不总是对人类友好的。它可能不再以可读性优先，而是变得更接近于模型的自然语言程序。人类可能无法完全理解 AI 为自己编写的技能的内部结构或优先级排序。

人类角色的转变

如果技能向 LLM 优化的执行方向进化，人类的角色将从“编写过程”转变为“定义目标和边界”。人类将判断结果、处理回归并注入领域判断，而 Agent 则通过迭代来完善具体的操作系统细节。

4. 去重、验证与 PoC

一旦发现漏洞，工作远未结束。去重、验证和 PoC 通常决定了系统的成熟度。

根因归一化

去重不是文本相似性问题；它是根因归一化 (Root-cause normalization)。Agent 必须学习解析对象、状态转换和攻击路径，以决定发现的结果是同一个问题还是攻击链的不同片段。一种稳定的方法是先进行局部合并，然后进行跨组比较。

信任边界与意图

验证中最难的部分通常不是幻觉，而是 信任边界 (trust boundaries)。如果不知道项目的设计意图或风险接受假设，许多发现就无法做出果断判断。意图设计是误报的最大来源之一。

PoC 作为验证手段

在 AI 审计中，PoC 的作用就像是一个昂贵的验证仪器，后期用于少数候选对象。它的优先级取决于你是在构建漏洞挖掘系统（针对命中率进行优化）还是审计系统（针对覆盖率和底线保留进行优化）。

证据与不确定性

最稀缺的资源是人类的注意力。一个成熟的系统应该压缩噪音，并输出一个带有明确不确定性说明的 证据包 (evidence package)。说明缺失了哪些材料或哪些假设使结论成立，是帮助人类决定如何干预的专业行为。

5. 未来的 AI 审计系统究竟会是什么样子？

轻量化编排

未来的系统不太可能使用沉重、僵化的链条。方向是保持结构轻量化，让更强大的模型在明确的约束下完成更多执行工作。

确定性规则 vs. Agent

并非所有事情都属于 Agent。只要可能，就应该使用稳定的确定性规则和脚本。Agent 在开放式探索和复杂的上下文推理中最具价值。

单引擎 vs. 多 Agent

• 强大的单引擎：更容易管理回归、控制迭代并保持可观察的状态。
• 多 Agent 组：可能从分工和协作中获益，但通常更重且更难调试。

默认的起点应该是一个轻量、可迭代的系统。复杂性应根据需求引入。重要的是系统保持可观察、可重放和可继承。

6. 停止条件与反馈飞轮

何时停止

代码审计是一种开放式的搜索。系统需要基于攻击面覆盖、假设穷尽或边际收益递减的明确停止条件。

护城河与通用能力

通用能力（规划器、工具使用）将被基础模型公司商品化。真正的护城河将转向私有的 Bad Case 库、隐藏的回归集、领域约束和客户信任。

反馈飞轮

真正的竞争单元是反馈飞轮：Agent、回归集、验证器和人工评审结果。一个在运行后不留下任何东西的系统是失忆的。有组织的失败沉淀才是让系统稳步走强的核心。

7. Benchmark 的失效

许多公开的 Benchmark 正在变成公关工具，而不是能力的衡量标准。分数可能会因自选样本、训练数据污染以及偏向特定风格的评分标准而失真。

超越公开竞赛

一个更有前景的方向是生成注入了系统未见过的变异的本地代码库。这减少了“应试型”进化，并迫使系统理解代码结构和路径行为。

分层评估

有意义的评估必须是分层的：

1. 公开 Benchmark：可用性检查。
2. 合成/变异 Benchmark：防止作弊。
3. 私有回归/人工评审：测试真正的能力边界。

8. 社交媒体推广的扭曲

在 X 等平台上高频的推广奖励的是最容易展示的东西（发现数量、截图），而不是最重要的东西（误报控制、回归稳定性）。

叙事 vs. 现实

将打磨过的外部叙事与修复 Bad Case 的混乱内部现实进行比较，会产生不必要的焦虑。能展示出来的往往只是能力的一个切片。能够持久存在的系统，是那些无论发帖频率如何，都能被信任并承担交付责任的系统。

结论

一个真正属于 Agent 时代的系统是一个能够持续进化而不失去控制的系统。它必须容忍试错而不产生不可逆的回归，并能处理去重和验证等困难的后端任务。

AI 审计方法论的真正差距不在于谁先连接了 Agent，而在于谁构建了一个能够进化——且在进化过程中不迷失方向——的系统。

• 原文链接： x.com/xy9301/status/2036...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～