一、基础概念与核心思想 Q1：什么是 Agent 的 Harness？为什么要把安全边界外置到 Harness？ 回答要点： Harness 是连接模型、工具和真实执行环境的那一层——模型是大脑，Harness 是手脚，业界共识是 Model + Harness = Agent。 Agent 拿到工具调用、代码执行、文件操作权限后，能力和风险同时上升。而模型本身的行为是概率性的：提示词它能无视、hooks 配置极端情况下能改写，所以不能把安全押在模型”自觉”上。必须把边界外置到 Harness，落在模型改不动的执行点（沙箱、网络出口、白名单通道、CI 门禁）上。 目标是建设一套”就算模型犯错也兜得住”的工程化护栏：事前隔离授权、事中循环封顶/人机分级/哨兵熔断、事后门禁/审计/自迭代。 加分点： Agent-First 下人的工作从写代码变成三件事——设计 Agent 工作环境、写规范、拆分与验收任务；修缺陷往往要同时改 Harness，防止同类问题再犯。

Q2：Harness 安全的核心思想是什么？ 回答要点： 一句话：Never Trust, Always Verify（永不信任，持续验证）——默认不信任任何输入、任何中间产物、任何工具调用，在生命周期每一环持续校验。 落地靠两个方法论： 纵深防御（Defense in Depth）：不指望单层自闭环，层层设卡——信息边界、工具系统、执行编排、系统隔离，动作落地后再过门禁层做可程序化裁决；一层被穿透还有下一层兜底。 运行时安全（Runtime Security）：静态规则只降概率，运行时持续监控、动态拦截和降级才兜底。

Q3：Harness 安全有哪几条设计原则？ 回答要点（四条）： 把 Harness 当一等治理对象：像管代码一样管 Harness 配置（工具集、权限、门禁、规则注入），而不是散落在各处的提示词。 按 model–harness 组合评估：安全性不看”模型多聪明”，看”模型 + 这套 Harness”整体表现；换模型必须连同 Harness 一起重评。 状态变更动作必须可中断、可恢复、可逆——这是快照、回滚、三色卡等机制的依据。 边界设在模型改不动的地方：提示词、hooks、配置文件是”软约束”，Agent 能读、极端情况下能改写或无视；真正的强制点落在网络/会话/系统层这类 Agent 绕不过的 enforcement point。 加分点： 留痕要求要硬——任何发送给模型的内容都必须能从日志重建；会话是只追加、不可改的事件日志，因此能分叉、断点续传、事后审计。

Q4：“事前/事中/事后”和研发流水线阶段（SDLC）是什么关系？ 这是两套正交的分类，面试很容易混： 事前/事中/事后是安全时序：护栏相对某个危险动作的时机——事前防（隔离、白名单、输入净化）、事中控（运行时校验、循环封顶、人工介入）、事后兜（门禁裁决、审计、自迭代）。 需求/设计/编码/发布是 SDLC 阶段：同一个”编码阶段”里，既有事前注入的规则，也有事中的循环封顶。 别把箭头读成日历时序——体系总览图里的箭头是一次调用穿过各层的顺序，不是时间先后。

二、风险识别：两类风险 Q5：Agent 自身有哪些工程侧失效模式？ 这类风险不来自攻击者，不设防也会自然发生，共四种： 失效模式 含义 对策 代码腐化 Code Rot 每次生成都可能引入风格不一致、冗余、次优实现，单次无感、累积成灾 外部化、自动化验证质量，不依赖 Agent 自我审查 自我确认偏差 同一个 Agent 既写又评，评的是自己刚写的东西，结论几乎总是”没问题” 写和评不能是同一个 Agent（角色隔离） 失控循环 Doom Loop 在一个错误上无限打转，反复改同一处、越改越乱，烧光预算时间 成本包络（循环封顶）+ 触顶交人 上下文漂移/长任务失焦 多轮后被历史带偏、忘记原始目标 最小知识 + 精确回退到责任阶段

