base02 · 沙箱与凭证隔离 · 分治：上下文压缩的算法原理

来源：xueai.miyang.cn（小山学堂 · 洛小山《学 AI 产品，从入门到精通》）

本内容改编自小山学堂《学 AI 产品，从入门到精通》，为二次演绎配音版

---

本集定位

本集是技术侧（S2）工程师补课模块 T1 的第二集，覆盖两件看似无关、实则同构的事：

1. Agent 安全架构：凭证与执行环境如何结构性隔离；
2. 上下文压缩 Compaction 的算法原理：它其实就是分治（Divide and Conquer）。

把它们放在一集里讲，是因为两者的底层动作完全一致——承认单点扛不住，然后用结构去分解压力。

本集取材自 6 节课：沙箱与凭证隔离、二分查找、排序（冒泡 vs 快排）、Rerank、递归、分治与上下文压缩。

---

一、能力地图

读完本集，你应该能够：

能力	具体表现
识别危险架构	一眼看出「代码执行与密钥同容器」的结构性缺陷
设计凭证隔离	能说清「绑定到资源」与「Vault 代理」两种模式的差异与适用场景
布置隔离屏障	知道文件系统 / 网络 / 进程三层各自阻断的是什么
划分信任层级	能按 Tool / Session / Global 三层设计权限模型
估算算法代价	对 O(n²) 与 O(n·log n) 在数据规模放大时的差距有直觉
设计检索漏斗	能讲清粗排与精排为什么必须并存，以及代价分在哪一层
判定递归合格	用「同构、更小、有终止」三件套验收任何递归实现
实施上下文压缩	会做切分—各治—合并三步，并知道该保留哪些不压

---

二、安全架构：为什么提示词靠不住

2.1 旧架构的致命假设

传统做法是「一个容器装所有东西」：代码执行、API 密钥、OAuth Token、会话凭证全部共存于同一运行环境。

它隐含了一个假设——Agent 是善意的。而这个假设在提示词注入面前不堪一击：

攻击者 → 提示词注入 → 说服 Agent 执行 echo $API_KEY → 密钥全走

攻击链短到不需要任何提权技巧。更糟的是，模型越强，攻击面越大：更强的工具调用能力意味着更大的破坏半径。

2.2 核心命题

安全架构不能依赖模型自觉，必须通过结构性设计来保证：即使模型被完全控制，攻击者也拿不到凭证。

这句话是本集的锚点。它把安全从「行为约束」问题，转换成了「拓扑结构」问题。

---

三、两种凭证隔离模式

模式一：绑定到资源（Bound to Resource）

Token 在使用时被嵌入资源的访问路径，从不作为独立变量存在。

Git 克隆场景：

https://<token>@github.com/org/repo.git

• 沙箱内的 Agent 可正常 push / pull
• 但无法读取或提取 Token——它被嵌在 Git 配置深层，不是可枚举的环境变量
• 设计精髓：可用不可见

模式二：Vault 代理模式

Token 存于独立的 Vault 服务，Agent 每次调用都走代理转发。

Agent 发请求 → 代理按 Session ID 查 Vault → 注入 Token 到请求头 → 转发目标服务

• Agent 全程只知道「调用成功了」，从未见过 Token 的任何一个字符
• 即使把请求日志翻一遍，也翻不出凭证
• 适用于 MCP OAuth 一类的第三方授权场景

两种模式的共同点

都不是在教 Agent「别偷东西」，而是让 Agent 根本没有东西可偷。这就是结构性安全与提示词安全的根本分野。

提示1 · 可用不可见是可以直接写进评审表的检查项

下次做架构评审，把这一条加进去：「Agent 是否能在不持有凭证明文的前提下完成调用？」 如果答案是否，说明密钥仍在可被枚举的位置（环境变量、配置文件、挂载卷），这是一个必须修的缺陷，不是可以缓一缓的优化。

---

四、OS 级隔离的三重屏障

屏障	阻断什么	为什么单独一层不够
文件系统隔离	只能访问工作目录，宿主机其他路径不可见	拿不到凭证，但可能从别处拿到
网络隔离	无法向任意外部服务发送数据	关键补充：拿得到 ≠ 外传得了
进程隔离	独立进程空间，读不到其他进程内存，发不了信号	防止横向移动到宿主机其他服务

三层必须叠加。只做文件系统隔离，攻击者仍可能通过内存或进程间通信拿到东西；只做网络隔离，凭证本身还是暴露的。

---

五、三层信任层级

