第 18 章测验

对应章节：权限与 Human-in-the-Loop v05

共 8 题，答对率 ≥ 80% 即通过。请完成全部题目后点击「提交」。

Q1第 18 章给 Agent 加权限层的核心动机是什么？让模型更聪明，能自己判断工具该不该调用 Agent 的失败模式（over-eager、诚实失误、prompt injection）都指向「破坏性动作执行前要有人确认」；而「每个动作都问」会引发审批疲劳，所以按风险分级、只在高危动作上叫人因为 v04 的 Web 前端需要更多按钮让模型学会拒绝用户的要求

Q2三档风险 auto / suggest / approve 中，「suggest」档的正确语义是什么？和 approve 一样暂停等待，只是提示文案不同发一个 approval_request（risk=suggest）作为提示，但不等待、不调用审批回调、直接执行，也不产生审批决策自动执行但记录到审计日志拒绝执行，只告诉模型「这个工具危险」

Q3工具的 risk 档位放在哪里，为什么？放在模型的 system prompt 里，让模型自己遵守放在工具注册表的 spec 上（spec.risk，缺省 auto），且 modelTools() 输出给模型的列表里不含 risk——风险是策略，不给模型看，模型无法在 prompt 里「说服」策略层写死在 executeTool 的每个 if 分支里由用户在每次对话开始时手动指定

Q4approve 级工具调用在事件流里的正确顺序是？ approval_request → tool_call_start → approval_result → tool_result tool_call_start → approval_request → approval_result → tool_result tool_result → approval_request → approval_result → done tool_call_start → tool_result → approval_request → done

Q5人类拒绝了某个 approve 级调用，主循环接下来做什么？抛出异常中断整轮对话，让用户重来 [object Object] 静默忽略，不给模型任何反馈自动重试一次删除

Q6主循环如何获得审批决定？这体现哪条分层红线？直接 import cli.mjs 里的 readline，问终端直接 fetch 自己的 /approvals 接口通过注入的 getApproval(request) 异步回调（Promise<{ approved, reason? }>）拿到决定——core 不 import 任何界面；终端提问、HTTP 挂起表、测试脚本都是界面层对同一回调的实现让模型自己决定是否批准

Q7executeTool 里的「审批硬校验」和主循环的审批门是什么关系？两处重复代码，删一处即可纵深防御：交互门（loop 暂停问人）在前，硬门（executeTool 无匹配审批记录即拒绝）在后——绕过交互门的调用方也拿不到执行权；安全默认拒绝（fail closed）硬校验只在 approve 级工具数量超过 10 个时启用 executeTool 的校验是给测试用的，生产环境不走

Q8本章的「操作审计」落在哪里？两层都有：approval_result 事件进事件流（core 发出的审计「流」形态），服务端 GET /approvals 返回历史决策（requestId / 工具 / 参数 / 风险 / 决定 / 理由 / 时间）——「库」形态只存在模型的消息历史里只在终端打印一次只记录拒绝的决策，批准的不用记