vault backup: 2026-08-09 19:06:40

06.AI/agent-design/Eino DAG 工作流设计_test.md

@@ -0,0 +1,147 @@
+---
+tags: [test/review, ai, agent-design, eino-dag]
+create time: 2026-08-09 12:00
+---
+
+# Eino DAG 工作流设计 — 测试题
+
+## 概述
+本测试覆盖 Eino DAG 核心概念（Node/Edge/Workflow）、状态传递机制、Choice 条件分支、ParallelStep 并行执行以及错误处理与重试策略。共 10 道题目（6 选择 + 3 填空 + 1 简答）。
+
+---
+
+## 一、选择题（6道，由浅入深）
+
+> **难度阶梯**: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景
+
+### Q1（基础）— 考察定义层面
+
+Eino 框架中，以下哪个节点类型**不是**原生支持的？
+
+A. LLM Node — 调用大模型生成文本
+B. Tool Node — 执行预注册的外部工具
+C. Database Node — 直接执行 SQL 查询
+D. Lambda Node — 自定义 Go 函数闭包
+
+### Q2（基础）→ 
+
+DAG 的核心优势在于并行性——如果两个节点没有数据依赖，它们可以在不同 Goroutine 中同时运行。那么两个节点能否安全并发的判定条件是：
+
+A. 它们的输入相同
+B. 它们的上游节点相同
+C. 它们没有重叠的 writes
+D. 它们的执行时间相近
+
+### Q3（进阶）— 核心原理
+
+在 Eino 中 Choice 节点根据什么决定走向哪个下游节点？
+
+A. 固定的路由规则表
+B. 回调函数返回的目标节点 ID
+C. 节点的拓扑排序位置
+D. 随机选择一个未饱和的下游
+
+### Q4（进阶）— 比较/辨析
+
+关于 ParallelStep 的描述，以下哪个是错误的？
+
+A. 可以对同一上游 fan-out 到多个下游
+B. 需要一个 Merge 函数负责将子图结果聚合为最终输出
+C. 三个子任务串行执行后合并结果以节省资源
+D. 每个子任务可以处理输入的不同维度
+
+### Q5（深入）— 场景推理
+
+一个 RAG 系统中，检索节点的输出可能为空（找不到相关文档）。用 Eino DAG 实现时，最合理的方案是：
+
+A. 在检索节点后加一个 Checkpoint，如果为空就中断整个 DAG
+B. 使用 Choice 节点判断 hits 是否为空，为空时走 fallback 路径，不为空时走主路径
+C. 配置重试策略无限重试直到有结果
+D. 让 LLM 自己编造答案
+
+### Q6（深入）— 源码级/边界场景
+
+关于 Eino DAG 的错误处理策略，"连续失败 N 次后跳过整条链路"对应的是哪种机制？
+
+A. 节点级超时
+B. 失败重试
+C. 降级路径
+D. 熔断器
+
+---
+
+## 二、填空题（3道）
+
+### F1 — 填空1
+
+DAG 在编译期完成_____，确保图中无环。运行时按拓扑序执行所有没有未满足依赖的节点，已就绪节点可并发执行。如果实际项目中节点数超过_____个，建议拆分为嵌套子 DAG。
+
+> **提示**: 第一个空是编译期的关键动作；第二个空是原文中的经验上限值。
+
+### F2 — 填空2
+
+State Schema 中节点的读集合（reads）和写集合（writes）决定了节点间能否安全并行——两个节点如果没有_____就一定能并发执行。如果都写同一个字段则必须串行。
+
+> **提示**: 原文面试常考点的原话。
+
+### F3 — 填空3
+
+重试配置的参数包括 MaxRetries = _____、BackoffBase = 1s、BackoffMul = 2。这是一个标准的_____退避算法。
+
+> **提示**: 回忆重试代码示例中的数值和时间算法名称。
+
+---
+
+## 三、简答题（1道）
+
+### S1
+
+面试官问："如何用 DAG 实现一个多轮对话系统？"请给出你的架构设计，需要涵盖：
+1. State 如何携带上下文
+2. Intent 判断的节点设计
+3. 专业 Agent 的分发机制
+4. 质量保障闭环
+
+> **答题框架提示**:
+> 1. 单轮 vs 多轮的建模方式
+> 2. 关键节点类型及其职责
+> 3. 循环/反馈的设计（如 self-check）
+> 4. 复杂度控制
+
+---
+
+## 参考答案与解析
+
+### 选择题答案
+
+| 题号 | 正确答案 | 解析 |
+|------|---------|------|
+| Q1 | C | Eino 原生的五种节点是：LLM Node、Tool Node、Prompt Node、State Node、Lambda Node。Database Node 不是原生类型——如果需要数据库操作，可以用 Tool Node 或 Lambda Node 封装 SQL 查询逻辑。 |
+| Q2 | C | 原文面试常考点：两个节点如果没有重叠的 writes，就一定能并发执行。共享读取不冲突，只有写入冲突才需要序列化。 |
+| Q3 | B | Choice 节点基于回调函数（路由函数）返回目标节点 ID，然后 map 中将字符串 key 映射到对应的下游节点。回调函数的签名是 `func(state *eino.State) (string, error)`。 |
+| Q4 | C | ParallelStep 是**并行**执行而非串行——三个 Agent 同时启动各自处理 query 的一个维度。C 说"串行执行"完全违背了 ParallelStep 的设计目的。 |
+| Q5 | B | Choice 判断 hits 是否为空是最合理的方案：RAG 检索为空时回退到备用路径（如默认回答或直接拒绝），这是原文中提到的降级模式。 |
+| Q6 | D | 熔断器的定义是"连续失败 N 次后跳过整条链路"。这是为了防止上游服务不可用时持续浪费资源尝试调用。 |
+
+### 填空题答案
+
+| 题号 | 答案 | 解析 |
+|------|------|------|
+| F1 | `拓扑排序`；`15` | DAG 编译期做拓扑排序确保无环。原文建议控制在 15 个节点以内，超出则拆分为嵌套子 DAG——因为复杂度随节点数呈组合增长。 |
+| F2 | `重叠的 writes`（或"共同的写入字段"） | 读读不冲突，读写也不冲突（只要不是同一个字段），只有写写冲突才需要串行。这也是 Eino 状态机的核心并发安全原则。 |
+| F3 | `3`；`指数` | 标准指数退避：第一次 1s，第二次 2s，第三次 4s。MaxRetries=3 表示最多重试 3 次。 |
+
+### 简答题参考答案
+
+S1：**参考答案要点**：
+1. **单轮建模**：每轮对话作为一个独立的 DAG 实例，但 State 携带历史消息（messages 数组），保证上下文连贯。
+2. **IntentNode**：LLM Node 分析用户意图类型（问答/创作/闲聊），通过 Choice 分发给不同专业 Agent。
+3. **分发机制**：Choice 根据 IntentNode 的输出路由到不同路径；ParallelStep 并行调用搜索 Agent、知识库加载 Agent 等。
+4. **质量保障**：在 LLM 生成后加入质量评估节点做 self-check，如果不达标则重新触发检索节点（形成循环）。
+5. **复杂度控制**：单轮 DAG 控制在 15 个节点内；复杂的多轮对话拆分为嵌套子 DAG，外层管理回合切换。
+
+**评分标准**：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点。
+
+## 关联笔记
+- [[多智能体协作模式]]
+- [[上下文工程与记忆管理]]

