โดย Nokka (นก-กา) | ตรวจข้อมูล 26 ต.ค. 2026

บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

ภาพเปิด: โรงงานขนาดเล็กในความมืด มีสถานีทำงานหลายจุดเรียงเป็นสายพาน และหุ่นยนต์ตัวเล็กประจำแต่ละสถานี

โพสต์ที่ผมเห็นบน X (Twitter) เริ่มด้วยประโยคที่ตรงประเด็นมาก "coding agent เขียนไฟล์ได้ แต่รีโปนี้ประสานงานวิศวกรรมทั้งหมดรอบ ๆ ไฟล์นั้น" [1]

เจ้าของโพสต์คือ Dan Kornas เขาแนะนำโปรเจกต์ชื่อ SWE-AF ซึ่งเป็น runtime สำหรับทีมวิศวกรรมอัตโนมัติที่สร้างบน AgentField [1]

ตอนที่ผมเข้าไปดูเมื่อ 26 ต.ค. 2026 รีโปมีดาวราว 1,100 ดวง [2] น้อยกว่าพวก agent coding ดัง ๆ มาก แต่ไอเดียข้างในน่าสนใจกว่าตัวเลขดาว

SWE-AF คืออะไร

ไม่ใช่ agent ตัวเดียว แต่เป็นทีมที่มีบทบาท

รีโปอธิบายตัวเองว่าเป็น runtime สำหรับทีมวิศวกรรมซอฟต์แวร์อัตโนมัติ ทำงานบน AgentField [2]

คุณสั่งงานด้วยเป้าหมายเดียว เช่น "เพิ่มระบบยืนยันตัวตนด้วย JWT" แล้วมันจะแตกงานออกเป็นแผน มอบหมายให้ agent หลายบทบาท ทั้งสถาปนิก นักเขียนโค้ด ผู้ตรวจโค้ด และ QA [2]

ทั้งหมดนี้ทำงานร่วมกันผ่าน build flow เดียว ไม่ใช่แชทแยกกันคนละหน้าต่าง

ใบอนุญาตและสถานะ

โปรเจกต์ใช้ Apache License 2.0 และประกาศตัวเองว่าเป็น public beta [2]

ถ้าติดตั้งจากซอร์ส ต้องมี Python 3.12 ขึ้นไปในเครื่อง และต้องมี AgentField เป็นแกนควบคุมก่อน [2] ตัว agent มีสอง implementation คือ Python (classic loop) และ Go (node ที่ af install ลงให้เป็นค่าเริ่มต้น) ส่วนแกนควบคุมเขียนด้วย Go [2][3]

ตัว AgentField เองก็เป็นโอเพนซอร์ส Apache 2.0 มีดาวราว 2,600 ดวง และนิยามตัวเองว่าเป็น backend สำหรับสร้างและรัน agent เหมือน API [3]

ข้างในทำงานอย่างไร

สามลูปควบคุมที่ไล่ระดับปัญหา

หัวใจของมันคือลูปสามชั้น [2]

ลูปในสุดทำงานกับ issue เดียว ถ้า QA หรือ reviewer ไม่ผ่าน นักเขียนโค้ดจะลองใหม่พร้อม feedback

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

ลูปนอกทำงานกับแผนที่เหลือทั้งหมด ถ้าพังหนักพอ มันจะจัดโครงสร้าง issue และ dependency ใหม่

แผนที่ปรับได้ระหว่างทาง

จุดที่ผมคิดว่าต่างจาก agent ทั่วไปคือมันไม่ได้ถือแผนเดิมแบบตายตัว

เมื่อเจอปัญหาที่ยากกว่าที่ประเมิน มันจะเปลี่ยนลำดับงานและเพิ่มงานที่จำเป็น ซึ่งรีโปเรียกว่า DAG-level replanning [2]

นี่คือพฤติกรรมของทีมจริง ไม่ใช่พฤติกรรมของสคริปต์ที่รันตามรายการ

งานขนานที่ไม่ชนกัน

มันใช้ git worktree แยกสำหรับแต่ละงานที่รันพร้อมกัน ทำให้ agent หลายตัวแก้โค้ดได้โดยไม่แย่ง branch กัน [2]

ยังมี checkpoint ทำให้ build ที่ล้มกลางทางกลับมารันต่อได้ ไม่ต้องเริ่มใหม่ทั้งหมด [2]

ตั้งโมเดลแยกตามบทบาท

คุณกำหนดได้ว่า coder ใช้โมเดลอะไร QA ใช้ตัวไหน และ architect ใช้อะไร [2]

มันรองรับหลายผู้ให้บริการ ทั้ง Claude, OpenRouter, OpenAI และ Google ใน build เดียวกัน

ตัวอย่างคำสั่งติดตั้งสั้น ๆ มีอยู่ใน README [2]

af install https://github.com/Agent-Field/SWE-AF af run swe-planner af call swe-planner.build --in '{"goal": "Add JWT auth", "repo_url": "https://github.com/user/my-repo"}'

