แอปเดสก์ท็อป Kanban โอเพนซอร์สที่รันเอเจนต์แบบขนานบนทุกการ์ด

 (kanbots.dev)
1 คะแนน โดย GN⁺ 8 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • KanBots เป็นแอปเดสก์ท็อปที่รัน Claude Code และ Codex แบบขนานในแต่ละการ์ดคันบัง พร้อมแสดงความคืบหน้า การตัดสินใจ และค่าใช้จ่ายบนบอร์ดแบบเรียลไทม์
  • การรันแต่ละครั้งถูกแยกอยู่ใน git worktree ของตัวเองบนสาขา kanbots/issue-N และสามารถสร้างบอร์ดได้ด้วยการใส่โฟลเดอร์พร้อมกำหนดเอเจนต์ให้แต่ละการ์ด
  • Autopilot จะวนใช้เพอร์โซนาอย่าง product, engineer, reviewer, tester ด้วยระดับความขนานสูงสุด 4 เพื่อแบ่งงานและอัปเดต backlog
  • เอเจนต์จะหยุดเมื่อถึงจุดที่ต้องตัดสินใจและเสนอทางเลือก โดยผู้ใช้สามารถเลือกหมายเลข แก้ไขแล้วส่งใหม่ หรือทำต่อด้วย /spec, /review, /split
  • แอปเดสก์ท็อปใช้แนวทาง ฟรีภายใต้สัญญาอนุญาต MIT และ local-first ส่วน Cloud ราคา $19 ต่อที่นั่งต่อเดือน พร้อมซิงก์ทีม การแจ้งเตือน และแดชบอร์ด

แนวคิดพื้นฐานของ KanBots

  • KanBots เป็นแอปเดสก์ท็อปที่รันเอเจนต์ Claude Code และ Codex แบบขนานในระดับการ์ดบนบอร์ดคันบัง
  • เอเจนต์แต่ละตัวจะทำงานใน git worktree แยกของตัวเองบนสาขา kanbots/issue-N และบอร์ดจะอัปเดตความคืบหน้า คำขอตัดสินใจ และค่าใช้จ่ายแบบเรียลไทม์
  • เมื่อนำโฟลเดอร์เข้ามา ระบบจะสร้างบอร์ด และสามารถกำหนดเอเจนต์ Claude Code หรือ Codex ให้กับหลายการ์ดได้
  • ในโหมดรันอัตโนมัติ เพอร์โซนาจะช่วยแบ่งงาน รันแบบขนาน และตรวจสอบผลลัพธ์
  • แอปเดสก์ท็อปให้ใช้ฟรี ภายใต้สัญญาอนุญาต MIT รองรับการบริจาค และทำงานแบบ local-first

องค์ประกอบผลิตภัณฑ์และการคิดราคา

  • เดสก์ท็อป OSS

    • Desktop เป็นแบบ local-first ไม่ต้องมีบัญชี ไม่มี telemetry ใช้ฟรีตลอดชีพ และอยู่ภายใต้สัญญาอนุญาต MIT
    • รองรับ macOS, Linux, Windows และรวมทุกฟีเจอร์ไว้ครบ
    • ฟีเจอร์หลักประกอบด้วยการรันเอเจนต์แบบขนาน, รันอัตโนมัติ, decision prompt, เพอร์โซนาในตัวและแบบกำหนดเอง, วิเคราะห์ค่าใช้จ่ายแบบเรียลไทม์, recipe library, kanbots-mcp-server, นำเข้า Sentry, โหมด GitHub Issues, branch preview, สร้าง draft PR, รองรับ Claude Code·Codex และ pre-push hook

  • Cloud สำหรับทีม

    • Cloud เป็นผลิตภัณฑ์แบบโฮสต์สำหรับหลายผู้ใช้ โดยเอเจนต์ยังคงรันแบบโลคัลบนฮาร์ดแวร์ของผู้ใช้
    • ราคาอยู่ที่ $19 ต่อที่นั่งต่อเดือน หรือ $190 เมื่อชำระรายปี
    • นอกจากฟีเจอร์ OSS แล้ว ยังมีการแสดงสถานะการอยู่บนบอร์ดแบบเรียลไทม์, การแจ้งเตือนเมื่อมอบหมายสมาชิกทีม, การซิงก์ข้ามอุปกรณ์, การแจ้งเตือนผ่าน Slack, การรวมค่าใช้จ่ายทั้งองค์กร, การแก้ไขการ์ดร่วมกันแบบเรียลไทม์, แดชบอร์ดกิจกรรมเอเจนต์ระดับองค์กร และ Managed GitHub App
    • ฟีเจอร์ Enterprise มี audit log, SSO / SCIM, REST API และ PAT รวมถึง outbound webhook
    • ฟีเจอร์เฉพาะ Cloud จะจำกัดไว้เฉพาะสิ่งที่มีความหมายเมื่อมีคนอื่นหรือมีหลายอุปกรณ์ ส่วนฟีเจอร์ที่ใช้คนเดียวบนเครื่องเดียวจะอยู่ใน OSS

