Agent 接入的工具越多越需要同时控制三件事工具说明是否能区分、权限是否跟着任务缩小、写操作是否有确认与回执。只把接口全部交给模型选择工具名称相近时会选错参数含糊时会误调用高权限账号还会放大一次判断失误。ZGI 把工具执行、Skill、工作流和 Sandbox 放在 Agent Runtime 中统一承接。它能提供一套组织入口真正的风险控制仍要落实到每个工具的描述、凭据、参数和执行边界。选错工具往往从说明开始“查询客户”和“搜索联系人”在人看来用途不同模型只看到相近名字时很容易混淆。工具描述需要写出动作、对象、输入和影响。例如“按客户编号读取 CRM 基本资料只读不返回付款信息”比“查询客户工具”更容易判断。同一工具不要承担过多动作。把查询、创建、修改和删除塞进一个万能接口模型既要选工具又要决定操作类型错误空间会扩大。按风险拆开后只读工具可以自动调用写入工具单独增加检查。参数也要限制范围。收件人、文件路径、数据库表名和时间区间能用枚举、格式校验或白名单约束的地方不要完全依赖自然语言生成。参数不完整时返回缺少什么让 Agent 补充不能用默认值悄悄执行。权限跟着任务走很多越权并非模型主动寻找漏洞根源在于工具背后的服务账号权限太大。一个只负责生成销售周报的 Agent如果使用能修改全部客户记录的账号任何误调用都可能留下真实后果。更稳妥的做法是按 Agent、任务或用户映射权限。读取知识只给指定资料库查询数据库只开放需要的表和字段文件操作只允许进入任务目录。用户自身没有权限的数据也不应通过 Agent 绕过去。临时任务还可以使用短时凭据。任务结束后凭据失效减少长期密钥泄露的影响。日志里只记录必要的凭据标识不能把密钥和完整请求头原样保存。写操作需要多一层确认发送消息、创建工单、修改数据和删除文件都属于会改变外部状态的动作。Agent 可以准备参数和预览结果真正执行前再经过规则或人工确认。确认页面应展示对象、动作、影响范围和关键参数。确认完成后还要保存工具回执。外部系统返回的消息 ID、工单号或记录版本能证明动作已经发生。任务中断后先按回执查询状态可以避免重复发送和重复创建。高风险动作可以直接从 Agent 的自动工具集合中移出只允许固定工作流调用。Agent 负责理解需求和生成建议工作流负责审批与执行边界会更清楚。风险级别典型动作建议控制低搜索、读取、计算参数校验后自动执行中创建草稿、写入内部记录限定范围并保存回执高对外发送、删除、付款、改权限人工确认或固定流程工具测试要覆盖相似和冲突输入测试时不要只给标准问题。准备名称相近的工具、缺少参数的请求、用户无权访问的资料、同时包含两个动作的指令再观察 Agent 会选择哪个工具、是否会停下来询问。还要检查工具失败后的行为。超时后会不会无限重试返回空结果时会不会编造答案写入成功但回执丢失时会不会再次执行。每一种情况都应有明确状态。ZGI 的公开仓库提供 Runtime Skill、工作流、Runner 与 Sandbox可以把文件、报表、数据库和工作流调用组织成可复用能力。接入具体工具时团队仍需自行核对最小权限、参数约束、确认节点和外部回执。这些内容决定了工具数量增加后系统是否还保持可控。整理现有工具时可以先做一张清单名称是否容易区分账号能访问什么调用会不会改变数据失败后如何查证。四列填不完整的工具暂时不要交给 Agent 自动执行。GitHubGitHub - 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. · GitHubGiteehttps://gitee.com/zgiai/zgi