Microsoft Research เปิดซอร์ส Agensh: harness ที่ให้ agent 1,024 ตัวแบ่งงานกันเองโดยไม่มี orchestrator — สร้าง pandoc ใหม่ได้ผ่านเทสต์ 55% เทียบกับ 34% ของ agent ตัวเดียว แต่ไม่รายงานต้นทุนโทเคนเลย และจาก 1 เป็น 8 ตัวได้เพิ่มแค่ 1.4 แต้ม

Microsoft Research (ทีม General AI ของ Furu Wei) เปิดซอร์ส Agensh ภายใต้ไลเซนส์ MIT ส่วน News ของรีโประบุวันที่ปล่อยเป็น 24 ต.ค. 2026 (commit แรกบน GitHub ลงวันที่ 22 ต.ค.) โค้ดนี้ตามหลัง preprint บน arXiv ที่เผยแพร่ไว้ตั้งแต่ 22 ก.ย. Agensh เป็น harness สำหรับ multi-agent ที่ ไม่มี orchestrator กลางคอยแจกงาน agent ทุกตัวได้ prompt เดียวกัน (ต่างกันแค่หมายเลข worker) แล้ววนลูปเดียวกันคือ เก็บ context → จองงานย่อยเอง → ลงมือ → ตรวจผล → merge แบบ asynchronous ทีมทดลองไปจนถึง 1,024 agent พร้อมกัน

ข่าวนี้ออกมาสองวันหลัง Anthropic แนะนำให้ยุบ subagent กลับเข้า agent loop เดียว สองแล็บใหญ่จึงเสนอทิศทางตรงข้ามกันในสัปดาห์เดียว แต่ถ้าอ่านรายละเอียด สองข้อเสนอนี้ตอบโจทย์คนละแบบ

ทำงานอย่างไร

Agensh ใช้ซอฟต์แวร์ทีมทั่วไปเป็นโครงสร้างพื้นฐานของ “องค์กร agent”

• Gitea เป็น shared workspace ใช้ issue และ PR เป็นตัวบอกว่างานไหนเสนอแล้ว มีคนทำอยู่ หรือเสร็จแล้ว
• Mattermost ใช้ส่งข้อความระหว่าง agent
• Shared context (ดัดแปลงจากโปรเจกต์ DeLM) เก็บสิ่งที่ค้นพบและเจตนาว่าใครกำลังจะทำอะไร ระบบแทรกข้อความใหม่เข้าไปในผลลัพธ์ของ MCP tool ทุกครั้งที่ agent เรียกใช้
• agent แต่ละตัวรันบน Copilot harness (GitHub Copilot CLI ผ่าน ACP) ใช้ GPT-5.6-sol ที่ reasoning high, input สูงสุด 272K โทเคน

ตามรายงาน เมื่อทีมใหญ่ขึ้นก็เริ่มมีพฤติกรรมที่ไม่ได้สั่งไว้ เช่น agent ประกาศ interface กลางให้ตัวอื่นทำตาม แก้ปัญหาเองเมื่อจองงานซ้อนกัน และที่ 1,024 ตัวเริ่มมี agent ที่รับบทเฉพาะอย่างผู้ดูแล integration

ผลบน ProgramBench

ProgramBench (ของ Meta) ให้ agent สร้างโปรแกรมจริงขึ้นใหม่ตั้งแต่ศูนย์ จากการสังเกตพฤติกรรมของโปรแกรมและเอกสาร โดยไม่มีอินเทอร์เน็ต ให้เวลา 6 ชั่วโมง ทีมเลือก 5 โจทย์ที่ยากที่สุดจาก 200 โจทย์ ได้แก่ FFmpeg, gromacs, pandoc, PHP-src และ ctags

จำนวน agent	test-pass เฉลี่ย 5 โจทย์
1	19.31%
8	20.68%
32	26.52%
128	28.78%

• เฉพาะ pandoc: 1 ตัวได้ 33.89% → 128 ตัวได้ 50.94% → 1,024 ตัวได้ 55.06% (ใช้ 16 เครื่อง เครื่องละ 64 agent)
• ทีมใหญ่ไปถึงคะแนนเดียวกันได้เร็วกว่า บน pandoc ทีม 128 ตัวผ่าน 30% ได้ภายใน 30 นาที ขณะที่ agent ตัวเดียวยังไม่ถึงเกณฑ์นี้ในสองชั่วโมงแรก
• README มีผลเพิ่มที่ไม่อยู่ในเปเปอร์ คือเมื่อใช้ GPT-6.1-sol บน pandoc คะแนนขึ้นจาก 56.19% (1 ตัว) เป็น 79.59% (32 ตัว)

สิ่งที่ตัวเลขไม่ได้บอก