ตัวเลขที่ทำให้คนสนใจ

เคสจริงที่อ้างในรีโป

รีโปยกตัวอย่าง pull request หมายเลข 179 ของ AgentField ที่สร้างโดย SWE-AF ทั้งหมด [2][4]

ผลที่ระบุคือปิด issue ครบ 10 จาก 10 เทสต์ผ่าน 217 ตัว เกณฑ์ยอมรับผ่าน 34 จาก 34 และใช้ agent ไป 79 ครั้ง [2]

ค่าใช้จ่ายรวมอยู่ที่ 19.23 ดอลลาร์ โดยใช้โมเดลระดับ haiku [2]

ถ้าตัวเลขนี้จริง มันหมายความว่าทีม agent ทำงานหนึ่งรอบจบได้ในราคาใกล้เคียงค่าอาหารกลางวันของทีมเล็ก ๆ

Benchmark ที่ต้องอ่านอย่างระวัง

รีโปอ้างว่าทำคะแนนได้ 95 จาก 100 เมื่อใช้ haiku และ MiniMax M2.5 เทียบกับ Claude Code รุ่น sonnet ที่ได้ 73, Codex o3 ที่ได้ 62 และ Claude Code haiku ที่ได้ 59 [2]

ตัวเลขนี้เป็น self-reported จากทีมผู้พัฒนาเอง และมาจากโจทย์เดียว ไม่ใช่การทดสอบซ้ำหลายรอบ

ผมจึงอ่านเป็นสัญญาณว่าสถาปัตยกรรมทีมช่วยได้ในงานบางประเภท ไม่ใช่หลักฐานว่ามันชนะทุกงาน

ต้นทุนกระจายอยู่ที่บทบาทไหน

ตารางแยกค่าใช้จ่ายในรีโปแสดงว่า coder กินเงินมากที่สุดที่ 5.88 ดอลลาร์ หรือราว 30% รองลงมาคือ code reviewer 3.48 ดอลลาร์ [2]

ที่น่าสนใจคือ planning ทั้งหมด ทั้ง PM, architect, tech lead และ sprint ใช้เงินรวมกันเพียง 0.79 ดอลลาร์ [2]

ตัวเลขนี้บอกอะไรบางอย่างเกี่ยวกับเศรษฐกิจของ agent ผมอ่านว่าการคิดแผนถูกกว่าการลงมือมาก

สิ่งที่มันเปลี่ยนในวิธีทำงาน

หน่วยของงานเปลี่ยนจาก prompt เป็นเป้าหมาย

ถ้าใช้ agent ทั่วไป คุณต้องเขียน prompt หลายรอบและคุมจังหวะเอง

แต่ถ้าใช้ runtime แบบนี้ หน่วยงานคือ goal หนึ่งข้อ แล้วระบบจัดการว่าจะแตกเป็นอะไรและใครทำ

คนจึงต้องเก่งการเขียนเป้าหมายและเกณฑ์ยอมรับมากขึ้น ไม่ใช่เก่งแค่การเขียน prompt

คอขวดย้ายไปที่การรีวิวและ merge

เมื่อ agent ผลิตโค้ดได้เร็ว สิ่งที่ช้าลงคือคนที่ต้องอ่านและอนุมัติ

รีโปแก้ปัญหาส่วนนี้ด้วย reviewer agent แต่สุดท้ายอำนาจ merge ยังอยู่ที่ทีมมนุษย์ [2] ซึ่งเป็นจุดที่ต้องออกแบบให้ชัด

การวัดผลเปลี่ยนจาก "โค้ดสวยไหม" เป็น "งานเสร็จและไม่ต้องกลับมาแก้ไหม"

เครื่องมือแบบนี้ทำให้เราวัดทีมด้วยอัตราการปิดงาน ไม่ใช่ด้วยจำนวนบรรทัด

แต่มันก็เปิดช่องให้ทีมเร่งปิด issue โดยลดคุณภาพ ซึ่งต้องมีคนคอยดู

ความเสี่ยงที่ต้องรู้ก่อนลอง

benchmark ของผู้พัฒนาเอง

ตัวเลข 95 จาก 100 ฟังดูดี แต่ผมยังไม่พบรีวิวอิสระที่ทำซ้ำในเงื่อนไขเดียวกัน

ผมจึงแนะนำให้ลองกับงานของคุณเอง โดยเก็บ baseline จากวิธีเดิมก่อน แล้วค่อยเทียบ

สถานะ public beta

รีโปประกาศชัดว่าเป็น beta [2] แปลว่าอาจมี bug และ API อาจเปลี่ยน

อย่าเพิ่งเอาไปรันกับรีโปที่ใช้งานจริง โดยไม่มีคนเฝ้า

สิทธิ์ที่คุณให้มัน

