ปรับใช้ AI เอเจนต์บน VPS ราคา $7/เดือน และสร้างดิจิทัลโดร์แมนโดยใช้ IRC เป็นชั้นขนส่ง

 (georgelarson.me)
4 คะแนน โดย GN⁺ 2026-03-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เชื่อมต่อ AI เอเจนต์ที่ใช้ IRC เข้ากับเว็บไซต์พอร์ตโฟลิโอส่วนตัว เพื่อให้ผู้เยี่ยมชมสามารถถามคำถามและรับคำตอบโดยอิงจาก ผลการวิเคราะห์โค้ดใน GitHub repository จริง
  • ไม่ใช่แค่แชตบอตสรุปเรซูเม่แบบง่าย ๆ แต่ถูกออกแบบเป็น เอเจนต์แบบลงมือทำจริง ที่สามารถ โคลนรีโพซิทอรี·คำนวณการทดสอบ·ตรวจสอบโค้ด ได้
  • ระบบแยกเป็นสองเอเจนต์คือ nullclaw สำหรับสาธารณะ และ ironclaw สำหรับส่วนตัว โดยสื่อสารกันอย่างปลอดภัยผ่าน เครือข่าย Tailscale
  • เลือกใช้ โปรโตคอล IRC เป็นชั้นขนส่ง เพื่อให้ได้ทั้ง โฮสต์เองได้·เป็นมาตรฐาน·ต้นทุนต่ำ พร้อมแยกบทบาทของ โมเดล Haiku 4.5 และ Sonnet 4.6 เพื่อจำกัดค่าใช้จ่ายไว้ที่ $2 ต่อวัน
  • ทั้งระบบทำงานด้วย ไบนารีรวมไม่ถึง 10MB·หน่วยความจำไม่ถึง 5MB และถูกนำเสนอเป็นตัวอย่างของ โครงสร้างพื้นฐาน AI แบบเบา ที่ได้ทั้ง ความปลอดภัย·ต้นทุน·ความโปร่งใส

สร้างดิจิทัลโดร์แมน

  • โครงสร้างที่ติดตั้ง AI เอเจนต์ บน VPS ราคา $7/เดือน และใช้ IRC server ส่วนตัวเป็นชั้นขนส่งเพื่อเชื่อมกับ GitHub repository
    • ผู้เยี่ยมชมสามารถถาม AI ผ่านเว็บไซต์พอร์ตโฟลิโอ และรับคำตอบที่อิงจากโค้ดจริงได้
    • ไม่ใช่แชตบอตสรุปเรซูเม่แบบผิวเผิน แต่ให้คำตอบที่เฉพาะเจาะจงผ่านการวิเคราะห์โค้ด

ข้อจำกัดของ "แชตบอตที่ตอบคำถามเกี่ยวกับเรซูเม่"

  • แชตบอตพอร์ตโฟลิโอส่วนใหญ่ยังอยู่แค่ระดับ ป้อนเนื้อหาเรซูเม่เข้าโมเดล แล้วให้เรียบเรียงใหม่
  • วิธีนี้ไม่ได้ให้ข้อมูลใหม่ และเป็นเพียง การสนทนาเชิงรูปแบบ เท่านั้น
  • สำหรับคำถามอย่าง “จัดการ test coverage อย่างไร?” จำเป็นต้องมีคำตอบเชิงรูปธรรม เช่น โคลนรีโพซิทอรีแล้วคำนวณจำนวนเทสต์
  • เพื่อสิ่งนี้ จึงสร้าง โครงสร้างพื้นฐานที่เข้าถึงและวิเคราะห์โค้ดได้โดยตรง

สถาปัตยกรรมระบบ

  • ประกอบด้วย เอเจนต์ 2 ตัว, เซิร์ฟเวอร์ 2 เครื่อง, ขอบเขตความปลอดภัย 2 ชั้น
    • nullclaw: โดร์แมนสาธารณะ, Zig binary ขนาด 678KB, ใช้ RAM ราว 1MB
      • ทักทายผู้เยี่ยมชม, ตอบคำถามเกี่ยวกับโปรเจกต์, โคลน GitHub repository และตรวจสอบข้อมูลจากโค้ดจริง
    • ironclaw: เอเจนต์แบ็กเอนด์แบบส่วนตัว ทำงานบนอีกระบบหนึ่ง
      • เข้าถึงอีเมล, ตารางเวลา, และคอนเท็กซ์ส่วนตัวได้
      • รับคำขอที่ซับซ้อนจาก nullclaw ผ่าน IRC channel #backoffice
  • ทั้งสองระบบเชื่อมต่อกันผ่าน Tailscale และเซิร์ฟเวอร์สาธารณะไม่สามารถเข้าถึงข้อมูลส่วนตัวได้