• ไม่มีต้นทุนเลย เปเปอร์ไม่รายงานจำนวนโทเคนหรือค่าใช้จ่าย ทีม 1,024 ตัวที่รัน 6 ชั่วโมงใช้ agent-hour มากกว่า agent ตัวเดียวราวพันเท่า (หักช่วงที่ทยอยเปิด agent ทีละตัวในชั่วโมงแรก) แต่ได้คะแนน pandoc เพิ่มเพียง 21 แต้ม และจาก 128 เป็น 1,024 ตัว ซึ่งใช้ agent มากขึ้นแปดเท่า ได้เพิ่มแค่ 4.12 แต้ม
• ไม่ได้เทียบกับ compute ที่เท่ากัน baseline คือ agent ตัวเดียวที่มีเวลา 6 ชั่วโมงเท่ากัน ไม่ใช่ agent ตัวเดียวที่ได้งบโทเคนเท่าทีม ข้อสรุปที่เปเปอร์ใช้ได้จริงจึงเป็นเรื่อง “ทำเสร็จเร็วขึ้นภายใต้เส้นตายเดียวกัน” ซึ่งตัวเปเปอร์เองก็บอกไว้ในบทคัดย่อว่าเหมาะกับงานที่มี “hard latency constraints or time budgets”
• ช่วงแรกได้ผลน้อยมาก จาก 1 เป็น 8 ตัว คะแนนเฉลี่ยขึ้นแค่ 1.37 แต้ม ผลชัดเริ่มเห็นตั้งแต่ 32 ตัวขึ้นไป
• baseline agent ตัวเดียวต้องใส่ stop hook ที่คอยบอกว่า “There is always new work” เพราะทีมพบว่าถ้าไม่ใส่ agent ตัวเดียวแทบไม่เคยทำงานครบ 6 ชั่วโมง

รีโปที่ปล่อยมาเป็นชุดสำหรับทำซ้ำการทดลอง ไม่ใช่เครื่องมือที่หยิบไปใช้ได้ทันที ต้องใช้ Linux ที่มี Docker, systemd, cgroup v2 และ sudo แบบไม่ใส่รหัสผ่าน ค่าเริ่มต้นคือ 8 worker ใช้ GPT-5.6-sol ผ่าน gateway ที่ตั้งเอง และรีโปที่ปล่อยมีแค่ชุดสำหรับเครื่องเดียว

มุมมอง AI Curator

ถ้าอ่านคู่กับบทความของ Anthropic เมื่อวันพฤหัสฯ จะเห็นว่าสองแล็บไม่ได้ขัดกันอย่างที่พาดหัวชวนให้คิด Anthropic พูดถึงงานทั่วไปที่ต้นทุนและความถูกต้องสำคัญที่สุด ซึ่งในงานแบบนั้น subagent เพิ่ม overhead โดยไม่จำเป็น ส่วน Agensh พูดถึงงานที่มีเส้นตายชัดและยอมจ่ายค่า compute เท่าไรก็ได้ จุดที่น่าสนใจจริงของ Agensh ไม่ใช่ตัวเลข 1,024 แต่เป็นการเลือกไม่สร้างโครงสร้างประสานงานใหม่ แล้วใช้ Gitea, Mattermost และ PR ซึ่งทีมคนใช้กันอยู่แล้ว ข้อนี้ทำให้มนุษย์อ่านย้อนดูได้ทุกขั้นว่า agent ตัดสินใจอะไรไป และสอดคล้องกับแนวที่ GitHub, Cursor และเครื่องมืออื่นกำลังพาไป คือให้ agent ทำงานผ่าน workflow แบบทีมเดียวกับที่คนใช้

สำหรับทีมพัฒนาในไทยที่จ่ายค่า API เป็นเงินบาท ข้อสรุปที่ใช้ได้จริงคือ อย่าเพิ่งเพิ่มจำนวน agent ถ้ายังไม่ได้วัดต้นทุน ข้อมูลของ Microsoft เองแสดงว่าจาก 1 เป็น 8 agent แทบไม่ได้อะไรเพิ่ม และเปเปอร์ไม่มีตัวเลขค่าใช้จ่ายให้คำนวณความคุ้มเลย งานที่เหมาะกับแนวทางนี้คือโปรเจกต์ใหญ่ที่แบ่งเป็นส่วนอิสระได้ชัด และเวลามีค่ามากกว่าเงินจริง ๆ เช่น migrate โค้ดเก่าก่อนเส้นตายของลูกค้า สำหรับงานประจำวัน แนวของ Anthropic ที่ใช้ agent ตัวเดียวกับ skill ที่ดีน่าจะคุ้มกว่า ถ้า Microsoft เปิดเผยตัวเลขโทเคนต่อแต้มที่เพิ่มขึ้นในอนาคต ตอนนั้นเราจะรู้ได้จริงว่าการเพิ่มจำนวน agent ที่เปเปอร์เรียกว่า “new scaling dimension” คุ้มค่าเพียงใด

แหล่งข่าว

• GitHub — microsoft/Agensh (โค้ด, README, ผล GPT-6.1-sol)
• arXiv — Agensh: Scaling Organizational Intelligence to 1,024 Agents (2609.26781)
• Agensh — REPRODUCE.md (ข้อกำหนดและวิธีทำซ้ำการทดลอง)
• GitHub — facebookresearch/ProgramBench