Agency Agents 132K ดาว: มี AI Specialist 263 บทบาท แต่ทีมแรกควรมีแค่ 5

ผมเปิด GitHub repo ชื่อ Agency Agents แล้วเจอสิ่งที่น่าสนใจมากครับ

มันรวม AI Specialist ไว้ 263 บทบาท กระจายอยู่ใน 17 divisions

มีทั้ง Frontend Developer, Backend Architect, Security Architect, UX Researcher, Content Creator, Sales Strategist, Evidence Collector และ Reality Checker

Repo นี้มีดาวมากกว่า 132K และมีตัวแปลง role ไปใช้กับเครื่องมือ 16 ตัว เช่น Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, OpenClaw และ Hermes

ฟังดูเหมือนเรากำลังดาวน์โหลดบริษัท AI สำเร็จรูปมาไว้ในเครื่อง

แต่คำถามแรกที่ผมอยากถามไม่ใช่

“ติดตั้งอย่างไร”

คำถามคือ

ถ้ามี AI Specialist 263 บทบาท แล้วใครควรทำงานชิ้นแรก

เพราะปัญหาของทีม AI ไม่ได้เริ่มตอน Agent น้อยเกินไป

หลายครั้งมันเริ่มตอนเรามี Agent เยอะเกินไป แต่ไม่มีเจ้าของงาน ไม่มี handoff ไม่มี acceptance criteria และไม่มี proof ว่า role ที่เพิ่มมาช่วยให้งานดีขึ้นจริง

Agency Agents คืออะไร

Agency Agents ไม่ใช่โมเดล AI และไม่ใช่ runtime ที่เปิดขึ้นมาแล้วบริษัททำงานเองทันที

แก่นของมันคือ role definition library

แต่ละ Agent เป็นไฟล์ Markdown พร้อม frontmatter ที่บอกว่า Agent ตัวนั้นคือใคร รับผิดชอบอะไร ทำงานแบบไหน ส่งมอบอะไร สื่อสารอย่างไร และวัดความสำเร็จจากอะไร

ตัวอย่างเช่น

• Frontend Developer มี workflow ตั้งแต่ requirement ไปถึง implementation, performance และ accessibility
• Evidence Collector บังคับให้เก็บภาพและหลักฐานจากระบบจริง
• Reality Checker ตั้งต้นด้วย NEEDS WORK จนกว่าจะมี proof มากพอ
• Content Creator มี decision framework และ success metrics สำหรับงาน content
• Agents Orchestrator อธิบาย pipeline ตั้งแต่ project management ไปถึง architecture, implementation, QA และ reality check

สิ่งที่ repo ทำได้ดีคือ เปลี่ยนคำว่า “ช่วยทำงานนี้หน่อย” ให้กลายเป็น role ที่มีท่าที ขั้นตอน และ deliverable ชัดขึ้น

เราสามารถอ่าน แก้ และ version control role เหล่านี้ได้

นี่คือแนวคิดแบบ Org Chart as Code

แต่ต้องระวังคำว่า Code ในที่นี้ครับ

Agent file ส่วนใหญ่ยังเป็น instruction และ workflow definition

ความสามารถจริงยังขึ้นกับ host ที่นำมันไปรัน

• โมเดลเก่งแค่ไหน
• มี tool อะไรให้ใช้
• tool permission ถูกบังคับจริงหรือไม่
• context แยกกันหรือไม่
• delegation ทำอย่างไร
• งบ token เท่าไร
• ใครตรวจผลลัพธ์

Role ที่เขียนว่า Security Architect ไม่ได้ทำให้ระบบปลอดภัยอัตโนมัติ

Role ที่เขียนว่า Evidence Collector ก็ไม่ได้แปลว่ามันเปิด browser หรือถ่าย screenshot ได้ ถ้า host ไม่ได้ให้เครื่องมือเหล่านั้น

132K ดาวคือสัญญาณความสนใจ ไม่ใช่ benchmark คุณภาพ

ตัวเลขดาวของ Agency Agents ใหญ่มาก และสะท้อนชัดว่าคนกำลังมองหา role สำเร็จรูปสำหรับ AI workflow

แต่ดาวบน GitHub ไม่ได้ตอบคำถามว่า