เครื่องมือและการเชื่อมต่อที่รองรับ

  • รองรับ CLI ของ Claude Code และ Codex
  • รองรับงาน GitHub Issues และ PR
  • รองรับการนำเข้าข้อผิดพลาดจาก Sentry
  • Cursor และ Claude Desktop สามารถเชื่อมต่อได้ในฐานะ MCP client
  • ที่เก็บข้อมูลโลคัลใช้ SQLite
  • เดสก์ท็อปเชลล์สร้างบน Electron

ฟีเจอร์หลัก

  • รันการ์ดแบบขนาน

    • สามารถรันเอเจนต์พร้อมกันบนหลายการ์ดได้ โดยแต่ละการรันจะเกิดขึ้นใน git worktree และสาขา kanbots/issue-N ของตัวเอง
    • บอร์ดจะอัปเดตความคืบหน้าการรัน คำขอตัดสินใจของเอเจนต์ และค่าใช้จ่ายสะสมแบบเรียลไทม์

  • รันอัตโนมัติและเพอร์โซนา

    • สามารถเชื่อมเพอร์โซนาอย่าง product, engineer, reviewer, tester และตั้งระดับความขนานได้สูงสุด 4
    • ตัว orchestrator จะวนเพอร์โซนาแบบ round-robin แยก issue ระดับบนออกเป็นงานย่อย และอัปเดต backlog ด้วยงานที่เอเจนต์ค้นพบ
    • เพอร์โซนาสามารถสร้างเพอร์โซนาอื่นได้

  • การทำงานที่ขับเคลื่อนด้วยการตัดสินใจ

    • เอเจนต์จะหยุดเมื่อพบการตัดสินใจที่จำเป็นและแสดงตัวเลือก
    • ผู้ใช้สามารถเลือกหมายเลข แก้ไขแล้วส่งใหม่ หรือใช้ slash command เช่น /spec, /review, /split เพื่อดำเนินการต่อ
    • แทนที่จะเปลี่ยน worktree แบบเงียบ ๆ ระบบจะทิ้งเส้นทางการตัดสินใจที่ตรวจสอบได้ไว้

  • การรวม Claude Code และ Codex

    • สามารถใช้ Claude Code หรือ Codex ได้บนบอร์ดเดียวกัน worktree เดียวกัน และ UI การตัดสินใจเดียวกัน
    • KanBots จัดการสตรีมทั้งสองรูปแบบไว้หลัง AgentCliAdapter ตัวเดียว
    • สามารถใช้ claude /login เดิมหรือ OPENAI_API_KEY ได้

  • การจัดเก็บแบบ local-first

    • ข้อมูลทั้งหมดอยู่ใน .kanbots/ ข้าง repository
    • ฐานข้อมูล SQLite, การตั้งค่า และ worktree ถูกเก็บไว้แบบโลคัล
    • ไม่มีบัญชีคลาวด์ ไม่มี telemetry ไม่มี HTTP server และโค้ดไม่ออกจากเครื่อง

  • การวิเคราะห์ค่าใช้จ่ายและการจำกัดงบประมาณ

    • มีการรวมค่าใช้จ่ายในระดับการรัน การ์ด และโปรเจกต์
    • มี cost meter สะสมระหว่างที่เอเจนต์ทำงาน
    • ตั้งเพดานได้ทั้งต่อการรันและต่อเซสชัน และจะหยุดเมื่อถึงงบประมาณ

  • เวิร์กโฟลว์ GitHub

    • สามารถจัดการ GitHub issue จริงได้ด้วย PAT ส่วนตัว
    • สามารถยกระดับ worktree เป็น commit หรือเปิด draft PR ได้ในคลิกเดียว
    • มี pre-push hook เพื่อกันไม่ให้เอเจนต์เผยแพร่ด้วยตัวเอง

  • MCP server

    • kanbots-mcp-server เปิดเผยบอร์ดผ่าน Model Context Protocol
    • Cursor, Claude Desktop หรือเครื่องมือที่เข้าใจ MCP สามารถจัดการบอร์ดได้
    • ทำให้บอร์ดกลายเป็นเครื่องมือที่เอเจนต์อื่นใช้งานได้

