使用 OpenAI 兼容 API 和 JSON Schema 验证构建 n8n 人工审批工作流

决策重点：审批操作，而不只是审批提取结果

对于发票、支持工单、表单和入站请求而言，风险通常不在于提取字段，而在于后续发生的事情：创建客户记录、修改状态、发送外部消息或删除数据。

因此，稳健的 n8n 设计应包含三个关卡：

1. 提取： OpenAI 兼容 API 返回结构化数据。
2. 验证： n8n 检查数据是否符合 JSON Schema。
3. 审批： n8n AI Agent 只有在人员批准后，才能调用具有重要影响的工具。

这样既能避免格式错误的数据到达审核者，也能将已批准的执行与模型输出分离开来。

OneMux 通过一个 OpenAI 兼容 API 提供对领先 AI 模型的访问。如果端点和所选模型的文档明确支持 n8n 配置所需的请求格式和参数，你可以将其用作模型访问路径。本文不声称 OneMux 与 n8n 的集成已经过测试。

前置条件

你需要：

• 一个能够访问 HTTP Request、Code 以及（适用时）AI Agent 节点的 n8n 实例。
• 一个由 n8n 设置支持的审批渠道，例如 n8n Chat、Slack、Telegram、电子邮件或其他有文档说明的渠道。
• 一个 OpenAI 兼容 API 的访问权限。如果使用 OneMux，请先阅读 OneMux 快速入门，并在 OneMux 文档 中确认当前端点、身份验证方式、模型标识符和支持的请求参数。
• 一个用于描述待提取对象的 JSON Schema。
• 一个不应在没有人工审核的情况下运行的目标工具，例如 CRM 更新工具或消息发送操作。

不要假设每个 OpenAI 兼容端点都支持所有结构化输出功能。请确认其是否支持 response_format、JSON Schema、工具调用，以及你选择的具体模型。OneMux 模型目录可以帮助你查看可用的模型选项，但它本身不能证明某个特定 n8n 节点配置一定受到支持。

推荐的 n8n 工作流

一个实用的工作流可以使用以下节点：

1. Webhook 或其他触发器接收源文本。
2. HTTP Request 将文本发送到兼容模型端点。
3. Code 解析并验证返回的对象。
4. IF 将无效结果路由到错误处理或人工修正路径。
5. AI Agent 接收已验证的对象，并获得一个具有重要影响的工具。
6. 人工审核 在该工具运行前暂停工作流。
7. 已批准的工具 写入记录或发送消息。

提取请求应只要求工作流需要的字段。以下是一个支持请求的简化示例 Schema：

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "additionalProperties": false,
  "required": ["category", "priority", "summary", "customer_email"],
  "properties": {
    "category": {
      "type": "string",
      "enum": ["billing", "technical", "account", "other"]
    },
    "priority": {
      "type": "string",
      "enum": ["low", "normal", "high", "urgent"]
    },
    "summary": {
      "type": "string",
      "minLength": 1
    },
    "customer_email": {
      "type": "string",
      "format": "email"
    }
  }
}

配置 OpenAI 兼容请求

在 HTTP Request 节点中，使用提供商文档中的基础 URL 和身份验证说明。除非已针对你的账户和区域完成验证，否则不要硬编码特定提供商的 URL。

以下请求结构仅用于说明。是否接受 response_format 及其 JSON Schema 结构，取决于你选择的端点、模型和 n8n 配置。

{
  "model": "YOUR_DOCUMENTED_MODEL_ID",
  "messages": [
    {
      "role": "system",
      "content": "Extract the requested fields. Do not guess missing values. Return only an object matching the supplied schema."
    },
    {
      "role": "user",
      "content": "{{$json.source_text}}"
    }
  ],
  "temperature": 0,
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "support_request",
      "strict": true,
      "schema": {
        "type": "object",
        "additionalProperties": false,
        "required": ["category", "priority", "summary", "customer_email"],
        "properties": {
          "category": {"type": "string"},
          "priority": {"type": "string"},
          "summary": {"type": "string"},
          "customer_email": {"type": "string"}
        }
      }
    }
  }
}

示例特意使用了占位模型 ID。请选择文档明确说明与所选端点兼容的模型。如果无法使用严格的 JSON Schema 输出，只有在你的验证路径能够安全拒绝不符合要求的响应时，才使用受支持的 JSON 模式。JSON 模式本身不等同于 Schema 验证。

