ทดลองใช้ OpenClaw Workboard + Skill Workshop: จาก multi-agent สู่ skill ที่ตรวจสอบได้

# ทดลองใช้ OpenClaw Workboard + Skill Workshop

หลายคนลอง multi-agent แล้วเจอปัญหาเดียวกัน: agent แต่ละตัวทำงานได้ แต่คนคุมกลับไม่รู้ว่าใครกำลังทำอะไร งานไหนรอตรวจ และผลลัพธ์ชิ้นไหนพร้อมส่งต่อ

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

บทความนี้เป็น Lab ที่ทำตามได้จริง เราจะจำลองทีม content สาม agent: Researcher ค้นข้อมูล, Verifier ตรวจหลักฐาน และ Writer เขียนสรุป จากนั้นนำขั้นตอนที่นิ่งแล้วไปสร้างเป็น skill แบบมี governance

หมายเหตุจากการตรวจเครื่องทดสอบวันที่ 10 มิถุนายน 2026: เครื่องเดิมที่ใช้ OpenClaw 2026.3.11 ยังไม่มีคำสั่ง Workboard และ Skill Workshop รุ่นนี้ จึงต้องอัปเกรดเป็น 2026.6.1 ขึ้นไปก่อน บทความจะไม่แต่ง benchmark หรือผลรันที่ยังไม่ได้เกิดขึ้น

สิ่งที่เราจะพิสูจน์

เมื่อจบ Lab นี้ เราควรตอบได้ 4 ข้อ:

1. คนดูแลเห็นเจ้าของ สถานะ และหลักฐานของแต่ละงานจากจุดเดียวหรือไม่ 2. การส่งต่องาน Research → Verify → Write ลดการตามงานในแชตหรือไม่ 3. เมื่อ agent ทำงานพลาด ระบบพางานไปที่ blocked/review โดยไม่ทำให้หายหรือไม่ 4. workflow ที่ผ่านการทดลองสามารถเปลี่ยนเป็น skill โดยยังมี proposal และ approval gate หรือไม่

เตรียมระบบ

ใช้ OpenClaw stable รุ่น 2026.6.1 ขึ้นไป แนะนำ stable ล่าสุดที่ทีมทดสอบแล้ว สำรอง config และ state ก่อนอัปเกรดเสมอ

~~~bash openclaw --version openclaw doctor openclaw status ~~~

Workboard เป็น bundled plugin ที่ปิดไว้โดยค่าเริ่มต้น เปิดใช้งานแล้ว restart Gateway:

~~~bash openclaw plugins enable workboard openclaw gateway restart openclaw dashboard ~~~

หากเปิดหน้า Workboard ไม่ได้ ให้ตรวจ runtime policy:

~~~bash openclaw plugins inspect workboard --runtime --json ~~~

Skill Workshop เป็น built-in agent tool ไม่ต้องเปิด plugin แยก โดย profile แบบ coding มีเครื่องมือนี้อยู่แล้ว หากตั้ง allowlist แบบเข้ม ให้เพิ่ม skill_workshop ใน tools.allow หรือ tools.alsoAllow และทำ review จาก host-side session หรือ CLI ไม่ใช่ sandboxed run

Lab 1: ทำให้งาน multi-agent มองเห็น

โจทย์ของเราคือสร้างบทความสั้นเรื่อง “3 use case ของ OpenClaw สำหรับ SME ไทย” พร้อมแหล่งอ้างอิงและข้อจำกัด เป้าหมายไม่ใช่ให้ agent คุยกันเยอะ แต่ให้แต่ละงานมีเจ้าของและนิยามคำว่าเสร็จชัดเจน

สร้างบอร์ดและการ์ดงาน

สร้างการ์ดสามใบ โดยเปลี่ยน agent id ให้ตรงกับระบบของคุณ:

~~~bash openclaw workboard create "ค้นหา 3 use case สำหรับ SME ไทย" --status ready --priority high --agent researcher --board community-lab --labels research,thai

openclaw workboard create "ตรวจ claim และแหล่งอ้างอิง" --status ready --priority high --agent verifier --board community-lab --labels review,sources

openclaw workboard create "เขียนบทความฉบับเผยแพร่" --status ready --priority normal --agent writer --board community-lab --labels content,thai ~~~

ในหน้า Dashboard ให้เติม notes ของแต่ละการ์ดด้วย acceptance criteria:

Researcher

• ส่ง 3 use case ที่ต่างกันจริง
• ทุก claim สำคัญมี URL ของแหล่งต้นทาง
• ระบุวันที่เข้าถึงข้อมูล
• แยก fact ออกจากความเห็น

Verifier

