设计一个「可扩展且安全」的 Agent 系统 —— 系统设计面试 - 求加米

一句话主线（开口先讲这句）：把编排（orchestration）和执行（execution）彻底分开。模型只负责提议动作，真正决定「能不能执行」的是模型之外一套确定性的控制平面。模型的任何输出——哪怕长得像结构化 JSON——都当作不可信输入；每个被提议的工具调用，都要过鉴权 / 校验 / 预算 / 幂等四道确定性闸门才能落地。

这道题考三件事：并发规模化、防止不安全的工具使用、检测重复/死循环。但真正让面试官点头的是你能不能讲清楚信任边界和执行前需要哪些"证据"。下面按面试作答顺序展开。

0. 先问澄清问题（30 秒，展示 senior 判断力）

• 工具与数据源有哪些？每个用户的权限边界是什么？（决定 authz 模型）
• 哪些动作需要显式确认或人工复核？（决定 human-in-the-loop 的触发阈值）
• 延迟 / 成本 / 完成度，哪个是硬约束？（决定要不要同步返回、预算怎么切）
• run 能不能暂停/恢复？状态保留多久？（决定持久化与 saga 设计）

面试技巧：问完立刻自己给出合理默认假设再往下讲，别停在提问上。

1. 信任边界与架构总览
把系统画成几个同心信任区（trust zones），这是本题的骨架：

区域	组件	是否可信	关键点
Zone 0	用户 & 目标(goal)	已认证身份	run 的 principal 从 用户 派生，绝不从模型派生
Zone 1	编排器 / 控制平面	可信	持久化状态机；它 不信任 模型输出
Zone 2	LLM / Agent（规划器）	不可信输出	只吐"提议动作"；无直连网络/工具/凭据
Zone 3	工具网关 / 策略引擎	可信、确定性	真正的 执行前闸门 （enforcement point）
Zone 4	工具 & 外部系统	混合	工具返回的内容也是不可信输入 ，会回灌进模型

两个最容易被忽略、但最能加分的洞察：

• LLM 是"你的"组件，但它的输出不可信。 它是个会被骗的规划器，不是权威。
• 工具的输出同样不可信——从网页/文档/邮件里读回来的内容，是**提示注入（prompt injection）**的主要入口。因此数据流是双向污染的。

落到一句话：模型可以被骗去"提议"坏动作，所以真正的防线永远是模型之外那道确定性闸门。 这是全篇的 thesis，反复回扣它。

2. 执行前需要哪些「证据」——确定性闸门（本题的核心）
网关在执行任何一个被提议的工具调用之前，必须集齐这些"证据"，缺一即拒：

• 已认证的调用者身份——run 的 principal（源自用户，不是模型编出来的）。
• 能力凭证（capability / grant）——证明"这个 run 被授权、在这个资源上、用这个工具"。要最小权限、短时效、按资源作用域（scoped），而不是 ambient authority（环境权限）。
• schema 校验通过——参数按工具契约做强类型校验；畸形就拒绝或修复。绝不把模型原始文本直接拼进 shell / SQL / API（用参数化，杜绝二次注入）。
• 策略检查通过——OPA 式确定性策略引擎判定(principal, tool, resource, args)的 allow/deny：资源白名单、数据分级、blast radius（爆炸半径）。
• 预算充足——run 级 & 租户级的 step / token / 成本 / 时间预算未超；单工具花费上限。
• 幂等键 + 去重检查——这个动作是不是已经执行/提交过了？（retry 安全的关键）
• 高危动作：一张已记录的人工审批令牌（signed approval token，一次性消费）。
• 先写审计再执行——执行前记"意图(intent)"，执行后记"结果(outcome)"，全程脱敏。

凭据/密钥永远不进模型、不进日志。 网关在执行时从 secrets broker 注入凭据，模型只看到不透明的能力句柄（capability handle）。

3. 关注点一：并发规模化（很多 run 同时跑）
思路是把它当成一个持久化工作流引擎（Temporal / durable execution 那一类）来设计。