เวิร์กโฟลว์ภายในแอป

  • Autopilot

    • เลือกเพอร์โซนาอย่างน้อยหนึ่งตัว ตั้งค่าความขนาน แล้วเริ่มรันอัตโนมัติ
    • สล็อตขนานสูงสุด 4 ช่องจะวนตามรายการเพอร์โซนาแบบ round-robin
    • แต่ละสล็อตจะหยิบเพอร์โซนาถัดไปแบบ atomic และเอเจนต์จะแยก issue ระดับบนเป็นงานย่อยระหว่างดำเนินการ
    • จะหยุดเมื่อเสร็จสิ้นหรือเมื่อถึงงบประมาณของเซสชัน
    • หน้าจอตัวอย่างแสดง Claude Opus 4.7, effort ระดับ medium, ความขนาน 2 และมีการเลือกเพอร์โซนา Product Manager กับ Senior Engineer

  • Decisions

    • เธรดการรันจะสตรีม tool_use และ tool_result ทั้งหมดแบบเรียลไทม์
    • เอเจนต์จะหยุดเมื่อถึงจุดที่ต้องใช้วิจารณญาณและเสนอทางเลือกที่มีหมายเลขกำกับ
    • ช่องตอบกลับรองรับคำสั่งอย่าง /spec, /review, /split
    • ในตัวอย่างการทำ reset token สำหรับรหัสผ่าน มีตัวเลือกอย่าง JWT ใช้ครั้งเดียว, opaque token ที่เก็บใน DB, magic link หรืออธิบาย trade-off ก่อน
    • หน้าจอการรันแสดง model, เวลาที่ผ่านไป, จำนวน token, ค่าใช้จ่าย, สถานะ, ลำดับความสำคัญ, โฟลเดอร์, worktree, branch, base branch และผู้เขียน

  • Personas

    • เพอร์โซนา คือชิ้นส่วน system prompt ที่มีชื่อกำกับ
    • มีเพอร์โซนาเริ่มต้นรวมมาในแอป และผู้ใช้สามารถเขียน บันทึก และนำเพอร์โซนาใหม่กลับมาใช้ซ้ำได้
    • เพอร์โซนาแบบกำหนดเองจะถูกเก็บแบบโลคัลบนเครื่องนั้น
    • ตัวอย่างเริ่มต้นมี Product Manager, Senior Engineer, UX Designer, Growth Lead และ Reliability Engineer

  • Providers

    • ใช้ Claude Code และ Codex ได้หลัง AgentCliAdapter ตัวเดียว
    • ใช้ claude /login หรือ codex login เดิมซ้ำได้ โดยไม่ต้องมีบัญชีเพิ่มหรือจัดการคีย์เพิ่ม
    • สามารถสลับ provider ได้ในแต่ละการรัน
    • Codex CLI ต้องมี codex อยู่ใน PATH และการร่าง issue กับการวิเคราะห์ Sentry ยังทำผ่าน Claude
    • การล็อกอิน Codex สามารถเปิด auth.openai.com ในเบราว์เซอร์ หรือใช้ตัวแปรสภาพแวดล้อม OPENAI_API_KEY

  • Tasks

    • งานใหม่มีเทมเพลตสำหรับ bug fix, feature, refactor, review และ spike
    • วิธีเริ่มมีให้เลือกเป็น spec-first, รันทันทีหลังสร้าง หรือเข้าคิวไว้ทีหลัง
    • ชื่อเรื่องจะถูกใช้เป็นชื่อ branch และชื่อ PR
    • spec-first จะรัน /spec เพื่อปรับ acceptance criteria ให้ชัดเจนและค้างไว้ในสถานะรออนุมัติ
    • งานใหม่จะสร้าง fresh worktree และสร้างสาขาภายใต้ .kanbots/worktrees/issue-N โดยอิงจาก main

  • Chat

    • มีเอเจนต์ทั่วไปสำหรับถามคำถามเกี่ยวกับ workspace
    • เอเจนต์รู้จัก repository, การทดสอบ และสถานะ git และตอบคำถามได้
    • มีตัวอย่างการค้นหา API route ที่ไม่มี rate limiting จากนั้นเพิ่ม rateLimit({ windowMs: 60_000, max: 10 }) ให้กับ /api/login และ /api/signup แล้วเขียนเทสต์ให้ผ่าน

