ผมสร้าง AI Agent ที่ทำงานเองได้ แต่ไม่ให้มันแตะเงินเอง

กรอบควบคุมหลัก

AI agent จะไม่แตะเงินหรือติดต่อลูกค้าโดยไม่ได้รับอนุญาต

ปฏิบัติกับตรรกะของ agent เหมือนพนักงานใหม่ในวันแรก ให้งานที่ชัดเจน วางขอบเขตที่เข้มงวด และให้ผู้จัดการอนุมัติทุกอย่างที่ลูกค้าจะเห็น คุณคงไม่ยื่นบัตรเครดิตบริษัทกับกล่องรีวิวให้พนักงานใหม่ แล้วบอกให้ใช้วิจารณญาณเอาเอง

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

สามลูป

agent อยู่ตรงกลาง ส่วนการตรวจสอบแบบกำหนดตายตัวอยู่ระหว่างมันกับทุกอย่างที่ย้อนกลับไม่ได้

รีวิว ลูกค้าทุกคนที่ซื้อจะได้รับสิ่งเดียว คือลิงก์ที่เป็นกลางสำหรับเขียนรีวิว Google ไม่มีสิ่งจูงใจ ไม่มีการถามกรอง เช่น "ทุกอย่างห้าดาวไหม" ถ้าฟีดแบ็กกลับมาต่ำ agent จะเขียนสรุปเหตุการณ์ ว่าเกิดอะไรขึ้น สาขาไหน ลูกค้าพูดว่าอะไร แล้วโพสต์เป็นการ์ดโต้ตอบเข้าไปใน Google Chat ของผู้จัดการสาขา ไม่มีอะไรเกิดขึ้นต่อจนกว่าผู้จัดการจะรับเรื่อง การวาง review strategy ที่ตั้งใจ ก็หน้าตาคล้ายแบบนี้ เพียงแต่ไม่มี agent

ตะกร้าที่ถูกทิ้ง checkout ค้างอยู่ 15 นาที agent เสนอส่วนลดเพื่อดึงลูกค้ากลับมาได้ แต่ขนาดของส่วนลดนั้นไม่ใช่การตัดสินใจของโมเดล ฟังก์ชันนโยบายเป็นคนคำนวณ ห้าเปอร์เซ็นต์ เพดานที่ £35 หนึ่งครั้งต่อลูกค้าหนึ่งคนทุก 30 วัน หมดอายุใน 2 ชั่วโมง ข้อเสนอส่งออกไปแบบ agent-to-agent ไปยังผู้ช่วยช้อปปิ้งที่ลูกค้าใช้อยู่

สินค้าหมด ลูกค้าอนุมัติการซื้อไว้ล่วงหน้า ยางสี่เส้น ยอดรวมไม่เกิน £500 ภายใน 14 วัน เมื่อสต็อกเข้า ตัวจับคู่จะตรวจสินค้า สาขา จำนวน และเพดานราคา เทียบกับสิ่งที่อนุมัติไว้เป๊ะ ๆ การชำระเงินจะผ่านก็ต่อเมื่อทุกอย่างตรงกันเท่านั้น

หน้าร้าน เลือกยางและล้อแม็กตามรุ่นรถ พร้อมสต็อกจริงของแต่ละสาขา

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

หน้าตาของมันในโค้ด

นี่คือส่วนที่ผมอยากให้กรรมการที่ขี้สงสัยได้ดู

ส่วนลดตะกร้าไม่ใช่ prompt มันคือโค้ด Python บรรทัดเดียว min(total * 0.05, 35) พร้อมการตรวจว่าลูกค้าคนเดิมไม่ได้รับข้อเสนอในช่วง 30 วันที่ผ่านมา และมีการประทับเวลาหมดอายุ 2 ชั่วโมงไว้ ถ้าโมเดลหลอกตัวเองว่าส่วนลด 40% ที่ไหนสักแห่งในกระบวนการคิด มันก็ไม่มีผล ตัวเลขที่ออกไปคำนวณโดยโค้ดที่เถียงด้วยไม่ได้

การส่งต่อเรื่องรีวิวเป็นเกณฑ์ ไม่ใช่การใช้ดุลยพินิจ ฟีดแบ็กที่ 6 เต็ม 10 หรือต่ำกว่า ส่งถึงมนุษย์ โมเดลไม่มีสิทธิ์ออกเสียงว่าอะไรแย่พอที่จะต้องส่งต่อ

