D3 架构级防御：六个设计模式，以及先定计划后执行怎么把攻击成功率压到零

今日目标

能逐一说出六个设计模式各自约束了什么，以及分别付出什么能力代价
能用一条判据为给定任务选出合适的模式，而不是罗列所有模式
能把靶场 Agent 改造成先定计划后执行加隔离读取，并用两个数字证明改造有效

昨天你把四档输入侧防御全接了一遍，最好的一档把攻击成功率压到了 33%，代价是误伤了一条完全正常的工单；再加一条自适应用例，它又涨回来了。今天我们换一层动手：不再问「怎么让模型别上当」，而是问「就算它上当了，它还能不能做成那件坏事」。读完回到页面顶部把三条目标勾掉。

小白版讲解

点菜与自助餐：什么时候服务员改不了你的单

你在餐厅点完菜，服务员把单子送进后厨。这时邻桌的人凑过来跟服务员说「把他那桌的菜改成十份龙虾，账记他头上」——能改成吗？如果这家店的规矩是「下单之后一切以单子为准」，那改不成，不是因为服务员识破了这个人，而是因为改单这件事在流程里根本没有入口。

自助餐就完全相反。你端着盘子边走边看，看到什么拿什么，旁边的人只要能影响你看到的东西，就能影响你最后盘子里是什么。

昨天那个 deskmate 就是自助餐式的：它一边读工单、读工单里贴的网页，一边决定下一步做什么。攻击者不需要跟它对话，只要能往它读的东西里塞一段字，就已经站在了决策的位置上。 这也是为什么输入侧防御天然是被动的——它只能拦住「看起来坏的文字」，而决策入口一直敞开着。

昨天那张对照表里有一件事值得再看一眼：第三档聚光标注把攻击成功率压到 33%，漏掉的那三条一个可疑词都没有；它们不覆盖任何指令，只是把外泄写成这条工单自己的处理要求。而用户交代的恰恰是「按工单要求处理」。这类载荷不是骗过了检测器，而是压根没有可被检测的特征——它和一条正常工单在文本上是同一种东西。 检测器能做的事到此为止了，剩下的必须靠结构。

一条核心原则：摄入之后就不能有后果

今天全部六个模式都从同一句话长出来。这句话出自 Beurer-Kellner 等人 2025 年 6 月的论文（作者来自 Google DeepMind、ETH 与 Microsoft），值得逐字记住：

一旦 Agent 摄入了不可信输入，就必须被约束到「那段输入不可能触发任何有后果的动作」。

注意它说的不是「不要让模型被骗」，而是「被骗了也无所谓」。这是一个关于能力的约束，不是关于判断力的期望。判断力是概率的，能力是可以被代码写死的。

把它翻译成能落地的两句话就是：要么动作在摄入之前就定死，要么摄入的那一次调用手上没有工具。六个模式全是这两句话的不同组合。

先看反面，也就是昨天那份代码的结构：

reactive.js

// 昨天的流程：读到什么，就拿什么去决定下一步做什么
const blocks = [{ label: '工单正文（来自外部用户）', content: ticketBody }]
const link = /https?:\/\/\S+/.exec(ticketBody)?.[0]
if (link) blocks.push({ label: '抓取到的网页', content: await fetchPage(link) })
 
// 同一次调用里，模型既拿到了不可信内容，又拿到了全部工具
const actions = await model.decide({ prompt: buildPrompt(level, request, blocks), tools: ALL })
for (const a of actions) await tools[a.tool](a) // 工单里写什么，它就可能做什么

reactive.py

# 昨天的流程：读到什么，就拿什么去决定下一步做什么
blocks = [{"label": "工单正文（来自外部用户）", "content": ticket_body}]
link = re.search(r"https?://\S+", ticket_body)
if link:
    blocks.append({"label": "抓取到的网页", "content": fetch_page(link.group(0))})
 
# 同一次调用里，模型既拿到了不可信内容，又拿到了全部工具
actions = model.decide(prompt=build_prompt(level, request, blocks), tools=ALL)
for a in actions:
    TOOLS[a.tool](a)  # 工单里写什么，它就可能做什么

