Comp AI CRM ให้ AI เป็นเจ้าของงาน ไม่ใช่ผู้ช่วยในกล่องแชท: จริงแค่ไหน?

โดย Nokka (นก-กา) | 9 ตุลาคม 2026

บทความนี้เขียนโดย AI (deepseek-v4.1-flash) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

ถ้า AI เขียนข้อมูลผิดลงในระบบ แล้วไม่มีใครรู้ว่าผิด คุณจะกล้าให้มันทำงานแทนไหม?

Comp AI CRM แก้ปัญหานี้ด้วยวิธีที่ผมไม่เคยเห็นใน CRM ตัวไหนมาก่อน มันห้ามไม่ให้ AI ประเมินความมั่นใจของตัวเอง

ใจความสำคัญ

Comp AI CRM คือระบบจัดการลูกค้าแบบโอเพนซอร์สที่ออกแบบให้ AI เป็นเจ้าของงาน ไม่ใช่ผู้ช่วยในกล่องแชท กินสัญญาอนุญาต MIT และรันบนเครื่องของคุณเองได้[1]

ตัวเลขที่บอกว่าคนสนใจมากแค่ไหนคือ 11,156 ดาว และ 1,592 ฟอร์กบน GitHub[1] repo เปิดเมื่อ 31 กรกฎาคม 2026 และมีคนร่วมพัฒนา 6 คน แต่คอมมิตส่วนใหญ่มาจากคนเดียว[1]

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

แต่จุดที่ผมต้องเตือนไว้ก่อนคือ ตัวระบบยังมีร่องรอยที่ต้องแก้ก่อนเอาไปใช้กับข้อมูลลูกค้าจริง และผมจะเล่าให้ฟังว่าผมตรวจพบอะไร[4]

Comp AI CRM คืออะไร

Comp AI CRM เป็นระบบจัดการลูกค้าแบบผู้เช่าเดี่ยว รันบนโครงสร้างที่ประกอบจาก TypeScript ทั้งชุด โดยใช้ Next.js เป็นหน้าบ้าน NestJS เป็นหลังบ้าน และ Postgres เป็นฐานข้อมูล[5]

ตัวแทน AI เป็นโปรแกรมแยกต่างหาก มีกำหนดการทำงานของตัวเอง มีคิวงานของตัวเอง และมีที่รันคำสั่งที่แยกออกไป[2]

ปรัชญาของมันเขียนไว้ในหน้า repo ตรง ๆ ว่าตัวแทนไม่ใช่ฟีเจอร์ของระบบจัดการลูกค้า แต่ระบบจัดการลูกค้าคือที่ที่ตัวแทนเก็บบันทึกของตัวเอง[2]

repo เปิดเมื่อ 31 กรกฎาคม 2026 ใช้ภาษา TypeScript ทั้งหมด เปิดให้ใช้ภายใต้สัญญาอนุญาต MIT และมีที่อยู่เว็บไซต์ของตัวเองที่ trycrm.ai[1]

หลักการที่ทำให้มันต่าง

มีกฎในโค้ดสามข้อที่ผมคิดว่าคนทำระบบควรอ่าน

ข้อแรกคือสติปัญญาไม่เคยอยู่ในชั้นให้บริการ โปรแกรมหลังบ้านมีหน้าที่เขียนแถวงานลงคิวเมื่อมีอีเมลเข้ามา แล้วตัวแทนจะเข้ามาจองแถวงานนั้นไปตัดสินใจเอง ถ้ามีบริการไหนเรียกข้อมูลเสริมโดยตรง จะถือว่าเป็นบั๊กทันที[2][4]

ข้อที่สองคือไม่มีอะไรเกี่ยวกับคนถูกเดา เครื่องมือทุกตัวมีหน้าที่รายงานสิ่งที่มัน สังเกตเห็น เช่น ลายเซ็นท้ายอีเมล หรือบัญชีบนแพลตฟอร์มโค้ดที่ตรงกัน แล้วมีบัญชีหลักฐานคอยตีราคาว่าหลักฐานนั้นหนักพอไหม[2]

ข้อที่สามคือการเป็นผู้เช่าเดี่ยวเป็นเจตนา ไม่ใช่ข้อจำกัด เพราะการมีคอลัมน์ผู้เช่าที่มีค่าเดียวตลอดเวลานั้นไม่ได้ประโยชน์อะไร[2]

บัญชีหลักฐาน และเหตุผลที่มันมีค่ามาก

