AI审计方法论：你需要知道的一切 (第一部分)

在过去的几年里，几乎所有将大型模型应用于代码审计、漏洞发现和安全分析的可能路径都已被尝试：静态分析、动态分析、符号执行、RAG、工作流编排、代码切分、长管道框架以及各种学术原型。这些方法中的每一种都在不同时期发挥了作用，它们共同推动了该领域发展到今天的水平。

但如果将所有这些探索都放在同一时间线上，有一点变得越来越清晰：构建 AI 安全工具的方式已经达到了一个真正的转折点。

这个转折点不仅仅是关于更强大的模型、更多的工具或更多的人进入该领域。更深层次的转变是该领域自身的认知框架正在改变。

如果你继续展开这条时间线，一条相当清晰的演进路线就会出现：

AI for Security 正在从框架驱动转向编码代理驱动；从手工构建复杂流程转向首先重现人类过程然后自动化；从手动预先裁决信息转向让代理更自主地探索更丰富材料。

本文主要试图回答三个问题：过去几年 AI 代码审计是如何演进的，为什么旧的重编排和重预处理方法不再是一个好的默认选择，以及如果你今天构建自己的 AI 安全工具，正确的起点是什么。

1. AI 代码审计在过去三年经历了什么？

如果大致将时间线从 2022 年末延伸到 2026 年初，该领域的发展可以分为两个主要阶段。

第一阶段以学术探索为主，工程化尚处于早期。这一阶段大致持续到 2025 年 1 月之前，其本身又可分为三个小阶段。

最初，该领域主要以静态分析为主。最早的一波工作，实质上是让大型模型参与静态代码分析。该时期的核心思想是 SAST，利用大型模型解释业务逻辑，并使用 LLM 帮助识别漏洞上下文。简而言之，核心思想是传统静态分析将代码结构抛给模型，模型则处理业务理解。在学术上，这很重要，因为它首次证明 LLM 不仅可用于代码生成，还能参与程序理解、安全推理和漏洞发现。但局限性显而易见：大部分仍是纸面验证，远非可真正用作工程产品的东西。

随后，该领域从静态方法转向动态方法。研究扩展到更复杂的方法，包括动态分析、符号执行以及与传统程序分析工具的更紧密集成。该阶段的决定性认识是，静态分析加上大型模型是不够的。必须将更多运行时、路径级别和约束级别的信息引入循环。这也是一些代表性工作开始出现的时候，它们试图从不同角度将 LLM 与传统安全分析能力结合，推动方法论向前发展。

到 2024 年下半年和 2025 年 1 月左右，该领域进入了一个相对成熟的阶段。成熟并不意味着问题已解决，而是意味着共识变得更加清晰：仅靠模型是不够的，仅靠传统工具也不够。更现实的路径是更紧密地结合它们。在此阶段，许多系统开始呈现出更清晰的工程形式。它们仍然复杂，但不再仅仅是论文演示，开始看起来像真正的系统。

如果用一句话总结第一阶段，那就是：从主要静态，到动态增强，再到工具-模型集成。

一旦理解了这段历史，2025 年之后的变化就更容易解释了。因为变化的不仅仅是工具或参与者增多，而是方法论本身发生了转变。

2. 2025 年之后，真正的转变开始

如果说前一阶段主要还是学术探索和早期工程，那么从 2025 年开始，特别是从 2025 年末到 2026 年初，该领域进入了一个截然不同的阶段：工程化爆发。

最明显的变化是，越来越多的团队能够构建自己的“大型模型 + 安全”系统。换句话说，这不再是少数研究团队才能尝试的事情，而成为一个可以广泛尝试、快速迭代和持续交付的工程方向。

但如果仅仅将其解释为“更多人开始做这件事”，那仍然错过了真正的重点。实际的转折点是方法论开始集体转变。