• role ไหนช่วยให้งานเราดีขึ้น
• role ไหนซ้ำกัน
• role ไหนทำให้ review ช้าลง
• role ไหนใช้ token มากกว่ามูลค่าที่สร้าง
• role ไหนต้องปรับให้เข้าใจธุรกิจเราใหม่

งานทดลองของ Steve Hocking ใช้ Agent บางส่วนกับ GitHub Copilot เพื่อปรับเว็บไซต์จริง

ผลลัพธ์ทำงานได้ และมีบางจุดที่เหมือน persona ช่วยกำหนด design language

แต่เขาพูดตรง ๆ ว่า แยกยากว่าผลดีมาจาก role definition หรือความสามารถพื้นฐานของ Copilot

อีกการทดลองจาก Agent Cookbooks รัน persona 6 ตัวกับ artifact จริง

ได้ finding ที่ใช้ได้ 3 เรื่อง แต่ใช้ประมาณ 390K agent tokens

บทเรียนไม่ได้แปลว่า Agent ไม่คุ้ม

บทเรียนคือ ถ้าจะใช้หลาย role ต้องให้แต่ละ role ตรวจคนละเรื่องกับ artifact ที่ระบุชัด

ถ้าสั่งกว้าง ๆ ว่า “ช่วยดูเว็บนี้หน่อย” หลาย Agent จะส่งคำตอบที่ดูฉลาด แต่ตรวจย้อนกลับยาก

ถ้าสั่งว่า “ตรวจ commit นี้ว่ามี frontmatter หลุดจาก schema หรือไม่ พร้อมอ้างไฟล์และบรรทัด” โอกาสได้ proof ที่ใช้ได้จะสูงขึ้นมาก

Repo ให้ role แต่ runtime ต้องจัดทีม

ใน GitHub Discussion #397 มีคนถามว่าจะเปิดหลาย Agent ให้ทำงานร่วมกันใน Claude Code ได้อย่างไร

คำตอบในตอนนั้นชัดเจนว่า individual Agent ใช้งานได้ แต่ repo ไม่ได้ทำ multi-agent orchestration ให้เอง

ทางเลือกคือรันแบบลำดับ ใช้ meta-prompt รวมหลายมุม หรือเพิ่ม wrapper/runtime สำหรับ parallel execution

ประเด็นนี้สำคัญมาก

Agent catalog กับ Agent runtime เป็นคนละชั้น

Catalog บอกว่าเรามีใครบ้าง

Runtime ตัดสินว่าใครทำเมื่อไร อ่านอะไร ใช้ tool ไหน ใช้งบเท่าไร ส่งต่อให้ใคร และต้องหยุดถามคนตอนไหน

ถ้าสองชั้นนี้ปนกัน เราจะคิดว่าแค่มี persona ก็เท่ากับมีทีม

แต่ในงานจริง persona เป็นเพียงจุดเริ่มต้น

Hermes integration ให้บทเรียนเรื่อง Lazy Routing

ส่วนที่ผมชอบที่สุดของ repo นี้คือ Hermes integration

แทนที่จะโหลด Agent 263 ตัวเข้า context ทุกครั้ง มันเก็บ roster ทั้งหมดไว้บน disk แล้วเปิด tool หลัก 4 ตัว

• search หา specialist ตาม capability
• inspect ดูรายละเอียดก่อนใช้
• load โหลด role ที่ต้องการเข้ามา
• delegate ส่งงานให้ subagent เมื่อเหมาะสม

แนวคิดนี้เรียกว่า lazy routing

มันแยก ความกว้างของ catalog ออกจาก ต้นทุน context ของงานหนึ่งชิ้น

เรามีผู้เชี่ยวชาญ 263 บทบาทได้ แต่ไม่ต้องเรียกประชุม 263 คนทุกเช้า

งานแต่ละช่วงใช้เฉพาะ role ที่จำเป็น

นี่เป็น pattern ที่เหมาะกับ AI coworker มากกว่า preload ทุกอย่างไว้ใน prompt ใหญ่ก้อนเดียว

ถ้าเอาไปใช้บน runtime อย่าง Hermes หรือ environment แบบ OPB Stack สิ่งที่ต้องเติมต่อคือ memory, source of truth, sandbox, tool scope, schedule, approval และ proof

อย่าเริ่มด้วย 263 ให้เริ่มด้วย 5

