这个标题多少有点标题党。

准确来说，不是所有安全提示词都会让 Codex 变差。最近一篇自动渗透测试论文测试了两种安全提示词：模型、基准测试、预算和工具环境全部不变，最后都输给了 Codex 的原生默认配置。更尴尬的是，它们还更贵。¹

但我真正感兴趣的并不是「安全提示词已死」这种结论，而是它后面那个更麻烦的问题：

当通用模型和编程 Agent 已经越来越强，业务团队到底应该把垂类能力写在哪一层？

继续堆提示词？做插件？在外面套规划器、审阅器和子智能体？还是干脆自己造一套专用执行框架？

Codex Security 恰好给了一个很有意思的参考答案。

先看一组有点打脸的数据

2026 年 7 月的论文 Baselines Before Architecture（《先做基线，再谈架构》），在 XBOW 的 104 个渗透测试任务上做了一组控制实验。研究者固定 Codex、GPT-5、基准测试、预算和工具环境，只改变提示词。¹

提示词条件	第一次	第二次	Pass@2	单次成本
Codex 原生默认	70	70	81	$27.71
Detailed task prompt（详细任务提示词）	64	58	68	$32.81
Whole-system prompt（全系统提示词）	60	68	75	$32.28

结果很直接：这两个更详细、更「专业」的安全提示词没有提高成绩，反而让 Codex 花了更多 token（词元）、调用了更多工具，最后解出的题还更少。

这里需要先踩一脚刹车。这组实验只能证明这两个提示词变体没有带来收益，不能顺手推导出「提示词越长越差」「强模型不需要提示」或者「上下文污染就是原因」。论文也没有证明这些更强的因果判断。

但它至少打破了一个很常见的工程直觉：给通用 Agent 塞更多领域指令，不等于获得了垂类能力。

很多所谓的专业提示词，最后都会长成这样：

flowchart TB
    A["角色与固定步骤"] --> B["规划"]
    B --> C["检查与反思"]
    C --> D{"通过？"}
    D -->|"否"| B
    D -->|"是"| E["结束"]

它的问题未必是不够专业，更可能是太想替模型决定「应该怎么思考」。

成熟编程 Agent 的默认提示词、工具循环和上下文策略，本来就是一个被长期优化过的整体。业务方再叠一套强流程提示词，不一定是在补能力，也可能只是在把原本已经不错的执行轨迹拽向另一个方向。

提示词没帮上忙，为什么执行框架又有效？

如果只看前一组数据，很容易滑向另一个极端：既然提示词没用，那就直接裸用最强模型，什么都别定制。

同一篇论文随后给出了反例。研究者尽量匹配底层模型，把通用 Codex 和专门为渗透测试设计的系统放在一起比较：¹

系统	模型	单次成绩
原生 Codex	GPT-5	67.3%
MAPTA	GPT-5	76.9%
Architecture residual（架构增益）		+9.6 个百分点
原生 Codex	GPT-5.2	79.8%
PentestGPT V2	GPT-5.2	85.0%
Architecture residual（架构增益）		+5.2 个百分点

同一个模型放进不同的执行结构里，能力确实会变化。

MAPTA 和 PentestGPT V2 增加的也不只是一段「请系统搜索所有攻击路径」的提示词。论文列出的安全专用规划器（security-specific planner）、持久化记忆（persistent memory）、检索（retrieval）、攻击树 / 图搜索（attack tree / graph search）和验证（validation），都被做成了系统结构。

这两类东西表面上都叫垂类定制，实际差别很大。前者主要改变模型收到的指令，后者会改变模型能看到什么、能调用什么、得到什么反馈，以及下一步如何被组织。

另一篇 2026 年的论文 The Scaffold Effect in Coding Agents（《编程 Agent 中的脚手架效应》）也观察到了相似现象。相同的 Qwen 3.6 Plus 和 MiniMax M2.5，放进 Goose、OpenCode、OpenHands-SDK 三套执行框架后，配对通过率相差 0～8 个百分点，每个成功任务的 token 消耗最高相差约 40 倍；不同执行框架还留下了相对稳定的 failure fingerprint（失败特征）。²

所以只拿模型名字比较编程 Agent，其实少看了一半。论文提出，更完整的比较单位应该是：

harness–model pair（执行框架与模型的组合）

我现在怎么理解模型、执行框架和插件

Agent 讨论经常绕晕，是因为大家会把不同层都叫成 Agent。我更倾向于把它们拆开：

层级	它负责什么	典型内容
模型	提供智力	理解、推理、规划、生成、选择动作
通用执行框架	把模型变成能持续行动的 Agent	Agent 循环、命令行、文件系统、工具调用、上下文管理、重试 / 停止
插件	让通用 Agent 进入专业领域	Skill、MCP、领域资源、工作流、必要的钩子
业务环境	提供真实业务状态和反馈	代码库、平台、测试环境、审批、线上系统