在执行前验证响应

不同提供商可能会将生成的内容放在不同字段中。在编写解析器前，先在 n8n 中检查一次真实响应。以下 Code 节点假设模型在 message.content 中返回了 JSON 字符串；请根据实际收到的响应调整路径。

const raw = $json.choices?.[0]?.message?.content;

if (typeof raw !== 'string') {
  throw new Error('Model response did not contain message.content as a string');
}

let extracted;
try {
  extracted = JSON.parse(raw);
} catch (error) {
  throw new Error('Model returned invalid JSON');
}

const required = ['category', 'priority', 'summary', 'customer_email'];
const missing = required.filter((key) => extracted[key] === undefined || extracted[key] === '');

const validCategory = ['billing', 'technical', 'account', 'other'].includes(extracted.category);
const validPriority = ['low', 'normal', 'high', 'urgent'].includes(extracted.priority);
const validEmail = typeof extracted.customer_email === 'string' &&
  /^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$/.test(extracted.customer_email);

if (missing.length || !validCategory || !validPriority || !validEmail) {
  throw new Error('Extracted object failed application validation');
}

return [{ json: { extracted } }];

在生产环境中，如果你的 n8n 部署允许，请使用维护中的 JSON Schema 验证器替换这个轻量级检查。请求中的 Schema 与验证阶段执行的 Schema 应一起进行版本管理。如果下游系统需要区分不同版本，请在输出中加入 Schema 版本。

为 AI Agent 工具添加人工审批

将已验证的对象作为 AI Agent 的上下文。为 Agent 提供范围明确的工具，例如 CreateSupportTicket，而不是广泛的数据库访问权限。在 AI Agent 的 Tools Panel 中，为该选定工具配置人工审核。

n8n 文档说明，当 Agent 尝试调用需要审核的工具时，工作流会暂停。审核者可以批准调用，使工具能够使用拟议输入执行；也可以拒绝调用，从而取消该操作。n8n 支持多种审批渠道，包括内置聊天界面，以及 Slack、Telegram、Discord、Teams、电子邮件、WhatsApp、Google Chat 和 Outlook email 等集成。有关当前设置步骤和渠道详情，请参阅官方 n8n 人在回路文档。

有用的审批消息应展示拟执行的操作和参数：

The AI wants to use {{ $tool.name }} with the following parameters:
{{ JSON.stringify($tool.parameters, null, 2) }}

源文档为此审核上下文指定了 $tool.name 和 $tool.parameters。请保持消息易读；如果审核者需要更多上下文，也应包含原始请求或工单引用。

你的 Agent 系统提示词还应说明审核行为：

The CreateSupportTicket tool requires human approval. If approval is denied, do not retry automatically. Tell the user that the action was not completed and explain what information or correction is needed.

限制与故障排查

模型返回 Markdown 或额外文本

检查端点是否支持你发送的结构化输出参数。如果不支持，请移除不受支持的参数、收紧指令，并将 Code 节点验证保留为硬性关卡。绝不要将未经验证的对象发送给写入工具。

n8n 找不到预期的响应字段

检查 HTTP Request 的输出并更新解析器。OpenAI 兼容 API 可能采用相似的请求约定，但在响应细节和支持的参数方面存在差异。

审批请求过于模糊

使用范围明确的工具，并在审批消息中包含 $tool.name 和 $tool.parameters。不要让审核者批准诸如“处理此请求”这样的不透明指令。

被拒绝的工具调用导致循环

在 Agent 系统提示词中加入明确的拒绝处理行为，并配置工作流，使拒绝结束操作路径或将请求路由到澄清环节。n8n 文档建议说明哪些工具需要审批，以及 Agent 应如何响应拒绝。

审核者批准了错误数据

符合 Schema 并不能证明语义正确。应同时展示源文本片段、提取出的字段和拟执行的操作。对于影响较大的工作流，应要求审核者独立确认敏感字段。

结论

结构化提取最安全的 n8n 模式不是“让模型直接写入”。应先将内容提取为受约束的对象，验证该对象，然后在会改变外部世界的工具前加入人工审批。OpenAI 兼容 API 可以简化模型访问，而 n8n 则提供编排和审批控制。使用 OneMux 时，请采用文档中说明的兼容端点和模型参数，在你自己的环境中验证配置，并将不受支持的结构化输出功能视为应停止流程或回退到单独验证的响应路径的信号。