TOOL    工具级信任   → 管单次操作（删文件 / 写库 / 发邮件需人工审批；只读自动放行）
SESSION 会话级信任   → 管一段时间（可读写 /src，不可改 /config；会话结束自动回收）
GLOBAL  全局级策略   → 管永远（永不访问生产库、永不向外部域名发请求）

逻辑非常清晰：工具层管一次，会话层管一段，全局层管永远。

三层缺一层，就有一层没人兜底。实践中常见的问题是只做 Tool 层（每次都弹窗问用户），既累又不可靠——用户点快了就全放行了。

提示2 · 先把全局红线写死，再谈用户授权

很多团队的权限模型是「用户说了算」，这在 Agent 场景下非常危险，因为用户自己也可能被提示词注入的输出误导。顺序应该是反过来的：先由组织写死全局策略（无论会话里授予什么都不可违反），再在其下开放会话级与工具级授权。全局层是兜底防线，不是可选项。

---

六、算法侧：从二分到排序

6.1 二分查找给的是「最坏情况的保证」

• 100 个候选 → 最多 7 次
• 10 亿条数据 → 最多约 30 次
• 数据量翻一万倍，次数只从 7 涨到 20 出头

真正值钱的不是「7 次」这个数字，而是它的性质：二分给的是最坏情况的上限，不靠运气。工程上最值钱的就是确定性。

前提：二分的门票是「先排好序」。页码打乱的字典里，翻到中间发现是「猫」，你无法判断「狗」在左还是在右，二分当场失效。

6.1b 二分的日常真身

你其实早就在用二分，只是没给它起这个名字：

• 翻字典 / 翻通讯录：找「王」不会从第一页翻起，先翻到中间，比一下拼音前后，直接扔掉一半——你手上的动作就是二分。
• git bisect 找坏提交：1000 个提交里有一个引入了 bug，让 git 自动跳到中间的提交测一下，好的砍前半、坏的砍后半，10 次内锁定元凶。
• 猜价格 / 调参数：综艺里的猜价环节，高手全在心里做二分；调试超参数时的手动逼近也是同款。

6.2 冒泡 vs 快排

	冒泡排序	快速排序
思路	相邻比较，大的往右冒	选基准，矮的左、高的右，各自递归
复杂度	O(n²)	平均 O(n·log n)
观感	10 根柱子时差不多	60 根柱子时比较次数只有冒泡的零头

说实话：真实工程里没人手写排序，一行 list.sort() 就完事，内置实现比手写的都好。学这个是为了两种手感：

1. 看懂「为什么有的代码要跑一整晚」——多半是有人在百万级数据上用了 O(n²)；
2. 亲身体会 O(n²) 与 O(n·log n) 到底差多少。

尺子有了，验收 AI 写的代码才有底气。

---

七、Rerank：排序在 AI 时代的真身

7.1 两阶段漏斗

知识库全部文档
   ↓ 粗排：向量近邻，快而糙（100 万 → 50）
50 条候选段落
   ↓ 精排 Rerank：逐条细看，贵而准（50 → 5）
5 条最终塞进上下文

• 为什么不全用精排？贵。把「问题 + 段落」成对送进模型逐条细读，100 万条要等一小时、烧一笔钱。
• 为什么不全用粗排？不准。粗排只看向量距离，分不清「现行政策」与「旧版政策」。

7.2 权重就是价值观

在客服问答场景里，候选段落有三个分数维度：向量相似度、关键词命中、新鲜度。总分是三项的加权平均。

关键实验：初始只重视相似度时，排第一的是 2023 年的旧版政策；把「新鲜度」权重加上去，正确的现行条款立刻登顶。

这说明了很重要的一点：你给哪个维度多少权重，就等于宣告你更在意什么。权重配置不是调参，是价值观的编码。

提示3 · 工程 = 在漏斗的每一层花对钱

快而糙的算法负责海选，贵而准的模型负责决赛，两层各干各的，总成本和总质量才能同时达标。这个「分层花钱」的思路，你在缓存、推荐、审核系统里会反复见到。验收一个检索系统时，先问：粗排召回多少、精排看多少、两层的单条成本各是多少。 答不上来的系统，成本一定失控。

---

八、递归：把大事拆成同一件小事

8.1 递归三件套（验收标准）

要件	含义	反例
同样的事	子问题与原问题同构，能用同一套拆法	拆出来的子问题完全是另一码事
规模更小	每拆一层问题必须变小一圈	不变小，永远拆不完
终止条件	拆到「能直接干了」的叶子就得停	没有终止条件 = 爆栈 Stack Overflow

