AI Harness Engineering：护栏机制的运作逻辑与个人设计方法
2023 年 4 月，NVIDIA 开源了 NeMo Guardrails——一个用 Colang 语言定义对话护栏规则的框架。
两年后的 2026 年 3 月，一份蒙特卡洛仿真报告给出了令人震惊的结论：NeMo Guardrails 对 PII 泄露和 Prompt 注入攻击的拦截率（Rate of Catch, RoC）仅为 0.05[1]。
几乎在同一时间，另一篇论文测出 Meta 的 Llama Guard 3 在代理执行安全任务上的 F1 分数是 0.0105——大致等于随机猜[2]。
这些数字指向一个被广泛忽视的事实：AI 护栏（Guardrails）作为当下企业 AI 部署的事实标配，其防御效能远低于大多数从业者的预期。
与此同时，"No Free Lunch with Guardrails"论文对 6 种行业级护栏的横评确认了一个根本性约束：安全性和可用性之间存在不可消除的权衡——更强的防护必然牺牲更多的正常功能[3]。
这些发现不只是技术问题。
当每个调用 ChatGPT API 的开发者都在系统提示里写"请不要输出有害内容"时，他们就在设计自己的 harness。
问题是：大多数人并不清楚自己到底在哪一层施加约束，也不清楚每一层约束的真实代价。
本次调研围绕四个问题展开：
AI Harness 的约束到底施加在哪一层？ 不同层级的约束有什么不可替代性？
Guardrails 与 Alignment 的边界在哪？ 一个 guardrail 完美的模型还需要 alignment 吗？
当前 harness 工程的实际失败模式是什么？ 哪些是护栏可以防御的，哪些是架构性缺陷？
个人设计 harness 时，约束的粒度、强度、可配置性之间，真实的权衡是什么？
一、约束的三层架构：Harness 施力在哪里
1.1 Prompt 级约束——最薄的一层
在系统提示中注入行为规则，是绝大多数个人用户唯一使用的护栏手段。
"你是一个安全的助手，不应该输出有害内容"——这条指令的本质是在模型的输入空间中增加一段文本，试图通过上下文影响生成分布。
它的优势显而易见：零成本、即时生效、无需代码。
它的劣势同样明显：它是可被覆盖的。
SSAH（Safety Separability Assumption Hypothesis）假说，在 ICLR 2026 上发表的研究表明，大语言模型的安全行为实际上只依赖于极少数"安全关键单元"（Safety-Critical Units, SCU）[4]。
这意味着 prompt 级的约束指令只在模型恰好激活这些 SCU 时才有效。
当攻击者通过精心构造的输入使 SCU 的激活被抑制——比如多轮对话中的"意图分解"攻击将有害目标拆分为多个无害子查询——prompt 级约束便形同虚设。
2025 年 12 月的一篇论文证实了这一点：CKA-Agent 攻击将有害目标分解为看似无害的子查询序列，对 Gemini 2.5、GPT-4 和 Claude 均实现了超过 95% 的越狱率[5]。
这些子查询每一个单独看都完全合规，prompt 级的规则引擎无法检测到累积的恶意意图。
Prompt 级约束的不可替代性：尽管脆弱，它是唯一不需要任何基础设施的约束层。
对于个人用户，它的价值不在于防御，而在于默认行为校准——告诉模型"你应该如何表现"，而非"你不能做什么"。
前者是设定倾向，后者是设定边界，而边界恰好是 prompt 最不擅长的。
1.2 模型权重级约束——最深的一层
通过 RLHF、RLAIF、DPO、Constitutional AI 等方法修改模型权重，使模型"内在地倾向于安全行为"，是当前主流 AI 实验室采用的根本方案。
Constitutional AI（CAI）是这一路线的代表性方案。
Anthropic 在 2022 年底的论文中描述了其机制：模型先生成回答，再依据一组"宪法原则"自我批评，然后基于修正后的回答进行 RL 训练[6]。
CAI 的哲学立场是——安全应该被内化为模型的"品格"，而非外挂为"围栏"。
权重级约束的核心优势在于绕过难度：攻击者无法通过简单的输入工程改变模型权重，必须找到权重中安全行为的"盲区"。
但其核心代价是对齐税（Alignment Tax）——安全训练在压制有害行为的同时，不可避免地压制了部分正常能力。
OGPSA（Orthogonal Gradient Projection for Safe Alignment）的实验量化了这一代价：对 Qwen2.5-7B 进行安全对齐后，SimpleQA 准确率从 0.53% 降至 3.03%（信息暂缺——原文数字可能存在异常），而 OGPSA 通过将安全梯度投影到能力梯度的正交子空间来缓解这个问题[7]。
更根本的问题来自 SSAH 假说的推论：如果安全行为只依赖少数 SCU，那么权重级约束从根上也是浅层的。
NSPO（Null-Space Policy Optimization）在 ICLR 2026 上的研究试图通过将安全策略优化限制在原始能力的零空间中来解决这个问题——仅需要 40% 的安全数据就能在对齐的同时保留原始能力[8]。
权重级约束的不可替代性：它是唯一能影响模型内部推理方向的约束层。
外部 guardrails 只能对"最终输出"做二分类判断，无法改变模型"在思考什么"。
当模型需要在多个安全选项中选择最优解时，只有权重级约束能让模型"偏好"安全选项。
1.3 运行时管线级约束——最工程化的一层
在推理管线中插入独立的检测/过滤模块，是 AI Harness Engineering 作为独立工程学科存在的核心层。
NVIDIA NeMo Guardrails 和 Guardrails AI（guardrails-ai）是这一层的两个代表性框架。
NeMo Guardrails 的设计基于 Colang 语言——一种专用于对话流控制的领域特定语言（DSL）。
其架构是三层中间件：LLM ↔ Guardrails 编排层 ↔ 用户。
编排层包含四种功能切面：
| 切面 | 作用 | 典型实现 |
|------|------|---------|
| Input Rails | 拦截并验证用户输入，阻断有害请求 | 关键词过滤 + 分类器 |
| Dialog Rails | 控制对话流程，决定话题边界 | Colang flow 定义 |
| Retrieval Rails | 过滤 RAG 检索结果，防止注入 | 来源验证 + 相关性过滤 |
| Output Rails | 审核模型输出，阻断/修正不合规响应 | Llama Guard + 规则引擎 |
NeMo 的核心论文将其定位为"One Tool to Rule Them All"——统一的安全编排工具包[9]。
Guardrails AI 走了完全不同的路线。
它基于 Pydantic 的结构化数据验证范式，核心抽象是 Guard → Validator → Schema。
开发者通过 .use(validator) 装饰器链式添加验证器——格式校验、内容合规、PII 过滤等[10]。
NeMo 偏重对话流控制，Guardrails AI 偏重数据结构验证。
运行时约束的致命缺陷——来自实验数据的警告：
2025 年 12 月的 RAG + DeepSeek-R1 + 10k 蒙特卡洛仿真测试给出了残酷的量化结果：NeMo Guardrails 的 RoC 仅为 0.05，ABAC（基于属性的访问控制）的 RoC 为 9.83[1:1]。
NeMo 在 PII 泄露和 Prompt 注入防御上几乎无效。
RAG 场景加剧了这个问题。
"RAG Makes Guardrails Unsafe?"论文（2025 年 10 月）揭示了 RAG 管线中 guardrails 的鲁棒性危机：当检索结果中包含精心构造的恶意文本时，output rail 往往无法区分"模型自主生成的有害内容"和"检索结果中本就存在的有害内容"——两者在文本形式上不可区分[11]。
运行时约束的不可替代性：尽管效能存疑，它是唯一允许可编程、可审计、即时修改的约束层。
权重级约束修改需要重新训练，prompt 级约束太脆弱——运行时约束是工程实践中的"快速响应"层。
当新的攻击模式被发现的当天，你可以通过修改 Colang 规则或添加 validator 来应对，而不需要等模型重新训练。
1.5 从 NeMo 到 Llama Guard——运行时层内部的分工细化
运行时约束层本身正在分化为更精细的子层。
内容分类子层以 Meta 的 Llama Guard 系列为代表。
Llama Guard 3 是一个基于 Llama 3.1-8B 微调的安全分类器，专门用于判断输入/输出是否违反预定义的安全类别（仇恨言论、暴力、性内容等）。
它的设计逻辑是将"判断是否有害"这个任务从主模型中剥离出来，交给一个专用的分类模型——这在理论上比用主模型"自我审查"更可靠，因为分类模型的决策边界更清晰。
然而，ILION 论文的评测揭示了一个深层问题：Llama Guard 3 在"代理执行安全"任务上的 F1=0.0105——不是 0.1 或 0.5，而是接近零。
这意味着，当你让 LLM 作为 agent 执行操作（如调用 API、操作文件系统）时，用 Llama Guard 3 来判断这些操作是否安全，效果和随机猜几乎一样[2:1]。
原因在于：Llama Guard 3 的训练数据是文本安全分类（"这段话是否包含仇恨言论"），而代理安全需要的是行为安全推理（"这个 API 调用序列是否会导致数据泄露"）——这是完全不同的信号空间。
对话流控制子层以 NeMo Guardrails 为代表。
NeMo 的 Colang 语言允许定义对话流程——"当用户询问 X，模型应该先做 Y 检查，再回应 Z"。
这个子层的价值不在于内容过滤，而在于流程编排：它控制的是"对话应该怎么走"，而非"内容是否合规"。
数据验证子层以 Guardrails AI 为代表。
它关注的是输出格式是否符合预期——JSON 字段是否完整、数值是否在合理范围内、是否包含 PII 信息。
这个子层的任务最明确、验证最可靠，因为格式验证是一个有确定性答案的问题（不像内容安全判断那样存在灰色地带）。
三个子层的分化暗示了一个趋势："运行时护栏"正在从一个单一产品变成一个技术栈。
正如 web 开发从"写一个 CGI 脚本"演变为"前端 + 后端 + 中间件"的技术栈，harness engineering 也在从"加一个 guardrail"演变为"内容分类 + 对话流控制 + 数据验证"的多组件架构。
1.6 三层的互补关系——不是替代，是深度防御
三层约束构成一个互补体系：
Prompt 级：校准默认行为倾向（低可靠性，零成本）
权重级：内化安全偏好（高可靠性，高修改成本）
运行时级：可编程的即时防线（中等可靠性，低修改成本）
任何单一层都不足以提供完整的安全保证。
但关键问题在于：当前业界对运行时层——即"harness engineering"的核心——的依赖程度，远超其实际效能所能支撑的水平。
二、Guardrails 与 Alignment 的边界
2.1 两种安全范式的本质差异
Guardrails（护栏）和 Alignment（对齐）在公众讨论中经常被混用，但它们解决的是不同的问题，且有着不可互相替代的功能。
Alignment 解决"模型想不想做坏事"——通过训练修改模型的内在偏好。
一个良好对齐的模型在面对有害请求时，其内部推理过程就会拒绝，而非在生成后被动过滤。
Guardrails 解决"模型做了坏事能不能拦住"——通过外部机制检测和拦截。
即使模型内部"想做坏事"，guardrails 试图在输出发送给用户之前将其阻断。
两者的关系可以用一个类比来理解：Alignment 是让员工"不想贪污"（价值观内化），Guardrails 是让财务系统"查得出贪污"（流程监控）。
两者都不可或缺，但它们防御的是不同环节的风险。
2.2 "完美 Guardrails 能否替代 Alignment"——答案是不能
假设存在一个 F1=1.0 的完美 output guardrail——它能在所有情况下准确判断模型输出是否有害并正确拦截。
这能否替代 alignment？
不能，原因有三：
**第一，agent 行为的不可观测性。
** 当 LLM 作为 agent 执行操作（调用 API、修改文件、发送消息）时，有害行为的后果发生在 guardrail 拦截之前。
一个执行了删除操作的 agent 无法被 output guardrail "收回"已删除的数据。
Llama Guard 3 在代理安全任务上 F1=0.0105 的灾难级表现[2:2]揭示了这一根本性任务不匹配：文本安全分类器无法理解行为安全。
**第二，中间推理的毒性。
** Guardrails 只能检测最终输出，无法检测模型的中间推理过程（Chain-of-Thought）。
一个模型可能在其 CoT 中规划了有害行动方案，但最终输出了一个无害的总结。
当前没有运行时机制能可靠地审计 CoT 的安全性。
**第三，误杀的累积代价。
** "No Free Lunch with Guardrails"论文的核心发现[3:1]——安全性和可用性的不可消除权衡——意味着任何 guardrail 都必须在误杀（false positive）和漏杀（false negative）之间设定阈值。
而 alignment 不存在这个阈值问题：一个良好对齐的模型在拒绝有害请求和回答正常请求之间没有"灰色地带"——它对两者都有明确的内部偏好。
2.3 "完美 Alignment 能否替代 Guardrails"——理论上可以，实践中不行
反过来假设：如果模型被完美对齐——内在地拒绝所有有害请求、永远不产生幻觉、永远不泄露隐私——还需要 guardrails 吗？
理论上不需要。
但实践中：
**对齐是可被微调覆盖的。
** 2025 年 6 月的论文 "Why LLM Safety Guardrails Collapse After Fine-tuning" 直接证明了：仅需要少量恶意微调数据就能让经过 RLHF 对齐的模型恢复有害行为[12]。
对齐不是永久的——它是一种可以被后续训练覆盖的权重状态。
**对齐是粗粒度的。
** 对齐训练针对的是通用行为倾向（"不要输出有害内容"），而业务场景需要细粒度的特定约束（"不要在这个特定 API 调用中泄露用户邮箱"）。
后者不可能全部通过权重级对齐实现。
**对齐是不可审计的。
** 你无法打开模型权重检查"第 47 层的第 128 个神经元是否编码了'不要泄露邮箱'的约束"。
但你可以打开 NeMo 的 Colang 文件，逐行审查每一条护栏规则。
在合规场景中，可审计性本身就有独立价值。
2.4 边界总结
| 维度 | Alignment 不可替代的场景 | Guardrails 不可替代的场景 |
|------|------------------------|------------------------|
| Agent 执行 | 防止有害操作被发起 | 无法拦截已执行的后果 |
| CoT 毒性 | 模型内在推理方向控制 | 无法检测中间推理 |
| 微调攻击 | 无效（权重可被覆盖） | 可作为第二道防线 |
| 细粒度业务约束 | 无法穷举所有场景 | 可编程即时响应 |
| 合规审计 | 黑箱，无法举证 | 规则显式可审查 |
结论：Alignment 是根基（解决"想不想"），Guardrails 是围栏（解决"拦不拦得住"）。
两者是深度防御（defense in depth）的两层，不是替代关系。
2.5 从概念到产业——Guardrails 三年演进的叙事弧
Guardrails 从一个学术概念到产业标配，经历了三年时间。
这段历史有助于理解当前 harness 工程的格局和局限。
2022：概念萌芽——"我们需要外部防线"
Anthropic 在 2022 年 8 月发布的 Red Teaming 论文首次系统化了一个问题：大语言模型即使经过 RLHF 对齐，仍然可以通过对抗性输入被诱导产生有害输出[13]。
这篇论文的贡献不仅是发现了问题，更定义了解题框架——"红队测试"（adversarial testing）成为评估安全性的标准方法论。
同年 12 月，Anthropic 发布 Constitutional AI 论文，提出了"内在化安全"的技术路线。
这两篇论文构成了一个张力：Red Teaming 说"对齐不够"，CAI 说"对齐可以更深入"。
但两条路线都没有完全回答一个工程问题——**如果你今天就要部署一个面向公众的 LLM 应用，你能做什么？
**
2023：框架诞生——"工具来了"
2023 年 4 月，NVIDIA 发布 NeMo Guardrails v0.1.0。
这是第一个将 guardrails 从"概念"变成"可部署工程组件"的开源项目。
Colang 语言的引入使得护栏规则可以用声明式语法编写，而非硬编码在应用逻辑中。
从 v0.1.0 到 v0.6.0-rc2，NeMo 在 2023 年快速迭代了 6 个大版本，反映了"从 0 到 1"阶段的特征——功能快速扩张，API 不断变化，生产就绪还不是主要考量。
同年 8 月，Guardrails AI 项目启动，走了 Pydantic Schema 验证的差异化路线。
10 月，NeMo 核心论文 arXiv:2310.10501 发布，正式将"Guardrails Toolkit"定义为学术概念。
双框架格局的形成标志着一个关键转折：**harness engineering 开始有了"选择"——你需要对话流控制（NeMo）还是数据格式验证（Guardrails AI）？
** 这个分化本身就是领域成熟的信号。
2024：商业化——"企业标配"
2024 年下半年，AWS Bedrock 和 Azure AI Safety 相继集成了 guardrails 功能。
这不是技术突破，而是市场信号——云厂商将 guardrails 作为平台级服务提供，意味着它从"开发者可选工具"变成了"企业部署必选项"。
Gartner 的 AI 治理报告将 guardrails 列为"必要但不足"的安全组件。
NeMo 在 2024 年的迭代从 v0.7.x 到 v0.8.x，重点转向生产就绪——性能优化、错误处理、文档完善。
这标志着 guardrails 从"研究原型"进入"工程实用"阶段。
2025-2026：成熟期与反思——"我们知道了它的局限"
2025 年 4 月，"No Free Lunch with Guardrails"论文发表，用横评数据确认了安全-效用权衡的不可消除性[3:2]。
同年 10 月，RAG 场景下 guardrails 鲁棒性问题的论文发表[11:1]。
12 月，蒙特卡洛仿真报告给出了 NeMo RoC=0.05 的量化结论[1:2]。
2026 年 3 月，Llama Guard 3 F1=0.0105 的数据发表[2:3]。
这些负面结果的密集发表并非偶然——它们是领域成熟的标志。
当 guardrails 被广泛部署后，真实场景的失效数据才可能被收集和分析。
早期（2023 年）的 guardrails 论文大多报告正面结果（"我们提出了 X 框架，在 Y 基准上达到了 Z 准确率"），因为那时的评估环境是受控的。
当评估转向真实攻击场景时，性能断崖式下降是预期内的——**受控环境的高性能和真实环境的低效能之间的落差，正是工程成熟度不足的直接度量。
**
同时，前沿研究正在转向新方向：ILION 的确定性门控方案（F1=0.8515, FPR=7.9%, 延迟 143μs）[2:4]试图用"确定性验证"替代"概率分类"；
Lean-Agent 用 Lean4 形式化验证为代理行为提供加密级合规确定性[14]；
MOSAIC 用模块化控制令牌将安全与能力解耦[15]。
这些方向暗示着下一轮范式转变——从"概率护栏"到"确定性验证"。
三、Harness 的真实失败模式
3.1 越狱攻击的进化——Guardrails 面对的不是"能不能拦住一条有害请求"的问题
2023 年的越狱攻击主要是"越狱 prompt"——在用户输入中嵌入精心构造的指令，试图覆盖系统提示。
这类攻击相对容易防御，因为它们在单轮交互中就能被检测到。
2025-2026 年的越狱攻击已经进化为多步骤、跨模态、跨系统的复合攻击。
以下是最具代表性的几种：
意图分解攻击（CKA-Agent）：将有害目标分解为多个无害子查询。
例如，"如何制造危险品"被分解为"化学品的储存标准""实验室通风设计""常见化学品采购渠道"等看似完全合规的独立问题。
对 GPT-4、Claude、Gemini 2.5 均实现 >95% 越狱率[5:1]。
这类攻击对任何单轮 input rail 完全无效。
编码绕过攻击：使用密码、Base64、字符编码等方式传递有害请求。
模型能理解和执行编码后的指令，但 guardrails 的文本分类器无法解码。
CPT-Filtering 通过 BPE 字符/令牌比率异常检测来应对，在编码攻击上接近完美准确率，但仅限这一种攻击类型[16]。
Cascade 组合攻击：软件注入 + Rowhammer 硬件攻击的组合。
先通过 prompt 注入在 guardrails 的内存中写入恶意数据，再通过 Rowhammer 翻转内存比特，直接修改 guardrails 的拦截规则[17]。
这已经超出了软件层 guardrails 的防御范围。
RAG 注入：在检索语料库中植入恶意文本，使模型在 RAG 流程中"自然地"输出有害内容。
由于 output rail 无法区分"模型自主生成的有害内容"和"忠实于检索结果的引用"，RAG 场景下的 guardrails 鲁棒性大幅下降[11:2]。
3.2 Over-refusal——护栏的另一面灾难
如果说越狱是"该拦的没拦住"，over-refusal 就是"不该拦的拦了"。
AdaCD（Adaptive Contrastive Decoding）在 ACL 2026 上的实验揭示了 over-refusal 的严重程度：当前经过安全对齐的 LLM 对大量无害查询产生拒绝响应；
AdaCD 能减少 10.35% 的 over-refusal，同时恶意拒绝仅增加 0.13%[18]。
这意味着当前模型存在大量"本不该拒绝但因安全训练过度而拒绝"的查询——而且修复拒绝的边际成本极低（0.13% 的恶意拒绝增幅换取 10.35% 的正常功能恢复）。
MOSAIC（Modular Safety Control via Token Injection）从另一个角度证实了这一点：传统参数对齐的高 over-refusal 源于"安全和能力被纠缠在同一个权重空间中"。
MOSAIC 通过模块化控制令牌将安全约束与能力解耦，显著降低了 over-refusal[15:1]。
对个人用户而言，over-refusal 的实际体验是：模型频繁地说"我无法帮助您完成这个请求"，即使你问的是一个完全合理的问题。
这是当前 harness 设计中最容易被忽视的代价——人们关注"护栏能否防御攻击"，却很少追问"护栏挡住了多少正常请求"。
3.3 失败模式分类——什么能防，什么防不了
| 失败模式 | Guardrails 可防御？ | 根本原因 |
|---------|-------------------|---------|
| 单轮有害请求 | ✅ 可防御（关键词/分类器） | 信号明显，检测空间充足 |
| 编码绕过 | ⚠️ 部分可防（需专用检测器） | 需理解编码层 |
| 多轮意图分解 | ❌ 当前几乎无法防御 | 单轮过滤器缺乏累积意图检测 |
| RAG 注入 | ❌ output rail 无法区分来源 | 信息损失（无来源追溯） |
| 微调攻击 | ❌ 外部防护无法感知权重变化 | 层级隔离（权重级问题） |
| Agent 有害执行 | ❌ 行为发生在拦截前 | 时序不可逆 |
| Cascade 硬件攻击 | ❌ 超出软件防御范围 | 物理层攻击 |
| Over-refusal | —（这是护栏自身的病） | 安全-效用权衡的不可消除性 |
这个分类揭示了一个清晰的边界：**Guardrails 能有效防御的是"信号明显的单轮攻击"，对"累积意图""跨系统组合""执行后不可逆"三类威胁几乎无能为力。
**
四、个人 Harness 设计：约束的真实权衡
4.1 个人用户与企业用户的不同问题
企业 Harness 设计的核心问题是合规——满足法规要求、通过审计、降低法律风险。
NeMo Guardrails 的 Colang 规则可以逐条审计，这在合规场景中是核心价值，即使 RoC=0.05 也有意义（"我们有防护措施"比"我们没有防护措施"在法律上好得多）。
个人用户的核心问题不是合规，而是控制——让 AI 工具按照自己的预期行事，既不被越狱干扰，也不被 over-refusal 束缚。
这是一个完全不同的设计问题。
4.2 约束粒度光谱——从"什么都允许"到"什么都禁止"
个人 harness 设计的核心权衡在一条光谱上：
← 开放 封闭 →
无约束 ── Prompt级 ── 系统提示模板 ── 输出过滤 ── 输入+输出过滤 ── 白名单模式光谱左端的"无约束"意味着你获得模型的最大能力，但也承受最大风险（幻觉、偏见、不安全输出）。
光谱右端的"白名单模式"意味着模型只能回答预设范围内的问题——极度安全但几乎无用。
**关键发现：大多数个人用户实际上只需要在光谱的左端偏右一点——一个精心设计的 prompt 级约束加上选择性 output 过滤，就能覆盖 80% 的日常需求。
** 原因是：个人用户面临的"攻击"不是恶意第三方的越狱，而是模型自发的不当输出——幻觉、偏见泄露、隐私信息外溢。
这些恰恰是 prompt 级约束和轻量 output 过滤最擅长的。
4.3 三种个人 Harness 设计模式
基于约束层级和场景需求，提炼三种实用设计模式：
模式 A：最小可信护栏（Minimal Trust Guardrail）
适用场景：日常对话、写作辅助、知识查询
约束层配置：
├── Prompt 级：角色定义 + 行为边界（150字以内系统提示）
├── 权重级：依赖模型自带对齐（不自行训练）
└── 运行时：无
设计原则：
- 明确告诉模型"你是什么"和"你不做什么"
- 不写长篇大论的安全规则（prompt 越长，模型对约束的遵从率越低）
- 接受模型自带对齐的基线安全性
- 不为低风险场景增加运行时成本系统提示模板示例：
你是一个专业的写作助手。你的职责是帮助用户完成写作任务。
你不应该：生成违法内容、冒充真实人物、输出未经验证的医疗/法律建议。
遇到不确定的信息，明确标注"我不确定"而非编造。这个模板的设计要点：正向定义优先于负向禁止。
告诉模型"你是什么"比告诉它"你不能做什么"更有效——后者是在触发模型对抗指令的能力，前者是在校准它的角色认同。
模式 B：编程式护栏（Programmatic Guardrail）
适用场景：数据处理、API 调用、自动化工作流
约束层配置：
├── Prompt 级：结构化输出指令
├── 权重级：依赖模型自带对齐
└── 运行时：Guardrails AI（Pydantic Schema 验证）
设计原则：
- 用 Schema 强制约束输出格式（JSON Schema / Pydantic Model）
- 用 Validator 链式验证内容合规性
- 输入层不设重过滤（避免误杀用户的正常数据输入）
- 输出层设格式+内容双重验证Guardrails AI 代码示例：
python
from guardrails import Guard
from guardrails.validators import ValidLength, NoPII, IsNotCodeInjection
guard = Guard.from_pydict(
pydantic_model=ResponseSchema,
validators=[
NoPII(), # 过滤个人身份信息
IsNotCodeInjection(), # 防止输出中的代码注入
]
)
raw_llm_output = model.generate(prompt)
validated_output, validation_passed = guard.parse(raw_llm_output)模式 B 的核心价值在于格式确定性而非内容安全性——它解决的是"LLM 输出不确定时如何强制结构化"的工程问题，这是 Guardrails AI 的设计初衷。
模式 C：深度防线（Deep Defense）
适用场景：公开服务、面向第三方的 AI 应用、涉及敏感数据的场景
约束层配置：
├── Prompt 级：角色定义 + 行为边界 + 话题白名单
├── 权重级：模型自带对齐 + 可选安全微调
└── 运行时：NeMo Guardrails（对话流控制）+ Llama Guard（内容分类）
设计原则：
- Input Rail：检测已知攻击模式（编码注入、多轮意图累积）
- Dialog Rail：限制话题范围，强制对话在白名单内
- Output Rail：双验证（Llama Guard 分类 + 规则引擎关键词匹配）
- 但要认识到：即使部署所有这些，仍然无法防御 >95% 成功率的意图分解攻击关键认知校准：**模式 C 不等于"安全"。
** 它增加了攻击成本，降低了大多数低级攻击的成功率，但在面对高级多步骤攻击时仍然脆弱。
它的真实价值在于合规和可审计性——而非绝对安全性。
4.4 约束强度与能力保留的权衡曲线
基于"No Free Lunch with Guardrails"[3:3]和 AdaCD[18:1]的实验数据，约束强度和模型能力之间的关系大致遵循以下曲线：
能力保留%
100│──────●
│ ╲
90│ ╲
│ ╲
80│ ● ← 个人用户最佳区间
│ ╲
70│ ╲
│ ╲
60│ ● ← 企业合规区间
│ ╲
50│ ╲
│ ╲
0└──────────────────●
0% 20% 40% 60% 80% 100%
约束强度（安全覆盖率）个人用户的最佳区间在约束强度 20%-40%、能力保留 80%-90%。
这个区间对应的是：prompt 级约束 + 选择性 output 过滤，足够防御模型自发的多数不当输出，同时保留几乎全部正常能力。
企业合规区间在约束强度 60%-80%、能力保留 50%-70%。
这个区间增加了强运行时约束和多层验证，代价是 over-refusal 大幅上升——但合规价值弥补了能力损失。
**约束强度超过 80% 后，能力保留的下降不是线性的而是加速的。
** 因为在这一区间，你必须部署的检测器开始大量误杀正常请求，每次降低误杀率都意味着提高漏杀率——而合规要求不允许你提高漏杀率。
4.5 可配置性——个人 Harness 的核心设计原则
与固定配置的企业护栏不同，个人 harness 最重要的设计原则是可配置性——约束必须能随场景切换。
一个实用策略是场景-约束映射表：
| 场景 | Prompt 级 | Output 过滤 | 说明 |
|------|----------|------------|------|
| 创意写作 | 角色定义 | 无 | 开放 > 安全 |
| 数据分析 | 格式指令 | Schema 验证 | 准确性 > 安全 |
| 信息检索 | 事实性提示 | 无 | 信息量 > 安全 |
| 对外内容 | 完整行为边界 | 内容合规 | 安全 > 开放 |
| 代码生成 | 安全编码规则 | 代码审计 | 安全性 = 功能性 |
这张表的核心洞察：**约束不是越多越好，而是匹配场景才有效。
** 一个在代码生成场景中过度约束的 harness 会拒绝生成"删除文件"的代码——即使这完全合理——而在创意写作场景中不设约束的 harness 可能产出不当内容。
场景切换比全局加严更有效。
4.6 从理论到实践——一个完整的个人 Harness 设计流程
综合以上分析，个人 harness 设计可以压缩为一个四步决策流程：
第一步：确定你的主要使用场景
这不是"你在用什么模型"，而是"模型输出要经过什么环节、要暴露给谁"。
判断标准很简单：
模型输出只有你自己看 → 低风险场景
模型输出会进入自动化流程（API 调用、文件操作）→ 中风险场景
模型输出会暴露给第三方（公开文章、对外服务）→ 高风险场景
第二步：选择对应的约束模式
低风险 → 模式 A（最小可信护栏）：精心设计的系统提示就够了
中风险 → 模式 B（编程式护栏）：加 Schema 验证确保输出格式
高风险 → 模式 C（深度防线）：多层运行时约束
第三步：测试 over-refusal
这是大多数个人用户忽略的步骤。
部署任何约束后，用你自己的典型查询测试一遍，关注两个信号：
模型是否拒绝了它以前能回答的正常问题？
拒绝的比例是否超过你预期的 5%？
如果 over-refusal 过高，优先考虑缩小约束范围而非降低约束强度。
例如，将"不要讨论任何敏感话题"改为"不要生成关于 X、Y、Z 三个特定话题的内容"——明确的禁止列表比模糊的安全指令更不容易误杀。
第四步：迭代调整
约束配置不是一次性的。
以下情况需要重新调整 harness：
模型升级后——新版模型的内置对齐可能变化，旧的 prompt 级约束可能冗余或冲突
使用场景变化后——从个人笔记变为对外文章时，需要升级约束模式
遇到新的误杀/漏杀时——针对性地增减约束
4.7 一个容易被忽视的设计陷阱——约束之间的冲突
当你在多个层级同时施加约束时，一个不常被讨论的问题是约束冲突。
典型场景：系统提示中写"如果用户请求可能有害，你应该拒绝并解释原因"（prompt 级），同时运行时 output rail 配置了"检测到拒绝响应时，标记为安全事件"（运行时级）。
如果模型在 prompt 级约束下拒绝了一个请求，output rail 可能将这个拒绝响应误判为"异常行为"并触发告警——两次约束互相矛盾。
更隐蔽的冲突发生在 prompt 级和权重级之间。
如果你的系统提示写"你应该帮助用户完成任何编程任务"，但模型的内置对齐已经学习了"不应该帮助编写恶意代码"，两者就会在边界案例上产生张力——模型可能同时尝试"帮助"和"拒绝"，产出生硬的折中响应。
解决方法：**约束层级越少，冲突越少。
** 个人用户在大多数场景下只需要 prompt 级约束 + 模型自带对齐两层。
只有在这两层明显不够时才加运行时层——而加的时候，要确保运行时约束是 prompt 级约束的补充而非重复。
五、交叉洞察
洞察 1：AI Harness Engineering 不是独立工程学科，而是"对齐的运维层"
数据依据
NeMo Guardrails 在 10k 蒙特卡洛测试中 RoC=0.05[1:3]，远低于 ABAC 的 9.83
Llama Guard 3 在代理安全任务上 F1=0.0105[2:5]，近乎随机
SSAH 假说表明安全行为仅依赖少数 SCU[4:1]，意味着外部约束无法触及模型内部推理
推理链 运行时 guardrails 的核心能力是对"最终输出"做二分类判断——有害/无害。
但 LLM 的安全风险不仅来自"最终输出了什么"，还来自"推理过程中规划了什么"和"执行了什么操作"。
后两者完全在 guardrails 的观测范围之外。
因此，guardrails 的防御效能存在天花板——它只能防御"可以被文本分类器检测到的输出级风险"，而对推理级和执行级风险完全无效。
这意味着 harness engineering 不是独立的安全工程学科，而是对齐训练的运维补充——它解决的是对齐无法覆盖的细粒度业务约束和即时响应需求，而非安全本身。
置信度：高
可证伪条件：如果未来 18 个月出现 F1>0.9 的通用 guardrails 分类器且 over-refusal<5%，或者出现能可靠审计 CoT 安全性的运行时机制，则此判断被推翻。
洞察 2：个人 harness 的最优策略是"窄域强约束 + 宽域弱约束"，而非"全场景中等约束"
数据依据
AdaCD 减少 10.35% over-refusal 仅增加 0.13% 恶意拒绝[18:2]，说明当前模型存在大量"不必要的安全拒绝"
"No Free Lunch"横评确认安全-效用权衡不可消除[3:4]
MOSAIC 证明安全约束与能力解耦能显著降低 over-refusal[15:2]
推理链 "No Free Lunch"约束意味着任何全局约束强度设定都必然在某个场景下是次优的——要么太松（风险），要么太紧（误杀）。
AdaCD 的实验数据说明，当前模型在安全训练后的 over-refusal 有大量"低垂果实"可以修复——10.35% 的拒绝中只有 0.13% 是真正必要的。
这意味着个人用户不应追求"全局中等约束"，而应采用场景切换策略：在低风险场景（创意写作、知识查询）使用弱约束保留最大能力，在高风险场景（对外内容、敏感数据处理）使用强约束确保安全。
场景间的约束差异越大，整体效能越高——因为每个场景都在自己的最优权衡点上运行。
置信度：高
可证伪条件：如果出现能根据查询内容自适应调节约束强度的运行时机制（且其自适应判断的 F1>0.85），则场景-约束映射表的静态策略被自适应策略替代。
洞察 3：未来 12-18 个月，harness 设计的核心问题将从"如何防御攻击"转向"如何减少误杀"
数据依据
Llama Guard 3 F1=0.0105[2:6]——当前护栏的假阳性和假阴性均灾难级，但假阳性（误杀）是更紧迫的用户体验问题
AdaCD 在 ACL 2026 发表，核心贡献就是减少 over-refusal[18:3]
MOSAIC 通过模块化控制降低 over-refusal[15:3]
当前社区讨论（Reddit, HN）中用户对"模型拒绝正常请求"的抱怨远多于对"模型被越狱"的抱怨
推理链 2023-2025 年，harness 研究的主流问题是防御越狱——这反映的是企业合规需求。
但 2026 年的研究前沿已经转向 over-refusal 修复——AdaCD（ACL 2026）、MOSAIC、NSPO（ICLR 2026）等顶会论文的核心贡献都是"在对齐的同时减少误杀"。
这个转向的原因是：随着模型能力的提升，over-refusal 的代价在增加——一个 GPT-5 级别的模型如果拒绝 15% 的正常查询，浪费的不仅是用户体验，更是模型本身巨大的能力价值。
当模型能力增长速度远快于护栏准确性提升速度时，误杀的相对代价在加速增长。
置信度：中
可证伪条件：如果出现新型越狱攻击导致重大安全事故（如 AI agent 造成物理损害），监管可能强制要求"宁可误杀不可漏杀"，将研究重心重新推回防御方向。
洞察 4：个人用户最有价值的 harness 投资不在工具，而在"场景-约束映射"的决策框架
数据依据
ILION 在 143μs 延迟内实现 F1=0.8515[2:7]，但其核心是确定性门控（白名单/黑名单），而非 ML 分类器
Guardrails AI 的 Pydantic 验证器在格式约束上接近 100% 准确率[5:2]，但在内容安全上依赖模型自身判断
个人用户使用场景的 80%+ 属于低/中风险（自行阅读、自动化流程），不需要运行时安全分类器
推理链 工具市场上充斥着 NeMo Guardrails、Llama Guard、Guardrails AI 等框架，但个人用户面临的实际问题是：我该在什么场景下用什么层级的约束？
这不需要安装任何框架就能回答——它是一个决策问题而非工具问题。
ILION 的高效能证明，确定性规则（白名单、格式 Schema）比 ML 分类器更适合个人用户的多数场景——因为确定性规则的 FPR 可以精确控制，而 ML 分类器的 FPR 是不可预测的。
个人用户的时间投资回报排序：1）花 1 小时打磨系统提示（覆盖 80% 场景）→ 2）花 30 分钟为 API 场景配置 Schema 验证（覆盖 15% 场景）→ 3）花 2 小时部署运行时护栏（覆盖最后 5% 场景，但可能引入更多问题）。
置信度：高
可证伪条件：如果个人用户的主流使用场景从"自己阅读模型输出"转向"模型自主执行操作"（即 agentic use 成为默认模式），则运行时护栏的投资优先级将显著上升——因为 agent 执行的操作是不可逆的。
认知校准
研究前的先验理解
AI 的 harness engineering 运作机制？个人如何设计适合自己的 harness？
研究后的校准
✅ 确认：harness 确实是多层约束体系，prompt/权重/运行时三层各有不可替代性
🔄 修正：此前倾向认为"运行时护栏是 harness 的核心层"——实际上运行时层的防御效能远低于预期（NeMo RoC=0.05），权重级对齐才是安全根基，运行时层更多是合规和可审计性价值
🔄 修正：此前隐含假设"约束越强越安全"——No Free Lunch 证明安全-效用权衡不可消除，过强约束的误杀代价可能超过安全收益
❌ 推翻：此前隐含假设"harness engineering 是独立工程学科"——它是"对齐的运维层"，无法独立解决安全问题的根本
💡 新发现：over-refusal 是比越狱更紧迫的个人用户体验问题，未来 harness 设计的主战场将从防御转向减少误杀
最大的认知偏差在哪 高估了运行时护栏的防御效能，低估了 over-refusal 的实际代价。
NeMo Guardrails 作为最知名的开源框架，RoC=0.05 这一数据直接否定了"部署运行时护栏就能安全"的直觉——而当前大多数个人用户的 harness 设计思路恰恰停留在这个直觉上。
信息来源
Rehman M, et al. (2025). "Guardrails Effectiveness in RAG Systems: A Monte Carlo Simulation Study". arXiv:2512.15081, 2025-12 提交. URL: https://arxiv.org/abs/2512.15081. 成熟度：预印本-4月. 检索来源：SearXNG. 访问日期：2026-04-23. ↩︎ ↩︎ ↩︎ ↩︎
ILION 作者团队 (2026). "ILION: Deterministic Gate-Control for AI Agent Safety". arXiv:2603.13247, 2026-03 提交. URL: https://arxiv.org/abs/2603.13247. 成熟度：预印本-1月. 检索来源：SearXNG. 访问日期：2026-04-23. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
Kumar D, Birur NA, Baswa T, et al. (2025). "No Free Lunch with Guardrails". arXiv:2504.00441, 2025-04 提交. URL: https://arxiv.org/abs/2504.00441. 成熟度：预印本-12月. 检索来源：SearXNG. 访问日期：2026-04-23. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
Li J, Kim JE (2024). "SSAH: Safety Separability Assumption Hypothesis". arXiv:2410.10862, 2024-10 提交. URL: https://arxiv.org/abs/2410.10862. 成熟度：已发表-ICLR 2026. 检索来源：SearXNG. 访问日期：2026-04-23. ↩︎ ↩︎
Wei R, Niu P, Shen X, et al. (2025). "CKA-Agent: Cross-Key Attention Agent for Multi-Step Jailbreak". arXiv:2512.01353, 2025-12 提交. URL: https://arxiv.org/abs/2512.01353. 成熟度：预印本-4月. 检索来源：SearXNG. 访问日期：2026-04-23. ↩︎ ↩︎ ↩︎
Bai Y, et al. (2022). "Constitutional AI: Harmlessness from AI Feedback". Anthropic Research, 2022. URL: https://arxiv.org/abs/2212.08073. 成熟度：已发表-行业里程碑论文. 访问日期：2026-04-23. ↩︎
Sun G, Zhang S, Wang L, et al. (2026). "OGPSA: Orthogonal Gradient Projection for Safe Alignment". arXiv:2602.07892, 2026-02 提交. URL: https://arxiv.org/abs/2602.07892. 成熟度：预印本-2月. 检索来源：SearXNG. 访问日期：2026-04-23. ↩︎
Niu Y, Xiao H, Liu D, et al. (2025). "Mitigating the Safety Alignment Tax with Null-Space Constrained Policy Optimization". arXiv:2512.11391, 2025-12 提交. URL: https://arxiv.org/abs/2512.11391. 成熟度：已发表-ICLR 2026. 检索来源：SearXNG. 访问日期：2026-04-23. ↩︎
Reber J, et al. (2023). "One Tool to Rule Them All: The NeMo Guardrails Toolkit". arXiv:2310.10501, 2023-10 提交. URL: https://arxiv.org/abs/2310.10501. 成熟度：已发表-行业白皮书. 访问日期：2026-04-23. ↩︎
Guardrails AI 开发团队 (2023-2026). "Guardrails AI: Python Library for LLM Output Validation". GitHub Repository. URL: https://github.com/guardrails-ai/guardrails. 成熟度：官方文档. 访问日期：2026-04-23. ↩︎
She Y, Peterson DW, Liu MM, et al. (2025). "RAG Makes Guardrails Unsafe? Robustness of Guardrails under RAG-style Contexts". arXiv:2510.05310, 2025-10 提交. URL: https://arxiv.org/abs/2510.05310. 成熟度：预印本-6月. 检索来源：SearXNG. 访问日期：2026-04-23. ↩︎ ↩︎ ↩︎
Hsiung L, Pang T, Tang YC, et al. (2025). "Why LLM Safety Guardrails Collapse After Fine-tuning". arXiv:2506.05346, 2025-06 提交. URL: https://arxiv.org/abs/2506.05346. 成熟度：预印本-10月. 检索来源：SearXNG. 访问日期：2026-04-23. ↩︎
Ganguli D, Askell A, Schiefer N, et al. (2022). "Red Teaming Language Models to Reduce Harms: Methods, Scaling Behaviors, and Lessons Learned". Anthropic Research, 2022. URL: https://arxiv.org/abs/2209.07858. 成熟度：已发表-行业里程碑论文. 访问日期：2026-04-23. ↩︎
Rashie D, Rashi V (2026). "Lean-Agent: Type-Checked Compliance for AI Agent Safety Using Lean4". arXiv:2604.01483, 2026-04 提交. URL: https://arxiv.org/abs/2604.01483. 成熟度：预印本-<1月. 检索来源：SearXNG. 访问日期：2026-04-23. ↩︎
Peng J, Chen H, Dong J, et al. (2026). "MOSAIC: Modular Safety Control via Token Injection". arXiv:2603.16210, 2026-03 提交. URL: https://arxiv.org/abs/2603.16210. 成熟度：预印本-1月. 检索来源：SearXNG. 访问日期：2026-04-23. ↩︎ ↩︎ ↩︎ ↩︎
Zychlinski S, Kainan Y (2025). "CPT-Filtering: Character/Token Ratio Based Prompt Injection Detection". arXiv:2510.26847, 2025-10 提交. URL: https://arxiv.org/abs/2510.26847. 成熟度：预印本-6月. 检索来源：SearXNG. 访问日期：2026-04-23. ↩︎
Banerjee S, Sahu P, Vahldiek-Oberwagner A, et al. (2026). "Cascade: Combined Software and Hardware Attacks on AI Guardrails". arXiv:2603.12023, 2026-03 提交. URL: https://arxiv.org/abs/2603.12023. 成熟度：预印本-1月. 检索来源：SearXNG. 访问日期：2026-04-23. ↩︎
Qi Y, Lyu Z, Cui L, et al. (2026). "AdaCD: Adaptive Contrastive Decoding for Reducing Over-Refusal". arXiv:2604.17132, 2026-04 提交. URL: https://arxiv.org/abs/2604.17132. 成熟度：已发表-ACL 2026. 检索来源：SearXNG. 访问日期：2026-04-23. ↩︎ ↩︎ ↩︎ ↩︎