เวิร์กโฟลว์อนุมัติโดยมนุษย์ใน n8n ด้วย OpenAI-Compatible API และการตรวจสอบ JSON Schema

การตัดสินใจ: อนุมัติการดำเนินการ ไม่ใช่แค่การดึงข้อมูล

สำหรับใบแจ้งหนี้ ทิกเก็ตฝ่ายสนับสนุน แบบฟอร์ม และคำขอขาเข้า ส่วนที่มีความเสี่ยงมักไม่ใช่การดึงฟิลด์ข้อมูล แต่คือสิ่งที่เกิดขึ้นหลังจากนั้น เช่น การสร้างระเบียนลูกค้า การเปลี่ยนสถานะ การส่งข้อความภายนอก หรือการลบข้อมูล

ดังนั้น การออกแบบ n8n ที่รัดกุมควรมีด่านตรวจสอบ 3 ขั้นตอน:

1. การดึงข้อมูล: OpenAI-Compatible API ส่งข้อมูลแบบมีโครงสร้างกลับมา
2. การตรวจสอบ: n8n ตรวจสอบว่าข้อมูลเป็นไปตาม JSON Schema
3. การอนุมัติ: n8n AI Agent สามารถเรียกใช้เครื่องมือที่มีผลกระทบได้ก็ต่อเมื่อมีบุคคลอนุมัติแล้ว

แนวทางนี้ช่วยป้องกันไม่ให้ข้อมูลที่มีรูปแบบไม่ถูกต้องไปถึงผู้ตรวจสอบ และแยกการดำเนินการที่ได้รับอนุมัติออกจากเอาต์พุตของโมเดล

OneMux ให้เข้าถึงโมเดล AI ชั้นนำผ่าน OpenAI-Compatible API เดียว คุณสามารถใช้ OneMux เป็นเส้นทางเข้าถึงโมเดลได้ หากเอนด์พอยต์และโมเดลที่เลือกมีเอกสารยืนยันว่ารองรับรูปแบบคำขอและพารามิเตอร์ที่การกำหนดค่า n8n ของคุณต้องใช้ บทความนี้ไม่ได้กล่าวอ้างว่าการผสานรวม OneMux และ n8n ได้รับการทดสอบแล้ว

ข้อกำหนดเบื้องต้น

คุณต้องมีสิ่งต่อไปนี้:

• อินสแตนซ์ n8n ที่เข้าถึงโหนด HTTP Request, Code และในกรณีที่เกี่ยวข้องคือโหนด AI Agent ได้
• ช่องทางการอนุมัติที่การตั้งค่า n8n ของคุณรองรับ เช่น n8n Chat, Slack, Telegram, อีเมล หรือช่องทางอื่นที่มีเอกสารระบุไว้
• การเข้าถึง OpenAI-Compatible API หากใช้ OneMux ให้เริ่มจาก คู่มือเริ่มต้นใช้งาน OneMux และยืนยันเอนด์พอยต์ วิธีการยืนยันตัวตน ตัวระบุโมเดล และพารามิเตอร์คำขอที่รองรับใน เอกสาร OneMux
• JSON Schema ที่อธิบายอ็อบเจ็กต์ที่คุณต้องการดึงข้อมูล
• เครื่องมือปลายทาง เช่น การอัปเดต CRM หรือการดำเนินการส่งข้อความ ซึ่งไม่ควรทำงานหากยังไม่มีการตรวจสอบโดยมนุษย์

อย่าสันนิษฐานว่า OpenAI-Compatible API ทุกเอนด์พอยต์รองรับฟีเจอร์เอาต์พุตแบบมีโครงสร้างทั้งหมด ให้ตรวจสอบการรองรับ response_format, JSON Schema, tool calls และโมเดลที่คุณเลือกโดยเฉพาะ ไดเรกทอรีโมเดล OneMux ช่วยให้คุณตรวจสอบตัวเลือกโมเดลที่มีอยู่ได้ แต่ไม่ได้ยืนยันด้วยตัวเองว่ารองรับการกำหนดค่าโหนด n8n เฉพาะแบบใด

เวิร์กโฟลว์ n8n ที่แนะนำ

