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

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

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

Multica ไม่ได้เขียนโค้ดเอง แต่เป็นคนจ่ายงานให้ CLI ที่เรามีอยู่

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

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

ข้อดีของการทำหน้าที่แค่คนสั่งงานคือเปลี่ยนผู้ให้บริการได้จากเมนูเลือกเพียงจุดเดียว ไม่ต้องรื้อระบบงานใหม่ทั้งชุด ตารางของโปรเจกต์มีรายชื่อ CLI ที่รองรับมากกว่ายี่สิบรายการ ตั้งแต่ Claude Code, Codex, Cursor ไปจนถึง GitHub Copilot CLI, Kimi และ Qwen Code

โจทย์เรื่องการรวม agent หลายตัวไว้ในที่เดียวไม่ได้มีแค่แนวทางเดียว GitHub Copilot app ก็รวม AI agent หลายตัวให้ทำงานขนานกันในแอปเดสก์ท็อปเดียวเหมือนกัน ส่วนทางที่ Multica เลือกคือเปิดซอร์ส ยกทั้งระบบไปรันบนเครื่องของทีมเองได้ และผูกงานทุกอย่างไว้กับ issue

หน่วยของงานเปลี่ยนจากพรอมต์เป็น issue

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

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

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

ใช้หลาย agent พร้อมกัน โดยไม่ต้องนั่งจ่ายงานทีละใบ

พอ agent มีหลายตัว คนจ่ายงานจะกลายเป็นคอขวดแทน โปรเจกต์เลยเตรียมสามอย่างนี้ไว้

• Squads ระบบจัดทีมสำหรับงานที่ต้องใช้หลายมือ รวมคนกับ agent ไว้เป็นทีมเดียว แล้วมีหัวหน้าทีมคอยแจกงานให้สมาชิก
• Skills ระบบบันทึกทักษะสำหรับปัญหาที่เจอซ้ำ เก็บวิธีแก้ที่ใช้ได้ผลไว้เป็นคู่มืออย่าง playbook เพื่อให้ agent ตัวอื่นหยิบไปใช้ต่อ
• Autopilots ระบบทำงานอัตโนมัติสำหรับงานที่ต้องทำตามเวลา ตั้งให้สรุปงานประจำวัน ตรวจความเรียบร้อยของระบบ หรือทำรายงานตามรอบได้เอง

สิ่งที่ทำให้เรียกว่าเพื่อนร่วมทีมได้ คือร่องรอยที่มันทิ้งไว้

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

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

การแจ้งเตือนก็ไม่ได้เด้งทุกขั้นตอน กล่องแจ้งเตือนอย่าง Inbox จะเรียกเฉพาะตอนที่ agent ต้องการให้คนตัดสินใจ ส่วนงานที่รันพลาดจะลองใหม่ให้เองหรือหยุดพร้อมบอกเหตุผล ฝั่งการจัดการสิทธิ์แบ่งเป็นสามระดับคือเจ้าของ (owner), ผู้ดูแล (admin) และสมาชิก (member) พร้อมกำหนดขอบเขตสิทธิ์การใช้งานอย่าง access scope ได้ว่าสมาชิกคนไหนสั่ง agent ตัวใดได้บ้าง

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

เริ่มจากการเชื่อมเครื่องแรก

ขั้นแรกคือเข้าใช้งานผ่านเบราว์เซอร์ที่ multica.ai หรือลง Multica Desktop ที่มีให้ทั้ง macOS, Windows และ Linux

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

ตัวเดสก์ท็อปจะลงทะเบียนเครื่องที่รันอยู่ให้เอง แล้วไล่ตรวจว่ามี CLI ตัวไหนติดตั้งไว้บ้าง ส่วนบนเว็บหรือเวลาจะเพิ่มเครื่องอื่นเข้ามา ให้เปิดเมนู Runtimes แล้วเลือก Add a computer ระบบจะให้คำสั่งมาสองบรรทัด เอาไปวางในเทอร์มินัลของเครื่องนั้น

ขั้นที่สามคือสร้าง agent โดยเปิดเมนู Agents แล้วเลือก New agent จากนั้นเลือก runtime ที่เพิ่งเชื่อมไว้ เลือกผู้ให้บริการ แล้วตั้งชื่อ ชื่อนี้จะไปโผล่บนบอร์ดและในคอมเมนต์ หรือจะกด Build with AI ให้มันร่างการตั้งค่าจากคำอธิบายสั้นๆ ก็ได้

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

จะ self-host ยกทั้งระบบมาไว้บนเครื่องของทีมก็ได้

ทีมที่ไม่อยากให้โค้ดวิ่งผ่านบริการของคนอื่นสามารถรันทั้งระบบเองได้ จะใช้เครื่องมือจัดการคอนเทนเนอร์อย่าง Docker Compose หรือ Helm ก็เลือกตามโครงสร้างที่มีอยู่ ฝั่งที่เก็บโค้ดก็รองรับหลายเจ้า ทั้ง GitHub, GitLab, Gitea และ Forgejo รวมถึงแบบที่ทีมตั้งเซิร์ฟเวอร์เอง

ติดตั้งพร้อมเซิร์ฟเวอร์บน macOS หรือ Linux ใช้สองคำสั่งนี้ โดยเครื่องต้องมีโปรแกรม Docker ติดตั้งไว้ก่อน

curl -fsSL https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.sh | bash -s -- --with-server
multica setup self-host

ฝั่ง Windows ตั้งค่าโหมดก่อน แล้วค่อยเรียกตัวติดตั้งผ่านโปรแกรมบรรทัดคำสั่งอย่าง PowerShell

$env:MULTICA_MODE="with-server"
irm https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.ps1 | iex

ขั้นตอนเต็มทั้งชุดอยู่ในคู่มือติดตั้งระบบเองอย่าง Self-Hosting Guide ของโปรเจกต์

ของที่ต้องดูให้ชัดก่อนเอาไปใช้จริง

คำว่าโอเพนซอร์สในที่นี้มีเงื่อนไขแนบมาด้วย สัญญาอนุญาตของโปรเจกต์ใช้ชื่อว่า Multica License เนื้อความข้างในเป็น Apache License 2.0 ฉบับเต็ม ซึ่งเป็นสัญญาอนุญาตโอเพนซอร์สแบบเปิดกว้าง จากนั้นเติมข้อกำหนดเพิ่มอีกชั้น ทั้งเรื่องการเอาไปเปิดเป็นบริการให้คนอื่นใช้ การฝังลงไปในสินค้าเชิงพาณิชย์ และการใช้ชื่อแบรนด์ ทีมที่คิดจะเอาไปต่อยอดเพื่อขายควรอ่านส่วนนี้ให้จบก่อนตัดสินใจ

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

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

ฝั่งแอปมือถือยังไปไม่สุด เวอร์ชัน iOS ต้อง build เองจากซอร์สโค้ด ยังไม่มีให้โหลดบน App Store ส่วนการเชื่อมเข้ากับแชทที่ทีมใช้อยู่ รองรับ Slack กับ Lark โดยทีมหลัก ขณะที่ DingTalk และ WeCom ดูแลโดยชุมชน ซึ่งระดับการดูแลช่วยเหลือจะต่างกัน

ชื่อ Multica มาจากยุคที่คนต้องแบ่งกันใช้เครื่อง

ชื่อโปรเจกต์ย่อมาจาก Multiplexed Information and Computing Agent โดยผู้พัฒนาตั้งชื่อล้อตาม Multics ระบบปฏิบัติการยุค 1960s ที่บุกเบิกแนวคิดแบ่งปันเวลาประมวลผลอย่าง time-sharing

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

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

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