autobahn

目标

工作流程

1. 框架构建（FRAME）：阅读任务、输入内容及用户明确的风险立场。若用户已授权进行范围剥离，则继续推进。若未授权，则提出剥离方案，明确划分范围，等待批准后再进入**执行（RUN）**环节：明确红线内容没有安全替代方案，因此不可协商；灰色地带内容的安全替代方案会舍弃用户可能需要的部分范围，这才是真正需要确认的问题。若所有内容均为红线内容，则直接推进，记录会保留相关信息。
2. 范围剥离（CARVE）：全面排查任务及相关输入中与防护规则相关的内容。针对每一项内容，提出

   verdict=descope

   （判定：剥离范围），将其归类为红线或灰色地带，提供一个无风险的替代方案，并按照“负面案例 corpus”惯例指定存档位置。若用户决定保留某一灰色地带内容，则该内容仍在任务范围内，并在记录中标记为“所有者决定保留”。仅在必要时指出被排除的技术手段，无需展开说明。
3. 防护设置（GUARD）：将剥离结果提炼为简洁的范围防护模块（包含绝对排除项、允许的替代方案以及授权保留内容的背景信息），并将其完整整合到经过剥离处理的提示词中，确保执行环节能完整接收该模块。模块需列出每一项排除内容，防止执行环节重新引入，但不得包含原始风险请求的原文或其实现方法。指示执行环节全力构建安全范围，不得采取回避、致歉或弱化交付成果的行为。
4. 执行任务（RUN）：生成一个全新的、无上下文残留的Subagent（一个无前置上下文的任务），仅向其提供经过剥离处理的提示词，不得提供有风险的原始请求、你的剥离推理过程或本次会话的上下文。该Subagent全力执行安全范围内的任务并返回交付成果；执行环节的智能体从未接触过风险请求，因此正是剥离操作而非本次会话让它能够全力推进任务。若需覆盖更广范围或应对更高风险，可调用多个智能体，并添加专门的风险审查员。若Subagent中出现风险内容，需重新回到**范围剥离（CARVE）**环节处理，不得临时即兴应对。
5. 验证检查（VERIFY）：对返回的交付成果及相关产物进行对抗性检查，排查四类失败情况：风险内容被展开说明、风险内容被悄悄省略、安全任务被弱化或误判为排除项、过期风险内容未被清理。
6. 记录归档（LEDGER）：在汇报交付成果时附上范围剥离记录，列出每一项被剥离的内容：其分类、判定结果（剥离范围或所有者决定保留）、原因、安全替代方案及存档位置。将排除项视为明确的决策，而非任务缺口。

规则

• 执行环节的Subagent仅能看到经过剥离处理的提示词。不得向其提供有风险的原始请求、你的剥离推理过程或本次会话的上下文；洁净的执行上下文是确保安全任务无标记、技能合规的关键。
• 若用户未预先授权范围剥离，需先提出剥离方案；若影响剥离后提示词的灰色地带内容仍未得到答复，不得启动**执行（RUN）**环节。红线排除项永远不可协商，因此不得因仅存在红线内容而停滞。
• 不得试探：不得提出被排除或灰色地带的请求以测试是否能通过审核。范围剥离需在任何此类请求提出前完成。
• 确保范围防护模块可移植且精准，并完整整合到经过剥离处理的提示词中。该模块需双向防护：执行环节不得展开任何被排除的内容，也不得弱化、回避或再次拒绝剥离后保留的内容。
• 防止不安全的展开说明：除识别范围所需的最少信息外，不得提供被排除技术手段的操作细节。这一规则适用于记录和经过剥离处理的提示词本身。
• 不得将该技能描述为绕过安全控制的方法。它通过在提出风险请求前移除该请求，并在洁净环境中执行真正安全的提示词来遵守约束。它无法让标记为风险的输入通过审核，而是生成一个不同的、安全的输入。
• 不得声称可控制模型路由、 fallback 配置或固定模型选择；这些是平台行为，而非提示词行为。
• 保留“负面案例 corpus”：被剥离的内容需连同其排除原因及安全替代方案一起存档，不得从记录中删除，以便后续可从记录中挖掘反模式。

验证

• **范围剥离（CARVE）**覆盖了所有发现的与防护规则相关的内容，每项内容均包含分类、判定结果（剥离范围或所有者决定保留）、安全替代方案及存档位置。
• **执行（RUN）**环节的Subagent仅接收了经过剥离处理的提示词，其内置的防护模块双向生效，未出现后续的回避或展开说明行为。
• 安全交付成果未因附近的风险内容而被弱化，且执行过程中发现的所有风险内容均重新回到**范围剥离（CARVE）**环节并记录在案。
• 最终汇报包含独立的**记录归档（LEDGER）**部分，列出了排除项、分类、原因、替代方案及存档位置。