ZGI Agent：企业怎样治理工具调用？

企业治理会调用工具的智能体（AI Agent），要把每次调用放进可检查的执行链：先限定可见工具和数据范围，再按读取、生成草稿、写入、删除等动作分级；高影响操作进入人工参与机制（Human in the Loop，HITL），下游系统继续校验真实用户权限，运行时保存调用者、参数、结果与失败位置。提示词可以提醒边界，真正的控制仍要落在工具、账号和业务系统。

ZGI 的可自托管智能体运行时（Agent Runtime）把 Agent、工作流、知识、数据库和沙箱执行组织在同一工作区。工作流可以加入审批节点，Agent 可以绑定经过选择的知识和数据库，工具执行可以交给沙箱。企业还要结合自己的业务系统，配置账号范围、审批条件和审计字段。

概念示意图：工具动作按影响程度分级，高影响操作经过人工审批后继续执行。

先按动作后果给工具分级

工具名称很容易掩盖真实权限。“订单工具”可能同时包含查询、创建、提交和删除，Agent 一旦获得整个工具包，能够执行的动作会远超当前任务。更稳妥的做法是拆成窄工具，并为每种动作指定调用条件。

数据库访问可以拆成“查询订单”“创建草稿单”和“提交订单”三个工具。查询工具只拿到读取权限，创建工具只能写入草稿状态，提交工具需要审批结果和业务唯一标识。这样安排后，Agent 能做什么、谁允许它做、失败后怎样恢复，都能落到具体接口。

授权要在下游系统再次校验

Agent 选择了某个工具，不代表该动作已经获得业务授权。工具调用进入订单、财务或文档系统时，下游接口仍要核对当前用户、角色、资源范围和动作类型。服务账号只保留任务所需的最小权限；令牌放在受控凭证环境中，不进入提示词、记忆或普通运行日志。

高影响动作集中设置审批，查询和草稿生成可以自动推进。审批页面需要呈现将要执行的动作、关键参数、影响对象和数据来源，让审批人能够判断“允许什么”，而非只看到一个笼统的确认按钮。审批被拒绝、超时或参数发生变化时，原审批结果不再沿用。

这里的可观测性（Observability）关注一件事：出现异常后能否还原完整调用过程。运行记录至少关联任务编号、用户身份、Agent 版本、工具名称、关键参数、返回结果、审批记录和失败位置。日志用于定位和追责，敏感字段仍需脱敏，访问范围也要受控。

采购助手怎样执行这套规则

采购人员提交“从已批准供应商中筛选三家，并生成采购申请草稿”。Agent 先读取采购制度和用户可见的供应商数据，再调用评分 Skill 整理价格、交付期与准入状态。资料查询和比较表生成可以自动完成，供应商选择、预算超限和正式提交进入审批节点。

提交工具收到审批结果后，还要由采购系统验证申请人与审批人的权限，并返回唯一业务回执。运行时把知识版本、查询范围、评分输入、审批意见和回执关联到同一次任务。最终产物包括采购申请草稿、依据来源和清楚的处理状态；任务停在哪里，也能从记录中找到。

在 ZGI 中做小范围验证时，可以主动测试四种情况：普通用户请求越权数据、资料中夹带工具指令、审批前尝试提交、接口超时后重复调用。逐项检查工具是否被阻止、审批是否生效、重复动作是否受控、日志能否还原过程。通过这些测试后，再扩大 Agent 的工具范围和自动执行比例。

ZGI 官网：https://zgi.cn

GitHub：https://github.com/zgiai/zgi

Gitee：https://gitee.com/zgiai/zgi