flowchart TB
    M["模型：理解与推理"] --> H["通用执行框架：组织行动"]
    P["插件：补充领域能力"] --> H
    H --> B["业务环境：真实状态与反馈"]

模型决定智力上限，Codex、Claude Code、OpenCode、Pi 这类通用执行框架负责把它变成可以持续读文件、跑命令、调用工具并从反馈里继续行动的 Agent。

插件不需要重新实现这一套运行时。OpenAI 现在的插件可以组合 Skill、MCP 服务器连接、内置 MCP 服务器、展示资源和生命周期钩子；Skill 则负责描述可复用的工作流。³⁴

所以我更愿意把插件理解成一个领域能力包：它回答的是一个成熟 Agent 进入这个领域后，应该拥有什么知识、工具和工作流，而不是重新回答「Agent 应该怎么运行」。

Codex Security 没有让你重造 Codex

再回来看 Codex Security，OpenAI 现在同时提供插件、CLI、TypeScript SDK 和云端四种入口。⁵

安全领域需要的结构一点也不少：

flowchart TB
    R["代码仓库"] --> T["威胁建模与漏洞发现"]
    T --> V["隔离环境验证"]
    V --> P["问题报告与修复审阅"]

但这些结构没有被塞进一句「你是一名安全专家」里。

威胁模型（threat model）是显式的项目级领域状态。它记录入口点、不可信输入、信任边界、鉴权假设、敏感数据路径和优先关注区域，并影响后续扫描的上下文与排序。⁶

验证也不是让模型再认真想一遍。Codex Security 会在隔离环境里验证高信号候选问题，再把验证证据和可审阅的修复建议交给用户，用真实执行反馈减少误报。⁵

到了深度扫描，系统会继续增加发现工作线程、子智能体、停止条件和最大探索轮次。官方配置甚至直接暴露了这些参数：⁷

[deep_scan]
workers = 2
subagents = 0
stop_after_no_new = 3
max_discovery_runs = 10

CLI / SDK 还支持扫描历史、结构化结果和其他推理服务提供商。⁸

这里值得研究的是 OpenAI 的分层选择：安全领域足够专业，流程也足够复杂，但 Codex Security 仍然建立在成熟的通用 Agent 之上。

专业 Agent 可以先在成熟 Agent 上补充领域能力，只把必须由系统保证的状态、搜索和验证结构继续下沉。至少 Codex Security 选择的是这条路。

专用执行框架有价值，只是没想象中那么无敌

前面的 +9.6pp、+5.2pp 当然有价值，但同一篇论文还有第二个反转：¹

对比	单次成绩	两次原生 Codex 的 union coverage（联合覆盖率）
GPT-5 原生 Codex 对比 MAPTA	67.3% 对比 76.9%	77.9%
GPT-5.2 原生 Codex 对比 PentestGPT V2	79.8% 对比 85.0%	88.5%

通用 Agent 多跑一次，在覆盖率上就可能追平甚至超过专用执行框架。

这里也不能把 Pass@2 和单次成功率混为一谈。专用执行框架提供的可能不是全新的能力上限，而是更好的采样效率、更稳定的执行轨迹、更少的无效探索，以及更高的单次成功率。

区别很关键。假设一套领域执行框架花半年开发带来 8 个百分点的提升，而通用 Agent 多采样一次就能覆盖这部分差距，那么它有没有商业价值，就不能只看基准测试上的成绩，还要把调用规模、成本、延迟和维护周期一起算进去。

更残酷的是，一次模型升级还可能直接吃掉过去的执行框架工程。论文固定 Codex 的默认执行脚手架（scaffold），只替换模型，平均 Pass@1 从 GPT-5 的 67.3% 提升到 GPT-5.2 的 79.8%，再到 GPT-5.5 的 92.3%。¹

这不能证明模型在所有领域永远比执行框架重要，但它至少说明了一件事：

执行框架会折旧。

我把这种现象叫作执行框架半衰期。

半衰期	典型结构	原因
短	强制任务拆解、反思循环、固定审阅器、复杂 SOP 式提示词	经常是在替当前模型补思考短板，模型升级后容易从帮助变成冗余
中	领域 Skill、威胁模型、持久状态、强类型工具、搜索拓扑	描述的是业务结构，比单代模型技巧稳定
长	编译器、测试、沙箱、校验器、外部环境反馈	这些是可执行的事实依据，模型再聪明也不能靠脑补替代真实执行

所以决定要不要下沉执行框架时，我现在会先问：

下一代模型出来以后，这部分代码还值钱吗？

业务团队真正该把力气花在哪

