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

Comp AI CRM แก้ปัญหานี้ด้วยการให้ AI agent ค้นข้อมูลแล้วบันทึกลงเรคคอร์ดเอง พนักงานจึงไม่ต้องค้นและกรอกข้อมูลทั้งหมดด้วยตัวเอง CRM ทำหน้าที่เก็บข้อมูลที่ agent บันทึกไว้ โค้ดทั้งหมดใช้สัญญาอนุญาต MIT และนำไปติดตั้งบนเครื่องของตัวเองได้ วันที่ 7 สิงหาคม 2026 โปรเจกต์นี้มี 7.3 พันดาวและ 768 fork บน GitHub

งานที่หนักที่สุดใน CRM ยังตกอยู่กับคนมาตลอด

คำอธิบายในรีโปนี้ระบุปัญหาไว้ตรงๆ

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

Comp AI CRM จึงให้ agent ค้นข้อมูลเป็นประจำ แล้วให้พนักงานตรวจข้อมูลที่ agent บันทึกไว้

agent มีคิวงานของตัวเอง ปิดเบราว์เซอร์แล้วมันยังทำต่อ

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

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

ถ้า agent ต้องการกลับมาตรวจข้อมูลของใครอีกครั้ง มันจะใช้คำสั่งนัดตรวจซ้ำและบันทึกเหตุผลไว้ พนักงานที่ดูแลเรคคอร์ดจะเห็นเหตุผลนั้นด้วย

agent มีส่วนประกอบสามส่วน ส่วนแรกคือเครื่องมือ 18 ตัวที่ agent เรียกใช้ได้ เช่น เครื่องมืออ่านประวัติในเรคคอร์ด ค้นข้อมูลใน CRM ระบุตัวตนของผู้ติดต่อ ค้นข้อมูลบุคคล เพิ่มข้อมูลบริษัท บันทึกข้อเท็จจริง และนัดตรวจซ้ำ ส่วนที่สองคือสกิล 4 ไฟล์ ได้แก่ evidence.md identity-matching.md data-boundaries.md และ writing-a-brief.md ไฟล์เหล่านี้เขียนด้วยมาร์กดาวน์เพื่อให้ agent อ่าน ระบบเก็บทุกไฟล์ไว้เป็นเวอร์ชัน จึงตรวจได้ว่าใครแก้อะไร ส่วนที่สามคือตัวจัดตาราง ต้นทางระบุว่าส่วนนี้ไม่ตัดสินใจอะไร หน้าที่ของมันคือเริ่มงานที่ถึงกำหนด โดยเริ่มงานละหนึ่งรอบ

โมเดลเริ่มต้นคือ zai/glm-5.2-fast ต้นทางระบุว่าโมเดลนี้ไม่ใช่โมเดลระดับแนวหน้า เพราะระบบใช้เครื่องมือและการประเมินความน่าเชื่อถือของหลักฐานเพื่อรักษาความถูกต้องของข้อมูล ไม่ได้ใช้โมเดลที่เก่งกว่าเพื่อให้ข้อมูลถูกต้อง ระบบใช้ eve ซึ่งเป็นเฟรมเวิร์กของ Vercel เพื่อให้ agent ทำงานต่อได้แม้จะมีการดีพลอยระหว่างรอบการทำงานที่ใช้เวลานาน

กฎเหล็กข้อเดียวคือห้ามเดาเรื่องคน

ส่วนนี้นำไปใช้กับระบบอื่นได้ แม้จะไม่ได้ติดตั้ง CRM ตัวนี้

ระบบห้าม agent เดาข้อมูลเกี่ยวกับคน โดยออกแบบเครื่องมือให้ทำตามกฎนี้แทนการเขียนคำสั่งขอให้โมเดลทำตาม เครื่องมือแต่ละตัวรายงานได้เฉพาะข้อมูลที่พบจริง เช่น ตำแหน่งงานในลายเซ็นท้ายอีเมล หรือบัญชี GitHub ที่ยืนยันแล้วว่าเป็นของคนนั้น จากนั้นระบบจะแยกหลักฐานเหล่านี้ไว้ และประเมินว่าหลักฐานแต่ละชิ้นน่าเชื่อถือแค่ไหน

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

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

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

ทุกเรคคอร์ดมีแท็บ Agent ให้ย้อนดูว่ามันทำอะไรไป

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

