Agent 接入的工具越多，越需要同时控制三件事：工具说明是否能区分、权限是否跟着任务缩小、写操作是否有确认与回执。只把接口全部交给模型选择，工具名称相近时会选错，参数含糊时会误调用，高权限账号还会放大一次判断失误。

ZGI 把工具执行、Skill、工作流和 Sandbox 放在 Agent Runtime 中统一承接。它能提供一套组织入口，真正的风险控制仍要落实到每个工具的描述、凭据、参数和执行边界。

选错工具往往从说明开始

“查询客户”和“搜索联系人”在人看来用途不同，模型只看到相近名字时很容易混淆。工具描述需要写出动作、对象、输入和影响。例如，“按客户编号读取 CRM 基本资料，只读，不返回付款信息”比“查询客户工具”更容易判断。

同一工具不要承担过多动作。把查询、创建、修改和删除塞进一个万能接口，模型既要选工具，又要决定操作类型，错误空间会扩大。按风险拆开后，只读工具可以自动调用，写入工具单独增加检查。

参数也要限制范围。收件人、文件路径、数据库表名和时间区间，能用枚举、格式校验或白名单约束的地方，不要完全依赖自然语言生成。参数不完整时返回缺少什么，让 Agent 补充，不能用默认值悄悄执行。

权限跟着任务走

很多越权并非模型主动寻找漏洞，根源在于工具背后的服务账号权限太大。一个只负责生成销售周报的 Agent，如果使用能修改全部客户记录的账号，任何误调用都可能留下真实后果。

更稳妥的做法是按 Agent、任务或用户映射权限。读取知识只给指定资料库，查询数据库只开放需要的表和字段，文件操作只允许进入任务目录。用户自身没有权限的数据，也不应通过 Agent 绕过去。

临时任务还可以使用短时凭据。任务结束后凭据失效，减少长期密钥泄露的影响。日志里只记录必要的凭据标识，不能把密钥和完整请求头原样保存。

写操作需要多一层确认

发送消息、创建工单、修改数据和删除文件都属于会改变外部状态的动作。Agent 可以准备参数和预览结果，真正执行前再经过规则或人工确认。确认页面应展示对象、动作、影响范围和关键参数。

确认完成后还要保存工具回执。外部系统返回的消息 ID、工单号或记录版本，能证明动作已经发生。任务中断后先按回执查询状态，可以避免重复发送和重复创建。

高风险动作可以直接从 Agent 的自动工具集合中移出，只允许固定工作流调用。Agent 负责理解需求和生成建议，工作流负责审批与执行，边界会更清楚。

工具测试要覆盖相似和冲突输入

测试时不要只给标准问题。准备名称相近的工具、缺少参数的请求、用户无权访问的资料、同时包含两个动作的指令，再观察 Agent 会选择哪个工具、是否会停下来询问。

还要检查工具失败后的行为。超时后会不会无限重试，返回空结果时会不会编造答案，写入成功但回执丢失时会不会再次执行。每一种情况都应有明确状态。

ZGI 的公开仓库提供 Runtime Skill、工作流、Runner 与 Sandbox，可以把文件、报表、数据库和工作流调用组织成可复用能力。接入具体工具时，团队仍需自行核对最小权限、参数约束、确认节点和外部回执。这些内容决定了工具数量增加后，系统是否还保持可控。

整理现有工具时，可以先做一张清单：名称是否容易区分，账号能访问什么，调用会不会改变数据，失败后如何查证。四列填不完整的工具，暂时不要交给 Agent 自动执行。

GitHub：GitHub - zgiai/zgi: ZGI is an open-source platform for building AI applications. Its intuitive interface combines workflow design, agent orchestration, dataset management, and model integration—allowing you to quickly move from prototype to production. · GitHub

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