เวิร์กโฟลว์ที่ใช้งานได้จริงอาจใช้โหนดต่อไปนี้:

1. Webhook หรือทริกเกอร์อื่นรับข้อความต้นทาง
2. HTTP Request ส่งข้อความไปยังเอนด์พอยต์โมเดลที่เข้ากันได้
3. Code แยกวิเคราะห์และตรวจสอบอ็อบเจ็กต์ที่ส่งกลับ
4. IF แยกผลลัพธ์ที่ไม่ถูกต้องไปยังเส้นทางข้อผิดพลาดหรือการแก้ไขด้วยตนเอง
5. AI Agent รับอ็อบเจ็กต์ที่ผ่านการตรวจสอบแล้วและเข้าถึงเครื่องมือที่มีผลกระทบได้
6. การตรวจสอบโดยมนุษย์ หยุดเวิร์กโฟลว์ก่อนเรียกใช้เครื่องมือนั้น
7. เครื่องมือที่ได้รับอนุมัติ เขียนระเบียนหรือส่งข้อความ

คำขอสำหรับการดึงข้อมูลควรระบุเฉพาะฟิลด์ที่เวิร์กโฟลว์ต้องใช้ ตัวอย่างสคีมาแบบกระชับสำหรับคำขอฝ่ายสนับสนุนอาจมีลักษณะดังนี้:

{
  "$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-Compatible

ในโหนด HTTP Request ให้ใช้ Base 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"}
        }
      }
    }
  }
}

ตัวอย่างนี้ใช้ Model ID แบบตัวยึดตำแหน่งโดยตั้งใจ ให้เลือกโมเดลที่มีเอกสารระบุว่าเข้ากันได้กับเอนด์พอยต์ที่คุณเลือก หากไม่มีเอาต์พุต JSON Schema แบบ strict ให้ใช้ JSON mode ที่รองรับได้ก็ต่อเมื่อเส้นทางการตรวจสอบของคุณสามารถปฏิเสธผลลัพธ์ที่ไม่เป็นไปตามข้อกำหนดได้อย่างปลอดภัย JSON mode เพียงอย่างเดียวไม่เทียบเท่ากับการตรวจสอบสคีมา

ตรวจสอบการตอบกลับก่อนดำเนินการ

การตอบกลับจากผู้ให้บริการอาจวางเนื้อหาที่สร้างขึ้นไว้ในฟิลด์ต่างกัน ให้ตรวจสอบการตอบกลับจริงใน n8n ก่อนเขียนตัวแยกวิเคราะห์ โหนด Code ต่อไปนี้สมมติว่าโมเดลส่งสตริง JSON กลับมาใน message.content ให้ปรับพาธให้ตรงกับการตอบกลับที่คุณได้รับจริง

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 } }];

สำหรับการใช้งานจริง ให้แทนที่การตรวจสอบแบบเบานี้ด้วยตัวตรวจสอบ JSON Schema ที่ได้รับการดูแล หากการติดตั้ง n8n ของคุณอนุญาต สคีมาในคำขอและสคีมาที่ใช้บังคับในการตรวจสอบควรจัดการเวอร์ชันร่วมกัน เพิ่มเวอร์ชันสคีมาในเอาต์พุต หากระบบปลายทางจำเป็นต้องแยกแยะการแก้ไขแต่ละรุ่น

เพิ่มการอนุมัติโดยมนุษย์ให้เครื่องมือของ AI Agent

ใช้อ็อบเจ็กต์ที่ผ่านการตรวจสอบแล้วเป็นบริบทสำหรับ AI Agent กำหนดเครื่องมือให้ Agent อย่างแคบและชัดเจน เช่น CreateSupportTicket แทนการให้สิทธิ์เข้าถึงฐานข้อมูลแบบกว้าง ตั้งค่าการตรวจสอบโดยมนุษย์สำหรับเครื่องมือที่เลือกใน Tools Panel ของ AI Agent