พนักงานควรเห็นทั้งข้อมูลที่ agent ไม่เลือกและข้อมูลที่ agent บันทึก เพราะถ้าเห็นเฉพาะผลลัพธ์ พนักงานจะตรวจไม่ได้ว่าข้อมูลที่ถูกตัดออกนั้นเป็นข้อมูลที่ใช้ไม่ได้หรือลูกค้าจริง

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

ไม่ใส่คีย์บริการภายนอกสักตัวก็ยังใช้งานได้

บริการภายนอกทุกตัวเป็นส่วนเสริม ระบบนี้จึงทำงานได้แม้จะไม่ใส่คีย์ของบริการเหล่านั้น ข้อมูลหลักมาจากกล่องอีเมลและปฏิทินขององค์กร รวมถึงลายเซ็นท้ายอีเมลที่คู่สนทนาใส่มาในแต่ละฉบับ ต้นทางระบุว่านี่เป็นหลักฐานที่ดีที่สุดที่หาได้ เพราะผู้ขายข้อมูลไม่มีอีเมลตอบกลับที่เจ้าตัวส่งจากที่อยู่อีเมลของตัวเอง

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

[agent] on LinkedIn (RAPIDAPI_KEY)
[agent] off Web research (PERPLEXITY_API_KEY)
[agent] off Company brand data (Settings → General)

ข้อมูลนี้ช่วยให้ agent วางแผนตามเครื่องมือที่ใช้ได้ตั้งแต่เริ่มทำงาน จึงไม่ต้องลองเรียกเครื่องมือทีละตัวแล้วรอให้เกิดข้อผิดพลาดก่อน

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

ยกขึ้นมารันบนเครื่องตัวเอง

ก่อนเริ่มต้องติดตั้ง Bun และ Docker จากนั้นให้รันคำสั่งต่อไปนี้ตามลำดับ

git clone https://github.com/trycompai/crm.git && cd crm
cp .env.example .env
bun install
docker compose up -d
bun run db:deploy
bun run db:seed
bun run dev

คำสั่งสามบรรทัดตรงกลางทำหน้าที่ต่างกัน

• docker compose up -d เปิด Postgres บนเครื่องที่พอร์ต 5432
• bun run db:deploy ติดตั้งโครงสร้างฐานข้อมูลทั้งหมด
• bun run db:seed เป็นคำสั่งเสริมสำหรับโหลดข้อมูลตัวอย่างให้ทดลองใช้ หากต้องการเริ่มด้วยระบบที่ไม่มีข้อมูล ให้ข้ามคำสั่งนี้

เมื่อรันคำสั่งครบแล้ว หน้าเว็บจะอยู่ที่ localhost:3000 ส่วน API จะอยู่ที่ localhost:3001

ขั้นตอนที่ต้องกรอกข้อมูลเองมีเพียงขั้นตอนเดียว คือใส่ค่าสี่ตัวในไฟล์ .env

หากต้องการคู่คีย์ Google ให้เปิดหน้า Google Cloud console แล้วเข้าเมนู Credentials จากนั้นสร้าง OAuth client ID แบบ Web application ตั้งที่อยู่เรียกกลับเป็น http://localhost:3001/api/auth/callback/google แล้วเปิด Gmail API กับ Calendar API ให้โปรเจกต์นั้น สุดท้ายให้คัดลอกคีย์ทั้งคู่ไปใส่ในไฟล์ .env

ค่าที่เหลือใช้สำหรับเพิ่มความสามารถตามต้องการ

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

ข้อจำกัดที่ควรรู้ก่อนตัดสินใจ

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

ค่า ALLOWED_SIGN_IN เป็นตัวกำหนดว่าใครเข้าใช้งานระบบได้ และไม่มีวิธีอนุญาตแบบอื่น ถ้าไม่ตั้งค่านี้ จะไม่มีใครล็อกอินได้ เพราะระบบตั้งใจให้ค่าเริ่มต้นปลอดภัย

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

กฎห้ามเดา เอาไปใช้กับงาน AI ของตัวเองได้เลย

วิธีคิดสามส่วนของระบบนี้ใช้กับงาน AI อื่นได้ แม้จะไม่ได้ใช้ CRM ตัวนี้

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

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

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

โค้ดทั้งหมดอยู่บน GitHub และใช้สัญญาอนุญาต MIT ผู้ที่ต้องการดูว่าระบบใช้กฎห้ามเดาอย่างไร สามารถเปิดอ่านโค้ดได้ทันที

ที่มา: โปรเจกต์ Comp AI CRM บน GitHub