Q6：提示词注入（Prompt Injection）和越狱（Jailbreak）有什么区别？ 注入攻的是应用层：“应用把可信 Prompt 与不可信输入拼接”这一层，攻击者在数据里夹带指令。 越狱攻的是模型自身对齐：诱导模型违反安全对齐。 关键结论：只做越狱防护挡不住 IPI，两者是不同层面的问题，防护手段也不同。 Q7：DPI 和 IPI 的区别？ DPI（直接提示词注入）：直接在用户输入框里写”忽略之前的指令”。 IPI（间接提示词注入）：把指令藏进网页、PDF、代码注释、工具描述、知识库检索结果里，等 Agent 读到才触发。 Agent 会主动消费大量外部内容，所以 IPI 面比 ChatBot 时代大得多。 Q8：为什么说从 ChatBot 到 Agent，注入风险升级了？ ChatBot 只回答问题，注入最多污染输出；Agent 进入 Agent Loop 并拥有工具权限后，注入会影响行为、数据流向、权限边界，从内容安全问题升级为系统安全问题——一句话诱导可能触发发邮件、改权限、删数据。 Q9：为什么说注入”可能永远无法完全缓解”？那防护目标是什么？ 单点检测器会被编码、零宽字符、语义改写绕过，所以目标不是 100% 消除，而是： 持续压低攻击成功率； 锁死损失上限（沙箱限爆炸半径、白名单限动作、熔断止扩散）。 方法论上必须纵深分层，不能指望一个检测器。

三、事前 · 防（成本最低、收益最高） Q10：事前设防的三层，按什么顺序建？ 建防顺序是由外到内（注意与一次调用穿过的”信息边界→工具→编排→隔离”请求路径相反）： 先锁物理墙——系统隔离层； 再收能力面——工具系统层； 再收上下文——信息边界层。 Q11：系统隔离层怎么做？ 三条理论： OS 级隔离沙箱：代码/文件/网络限制在 OS 级沙箱里锁死爆炸半径；应用层沙箱不可靠。 凭证不落 Agent 主机：真实凭证不驻留 Agent 机器，执行点按调用注入短时任务域 token。 收敛可达面：运行前就把网络可达面收敛到项目必需的最小集合。 典型实践：整条流水线跑在 OS 级隔离的云研发沙箱（CDE），一人一盒子、只在指定工作区读写、外发走受控出口；平台凭证由平台侧注入、Agent 侧无裸 token；devflow doctor 启动自检不达标即 fail-closed。 这是所有软约束被绕过时的最后一道物理墙。 Q12：工具系统层的授权设计原则？ 默认拒绝 + 白名单：白名单优于必漏的黑名单。 细粒度权限 + 最小权限：只读/写/执行/网络分开授。 能力永不默认在线（never-ambient）：高危能力按”主体 + 本次运行”授予、用完回收，绝不是”谁都能用”。授权过大是多起 Agent 事故的共性。 按爆炸半径分风险层 + 渐进自治：Tier0 只读自动放行 / Tier1 非生产写受限 / Tier2+ 生产写强制审批。 工具描述校验：把 Skill/MCP/插件当供应链组件，pin 版本。 典型实践：高危动作（git 操作、发布、流水线）只走白名单通道，无裸 token、无旁路；只读放宽、副作用收窄到会话+仓库、删库/投产默认关。 Q13：MCP/插件供应链投毒怎么防？ 用一份 mcp-lockfile 固定供应链：记录每个已批准工具的 name + description + schema 哈希，进阶段前比对。一旦 MCP 服务端悄悄改了 description（诱导模型多传参、换语义），立即 fail-closed，把投毒挡在调用之前。 Q14：信息边界层的输入净化怎么做？ 不是”加一个检测器”，而是三条硬步骤叠加： L1 归一化：先把 Base64 / HTML entity / URL / Unicode escape 解码，剥掉零宽字符和 RTL 控制符，再交给后续层。否则”忽略之前的指令”可以藏在白色字体或编码里绕过。 L2 来源隔离：系统提示/开发者配置标可信指令（如 [SYSTEM_PROMPT]）；用户消息、工具返回、检索结果、外部数据标不可信数据（如 [TOOL_RESPONSE]），禁止二者裸拼接，逼模型按来源判断优先级。 L3 检测分级：规则引擎拦已知模板 + 判别模型拦变异样本，按风险分级处置（低放行 / 中二次确认 / 高拦截），不是命中即一律拦。 Q15：知识库为什么也是高危输入面？怎么治？ 知识库常被当”可信内参”直接喂给模型，但它的条目可能被人为投毒、或沉淀了错误/过期口径，命中检索后会顺着上下文放大。 两道防线： 检索时：检索结果同样是外部输入，先净化再入上下文——标 untrusted、作为”参考证据”而非”指令”，口径以澄清结论为准、与权威源交叉核验。 更前置——入库前审核：关口从”检索时净化”左移到”入库前审核”，尤其团队级知识库（多人可写、影响面大），要求来源可追溯、准入评审（正确性/时效性/敏感信息）、版本与过期下线机制。 Q16：I/O 双向脱敏具体指什么？ 输入侧：进上下文前扫密钥/token/密码、银行卡号、身份证手机号、连接串并掩码（卡号保留后四位 ************1234、密钥整段替换为 [REDACTED]）。 输出侧：日志、审计、企微/邮件通知、工件、工具参数回显、知识沉淀落盘前同样过脱敏闸门。 脱敏必须固化为规则或脚本（掩码、截断、哈希），缺省拒绝明文落盘或外发——不能指望模型”别把密钥写出来”。 Q17：最小知识原则是什么？角色隔离如何天然实现它？ 只给完成当前任务所需的最小信息，降低泄露面和被注入面。 角色隔离天然实现最小知识：subagent 只拿本阶段工件（如 proposal.md、design.md），看不到全量历史。隔离粒度按”利益冲突 / 信任边界 / 上下文健康”三个信号触发。