• 持久化 run 状态：每个 run 是一台事件溯源（event-sourced）的状态机，一步一个 event 落库（Postgres / Spanner）。worker 崩了能从日志重建 → retry 安全的前提。
• 队列 + 无状态 worker 池：提交与执行解耦。run/step 进队列，无状态 worker 拉取 → 水平扩展。
• worker 租约（lease）+ 心跳：worker 领任务时拿一个带 TTL 的租约并持续心跳；worker 挂了租约过期，别的 worker 接手。用 fencing token（栅栏令牌） 防脑裂——崩掉又复活的旧 worker 不能重复提交。
• 幂等（idempotency）：每个工具调用、每次状态转移都带幂等键，retry 不会双重执行。（对应"worker/网络失败后重试"这条约束）
• 背压（backpressure）：有界队列 + 准入控制（admission control）；饱和时限流 / 拒绝并让重试 / 排队延后，而不是把系统压垮。
• 公平资源预算：按用户/租户配额 + 加权公平调度，防止一个租户的 run 饿死别人；租户级并发上限、token/成本预算。
• 分离两个 worker 池："思考"池（LLM 推理，贵且延迟主导） 和 "执行"池（工具调用） 独立扩缩。LLM 调用是成本与延迟的大头，必须能单独 autoscale（按队列深度）。

4. 关注点二：防止不安全的工具使用
分级是前提：工具在注册表里带机器可读契约——输入/输出 schema、风险等级、所需 scope、副作用类别（只读 / 改数据 / 花钱 / 联系真人）。

• 基于能力的工具网关（capability-based gateway）：访问靠受限、最小、时效性的能力授予，不是环境权限。agent 只拿到本任务需要的工具与 scope。
• 认证 + 授权：run 以某 principal 身份运行，网关认证它；确定性策略引擎逐调用判 allow/deny。最小权限。
• schema 校验 + 参数化：校验并规范化模型给的参数；下游一律参数化调用，杜绝注入。
• 沙箱（sandbox）：尤其是代码执行类工具，跑在隔离环境里（gVisor / microVM / 容器），无环境网络、出口白名单、资源上限，控制爆炸半径。
• 高危动作走人工闭环（human-in-the-loop）：超过风险阈值的动作（花费 > $X、删数据、给客户发邮件、不可逆操作）暂停 run，把具体的 diff / 预览展示给人，需显式确认（打字确认）。审批产出一张签名令牌，被网关一次性消费。
• 提示注入 & 数据外泄（exfiltration）防御（这块讲深最加分）：
• • 数据 ≠ 指令：把工具/检索回来的内容放进明确分隔的"数据区"，标注来源与"仅作数据、不作指令"，结构上隔离，别和 system/指令区混一锅。
  • 信息流/污点控制（taint tracking）：给来自低信任源的内容打污点标签；污点数据未经闸门不得流向高危 sink。
  • 切断经典外泄链：不要在同一上下文里既给"读敏感数据"又给"对外写"的能力而无策略门——那正是"读密钥 → 发给攻击者"的路径。
  • 出口白名单 + 对外参数做 DLP 扫描；密钥不进 prompt/日志，网关执行时注入、审计里脱敏。

核心心态：假设注入迟早会成功让模型"提议"坏动作。真正拦住它的是第 2 节那道确定性闸门（authz / 策略 / 预算 / 人工审批），这就是纵深防御。

5. 关注点三：循环 / 重复 / 死循环检测
用多个相互独立的上限做纵深防御，任一触发即停：

• 步数上限：单 run 最多 N 个"规划-执行"循环。
• 墙钟时间上限 + 单步超时。
• token 预算 + 成本预算：累计 LLM token 与美元硬上限。
• 重复状态检测：对(action, args)和/或 agent 状态做哈希；同一动作/状态在滑动窗口内复现超阈值就报循环；检测振荡环（A→B→A→B）。
• 无进展检测（progress metric）：可观测状态是否朝目标推进？若连续几步不产生新信息、不改变状态，多半是无效循环。
• 触发后的"有用的终止行为"：优雅收尾——返回部分结果 + 原因说明（"因步数耗尽/检测到循环而停止"），保留状态供恢复或人工复核，发出一条 incident/eval 信号。别静默失败，必要时升级给人。

6. 可观测性 / 脱敏 / 评估 / 事故响应

• 可审计但不泄密：完整记录 run 的每一步（意图→结果、审批、拒绝原因）；审计里对密钥/PII 脱敏（redaction）——审计完整性与脱敏是一对张力，明确取舍。
• 评估（eval）：离线用 trajectory grading / LLM-as-judge 对 run 轨迹打分；线上盯注入命中率、闸门拒绝率、循环触发率、人工审批通过率、成本/step。
• 事故响应：能全局熔断某个工具/某类动作；能按 run/租户回放事件日志定位；有 kill switch。