ถ้าผมต้องสร้างทีมแรกจาก Agency Agents ผมจะไม่เลือกตาม division และไม่เลือก role ที่ชื่อดูเท่ที่สุด

ผมจะเลือกตามหน้าที่ในวงจรงาน

1. Work Owner

ตัวอย่าง Agent: Senior Project Manager

หน้าที่คือกำหนด

• outcome
• scope
• definition of done
• task order
• stop condition

Role นี้ไม่จำเป็นต้องลงมือทำ artifact หลัก

แต่ต้องตอบได้ว่า งานเสร็จคืออะไร และอะไรไม่อยู่ในงานรอบนี้

2. Maker

ตัวอย่าง Agent:

• Frontend Developer สำหรับหน้าเว็บ
• Backend Architect สำหรับระบบ
• Content Creator สำหรับบทความ
• Sales Outreach สำหรับ lead workflow

Maker ควรมีเพียงหนึ่งตัวต่อ artifact หลักในรอบแรก

ถ้ามี Maker หลายตัวแก้ไฟล์เดียวกันพร้อมกัน เราต้องมี isolation และ merge policy ไม่เช่นนั้น throughput ที่เห็นจะกลายเป็น conflict

3. Risk Specialist

เลือกเพียงหนึ่งความเสี่ยงที่สำคัญที่สุดของงานนั้น

ตัวอย่าง

• Security Architect ตรวจ auth และ data exposure
• Accessibility Auditor ตรวจ keyboard, label และ contrast
• Tracking Specialist ตรวจ event และ attribution
• SEO Specialist ตรวจ indexing และ search intent

อย่าใส่ specialist ทุกด้านในงานชิ้นเล็ก

ให้เลือกจากความเสียหายที่ยอมรับไม่ได้

4. Reviewer

Reviewer ต้องอ่านจากมุมแยก ไม่ใช่ช่วย Maker แต่งเรื่องเดิมให้ดูดีขึ้น

Reviewer ควรมี

• checklist
• known failure cases
• input ที่ระบุชัด
• สิทธิ์เสนอแก้ แต่ไม่ควร merge หรือ publish เองโดย default

สำหรับงาน code อาจใช้ Code Reviewer

สำหรับ content อาจใช้ editor ที่ตรวจ claim, voice, SEO และ CTA แยกจากคนเขียน

5. Evidence Checker

ตัวอย่าง Agent: Evidence Collector หรือ Reality Checker

Role นี้มีหน้าที่ถามว่า

• เปิดหน้าใช้งานจริงหรือยัง
• test ผ่านจริงหรือยัง
• screenshot หรือ URL อยู่ไหน
• output ตรง acceptance criteria ข้อไหน
• มีอะไรที่ยังเป็น assumption

ผมชอบ Reality Checker เพราะมันเริ่มจาก NEEDS WORK

นี่เป็นท่าทีที่ดีสำหรับงาน AI

AI ไม่ควรได้สถานะ Done เพราะคำตอบดูมั่นใจ

มันควรได้สถานะ Done เพราะมี proof

Operator Kit: 5-Role Starter Canvas

ก่อนเพิ่ม Agent แต่ละตัว ให้กรอกตารางนี้

ช่อง	คำถามที่ต้องตอบ
Role	บทบาทนี้รับผิดชอบอะไรหนึ่งอย่าง
Outcome	ผลลัพธ์ธุรกิจที่ role นี้ต้องทำให้ดีขึ้น
Source of truth	อ่านข้อมูลจากไฟล์ ระบบ หรือ URL ไหน
Deliverable	ส่ง artifact อะไรในรูปแบบไหน
Tool scope	ใช้เครื่องมืออะไรได้
Forbidden actions	ห้าม publish, deploy, send, spend หรือแก้ข้อมูลใด
Reviewer	ใครตรวจ และตรวจด้วย rubric ไหน
Evidence	ต้องส่ง test, URL, screenshot, diff หรือ metric อะไร
Budget	จำกัดเวลา token หรือจำนวนรอบเท่าไร
Stop rule	เมื่อไรต้องหยุดและถามคน

ถ้ากรอกตารางนี้ไม่ได้ แปลว่า role ยังไม่พร้อมใช้งานจริง

แผนทดลอง 7 วัน

วันที่ 1 เลือก workflow เดียว