06.AI/agent-design/上下文工程与记忆管理_test.md

@@ -0,0 +1,147 @@
+---
+tags: [test/review, ai, agent-design, rag]
+create time: 2026-08-09 12:00
+---
+
+# 上下文工程与记忆管理 — 测试题
+
+## 概述
+本测试覆盖 RAG 完整链路（Chunking → Embedding → 检索 → 重排）、Prompt Context 组装策略、Prompt 压缩方法以及 Agent 三层记忆架构。共 10 道题目（6 选择 + 3 填空 + 1 简答）。
+
+---
+
+## 一、选择题（6道，由浅入深）
+
+> **难度阶梯**: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景
+
+### Q1（基础）— 考察定义层面
+
+RAG（Retrieval-Augmented Generation）解决 LLM 的哪些问题？
+
+A. 推理速度慢和成本高
+B. 知识截止和幻觉问题
+C. 不支持多语言
+D. 无法调用外部工具
+
+### Q2（基础）→ 
+
+以下哪种 Chunking 分块策略被推荐为实际项目的最佳实践？
+
+A. 固定长度按字符数 N 切割，简单快速
+B. 语义边界在标题段落间切割
+C. 递归分块 + 重叠——先按 Markdown 层级分，超阈值再按句子切，保留 10-15% 重叠区
+D. 文档感知基于 PDF 解析的结构信息
+
+### Q3（进阶）— 核心原理
+
+Top-K 检索流程中，为什么 Cross-Encoder 比 Single-Encoder 精度高约 10-15% 但只用于二次筛选而非全量检索？
+
+A. Cross-Encoder 模型更小更快
+B. Cross-Encoder 速度慢 20 倍，只做二次筛选
+C. Single-Encoder 只能处理单条查询
+D. Cross-Encoder 需要 GPU 加速而服务器没有
+
+### Q4（进阶）— 比较/辨析
+
+关于 RAG 和记忆的关系，原文的结论是：
+
+A. RAG 可以完全替代记忆模块
+B. 记忆可以完全替代 RAG
+C. 两者正交互补而非互斥——RAG 面向外部知识，记忆面向个性化数据
+D. 它们本质上是同一个东西的不同叫法
+
+### Q5（深入）— 场景推理
+
+一个智能客服对话系统已经持续交互了 30 轮，当前 token 预算只剩 500 tokens。以下哪种 Context 压缩方法的优先级最高？
+
+A. Token 池修剪——计算 Self-Influence Score
+B. 摘要浓缩——用 LLM 将多个片段合并为一句话
+C. 信息密度排序——按非停用词比例保留高密度片段
+D. 全部丢弃以节省 token
+
+### Q6（深入）— 源码级/边界场景
+
+Agent 的三层记忆架构中，"用户在交互中表达的偏好和事实陈述会被抽取并持久化"属于哪一层？
+
+A. 短期记忆
+B. 工作记忆
+C. 长期记忆
+D. 以上都不是
+
+---
+
+## 二、填空题（3道）
+
+### F1 — 填空1
+
+Prompt Context 组装的优先级顺序是：_____ > 事实上下文 > 历史对话。永远不要盲目把全部 Top-K 塞进 Prompt——token 预算有限，超出的部分会触发 truncation 丢失重要信息。建议按_____降序填充直到触及 token 上限。
+
+> **提示**: 回想原文中关于组装优先级的描述。
+
+### F2 — 填空2
+
+长期记忆的更新策略包括四种：新增（新发现信息插入）、修正（标记旧记忆为 obsolete）、合并（碎片信息聚合）、_____（随时间推移降低旧记忆权重，weight *= decay_factor）。
+
+> **提示**: 原文中的第四个关键词。
+
+### F3 — 填空3
+
+向量维度选择的权衡：768 维够用且快，_____ 维更精细但消耗更多内存。国内常用的 text-embedding-v3 默认 _____ 维。
+
+> **提示**: 原文中提到的高维度数值。
+
+---
+
+## 三、简答题（1道）
+
+### S1
+
+某知识库搜索产品采用 RAG 架构，用户反馈"回答不准确，检索到的文档似乎与问题无关"。请结合 RAG 全流程分析可能的原因和解决方案，涵盖：
+1. Chunking 阶段的问题
+2. 检索阶段的问题
+3. Context 组装的问题
+4. 重排环节的缺失
+
+> **答题框架提示**:
+> 1. 每个阶段的常见陷阱
+> 2. 对应的改进方案
+> 3. 优先级排序（先排查哪个阶段）
+
+---
+
+## 参考答案与解析
+
+### 选择题答案
+
+| 题号 | 正确答案 | 解析 |
+|------|---------|------|
+| Q1 | B | RAG 通过检索增强生成补充 LLM 的知识库，解决两个核心问题：① 知识截止（LLM 训练时未包含的最新信息）；② 幻觉（编造不存在的事实）。RAG 不解决推理速度或代码能力问题。 |
+| Q2 | C | 递归分块+重叠是推荐的综合方案：先按 Markdown 层级保持结构完整性，同一块超限再按句子切，相邻块保留 10-15% 重叠避免关键句被拆分。这是兼顾精度和效率的最佳实践。 |
+| Q3 | B | Cross-Encoder 对 query-document 对做联合编码，精度高 10-15%，但计算复杂度高 20 倍。所以先用 Single-Encoder/BM25 召回 Top 50，再用 Cross-Encoder 精排取 Top 5。 |
+| Q4 | C | 面试常考点：RAG 面向的是外部知识（文档、手册），记忆面向的是个性化数据（用户偏好、历史对话）。两者正交互补而非互斥。 |
+| Q5 | C | 信息密度排序是最实用的压缩方法——计算每 token 包含的事实数量（非停用词比例），保留高密度的核心片段，丢弃废话。不需要额外 LLM 调用（摘要浓缩有信息损失），也不需要复杂计算（Token 池太贵）。 |
+| Q6 | C | 长期记忆 = 跨会话的知识库。用户偏好（技术栈偏好）、事实陈述（PostgreSQL 支持 JSONB）、决策记录都会被抽取存储到向量数据库中。短期记忆是当前会话内的滑动窗口。 |
+
+### 填空题答案
+
+| 题号 | 答案 | 解析 |
+|------|------|------|
+| F1 | `系统提示`；`相关度` | 系统提示是固定的角色和行为准则，不可变且最高优先级。事实上下文按相关度降序填充，直至触及 token 上限为止。 |
+| F2 | `衰减` | 记忆的 decay_factor 确保旧信息不会永远占据主导地位。例如每次访问时 weight *= 0.99，随着时间推移逐渐降低旧记忆的检索优先级。 |
+| F3 | `1536`；`1536` | 768 维够用且计算快，1536 维更精细但占更多内存。text-embedding-v3 默认的 1536 维在国内生态中最常用。 |
+
+### 简答题参考答案
+
+S1：**参考答案要点**：
+1. **Chunking 问题**：固定长度切可能截断语义；建议使用递归分块+10-15% 重叠。如果文档格式不规范（PDF 解析差），考虑改用文档感知分块。
+2. **检索问题**：向量相似度可能召回语义相似但不相关的文档。引入 BM25 关键词匹配做混合检索，或提升 Top-K 数量后靠重排过滤。
+3. **Context 组装问题**：盲目塞入全部 Top-K 导致关键信息被 truncation 丢弃。应按相关度降序逐段填充，直到 token 上限，或使用信息密度排序优先保留核心片段。
+4. **重排缺失**：缺少 Cross-Encoder 重排环节意味着 Top-K 直接注入而没有二次精筛。加上重排可以显著提升准确率 10-15%。
+5. **排查优先级**：先检查 Chunking（源头质量决定上限）→ 再调 Top-K 大小 → 加 Cross-Encoder 重排 → 最后优化 Context 组装策略。
+
+**评分标准**：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点。
+
+## 关联笔记
+- [[Eino DAG 工作流设计]]
+- [[沙箱权限治理]]
+- [[循环状态机在Agent中的应用]]

