工具越多，智能体完成的任务未必越多。名称相近、职责重叠或输入要求含糊时，模型容易选错工具，也可能反复调用同一能力。排查这类问题，需要同时检查候选范围、Skill 边界、参数契约和停止条件，不能只改提示词。
ZGI 将技能（Skill）、工具（Tool）和智能体运行时（Agent Runtime）放在同一套执行体系里组织。Skill 负责描述一类任务怎样完成，可以引用脚本和辅助文件；Tool 承接数据库查询、接口请求、文件处理等具体动作。两者分开后，团队更容易控制模型当前可以选择什么，以及每一步实际执行了什么。
工具为什么会被选错
模型选择工具时，通常会参考名称、说明、参数和当前上下文。如果多个工具都写着“查询数据”，模型很难判断该查客户资料、订单状态还是知识库。工具说明写得很长也会带来麻烦，关键限制埋在段落中，模型可能抓住了功能，却漏掉使用条件。
候选集合过大同样常见。一个客服任务只需要订单查询和退款规则，运行时却同时提供邮件发送、数据库写入、网页抓取和报表生成。无关能力进入上下文后，会增加选择干扰，也扩大误操作范围。
| 检查位置 | 常见问题 | 调整方向 |
|---|---|---|
| 候选范围 | 当前任务看到太多无关工具 | 按任务开放必要能力 |
| 职责边界 | 多个工具处理相近动作 | 拆清对象、动作和适用条件 |
| 输入契约 | 参数名称含糊或允许随意填写 | 明确类型、必填项和格式 |
| 停止条件 | 失败后持续尝试或重复调用 | 设定次数、超时和退出结果 |
先划 Skill 边界，再写工具说明
一个 Skill 最好对应一类可验收的任务，例如“查询订单并整理当前状态”。它可以调用订单查询 Tool，也可以规定缺少订单号时先向用户补问。任务完成后，应交付固定结构的结果，并在查不到订单、接口超时或用户取消时结束。
边界过大的 Skill 往往写成“处理全部售后问题”。这类描述把查询、判断、通知和数据修改挤在一起，模型很难稳定决定下一步。更实用的拆法围绕业务产物展开：订单状态查询交付一份状态结果；退款材料检查交付缺失项；退款申请提交则单独受权限和审批控制。
Tool 的说明需要更窄。名称直接写动作和对象，参数只保留执行所需字段，返回值保持稳定。涉及写入、发送和删除的动作，还要与只读查询分开，避免模型把“获取信息”和“改变业务状态”当成同一能力。
用执行记录定位误选发生在哪一步
只看最终回答，很难分清模型选错了工具，还是工具返回后被错误理解。ZGI 的 Skill 运行循环会保留 Skill 轨迹和结构化工具载荷，可用于沿执行顺序检查：当时有哪些候选能力，模型选择了哪一个，传入参数是什么，工具返回了什么，随后为何继续或停止。
这些记录也能帮助团队判断该改哪里。选择阶段出错，先收窄候选集合和描述；参数阶段出错，补充字段约束与示例；工具已经返回正确结果，后续仍重复调用，需要检查终止条件和结果状态。不同问题落到不同位置，修改提示词才不会成为唯一手段。
上线前用失败样本验收
测试时不要只准备信息完整的标准问题。加入缺少关键字段、名称相近、无权限、接口超时和查询无结果的样本，再观察 Skill 能否选中正确工具、补齐必要输入，并在无法继续时给出明确状态。
一条实用的验收线可以这样定：任务入口只提供必要能力；每个 Tool 的对象和动作可以从名称看懂；输入输出能够被程序校验；高风险动作有单独权限；执行记录可以还原选择过程。工具继续增加时，这套边界比持续加长提示词更容易维护。
GitHub：github.com/zgiai/zgi
Gitee：gitee.com/zgiai/zgi