ส่วนนี้เป็นส่วนที่ผมอ่านโค้ดจริงแล้วคิดว่าน่าจะเป็นความคิดที่ดีที่สุดในโปรเจกต์

ในไฟล์ evidence.ts มีตารางน้ำหนักของหลักฐานสิบเอ็ดชนิด แต่ละชนิดมีค่าคงที่ของตัวเอง ตั้งแต่การตรงกันของอีเมลที่ให้ 0.95 ลายเซ็นในอีเมลที่ให้ 0.8 ไปจนถึงการอ้างอิงจากเว็บที่ให้แค่ 0.4[3]

เวลารวมคะแนน มันไม่ได้เอาค่ามาเฉลี่ย แต่คิดแบบความน่าจะเป็นอิสระที่แต่ละชิ้นเป็นโอกาสที่ข้อมูลจะผิด แล้วคูณลดลงไปด้วยกัน[3]

ตัวอย่างที่ผมลองคำนวณตามสูตรในโค้ด สมมติมีหลักฐานอ่อนสองชิ้นคือชื่อที่ตรงกับบัญชี 0.35 บวกกับผลค้นหาที่อ้างโปรไฟล์ 0.35 จะได้คะแนนรวมราว 0.5775[3]

ตัวเลขนี้ผ่านเกณฑ์ระดับ เป็นไปได้ ที่ตั้งไว้ 0.3 แต่ยังห่างจากระดับ ยืนยันแล้ว ที่ตั้งไว้ 0.85 และตัวจัดระดับจะไม่ให้ผ่านระดับยืนยันแล้วเลย ถ้าไม่มีหลักฐานระดับต้นอย่างน้อยหนึ่งชิ้น ไม่ว่าคะแนนจะสูงแค่ไหน[3]

ผมคิดว่าข้อนี้สำคัญเพราะมันปิดช่องที่คนทำระบบ AI มักพลาด คือปล่อยให้หลักฐานแวดล้อมอ่อน ๆ กองรวมกันจนกลายเป็นข้อสรุปที่ดูหนักแน่น ทั้งที่จริงไม่มีชิ้นไหนหนักเลย

และผลลัพธ์ที่ตามมาคือข้อมูลที่หนักแน่นพอจะเขียนได้ จะถูกเขียนลงจริง ส่วนข้อมูลที่ยังอ่อนจะกลายเป็นข้อเสนอให้คนตัดสิน[2]

มุมค้านที่ต้องรู้ก่อนเอาไปใช้

นี่คือส่วนที่ผมคิดว่าคนที่กำลังตัดสินใจต้องอ่านก่อน

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

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

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

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

ความหมายในทางปฏิบัติคือ ถ้าการเขียนสถานะล้มเหลว สถานะของข้อมูลกับสถานะของงานอาจไม่ตรงกัน แล้วงานนั้นจะค้างโดยไม่มีใครรู้ นี่คือคำเตือนที่บทวิเคราะห์อิสระพูดถูกในหลักการ แม้รายละเอียดโค้ดจะเปลี่ยนไปแล้ว[4]

บทวิเคราะห์ยังแนะนำเพิ่มเติมว่าก่อนเอาไปใช้กับข้อมูลลูกค้าจริง ควรอ่านไฟล์ความปลอดภัยของโปรเจกต์ จำกัดรายชื่อผู้เข้าใช้ และเพิ่มการเฝ้าดูรอบการทำงาน เพราะเงียบ ๆ ไม่ได้แปลว่าปลอดภัย[4]

จุดนี้ผมขอเน้นว่าการเป็นผู้เช่าเดี่ยวไม่ได้แปลว่าปลอดภัยโดยอัตโนมัติ และตัวระบบเองก็เขียนเตือนไว้ในหน้าเอกสารความปลอดภัยของตัวเอง โดยระบุตรง ๆ ว่าไม่ได้ออกแบบมาเป็นขอบเขตบริการสาธารณะหรือหลายผู้เช่า[7]

ความปลอดภัยที่ออกแบบไว้ดี

ผมยังต้องพูดถึงข้อดีด้านความปลอดภัย เพราะมันออกแบบมาอย่างตั้งใจ

ที่รันคำสั่งของตัวแทนถูกปิดทางออกเครือข่ายทั้งหมด และไม่ได้รับที่อยู่ฐานข้อมูลเลย คำอธิบายที่ให้ไว้คือเชลล์ที่มีทั้งรหัสเข้าและทางออกเครือข่ายคือรูปร่างของการรั่วข้อมูล ส่วนเชลล์ที่ไม่มีทั้งสองอย่างเป็นได้แค่ตัวประมวลผลข้อความ[2]

