系统整合 · 实作指南
为代理可呼叫的每个工具订立合约
用范围明确的工具介面，将自然语言转成受限制的操作。
避免万能操作入口
假设服务台代理只有一个更新系统工具，接受任意网址与内容。初期看来省工，却把目的地、权限和副作用全部隐藏。建议改成提出请求分派、读取已批准状态等业务工具，清楚写明可接触哪些纪录、会产生什麽後果。与其要求模型小心行事，范围明确的工具更容易测试，也较能让客户知道系统实际可以做什麽。
列出执行前必查事项
每个工具记录必要参数、允许值、身份脉络、前置条件、逾时与重试行为。未预期栏位应拒绝，不可直接转交下游 API。公司和呼叫者身份来自已验证脉络，不由生成文字指定。结果也要结构化，分清拒绝、无效、暂时失败与完成。下游错误讯息仍是资料，不能因为看似系统回应，就变成要求增加权限的新指令。
流程一览
用故障清单验证合约
验收可测试缺少负责人、越权公司、过时版本、无效状态值，以及提交後逾时。JSON 格式正确并不等於业务操作有效。以分派工具为例，要检查目的员工仍属於该客户，并有权阅读相关纪录。OWASP 授权指引提供每次请求检查存取的背景；本文把它转为可执行的测试，让合约不是文件上的愿望。
限制工具也要管理版本
工具含义改变时要管理版本，不只是改栏位名称才处理。旧队列任务应有相容执行器，否则清楚标示需要迁移并停止。支援人员要有允许与拒绝操作的例子。工具太碎也会增加维护成本，因此按稳定业务目的分组，而不是每个按钮都建一个工具。目标是把权限收窄到可理解、可验证的范围，而非堆积一份庞大工具目录。
交付中的工具合约卡
交付时每个工具有一张合约卡，说明用途、允许纪录、审核人和失败路径，技术参数结构与卡片共用版本编号。操作人员便能判断新用途是否仍在原范围，还是需要另行审查能力。卡片也应列出明确不做的操作，减少使用者因名称太广而误解；这不是限制销售，而是让承诺可被实际系统支持。
来源与延伸阅读
编辑原则
本系列以 AI 辅助原创撰写，并对照连结的公开来源。实作建议与假设情境属编辑分析，并非客户实绩。来源发布日期及产品细节可能与本系列整理日期不同。