此前，许多系统围绕工作流和框架组织：使用 LangChain 和 LangGraph 等工具构建流程，手动预处理代码和文档，手动管理 RAG，手动连接 SAST、AST、动态工具和验证，然后将整个推理过程编码成固定的管道。

这在当时是合理的，因为模型能力较弱，必须小心翼翼地引导。

但新一代编码代理出现后，情况开始发生变化。借助 Claude Code、Codex 和 Cursor 等工具，许多人几乎同时意识到，开发者过去手动硬编码的信息过滤、工具选择、任务分解和流程拼接，现在可以越来越多地交给代理本身。

这就是为什么 2026 年感觉像一个如此明显的里程碑。从那时起，主流思想越来越倾向于：停止用笨重的框架硬编码整个过程；停止预定义每个工作流步骤；停止痴迷于手动维护大量的预处理和提示组装逻辑。相反，给代理一个明确的目标、必要的工具和一些约束，让它决定阅读什么、使用什么、如何进行，然后让它反思并迭代结果。

换句话说，该领域正在从框架驱动转向编码代理驱动。

这里还需要补充一个更尖锐、更现实的判断。在 2026 年之前，许多公司和个人，无论是出于路径依赖、组织惯性，还是仅仅缺乏理解，多年来一直低估 LLM，有时甚至完全不屑一顾。然后一旦方向变得明显，他们突然想实现一次大跃进，仿佛整个能力栈可以一夜之间追赶上来。这种转变本身就是荒谬的。

因为真正决定一家公司、一个团队或一个人能否构建出有用东西的，从来不是他们今天喊得有多响亮，而是他们是否一直在积累理解。他们是否真正理解 LLM 的倾向、概率和不稳定性边界？他们是否理解模型何时漂移、何时幻觉、何时应该信任、何时必须约束？他们是否通过反复迭代将这种理解融入产品？没有这种积累，后期的集中努力往往会产生看起来新颖但并非真正有用的东西。

这正是理解这种范式转变发生的原因，比仅仅重复口号要重要得多。所以下一个问题显而易见：为什么传统的框架驱动路线不再是一个好的默认选择？

3. 为什么传统的框架驱动路线正在过时？

一个判断可以直接说明：传统框架并非完全无用，但它们不再是当今构建 AI 安全工具的良好默认起点。问题不在于它们是否有价值，而在于它们越来越不适合作为新一代系统的起点。

第一个原因是工程量太大。开发者必须自己解决所有问题：如何过滤材料、如何切分代码、如何构建 RAG、如何分析调用关系、如何将静态分析结果插入循环、如何将这些结果反馈给模型、如何进行规划以及如何进行验证。链条中的每个环节都必须手动设计、拼接和调整。最终结果通常是相同的：庞大的代码库、复杂的工作流以及一个牵一发而动全身的系统。

第二个原因是手动预处理极其昂贵。在许多旧系统中，管道中最繁重的部分实质上是预先决定代理应该看到什么，不应该看到什么。为了向模型提供人类预定义的“恰到好处”的材料量，团队进行了大量预处理：检索、切分、聚合、提取调用链、修剪路径信息等等。当模型能力较弱且可读材料量受限时，这些方法确实是必要的。但它们带来了两个问题。首先，工程实现复杂。其次，它们往往过早地做出错误的信息决策，并在代理有机会看到关键细节之前就将其丢弃。很多时候，看起来是在帮助代理理解代码，实际上却是在替代理做出错误的过滤决策。

第三个原因是，一旦工作流被硬编码，它就停止了演进。如果将整个系统变成一个固定的流程，例如静态分析，然后切分，然后一轮预过滤，然后模型，然后验证，它可能看起来很整洁。但真正的问题是它变得僵化。一旦结果不佳，就很难知道该改变什么。是提示、检索、切分、规划还是工具排序？一旦模型能力发生变化，整个固定流程可能就会立即过时。

因此，框架驱动系统的问题不仅仅是它们笨重。更深层的问题是，它们与模型快速变化的时代不自然契合。

