AI Agent 工具调用审计：别让智能体在生产环境裸奔

AI Agent 最危险的地方，不是它会说错话，而是它能调用工具。读文件、查数据库、发请求、改配置、触发流水线，这些动作一旦进入生产环境，就不能只靠 Prompt 约束。Prompt 是软约束，审计和权限才是硬边界。别整虚的，Agent 上生产第一件事就是把工具调用管起来。

一个可上线的 Agent 系统，必须能回答四个问题：谁让它调用了工具？调用了哪个工具？输入输出是什么？失败或越权时谁来兜底？

一、工具调用要走统一网关

flowchart TD
  A[Agent Planner] --> B[Tool Gateway]
  B --> C[Policy Check]
  C --> D[Audit Log]
  C --> E{Allowed}
  E -->|yes| F[Tool Executor]
  E -->|no| G[Reject With Reason]
  F --> H[Result Filter]
  H --> A

不要让 Agent 直接连各种内部接口。工具网关负责鉴权、参数校验、审计、限流和结果脱敏。这样即使模型层换了，安全边界也不会跟着重写。

二、审计日志要记录决策上下文

只记录“调用了 search_tool”没用。排查事故时，需要知道调用原因、用户会话、工具参数、策略版本、返回摘要和耗时。

{
  "trace_id": "agt-20260703-001",
  "user_id": "u_123",
  "agent_id": "ops_assistant",
  "tool": "query_deploy_status",
  "reason": "用户询问最近一次灰度状态",
  "policy_version": "2026-07-03",
  "input_hash": "sha256:...",
  "duration_ms": 83,
  "result_level": "summary_only"
}

敏感输入不要原文全量落盘，可以做 hash、摘要或分级存储。但关键上下文必须有，否则线上问题只能靠猜。

三、权限要按动作拆，不按工具名粗放授权

同一个工具可能有读和写两类动作。比如 Kubernetes 工具，查看 Pod 状态和删除 Pod 完全不是一个风险等级。权限模型要细到 action、resource、scope。

tool_policy:
  tool: kubernetes
  allowed_actions:
    - get_pod
    - list_events
  denied_actions:
    - delete_pod
    - patch_deployment
  scope:
    namespace: "staging"
  require_human_approval:
    - restart_workload

生产环境里，Agent 默认只读。写操作、重启、扩缩容、发布回滚必须有人工确认或审批链。智能体可以建议，不能偷偷动手。

四、失败路径要比成功路径更认真

工具调用失败时，Agent 容易编一个看起来合理的解释。工程上必须把失败明确返回给模型，并限制它继续猜。

tool_error_contract
├── error_code: stable and typed
├── retryable: true or false
├── user_message: safe summary
├── debug_ref: audit trace id
└── next_allowed_actions: retry, ask_user, escalate

如果工具超时，就告诉用户超时；如果权限不足，就提示需要授权；如果参数非法，就回到澄清问题。别让模型把工具失败包装成“系统状态正常”。

五、总结

AI Agent 上生产，工具调用审计是底线。统一工具网关、记录决策上下文、按动作拆权限、明确失败契约，才能让 Agent 有能力但不失控。

真正可靠的 Agent，不是永远答得漂亮，而是每一次工具动作都有边界、有记录、有责任人。没有这套东西，就别让它碰生产系统。