如果可以持续使用当前最强的模型，我会按下面的顺序投入：

flowchart TB
    A["强模型 + 通用执行框架"] --> B["插件 + 工具 + 状态 + 校验器"]
    B --> C["基准测试：失败稳定吗？增益划算吗？"]
    C -->|"没有证据"| D["保持当前结构"]
    C -->|"证据成立"| E["验证领域控制器，再决定是否自建"]

这不是说提示词不重要。它仍然需要表达任务，只是更适合写成任务规格，而不是操作手册：

• 目标
• 背景
• 约束
• 完成标准

我要什么、有哪些限制、做到什么算完成，应该讲清楚。至于每一步必须先想什么、反思几次、什么时候召唤审阅器，未必需要业务方提前替前沿模型编排完。

绝大多数业务能力，可以先停在插件这一层：

• 缺领域知识，就提供 Skill / 资源；
• 缺业务动作，就提供 MCP / 工具；
• 有反复出现的业务流程，就把它收敛成 Skill / 插件工作流；
• 依赖外部实时状态，就接连接器 / MCP。

只有在通用 Agent 已经出现稳定、可复现的失败模式后，才继续往下加结构。比如结果经常误报，就加校验器；搜索总在同一路径打转，就考虑搜索控制器；长任务持续丢上下文，再引入持久化记忆。

这和「Agent 不稳定，所以先加规划器、审阅器和反思」是两种完全不同的开发顺序。

先跑基线，比先画架构图有用

如果把这些判断变成一套工程流程，我会从通用基线开始。

第一步，直接用最强可用模型、成熟通用执行框架和最小任务说明，跑出通过率、token 用量、延迟、失败案例与执行轨迹。没有基线，就先别讨论要不要做规划器。

第二步，把重复出现的领域背景、工作流、工具和资源收进插件，减少每次任务临时拼装上下文的成本。

第三步，按失败类型加结构：不会调用内部系统就补工具，不知道业务状态就补领域状态，结果经常误报就补校验器。让结构对应证据，而不是对应想象。

最后，每增加一层都做消融实验：

实验组	结构
A	通用执行框架
B	A + 插件
C	B + 校验器
D	C + 领域控制器

而且别忘了定期拿最新模型重跑基线。不然很可能出现一种很有软件工程黑色幽默的场面：半年前为了旧模型造出的复杂优化，今天已经被新模型的默认能力覆盖，但团队还在继续维护那套架构。

执行框架的投入产出比（ROI）最后应该按下面这笔账来算：

执行框架 ROI =（性能提升 × 生命周期 × 调用规模）÷ 开发与维护成本

一个只提升 3 个百分点、但跨五代模型都稳定工作的校验器，可能比一个今天提升 10 个百分点、三个月后就开始拖后腿的规划器更值钱。

所谓「轻执行框架」

轻执行框架不是没有执行框架。

同模型换执行框架的实验已经说明，它会真实影响成功率、token 用量、延迟和失败方式。随着模型变强，执行框架的价值重心也在迁移。

弱模型时代，大家热衷用规划器、反思、审阅器、强制分步和复杂系统提示词替模型组织思考。

强模型时代，更值得长期投资的是工具、状态、环境、校验器和搜索反馈。它们不替模型想答案，而是让模型接触真实状态，并且必须接受现实世界的反馈。

Codex Security 值得研究，不只是因为 OpenAI 教会 Codex 扫漏洞。它更像是一个样板：当通用 Agent 已经足够成熟时，一个专业领域可以怎样把知识、工具、状态、搜索和验证叠上去，又不急着把整个 Agent 重新造一遍。

未来做垂类 Agent，重要的能力可能不是谁最会调提示词、堆规划器或造框架，而是谁能判断清楚：

什么应该交给模型，什么应该做成插件，什么真的值得下沉到执行框架。

---

参考资料

Footnotes

1. Ananda Dhakal, Krish Neupane, Aarjan Chaudhary. Baselines Before Architecture: Evaluating Coding Agents for Autonomous Penetration Testing（《先做基线，再谈架构：自动渗透测试中的编程 Agent 评估》）, 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵

2. Naman Vats, Oleg Golev. The Scaffold Effect in Coding Agents: Harness Choice as a Hidden Variable in Coding-Agent Evaluation（《编程 Agent 中的脚手架效应：执行框架是评测中的隐藏变量》）, 2026. ↩

3. OpenAI. Package your plugin. ↩

4. OpenAI. Build skills. ↩

5. OpenAI. Codex Security. ↩ ↩²

6. OpenAI. Improving the threat model – Codex Security. ↩

7. OpenAI. Run a deep security scan – Codex Security. ↩

8. OpenAI. openai/codex-security – CLI and TypeScript SDK. ↩