一旦旧路线的问题明确，下一个真正的问题就显而易见：如果框架不再是正确的起点，那什么才是？

4. 有效方法：先复现人类流程，再自动化

如果用一句话概括整个方法论，那就是：代理的本质是复现人类流程。

这句话听起来很简单，但它几乎可以作为当今构建 AI 安全工具的通用原则。如果上一节解释了旧方法为何越来越不适用，那么本节则探讨新方法论应该从何开始。

一个非常常见的误解是，一开始就问系统应该如何构建。我早在 2025 年年中的一次内部公司讨论中就提出了这一点。不幸的是，当时没有多少人真正听进去。当许多人接到任务时，他们的第一反应仍然是：我应该使用 LangChain 吗？我应该先插入 RAG 吗？我应该进行代码切分吗？工作流应该分成多层吗？但这不是正确的第一个问题。

你真正需要首先弄清楚的不是使用什么框架，而是人类将如何完成这项任务，哪些步骤是必不可少的，必须获取哪些信息，什么经验决定了结果质量，以及人类和代理如何最顺畅地协作。只有当这些问题明确后，自动化才有了真正的基础。

实际的起点是让人类和编码代理首先一起执行任务。不要试图一次性构建最终系统。让人类和代理首先一起完成任务。

例如，在根本原因分析中，你可以从拉取必要数据开始，然后让人类与 Cursor 或 Codex 协作，将结果与真实情况进行比较，如果结果错误，则添加更多信息，调整提示，并改变协作模式，直到流程正常运行。

白盒代码审计也是如此。首先编写操作指南，让代理在第一阶段遵循，例如分解架构并建立初步理解。然后添加更详细的指南，让它继续深入漏洞发现。人类只在关键点进行干预。一旦流程足够稳定，人类就可以逐渐退出。

这种方法论的关键不在于早期节省精力，而在于首先发现任务的真实执行路径。

一旦“人类 + 代理”能够可靠地完成任务，自动化就变成了工程问题。换句话说，自动化不应该是第一步，而应该是最后一步。

5. 手册、技能和文档本质上是同一回事

一旦你遵循上述逻辑，自然会引出一个核心问题：人类经验应该如何积累？这时一个重要的概念出现了：手册。

但从另一个角度看，今天人们所说的手册、技能、操作指南、经验文档和 SOP，都指向同一件事：将人类经验显性化。

这并非今天才被注意到。早在 2023 年，我们实践中的人们就已经意识到，如果 AI 真的要进入安全工作流，最终人类的经验、判断路径和分析习惯必须从隐性直觉转变为显性文本。

问题在于，当时大多数人既不擅长也不热衷于此。一方面，将经验显性化确实很难。它要求人们将长期依赖直觉和习惯做出的判断，一步步分解成可以实际解释的东西。另一方面，在当时的模型能力和工程范式下，做这项工作的回报并不直接。许多人本能地抵制它，因为它感觉繁琐、低效，像是没有即时回报的额外工作。

但到了 2026 年，一个有趣的逆转发生了。许多原本不愿将经验显性化的人开始积极编写自己的技能。表面上看，他们的习惯改变了。但更深层次的原因是回报结构发生了变化。一旦编码代理成为核心，技能、手册和 SOP 不再仅仅是供人阅读的文档。它们越来越像自然语言程序，可以直接塑造代理的任务分解、信息使用、执行稳定性以及输出质量。

换句话说，同样是将经验显性化的行为，在 2023 年看起来像是在写文档，但到了 2026 年，它更像是在编写一个直接生效的程序。人们并没有突然变得更勤奋，他们只是终于看到了直接而明显的回报。

基础模型公司也将迅速吸收这一趋势。例如，Anthropic 在 2026 年 3 月对 skill-creator 的更新已经开始将技能测试、基准、回归检查、多代理并行评估、比较代理和触发时机优化直接融入产品中：https://claude.com/blog/improving-skill-creator-test-measure-and-refine-agent-skills。这完美地支持了之前的判断：一旦一项能力足够有用且足够通用，基础模型公司最终会将其从一种使用技术转变为平台原生能力。