เลือกงานที่เกิดซ้ำ วัดได้ และความเสี่ยงไม่สูงมาก

ตัวอย่าง

• ทำ weekly competitor brief
• แก้ bug ขนาดเล็กพร้อม regression test
• สร้างบทความจาก source pack
• ตรวจหน้า landing page แล้วสรุป issue พร้อม screenshot

วันที่ 2 ออกแบบ 5 role

ให้แต่ละ role มีหน้าที่ไม่ซ้ำกัน

ถ้าสอง role เขียน deliverable เหมือนกัน ให้รวมก่อน

วันที่ 3 รันแบบลำดับ

เริ่มจาก Work Owner ไป Maker ไป Specialist ไป Reviewer ไป Evidence Checker

การรันแบบลำดับทำให้เห็น handoff และแก้ปัญหาง่ายกว่า parallel ตั้งแต่วันแรก

วันที่ 4 ทำ baseline

ให้ AI generalist ตัวเดียวทำงานเดียวกัน ด้วย context และงบใกล้เคียงกัน

ถ้าไม่มี baseline เราจะไม่รู้ว่า role library เพิ่มคุณค่าหรือเพิ่มพิธีกรรม

วันที่ 5 เปรียบเทียบผล

วัดอย่างน้อย 5 ตัว

1. accepted output
2. review time
3. rework
4. error หรือ missed issue
5. token หรือค่าใช้จ่าย

วันที่ 6 ปรับ role ให้เข้ากับบริษัท

เอา role สำเร็จรูปมาเป็น starting point เท่านั้น

เติม

• product truth
• customer language
• internal policy
• tool rules
• approval boundary
• known failure modes
• proof template

นี่คือจุดที่ role สาธารณะเริ่มกลายเป็น skill ของบริษัทเรา

วันที่ 7 ตัดสินใจ

มี 3 ทางเลือก

• Keep ถ้า role สร้างคุณค่าเฉพาะชัดเจน
• Merge ถ้า role ซ้ำกับตัวอื่น
• Delete ถ้าเพิ่ม review load มากกว่าคุณภาพ

การลบ Agent เป็นส่วนหนึ่งของการออกแบบระบบครับ

คำเตือนก่อนติดตั้ง

Repo นี้มี shell scripts สำหรับ convert และ install

ใน Security Policy ผู้สร้างบอกตรง ๆ ว่าควร review script ก่อนรัน

ถ้าไม่อยาก copy ทุกอย่างแบบมองไม่เห็น มี desktop app ที่ agencyagents.app สำหรับ browse, install, track และตรวจ drift ของไฟล์ได้

แต่ app ก็ระบุชัดว่า มันเป็น installer และ registry ไม่ใช่ runtime

ไม่ว่าจะใช้วิธีไหน กติกาควรเหมือนกัน

• เริ่ม project scope ก่อน global
• backup config เดิม
• เลือก role เท่าที่ใช้
• อ่าน tool permission
• ทดลองกับงาน low risk
• วัดผลก่อนเพิ่มจำนวน

สรุป

Agency Agents เป็น open-source library ที่มีคุณค่ามาก เพราะมันทำให้เราไม่ต้องเริ่มออกแบบ AI role จากหน้ากระดาษเปล่า

เราสามารถเปิดดู specialist หลายร้อยบทบาท อ่าน workflow, deliverable, success metrics แล้วเลือกสิ่งที่เหมาะกับงานจริง

แต่สิ่งที่ไม่ควรทำคือ เอาจำนวน role มาแทนคุณภาพของระบบ

ทีม AI ที่ดีไม่ใช่ทีมที่มี Agent เยอะที่สุด

มันคือทีมที่ตอบได้ว่า

• ใคร owns งาน
• ใครสร้าง
• ใครตรวจความเสี่ยง
• ใคร review
• proof อยู่ไหน
• และเมื่อไรต้องหยุดถามคน

ถ้าจะเริ่มกับ Agency Agents

อย่าเริ่มจากคำถามว่า “เราจะติดตั้ง 263 ตัวอย่างไร”

ให้เริ่มจากคำถามว่า

Workflow แรกของเราต้องใช้ 5 role อะไร เพื่อทำให้งานดีขึ้นแบบวัดได้

นั่นคือจุดที่ AI Org Chart เริ่มกลายเป็นระบบทำงานจริงครับ