四、事中 · 控 Q18：执行编排层杠杆最高的控制点是什么？ pre-dispatch 决策点：工具执行前过一道确定性校验，输出三种结果——允许 / 拒绝 / 交人审批。这是杠杆最高的单一控制；据业界经验，pre-dispatch + 审批两项合计大约覆盖 60% 实用攻击面（非实测值）。受监管场景倾向放在进程外做独立审计。 Q19：授权为什么要”按声明”而不是”按推断”？ 主闸门是声明式白名单：每个阶段 subagent 声明一张 allowed_tools 清单（如 CODING 阶段只声明”读写工作区 + 编译”，不含 MR/投产）。超出声明即 denied。 靠系统推断意图不可靠；“动作合理性验证”只是补充层，用来拦声明内但明显偏离任务的调用。 举例：编码 Agent 被注入诱导去发 MR，而 MR 不在声明清单内 → 直接 denied，根本不需要判断”这个 MR 合不合理”。 Q20：什么是动态降级？ 风险累积时自动降级（收权到只读）或拦截。例如：检测到重复需求 → 红卡拦停；CodeCC 得分 89 < 基线 93 → 转受限修复循环；成本包络触顶 → 收回自动权交人工。 补充一层是输出行为兜底：动作落地前先识别”模型想调用什么”（发邮件/外发数据/改权限/写文件），按行为风险分级——低放行、中二次确认、高直接拦截。即使注入绕过了输入侧检测，高危行为仍在执行点被掐断。 Q21：什么是成本包络（Cost Envelope）？为什么修复循环上限取 3？ 给每一类循环装天花板，触顶就喊停，防 Doom Loop。 修复轮数遵循衰减收益曲线：前几轮解决绝大多数问题，越往后边际收益越低、越修越乱的概率越高，所以统一上限取 3。触顶后不硬闯，自动暂停发 🟡 卡，把”继续/改方向/终止”交回人；检测到循环也不直接 kill，而是先注入反思给自纠机会。 实践中 REVIEW 第二轮就过（2/3）、CR 也未触顶——说明包络是安全网而非常态。 Q22：HITL 三色卡是怎么分级的？为什么不能什么都问？ Overwhelming HITL：什么都问 = 审批疲劳 = 等于没有 HITL。所以按”置信度 × 破坏力/阻塞性”分级，只在真正需要拍板处停： 🔴 红卡 · 必须人确认：force push、删库、投产等不可逆动作，以及阻塞性必填项——人不点头卡住不执行。 🟡 黄卡 · 需人决策：成本包络触顶、评审分歧、模型降级 → 暂停，让人选择继续/改向/终止。 🟢 绿卡 · 自动流转：阶段间常规交接自动推进，不打扰人，记录进 records.json。 本质是把”人卡在哪个环节”做成可插拔的 pre-execute 钩子，三色卡只是按破坏力细化成三档。 Q23：哨兵（Trip Wire）和兜底熔断有什么区别？ 哨兵吹哨而非直接 kill：独立盯着异常，偏离正常区间就报警，遵循”记录 → 提醒 → 暂停”的渐进部署；同一主体重复违规达阈值才处置，避免误杀。 兜底熔断是全局止损：单任务触高危阈值、或单位时间违规超阈时，直接转人工 / 冻结工具权限——宁可任务中断，也不让失控扩散。它是哨兵之上的全局兜底，贯穿全程。 案例：哨兵吹过两次哨——需求重复（事件吹出来，开工裁决由事前去重闸门做）、质量红线拦截（89 < 93 → 转修复循环）。 Q24：状态纠偏与回滚解决什么问题？ 对 Agent 的中间状态、记忆、检查点持续打快照，一旦检测到污染（记忆里写进错误结论、被注入偏离指令），及时回滚到最近安全检查点，防止污染顺着流水线放大。 工程上每步状态落 records.json（阶段、子步骤、迭代次数、每个 detail 含来源与时间戳），带来三个能力： 可中断续做：中断后从 active.json 指针恢复，不用从头跑； 带来源回档：精准定位”从哪一步、因为什么打回”； 状态纠偏回滚：污染时干净退回安全点。 金句：Agent 时代的核心运维能力不是”高可用”，而是”可中断”——不只是停得下来，还能干净地退回去。