为什么这如此重要？

因为大型模型和代理的真正价值不在于它们凭空创造经验，而在于它们能够高效地执行、放大、转移和重用已经提炼出的经验。

当一位资深安全工程师的工作方式可以清晰地写下来时，例如先看什么、后看什么、哪些特征值得怀疑、某些攻击模式应如何验证以及特定业务场景中的高风险点是什么，那么这套经验就变成了代理可以自动化的东西。

从这个角度看，AI 安全工具中最重要的资产可能不仅仅是代码，还可能是知识积累、分析路径、漏洞模式总结以及表达领域经验的能力。

特别是对于安全团队而言，多年来积累的漏洞样本、攻击模式和审计经验不仅仅是背景材料，它们是构建代理能力的核心Gas。在代理时代，表达经验本身的能力成为主要的竞争优势。

6. 我们仍然应该使用 RAG、代码切分和传统工具吗？

至此，一个自然的问题出现了：我们仍然应该使用 RAG、代码切分和传统工具吗？这部分最容易引起分歧，也正因如此，才值得明确说明。

答案不是“全部扔掉”。答案是：它们仍然可以使用，但不应再处于系统设计的中心。

首先谈 RAG。RAG 的本质是从大量材料中找到所需内容。这种能力绝对有价值。问题是许多人习惯于将 RAG 视为必须首先构建的基础设施，然后自然而然地投入大量精力来决定首先检索什么、首先修剪什么、首先组装什么。

在编码代理时代，更合理的想法是：如果你确实需要在大量文档语料库中搜索，那么就添加检索。但如果代理已经可以通过 grep、图工具、脚本或文件搜索获得所需内容，那么就没有理由在其之上添加一个笨重的 RAG 层。

更重要的是，重点不应放在为代理预组装一个标准答案式的输入，而应放在让代理直接访问足够完整和足够原始的材料。

换句话说，RAG 是一种可用的能力，它不是默认前提，也不是开发的中心。

代码切分也是如此。代码切分和材料切分在学术工作中很常见。问题不在于它们原则上无用，而在于在实际工程中它们经常遇到几个实际问题：切分策略难以设计，它们容易丢失跨文件、跨函数或跨模块的信息，预处理成本高昂，并且随着模型改进，这种细粒度预处理的边际收益迅速下降。许多团队在切分上花费了大量时间，最终却发现系统并没有变得更有意义地强大，只是变得更复杂、更脆弱、更难以维护。

传统安全工具仍然很重要。SAST、动态分析、FAST、符号执行以及各种验证工具等能力仍然重要。但它们不应再主导整个主流程。它们最好被视为代理在必要时可以调用的外部工具。

这些能力可以很容易地通过 MCP 或类似机制暴露出来，然后由代理在需要时以最适合情况的方式调用。

这与新一代系统更自然地契合。工具仍然重要，但它们的作用已经改变：它们不再是整个管道的骨架，而是代理可以按需调用的模块化能力。

7. 为什么代码审计如此困难，而其他方向更容易产生成果？

一旦方法论清晰，你最终必须回到产品选择本身。这里有一个非常重要的产品层面判断：代码审计本质上是一个图探索问题，实际上是一个“未知未知”问题。

这意味着什么？

当一段代码交给模型时，它不会沿着单一路径推理。它可能从数据流、权限边界、调用链、业务逻辑、输入验证、状态一致性、经济模型以及许多其他角度进入。

其中一些推理路径导向正确答案，另一些则导向误报。更糟糕的是，很难知道有多少可能的路径，是否还有一些遗漏，以及搜索空间是否真的已穷尽。

这就是为什么代码审计本质上难以完成。