เอกสาร n8n ระบุว่าเวิร์กโฟลว์จะหยุดชั่วคราวเมื่อ Agent พยายามเรียกใช้เครื่องมือที่ต้องมีการตรวจสอบ ผู้ตรวจสอบสามารถอนุมัติการเรียกใช้ เพื่อให้เครื่องมือทำงานด้วยอินพุตที่เสนอ หรือปฏิเสธ ซึ่งจะยกเลิกการดำเนินการ n8n รองรับช่องทางการอนุมัติหลายรูปแบบ รวมถึงอินเทอร์เฟซแชตในตัวและการผสานรวมกับ Slack, Telegram, Discord, Teams, อีเมล, WhatsApp, Google Chat และ Outlook email ดู เอกสารอย่างเป็นทางการของ n8n เกี่ยวกับ human-in-the-loop สำหรับขั้นตอนการตั้งค่าและรายละเอียดช่องทางล่าสุด

ข้อความอนุมัติที่มีประโยชน์ควรแสดงการดำเนินการและพารามิเตอร์ที่เสนอ:

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

เอกสารต้นทางระบุ $tool.name และ $tool.parameters สำหรับบริบทการตรวจสอบนี้ ควรจัดข้อความให้อ่านง่าย และใส่คำขอต้นฉบับหรือหมายเลขอ้างอิงทิกเก็ตเมื่อผู้ตรวจสอบต้องการบริบทเพิ่มเติม

System prompt ของ 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-Compatible API อาจใช้รูปแบบคำขอร่วมกัน แต่มีรายละเอียดการตอบกลับและพารามิเตอร์ที่รองรับแตกต่างกันได้

คำขออนุมัติคลุมเครือเกินไป

ใช้เครื่องมือที่มีขอบเขตแคบ และใส่ $tool.name พร้อม $tool.parameters ในข้อความอนุมัติ อย่าขอให้ผู้ตรวจสอบอนุมัติคำสั่งที่ไม่ชัดเจน เช่น “ประมวลผลคำขอนี้”

การปฏิเสธการเรียกใช้เครื่องมือทำให้เกิดลูป

เพิ่มพฤติกรรมเมื่อถูกปฏิเสธอย่างชัดเจนใน System prompt ของ Agent และกำหนดค่าเวิร์กโฟลว์ให้การปฏิเสธสิ้นสุดเส้นทางการดำเนินการหรือส่งต่อไปยังการขอคำชี้แจง เอกสาร n8n แนะนำให้อธิบายว่าเครื่องมือใดต้องได้รับอนุมัติ และ Agent ควรตอบสนองต่อการปฏิเสธอย่างไร

ผู้ตรวจสอบอนุมัติข้อมูลที่ไม่ถูกต้อง

ความถูกต้องตามสคีมาไม่ได้พิสูจน์ความถูกต้องเชิงความหมาย ให้แสดงข้อความต้นฉบับ ฟิลด์ที่ดึงข้อมูลได้ และการดำเนินการที่ตั้งใจไว้ร่วมกัน สำหรับเวิร์กโฟลว์ที่มีผลกระทบสูง ให้ผู้ตรวจสอบยืนยันฟิลด์ที่มีความอ่อนไหวด้วยตนเอง

สรุป

รูปแบบ n8n ที่ปลอดภัยที่สุดสำหรับการดึงข้อมูลแบบมีโครงสร้างไม่ใช่การ “ปล่อยให้โมเดลเขียนข้อมูลโดยตรง” แต่คือการดึงข้อมูลลงในอ็อบเจ็กต์ที่มีข้อจำกัด ตรวจสอบอ็อบเจ็กต์นั้น แล้ววางการอนุมัติโดยมนุษย์ไว้หน้าเครื่องมือที่เปลี่ยนแปลงสิ่งต่าง ๆ ภายนอก OpenAI-Compatible API ช่วยให้เข้าถึงโมเดลได้ง่ายขึ้น ขณะที่ n8n จัดการการประสานงานและการควบคุมการอนุมัติ ด้วย OneMux ให้ใช้เอนด์พอยต์และพารามิเตอร์โมเดลที่เข้ากันได้ตามเอกสาร ตรวจสอบการกำหนดค่าในสภาพแวดล้อมของคุณเอง และถือว่าฟีเจอร์เอาต์พุตแบบมีโครงสร้างที่ไม่รองรับเป็นเหตุผลให้หยุดหรือเปลี่ยนไปใช้เส้นทางการตอบกลับที่ตรวจสอบแยกต่างหาก