• เปิดอ่านแหล่งอ้างอิงทุกลิงก์
• ทำเครื่องหมาย claim ที่ยืนยันไม่ได้
• บันทึกข้อจำกัดหรือเวอร์ชันที่เกี่ยวข้อง
• ส่ง proof หรือ comment กลับบนการ์ด

Writer

• ใช้เฉพาะ claim ที่ผ่านการตรวจ
• เขียนภาษาไทยที่คนไม่ใช่สายเทคนิคอ่านเข้าใจ
• มีตัวอย่างใช้งานและคำเตือน
• ส่ง draft เข้าสถานะ review ไม่ปิด done เอง

Dispatch งาน

~~~bash openclaw workboard list --board community-lab --status ready openclaw workboard dispatch ~~~

Workboard dispatch การ์ดสถานะ ready ไปเป็น task-tracked subagent run โดยค่าเริ่มต้นทำงานพร้อมกันได้สูงสุดสาม worker และเลือกหนึ่งการ์ดต่อ owner/agent ต่อรอบ การ์ดจะเก็บ task id, run id, session, attempt, proof, artifact และ diagnostic ไว้ให้ตรวจย้อนหลัง

จุดที่ควรสังเกตไม่ใช่แค่ว่า agent ตอบหรือไม่ แต่คือการ์ดเปลี่ยนสถานะอย่างไร:

• เริ่มงานสำเร็จ: ready → running
• run เสร็จ: ขยับเข้าสู่ review
• run ล้มเหลว หมดเวลา หรือถูกหยุด: ขยับสู่ blocked
• คนตรวจยอมรับงานแล้ว: ค่อยย้ายเป็น done

สถานะ review, blocked และ done ที่คนกำหนดเองจะมีสิทธิ์เหนือ lifecycle sync จนกว่าจะย้ายกลับไป todo หรือ running จึงลดปัญหา agent ปิดงานแทนคนตรวจ

ส่งต่องานอย่างมีหลักฐาน

ในรอบแรก อย่า dispatch ทั้งสามการ์ดโดยหวังว่า agent จะเดา dependency กันเอง ให้ Researcher จบก่อน จากนั้นแนบ artifact หรือ proof บนการ์ด Verifier แล้วจึง dispatch รอบถัดไป เมื่อผ่าน review ค่อยส่งผลให้ Writer

flow ที่แนะนำ:

~~~text Researcher: ready → running → review → done ↓ proof Verifier: ready → running → review → done ↓ verified notes Writer: ready → running → review → done ~~~

Workboard ไม่ได้มาแทน GitHub Issues, Jira หรือ Linear แต่เป็น local operating board ของ Gateway สำหรับดูงาน agent, task, run และ session จากการ์ดเดียว งานระยะยาวหรือการประสานหลายทีมยังควรเชื่อมกับระบบ project management หลักขององค์กร

ตารางบันทึกผลทดลอง

อย่าเริ่มด้วยคำถามว่า “AI ฉลาดแค่ไหน” ให้เก็บตัวเลขที่สะท้อนภาระการคุมงาน:

| ตัวชี้วัด | ก่อนใช้ Workboard | หลังใช้ Workboard | |---|---:|---:| | จำนวนครั้งที่ต้องถามว่าใครถือ งาน | ___ | ___ | | เวลาจากเริ่ม research ถึงพร้อม review | ___ นาที | ___ นาที | | claim ที่ไม่มีแหล่งอ้างอิง | ___ | ___ | | งานที่ล้มเหลวแต่ไม่มีสถานะเตือน | ___ | ___ | | เวลาที่คนใช้ตรวจและส่งต่อ | ___ นาที | ___ นาที |

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

Lab 2: เปลี่ยน workflow ที่นิ่งแล้วเป็น skill

เมื่อทีมพบว่า acceptance criteria และรูปแบบ handoff ใช้ซ้ำได้ อย่ารีบให้ agent เขียนทับ SKILL.md ที่ใช้งานจริง ให้สร้าง proposal ผ่าน Skill Workshop ก่อน

สร้างไฟล์ PROPOSAL.md สำหรับ skill ชื่อ thai-community-research-handoff:

~~~markdown --- name: thai-community-research-handoff description: Research, verify, and hand off Thai community content with source evidence. ---

# Thai Community Research Handoff

Use this skill when preparing a Thai article that depends on current external facts.

Workflow

1. Define the topic, audience, output, and cutoff date. 2. Research with primary sources first. 3. Attach a source URL to every material claim. 4. Separate confirmed facts, inference, and opinion. 5. Pass the evidence pack to a verifier. 6. Block unsupported claims instead of guessing. 7. Produce a Thai draft only from verified material.

Required Output

• Research notes
• Claim-to-source table
• Known limitations
• Thai publication draft
• Reviewer decision

จากนั้นเสนอ proposal:

~~~bash openclaw skills workshop propose-create --name thai-community-research-handoff --description "Research and verify Thai community content" --proposal ./PROPOSAL.md