因此，成熟的工程思维应该停止痴迷于是否已找到所有问题，转而转向一个更实际的目标：将一个实际上无限的漏洞推理空间，转化为一个有限的、可审查的、可覆盖的任务空间。

这是一个更接地气的优化目标：不是理论上的完整性，而是工程上的覆盖率、可重放性以及可持续优化。

相比之下，其他一些方向更容易闭环，例如大规模日志分析、恶意 IP 挖掘、根本原因分析以及其他具有更确定性答案的安全任务。

这些任务通常具有一个共同特征：搜索空间更小，结果更容易验证。

这意味着系统可以快速形成推理、比较、反思和迭代的循环。

一个典型的例子是具有明确真实情况的任务。在这种情况下，代理可以反复生成答案，将其与真实结果进行比较，反思哪里出错，调整提示或流程，然后再次尝试。

这样的任务特别适合自我改进，也更容易从中快速获得结果。

再进一步，你会发现并非所有代理系统都适合自动化迭代。真正适合的系统通常具有几个特点：

• 它们的输出可以比较，或者至少有明确的验证信号、约束或阶段目标。
• 它们的中间过程是可观察的，因此错误不仅出现在最终结果中，还可以定位到特定的分解、文档或子步骤。
• 它们的变更单元是可控的，因此你可以局部修改提示、技能、手册、策略线或任务模板，而不是重建整个流程。
• 它们的结果是合理可重现的；否则每次运行都会变得过于随机，自动化迭代就会退化为盲目试错。

换句话说，自动化迭代不最适合黑盒、不可观察、不可定位或非模块化的代理。它最适合具有清晰阶段边界、清晰评估信号、充分外部化状态和受控变更范围的系统。只有在这样的系统中，反馈才变得有意义，迭代才能积累成真正的能力。

从产品角度看，如果一个团队刚刚起步，优先选择这些更容易闭环的方向，通常比直接挑战最难的代码审计版本要明智得多。换句话说，通常最好在更容易的闭环场景中先取得进展，而不是在第一天就挑战最难的问题。

8. 评估 AI 安全工具：覆盖率、关键漏洞和“漏洞狩猎”与“审计”的区别

这是另一个非常实际的问题，经常被混淆：AI 安全工具到底应该如何评估，我们是在评估一个漏洞狩猎助手还是一个审计系统？