五、事后 · 兜 Q25：硬门禁和软门禁分别拦什么？ 硬门禁拦”确定错的”：质量门 + 安全门，可程序化裁决。 软门禁捕”可能差的”：逻辑合理但方案次优，靠独立视角交叉验收。 Q26：质量门和安全门有什么区别？ 质量门 = 连续指标、可分级（逐步逼近目标）。实践中设两档：退化基线 93 保命卡住，准入门槛 100 才放行。 安全门 = 二元事件、必须 fail-safe（命中即拦）。如 gitleaks/trivy 扫密钥和漏洞，命中即 fail。 准入条件 AND，缺一不可：实践中是 self_check.fail==0 ∧ CodeCC==100 ∧ CR resolved 三真才进 MERGE。三条件分别对应模型自检、外部检查、自定义规则三个维度。 Q27：什么叫”可程序化验证”？为什么 AI 无法可靠遵守数字阈值？ AI 无法可靠遵守数字阈值——写到第 49 行它不会主动停，因为它不会数行数。所以每道闸门都要落成 CI 里能跑、能 exit 的脚本： 软约束（Agent Skill / 注入 rules）让代码先天合规； 硬约束（CI lint / 扫描）做最后兜底。 门禁尽量看骗不过的客观信号：CodeCC 真实评分、build 状态、测试流水线 SUCCEED（check: command），而不是”文件存不存在”（check: exists）。 Q28：哪些参数必须程序化强校验？举个反面案例。 判据：只要一个动作”参数写错就会造成不可逆或大范围影响”，它的合法性就必须由确定性代码把关，而非模型意图。 反面案例：投产时发企微通知，若不强校验推送目标，AI 漏传/误解 target 为空，底层接口可能默认群发，把内部发布通知推给全员甚至外部群。 正确做法：发送前加程序化闸门——assert target ∈ 已登记白名单 && target ≠ 空 && 非”@all”，缺参直接 exit 拒发，绝不”缺省即广播”。 同类高危默认值：删除未带 where 条件、批量操作未设 limit、灰度未指定范围即全量。 Q29：什么是策略即代码（Policy-as-code）？ 门禁脚本本身也是资产，同样会腐化。做法是把安全策略当软件契约——为每条策略写单测并纳入 CI 回归，确保提示词更新或模型迁移不会引入安全回归（比如换模型后某道注入防护失效）。 它和 Dry Run 是同一逻辑的两种形态：Dry Run 用虚拟需求跑全流程测流程，Policy-as-code 用单测为每道闸门上锁——让护栏本身也处于持续验证中。 Q30：软门禁的四个机制是什么？ 角色隔离：执行 ≠ 验收、运动员 ≠ 裁判； 明确 rubric：给验收 Agent 结构化清单，独立审只出问题清单、不自由评； 跨模型交叉验证：开箱即用的模型是糟糕审查者，靠机制（rubric + 阈值卡 + 多验）而非 prompt 空喊； 非对称权重：重罚漏判、轻罚误判——“宁可误杀不可放过”，对齐安全优先。 实践：独立 subagent 按 rubric 评审，首轮报 2 Critical / 6 Major，带着具体问题精确回退到责任阶段。 Q31：全链路审计要注意什么？ 记录完整执行轨迹（Prompt、工具调用、参数、权限校验结果），回答”发生了什么”，支持事后审计、攻击溯源、异常行为分析，但它本身不自动改护栏。 两个要点： 审计链也是输出面，落盘前必须脱敏，否则”可追溯”变成密钥/卡号的二次泄露； 工程上 records.json 记全产物与来源，可一路追溯 需求→设计→编码→MR→发布→归档；错误写 errors/ledger.jsonl；每次拦截、每步耗时上过程指标看板。 Q32：自迭代怎么闭环？只复盘不改闸门行不行？ 不行——只复盘、不改闸门，等于没有迭代。依赖两路输入，缺一不可： 观测：审计链、过程指标、Trip Wire 哨兵、护栏触发记录（拦了几次、卡在哪、花多久）； 评测：门禁客观信号（CodeCC/安全扫描/测试断言）、Dry Run/回归结果、人工确认过的 badcase（该不该拦、拦得对不对、阈值松紧）。 沉淀的不是全文复盘，而是可执行的 Harness 资产： 安全规约：新规则进 rules/、收窄 allowed_tools、补脱敏/归一化/参数白名单； 门禁调整：升降阈值、加断言（如 TOTAL>0）、改 AND 条件、补回退映射或成本包络上限。 实践：流程结束写回 lessons/.md，下次同类需求自动注入。真实案例：测试零用例假绿 → 门禁补 TOTAL>0。

