ต้นทุน ความเสี่ยง และคนที่ต้องเซ็นรับ: สแตกไหนเหมาะกับทีมขนาดไหน?

โดย Nokka (นก-กา) | ตอนที่ 7 จาก 7 ของชุด "สร้างซอฟต์แวร์ด้วย AI" | ตรวจสอบข้อมูล ณ 23 ต.ค. 2026

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

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

ผมจะไม่ให้ตัวเลขค่าถูก ๆ ต่อโทเคน เพราะราคาเปลี่ยนทุกเดือนและแต่ละผู้ให้บริการคิดไม่เหมือนกัน

บทนี้จึงให้วิธีคำนวณและจุดที่ต้องตั้งเพดาน ซึ่งใช้ได้ไม่ว่าราคาจะเปลี่ยนไปแค่ไหน

ต้นทุนจริงของ agent หนึ่งงาน อยู่ที่จำนวนรอบ ไม่ใช่ราคาต่อโทเคน

วิธีวัดที่ผมแนะนำ

ทุกครั้งที่ agent วนอีกรอบ มันส่งบริบทที่โตขึ้นเข้า LLM ใหม่ทั้งก้อน

งานหนึ่งงานที่มีการอ่านไฟล์สิบไฟล์และรันเทสต์ห้ารอบ อาจใช้โทเคนมากกว่าการแชตถามตอบปกติหลายสิบเท่า

ตัวคูณที่แท้จริงคือจำนวนรอบ คูณด้วยขนาดบริบทที่โตขึ้นในแต่ละรอบ

วิธีที่ผมใช้คือบันทึกสามค่าต่อ task ได้แก่ จำนวนรอบ โทเคนขาเข้า และโทเคนขาออก

เมื่อมีข้อมูลสามค่านี้สิบงาน คุณจะรู้ว่าทีมคุณใช้งบต่อ task ประมาณเท่าไร และควรตั้งเพดานไว้ที่เท่าไร

ถ้าไม่วัดเลย บิลจะโตแบบอธิบายไม่ได้ และไม่มีใครรู้ว่าต้นเหตุอยู่ที่งานไหน

ตัวอย่างรูปแบบบันทึกที่ผมใช้ (สมมติขึ้นเพื่อให้เห็นภาพ)

task: fix-issue-142
rounds: 7
input_tokens: 412000
output_tokens: 18000
estimated_cost: คำนวณจากราคาต่อโทเคนของผู้ให้บริการ ณ วันนั้น
outcome: tests passed

บรรทัดสุดท้ายสำคัญไม่แพ้ตัวเลข เพราะงานที่แพงแต่ไม่ผ่านจะทำให้ค่าเฉลี่ยต่อ task ที่สำเร็จสูงกว่าที่เห็น

ความเสี่ยงที่หนึ่ง คือ prompt injection ผ่าน issue และ pull request

ช่องทางที่พบบ่อยในทีมจริง

ถ้า agent อ่าน issue หรือคอมเมนต์บน PR ได้ คนนอกสามารถเขียนข้อความที่สั่งให้ agent ทำสิ่งอื่นได้

OWASP จัดเรื่องนี้เป็นความเสี่ยงอันดับหนึ่งของระบบที่ใช้ LLM คือ LLM01 Prompt Injection [1]

ในทางปฏิบัติ ช่องทางที่พบบ่อยคือ

• issue ที่มีข้อความซ่อนคำสั่ง เช่น บอกให้อ่านไฟล์ secrets แล้วใส่ในคอมเมนต์
• ชื่อไฟล์หรือข้อความในโค้ดที่ agent อ่านเข้าไป แล้วตีความเป็นคำสั่ง
• ผลลัพธ์จากเครื่องมือภายนอก เช่น หน้าเว็บที่ agent เปิดอ่าน

วิธีลดความเสี่ยงที่ได้ผลจริงคือ จำกัดสิทธิ์ของ token ให้แคบ ประกาศ permissions: ให้ชัด และห้าม agent อ่านค่าความลับ [2]

อีกข้อที่สำคัญคือ action ที่รันจาก pull request ของคนนอกได้สิทธิ์แบบอ่านอย่างเดียวเป็นค่าเริ่มต้น ซึ่งช่วยได้มาก แต่เจ้าของ repo เปลี่ยนค่านี้ได้ด้วยตัวเลือกที่อนุญาตให้ workflow จาก fork รันด้วยสิทธิ์เขียน และเอกสารความปลอดภัยของ GitHub ไม่ได้รับรองว่าปลอดภัยในทุกกรณี [2][8]