การให้ agent เปิด pull request ต้องใช้ GH_TOKEN ที่มี scope repo และใช้เฉพาะเมื่อต้องโคลนรีโปส่วนตัวหรือเปิด PR ส่วนรีโปสาธารณะทำงานได้โดยไม่ต้องใช้ token นี้ [2]

ถ้าเลี่ยงไม่ได้ที่ต้องใช้ scope repo ให้สร้าง fine-grained token ที่เจาะจงรีโปเดียว และใช้บัญชีแยกสำหรับงานอัตโนมัติ ไม่ใช่บัญชีส่วนตัวของคุณ

หนี้ทางเทคนิคที่ถูกบันทึกอย่างเป็นระเบียบ

ระบบมีกลไกบันทึกเมื่อต้องลดขอบเขตงาน และจัดประเภทหนี้เหล่านั้น [2]

ข้อดีคือมันไม่เงียบ แต่ข้อเสียคือมันอาจกลายเป็นรายการยาวที่ไม่มีใครกลับมาเก็บ

ถ้าจะลอง ควรเริ่มอย่างไร

เลือกงานหนึ่งที่วัดผลได้

ไม่ต้องเริ่มจากโปรเจกต์ใหญ่ ให้เลือกงานที่มีเกณฑ์ชัด เช่น เพิ่ม endpoint หนึ่งตัวพร้อมเทสต์

วัดเวลาที่ทีมใช้ทำด้วยมือ แล้วเทียบกับเวลาที่ใช้กับ SWE-AF รวมเวลารีวิว

กำหนดคนอนุมัติให้ชัด

ทุก pull request ต้องมีคนอ่าน และต้องมีคนตัดสินว่าจะ merge หรือไม่

SWE-AF หยุดที่การเปิด PR สถานะพร้อมรีวิว ไม่ได้ merge เข้า main ให้ [2] สิ่งที่ต้องคุมคืออย่าตั้ง auto-merge หรือกด merge PR ของ agent โดยไม่อ่านเองในเดือนแรก ไม่ว่าผลทดสอบจะผ่านแค่ไหน

ตัว merger ในระบบ merge เพียง branch ของ agent เข้า integration branch ก่อนเปิด PR ไม่ใช่ merge เข้า main

เริ่มจาก single-repo mode

รีโปมีโหมดหลายรีโป แต่ผมแนะนำให้เริ่มจาก single-repository mode ก่อน [2] พอเข้าใจพฤติกรรมแล้วค่อยขยับเป็น multi-repo ที่มีทั้ง primary และ dependency

เก็บข้อมูลค่าใช้จ่ายทุกครั้ง

README แสดงค่าใช้จ่ายแยกตามบทบาทในเคสตัวอย่าง [2] ให้เก็บตัวเลขจาก build ของคุณเองไว้เทียบระหว่างงานแต่ละประเภท

ถ้างานหนึ่งใช้เงิน 20 ดอลลาร์แต่ประหยัดเวลาทีมได้ครึ่งวัน มันอาจคุ้ม แต่ถ้าใช้ 200 ดอลลาร์แล้วยังต้องแก้เองครึ่งหนึ่ง ก็ไม่คุ้ม

ใครควรลอง และใครควรดูอยู่ห่าง ๆ

ควรลองถ้า

ทีมคุณมีงานซอฟต์แวร์ปริมาณมาก มีชุดเทสต์ที่เชื่อถือได้ และมีคนพร้อมตรวจงานทุกวัน

ควรดูอยู่ห่าง ๆ ถ้า

ทีมยังไม่มีเทสต์ ไม่มีกระบวนการรีวิว หรือกำลังทำงานที่ความผิดพลาดกระทบลูกค้าโดยตรง

เพราะเครื่องมือแบบนี้จะเร่งกระบวนการที่มีอยู่ ถ้ากระบวนการอ่อน มันจะทำให้ความอ่อนนั้นเร็วขึ้น

สิ่งที่ผมคิดว่าโปรเจกต์นี้บอกเรา

Agent coding กำลังเคลื่อนจาก "เขียนโค้ดเก่ง" ไปเป็น "จัดการงานเก่ง"

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

SWE-AF ยังเป็น beta และตัวเลขยังต้องพิสูจน์ แต่ทิศทางที่มันชี้ชัดเจน

ถ้าคุณกำลังคิดจะลอง ให้เริ่มด้วยงานเล็ก วัดผลจริง และเก็บอำนาจ merge ไว้กับคนก่อน

REF

[1] Dan Kornas (25 ต.ค. 2026) · โพสต์แนะนำ SWE-AF. https://x.com/DanKornas/status/2114144009329271026
[2] Agent-Field (2026) · SWE-AF: Autonomous Engineering Team Runtime. https://github.com/Agent-Field/SWE-AF
[3] Agent-Field (2026) · AgentField: The AI Backend. https://github.com/Agent-Field/agentfield
[4] Agent-Field (2026) · Pull request #179: Add DID registration and VC generation for audit trails (README เรียกสั้นว่า Go SDK DID/VC Registration). https://github.com/Agent-Field/agentfield/pull/179