openclaw skills workshop list openclaw skills workshop inspect ~~~

หัวใจของ flow นี้คือ proposal ถูกเก็บแยกจาก skill ที่ใช้งานจริง ขณะยัง pending จะไม่มี SKILL.md ใหม่ไปเปลี่ยนพฤติกรรม agent

หาก reviewer พบว่าเกณฑ์ยังไม่พอ ให้แก้ proposal แล้ว revise:

~~~bash openclaw skills workshop revise --proposal ./PROPOSAL.md openclaw skills workshop inspect ~~~

เมื่อผ่านการตรวจจึง apply:

~~~bash openclaw skills workshop apply openclaw skills check ~~~

ก่อน apply ระบบจะตรวจ scanner/hash อีกครั้ง และเขียน rollback metadata ก่อนเปลี่ยน live skill หาก proposal ไม่เหมาะสมสามารถ reject หรือ quarantine ได้:

~~~bash openclaw skills workshop reject openclaw skills workshop quarantine ~~~

Governance ที่ควรใช้ในองค์กร

ค่าเริ่มต้นที่เหมาะกับทีมคือ approvalPolicy: "pending" เพราะการ apply, reject หรือ quarantine ที่ agent เป็นผู้เริ่มยังต้องผ่าน operator approval ส่วน approvalPolicy: "auto" ควรใช้เฉพาะ workspace ที่แยกขอบเขตและผ่านการทดสอบแล้ว

กติกาง่ายๆ ที่ช่วยลดความเสี่ยง:

1. agent เสนอได้ แต่คนเป็นผู้อนุมัติการเปลี่ยน live skill 2. proposal ต้องมีตัวอย่าง input/output และ failure cases 3. script ใน proposal ต้องมีขอบเขต path, network และ secret ชัดเจน 4. skill ที่กระทบ production ต้องทดลองใน workspace แยก 5. ทุกการ apply ต้องมีเจ้าของและเหตุผลที่ย้อนตรวจได้

Skill Workshop รองรับ support files ภายใต้ assets/, examples/, references/, scripts/ และ templates/ จึงสามารถ review ทั้งคำสั่ง ตัวอย่าง และไฟล์ประกอบเป็นชุดเดียวกันได้

ปัญหาที่พบบ่อย

Workboard tab ขึ้น unavailable

ตรวจว่า plugin เปิดแล้ว และไม่มี plugins.allow หรือ plugins.deny บล็อก workboard จากนั้น restart Gateway

Dispatch แล้ว worker ไม่เริ่ม

ตรวจว่ามีการ์ดสถานะ ready และไม่มี active claim:

~~~bash openclaw workboard list --status ready ~~~

หาก CLI รายงาน data-only dispatch แปลว่า Gateway ไม่พร้อม ระบบอาจจัดการ dependency หรือ stale claim ได้ แต่ไม่สามารถเริ่ม subagent worker ต้อง start/restart Gateway แล้ว dispatch ใหม่

Agent มองไม่เห็น skill_workshop

ตรวจ tool policy ว่า profile มี skill_workshop และไม่ได้อยู่ใน sandboxed run หากใช้ allowlist ให้เพิ่มเครื่องมือนี้อย่างชัดเจน

Proposal กลายเป็น stale

เกิดเมื่อ live skill เปลี่ยนหลังสร้าง proposal ให้ revise เทียบกับ target ล่าสุด หรือสร้าง proposal ใหม่ อย่าฝืน apply proposal เก่า

สิ่งที่น่าว้าวจริง

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

Workboard ทำให้เราเห็นปัญหาหน้างาน: การ์ดไหนติด ใครถือ proof อยู่ และ handoff ตรงไหนพัง ส่วน Skill Workshop ทำให้ทีมเก็บสิ่งที่เรียนรู้จากปัญหาเหล่านั้นเป็น proposal ที่ตรวจสอบได้ ก่อนยกระดับเป็น skill จริง

ดังนั้น multi-agent ที่ดีไม่ใช่การเปิด agent ให้มากที่สุด แต่คือการออกแบบให้ทุกงานมี owner, state, evidence, review และทางย้อนกลับ เมื่อองค์ประกอบเหล่านี้ครบ agent หลายตัวจึงเริ่มทำงานเหมือนระบบ ไม่ใช่กลุ่ม bot ที่คุยพร้อมกัน

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

• Workboard plugin: https://docs.openclaw.ai/plugins/workboard
• Workboard CLI: https://docs.openclaw.ai/cli/workboard
• Skill Workshop: https://docs.openclaw.ai/tools/skill-workshop
• Skills configuration: https://docs.openclaw.ai/tools/skills-config
• Skills CLI: https://docs.openclaw.ai/cli/skills