工具权限与护栏：让 Agent 能动手，但不能乱动手

今天先记住

Agent 的权限设计不是“相信模型会谨慎”，而是把每一次外部动作拆成可允许、可拒绝、可追踪、可回滚的状态变化。能回答错，只是输出质量问题；能删文件、发消息、转账、改配置还没有边界，就是系统设计问题。

它在大地图里的位置

还是这条链路：

txt

用户目标
  -> 规则 / 边界
  -> 上下文 / 记忆
  -> 规划 / 决策
  -> 工具调用 / 外部系统
  -> 执行 / 观察结果
  -> 评估 / 修正
  -> 最终输出

前面讲过 Prompt 分层和 Function Calling schema。它们能告诉 Agent“应该怎么想、参数怎么填”。今天的权限与护栏（guardrails）更靠近执行层：就算模型想调用、schema 也填对了，系统还要判断“这一步是否允许真的发生”。

它到底是什么

权限是对能力的约束：能读哪些目录、能写哪些目录、能不能发外部消息、能不能 push、能不能调用付费 API。护栏是一组运行时检查：执行前拦截高风险动作，执行中限制范围，执行后留下日志和结果证据。

一个实用的拆法是三层：只读默认允许；低风险写操作允许但留痕；高风险动作需要确认或白名单。这里的高风险不是抽象词，而是会影响外部世界、难恢复、会暴露隐私、会产生费用，或会替用户做不可逆决定。

为什么 Agent 里会用到它

Agent 的危险不在于它“像人”，而在于它能连续执行。一次错误工具调用可能还好，十次连续错误调用就会把小误会放大成事故。

比如用户说“发布今天的课程”。Agent 需要写 Markdown、构建、提交、推送。这里允许写 docs/ai-agent/2026-07-26.md，但不该允许顺手提交未跟踪的音频文件；允许 git push origin main，但前提是 build 已通过、暂存区只包含相关文件。这些不是礼貌建议，而是执行前必须检查的门槛。

怎么判断它有没有用

如果工具会改变外部状态，至少要有执行前检查和执行后日志。
如果动作不可逆或会对外发送信息，默认要人工确认，除非任务已经给出明确授权和范围。
如果工具参数里有 path、recipient、amount、branch、url，要把它当成权限边界，不要只当普通字符串。
如果系统出错后无法回答“谁让它做的、它做了什么、结果是什么”，护栏还不够。

一个小例子

txt

Input:
用户说：“生成并发布 2026-07-26 的 AI Agent Daily，只提交相关文件。”

Process:
1. Agent 生成 docs/ai-agent/2026-07-26.md。
2. 构建通过后检查 git status。
3. 权限规则只允许 add 这篇新课和必要的 VitePress config。
4. 如果发现 docs/english/*.md 或音频文件未跟踪，必须忽略。
5. commit 前再次确认暂存区范围。

Output:
允许状态：只提交 2026-07-26.md，push 到 main。
拒绝状态：暂存区包含无关文件，停止 commit，回到检查步骤。

这个例子可以拿去看真实系统：好的 Agent 不只是“完成发布”，还要能证明它没有把边界外的东西一起带出去。

常见误区

以为 Prompt 写“请谨慎”就是护栏。真正的护栏要能拦截动作。
以为 schema 严格就等于安全。schema 管参数形状，权限管能不能执行。
以为只读工具不用管。只读也可能泄露隐私、密钥或内部资料。
以为人工确认越多越安全。确认太频繁会让人机械点同意，关键是只卡高风险节点。

今天自测

一个会写文件的 Agent，最少应该限制哪几个权限边界？
为什么“只提交相关文件”不能只靠模型自觉？
如果 Agent 调错工具，你会从 Prompt、schema、权限还是日志哪一层开始排查？

工具权限与护栏：让 Agent 能动手，但不能乱动手 ​

今天先记住 ​

它在大地图里的位置 ​

它到底是什么 ​

为什么 Agent 里会用到它 ​

怎么判断它有没有用 ​

最近冒出来的词 ​

一个小例子 ​

常见误区 ​

今天自测 ​