06.AI/agent-design/多智能体协作模式_test.md

@@ -0,0 +1,143 @@
+---
+tags: [test/review, ai, agent-design, multi-agent]
+create time: 2026-08-09 12:00
+---
+
+# 多智能体协作模式 — 测试题
+
+## 概述
+本测试覆盖 Supervisor 主从分发模式、Critic 审查反馈循环、Planner 规划先行机制、消息传递协议以及各模式的对比分析。共 10 道题目（6 选择 + 3 填空 + 1 简答）。
+
+---
+
+## 一、选择题（6道，由浅入深）
+
+> **难度阶梯**: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景
+
+### Q1（基础）— 考察定义层面
+
+多智能体系统相比单一大 Agent 的核心挑战不包括以下哪项？
+
+A. 通信协议设计
+B. 任务分解质量
+C. 模型训练数据量
+D. 冲突消解机制
+
+### Q2（基础）→ 
+
+Supervisor 模式中子任务的最佳粒度是：
+
+A. 越细越好——每个原子操作都拆成独立子任务
+B. 越粗越好——减少通信开销
+C. 一般 3-7 个粒度最合适——匹配人类短期记忆容量（Miller 法则）
+D. 固定为 2 个子任务以确保并行效率
+
+### Q3（进阶）— 核心原理
+
+Critic Agent 的角色定位是什么？
+
+A. 负责生成候选方案并评估其可行性
+B. 不生产内容，只评估已有内容的质量，给出评分和改进建议
+C. 负责将最终结果格式化输出
+D. 负责与用户交互收集需求
+
+### Q4（进阶）— 比较/辨析
+
+以下关于 Planner 模式动态 Planning（Replan）的描述哪个是正确的？
+
+A. Plan 一旦制定就不能修改
+B. 当某一步失败或结果不符合预期时，Planner 重新规划后续步骤
+C. Replan 只在所有步骤完成后触发
+D. Replan 会从头开始执行整个流程
+
+### Q5（深入）— 场景推理
+
+在 Gen2D 项目中采用的多 Agent 混合架构是：
+
+A. 纯 Supervisor 模式
+B. 纯 Planner 模式
+C. Supervisor + Planner 混合模式
+D. Swarm 模式
+
+### Q6（深入）— 源码级/边界场景
+
+原文中提到"为什么不做一个超级大的 Agent"的四个原因中，以下哪个**不是**其中的一个？
+
+A. 上下文窗口有限，塞入太多能力会稀释注意力
+B. 工具冲突概率随数量增加而上升
+C. LLM 的单次推理成本随上下文长度指数增长
+D. 调试困难——出问题时无法定位是哪个模块的问题
+
+---
+
+## 二、填空题（3道）
+
+### F1 — 填空1
+
+多 Agent 之间通过结构化消息通信，推荐使用 _____ Schema 定义契约。消息类型体系中，`task_assignment` 的方向是 S → Agent，_____ 的方向是 Agent → S（汇报完成结果）。
+
+> **提示**: 第一个空填消息格式；第二个空是原文表格中的消息类型名称。
+
+### F2 — 填空2
+
+Critic 的质量取决于它的评估标准是否_____。纯自然语言的评判主观性太强，应该定义结构化评分维度：准确性、完整性、安全性各占权重。
+
+> **提示**: 形容词，表示可以用数字衡量。
+
+### F3 — 填空3
+
+Swarm 模式的优点是简洁灵活、天然并行，缺点是缺乏全局协调、易产生不一致。它最适合的场景是_____和发散性的_____。
+
+> **提示**: 两个词，描述一类任务的性质。
+
+---
+
+## 三、简答题（1道）
+
+### S1
+
+面试官问："在一个智能客服系统中，你需要同时处理用户咨询、订单查询和退款申请三个不同类型的请求。请设计一个多 Agent 协作方案，说明你会选用哪些模式组合，为什么这样选型，以及如何保证最终交付给用户的一致体验。"
+
+> **答题框架提示**:
+> 1. 整体架构模式选择及理由
+> 2. 各 Agent 的职责划分
+> 3. 通信与状态管理
+> 4. 质量保障机制
+
+---
+
+## 参考答案与解析
+
+### 选择题答案
+
+| 题号 | 正确答案 | 解析 |
+|------|---------|------|
+| Q1 | C | 多智能体的三大核心挑战：① 通信协议设计；② 任务分解质量；③ 冲突消解机制。模型训练数据量是单Agent和多Agent都要面对的共同问题，不是多Agent特有的挑战。 |
+| Q2 | C | Miller 法则指出人类短期记忆容量约为 7±2 个信息块。子任务拆得太细导致通信开销过大；太粗则失去并行价值。3-7 是最优区间。 |
+| Q3 | B | Critic 不生产内容，只评估已有内容的质量。Producer-Critic 形成对抗循环，类似于 GAN 中的判别器角色。 |
+| Q4 | B | 动态 Planning（Replan）的核心就是当某一步失败或结果不符合预期时，Planner 重新规划后续步骤。例如搜索结果为空时自动调整为扩大搜索范围。 |
+| Q5 | C | Gen2D 采用 Supervisor + Planner 混合：入口 Supervisor 分解为前端/后端/测试三条线，每条线内由 Planner 制定步骤序列。避免单层 DAG 节点过多。 |
+| Q6 | C | 原文提到的四个原因是：① 上下文窗口有限；② 工具冲突概率上升；③ 调试困难；④ 迭代成本高。单次推理成本随上下文增长虽然也是事实，但原文未将其列为核心理由。 |
+
+### 填空题答案
+
+| 题号 | 答案 | 解析 |
+|------|------|------|
+| F1 | `JSON`；`result_report` | JSON Schema 提供结构化的消息契约。消息类型体系包括 task_assignment（分配）、result_report（汇报）、feedback_request（反馈）、escalation（上报）、cancellation（取消）。 |
+| F2 | `量化`（或"可量化"） | 纯自然语言评判主观性太强。Critic 必须定义结构化评分维度如准确性（准确率%）、完整性（覆盖率%）、安全性（违规数），各占明确权重。 |
+| F3 | `探索性`；`头脑风暴` | Swarm 没有全局协调者，各 Agent 独立行动。这种模式适合无固定流程的探索性任务和发散性的头脑风暴，不适合需要严格顺序的步骤化任务。 |
+
+### 简答题参考答案
+
+S1：**参考答案要点**：
+1. **整体架构**：选用 Supervisor + Critic 混合模式。Supervisor 负责接收用户需求并按类型分发给专业 Agent（咨询专家、订单专员、退款专员），Critic 负责最终输出质量的交叉检查。
+2. **职责划分**：咨询 Agent 调用知识库 RAG；订单 Agent 查询数据库；退款 Agent 走审批流 FSM。每种类型的 Agent 工具集互不干扰。
+3. **通信与状态**：结构化消息（JSON Schema）承载任务分配和结果汇报。共享 State 存储中间产物和用户上下文。
+4. **一致体验**：Critic Agent 统一审核各 Agent 的输出——格式规范化、语气一致性、敏感词过滤。最终由 Supervisor 整合后交付用户。
+5. **降级策略**：某个 Agent 不可用时（如订单系统宕机），Supervisor 切换到缓存版本或直接告知用户暂时无法服务，而不是让整个对话崩溃。
+
+**评分标准**：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点。
+
+## 关联笔记
+- [[Eino DAG 工作流设计]]
+- [[上下文工程与记忆管理]]