วิธีทำงานของ Autopilot

  • Autopilot เป็นโหมดที่รับ issue และงบประมาณ แล้วอัปเดต backlog ด้วยตัวเอง
  • ตัว orchestrator จะวนรายการเพอร์โซนาแบบ round-robin และรันสล็อตแบบขนานได้สูงสุด 4 สล็อต
  • มันจะแยก issue ระดับบนออกเป็นงานย่อย และวนต่อไปจนกว่างานจะเริ่มนิ่งหรือถึงเพดานค่าใช้จ่าย
  • ตัวอย่างแสดงความขนาน 4, โมเดล opus 4.7, ใช้งบไป $4.27 จากงบเซสชัน $25.00 และอยู่ที่รอบที่ 14

  • เลือกรายการเพอร์โซนา

    • ใช้เพอร์โซนาเริ่มต้นได้ หรือจะกำหนด system prompt เองเพื่อบันทึกและใช้ซ้ำก็ได้
    • เพอร์โซนาแบบกำหนดเองจะไม่ออกจากเครื่อง

  • ตั้งค่าความขนาน

    • ความขนานตั้งได้ตั้งแต่ 1 ถึง 4
    • แต่ละสล็อตจะหยิบเพอร์โซนาถัดไปผ่านตัวนับ round-robin แบบ atomic
    • เอเจนต์สี่ตัวสามารถรันพร้อมกันจากสี่มุมมองและสี่ worktree ได้

  • การแยกงาน

    • เมื่อเอเจนต์ค้นพบงาน ระบบจะสร้างการ์ดใหม่บนบอร์ด
    • รอบถัดไปจะหยิบการ์ดใหม่ไปทำ ทำให้ backlog ขยายและหดภายใต้ orchestrator

  • หยุดเมื่อถึงงบหรือเสร็จงาน

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

โหมด QA

  • QA mode จะรัน typecheck, tests, lint, build และ e2e ภายใน worktree
  • หากจำเป็น สามารถเริ่มและเฝ้าดู development server ได้
  • สำหรับการตรวจสอบแต่ละรายการที่ล้มเหลว ระบบจะมอบหมายการรันแก้ไขใน child issue ที่แตกออกมา
  • จะทำซ้ำจนกว่าการตรวจสอบทั้งหมดจะผ่าน

