给 Agent 接一个附件检查工具，接口看起来很简单：传入 attachment_id，返回照片、发票或签收凭证的检查结果。工具说明写着“字符串、必填”，再补一句“编号来自附件列表”，似乎已经把使用方式交代清楚了。
接着会遇到一个很具体的问题：模型传来一个空值，系统究竟在哪一层拒绝？如果传来另一个订单的附件编号，又是谁负责发现对象错了？
只看工具定义，很容易把这些问题都归到“Schema 会校验”。真正沿执行链走一遍，会发现这里有几种不同的承诺：模型被告知该怎么填，程序检查了哪些字段，业务接口允许访问哪个对象。它们需要分别落实。
工具 Schema 能拦住什么，取决于声明了什么约束，以及执行路径实际检查了什么。 参数格式合格之后，仍然要回答对象和权限的问题。
“必填字符串”包含两件事
先看一套售后 Agent 的本地工具实现。它有两个相邻工具：attachment.list 根据订单号列出附件，attachment.inspect 根据附件编号读取检查结果。后一个工具只声明一个必填字符串字段，描述里说明编号应来自前一个工具。
这段描述有用。模型知道了先查列表、再检查具体附件的顺序，也知道不能拿订单号直接代替附件号。但描述本身不会执行查询，更不会自动把列表结果变成后续调用的访问范围。
再看“必填字符串”。必填要求字段出现，字符串要求字段的值属于指定类型。字段存在但值为 null，和整个字段没有传，是不同输入。空字符串又是另一种情况：它确实属于字符串，却未必是一个可用编号。
因此，单独声明字符串类型，并不会排除空字符串；需要非空时，还得增加长度等约束。至于编号是否存在，要查询数据才能知道。编号属于哪张订单，则要继续核对对象关系。
写定义时把这些条件放在一句话里，读起来很顺；运行时却要找到各自对应的检查。否则，“必填字符串”只是说明书上的完整表述，执行器可能只落实了其中一部分。
六个值都过了检查，后面的结果却不同
这套实现的 validate_args 方法，实际做了两项检查：必填字段有没有缺失，有没有传入未声明的字段。它没有继续读取字段的类型声明，也没有检查字符串长度。
把八组固定输入送过这条路径，区别很清楚。完全不传附件编号，得到“缺少 attachment_id”；传一个正常编号，再额外塞进 order_id，得到“未知参数 order_id”。这两种都在参数检查阶段被拒绝。
剩下六组输入通过了这一层：、空字符串、数字 、一个数组，以及两个真实存在于测试数据中的附件编号。这里的“通过”，只表示这个检查方法没有抛错，后续工具还要继续执行。