06.AI/agent-design/循环状态机在Agent中的应用_test.md

@@ -0,0 +1,145 @@
+---
+tags: [test/review, ai, agent-design, react-loop]
+create time: 2026-08-09 12:00
+---
+
+# 循环状态机在Agent中的应用 — 测试题
+
+## 概述
+本测试覆盖 ReAct 循环（思考→行动→观察）、自反思修正（Self-Reflection）、收敛条件设计以及与简单 Loop 的区别。共 10 道题目（6 选择 + 3 填空 + 1 简答）。
+
+---
+
+## 一、选择题（6道，由浅入深）
+
+> **难度阶梯**: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景
+
+### Q1（基础）— 考察定义层面
+
+ReAct 循环中的三个核心步骤依次是：
+
+A. Plan → Execute → Report
+B. Reason → Act → Observe
+C. Think → Do → Check
+D. Search → Read → Answer
+
+### Q2（基础）→ 
+
+以下关于 Self-Reflection 的描述哪个是正确的？
+
+A. 它是一个可有可无的附加功能
+B. 它在每次 Observe 之后额外增加自我评估步骤，判断当前进度是否足以完成任务
+C. 它只在所有迭代结束后才执行一次
+D. 它替代了 Reason 步骤
+
+### Q3（进阶）— 核心原理
+
+原文提到的经验表明，ReAct 的最大迭代次数不建议超过多少轮？为什么？
+
+A. 3 轮——太慢了
+B. 5 轮——没有证据支持
+C. 8 轮——超过后错误率开始反弹，因为早期错误累积进历史污染后续推理
+D. 20 轮——越多越准确
+
+### Q4（进阶）— 比较/辨析
+
+ReAct 状态机与简单 while Loop 的核心区别不包括以下哪项？
+
+A. ReAct 有 LLM 推理 + 工具反馈做决策依据，简单 Loop 只有固定规则
+B. ReAct 携带完整历史上下文，简单 Loop 无状态感知
+C. ReAct 需要数据库存储每步结果，简单 Loop 不需要
+D. ReAct 每轮可换策略，简单 Loop 不支持
+
+### Q5（深入）— 场景推理
+
+一个 Agent 正在执行搜索任务获取「Go 1.21 GC 改进」的信息。三轮后的状态是：第一轮搜索返回摘要，第二轮 fetch URL 得到详情，第三轮综合信息准备生成答案。这体现了哪种模式？
+
+A. Supervisor 分发
+B. Planner 静态规划
+C. ReAct 多轮循环
+D. Critic 审查
+
+### Q6（深入）— 源码级/边界场景
+
+以下哪种防无限循环的技巧**不**是原文中提到的？
+
+A. Token 用量监控——单轮突增 3 倍则强制中断
+B. 去重检查——相同 Action 和结果连续出现两次说明卡死
+C. Entropy 监测——计算 Thought 文本的 perplexity
+D. 动态学习——根据每轮表现自动调整 LLM 温度参数
+
+---
+
+## 二、填空题（3道）
+
+### F1 — 填空1
+
+收敛条件包括五种：最大迭代次数（典型值 _____~_____ 次）、连续无改善（N=3）、置信度阈值（通常 0.8）、时间预算（通常 30s）以及 Token 预算。这是防止无限循环的最重要机制。
+
+> **提示**: 第一个空填最小值，第二个空填最大值。
+
+### F2 — 填空2
+
+简单的 while loop 只能让 Agent "做一件事直到成功"，缺乏对执行过程的结构性理解。基于状态机的循环——特别是 ReAct 模式——为 Agent 引入了可推理、可观测、可终止的_____框架。这是构建自主智能体的基础架构模式。
+
+> **提示**: 回忆原文概述部分的原词。
+
+### F3 — 填空3
+
+ThumbUP 项目中缓存策略选择是一个典型的 ReAct 决策过程：Thought(单一缓存有风险) → Action(调研业界方案) → Observation(二级缓存+HeavyKeeper是主流) → Thought(验证一致性开销) → Action(模拟测试) → Observation(延迟增加15ms) → Reflection(利大于弊)。这个过程中每一步都依赖上一步的_____做出调整，而非预先写死的流程分支。
+
+> **提示**: 回想 ReAct 的本质特征——不是 pre-defined，而是 reactive to what you just learned.
+
+---
+
+## 三、简答题（1道）
+
+### S1
+
+面试官问："如果一个 Agent 在执行 ReAct 循环时陷入了死循环——同一组 Thought-Action-Observation 反复出现，该怎么办？请设计一套完整的防无限循环机制。"
+
+> **答题框架提示**:
+> 1. 硬性约束（不可绕过的上限）
+> 2. 软性检测（基于语义的智能保护）
+> 3. 提前退出条件
+> 4. 最佳尝试兜底
+
+---
+
+## 参考答案与解析
+
+### 选择题答案
+
+| 题号 | 正确答案 | 解析 |
+|------|---------|------|
+| Q1 | B | ReAct = Reasoning + Acting，核心三步：思考分析当前局面 → 行动调用工具或生成答案 → 观察获取工具返回结果。然后根据评估决定是继续还是结束。 |
+| Q2 | B | Self-Reflection 是在每次 Observe 后额外增加的一步自我评估，判断进展、不足和下一步策略。它不是可选的——没有反思的循环就是蛮力，有反思才是智能。 |
+| Q3 | C | 原文警告：超过 8 轮后错误率开始反弹。因为早期的错误被不断累积进历史上下文，污染了后续推理。8-10 轮是经过实验验证的黄金区间。 |
+| Q4 | C | 原文对比表中列出的五个区别是：决策依据、状态感知、策略调整、终止条件、可解释性。数据库存储不是区分标准——两者都可以用内存或持久化存储。 |
+| Q5 | C | 这是一个典型的 ReAct 多轮展开：每一轮都是 Thought → Action → Observation 的循环，每步依赖上一步的观察结果做出调整。 |
+| Q6 | D | 原文提到的四种技巧是：① Token 用量监控；② 去重检查；③ Entropy/perplexity 监测；④ 人工介入网关。动态调整 LLM 温度参数不在其中。 |
+
+### 填空题答案
+
+| 题号 | 答案 | 解析 |
+|------|------|------|
+| F1 | `5`；`10` | 最大迭代次数 5-10 是最常用的范围。低于 5 可能不够完成复杂任务，超过 10 错误率开始反弹。配合连续无改善(N=3)和置信度(0.8)双重判断更可靠。 |
+| F2 | `执行` | 原文原话："为 Agent 引入了可推理、可观测、可终止的执行框架。这是构建自主智能体的基础架构模式。" |
+| F3 | `观察结果`（或"Observation"） | ReAct 的核心价值在于每一步不是预先写死的流程分支，而是 reactive 到上一步的实际观察结果，据此调整策略。 |
+
+### 简答题参考答案
+
+S1：**参考答案要点**：
+1. **硬性约束**：设置 max_iterations（如 8 次）作为不可绕过的上限。同时设时间预算（30s）和 token 预算，任一超限立即终止。
+2. **去重检测**：如果当前 Step 的 Action 和前两轮完全相同且结果也一样，说明陷入卡死状态。此时强制切换工具或重试不同的 Action。
+3. **Token 突增检测**：单轮 token 消耗突增 3 倍说明 LLM 可能陷入冗长输出循环，强制中断当前轮次。
+4. **提前退出**：当 confidence ≥ 0.8 或连续无改善达到限制时提前退出，不必等到 max_iterations。
+5. **兜底策略**：即使未达最优但已达上限，也返回 history 中 bestOf(history) 的最佳尝试结果，而不是返回空或错误。
+6. **人工介入**：超过一定复杂度（如 iteration > 6）自动请求 human-in-the-loop 确认下一步方向。
+
+**评分标准**：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点。
+
+## 关联笔记
+- [[Eino DAG 工作流设计]]
+- [[上下文工程与记忆管理]]
+- [[沙箱权限治理]]

