Dify 工作流或 Agent 接入 DeepAI API 中转站 后，普通聊天请求能通，并不代表 Tool Calling 一定稳定。最近 Dify GitHub 上有一个很典型的 Issue：同一个自定义工具在 Gemini、Anthropic、OpenAI Compatible 插件里可以运行，但切到 OpenAI 插件后，工具调用阶段直接报 invalid_function_parameters，错误信息是 array schema missing items。
items，否则容易在 Function Calling 阶段被严格校验拦下。问题背景：为什么只有 OpenAI 插件会报错
这个问题来自 Dify Issue #32894。用户环境是 Dify 1.11.4 自托管 Docker，创建了一个图片转 PDF 的自定义工具，工具参数里包含数组类型。运行时 OpenAI 插件返回：
array schema missing items., 'type': 'invalid_request_error', 'param': 'tools[3].function.parameters', 'code': 'invalid_function_parameters'
这里最容易误判的地方是：同一工具在 Google Gemini 插件、Anthropic 插件和 OpenAI Compatible 插件里都能跑。于是很多人会先去怀疑 API Key、Base URL、模型 ID 或中转站路由。但从报错字段看，真正被拒绝的是 tools[3].function.parameters，也就是发给模型的工具函数 JSON Schema 不符合严格校验要求。
根因：array 类型必须写 items
在 JSON Schema 里，type: array 只是说明参数是数组，但还没有说明数组元素是什么类型。对普通配置界面来说，这个省略有时不会马上暴露；对 Function Calling 来说，模型服务需要根据 schema 生成参数，所以严格实现会要求每一个数组节点都带上 items。
错误写法通常长这样：
{
"type": "object",
"properties": {
"images": {
"type": "array",
"description": "需要转换为 PDF 的图片 URL 列表"
}
},
"required": ["images"]
}
正确写法需要给数组补上元素定义：
{
"type": "object",
"properties": {
"images": {
"type": "array",
"items": {
"type": "string"
},
"description": "需要转换为 PDF 的图片 URL 列表"
}
},
"required": ["images"]
}
如果是二维数组、对象数组，或数组嵌套在对象属性里，也要逐层声明。例如对象数组至少要写 items.type: object 和 items.properties；字符串数组则写 items.type: string。不要只在最外层补一个字段就结束。
Dify 侧应该怎么修
- 打开 Dify 的自定义工具配置，找到 Parameters 或 OpenAPI Schema。
- 搜索所有
"type": "array"或 YAML 里的type: array。 - 逐个确认是否存在
items。 - 根据真实业务补元素类型：URL 列表用
string，ID 列表可用string或integer，结构化项用object。 - 保存工具后重新发布应用，再跑一次完整的 Agent 或 Workflow。
如果你的工具是从 OpenAPI 文档导入的，不要只看接口能不能用，还要检查 OpenAPI 里的数组 schema 是否完整。很多内部接口文档只给前端或后端人读，数组元素类型写得比较松；一旦进入 LLM Tool Calling，就会被模型服务当成函数签名严格校验。
关联 PR：自动补全 items，但不要完全依赖自动修复
后续有人提交了 Dify PR #33137，思路是在 Dify 转换工具参数时递归扫描 JSON Schema：只要发现 type: array 却没有 items，就补一个默认的 {"type":"string"}。PR 里还提到会覆盖扁平数组、嵌套数组、对象属性中的数组和非变异处理等测试场景。
这个方向对兼容性有帮助，但站长和开发者仍然建议在工具配置源头修好 schema。原因很简单：默认补 string 只是保守兜底，并不一定符合你的业务。如果你真实需要的是对象数组，自动补成字符串数组可能会让模型生成“能通过校验但业务不可用”的参数。
DeepAI API 中转站场景下怎么定位边界
使用 DeepAI API 中转站时，可以把排查分成三层：
- 连接层：Dify 到
https://api.deepai.wang/v1是否能认证、路由、返回模型响应。 - 协议层：请求是否符合 OpenAI-compatible Chat Completions 与 Tool Calling 格式。
- Schema 层：
tools[].function.parameters是否是有效、完整、可被目标模型服务接受的 JSON Schema。
array schema missing items 属于第三层。中转站可以帮助统一 Key、模型路由、日志、成本统计和兼容入口，但不应该替上游工具“猜测”业务 schema。最稳的做法是：Dify 工具配置里显式写完整；中转站日志里保留可排查的请求摘要；上线前用一条最小工具调用做回归测试。
推荐的最小化测试流程
- 先用不带工具的普通对话测试 DeepAI API 中转站连接是否正常。
- 创建一个只有一个字符串参数的测试工具，确认 Dify Tool Calling 链路可用。
- 再加入一个字符串数组参数，并显式写
items.type: string。 - 观察 Dify 运行日志和中转站后台日志，确认工具调用请求、工具结果回传和最终回答都完成。
- 最后再替换成真实业务工具，逐步加入对象数组、可选字段和复杂嵌套。
如果最小工具能跑，真实工具失败，重点就不是 Base URL，而是工具 schema、参数描述、required 字段、枚举值或返回结构。如果最小工具也失败，再看模型是否支持 tools、是否误用了 Responses API 与 Chat Completions API 的字段、以及 Dify 插件版本是否匹配。
常见坑位
- 只补第一层 array：嵌套数组里的每一层都需要
items。 - 把对象数组写成字符串数组：能过校验不等于业务正确，复杂参数要写
items.properties。 - 复制 OpenAPI 文档但没校验：很多 OpenAPI 文档对内部调用足够，对 LLM 工具调用不够严格。
- 把中转站当成 schema 修复器：API 中转站更适合做转发、认证、日志、限流和模型兼容，不适合替业务工具推断参数类型。
- 只测插件凭据：Dify 的“凭据测试成功”通常只能说明连接可用，不能证明 Agent 的工具 roundtrip 可用。
给站长和开发者的上线建议
如果你准备用 Dify、n8n、Cherry Studio、Claude Code 或其他 Agent 工具统一接入 DeepAI API 中转站，建议把 Tool Calling 当成独立验收项：普通聊天、流式输出、多轮上下文、工具调用、工具结果回传、异常重试分别测试。尤其是要把工具 schema 存入版本管理，避免后续在界面里改坏参数定义却没有记录。
对生产环境来说，DeepAI API 中转站的价值不只是“换一个 Base URL”。它能让不同客户端使用统一入口，集中管理模型、额度、日志和访问策略。当某个 Agent 报错时，你可以先判断请求是否到达中转站，再判断目标模型是否拒绝，最后回到 Dify 工具 schema 排查。这种分层定位，比盲目更换模型或 Key 高效得多。
参考资料
- Dify Issue #32894：Array schema missing items error when using OpenAI plugin with Tool
- Dify PR #33137：auto-complete missing items in array tool parameter schemas
- Dify 接入 DeepAI API 中转站 404/401 与 Tool Calling 排查
- DeepAI API 中转站教程导航
总结
Dify 接入 DeepAI API 中转站时，如果 Tool Calling 报 array schema missing items，优先检查自定义工具或 OpenAPI 导入工具的 JSON Schema。凡是 type: array，都要明确写出 items；凡是对象数组，都要进一步写清对象属性。普通聊天成功、凭据测试成功、其他插件宽松通过，都不能替代 Function Calling 的严格 schema 校验。把工具参数定义好，再结合 DeepAI API 中转站的统一日志和路由能力，Agent 工作流才更容易稳定上线。