รูปแบบการให้บริการและบทสรุป

  • แอปเดสก์ท็อป OSS ให้ใช้ฟรี ภายใต้สัญญาอนุญาต MIT และไม่ต้องมีบัญชี
  • เน้นแนวทางนำการรันเอเจนต์ทั้งหมดขึ้นมาแสดงบนคันบัง เพื่อให้มองเห็นได้ ตัดสินใจได้ และแยกจากกันอย่างชัดเจน
  • หากทีมต้องแชร์บอร์ดร่วมกัน สามารถเปลี่ยนไปใช้ Cloud ได้
  • รูปแบบดาวน์โหลดมี macOS .dmg, Windows .exe, Linux .AppImage / .tar.xz

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

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

 
GN⁺ 8 시간 전
ความคิดเห็นจาก Hacker News

  • ยังคงสงสัยอยู่เสมอว่าผู้คนรับมือกับผลลัพธ์ที่เอเจนต์ทำงานทิ้งไว้ข้ามคืนกันอย่างไร
    แม้แต่ในรีโพซิทอรีโปรเจกต์ส่วนตัว ผลลัพธ์จากการวางแผน 30 นาทีและลงมือทำ 30 นาทีก็ยังใหญ่เกินกว่าจะรีวิวได้แล้ว ราว ๆ 5 นาทีผ่านไป บางทีก็สั่งให้ AI ทำใหม่ทั้งที่โค้ดยังไหลออกมาไม่หยุด

    • ช่วงนี้เรื่องเล่าหลักมักโฟกัสไปที่ว่า AI เขียนโค้ดทั้งหมดหรือเกือบทั้งหมด แต่ความจริงแล้วสัดส่วนของโค้ดที่มนุษย์ได้รีวิวจริงน่าจะกำลังเข้าใกล้ศูนย์เร็วกว่าที่คนส่วนใหญ่ตระหนักหรือยอมรับมาก
    • งานของเอเจนต์ลักษณะนี้ส่วนใหญ่คือการไล่ดูสิ่งที่สร้างไว้ก่อนหน้า และบังคับข้อจำกัดต่าง ๆ เพื่อให้ตอนรีวิว ผลลัพธ์ที่ถูกส่งมาบนโต๊ะพอจะคาดเดาได้ในระดับหนึ่ง
      ส่วนตัวคิดว่าโครงสร้างไฟล์ที่เข้มงวดก็ช่วยมาก การต้องรีวิวไฟล์เดียวที่เพิ่งถูกสร้างมายาว 3,000 บรรทัดนั้นแย่มาก และคงไม่อยากได้ผลลัพธ์แบบนั้นไม่ว่าจะจากคนหรือเครื่อง ถ้าแยกเป็นหลายไฟล์อยู่ในตำแหน่งที่เหมาะสม ภาระในการทำความเข้าใจก็จะลดลง
      บางครั้งก็รีวิวไปพร้อมกับคุยกับเอเจนต์ เช่น ถามว่าควรเริ่มรีวิวไฟล์ไหนก่อนเพราะสำคัญที่สุด
      ผมชอบสเตจการเปลี่ยนแปลงไว้ในกอง “LGTM” ก่อน ถ้าต้องแก้ทีหลัง ก็จะบอกเอเจนต์ว่า “ช่วยรีวิวการเปลี่ยนแปลงที่ยังไม่ได้สเตจหน่อย ตรงนี้อยากให้ทำอีกแบบ”
    • ไม่มีใครรีวิวโค้ดหรอก ผู้จัดการก็ไม่อยากให้เรารีวิวโค้ดด้วย เพราะมันเป็นคอขวด
      ถ้ามีอะไรผิดพลาด เช่น มีบั๊ก ก็แค่ค่อย ๆ แก้กันไป นี่เป็นยุคที่น่าเศร้ามากของวิศวกรรมซอฟต์แวร์ ถ้าอุตสาหกรรมเรายังเคยมี “วิศวกรรม” อยู่ ตอนนี้มันก็คงหายไปเกือบหมดแล้ว เหลือแต่การเดา ๆ เอาจาก ไฟล์ skills อย่าง “อย่าใส่บั๊กนะ” หรือ “คุณเป็นเจ้าของ ไม่ใช่แค่ผู้เช่า”
      ทั้งระดับความพยายามและความเป็นเชิงกำหนดต่ำมาก แอปใหญ่ ๆ อย่าง GitHub ก็ล่มอยู่เรื่อยเพราะขยะจาก AI และในระบบที่ดังน้อยกว่าก็ยิ่งเห็นบ่อย ทั้งในบริษัทเราและ SaaS อื่น ๆ ที่เราใช้อยู่ก็เหมือนกัน
      ผู้จัดการผลิตภัณฑ์แต่ไหนแต่ไรมาก็ไม่สนใจโค้ดอยู่แล้ว ผู้จัดการวิศวกรรมก็ไม่สนใจโค้ดเท่าตอนที่ยังเป็นวิศวกร ผู้อำนวยการไม่สนโค้ดเลย และตอนนี้ CTO ก็คงไม่รู้ด้วยซ้ำว่าโค้ดหน้าตาเป็นอย่างไร
      เราอยู่ปลายสุดของห่วงโซ่ และเพราะเรารู้อย่างลึกซึ้งว่าระบบที่ดีสร้างอยู่บนโค้ดที่ดี เราจึงเคยภูมิใจกับโค้ดที่ใช้งานได้ดีและดูแลรักษาได้ แต่ตอนนี้เรากลับกำลังทำให้ตัวเองเสี่ยง และคนที่ไม่ใส่ใจโค้ดอีกต่อไปก็คือพวกเราเองในฐานะวิศวกร โดยมี AI คอยขยายปัญหานั้นให้หนักขึ้น
    • ปกติจะตั้งเป้าให้หลังจากที่ Claude ทำงานข้ามคืนแล้ว สุดท้ายเหลือโค้ดประมาณ 500 บรรทัดเท่านั้น
      เวลาส่วนใหญ่หมดไปกับการลองหลายแนวทางแล้วสรุปออกมา เพื่อให้ผมได้ diff ที่ค่อนข้างเล็กพอจะรีวิวและแก้เองได้
    • ผมก็สงสัยเหมือนกัน คำตอบที่มักได้ยินจากคนที่ใช้งานได้จริงคือพวกเขาไม่ได้ดูโค้ด หรืออย่างน้อยก็ไม่ได้ดูละเอียด
      ส่วนตัวแล้วผลลัพธ์ที่เอเจนต์ทำออกมามักมีอะไรให้ต้องแก้เสมอ เลยยังลังเลว่าควรปล่อยการควบคุมตรงนั้นไปดีไหม

  • ทำให้นึกถึง Vibe Kanban(https://vibekanban.com/) ที่ผมใช้จัดการโค้ดดิ้งเอเจนต์ในโปรเจกต์ส่วนใหญ่
    น่าเสียดายที่ผู้พัฒนา Vibe Kanban ตัดสินใจหยุดลงทุนกับโปรเจกต์เพราะมองไม่เห็นเส้นทางการทำเงิน ถึงจะเป็นโอเพนซอร์สและยังรันบนเครื่องหรือ fork ได้ แต่การพัฒนาหยุดไปแล้ว และยังมีบั๊กน่ารำคาญที่ต้องแก้อีกหลายจุด ผมเองก็ไม่มีเวลามาดูแลต่อ
    เสียดายเหมือนกัน เพราะผมเต็มใจจ่ายเงินให้ Vibe Kanban แค่ไม่ได้ต้องการฟีเจอร์ในแพลนเสียเงิน พอมาคิดย้อนหลังก็อาจควรจ่ายไปเลย
    จะลองใช้ Kanbots ดูเหมือนกัน น่าจะก็อปฟีเจอร์ของ Vibe Kanban แบบจริงจังได้เลย โดยเฉพาะการรองรับรีโมตกับปุ่ม “Open in VS Code” ซึ่งสำคัญกับผมมาก สำหรับผม ปุ่มนี้จะเปิด VSCode client บนเครื่องให้ไปชี้ที่เซิร์ฟเวอร์ VSCode แบบรีโมต

    • Vibe Kanban เป็นขุมทรัพย์ของฟีเจอร์ที่มีประโยชน์จริง ๆ
      ช่วง 1-2 สัปดาห์ที่ผ่านมา ผมกำลังดันเครื่องมือใหม่ให้มีความสามารถเทียบเท่า VK และใส่การปรับปรุงเพิ่มเข้าไปด้วย ผมโพสต์สกรีนช็อตไว้ใน Discord ของ Vibe Kanban ไปบ้างแล้ว หวังว่าพอพร้อมเปิดตัว มันจะเหมาะกับกรณีใช้งานของคุณด้วย
      เครื่องมือของผมตั้งเป้าจะทำได้ดีกว่า VK ทั้งฝั่งบอร์ด Kanban และ workspace ของเอเจนต์ พร้อมใส่ระบบเพิ่มอย่างการจัดการหน้าต่างเดสก์ท็อป, ปลั๊กอิน, การรวม VSCode ในเบราว์เซอร์, และ UI แบบ server-rendered คล้าย htmx
      วิธีเข้าถึงแบบรีโมตก็ต่างกัน แทนที่จะเปิดเว็บเซิร์ฟเวอร์บนโน้ตบุ๊กเพื่อเข้าถึงรีโมตโค้ดดิ้งเอเจนต์ มันจะโฮสต์ทุกอย่างไว้ทั้งหมดแบบ OpenClaw แล้วให้เข้าถึง UI เดสก์ท็อประยะไกลผ่านเบราว์เซอร์

  • จุดที่ว่า “local-first, ไม่มีเซิร์ฟเวอร์ ทุกอย่างอยู่ใน .kanbots/ ข้างรีโพ: ฐานข้อมูล SQLite, การตั้งค่า, worktree ไม่มีบัญชีคลาวด์ ไม่มี telemetry ไม่มี HTTP server นี่คือเดสก์ท็อปเอดิชันแบบโอเพนซอร์ส” เป็นเงื่อนไขขั้นต่ำสำหรับการพิจารณาใช้เครื่องมือแบบนี้

    • ไม่แน่ใจว่า “เครื่องมือแบบนี้” หมายถึงอะไร
      ถ้า AI เป็นแบบเอเจนต์ ผมก็คาดหวังว่าผู้จัดการผลิตภัณฑ์คนไหนก็น่าจะคุยกับมันสักชั่วโมงแล้วทำให้ Jira เชื่อมกับ agent loop แบบใดแบบหนึ่งได้
      ทั้ง Jira, Trello, Linear และ Basecamp ต่างก็มี API และก็น่าจะมี CLI ให้เอเจนต์ใช้ได้ด้วย เวลาเริ่มงานมันก็ควรเข้าใจเองได้ว่าต้อง checkout ticket, อ่านคำสั่ง, แล้วพอเสร็จก็ย้ายไป DONE เรื่องแบบนี้ไม่น่าต้องพึ่งนักพัฒนาหรือ SaaS เพิ่มอีก
    • แต่ดูจากหน้าเว็บแล้ว ต่อให้ใช้แบบ local ฟีเจอร์นี้ก็ดูเหมือนจะต้องล็อกอินบัญชีคลาวด์ถึงจะใช้ได้ เลยตัดสินใจไม่ลอง
      พูดตามตรงมันก็ดูเจ๋งนะ แต่ตอนนี้ก็มีเครื่องมือที่ดูเจ๋งอยู่เยอะแล้วเหมือนกัน

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

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

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

    • งานดีมาก ผมเคยเอาโปรเจกต์ Jira เดิมมาจัดหมวดตาม workflow แล้วให้เอเจนต์ภายในหมุน Kanban กันเอง วันนี้มาเห็นโปรเจกต์นี้บน HN เลยดีใจ
      น่าจะสนุกดีถ้าได้ติดตามความคืบหน้าของงานนี้
    • ลองอ่านโพสต์ minions ของบล็อกนักพัฒนา Stripe ดู น่าจะไปในทิศทางคล้ายกัน

  • นี่ก็คือสิ่งที่ Windsurf ทำอยู่ไม่ใช่เหรอ? สุดท้าย UI พวกนี้ก็เป็นแค่ของตกแต่งภายนอกที่ครอบอยู่บนเอเจนต์เท่านั้น
    [0] https://windsurf.com/blog/windsurf-2-0

    • มีแอปอยู่ไม่กี่ตัวที่ช่วยส่งต่องานจากบอร์ด Kanban ไปให้เอเจนต์
      แต่สำหรับผมต้องการโฟลว์ที่มนุษย์มีส่วนร่วมมากกว่า วิธีที่ส่งต่อให้เอเจนต์ไปเลยโดยมองชุดการเปลี่ยนแปลงไม่ชัด และไม่มีจังหวะให้เปลี่ยนทิศทาง มันไม่เหมาะกับผม
      https://www.agentkanban.io เชื่อมบอร์ดงานกับ GitHub Copilot Chat ใน VS Code ผ่าน extension เพื่อให้ได้ทั้งการจัดการงานและการเก็บบริบทจากแชตสู่ตัวงาน ดังนั้นจึงใช้ข้อดีของสภาพแวดล้อมการทำงานระดับบนอย่าง VS Code ควบคู่กับความสามารถด้านการจัดการงาน/โปรเจกต์ได้
    • ผมไม่เห็นว่าตรงนี้มีปัญหาอะไร หรือมีเหรอ?
      Linear เองก็กำลังทำไปทางนี้โดยตรง
    • Windsurf เป็นโอเพนซอร์สไหม?

  • สิ่งที่ผมยังไม่เข้าใจในเครื่องมือพวกนี้คือจัดการเรื่องการเปิดใช้งานอินฟราสตรักเจอร์ของ worktree แต่ละอันอย่างไร
    ตัวอย่างเช่น ถ้าเป็นเว็บแอป แต่ละ worktree ก็ควรเปิดอินฟราสตรักเจอร์ของตัวเองได้ และควรเข้าถึงผ่าน local URL ที่ไม่ซ้ำกันได้ เพื่อให้ดูการเปลี่ยนแปลงของแต่ละ worktree บนเครื่องตัวเองได้ หรือให้เอเจนต์ใช้เครื่องมืออย่าง agent-browser ตรวจสอบภาพหน้า UI แบบอัตโนมัติได้
    ตอนนี้ผมใช้ Docker กับอินฟราสตรักเจอร์ และแต่ละ service ก็รันใน container ของตัวเอง มีสคริปต์ ./app worktree create worktreename ซึ่งจะสร้าง worktree ชื่อ “worktreename” แล้วเปิด Docker infrastructure ทั้งชุดโดยเติม prefix แบบ “WORKTREENAME” เข้าไป ทำให้ทุก URL เข้าผ่าน worktreename.myapp.test ได้ ส่วน worktree หลักก็ใช้ myapp.test ตามปกติ
    ตอนนี้มันทำงานได้ดี แต่ถ้ามีแอปพวกนี้สักตัวรองรับแนวคิดนี้ได้ ก็น่าสนใจที่จะย้ายไปใช้

    • ที่ทำงานผมก็มีปัญหาเดียวกัน เลยให้ CC ช่วยทำเครื่องมือ CLI ด้วย bun แบบง่ายมากสำหรับสร้าง ลบ และแสดงรายการ worktree
      CLI ตัวนั้นจะเติม URL และฐานข้อมูลของ worktree นั้นลงในไฟล์ .env แล้วใช้แพ็กเกจโอเพนซอร์ส portless ของ Vercel เพื่อเปิด dev server บนพอร์ตเฉพาะ ทำให้แต่ละ worktree มี URL ของตัวเอง
    • ลองดู emdash.sh ก็ได้ แต่ละงานจะเปิด worktree ของตัวเองและมีการ inject environment variables ที่กำหนดไว้ล่วงหน้า
      ในนี้รวมถึง EMDASH_PORT ซึ่งเป็นพอร์ตเฉพาะในช่วง 10 พอร์ตด้วย มีประโยชน์มากเวลาเปิดหลาย service จาก monorepo เดียวกัน
    • ผมใช้เชลล์สคริปต์สร้างและลบ worktree
      เชลล์สคริปต์จะหาพอร์ตเฉพาะที่ยังไม่ได้ใช้จาก worktree ที่มีอยู่ทั้งหมด แล้วกำหนดลง local .env ตอนสร้าง worktree พอ worktree ถูกรวมและลบออก พอร์ตก็จะถูกคืนกลับ
      ส่วนค่าลับที่ไม่ได้แยกตาม worktree ผมจะไม่ใส่ไว้ใน local .env แต่ inject ผ่านเชลล์แทน
      พูดตามตรง การเขียนสคริปต์ local แบบนี้เพื่อทำ automation งานพัฒนาเป็นเรื่องง่ายมาก และก็ทำงานร่วมกับ CLI อื่น ๆ ได้ดีอยู่แล้ว เลยยังไม่เคยลองใช้แอป GUI ไม่แน่ใจว่ามันจะมาแข่งกับการตั้งค่า local แบบปรับตามใจที่ทำงานได้ตรงตามที่ผมต้องการหรือเปล่า
    • ใช้ direnv ไปเลยไม่ได้เหรอ? พอร์ตสำหรับโฮสต์หน้า local อาจต้องปรับหน่อย แต่ก็ใช้แฮชจากชื่อ worktree เพื่อกำหนด N=mod(...) แล้วตั้ง port=default_port+N ได้
      ให้ Claude ตั้งค่าให้ก็ได้ น่าจะจบได้ด้วยพรอมป์ต์เดียว

  • “‘kanbots’ เสียหายและไม่สามารถเปิดได้ ควรย้ายไปที่ถังขยะ”
    เป็นข้อความผิดพลาดที่เหมาะเกินไปสำหรับการได้เจอครั้งแรกในซอฟต์แวร์ vibe coding

  • นี่มันก็แค่ vibe-kanban ไม่ใช่เหรอ?
    https://github.com/BloopAI/vibe-kanban

    • คู่แข่งย่อมมีได้
    • มันอยู่บน Bloop แบบตรงตัวเลย เป็นงานต้นฉบับของ Bloop