系统设计新题：Agent 控制平面的任务、权限、回滚和审计怎么拆

面试官让你“设计一个 Agent 平台”，最容易失分的画法，是把模型、队列、工具和数据库连起来，然后说系统可以自动规划并重试。第一层回答解释了组件；第二层追问却会立刻落到：谁允许这次动作、凭证从哪里来、邮件已经发错还能不能回滚、跨租户数据怎样不串、事故后靠什么还原。

高质量答案要先把控制面与执行面分开。控制面不替模型变聪明，它负责让有后果的动作保持有界、可暂停、可追责。

先分清控制面和执行面各自拥有什么

控制面拥有任务定义、策略判断、权限授予、审批状态、预算、超时、重试规则和审计索引；执行面拥有短时运行环境、模型调用、工具适配器和本次任务的临时状态。前者回答“能不能做、做到哪一步、失败后去哪里”，后者回答“这一步怎样执行并返回证据”。

你以为把两个面拆开只是架构整洁，实际上它决定了事故半径。如果执行 worker 同时能修改策略、读取长期凭证并改写审计记录，一次提示注入或程序错误就可能从任务失败升级为权限事故。

可以借用 Kubernetes 对期望状态和执行组件分离的思路帮助表达，但必须主动限定：Kubernetes 文档描述的是容器编排控制面，不是 AI Agent 的规定架构。这里使用的是设计类比，而不是行业标准。

任务契约先写意图、边界和完成条件

第一层回答常说“任务就是用户目标”。面试官会追问：一句“整理客户并发送跟进邮件”里，哪些客户、允许读取哪些系统、可以生成草稿还是直接发送、最多处理多少条、什么叫完成？如果这些问题只能在运行中让模型临时猜，控制面就没有稳定对象可管。

任务契约至少应包含意图、输入引用、允许动作、禁止动作、完成条件、预算、截止时间、审批要求和失败出口。自然语言可以保留给模型理解，但真正进入策略与执行的字段要可验证。例如，“发送”与“生成待审草稿”是不同能力，不能共用一个模糊状态。

任务还需要版本。策略、工具参数或用户目标变化后，旧执行不能悄悄套用新含义。面试中可以进一步说明：取消、暂停、恢复和重试都引用同一任务版本，并通过幂等键避免重复提交。

SDK Guardrails 也不能被当成万能的执行前闸门。不同执行模式下，模型工作可能在 tripwire 触发前已经开始，因此高风险外部动作仍要在工具网关提交前完成策略校验与人工确认。

AI Agent 工程师面试指南适合补齐角色层面的任务拆解、工具选择和停止条件；本题则把重点收窄到平台如何治理这些执行。

权限与凭证不能跟任务绑成一个对象

“任务有权限”听起来合理，却容易把意图、身份与秘密混在一起。更稳的做法是让控制面根据发起者、租户、任务类型、资源范围、风险等级和当前审批，签发短期、最小范围的授权；执行 worker 只拿到完成当前步骤所需的临时能力。

凭证服务与任务存储应分离。任务记录可以保存凭证引用和授权结果，不能保存长期密钥本身。工具适配器还要校验资源范围，而不是看到一个有效 token 就放行全部动作。到期、撤销和轮换也必须由独立所有者处理。

第二层追问通常是“如果 Prompt Injection 让模型改参数呢？”答案不能只说再加一段系统提示。模型提出的是动作候选，策略层仍要检查工具、参数、对象和影响范围。关于输入不可信、工具权限与事故止损的完整回答，可继续看 AI 安全工程师面试指南。

不可逆工具调用要靠确认、幂等与补偿

只读查询、创建草稿、发送邮件、支付款项和删除数据，不应共享一套执行规则。控制面应按可逆性、金额或影响范围、对象敏感度和证据质量进行分级。低风险动作可以自动通过；高后果动作进入预览、人工确认、双人批准或延迟执行窗口。

第一层回答说“失败就重试”，第二层追问会问“上一次到底成功没有”。网络超时不代表外部系统没有完成动作，因此工具调用要带幂等键、外部请求标识和可查询状态。重试之前先判定结果未知、明确失败还是已经成功，避免重复扣款或重复发送。

回滚也必须拆成三类：尚未提交的本地状态可以丢弃；支持撤销的外部系统调用正式撤销接口；不可逆副作用只能进入补偿或人工处置。补发解释邮件、发起退款与恢复本地快照都不是“什么也没发生”，面试时主动承认这一点，比承诺万能回滚更可信。

失败状态不能只写成成功或失败

Agent 链路常同时经历模型调用、工具调用、审批等待和外部状态变化。一个布尔值无法区分“尚未执行”“执行中”“外部结果未知”“已产生部分副作用”“等待人工”“可安全重试”和“需要补偿”。状态不够细，恢复策略就只能靠猜。

可以把故障处理原则说成：先冻结进一步高风险动作，再确认最后一个有证据的状态，随后选择重试、补偿、降级或人工接管。恢复后不应从任务开头盲目重放，而是从经过验证的检查点继续，并再次校验策略和授权是否仍有效。

控制面还要保存失败原因与处置所有者。模型超时、工具拒绝、策略阻断和审批过期不是同一种错误，告警、用户提示和重试责任也不同。这样设计既减少循环重试，也避免把安全拒绝误报成基础设施故障。

多租户与故障追问考的是隔离和降级

面试官追问多租户时，不只是想听“每行带 tenant_id”。任务队列、缓存、凭证引用、工具连接池、日志查询、预算和人工审批入口都必须带明确租户边界。高风险 worker 可以进一步采用隔离运行环境，避免一个租户的工具结果进入另一个租户上下文。

控制面自身故障时，安全默认值比高可用口号更重要。策略服务不可用，不能自动变成全部放行；审计写入失败，高后果动作不应继续制造不可追踪副作用。系统可以让只读能力降级运行，把写操作暂停到可验证状态恢复。

容量追问则要区分排队与权限。任务积压可以通过优先级、配额和背压治理，但不能因为超时就绕过审批。对重复失败的任务设置尝试预算与断路条件，也比无限自治循环更稳。

审计凭证要说明谁批准、做了什么、结果如何

一份可用的审计凭证应串起任务版本、发起身份、策略版本、授权范围、审批事件、模型与工具调用标识、参数摘要、时间、结果、状态变化和后续处置。它的目标是回答“第一次偏离在哪里、谁允许了什么、外部系统实际发生了什么”。

但记录越多不等于越可观测。秘密、完整个人数据和无关提示内容应默认最小化或脱敏，并通过访问控制、保留期和审计查询权限限制使用。Trace 能重建可见事件，不能证明模型内部为什么这样想，也不能凭相关顺序宣称因果。

Agent 可观测性面试指南进一步拆解了 span、工具调用、状态变化与失败凭证如何连接。控制平面则负责保证这些事件有统一任务身份、策略版本和处置结果，避免留下彼此对不上的日志碎片。

OpenAI 的 Agent 构建与 Agents SDK 文档强调 instructions、tools、guardrails 和 human intervention 等构件；NIST AI RMF 1.0 是自愿采用且在本文发布时正在修订的风险管理框架。它们可以支持设计判断，但都不替你规定唯一控制平面产品。真正高分的收口是：每项关键能力都有单一所有者、可见失败状态、最小权限和不可逆动作的现实处置路径。