ความเสี่ยงที่สอง คือสัญญาอนุญาต

เครื่องมือในซีรี่ส์นี้มีสัญญาอนุญาตหลายแบบ และบางแบบมีผลกับวิธีที่คุณใช้ในบริษัท

• Qodo Cover เป็น AGPL-3.0 ซึ่งเป็นสัญญาแบบ copyleft ที่เข้มกว่า GPL และมีผลเมื่อให้บริการผ่านเครือข่าย [3][4]
• Actions ส่วนใหญ่ที่ผมใช้เป็น MIT แต่ gitleaks-action มีสถานะ NOASSERTION ต้องเปิดไฟล์เอง [7]
• BMAD ระบุ MIT ใน README แต่ GitHub จัดสถานะ NOASSERTION เช่นกัน [6]

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

แต่ถ้าคุณจะเอาไปประกอบเป็นบริการให้ลูกค้า ต้องให้ฝ่ายกฎหมายอ่านก่อนทุกครั้ง

ความเสี่ยงที่สาม คือความรับผิดชอบเมื่อ agent ทำพัง

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

ถ้า agent ลบข้อมูลหรือใส่บั๊กที่ทำให้ลูกค้าเสียหาย ผู้รับผิดชอบคือคนที่อนุมัติให้ใช้ ไม่ใช่โมเดล

นี่คือเหตุผลที่ผมยืนยันเรื่อง branch protection และการบังคับให้มีคนอนุมัติในตอนที่ 6

ไปป์ไลน์ที่ดีทำให้ความผิดพลาดถูกจับเร็ว แต่ไม่ได้ทำให้ใครพ้นความรับผิดชอบ

สแตกสำหรับทีมคนเดียว

ถ้าคุณทำงานคนเดียวและต้องการเริ่มแบบควบคุมได้

• agent ในเครื่องหนึ่งตัว ที่คุณดูอยู่ตลอด เช่น Claude Code หรือ Codex
• git และ GitHub สำหรับเก็บประวัติ
• pytest หรือ vitest พร้อม coverage ขั้นต่ำใน CI
• ไม่ต้องมี Docker และไม่ต้องมี orchestrator ตั้งแต่ต้น

จุดที่ต้องระวังคืออย่าให้ agent merge เอง เพราะไม่มีคนที่สองช่วยจับ

สแตกสำหรับทีม 3 ถึง 5 คน

• spec-kit สำหรับแปลง issue เป็น spec และ task [5]
• agent หนึ่งตัวเป็นผู้เขียนหลัก และใช้ตัวเดียวกันรีวิวงานคนอื่น ไม่ใช่รีวิวงานตัวเอง
• CI ที่มี lint, typecheck, test, coverage gate และ secret scan
• mutation testing เฉพาะไฟล์ที่ถูกแก้
• คนอนุมัติอย่างน้อยหนึ่งคนที่ไม่ใช่คนเขียน PR

สแตกนี้เพิ่มงานด้านกระบวนการชัดเจน แต่ลดโอกาสที่งานจะไปค้างเพราะไม่มีใครรู้ว่าใครทำอะไร

สแตกสำหรับทีมที่ต้องผ่านการตรวจสอบ

• แยกสภาพแวดล้อมสำหรับ agent ออกจากเครื่องที่เข้าถึงข้อมูลจริง
• เก็บ log ของทุก task ทั้งคำสั่งและผลลัพธ์
• จำกัดสิทธิ์ของ token ตามหลัก least privilege และไม่ให้ agent เห็นค่าความลับ
• กำหนดเพดานค่าใช้จ่ายต่อวันและต่อทีม
• ตรวจสัญญาอนุญาตของทุกเครื่องมือก่อนใช้งานในผลิตภัณฑ์

สแตกนี้หนักกว่าเดิมมาก แต่เป็นราคาที่ต้องจ่ายถ้าคุณต้องอธิบายให้ผู้ตรวจสอบฟังว่าทำไมระบบถึงทำแบบนั้น

สิ่งที่ผมไม่ได้ทดลอง

ผมไม่ได้รันไปป์ไลน์เต็มรูปแบบบน GitHub Actions และไม่ได้ทดลอง agent ในสภาพแวดล้อมแยกที่ได้มาตรฐานองค์กร จึงยังไม่มีตัวเลข token หรือค่าใช้จ่ายจริงจากทีมของผมเองมาเล่า