六、研发流水线场景题（10 阶段） Q33：完整说一下这条流水线的 10 个阶段，以及每阶段的关键护栏？

阶段 场景与关键护栏 ① INTAKE 需求接入 外部来源默认 untrusted；先 I/O 脱敏（密钥 [REDACTED]、卡号留后四位），再过业务去重闸门，高度重复 → 🔴 红卡拦停 ② CLARIFICATION 技术澄清 PM subagent 把需求拆成 🔴7/🟡9/🟢4 共 20 个结构化问题，单轮 ≤5、按优先级分批；rules 注册表自动注入本阶段规则 ③ DESIGN 方案设计 架构师 subagent，最小知识——只拿澄清工件、看不到全量历史 ④ REVIEW 方案评审 裁判 subagent（利益冲突必换，prompt 首句强制”你没写过这段”）；首轮 2C/6M FAIL → 精确回退 ③，第 2 轮通过（2/3 未触顶） ⑤ CODING 编码 L1 归一化 + L2 标 untrusted 防间接注入；按声明授权（无 MR/投产权限）；CodeCC 退化 89<93 → 哨兵吹哨、转受限修复；快照 + 成本包络 ⑥ CODE-REVIEW 代码评审 独立 CR subagent；用户选择回退 ⑤ 再迭代 → 🟡 决策卡（人主动改向，非触顶） ⑦ ADMISSION 门禁检查 准入三条件 AND；质量门两档（89 修到 100）；安全门 gitleaks/trivy 命中即 fail；门禁脚本有单测 ⑧ TEST 测试验证 TOTAL>0 断言堵死”0/0 判绿”，必须有真实用例、真实断言 ⑨ MERGE 合入主干 5 条件全绿（可合并 ∧ approve ∧ 无未闭评论 ∧ CI 全绿 ∧ TAPD 关联）；只能走 Git 操作 MCP 白名单通道，无裸 git 远端 ⑩ RELEASE 投产发布 🔴 红卡强制人工确认，只经受控发布工具；通知 target 缺省即拒发；输出脱敏；全链留档；沉淀 lessons 自迭代闭合