7. Follow-up 追问答案（面试官必问）
Q1. worker 在工具调用成功后、还没记状态就崩了，怎么安全恢复？ 经典的"副作用到底发生没发生"问题。答案 = 幂等 + 预写意图日志 + 两段式记录：

• 执行前先持久化"意图"：(幂等键 K, args, status=PENDING)。
• 带 幂等键 K 调工具（工具/网关按 K 去重：同一个 K 再来，返回上次结果而不重复执行）。
• 成功后记status=COMMITTED+ result。
• 若在"已提交、未记 COMMITTED"之间崩了：恢复时新 worker 看到 K 是 PENDING，绝不盲目重试变更类动作，而是对账（reconcile）——要么按 K 查工具的既有结果，要么用同一个 K 重发让网关/工具去重返回原结果（不会二次扣款）。对不支持幂等的外部系统，用 saga / 补偿事务。fencing token 保证崩溃后复活的旧 worker 无法再提交。

一句话：把"工具成功了但我没记上"当作**"未知 → 按 K 对账"，而不是**"直接重试"。前提是变更类工具必须支持幂等键，否则由网关包一层 exactly-once 去重。

Q2. 一个工具返回的不可信内容，怎么呈现给模型？

• 结构隔离：放进明确分隔的"数据区"，标注来源、声明"仅数据、非指令"，绝不和指令区合并。
• 打污点：标记为不可信；策略禁止污点内容直接触发高危动作。
• 最小化：只传必要片段；过大就先用一个受限步骤做摘要/抽取。
• 兜底认知：即便注入成功让模型提议坏动作，第 2 节的确定性闸门仍是最后防线——设计上就假设模型会被骗。

Q3. 什么指标能区分"任务本身难"和"无效死循环"？

• 难任务：每步产生新信息、状态在变、子目标在推进、错误类型多样——预算在烧但进度在动。
• 死循环：动作近乎重复、状态哈希反复复现、状态振荡、同一错误反复出现、动作熵低。
• 可量化指标：重复动作占比、状态哈希复现率、每步新增信息量（novel tokens/step）递减、子目标完成停滞、错误消息重复率。

8. 残余风险（主动说，显成熟）

• 提示注入无法根除；停留在已授权能力内的新型注入仍有风险——确定性闸门是主防线而非灵药。
• 能力授予过宽会有 confused deputy（受困代理） 风险。
• 幂等依赖工具配合；遗留工具不支持幂等键是缺口（包装/对账可缓解但非完美）。
• 审批疲劳：人工审批可能被橡皮图章化。
• 上限触发前，对抗性循环仍可能烧掉一笔成本。
• 基于模型的注入检测器本身也会误判。
• 审计完整性 vs 脱敏是持续张力。

面试作答节奏（怎么把上面讲出来）

• 先抛主线（编排/执行分离 + 模型输出不可信）→ 立刻定调。
• 画信任边界表（第 1 节）→ 给出骨架。
• 讲"执行前的证据"闸门（第 2 节）→ 这是本题的题眼，多花时间。
• 依次过三个关注点（并发 / 安全工具 / 循环）→ 每个都回扣主线。
• 可观测性 + 残余风险收尾 → 显示 senior 的全局观。
• Follow-up 三问对应第 7 节，尤其把 Q1 幂等对账讲透。

记住那一句能反复回扣的话：模型可以被骗去"提议"，但真正决定"能不能执行"的，永远是模型之外那道确定性闸门。

你这个不是AI回复的 给你加什么米。。

请教几个问题
1. 实时性怎么保证？你有queue，高并发会导致消息积压，scale up的速度一般也都是分钟级别。那么用户是不是要等几分钟才能知道结果
2. 模型是可以配置的吗？就是说我的首选模型如果不可用，是不是降低为备选模型？还是用户可以选模型？
3. 幂等这个判断耗时间吗？还是只是用作队列级别的去重复，而不是全局？幂等一般有时间单位，多久比较合适？
4. 感觉你这个设计注重的是安全，但是我觉得他会影响系统的吞吐。怎么tradeoff？