เหตุผลที่เลือก IRC

  • ความสอดคล้องด้านสุนทรียะ: เว็บไซต์พอร์ตโฟลิโอใช้ UI แบบเทอร์มินัล จึงเข้ากับ IRC client ได้อย่างเป็นธรรมชาติ
  • โฮสต์เองได้ทั้งหมด: ทั้ง Ergo IRC server, gamja web client และ nullclaw รันอยู่บนโครงสร้างพื้นฐานของตนเอง
  • โปรโตคอลที่เรียบง่ายและเป็นมาตรฐาน: IRC ที่มีมา 30 ปี ไม่ผูกกับผู้ให้บริการรายใด, ไม่มีความเสี่ยงจากการเปลี่ยน API
  • เอเจนต์ตัวเดียวกันทำงานได้เหมือนกันทั้งบนเว็บไคลเอนต์และ irssi terminal client

การเลือกและออกแบบโมเดล

  • การใช้โมเดลขนาดใหญ่ตลอดเวลาไม่มีประสิทธิภาพ จึงแยกโมเดลตามบทบาท

    • Haiku 4.5**: ใช้สำหรับบทสนทนาและคำถามง่าย ๆ,** ตอบสนองหน่วงต่ำมาก

      • Sonnet 4.6: ใช้เฉพาะตอนวิเคราะห์โค้ดและทำ reasoning ที่ซับซ้อน
      • เพดานค่าใช้จ่าย: จำกัดไว้ที่ $2 ต่อวัน, $30 ต่อเดือน
      • ป้องกันค่าใช้จ่ายพุ่งจากการใช้งานที่เป็นอันตรายหรือบทสนทนาที่มากเกินไป
      • ด้วย โครงสร้าง reasoning แบบลำดับชั้น จึงได้ทั้ง ความเร็วและประสิทธิภาพด้านต้นทุน

การออกแบบความปลอดภัย

  • SSH: ปิด root login, อนุญาตเฉพาะ key authentication, ใช้พอร์ตที่ไม่ใช่มาตรฐาน
  • ไฟร์วอลล์: เปิดเฉพาะ SSH, IRC(TLS), HTTPS(WebSocket)
  • Cloudflare proxy: ทำ TLS termination, rate limiting, และ bot filtering
  • แซนด์บ็อกซ์ของเอเจนต์: อนุญาตเฉพาะเครื่องมือแบบอ่านอย่างเดียว, จำกัดแอ็กชัน 10 ครั้งต่อชั่วโมง
  • การควบคุมค่าใช้จ่าย: hard cap ที่ $2 ต่อวัน, $30 ต่อเดือน
  • เปิดใช้งาน audit log และ auto update
  • ลดพื้นผิวการโจมตีให้เล็กที่สุด: รันเพียงสองบริการคือ ergo และ nullclaw, ไม่มีการเสิร์ฟเว็บคอนเทนต์โดยตรง
  • หากเกิดการเจาะระบบ ความเสียหายจะถูกจำกัดไว้ที่ IRC bot ที่มีวงเงิน $2/วัน

การจัดสแตกการสื่อสาร

  • ทุกองค์ประกอบมีลักษณะเป็น ขนาดเล็ก·โฮสต์เองได้·สลับทดแทนได้
    • Ergo: IRC server, Go binary เดี่ยว, ใช้ RAM 2.7MB
    • gamja: เว็บ IRC client, หน้า static ขนาด 152KB, ให้บริการหลัง Cloudflare
    • nullclaw: รันไทม์ AI เอเจนต์, Zig binary ขนาด 4MB, ใช้หน่วยความจำราว 1MB
  • ทั้งระบบทำงานด้วย ไบนารีรวมไม่ถึง 10MB และ หน่วยความจำขณะ idle ไม่ถึง 5MB
  • จึงเพียงพอแม้กับ VPS ระดับราคาถูกที่สุด