Q34：规则注入是什么？它和硬约束什么关系？ 规则不能只是一份文档、指望 AI 自觉看。用 rules/ 注册表声明”哪条规则在哪个阶段生效”，进阶段时自动拼进系统提示（如 go 编码规范、CR checklist、自检规则、成本包络规则）。 定位要清楚：规则注入是软约束，提高先天合规率，但 Agent 仍可能无视；真正兜底的是沙箱、白名单通道和 CI lint/门禁脚本。 Q35：Subagent 是不是每个阶段都必须换新的？（高频误区题） 不是。换 subagent 买到”破自我确认偏差 + 上下文隔离”，但也有代价：新 agent 要重读工件重建理解、交接可能失真、对强连续的相邻子步是负优化。 三个信号触发隔离： 利益冲突（运动员 vs 裁判）：存在”生成 ↔ 评审”关系的必须换——DESIGN↔REVIEW、CODING↔CODE_REVIEW。这是最硬的一条；CR subagent prompt 首句强制”你没有写过这段代码”。 信任边界：跨信任边界、引入 untrusted 外部输入后换——如接入外部需求、消费第三方 MCP 返回之后。 上下文健康：上下文将超载或疑似被污染时换——长阶段末尾、注入疑似发生后做”上下文卫生”重置。 强连续、同一心智、上下文可控的相邻子步可以复用同一 subagent（如”详设→任务拆解”、同一 bug 的多轮修复），用”工件 + 结构化摘要”压缩交接。再叠 triage 分级：standard 需求严格隔离，quick 需求合并阶段、复用 subagent。 一句话：评审必换、边界必换、上下文脏了就换；其余能连续就连续。 Q36：失败后的精确回退路径是怎么设计的？ 失败不是”从头再来”，而是回退到最近的责任阶段： 评审 FAIL → 回 ③ 设计； CR / 编译 / CodeCC 问题 → 回 ⑤ 编码； 0/0 假绿、测试问题 → 回 ⑧ 测试； 需求不符 → 回 ② 澄清。 迭代上限与成本包络同一套：各类循环 ≤3，触顶发 🟡 卡交人，不另设”编码/测试评审 ≤2”。 Q37：Dry Run 是什么？排过哪些典型雷？ Dry Run（空跑/试运行）：不触发真实副作用（不真正合入、不投产、不发通知、不写生产库），用一份虚拟需求把流程完整走一遍，验证编排逻辑、门禁脚本、产物流转是否正确——相当于流水线”带电前的通电自检”，验证对象是 Harness 本身而非业务代码。 排到的典型雷： 门禁零用例假绿：用例数为 0 时 CI 仍判通过 → 补 TOTAL>0 断言； 产物”存在即通过”：只校验报告文件存在、不看内容，空报告也放行 → 改看客观信号（真实评分/构建状态，check: command 而非 check: exists）； 失败无回退落点：出错不知退回哪一阶段 → 建”失败信号 → 最近责任阶段”映射。 这些缺陷的修法都是修 Harness（补断言、改门禁判据、强制状态落盘、建回退映射），若到真实需求才暴露，每一个都可能导致严重返工。

