เดโม AI agent ทุกอันสุดท้ายจบที่อีเมลขอโทษ — เลยสร้าง firewall ขึ้นมา (Solo Builder สัปดาห์ที่ 6)

เมื่อ 3 สัปดาห์ก่อนใน Show GN แรก ผมแชร์ไว้ว่ากำลังทำ 5-tier firewall อยู่ ช่วงที่ผ่านมามีทั้งการแก้แบบการออกแบบ + สิ่งที่ ship จริง เลยมาอัปเดตให้ครับ

▶ ปรับจาก 5-tier → 4-tier (PUSH / QUEUE / SILENT / AUTO)
ส่วน tier แบบ "Call" เอาออกและพักไว้ก่อน ตัดสินใจจากข้อมูลระหว่างทำ PoC

▶ ทำ Agent loop แบบ end-to-end เสร็จแล้ว
อีเมลขอนัดประชุมเข้ามา → แยกประเภท tier → Klorn เช็ก calendar conflict → ร่างคำตอบกลับ + ร่าง calendar event → รอใน PendingAction → ผู้ใช้กดอนุมัติแบบ 1-click → ยิงออกไป ทุก action จะถูกเซ็นด้วย payload hash ก่อนยิง และถ้าไม่มี ActionReceipt ที่ตรงกันก็จะ execute ไม่ได้

▶ ส่วนที่ใช้เวลานานที่สุด: invariant test (โค้ดน้อยกว่า 100 บรรทัด)
เป็นเทสต์ที่ทำให้ build พังทันทีถ้า action อย่าง send_email ถูกรันโดยไม่มีการอนุมัติจากผู้ใช้ ถ้าใครลบ approval check ออก → เทสต์ล้มเหลว → build ล้มเหลว → deploy ล้มเหลว การ bypass จึงไม่ใช่ตัวเลือกตั้งแต่แรก นี่คือเหตุผลที่คำว่า "agent จะไม่ส่งเอง" ไม่ใช่แค่ข้อความการตลาด แต่เป็นข้อเท็จจริง

▶ เจอและแก้ prod bug จริงได้ 1 ตัว
OpenRouter retire SKU ของโมเดลแบบ :free ทำให้ autonomous cycle ทั้งหมดตายด้วย "404 No endpoints found" เดิม failover รองรับแค่ 402 / 403 / 429 แต่ยังไม่รองรับกรณี "โมเดลหายไป" เลยใส่ multi-model fallback chain ทำให้ต่อให้ upstream SKU ตัวหนึ่งตาย agent ก็ไม่ตายตาม

▶ กำลังวัด Day 14+7 retention
เกณฑ์ผ่าน PoC คือ activate ICP ให้ได้ 5 คน ฟีดแบ็กตรงไปตรงมาแม้แค่บรรทัดเดียวก็ยินดีมากครับ

▶ วิดีโอ 60 วินาที: https://klorn.ai
▶ โค้ด: https://github.com/k08200/klorn

เบต้าฟรี + ใช้ PRO ให้อัตโนมัติ ขอบคุณมากจริงๆ สำหรับทุกความเห็นในโพสต์แรกครับ

[k08200]

ขอถามหนึ่งข้อ — สำหรับคนที่ทำ agent / SaaS อยู่ เวลา agent ทำงานโดยไม่ตรงกับเจตนาของผู้ใช้ รูปแบบความล้มเหลวที่เจอบ่อยที่สุดคืออะไรบ้าง?

จากที่ผมเจอระหว่างดูแลระบบ เรียงตามความถี่คือ:

1. Prompt drift — ส่งข้อความตอบกลับอัตโนมัติที่ไม่ใช่สิ่งที่ตั้งใจไว้
2. Model retire — พอ :free SKU ตาย วงจรก็ตายตามไปเลยโดยไม่มี fallback
3. เข้าใจ Tool argument ผิด — agent ไปทำ action ภายนอกด้วยพารามิเตอร์ที่ผิด

อยากรู้เหมือนกันว่าของคนอื่นมีแพตเทิร์นแบบไหนบ้าง

[ng0301]

ข้อ 2 เกิดขึ้นบ่อยมาก แล้วพอ fallback ไปใช้ทางเลือกนั้น ก็เกิดข้อ 1 ตามพรอมป์ต์ แล้วสุดท้ายก็ทำให้เกิดข้อ 3 ตามมาอีกครับ 555
ถ้าใช้โมเดลระดับสูงตลอดก็คงไม่เจอปัญหาแบบนั้นหรอก แต่ถ้าเป็นบริการสำหรับลูกค้าทั่วไป ยังไงโมเดลระดับ Sonnet ขึ้นไปก็ค่อนข้างเป็นภาระเรื่องต้นทุนอยู่ดี ..

[k08200]

ฮ่าๆ อินกับลำดับนั้นจริงครับ/ค่ะ ผม/ฉันเองก็เจ็บกับ #2 มากที่สุดเหมือนกัน และพอปล่อยไปเป็น free แล้วพรอมป์ตก็ไม่เข้ากันจนเกิด #1 ก็เจอมาเหมือนกันเลย

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

พอตั้งแบบนี้ไว้ ต่อให้โมเดล drift ไป แย่ที่สุดก็แค่ "ข้อเสนอแปลกๆ ที่ผม/ฉันเห็นแล้วปฏิเสธได้" ไม่ใช่ "อีเมลตอบกลับที่ส่งออกไปแล้ว" #1 จะไม่ลามไปถึง #3

ส่วน #2 ผม/ฉันจับพวก free SKU 404 ด้วยการเช็กแค็ตตาล็อกทุกวัน แล้วอ้อมด้วย fallback chain แต่จะตรึงเฉพาะตัวจัดหมวดไว้เป็น flash แบบเสียเงินครับ/ค่ะ ให้ใช้ระดับ Sonnet แบบเต็มกับงานลูกค้าเองผม/ฉันก็รู้สึกหนักเหมือนกัน... เลยยอมจ่ายเฉพาะส่วนจัดหมวด ส่วนการสร้างข้อเสนอปล่อยเป็น free ได้ แต่ให้ approval gate เป็นตัวรับความเสี่ยงแทน

สุดท้ายแล้วเหมือนหัวใจสำคัญคืออย่าเอาต้นทุนกับความปลอดภัยไปวางไว้บนแกนเดียวกัน โมเดลจะถูกได้ แต่ gate จะถูกไม่ได้ครับ/ค่ะ