ความสามารถจริงของ nully (เอเจนต์สาธารณะ)

  • ระบุภาษาโปรแกรม: ตรวจสอบผ่านคอนเท็กซ์ที่โหลดไว้ล่วงหน้าและการยืนยันจากรีโพซิทอรี
  • วิเคราะห์โครงสร้างการทดสอบ: โคลนรีโพซิทอรีแล้วอ่านไฟล์ทดสอบโดยตรงเพื่อรายงานผล
  • อธิบายโปรเจกต์: เช่น ตอบรายละเอียดของโปรเจกต์ Fracture โดยอิงจากโค้ดจริง
  • ให้ข้อมูลติดต่อ: ให้เฉพาะข้อมูลติดต่อที่ถูกต้อง ไม่มีการแต่งข้อมูลขึ้นมา
  • คำขอนัดหมาย: ส่งต่อไปยัง ironclaw ผ่าน Google A2A protocol และส่งผลกลับมาในรูปแบบที่มีโครงสร้าง
  • ผู้เยี่ยมชมจะ ไม่รับรู้กระบวนการสลับไปยังแบ็กเอนด์

การใช้งาน A2A

  • รองรับ Google A2A protocol (v0.3.0) และจัดการสถานะงานบนพื้นฐาน JSON-RPC
  • เครื่องมือ a2a_call จะส่งข้อความไปยังเอเจนต์ระยะไกลและแยกวิเคราะห์ สถานะงาน (เสร็จสิ้น/ล้มเหลว/กำลังดำเนินการ)
  • บังคับใช้ HTTPS แต่ใน เครือข่ายภายใน Tailscale อนุญาต HTTP เพื่อความสะดวกในการดีบัก

  • โครงสร้างฝั่ง ironclaw

    • อินสแตนซ์ของ nullclaw ใช้ LLM gateway ของ ironclaw เป็นพร็อกซีโดยไม่ต้องมี API key ของตัวเอง
    • ดูแลเพียง API key และความสัมพันธ์ด้านการชำระเงินชุดเดียว
    • ironclaw เป็นผู้จัดการคำขอ inference ทั้งหมดและรับภาระค่าใช้จ่าย

ความปลอดภัยของการ handoff

  • A2A endpoint มี ความเสี่ยงจาก prompt injection จึงมีการจำกัดอย่างเข้มงวด
    • คำขอที่ส่งต่อไปยัง ironclaw ได้จำกัดเฉพาะเรื่อง ตารางเวลา, ข้อมูลติดต่อ, ความพร้อมใช้งาน
    • ปฏิเสธการส่งคำสั่งตามอำเภอใจ
    • A2A endpoint ของ ironclaw ได้รับการปกป้องด้วย ไฟร์วอลล์ที่ใช้ได้เฉพาะ Tailscale
    • ทั้งสองเอเจนต์รันด้วย โหมดเฝ้าระวังและ allowlist ของคำสั่งที่จำกัด
  • nully เป็นผู้ตัดสินใจว่าจะยกระดับคำขอหรือไม่ เพื่อป้องกันการรันคำสั่งแบบไร้การควบคุม

บทเรียนจากการสร้างระบบ

  • การเลือกโมเดลเป็นส่วนหนึ่งของการออกแบบระบบ และส่งผลโดยตรงต่อค่าใช้จ่าย, latency, และประสบการณ์ใช้งาน
  • ใช้เวลากับ การสื่อสาร, ความปลอดภัย, และการจัดโครงสร้างพื้นฐาน มากกว่าตัวเอเจนต์เอง
  • ความเรียบง่ายและเปิดกว้างของ IRC เหมาะอย่างยิ่งสำหรับเป็นชั้นขนส่งของ AI เอเจนต์
  • สถาปัตยกรรมแยก nullclaw–ironclaw คือแกนหลักของโมเดลความปลอดภัย
  • การใช้ A2A protocol ควบคู่กับ IRC log channel ทำให้ได้ทั้งการสื่อสารแบบมีโครงสร้างและการมองเห็นแบบเรียลไทม์
  • ป้องกันการทำสำเนาข้อมูลรับรองซ้ำซ้อน: ใช้ gateway ของ ironclaw เป็นพร็อกซีเพื่อคงไว้ซึ่ง API key เดียว·ความสัมพันธ์การชำระเงินเดียว