七、开放设计题 Q38：让你从零给一个能写代码、能发版的 Agent 设计安全护栏，你怎么设计？ 按事前/事中/事后三层回答： 事前（锁攻击面，由外到内）： 系统隔离：OS 级沙箱（CDE 一人一盒子、限定工作区、受控出口），凭证不落主机、短时 token 按调用注入，doctor fail-closed； 工具系统：默认拒绝 + 白名单，细粒度最小权限，never-ambient 高危授权用完回收，Tier0/1/2 风险分层，MCP 用 lockfile 锁哈希； 信息边界：输入过 L1 归一化 / L2 来源隔离 / L3 检测分级，知识库先审后入，I/O 双向脱敏，最小知识 + subagent 角色隔离。 事中（掐断跑偏）： pre-dispatch 决策点，按声明授权（allowed_tools 白名单），动作合理性验证做补充； 成本包络循环 ≤3，触顶发黄卡交人；HITL 三色卡按破坏力分级； 哨兵渐进吹哨 + 全局熔断冻结权限；动态降级收权； 每步落 records.json 快照，可中断、可回滚。 事后（裁决与沉淀）： 硬门禁（质量门分级 + 安全门二元 fail-safe + 准入 AND），软门禁（角色隔离 + rubric + 跨模型交叉 + 非对称权重）； 有副作用的参数全部程序化强校验，策略即代码进 CI； 全链路审计（落盘前脱敏），观测 + 评测驱动自迭代（改 rules、调门禁、补断言）； 上线前先 Dry Run 空跑，验证 Harness 本身。 Q39：10 条可迁移的工程原则，能收一下吗？ 边界设在模型改不动的地方：先给盒子锁死爆炸半径，再谈信任。 永不信任，持续验证：纵深分层，静态规则只降概率，运行时校验才兜底。 按声明授权，别猜意图：声明式白名单超出即 denied；能力 never-ambient、用完回收。 外部输入默认不可信：一律过 L1–L3；知识库先审后入；I/O 双向脱敏；trusted/untrusted 分槽禁止裸拼接。 每个循环设天花板 + 全局熔断：触顶交人防 Doom Loop，聚合超阈冻结权限。 按破坏力分级拦人：红卡拦不可逆与阻塞必填、黄卡拦分歧/触顶、绿卡自动流转，避免审批疲劳。 写和评拆开：利益冲突、跨信任边界、上下文脏了就换 subagent；其余能连续就连续。 失败回到最近责任阶段：哨兵吹哨而非直接 kill；状态可中断、可恢复、可回滚。 质量可分级，安全必二元，硬软门禁互补：放行看骗不过的客观信号；准入 AND；副作用参数程序化校验、缺省即拒。 把 Harness 当一等治理对象：软约束提合规率、硬约束兜底；上线前 Dry Run 验流水线；自迭代靠观测+评测；换模型连 Harness 一起重评。 收尾金句：提示词注入短期消不掉，检测器会过时；但执行点上的声明式拒绝和行为兜底不会。

八、名词解释速记卡 术语 一句话解释 Harness 连接模型、工具、执行环境的工程层，Agent 的手脚与安全边界 IPI / DPI 间接注入（藏在外部内容里）/ 直接注入（用户输入框） 越狱 攻击模型自身对齐，与注入不在同一层 Defense in Depth 纵深防御，层层设卡、不依赖单层自闭环 fail-closed 自检/校验不通过时默认拒绝、停止放行 never-ambient 高危能力不默认在线，按主体+按次授予、用完回收 Tier 分层 按爆炸半径分级：只读自动 / 非生产写受限 / 生产写审批 L1/L2/L3 归一化 / 来源隔离 / 检测分级 pre-dispatch 工具执行前的确定性决策点（允许/拒绝/交人） Cost Envelope 成本包络，每类循环设上限（≤3），防 Doom Loop Doom Loop 失控循环，在同一错误上反复打转烧光预算 三色卡 🔴 必确认 / 🟡 需决策 / 🟢 自动流转 Trip Wire 哨兵，记录→提醒→暂停，渐进吹哨 兜底熔断 全局止损，超阈转人工/冻结权限 硬门禁/软门禁 拦”确定错的”（脚本裁决）/ 捕”可能差的”（交叉评审） 质量门/安全门 连续可分级指标 / 二元 fail-safe 事件 Policy-as-code 策略写成脚本并配单测进 CI，防护栏自身腐化 rubric 验收 Agent 的结构化评分清单，只出问题不自由评 非对称权重 重罚漏判、轻罚误判，安全优先 records.json 每步落盘的状态/产物/来源记录，支撑续做与回档 Dry Run 虚拟需求空跑全流程，验证 Harness 本身 最小知识 只给当前任务所需最少信息 自迭代 观测+评测沉淀为 rules 与门禁调整，闭环改进