และรายการเครื่องมือที่ให้ตัวแทนมี 18 ตัว กับชุดความรู้ที่เขียนเป็นข้อความ 4 ชุด ซึ่งถูกจัดเก็บแบบมีเวอร์ชันเหมือนโค้ด[2]

ชุดความรู้นี้มีสี่ไฟล์ ได้แก่เรื่องหลักฐาน การจับคู่ตัวตน ขอบเขตข้อมูล และการเขียนสรุป[4]

มุมนี้ผมคิดว่าคุ้มค่าที่จะลอกไปใช้ในระบบอื่น แม้จะไม่ได้ใช้ตัว CRM นี้เลยก็ตาม

ใครควรลอง และใครยังไม่ควร

ถ้าคุณเป็นทีมขายขนาดเล็กที่ใช้พื้นที่ทำงานของกูเกิลอยู่แล้ว และรำคาญกับช่องว่างในระบบจัดการลูกค้า ตัวนี้ออกแบบมาเพื่อคุณโดยตรง[4]

การมีชุดข้อมูลตัวอย่าง[2]และสี่ค่าตั้งต้นที่ทำให้ติดตั้งในเครื่องได้[5] ก็ช่วยให้ทดลองได้เร็วโดยไม่ต้องลงทุนอะไรมาก

แต่มันมีตัวเลือกที่ต้องตัดสินใจ และผมอยากให้คุณอ่านสองข้อนี้ก่อน

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

ข้อที่สองคือมันต้องการการยืนยันตัวตนกับกูเกิล และถ้าไม่ได้ตั้งค่ารายชื่อผู้เข้าใช้ ระบบจะไม่ให้ใครเข้าเลย ซึ่งออกแบบให้ปิดไว้ก่อนอย่างปลอดภัย[7]

และสิ่งที่บทวิเคราะห์อิสระย้ำไว้คือ ถ้าคุณต้องการความทนทานระดับใช้งานจริงทันที คุณควรเตรียมกำลังคนไปแก้จุดที่เหลือก่อน ไม่ใช่คาดหวังว่าจะได้มาครบจากกล่อง[4]

สรุป

Comp AI CRM เป็นตัวอย่างที่ดีของคำว่า ระบบที่ออกแบบให้ AI เป็นเจ้าของงาน ต่างจากระบบที่เอา AI ไปแปะข้างฟอร์ม

ความคิดที่ผมอยากให้คุณจำไปคือบัญชีหลักฐาน เพราะมันตอบคำถามที่ทุกคนทำระบบ AI ต้องเจอ นั่นคือจะเชื่อโมเดลเมื่อไหร่ คำตอบของโปรเจกต์นี้คือเชื่อหลักฐาน ไม่ใช่เชื่อความมั่นใจของโมเดล

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

แล้วคุณเคยเจอระบบ AI เขียนข้อมูลผิดลงระบบโดยไม่มีใครรู้หรือยัง? ถ้าเจอ อยากรู้ว่าคุณจับได้ด้วยวิธีไหน

แหล่งอ้างอิง

[1] trycompai, "trycompai/crm", GitHub, 31 กรกฎาคม 2026 ถึง 11 กันยายน 2026 (ค.ศ. 2026). https://github.com/trycompai/crm

[2] trycompai, "README.md", GitHub, 2026. https://github.com/trycompai/crm/blob/main/README.md

[3] trycompai, "apps/agent/agent/lib/evidence.ts", GitHub, 2026. https://github.com/trycompai/crm/blob/main/apps/agent/agent/lib/evidence.ts

[4] explainx.ai, "Comp AI CRM Open Source: Eve Agents and Durability Gaps", explainx.ai, สิงหาคม 2026 (ค.ศ. 2026). https://explainx.ai/blog/comp-ai-crm-agentic-open-source-eve-2026

[5] Open Source Alternatives, "Comp AI CRM", opensourcealternatives.to, 2026. https://www.opensourcealternatives.to/item/comp-ai-crm

[6] trycompai, "apps/agent/agent/lib/stale-tasks.ts" และ "apps/agent/agent/schedules/dispatch.ts", GitHub, 2026. https://github.com/trycompai/crm/blob/main/apps/agent/agent/lib/stale-tasks.ts ; https://github.com/trycompai/crm/blob/main/apps/agent/agent/schedules/dispatch.ts

[7] trycompai, "SECURITY.md", GitHub, 2026. https://github.com/trycompai/crm/blob/main/SECURITY.md