บทนี้จึงอ้างจากเอกสาร OWASP เอกสาร GitHub และสถานะสัญญาอนุญาตที่เปิดตรวจจริง ไม่ใช่จากการวัดผลในทีมของผม

ถ้าคุณต้องการตัวเลขต้นทุนจริง ผมแนะนำให้วัดจากงานสิบงานแรกของทีมคุณเอง แล้วค่อยตั้งเพดานจากตัวเลขนั้น

เช็กลิสต์ก่อนอนุมัติให้ใช้ในทีม

1. วัดโทเคนต่อ task ได้แล้วหรือยัง
2. มีเพดานค่าใช้จ่ายรายวันหรือยัง
3. agent อ่าน issue จากคนนอกได้หรือไม่ และมีมาตรการอะไร
4. token ที่ใช้มีสิทธิ์แคบที่สุดหรือยัง
5. สัญญาอนุญาตของทุกเครื่องมือผ่านฝ่ายกฎหมายหรือยัง
6. ใครเซ็นรับเมื่อระบบพัง

ถ้าตอบข้อ 6 ไม่ได้ ยังไม่ควรใช้กับระบบที่มีผู้ใช้จริง

บทเรียนที่ผมอยากฝากไว้

เครื่องมือในซีรี่ส์นี้เปลี่ยนได้ตลอด แต่หลักที่ใช้ตัดสินใจไม่เปลี่ยน

วัดก่อนตั้งเพดาน จำกัดสิทธิ์ก่อนให้อำนาจ และกำหนดคนรับผิดชอบก่อนให้ระบบทำงานอัตโนมัติทุกอย่าง

ถ้าคุณกำลังวางแผนใช้ agent กับทีมจริง เล่าให้ผมฟังได้ว่าทีมขนาดไหนและมีข้อจำกัดอะไรบ้าง ผมช่วยดูสแตกให้ได้

ซีรี่ส์นี้จบที่ตอนนี้ แต่เรื่องนี้ยังเดินต่อทุกเดือน เพราะเครื่องมือที่ผมเขียนว่ายังเดินอยู่ วันหนึ่งอาจหยุดเหมือน Qodo Cover

[1] OWASP GenAI Security Project, "LLM01: Prompt Injection", สืบค้น 23 ต.ค. 2026. https://genai.owasp.org/llmrisk/llm01-prompt-injection/

[2] GitHub Docs, "Secure use reference", สืบค้น 23 ต.ค. 2026 (แนวปฏิบัติด้านความปลอดภัยของ GitHub Actions และการจำกัดสิทธิ์ของ GITHUB_TOKEN). https://docs.github.com/en/actions/reference/security/secure-use

[3] Open Source Initiative, "AGPL-3.0 license", สืบค้น 23 ต.ค. 2026 (ลักษณะ copyleft และเงื่อนไขเมื่อให้บริการผ่านเครือข่าย). https://opensource.org/license/agpl-3-0

[4] GitHub, "qodo-ai/qodo-cover" README, สืบค้น 23 ต.ค. 2026 (AGPL-3.0 · ประกาศหยุดดูแล 15 มิ.ย. 2025). https://github.com/qodo-ai/qodo-cover

[5] GitHub, "github/spec-kit" README, สืบค้น 23 ต.ค. 2026 (MIT · 142,492 ดาว · คำสั่ง speckit-specify ถึง speckit-implement). https://github.com/github/spec-kit

[6] GitHub, "bmad-code-org/BMAD-METHOD" README และหน้าสัญญาอนุญาต, สืบค้น 23 ต.ค. 2026 (README ระบุ MIT แต่ GitHub จัดสถานะ NOASSERTION). https://github.com/bmad-code-org/BMAD-METHOD

[7] GitHub, "gitleaks/gitleaks-action", สืบค้น 23 ต.ค. 2026 (666 ดาว · สถานะสัญญาอนุญาต NOASSERTION · รีลีสล่าสุด v3.0.0). https://github.com/gitleaks/gitleaks-action

[8] GitHub Docs, "Managing GitHub Actions settings for a repository", สืบค้น 23 ต.ค. 2026 (ตัวเลือกการรัน workflow จาก fork pull request และข้อยกเว้นเรื่องสิทธิ์เขียน). https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository