สร้าง Workflow ใน n8n สำหรับแก้ไขโค้ดโดยให้มนุษย์อนุมัติและตรวจสอบด้วยการทดสอบ

ภาพรวมของ workflow

ใช้ n8n ให้ AI agent เสนอการเปลี่ยนแปลง repository แต่กำหนดให้การเขียนต้องผ่านการอนุมัติจากมนุษย์ก่อน หลังจากอนุมัติและเขียนแล้ว ให้รันการทดสอบกับ commit ที่ได้โดยตรงและรายงานผล ส่วนการ merge หรือ deployment ให้เป็นการตัดสินใจแยกต่างหาก

ข้อแตกต่างสำคัญคือ การอนุมัติการใช้เครื่องมือเทียบกับการอนุมัติผลลัพธ์ ใน n8n ขั้นตอนตรวจสอบโดยมนุษย์สามารถหยุด AI Agent ชั่วคราวก่อนที่เครื่องมือที่เลือกจะทำงาน ผู้ตรวจสอบจะเห็นเครื่องมือที่เสนอและพารามิเตอร์ของเครื่องมือนั้น หากอนุมัติ ระบบจะเรียกใช้เครื่องมือดังกล่าว แต่หากปฏิเสธ ระบบจะยกเลิกและแจ้งให้ agent ทราบ พฤติกรรมนี้อธิบายไว้ใน คู่มือ human-in-the-loop ของ n8n

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

สิ่งที่ต้องเตรียมก่อนเริ่มสร้าง

• อินสแตนซ์ n8n ที่มี AI Agent การเชื่อมต่อ chat model ที่เหมาะสม และช่องทางตรวจสอบโดยมนุษย์ เช่น Slack หรือ n8n Chat
• การเชื่อมต่อ repository หรือบริการที่สร้างขึ้นเอง ซึ่งอ่าน revision ที่ระบุและใช้ patch กับ branch ที่ไม่ใช่ production ได้ โดยให้ credential สำหรับการเขียนมีสิทธิ์เท่าที่จำเป็นสำหรับ repository และ branch นั้นเท่านั้น
• test runner ที่แยกจาก credential และระบบ production โดยต้องรับตัวระบุ commit ที่แน่นอน และส่งคืนสถานะพร้อมลิงก์หรือข้อมูลอ้างอิงผลการทดสอบได้
• บัญชี OneMux และสิทธิ์เข้าถึง API หากเลือกใช้ OneMux เพื่อเรียกโมเดล ดูรายละเอียดการเชื่อมต่อล่าสุดได้ใน quickstart และดู รายการโมเดล เพื่อเลือกโมเดลที่พร้อมใช้งาน
• repository ที่ทราบคำสั่งทดสอบ มี default branch ที่ได้รับการป้องกัน และมีผู้มีอำนาจตรวจสอบการเปลี่ยนแปลงที่เสนอ

นี่เป็นรูปแบบสำหรับนำไปพัฒนา ไม่ใช่ workflow ที่นำเข้าใช้งานได้ทันที เครื่องมือ repository การเชื่อมต่อ runner การเลือกโมเดล และฟิลด์ n8n ที่ต้องใช้ขึ้นอยู่กับสภาพแวดล้อมของคุณ โดยเฉพาะอย่างยิ่ง เอกสารที่ให้มาไม่ได้ยืนยันว่าโมเดล OneMux ใดโดยเฉพาะรองรับพฤติกรรม tool-calling ที่ n8n AI Agent ต้องใช้ จึงควรตรวจสอบการรองรับก่อนพึ่งพาการออกแบบนี้

ออกแบบ workflow โดยอ้างอิง revision ที่แน่นอน

ลำดับการทำงานที่นำไปใช้ได้มีดังนี้:

1. รับคำขอ บันทึก repository คำอธิบาย issue branch สำหรับทำงานเป้าหมาย base commit และคำสั่งทดสอบที่อนุญาตจากการตั้งค่า workflow ที่เชื่อถือได้
2. อ่านและเสนอการเปลี่ยนแปลง ให้ agent ตรวจสอบไฟล์ที่เกี่ยวข้อง ณ base commit และเตรียม patch โดยสิทธิ์อ่านต้องไม่สามารถแก้ไข repository ได้
3. ตรวจสอบการเขียน ส่งการเรียกใช้เครื่องมือที่ใช้ patch ผ่านขั้นตอนตรวจสอบโดยมนุษย์ของ n8n เพื่อให้ผู้ตรวจสอบอนุมัติหรือปฏิเสธการเรียกใช้ที่เสนอ
4. นำการเปลี่ยนแปลงไปใช้และระบุ commit หากได้รับอนุมัติ บริการเขียนจะตรวจสอบว่า branch ยังชี้ไปที่ base commit ที่อนุมัติไว้ ใช้ patch ที่อนุมัติแล้ว และส่งคืน ID ของ commit ใหม่ หาก base เปลี่ยนไป ให้หยุดดำเนินการโดยไม่อนุญาตให้เขียน และขอข้อเสนอพร้อมการอนุมัติใหม่
5. ตรวจสอบด้วยการทดสอบ รันการทดสอบที่กำหนดไว้กับ commit ใหม่ที่ระบุโดยตรงใน runner แบบแยกส่วน บันทึกคำสั่ง commit สถานะ และข้อมูลอ้างอิงผลลัพธ์
6. รายงานผล ส่ง commit และผลการทดสอบให้ผู้ตรวจสอบและผู้ร้องขอ ผลการทดสอบที่ล้มเหลว ถูกยกเลิก หรือไม่มีผลลัพธ์ ไม่ถือว่าผ่าน

สิ่งเหล่านี้เป็นมาตรการควบคุมที่แนะนำ ไม่ใช่ความสามารถที่ขั้นตอนตรวจสอบโดยมนุษย์ของ n8n รับประกัน โดยเฉพาะอย่างยิ่ง บริการ repository ของคุณต้องบังคับใช้การตรวจสอบ base commit และรับประกันว่า patch ที่นำไปใช้เป็น patch เดียวกับที่อนุมัติ

ตั้งค่าการเชื่อมต่อโมเดล

ใน n8n ให้เลือกการตั้งค่า chat model ที่รองรับทั้ง endpoint ที่เข้ากันได้กับ OpenAI และกำหนดค่าได้ รวมถึง พฤติกรรม tool-calling ที่ AI Agent ต้องใช้ ใช้ endpoint วิธีการยืนยันตัวตน และตัวระบุโมเดลตามเอกสาร OneMux ฉบับปัจจุบัน เก็บ credential ไว้ในระบบ credential ของ n8n แทนการใส่ไว้ใน prompt หรือข้อความของ workflow

ก่อนเชื่อมต่อสิทธิ์เข้าถึง repository ให้ส่งคำขอทดสอบขนาดเล็กและตรวจสอบว่าคำตอบอยู่ในรูปแบบที่ node ของ n8n คาดหวัง จากนั้นทดสอบการเรียกใช้เครื่องมือที่ไม่ก่อให้เกิดผลเสีย การเข้ากันได้กับ OpenAI ไม่ได้หมายความว่า endpoint พารามิเตอร์ หรือรูปแบบการเรียกใช้เครื่องมือทุกแบบใช้แทนกันได้ โดยความเข้ากันได้ในที่นี้ขึ้นอยู่กับว่าทั้งสองฝ่ายรองรับคำขอและคำตอบที่จำเป็นหรือไม่ การตั้งค่านี้ยังไม่ได้รับการทดสอบสำหรับบทความนี้

หากการเชื่อมต่อโมเดลที่มีอยู่ไม่รองรับการเรียกใช้เครื่องมือของ agent อย่าข้ามขั้นตอนอนุมัติโดยให้ credential สำหรับเขียนแก่โมเดลโดยตรง ให้ใช้การตั้งค่าที่เข้ากันได้ หรือสร้างขั้นตอนส่งต่องานไปยังบริการเขียนแยกต่างหากโดยมีการตรวจสอบอย่างชัดเจน

เพิ่มด่านตรวจสอบโดยมนุษย์ก่อนเขียน repository

ใน node AI Agent ให้เปิดตัวเชื่อมต่อ Tools แล้วค้นหา Human review ใน Tools Panel เลือกช่องทางอนุมัติและตั้งค่า credential ของช่องทางนั้น เชื่อมต่อเครื่องมือเขียน repository เข้ากับตัวเชื่อมต่อเครื่องมือของขั้นตอนตรวจสอบ แยกเครื่องมือแบบอ่านอย่างเดียวตามความเหมาะสม และวางเครื่องมืออื่นที่เปลี่ยนแปลงสถานะภายนอกได้ไว้หลังขั้นตอนตรวจสอบของตนเองหรือมาตรการควบคุมที่เทียบเท่า

เอกสาร n8n ระบุว่าผู้ตรวจสอบสามารถรับชื่อเครื่องมือและพารามิเตอร์ที่ AI ส่งมาได้ ตัวอย่างเช่น ตั้งค่าข้อความตรวจสอบดังนี้:

Proposed tool: {{ $tool.name }}
Proposed parameters:
{{ JSON.stringify($tool.parameters, null, 2) }}

ใช้เครื่องมือเขียนที่มีอินพุตให้ตรวจสอบได้ ได้แก่ repository, branch, base commit และ patch ฉบับเต็ม หรือข้อมูลอ้างอิง patch ที่เปลี่ยนแปลงไม่ได้พร้อม digest หาก patch มีขนาดใหญ่เกินกว่าจะส่งผ่านช่องทางนั้นได้ ให้ระบุที่สำหรับตรวจสอบซึ่งปลอดภัยและเข้าถึงได้ และยืนยันว่าบริการเขียนใช้เนื้อหาเดียวกัน คำสั่งกว้าง ๆ เช่น “แก้ไขการทดสอบ” ไม่เพียงพอสำหรับอนุมัติการเปลี่ยนแปลง repository ที่เฉพาะเจาะจง

ค่า $tool.parameters ที่ระบุไว้ในเอกสารรวมถึงฟิลด์ที่ตั้งค่าด้วย expression $fromAI() อย่าคิดว่าข้อความจะแสดง credential ที่กำหนดตายตัว ค่าการตั้งค่าที่ซ่อนอยู่ หรือผลกระทบปลายทางทั้งหมด ควบคุมการตั้งค่าคงที่ให้จำกัดอยู่ในขอบเขตที่เหมาะสม และจัดวิธีแยกต่างหากให้ผู้ตรวจสอบดูการตั้งค่าเหล่านั้น หลีกเลี่ยงการใส่ข้อมูลลับในพารามิเตอร์ของเครื่องมือ เพราะพารามิเตอร์อาจปรากฏในข้อความขออนุมัติ

เพิ่มคำสั่งระบบที่ระบุชื่อเครื่องมือซึ่งต้องผ่านการอนุมัติ และบอก agent ว่าต้องทำอย่างไรเมื่อถูกปฏิเสธ ตัวอย่างเช่น:

Repository writes require human approval. Propose a patch against the
specified base commit and request the write tool only for that patch.
If approval is denied, do not retry the write or use another tool to make
the change. Tell the requester it was denied and ask for clarification.
Report test results only when supplied by the test runner.

คำสั่งนี้ช่วยให้ agent จัดการขั้นตอนตรวจสอบได้ แต่ไม่ใช่ขอบเขตความปลอดภัย ให้บังคับใช้สิทธิ์และข้อจำกัดของ branch นอกเหนือจาก prompt

ตรวจสอบการเปลี่ยนแปลงที่อนุมัติแล้ว

สั่งให้ test runner ทำงานหลังจากบริการเขียนส่งคืน commit ID แล้วเท่านั้น ตั้งค่า runner ให้ checkout ID นั้น ไม่ใช่ head ล่าสุดของ branch และรันคำสั่งในรายการที่ทีมอนุญาต สำหรับ repository ที่ผู้ดูแลเลือกใช้คำสั่งนี้ ตัวอย่างคำสั่งอาจเป็น:

npm test

คำสั่งดังกล่าวเป็นเพียงตัวอย่าง ให้ใช้คำสั่งทดสอบจริงของโปรเจกต์ ปฏิบัติต่อโค้ดใน repository สคริปต์ติดตั้ง dependency และผลลัพธ์การทดสอบเสมือนเป็นข้อมูลที่ไม่น่าเชื่อถือ รันสิ่งเหล่านี้โดยจำกัดการเข้าถึงเครือข่ายและ filesystem ไม่ใช้ข้อมูลลับของ production และกำหนดขีดจำกัดเวลาและทรัพยากร การทดสอบที่ผ่านแสดงเพียงว่าการตรวจสอบที่เลือกผ่านในสภาพแวดล้อมนั้น ไม่ได้พิสูจน์ว่าการเปลี่ยนแปลงปลอดภัยหรือถูกต้อง

ส่งคืนผลลัพธ์แบบกระชับที่ประกอบด้วย base ที่อนุมัติแล้ว commit ใหม่ คำสั่งทดสอบ สถานะผ่านหรือไม่ผ่าน และลิงก์ไปยัง log หากการทดสอบล้มเหลว agent อาจเสนอ patch ฉบับแก้ไขได้ แต่การเขียนครั้งถัดไปต้องได้รับการอนุมัติอีกครั้ง อย่า merge โดยอัตโนมัติเพียงเพราะผู้ตรวจสอบอนุมัติการเรียกใช้เครื่องมือครั้งก่อน

การแก้ปัญหาและข้อจำกัดในการใช้งาน

คำขออนุมัติไม่มีบริบทที่เพียงพอ

ตรวจสอบว่าอินพุตใดส่งมาจาก AI และมองเห็นได้ใน $tool.parameters ใส่ข้อมูลระบุ patch, branch และ revision ฐานไว้ในอินพุตของเครื่องมือที่ตรวจสอบได้ หรือจัดเตรียมสิ่งส่งมอบสำหรับตรวจสอบที่ปลอดภัยและเปลี่ยนแปลงไม่ได้ หากผู้ตรวจสอบไม่สามารถระบุการเขียนที่แน่นอนได้ ให้ปฏิเสธ

Agent ไม่สามารถเรียกใช้เครื่องมือได้

เริ่มจากทดสอบเครื่องมือที่ไม่ก่อให้เกิดผลเสียโดยแยกจากสิทธิ์ของ repository ตรวจสอบ node ของ n8n, endpoint ของ OneMux, โมเดลที่เลือก และพารามิเตอร์ที่จำเป็นสำหรับการเรียกใช้เครื่องมือเทียบกับเอกสารฉบับปัจจุบันของแต่ละส่วน แหล่งข้อมูลที่ให้มายังไม่ได้ยืนยันการใช้งานร่วมกันของโมเดลและ node คู่ใดโดยเฉพาะ

Branch เปลี่ยนไปหรือการทดสอบไม่เสร็จ

ปฏิเสธการเขียนที่อิงข้อมูลเก่า แทนที่จะนำ patch ไปใช้กับ base อื่น หากเกิด timeout ข้อผิดพลาดของ runner หรือไม่มี log ให้รายงานว่าการตรวจสอบยังไม่สมบูรณ์ รันซ้ำกับ commit เดิมตามความเหมาะสม และขออนุมัติใหม่หากการเขียนที่เสนอเปลี่ยนไป

สรุป

ขอบเขตสำคัญมีความเฉพาะเจาะจง: มนุษย์อนุมัติการเขียน repository ครั้งหนึ่งที่ระบุชัดเจน และ runner แบบแยกส่วนตรวจสอบ commit ที่ได้ n8n มีขั้นตอนหยุดและอนุมัติระดับเครื่องมือตามที่ระบุไว้ในเอกสาร ส่วนบริการ repository, runner, สิทธิ์ และกระบวนการตรวจสอบของคุณเป็นผู้จัดเตรียมมาตรการป้องกันที่เหลือ ใช้ OneMux เป็นชั้นสำหรับเข้าถึงโมเดลหลังจากยืนยันแล้วเท่านั้นว่า endpoint และพารามิเตอร์ที่เลือกทำงานร่วมกับการตั้งค่า n8n ของคุณได้

แหล่งข้อมูล

• n8n: Human-in-the-loop for tools — พฤติกรรมการอนุมัติเครื่องมือ การตั้งค่า ช่องทางตรวจสอบ และตัวแปรในข้อความตรวจสอบ
• เอกสาร OneMux — ดูรายละเอียดการเชื่อมต่อ API ล่าสุด