06.AI/agent-design/沙箱权限治理_test.md

@@ -0,0 +1,146 @@
+---
+tags: [test/review, ai, agent-design, sandbox]
+create time: 2026-08-09 12:00
+---
+
+# 沙箱权限治理 — 测试题
+
+## 概述
+本测试覆盖代码执行隔离方案（Docker/gVisor/Wasm/Firecracker）、资源限制四层架构、工具白名单设计、审计日志规范以及 Prompt Injection 纵深防御策略。共 10 道题目（6 选择 + 3 填空 + 1 简答）。
+
+---
+
+## 一、选择题（6道，由浅入深）
+
+> **难度阶梯**: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景
+
+### Q1（基础）— 考察定义层面
+
+以下哪种代码执行隔离方案的启动速度最快？
+
+A. Docker 容器（~2s）
+B. gVisor（~500ms）
+C. WebAssembly / Wasm（~10ms）
+D. Firecracker MicroVM（~125ms）
+
+### Q2（基础）→ 
+
+沙箱的 Docker 核心配置中，`ReadOnlyRootFilesystem: true` 和 `NetworkMode: "none"` 的主要作用是什么？
+
+A. 提高执行速度
+B. 防止恶意代码修改宿主文件系统并切断外网访问
+C. 增加内存上限
+D. 自动重启异常进程
+
+### Q3（进阶）— 核心原理
+
+工具白名单设计的核心理念是：
+
+A. 拦截所有包含危险关键词的工具调用
+B. 黑名单模式——列出禁止调用的工具
+C. 白名单模式——显式声明允许的工具，其余全部拒绝
+D. 让 LLM 自己判断该调用哪个工具
+
+### Q4（进阶）— 比较/辨析
+
+关于防 Prompt Injection 的三层防御，以下哪个匹配是错误的？
+
+A. 层级一（系统提示注入检测）— 分隔符保护、角色隔离、指令优先级
+B. 层级二（用户输入净化）— 关键字过滤、长度限制、转义特殊字符
+C. 层级三（行为防护）— 工具调用二次确认、输出过滤、速率限制
+D. 单层分隔符保护足以完全防御所有 Prompt Injection 攻击
+
+### Q5（深入）— 场景推理
+
+一个 Agent 需要执行用户提供的 Python 代码并返回结果。以下安全配置组合最合理的是：
+
+A. 普通 Linux 进程 + 无网络限制 + 无限时
+B. Docker 容器只读文件系统 + 无特权 + 切断网络 + 256MB 内存上限 + 10s 超时
+C. Wasm + 只读文件系统 + 有完整网络访问权 + 1h 超时
+D. 直接在宿主机上运行用户代码，加一个 kill -9 的兜底脚本
+
+### Q6（深入）— 源码级/边界场景
+
+关于审计日志的设计，以下哪个字段不是必须的？
+
+A. trace_id — 一次对话的唯一标识
+B. timestamp — ISO8601 精确到毫秒
+C. user_id — 发起者身份
+D. model_version — LLM 的具体版本号
+
+---
+
+## 二、填空题（3道）
+
+### F1 — 填空1
+
+资源限制分为四层，每层针对不同类型的 DoS 风险：时间维度用_____控制强制中断无限循环；CPU 维度用 CFS Quota 限制计算占比；内存维度用 cgroup limit 配合 OOM Killer 兜底；网络维度用 eBPF 策略做白名单域名 + 内网隔离。
+
+> **提示**: 第一个空对应原文时间维度的关键词。
+
+### F2 — 填空2
+
+防 Prompt Injection 的核心原则是纵深防御：至少_____层组合形成互补。没有任何单一手段能完全防御。具体来说，层级一是系统提示注入检测（_____保护），层级二是用户输入净化（关键字过滤），层级三是行为防护（高危操作需人工审批）。
+
+> **提示**: 第一空填数字，第二空填一种技术名称。
+
+### F3 — 填空3
+
+工具调用必须使用结构化 JSON 而不是自然语言的原因有三点：① 可被程序化校验；② 参数类型明确不需要_____解析；③ IDE 可提供自动补全和 schema hint 提高 LLM 出参准确率。
+
+> **提示**: 第二个原因中的技术缩写。
+
+---
+
+## 三、简答题（1道）
+
+### S1
+
+某 AI 编程助手项目允许 Agent 执行用户的代码片段以提供实时反馈。请设计一个完整的安全治理方案，要求涵盖：
+1. 执行环境的隔离方案选型及理由
+2. 资源限制的四层设计
+3. 工具调用白名单策略
+4. 审计追踪与告警机制
+
+> **答题框架提示**:
+> 1. 各层的防护目标
+> 2. 方案间的依赖关系
+> 3. 异常场景的应急处理
+
+---
+
+## 参考答案与解析
+
+### 选择题答案
+
+| 题号 | 正确答案 | 解析 |
+|------|---------|------|
+| Q1 | C | Wasm 启动只需约 10ms，远超 Docker（~2s）和 gVisor（~500ms）。但代价是不支持文件系统操作——适合纯计算场景。Firecracker ~125ms 是最快的虚拟机方案。 |
+| Q2 | B | 只读文件系统防止恶意代码写入或修改文件；NetworkMode: none 切断外网阻止数据外泄。这两项是沙箱的基础安全屏障。 |
+| Q3 | C | 白名单设计理念：不依赖黑名单拦截（总有漏网之鱼），而是显式声明允许的工具，其余全部拒绝。这是一种零信任思路。 |
+| Q4 | D | D 是错误的！没有任何单一手段能完全防御 Prompt Injection。分层防御才是正道——至少三层组合形成互补。 |
+| Q5 | B | Docker 容器提供最全面的隔离能力：只读文件系统、无特权、断网、内存/CPU 限制、超时控制。Wasm 不支持文件系统不适合需要写文件的操作。直接宿主运行完全没有安全保障。 |
+| Q6 | D | 审计日志的核心字段是 trace_id、timestamp、user_id、tool_name、input_snapshot、output_snapshot、result_status、latency_ms、cost_tokens。model_version 虽有用但不是必记字段。 |
+
+### 填空题答案
+
+| 题号 | 答案 | 解析 |
+|------|------|------|
+| F1 | `超时控制` | 四层资源限制的典型值：全局超时≤30s，子任务超时≤10s，单步超时≤5s。外层自动取消内层上下文。 |
+| F2 | `三`；`分隔符` | 纵深防御至少三层：分隔符保护阻止指令混淆，关键字过滤拦截已知 injection patterns，行为防护限制实际损害。 |
+| F3 | `NLP` | 结构化 JSON 避免了自然语言的歧义性。LLM 输出的 tool_call JSON 可以被 Schema Validator 和 Policy Engine 程序化检查参数格式、工具名是否在白名单、用户是否有权限。 |
+
+### 简答题参考答案
+
+S1：**参考答案要点**：
+1. **隔离方案**：选 Docker 容器而非 Wasm（需要文件系统操作支持），也非 gVisor（Google Cloud 专属）。核心配置：只读根文件系统、Privileged=false、NetworkMode=none、内存/CPU 限制、10s 超时。
+2. **四层限制**：超时控制（全局30s/子任务10s/单步5s）+ CFS Quota（0.5 CPU）+ cgroup 内存上限（256MB）+ eBPF 网络白名单。
+3. **白名单策略**：预注册 8 个 Tool（代码生成、Git 操作、文档搜索等），Tool Calling Schema 通过 JSON Schema validator 校验参数格式，Policy Engine 检查工具名和权限。
+4. **审计与告警**：每次工具调用记录 trace_id/timestamp/user_id/tool_name/input/output/result/latency/cost。写入 Elasticsearch 支持按 trace_id 回溯。设置 RateLimit/SecurityAlert/PerformanceAlert 三类告警。
+5. **应急处理**：检测到异常时立即终止容器、冻结该用户的所有 token、通知安全团队介入。
+
+**评分标准**：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点。
+
+## 关联笔记
+- [[Eino DAG 工作流设计]]
+- [[循环状态机在Agent中的应用]]