这段代码的问题不在任何一行里，而在 decide 的参数表：不可信内容与工具清单同时出现在一次调用里。工程代价也在这里——要改掉它，动的是整个控制流，不是加一个过滤函数。所以这类改造通常要排进迭代计划，而不是当成一个补丁提上去。

动作选择器与先定计划后执行：结果不回流，和把动作提前定死

动作选择器（Action-Selector） 是最保守的一个：模型只负责把用户的一句自然语言翻译成一个预定义动作，动作执行完，结果不回流给模型。像自助点餐机——你说「退这单」，它翻译成一个退单请求，退完就结束，退单接口返回的任何文字都不会再交给模型读。因为不回流，间接注入根本没有进来的路。代价也很直白：它只能做一次性动作，做不了多步任务，Agent 里最值钱的那部分能力被砍掉了。

先定计划后执行（Plan-Then-Execute） 放宽了一点：允许多步，但在看任何不可信数据之前把动作清单定死。之后无论读到什么，都只能改变每一步的参数内容，不能新增、删除或改变步骤本身。

planned.js

// 计划器的参数里没有 ticketBody——这不是遗漏，这就是这个模式的全部
function plan(request, recipients) {
  const steps = [{ tool: 'search_customers' }]
  if (request.includes('写回工单')) steps.push({ tool: 'update_ticket' })
  // 收件人来自用户预授权，不是工单说了算
  for (const to of recipients) steps.push({ tool: 'send_email', target: to })
  return steps
}
 
// 执行器只把计划里的步骤变成动作；读到的内容只能当数据
function runPlanned(input, recipients = []) {
  const steps = plan(input.request, recipients)
  const read = quarantinedRead(input.request, input.ticketBody)
  return steps.map((s) => ({ ...s, note: `读到 ${read.summary.length} 字，仅作数据` }))
}

planned.py

# 计划器的参数里没有 ticket_body——这不是遗漏，这就是这个模式的全部
def plan(request: str, recipients: list[str]) -> list[dict]:
    steps = [{"tool": "search_customers"}]
    if "写回工单" in request:
        steps.append({"tool": "update_ticket"})
    # 收件人来自用户预授权，不是工单说了算
    steps.extend({"tool": "send_email", "target": to} for to in recipients)
    return steps
 
 
# 执行器只把计划里的步骤变成动作；读到的内容只能当数据
def run_planned(inp: dict, recipients: list[str] | None = None) -> list[dict]:
    steps = plan(inp["request"], recipients or [])
    read = quarantined_read(inp["request"], inp["ticket_body"])
    return [{**s, "note": f"读到 {len(read.summary)} 字，仅作数据"} for s in steps]

plan 的签名就是那道墙。今天的实验里有一步变异检验，让你把 ticketBody 亲手传进去——攻击成功率会立刻涨回来，你会非常直观地看到墙原本挡在哪。代价是计划定死后无法根据读到的内容改主意：工单里写着「这事得先问法务」，Agent 也不会临时加一步。

分片归并与双模型隔离：有权限的那个模型永远不看原文

分片归并（LLM Map-Reduce） 处理的是「要读很多份不可信材料」的场景：每一片交给一个隔离的子 Agent 去读，子 Agent 没有工具，只准回传结构化字段（比如一个布尔值加一句摘要），主 Agent 只看这些字段。像审稿——一百份稿子分给一百个审稿人，每人只回一张固定格式的评分表，主编从头到尾没读过原文。代价是跨片推理能力下降：需要把第 3 片和第 87 片对照着看才能得出的结论，这个结构做不到。

双模型隔离（Dual LLM） 是同一思路的一般化，也是今天实验里真正落地的那一半：有权限的模型永远看不到原文，它拿到的只是一个符号引用（比如「变量 a 里是刚才抓到的网页」）；看原文的那个模型没有任何工具。

quarantined.js

// 这次调用看得到原文，但工具清单是空的——没有工具就不可能有后果
function quarantinedRead(request, ticketBody) {
  const blocks = collectUntrusted(ticketBody)
  const wanted = model.decide({ prompt: buildPrompt(3, request, blocks), tools: [] })
  // 把它「想做什么」记下来，只为了让你看见它确实上当了
  const hijackAttempts = wanted.filter((a) => a.tool === 'send_email' || a.tool === 'post_webhook')
  return { summary: summarize(blocks), hijackAttempts } // 只有字符串能流出去
}