几天前，当我与 OpenAI EVMbench (https://cdn.openai.com/evmbench/evmbench.pdf) 的第三作者 Xiaohai Xu (@sahuang97) 讨论这个问题时，有一个观点特别值得记住。

从客户的角度来看，他们真正关心的往往不是一个工具平均能发现多少中低风险问题，而是它能否避免遗漏少数真正决定结果的问题，特别是可能直接导致资金损失的高危漏洞。对于许多买家来说，关键漏洞命中率是感觉最接近购买理由的指标。

但这并不意味着覆盖率毫无意义。对于已经拥有强大人工能力的审计团队来说，AI 工具更像是安全网和放大器。对于希望通过 AI 降低成本和扩大交付能力的新团队来说，该工具更容易被期望替代或补充人工劳动。这些是不同的场景，因此指标的优先级自然会改变。

更重要的是，关键漏洞通常不是你可以直接瞄准的东西。许多高危漏洞的发现，仅仅是因为系统具有强大的整体搜索能力、代码理解、路径探索和覆盖率。换句话说，中低风险覆盖率不直接等同于商业价值，但它往往决定了系统是否具有命中关键漏洞的稳定基础。

所以更准确的表述不是覆盖率与关键漏洞的对立，而是：覆盖率是基础，而关键漏洞决定了胜负。

覆盖率决定了长期能力边界。关键漏洞决定了短期市场结果。一个工具绝对需要不断提高其整体覆盖率。但市场在短期内奖励的仍然是真正命中关键漏洞的系统。

然而，再进一步思考，另一个观点出现了：覆盖率和关键漏洞之所以经常争论不休，可能不仅仅是关于指标本身，而是因为人们评估的不是同一件事。

漏洞狩猎：高效率执行者

如果目标是发现漏洞，那么你真正评估的是一个高效率的执行者。

从漏洞狩猎的角度来看，许多这些判断都非常合理。在这种情况下，人类更像是一个导演：决定方向、削减攻击面、定义威胁模型，并决定哪个切片值得深入挖掘。AI 更像是一个高效率的执行者，沿着该方向快速探索，构建 PoC，验证可利用性，并试图发现最有价值的漏洞。

如果你将 ToB 安全研究员 Devansh 的文章《Needle in the haystack: LLMs for vulnerability research》(https://devansh.bearblog.dev/needle-in-the-haystack/) 放在这个框架内，它非常符合这种漏洞狩猎的视角。该文章的重点不是如何对一个项目产出更完整的安全判断，而是研究员如何先给出方向、威胁模型和切片，然后让 AI 作为高效率执行者进行集中探索、PoC 构建和高价值漏洞狩猎。

在这个框架中，最重要的不是系统是否稳定地覆盖整个项目，而是系统能否在有限时间内尽可能多地发现有价值的漏洞，特别是关键漏洞。如果它能不断发现少数最重要的漏洞，它就已经非常有竞争力了。

审计：构建可靠的团队

但如果目标是审计，那么你真正评估的是一个能够守住底线的团队。

从审计的角度来看，问题不再仅仅是“这个系统这次能否挖出一个漂亮的高危漏洞？”它变成了：这个系统能否持续积累能力、守住底线、尽可能避免遗漏关键风险，并产出更稳定的安全判断？

在这里，人类更像是一个管理者，而不仅仅是导演。重要的不仅是指引 AI 走向一个高信号方向并让它冲刺，更重要的是任务如何分配、覆盖率如何提高、模块间的结果如何结合、一个发现如何转化为未来的能力，以及系统在反复运行中如何保持可重放性、可回归性和可解释性。

换句话说，你在这里需要的不再仅仅是一个高效率的执行者，你更需要一个能够稳定推进工作的团队。它需要规划、覆盖率、手册、清单、验证器、回归和账本。它必须能够将局部发现转化为系统级能力，而不是每次都依赖于一个高信号切片中的一次灵光乍现。

这引出了另一个非常重要且容易被忽视的人类经验：将一群高效的执行者聚集在一起并不能自动形成一个优秀的团队。

一个强大的漏洞研究员与一个强大的 AI 执行者合作，绝对可以快速产出漂亮的结果。但将许多这样的高效执行者聚集在一起并不能自动形成一个优秀的审计团队。一个团队仍然需要分工、调度、交接、底线保障、事后分析、回归、知识共享和质量控制。

AI 系统也是如此。

如果一个系统只在少数高信号点上闪光，但不能稳定覆盖攻击面，不能保存中间状态，不能解释为什么这次发现了而上次没有，也不能将发现转化为下一轮的规划和验证，那么它更像是一个强大的执行者，而不是一个真正可靠的审计系统。

因此，覆盖率和关键漏洞之间的关系，往往需要在指标本身之上一个层面来理解：

我们是在评估一个漏洞狩猎助手，还是一个能够守住底线并逐步形成团队级能力的审计系统？

如果目标更偏向漏洞狩猎，那么关键漏洞命中率自然更接近价值。如果目标更偏向审计，那么覆盖率、底线质量、可重放性、回归能力和累积能力就变得重要得多。当然，一个成熟的系统最终两者都需要。但这两个目标的默认优化方向并不完全相同。

9. 为什么 Web2 和 Web3 如此不同，即使都称为审计？

如果你将上述判断应用于不同的赛道，一个非常真实的差异就会出现：Web2 和 Web3 代码审计不是同一规模的问题。

在传统安全设置中，Go、Java、C/C++、操作系统组件、大型开源项目，模型通常更容易产出有用的结果。原因很简单：漏洞模式更成熟，代码语料库更大，审计经验更标准化，工具链更完整。

因此，在 Web2 环境中，模型确实更容易产出有用的结果。

但一旦进入 Web3、合约安全和复杂的金融逻辑漏洞，问题就会迅速变得困难得多。

因为这些漏洞往往不是简单的内存问题或输入验证错误。它们是特定的业务流程缺陷、复杂资金流逻辑中的缺陷、嵌入在金融操作中的利用路径，或经济模型本身的问题。

它们高度依赖领域知识，高度依赖积累的经验。

这意味着它们更难标准化、更难自动化、更难围绕它们构建，但也更难复制。

从竞争角度看，这实际上是好消息。方向越难，就越不容易被轻易复制。这也是为什么两个都称为代码审计的东西，根据赛道的不同，可以有完全不同的方法论、工程复杂性和产出节奏。

10. 当今更合适的实现方法

如果将上述方法论落实到工程实现中，我不想在这里展开太多。其中一部分涉及核心方法论，一部分则不应在公开文章中描述得过于明确。唯一值得说的是：一个真正有效的系统不是一个具有局部最优点的系统。它是一个整体上既能守住底线又能深入挖掘重要任务的系统。

在我看来，一个真正有价值的代理至少需要两样东西。首先，一个轻量、松耦合、可替换的架构，能够随着模型的改进自然演进。其次，一个稳定、可重现且尽可能保留中间结果的执行过程。只有这样，系统才能知道为什么这次成功了，上次失败了，以及如何持续迭代。

一个非常直观的例子是 txnalayzer.xyz 和 clarahacks.com (@clara_oracle) 在攻击交易 RCA 上的区别。在相似的准确度水平下，前者通常快得多，而 Clara 路线则慢得多，甚至可能需要六小时的设置时间。

但这并不是说 Clara 不好。它表明不同的路线做出了不同的权衡。Clara 将大量的坏案例修正吸收到了运行时本身，因此人类不必逐个案例进行干预。另一条路线更快，但更依赖人类提前预测坏案例并不断将其写入文档和模板。

如果你想更详细地了解 @clara_oracle，你可以阅读 @lzhou1110 教授关于该方向的文章。

从更工程化的角度看，自动化迭代非常像一个电气闭环。日志、中间结果、验证器和人工审查结果是传感器。目标输出、真实情况和规则约束是参考输入。它们之间的差距决定了系统在下一轮中应该改变什么。

这个类比中的关键思想很简单：不要在每次出现问题时都重写整个系统。保持主结构稳定，外部化中间状态，将错误定位到具体层面，并限制每次迭代的范围。这样，反馈才变得有意义，迭代才能开始转化为能力。

再进一步推导这个想法，你会得到另一个判断：一个需要快速迭代的代理系统，应尽可能围绕单一瓶颈进行设计。

这里所说的单一瓶颈，并非指系统字面上只有一个限制因素。它意味着大多数问题应收敛到少数几个清晰可识别的关键环节，而不是分散在执行链的每个角落。

它的价值不仅在于更容易优化，还在于问题更容易定位、重现和修复。许多结果的真正差异并非产生于最后的执行步骤，而是在更早的阶段就已确定。

我在构建 Finite Monkey Engine (https://github.com/BradMoonUESTC/finite-monkey-engine) 时就已经意识到了这一点。当时，我的理解更倾向于将开放式探索和强收敛本身作为瓶颈。回过头来看，那个方向并非完全错误。但现在对我来说更重要的是：瓶颈不仅要强大，还应该可观察、可重放、可迭代。

对于需要持续改进的审计系统来说，这非常重要。系统不仅需要强大，还需要能够自我闭环。

11. 未来，竞争将不仅仅是代码能力，更是工作方式

这是范式转变最重要的影响之一。

如果越来越多的人可以依靠编码代理完成开发，那么团队之间的真正差距将不再仅仅是谁写代码更快。它将是谁更了解业务问题，谁更好地分解任务，谁更好地提炼经验，谁设计出更可迭代的执行路径，以及谁更擅长将复杂问题转化为代理可以执行的自然语言程序。

从这个角度看，AI 安全工具领域的竞争可能越来越像这样：

你是否能将专家工作方式提炼成一种可重用、可自动化并持续演进的方法？

这也是为什么那些在 2026 年才完全转向 LLM，并期望通过一次大规模组织冲刺解决所有问题的公司或个人，不太可能构建出具有长期价值的东西。没有足够的积累，没有对 LLM 倾向和概率性质的深入理解，也没有对产品边界、用户需求和部署约束的理解，他们构建的通常只是演示、报告和幻灯片，而不是能够长期运行并创造真正价值的产品。

更直接地说，代理时代的真正竞争不是谁追赶得更快，而是谁理解得更深、积累得更早、沉淀得更彻底。

12. 如果你今天开始构建 AI 安全工具，请记住这些

如果将整篇文章压缩成几个实用原则，归结起来就是这样：

• 不要先考虑框架，先考虑需求和信息可访问性。 弄清楚你到底想解决什么问题，然后才决定是否需要 RAG、SAST、动态分析、代码切分或工作流框架。与其一开始就设计一个复杂的信息组装流程，不如先问：代理需要看到什么材料，以及如何尽可能完整地暴露这些材料？
• 先让人类和代理一起工作，然后自动化。 不要急于编写整个系统。先让人类和 Cursor、Codex、Claude Code 等工具一起完成任务。一旦流程顺畅，再将其自动化。
• 将经验记录下来。 真正能积累成能力的不仅仅是代码，还有手册、技能、SOP、漏洞模式总结和业务经验文档。你越能清晰地表达经验，就越容易将这种能力转化为代理能力。
• 优先选择容易闭环的任务。 如果一个团队刚刚起步，优先选择搜索空间较小、验证更容易的方向。先让一些东西奏效，然后逐步转向代码审计等更困难的问题。
• 为未来六个月设计，而不是为过去一年。 模型能力仍在快速变化。不要为昨天的约束构建一个明天就过时的系统。一个面向未来的代理至少需要两个特性：首先，它应该足够轻量和灵活，能够随着模型的改进自然演进，而不是需要完全重写；其次，它的工作流应该稳定、可重现，并保留清晰的中间结果，以便后续的反馈、迭代和有针对性的优化有据可依。

还有一个重要的现实：基础模型公司本身也在积极迭代。任何被证明足够有价值和足够通用的东西，最终都会被内置到平台、工具链甚至模型默认设置中。与其追逐当前的工具链，不如追逐其底层原理。技能、记忆和子代理都是这样的例子：它们首先在实践中证明了自己，然后被产品化、平台化和内置。

与其让系统越来越重，不如让它们更轻、更灵活，并更能与代理能力一同演进。

结论

如果用一句话总结本文的核心观点，那就是：

在当今构建 AI 安全工具时，最重要的不再是如何组装框架，而是如何提炼人类分析过程，并让编码代理在足够丰富的材料下复现、执行和迭代它。

这不是一个小的改进，而是一种研发范式的转变。

旧的方式，即先构建框架，然后连接工具，再连接模型，并非完全错误。它只是越来越成为上一代的方法。

新的方法从需求出发，从人类流程出发，从经验沉淀出发，从信息可访问性出发，同时在更轻量的代码骨架上承载更强的代理能力。

对于安全行业来说，这一转变值得特别关注。安全从来不仅仅是技术的堆砌，它深深依赖于经验、路径、判断和事后分析能力。谁能更早地将这些能力转化为代理可执行的形式，谁就更有机会在下一波工具演进中占据主动。

最终，真正的分界线可能不是你是否知道如何构建 AI 安全工具，而是：

你构建的是另一个旧时代的工作流系统，还是一个真正属于代理时代的安全系统？

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