เส้นทางการชำระเงินเป็นส่วนที่เข้มงวด ก่อนอะไรจะจบ ตัวตรวจสอบจะเช็ก signature เข้ารหัสจริง Ed25519 หรือ RS256 และค่า SHA-256 hash ของ checkout ที่เจาะจง เพื่อให้พิสูจน์ได้ว่าสิ่งที่กำลังจ่ายเงินคือสิ่งที่อนุมัติไว้ ไม่ใช่เวอร์ชันที่ agent ขยับระหว่างทาง มันตรวจว่าการอนุมัติใหม่ยังอยู่ในกรอบของการอนุมัติเดิม และการอนุมัติเดิมจะถูกใช้ซ้ำสองครั้งไม่ได้

จุดที่โมเดลคุ้มค่า อ่านคำถาม ให้คำแนะนำเรื่องความเข้ากันของยาง ไม่ใช่การขยับเงิน

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

การเชื่อมต่อระหว่าง agent ไม่ว่าจะเป็น agent หนึ่งคุยกับอีก agent การอธิบาย checkout หรือการเซ็น payment mandate รันอยู่บนมาตรฐานเปิดที่กำลังเกิดขึ้นสำหรับเรื่องนี้ ได้แก่ A2A, AP2 และ MCP

ผู้จัดการสาขาเป็นผู้อนุมัติ

รีวิวคะแนนต่ำ ถูกเขียนสรุปและหยุดพักไว้ รอผู้จัดการสาขาตัดสินใจ

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

agent จะเขียนสรุปเหตุการณ์และส่งการ์ดโต้ตอบไปให้ผู้จัดการสาขาใน Google Chat ผู้จัดการเลือกได้ว่าจะ investigate, assign หรือ dismiss กระบวนการจะหยุดค้างอยู่จนกว่าจะมีการตัดสินใจ

เครื่องมืออัตโนมัติควรทำงานรวบรวมข้อมูล ร่างข้อความ และติดตามเรื่อง เพื่อให้ผู้จัดการใช้เวลากับการตัดสินใจที่ต้องอาศัยวิจารณญาณจริง ๆ และระบบต้องรอการตัดสินใจนั้น

ผมบอกลูกค้าเรื่องเดียวกันนี้มาหลายปีเกี่ยวกับ AI กับ Google Business Profile ของพวกเขา ให้มันร่าง ให้มันสรุป ให้มันหาสิ่งที่คุณพลาด อย่าให้มันกดเผยแพร่

ขอบเขตเดโมและข้อมูลจำลอง

สตรีมโปรโตคอลบนหน้า demo น่าดู และเป็นการจำลอง ไม่ใช่ทราฟฟิกจริง

• รันจริงบน Cloud Run: policy engine แบบกำหนดตายตัว การตรวจ cryptographic signature และ hash, core agent runtime พร้อม endpoint แบบ agent-to-agent และหน้าร้าน โดยมีชุดทดสอบครอบคลุมส่วนเหล่านี้
• จำลองสำหรับเดโม: event bus, checkout provider, protocol stream ที่แสดงบนหน้าเดโม ข้อมูลคู่แข่ง และระบบสร้างภาพกับเสียง ส่วนเหล่านี้ใช้ implementation ตัวแทนเพื่อแสดงเวิร์กโฟลว์ตั้งแต่ต้นจนจบ แต่ยังไม่ได้เชื่อมกับร้านค้าจริง

บทเรียนด้านวิศวกรรม

Session persistence agent ทำ state หายทุกครั้งที่ container รีสตาร์ต ผมใช้เวลาครึ่งวันไล่หาสาเหตุของ session ที่หายไป ก่อนเพิ่ม Firestore session store แบบถาวร เพื่อให้บทสนทนาอยู่รอดหลังการรีสตาร์ต

Idempotency สำคัญกว่าเมื่อมีมนุษย์อยู่ในลูป เวิร์กโฟลว์ที่หยุดรอผู้จัดการกดปุ่ม อาจค้างอยู่อย่างนั้นทั้งวัน เมื่อมันทำงานต่อ มันต้องไม่ส่งข้อเสนอที่ส่งไปแล้วซ้ำ หรือรัน settlement สองครั้ง one-time action token กับค่า checkout hash นั้นเป็นตัวกันซ้ำ อะไรก็ตามที่หยุดพักได้ ต้องถือว่ามันอาจรันสองครั้ง

Evaluation การทดสอบเน้นลำดับการทำงานและขอบเขต มากกว่าคุณภาพของข้อความ เราตรวจว่า agent เรียกเช็กสต็อกหรือไม่ เคารพเพดาน £35 หรือไม่ และหยุดรอที่ขั้นตอนอนุมัติหรือไม่