第三条最要命：递归每深一层就在栈上摞一层。

8.2 与 AI 的对应

你让 Agent「重构整个项目」，它先列子任务，发现「重构登录模块」还是太大就继续拆，直到每一项都是「改一个文件」这种能直接执行的动作。判断「够小了、能动手了」的那一刻，就是它的终止条件。

---

九、分治：上下文压缩的算法原理

9.1 三幕动作

以一段 12 条消息、约 3600 token 的装修对话为例：

1. 切（Divide）：分成三段；
2. 治（Conquer）：每段各自收成一条摘要（段够短，AI 一口能读完，总结准，且可并行）；
3. 合（Merge）：三条摘要并成一条总摘要。段还太多？递归再来一轮。

9.2 与归并排序同构

归并排序排的是数，Compaction 压的是话，骨架一模一样。

为什么不一口气让 AI 总结全文？因为「总结一万字」本身就会把上下文塞爆——这不正是我们要解决的那个问题吗。分治的聪明处在于：把解不动的大问题变成一堆肯定解得动的小问题，再花点力气拼装。

9.3 保留最近 N 条

真实 Agent 的做法是只压旧的、留新的：最近几条对话往往就是正在办的事，最金贵，一个字都不动。打开「保留最近 4 条」再压一次，token 数没有压到 200 那么狠——保真和省空间，永远在做交换。

9.4 诚实卡：压缩是有损的

	内容
原文	「预算 8 万以内」「我特别不喜欢红色，全屋别出现红色」
压缩后	「讨论了预算和配色偏好」——具体数字与红色禁令都没了

后果：AI 还知道「聊过预算」，但再问「我预算多少」它只能猜；下次它给你配个红沙发，你都没处说理。

提示4 · 关键事实必须另存，别指望摘要

数字、硬性要求、已经做出的决定，这些要另外记进长期记忆或项目文档，不能指望摘要替你留着。分工应该是：

• 摘要负责「大概聊过什么」；
• 档案负责「铁板钉钉的事」。

一条可直接落地的做法：在 Agent 的压缩流程里加一个「事实抽取」步骤，压缩前先把数字、日期、明确禁令抽成结构化条目写入档案，再对剩余内容做摘要。

---

十、审查清单

落地时逐条自查：

• Agent 的代码执行环境与密钥是否物理分离（不同容器 / 不同进程）？
• 凭证是否做到「可用不可见」（绑定资源 或 Vault 代理）？
• 文件系统、网络、进程三层隔离是否都开了？
• 信任层级是否具备 Tool / Session / Global 三层？全局红线是否已写死？
• 检索链路是否有明确的两阶段漏斗？粗排召回数与精排条数是否可配置、可观测？
• Rerank 的权重配置是否反映了业务价值观（而不只是默认相似度）？
• 递归实现是否通过了三件套验收？终止条件是否在所有分支上都成立？
• 上下文压缩是否保留了最近 N 条原样不动？
• 压缩前是否做了关键事实抽取并另存档案？
• AI 产出的排序 / 查找代码，是否核对过它在目标数据规模上的复杂度？

---

十一、约束说明

本集内容受以下约束限制，读者需注意：

1. 取材边界：仅取自小山学堂对应 6 节课的正文，不引入外部案例或数据。
2. 代码说明：文中出现的命令与流程均为示意，用于说明结构，非可直接生产使用的配置。
3. 复杂度口径：快排的 O(n·log n) 是平均复杂度，最坏情况会退化为 O(n²)，实际选型需考虑退化风险与语言内置实现的优化（如 introsort）。
4. token 数值：3600 token、保留 4 条等数字来自课程演示设定，真实系统的窗口与保留策略需自行压测确定。
5. 安全方案：凭证隔离的两种模式各有适用前提，Vault 代理引入了新的可用性依赖（代理本身成为关键路径），需配套高可用设计。
6. 压缩有损：这是信息论的必然，不是实现缺陷，只能通过「关键事实另存」缓解，无法根除。
7. 二次演绎：音频为改写后的口播版本，段落顺序与措辞相对原课程有调整，以音频与本文为准。

---

十二、一句话总结

无论是隔离凭证、分层信任、两阶段漏斗，还是切分再合并的上下文压缩，它们都在做同一个动作——承认单点扛不住，然后用结构去分解压力。

这大概就是工程师最核心的一种手艺。

---

*来源：xueai.miyang.cn（小山学堂 · 洛小山《学 AI 产品，从入门到精通》）*

*本内容改编自小山学堂《学 AI 产品，从入门到精通》，为二次演绎配音版*