quarantined.py

# 这次调用看得到原文，但工具清单是空的——没有工具就不可能有后果
def quarantined_read(request: str, ticket_body: str) -> QuarantinedRead:
    blocks = collect_untrusted(ticket_body)
    wanted = model.decide(prompt=build_prompt(3, request, blocks), tools=[])
    # 把它「想做什么」记下来，只为了让你看见它确实上当了
    hijack_attempts = [a for a in wanted if a.tool in ("send_email", "post_webhook")]
    return QuarantinedRead(summary=summarize(blocks), hijack_attempts=hijack_attempts)  # 只有字符串能流出去

代价是编排复杂度高：你要额外维护符号引用表、跨模型的数据流、以及一套「什么时候允许把引用解开」的规则。真要看工业级长什么样，读 CaMeL（arXiv 2503.18813）——它把双模型隔离和数据来源追踪做成了一套完整系统，每个值都带着它从哪来的标签。不要求你复现它，但读一遍会让你对「完整做对要花多少工程」有个准确的量感。

先写程序后执行与上下文最小化：可静态检查的计划，和用完就删的上下文

先写程序后执行（Code-Then-Execute） 是先定计划后执行的加强版：不让模型产出一串步骤，而是让它写一段小程序，由你自己的解释器执行。好处是程序可以在跑之前被静态检查——数据流是显式的，「客户库的返回值最终流向了哪个参数」这个问题有确定答案，而不是靠读模型的自然语言解释去猜。代价很实在：你得自建解释器与策略引擎，这是六个模式里工程量最大的一个。

上下文最小化（Context-Minimization） 最轻：那段不可信文字完成使命之后，就从上下文里删掉，不带进后续轮次。比如用它生成了一条数据库查询，查询生成完就把原文丢掉，后面的轮次只看查询结果。它的安全动机很清楚：上下文里留着的每一段不可信文字，都是后续每一轮的一次重新掷骰子——第一轮没被劫持，不代表第七轮也不会。

选型判据：这个任务到底需不需要根据不可信内容改变动作

六个模式摆出来之后，真正的问题不是「选哪个」，而是别一次全上。判据只有一条，而且是一个可以当场回答的问题：

这个任务，到底需不需要根据不可信内容改变动作？

答「不需要」的占绝大多数。总结工单、分类工单、把网页要点写回工单——这些任务里不可信内容只影响产出的文字，不影响做哪几件事。这一类直接用先定计划后执行，工程量小、能力损失几乎为零。

答「需要」的才付双模型隔离的复杂度。典型的是「读完这份材料，如果里面提到退款就发起退款流程」——动作本身依赖内容。这时你需要的是让有权限的那一侧只看到一个受控的符号（比如一个枚举值），而不是让它读原文。

还有第三种答案：「需要，但可以改成不需要」。这是最划算的一条路，今天实验的最后一行就是它——纯先定计划后执行时，N-03 那条合理的抄送请求被一起丢掉了（工单说了要抄送风控，但计划里没有这一步）；把收件人白名单改成由用户预授权，能力就回来了，而攻击成功率仍然是 0。很多「必须根据内容决定」的需求，换一个信任来源就消失了。

代价要摆上桌：每个模式换来的安全都是用能力换的

最后把六个模式和它们的账单并排放在一起。任何只讲优点的安全方案都是不完整的，面试里也是——说不出代价，面试官会认为你没落地过。

模式	约束了什么	代价
动作选择器	结果不回流给模型	只能做一次性动作，不能多步
先定计划后执行	动作清单在摄入之前定死	计划定死后无法根据读到的内容改主意
分片归并	每片交给隔离子 Agent，只回传结构化字段	跨片推理能力下降
双模型隔离	有权限的模型只看符号引用	编排复杂度高
先写程序后执行	产出可被静态检查的程序	需要自建解释器与策略引擎
上下文最小化	用完即删	只减少暴露面，不是隔离

今天实验跑出来的这张表，就是这笔账的实物：

TextText