วิธีทดลองใช้

  • เข้า georgelarson.me/chat หรือพิมพ์ irc ในเทอร์มินัลบนหน้าแรก
  • หากใช้ IRC client: irc.georgelarson.me, พอร์ต 6697 (TLS), channel #lobby
  • nully กำลังรออยู่และพร้อมสนทนาแบบเรียลไทม์กับผู้เยี่ยมชม

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-03-28
ความคิดเห็นจาก Hacker News

  • หาก OpenClaw agent ที่เข้าถึงอีเมลและข้อมูลส่วนตัวถูกเจาะ ความเสียหายอาจกว้างมาก
    มันไม่ใช่แค่บอต IRC ธรรมดา แต่ผู้โจมตีอาจรีเซ็ตรหัสผ่านเพื่อปลดข้อจำกัด API หรือแม้กระทั่งนำไปใช้เป็นฮับแชร์คอนเทนต์ผิดกฎหมายได้

    • ฉันก็รู้จักคนที่รัน OpenClaw agent แบบนี้บน Mac Mini และแปลกดีที่คนซึ่งปกติระวังเรื่องความปลอดภัยมากกลับไม่ค่อยรู้สึกถึงความเสี่ยงนี้
    • ถ้าที่คุณพูดเป็นจริง ก็ดูเหมือนเป็นตัวอย่างที่แสดงให้เห็นว่ามนุษย์ทำตัวอย่างไรใน “สภาพแวดล้อมที่ไม่มีราวกันตก”

  • ฉันสงสัยว่าทำไมถึงเลือก Haiku/Sonnet เพราะบน OpenRouter มีโมเดลที่ถูกกว่านี้มาก
    ตัวอย่างเช่น Haiku 4.5 ราคา $1 ต่ออินพุต 1 ล้านโทเค็น และ $5 ต่อเอาต์พุต ขณะที่ MiniMax M2.7 อยู่ที่อินพุต $0.30 เอาต์พุต $1.20 และ Kimi K2.5 อยู่ที่อินพุต $0.45 เอาต์พุต $2.20
    จากประสบการณ์ของฉัน M2.7 กับ K2.5 ก็ให้ประสิทธิภาพใกล้เคียงหรือดีกว่า Haiku

    • ถ้ารันแบบสาธารณะบน IRC แล้ว safety rails อาจเป็นปัจจัยสำคัญ
      ช่วงนี้ฉันก็ใช้โมเดลของ Anthropic ตอนทำ agent ด้วยเหตุผลนี้เหมือนกัน Haiku คุมผู้ใช้ที่โยนคำขอแปลก ๆ ได้ดี และรับมือบทสนทนาเชิงอารมณ์ได้เสถียร
    • Xiaomi Mimo v2-Flash ยอดเยี่ยมมาก ในเบนช์มาร์กของฉันมันเร็วกว่า Haiku 8% และถูกกว่าถึง 80 เท่า Gemini 3.1 Flash Lite Preview ก็เป็นตัวเลือกที่ดีเหมือนกัน
    • MiniMax M2.7 ก็ใช้เขียนโค้ดได้ดีพอสมควร แต่ Opus 4.6 ก็ยังเหนือกว่าอยู่อีกระดับ
    • Token Plan ของ MiniMax ถูกกว่า และอนุญาตให้ใช้งานกับ agent อย่างชัดเจนด้วย
    • ฉันคิดว่าใช้ Gemini Flash3 ไปเลยยังดีกว่า Haiku

  • IRC ดีในฐานะ transport layer แต่ไม่มี delivery guarantee ถ้าการเชื่อมต่อหลุด ข้อความช่วงนั้นก็หายไปเลย
    มันโอเคสำหรับแชตแบบเรียลไทม์ แต่ถ้าเป็น agent ที่ต้องทำงานจริง ควรมีการส่งแบบ at-least-once
    SSE(Server-Sent Events) เป็นทางสายกลางที่ดี เพราะเชื่อมต่อค้างไว้ได้และสามารถเพิ่มลอจิกส่งซ้ำเข้าไปได้

    • แต่ IRC มี bouncer มานานมากแล้ว ดังนั้นในทางเทคนิคก็สามารถทำ at-least-once ได้

  • ฉันเคยทำบอตแนวคิดคล้ายกันบนรถไฟจากโตเกียวไปโอซาก้า
    web-support-claw.oncanine.run — เป็นโปรเจกต์ที่อ่าน GitHub repo แล้วสร้าง intercom bot สำหรับเว็บไซต์
    มันตอบคำถามของผู้เข้าชมได้ จึงไม่จำเป็นต้องทำ knowledge base แยกต่างหาก

    • แต่ถ้ามีคนขอให้ “วิเคราะห์ช่องโหว่ในหน้าชำระเงิน” หรือ “หาคีย์ลับที่ hardcode ไว้” ได้ ก็ถือว่า เสี่ยงด้านความปลอดภัย มาก

  • ต่อไปฉันแนะนำให้มี Haiku instance หนึ่งตัวไว้คอยเฝ้าระวัง และจะรับแจ้งเตือนผ่าน ntfy ก็ได้
    ตอนนี้ห้องแชตควบคุมไม่ได้โดยสิ้นเชิงแล้ว

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

  • ทีมของเราก็ใช้โครงสร้างคล้ายกัน เป็น message board ที่สร้างด้วย FastAPI + SQLite ให้ agent 4 ตัว (ฝ่ายขาย โซเชียล การเงิน กลยุทธ์) สื่อสารกัน
    แทนที่จะจำกัดงบรายวัน เราจัดการ เพดานค่าใช้จ่ายใน governance layer
    โครงสร้าง pub/sub ของ IRC เหมาะกับการสื่อสารแบบหลาย agent แต่เราใช้ HTTP polling + การตัดข้อความซ้ำ แทน แม้จะไม่สวยเท่า แต่กู้คืนได้ง่ายเมื่อ agent ล่มบ่อย

  • ฉันก็ใช้ IRC เป็นอินเทอร์เฟซ ใน agent สำหรับเขียนโค้ด
    ฉันสลับห้องเพื่อเปลี่ยนพรอมป์ต์ และควบคุมโปรเจกต์จากระยะไกล

    • สงสัยว่า IRC ยังมี ข้อจำกัดความยาวข้อความ อยู่ไหม
    • ฉันก็ใช้อยู่แบบเดียวกัน ถ้าได้ลองเทียบกันก็น่าจะดี

  • มีคนบอกว่า “กล่องสาธารณะไม่เข้าถึงข้อมูลส่วนตัว” ซึ่งถ้าเอาไปทำเป็น CTF challenge ก็น่าจะสนุกดี
    ซ่อน flag ไว้ในกล่องส่วนตัว แล้วถ้าใครเข้าถึงและเอามาได้ก็ให้ 50 ดอลลาร์

  • ท่าทีของ nully จะค่อนข้างแข็งไปหน่อย แต่ฉันชอบ โครงสร้างระบบ โดยรวม
    ฉันก็ใช้โครงสร้างแบบเป็นชั้น ๆ โดยชั้นล่างสุดเป็น Qwen local bot
    ฉันสงสัยเรื่อง ลอจิกการ escalation จาก Haiku ไป Opus

    • ฉันใช้โครงสร้างที่ยกระดับจาก Haiku ไป Opus เมื่อคำขอเริ่มซับซ้อนขึ้น ได้แรงบันดาลใจจากแนวคิด “think hard” ของ Claude Code
    • ถ้าเปลี่ยนข้อความ “An error occurred” เป็น “ตอนนี้มีผู้ใช้จำนวนมาก กรุณาลองใหม่อีกครั้งในภายหลัง” ก็น่าจะดูน่าสนใจกว่าสำหรับคนสรรหา

  • ไอเดียนี้น่าสนใจมาก ทำให้อยากสร้างบอตสำหรับ ทำกระบวนการรับสมัครงานอัตโนมัติ
    มันอาจสัมภาษณ์เพื่อดูแนวโน้มของผู้สมัคร จากนั้นหาตำแหน่งที่เหมาะและสมัครให้โดยอัตโนมัติ
    ถ้าบอตฝั่งบริษัทก็ประเมินผู้สมัครแบบเดียวกัน ก็อาจจับคู่กันได้ตามความชอบของทั้งสองฝ่าย
    สามารถทำเป็น โอเพนซอร์สแบบ self-hosted ได้ทั้งหมด และน่าจะให้สัญญาณที่ดีกว่าเรซูเม่มาก

    • ถ้าบอตช่วยทำ การบ้านที่ไม่ได้รับค่าจ้าง แทนได้ด้วยก็คงดียิ่งขึ้น แล้วให้ HR bot ดูผลลัพธ์เพื่อตัดสินการจ้างงาน
    • เมื่อก่อน Triplebyte เคยลองทำอะไรคล้ายกัน ดูเหมือนถึงเวลาที่แนวคิดนี้จะกลับมาอีกครั้ง
    • แต่ UI สมัครงานของแต่ละบริษัทต่างกันหมด ถ้าจะให้บอตสมัครทุกเว็บอัตโนมัติก็ต้องฝึกอีกมาก
    • ถ้ามีระบบแบบนี้ขึ้นมา ก็อาจมีทั้ง ผู้สมัครสแปม และ บัญชีปลอม ล้นระบบ
    • ตอนนี้ฉันก็กำลังทำโปรเจกต์แนวนี้อยู่แล้ว