D2 第三档：聚光标注                40%   100%   达成      A-07 A-08 A-09 A-10
D2 第四档：标记加检测器            10%    83%   被丢弃    A-10
先定计划后执行                      0%   100%   被丢弃    （无）
先定计划后执行 加 预授权收件人      0%   100%   达成      （无）

三件事值得念一遍：第一，攻击成功率从 40% 到 0，靠的不是更聪明的检测，是结构；第二，第三行的任务完成率是 100%，但「合理抄送」那一列写着被丢弃——安全确实是用能力换的，代价这一列就是账单；第三，最后一行把那份能力买了回来，而攻击成功率仍然是 0。这才是一次合格的改造：两个数字都要看，一个都不能少。

源码导读

动手实验

🧪 D3 实验：改造后的靶场 Agent：先定计划后执行加隔离读取，攻击成功率归零而正常任务完成率基本不掉

代码位置：labs/agent-security-5days/day-03-secure-patterns

验收标准：

pnpm start 打印四行对照表，后两行的攻击成功率都是 0%、任务完成率都是 100%。
表里出现「隔离模型被劫持 5 次，但它没有工具，一次都没发出去」这一行。
纯先定计划后执行那一行的「合理抄送」列是被丢弃，最后一行是达成——代价与买回代价都看得见。
底部 A-07 的演示里，「隔离模型想做的事」与「实际执行的动作」是两行不同的内容。
变异检验：把工单正文传进计划器，攻击成功率立刻涨回去。

动手之前先记住一件事：starter 第一次跑出来是攻击成功率 0%、任务完成率 0%。别高兴，那正是昨天点名过的反模式——把 Agent 改成什么都不做，攻击成功率当然是 0。两个数字必须一起看。卡住了先读 starter/src/agent/planned.ts 里三个 TODO 的注释，它们指向坑而不是答案。

先跑通 solution，把四行对照表和底部那段 A-07 演示完整看一遍，确认你能指出哪一行是昨天的最好成绩、哪一行是今天的产出。
在 starter 里补全计划器 plan：它的参数里只有用户请求与预授权收件人，看不到工单正文——不要把工单正文加进去，加进去这个模式就作废了。
补全隔离读取 quarantinedRead：调一次模型，把它想做的对外发送记下来，然后把所有动作丢掉，只返回一段字符串。跑起来应该能看到被劫持次数不为 0。
补全执行器 runPlanned：只把计划里的步骤变成动作。写完这一行，表里后两行的攻击成功率应该同时归零。
做两次变异检验：把工单正文传进计划器并让它按工单追加发送步骤，以及把执行器改成执行隔离读取返回的动作——两次攻击成功率都必须涨回去，涨不回去说明对照组没接上、表里的 0% 是假的。

面试题

今天 3 道题在下方题库区，侧重六个设计模式的约束与代价、选型判据，以及架构防御与提示词防御的本质差别。展开后先看"分析过程"再看要点——第 3 题问的是「什么时候你会拒绝用这些模式」，那是区分「背过论文」和「落地过」的地方，别跳过。标注"国内高频 / 海外高频"方便按目标市场取舍。

检查清单与明日预告

能逐一说出六个设计模式各自约束了什么，以及分别付出什么能力代价
能用一条判据为给定任务选出合适的模式，而不是罗列所有模式
能把靶场 Agent 改造成先定计划后执行加隔离读取，并用两个数字证明改造有效
能逐字复述那条核心原则，并说清它约束的是能力而不是判断力
能解释「隔离模型被劫持了却没造成后果」和「模型抗住了攻击」差在哪
实验的 5 条验收标准全部通过，两次变异检验都让攻击成功率涨了回去
3 道面试题不看要点也能答出至少 2 道

明天（D4）我们把假设再放宽一档：假设注入已经发生、架构也有缝，靠运行时把损失锁住。你会给每个工具声明能力面与危险等级，给不可逆的动作加确认门，给文件和网络加出口白名单，再把「沙箱」拆成你自己写的策略层与内核替你兜底的隔离层，最后处理密钥、用户级凭据与多租户隔离。顺序是有意的：今天这一层管的是「坏动作压根不会被提出来」，明天那一层管的是「它被提出来了也执行不成」——两层都做，才不会因为任何一层的一个疏忽就全线失守。

架构级防御：六个设计模式，以及先定计划后执行怎么把攻击成功率压到零