OpenCode 2.0 คืออะไร? ทำไม AI เขียนโค้ดตัวนี้ถึงรื้อสถาปัตยกรรมทั้งตัว

โดย Nokka (นก-กา) | 17 ตุลาคม 2026

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

ลองนับดูว่าวันหนึ่งคุณเปิดช่องทางคุยกับ AI เขียนโค้ดกี่แบบ

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

ความหงุดหงิดนี้ไม่มีชื่อเรียก แต่ทุกคนที่ใช้ agent เขียนโค้ดเจอ

ฝั่งที่ปิดโค้ดอย่าง Claude Code กับ Codex แก้ด้วยการย้ายงานไปวิ่งบนคลาวด์ของตัวเองมาตั้งแต่แรก ส่วนฝั่งโอเพนซอร์สยังไม่มีใครแตะ กระทั่ง OpenCode 2.0 เปิดตัวกลางเดือนตุลาคม 2026 แล้วประกาศทิ้งโมเดล "หนึ่งหน้าจอ หนึ่งเซสชัน" ไปเลยในประกาศทางการ [1]

ภาพประกอบ: หลายหน้าจอที่ต่างกันเชื่อมเข้าหากระบวนการกลางตัวเดียว ซึ่งเป็นหัวใจของการรื้อสถาปัตยกรรมในรุ่น 2.0

ปัญหาที่ซ่อนอยู่หลังทุกหน้าจอ

OpenCode เลือกใช้สถาปัตยกรรมแบบไคลเอนต์กับเซิร์ฟเวอร์มาตั้งแต่ต้น [1]

แต่คนใช้งานระดับลึกเท่านั้นที่ได้สัมผัสความสามารถนั้นจริง เพราะเซิร์ฟเวอร์ไม่ทำงานเองโดยค่าเริ่มต้น [1] คนทั่วไปจึงยังเจอปัญหาเดิม คือแต่ละหน้าจอเริ่มนับหนึ่งใหม่เสมอ

ความเปลี่ยนแปลงของรุ่น 2.0 จึงไม่ใช่การเพิ่มฟีเจอร์ แต่เป็นการย้ายจุดศูนย์ถ่วงของทั้งระบบ จากที่เคยมีหน้าจอเป็นศูนย์กลาง มาเป็นมีกระบวนการทำงานเบื้องหลังเป็นศูนย์กลาง

เทียบกับคู่แข่งที่ทำแบบนี้มาก่อน

Claude Code กับ Codex ให้ความต่อเนื่องข้ามหน้าจอได้ผ่านคลาวด์ของเจ้าของ [3] ฝั่งโอเพนซอร์สยังไม่มีใครทำได้จริง เพราะต้องมีกระบวนการกลางที่คอยรับงานอยู่ตลอด

บทวิเคราะห์ของ byteiota ระบุว่า OpenCode 2.0 เป็นตัวแรกในฝั่งโอเพนซอร์สที่ปิดช่องว่างนี้ได้ [3] ข้อได้เปรียบเหนือคู่แข่งอยู่ที่ข้อมูลยังอยู่บนเครื่องคุณ ไม่ต้องส่งขึ้นคลาวด์ของใคร

บริการพื้นหลังตัวเดียวที่ทุกหน้าจอคุยด้วย

ในรุ่น 2.0 เซิร์ฟเวอร์จะรันตัวเองเป็นโปรเซสพื้นหลังตัวเดียวบนเครื่องคุณ ไม่ต้องไปเปิดเอง [1]

เมื่อคุณเปิดเทอร์มินัล เว็บ หรือแอปเดสก์ท็อป ทั้งสามอย่างจะคุยกับโปรเซสกลางตัวเดียวกันทั้งหมด [1] งานที่ค้างอยู่จึงไม่หายไปตอนสลับหน้าจอ

รายละเอียดปลีกย่อยที่ทีมงานเล่าไว้สำคัญกว่าตัวฟีเจอร์เสียอีก สคริปต์ที่เขียนด้วยไลบรารี @opencode/client จะค้นหาบริการในเครื่องเจอเองโดยไม่ต้องระบุที่อยู่ [1]

มันมีประโยชน์ตรงกับงานที่รันตามเวลาอย่างชัดเจน เพราะสคริปต์ไม่ต้องรู้ล่วงหน้าว่าเซิร์ฟเวอร์เปิดอยู่พอร์ตไหน ส่วนใครที่อยากให้เครื่องอื่นเชื่อมเข้ามาใช้ ก็สั่ง /pair ได้

จุดนี้ทำให้ OpenCode ยืนอยู่ในตำแหน่งที่ก่อนหน้านี้มีเพียงเครื่องมือปิดโค้ดเท่านั้นที่ทำได้ [3]

Code Mode ที่เปลี่ยนวิธีนับรอบของ agent

แนวคิดที่อยู่เบื้องหลัง

หัวใจจริงของรุ่นนี้อยู่ที่กลไกที่ทีมงานเรียกว่า Code Mode [1]

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

ทีมงานสร้างตัวแปลภาษา JavaScript ขนาดเล็กขึ้นมาเองในแพ็กเกจ @opencode/codemode โดยไม่พึ่ง Node.js หรือ embedding อย่าง QuickJS [1]

มันรับ MCP server หรือปลายทาง OpenAPI เข้ามา แล้วแปลงเป็นฟังก์ชันที่ agent เรียกจากในสคริปต์ได้ [1]

ตัวอย่างที่เห็นภาพที่สุด

ตัวอย่างที่ทีมงานยกมาคือการปิดงานระหว่าง GitHub กับ Linear ในรอบเดียว งานที่เคยต้องยิงเครื่องมือหลายครั้งกลายเป็นแบบนี้

const { issues } = await tools.github.list_issues({
  owner: "anomalyco",
  repo: "opencode",
  labels: ["bug"],
  state: "OPEN",
});
const filed = await Promise.all(
  issues.map(({ title }) => tools.linear.save_issue({ team: "OC", title }))
);
return filed.map((issue) => issue.identifier);

อ่านโค้ดนี้แล้วจะเห็นภาพทันที โมเดลดึงรายการบั๊ก กรองแล้ววนสร้างงานใน Linear ครบในรอบเดียว และคืนกลับมาแค่รหัสงาน ไม่ใช่ผลลัพธ์ดิบทั้งหมด [1]

สิ่งที่ได้กลับเข้าไปในบริบทจึงมีขนาดเล็กกว่าที่เคยเป็นหลายเท่า

ที่น่าสนใจคือ MCP ย่อมาจาก Model Context Protocol เป็นมาตรฐานกลางที่ทำให้ agent ต่อกับเครื่องมือภายนอกได้ [9]

ทีมงานตัดสินใจเปิดโหมดนี้ให้ MCP server ทุกตัวโดยอัตโนมัติในรุ่น 2.0 [1] แปลว่าต่อเครื่องมือเพิ่มอีกไม่กี่ร้อยตัวก็ไม่ทำให้บริบทบวมเท่าเดิม ซึ่งเป็นปัญหาที่คนใช้งาน MCP หนัก ๆ เจอกันมานาน

ตัวเลข 69% ที่ต้องอ่านให้ระวัง

มีตัวเลขหนึ่งที่ถูกพูดถึงมากในโพสต์วิเคราะห์หลังวันเปิดตัว

เคสที่ถูกอ้างถึงมากที่สุดวัดได้ว่าบริบทลดจาก 177,444 โทเคนเหลือ 54,181 โทเคน หรือราว 69% โดยมีเครื่องมือตัวหนึ่งที่ช่างพูดเป็นต้นเหตุหลักของความบวม

ผมต้องกำกับไว้ให้ชัดว่า ตัวเลขนี้มาจากบทวิเคราะห์ของ byteiota ไม่ใช่ประกาศทางการของ OpenCode [3]

ในประกาศต้นทางระบุเพียงกลไก ไม่ได้ให้ตัวเลขเปรียบเทียบไว้ [1] และในกระทู้ Hacker News ที่มีผู้แสดงความเห็นกว่า 385 คน ก็ไม่มีใครอ้างตัวเลขชุดนี้ [2]

ตัวเลขแบบนี้มีเจ้าของเป็นบทวิเคราะห์นั้น ไม่ใช่คุณสมบัติของผลิตภัณฑ์ การอ้างต่อ ๆ กันโดยไม่บอกที่มาจะทำให้คนอ่านเข้าใจผิดว่าเป็นผลวัดจากทีมผู้พัฒนาเอง

ถ้าคุณจะนำไปอ้างในที่ทำงาน ผมแนะนำให้บอกที่มาทุกครั้ง

งานเบื้องหลังและปลั๊กอินที่รื้อใหม่

อีกระบบที่ทีมงานลงทุนหนักคือการทำงานเบื้องหลัง

ตอนนี้ agent หลักสามารถส่งงานต่อให้ agent ลูกทำขนานไปได้โดยไม่ต้องหยุดรอ และเลือกได้ด้วยว่าจะให้ใช้คนละโมเดลกัน [1]

คำสั่งพื้น ๆ อย่างการสั่งให้ agent ลูกไปตรวจโค้ดระหว่างที่เราคุยงานอื่นต่อ จึงกลายเป็นเรื่องปกติ

ฝั่งเชลล์ก็เช่นกัน คำสั่งที่ใช้เวลานานรันแบบไม่บล็อกได้ [1]

ถ้าเผลอรันงานหนักในฉากหน้าอยู่นานเกินไป ก็มีปุ่มลัดให้ย้ายไปไว้เบื้องหลังโดยไม่ต้องเสียงานที่ทำค้างไว้ [1]

ส่วนระบบปลั๊กอิน ทีมงานยอมรับตรง ๆ ว่ารุ่น 1.0 ทำไว้แล้วทิ้งไม่ได้ดูแล [1] ทางแก้ของพวกเขาจึงน่าสนใจ

ทางแก้ที่พวกเขาเลือก คือบังคับตัวเองให้สร้างฟีเจอร์ของรุ่น 2.0 แทบทั้งหมดเป็นปลั๊กอินภายใน จนมีมากกว่า 80 ตัว [1] วิธีนี้ทำให้ API ของปลั๊กอินถูกใช้งานจริงทุกวัน จึงไม่มีทางเน่าทิ้งเหมือนเดิม

ถ้าใครอยากเขียนปลั๊กอินเอง เอกสารสำหรับนักพัฒนา อยู่ที่ [7]

ที่ผมประทับใจที่สุดคือระบบโหลดใหม่ทันที ทีมงานเล่าว่า OpenCode เขียนปลั๊กอินให้ตัวเองกลางเซสชันแล้วใช้งานได้เลย [1]

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

ราคาที่ต้องจ่าย และรอยแผลที่ประกาศไม่พูดถึง

สิ่งที่ทีมงานเขียนไว้เอง

การรื้อครั้งนี้ไม่ฟรี และทีมงานเขียนไว้ตรงไปตรงมาในหัวข้อการอัปเกรด

ปลั๊กอินจากรุ่น 1.0 ใช้กับรุ่น 2.0 ไม่ได้ API ฝั่งเซิร์ฟเวอร์เปลี่ยนใหม่ทั้งหมด และไฟล์ตั้งค่าเดิมถูกย้ายที่ [1]

การอัปเกรดต้องสั่ง opencode upgrade --major และควรชี้ให้ตัว agent อ่านเอกสารการย้ายระบบช่วย [1]

แต่รอยแผลที่หนักกว่านั้นไม่ได้อยู่ในประกาศ และต้องไปอ่านจากกระทู้ของผู้ใช้งานจริง

แซนด์บ็อกซ์ที่ผู้ใช้คิดว่ายังกันอยู่

ในสายตาผม กรณีศึกษาที่ตรงประเด็นที่สุดมาจากผู้ใช้รายหนึ่งบน Hacker News ชื่อบัญชี kingds (ผมระบุชื่อบัญชีเพื่อให้คุณตรวจย้อนได้)

เขาเล่าว่าหลังอัปเกรด แซนด์บ็อกซ์ที่เคยครอบโปรเซสหน้าจอไว้กลายเป็นของไร้ความหมายไปเงียบ ๆ

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

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

ผู้ใช้อีกรายในกระทู้เดียวกัน ชื่อบัญชี verdverm นับได้อย่างน้อยสามจุดที่ถดถอยด้านความปลอดภัยในรุ่น 2.0 ช่วงแรก [2]

หนึ่ง การโหลดไฟล์ตั้งค่าที่หลุดการรองรับระดับระบบไปแล้วถูกนำกลับมาแบบไม่ถูกต้อง ซึ่งเจ้าของรายงานเขียนกำกับเองว่าได้รับการแก้แล้ว ส่วนที่เหลือเป็นปัญหาย่อยในระดับการตั้งค่าของผู้ใช้ (user space)

สอง การโหลดปลั๊กอินใหม่ทันทีที่ทำให้ agent แก้พฤติกรรมตัวเองได้โดยมีผลทันที

สาม เรื่องแซนด์บ็อกซ์ที่ผู้ใช้รายแรกเล่าไว้ [2]

verdverm ยังตั้งข้อสังเกตที่เจ็บแต่ตรงว่า ทีมงานอาจเชื่อคำของ AI ว่าของเดิมดีพอแล้ว โดยขาดการคิดเชิงวิพากษ์ของคนมากพอ [2]

verdverm ยังเปิดกระทู้แยกเรื่องการโหลดไฟล์ตั้งค่าของตัวเองไว้ และตามด้วยissue ฝั่งโปรเจกต์อื่นที่อ้างอิงถึงกัน [5][6]

ในกระทู้เดียวกันยังมีจุดที่นำไปใช้ได้จริงอีกสองเรื่อง ผู้ใช้รายหนึ่งให้วิธีปฏิบัติว่าต้องรันด้วยธง --standalone มิฉะนั้นตัวที่ถูกแซนด์บ็อกซ์จะเป็นเฉพาะไคลเอนต์ ไม่รวมเซิร์ฟเวอร์ และคนเดียวกันยังรายงานจุดถดถอยข้อที่สี่ของชุดเดียวกัน คือเครื่องมือที่เพิ่มโดยปลั๊กอินไม่เคารพการตั้งค่าสิทธิ [2]

สถานะโปรเจกต์ตอนนี้

ผมตรวจตัวเลขสาธารณะของโปรเจกต์ ณ วันที่เขียนแล้วพบว่ายังแข็งแรงดี

สถิติจาก GitHub APIระบุ 214,567 ดาว 28,803 ฟอร์ก และมี issue เปิดค้าง 4,530 รายการ ภายใต้สัญญาอนุญาต MIT [4]

ใครอยากดูissue trackerของจริงก็เข้าไปดูได้ [10]

เรื่องสุดท้ายเป็นประสบการณ์ตรงที่หลายคนน่าจะเจอเหมือนกัน มีผู้ใช้รายงานว่าตัวติดตั้งค้างอยู่ที่ 10% นานหกนาที [2]

อ่านแล้วผมนึกถึงความรู้สึกตอนนั่งรออะไรก็ไม่รู้ ไม่รู้ว่าแฮงก์หรือแค่ช้า

เรื่องนี้แก้ได้ไม่ยากด้วยข้อความบอกความคืบหน้าที่ดีขึ้น

แล้วคนทำงานไทยควรทำอะไร

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

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

เหตุผลคือช่วงเปลี่ยนผ่านแบบนี้มักมีของที่ต้องเก็บตกอยู่ ส่วนเอกสารหลักของ OpenCodeก็มีคู่มือสำหรับคนที่เพิ่งเริ่มอยู่ด้วย [8]

แต่ถ้าคุณต้องการความต่อเนื่องของบริบทข้ามหน้าจอ การรื้อครั้งนี้ก็เป็นเหตุผลที่หนักแน่นพอจะยอมเจ็บกับรอยแผลช่วงเปลี่ยนผ่าน

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

แล้วคุณล่ะ เคยเจอเคสที่อัปเกรดเครื่องมือแล้วความปลอดภัยเดิมหายไปเงียบ ๆ แบบนี้ไหมครับ เล่าให้ผมฟังได้เลย

ขอออกตัวไว้ตรงนี้ว่าบทความนี้เรียบเรียงจากประกาศต้นทาง เอกสารของโปรเจกต์ และกระทู้ผู้ใช้จริง ผมยังไม่ได้ติดตั้ง OpenCode 2.0 มาทดสอบเอง

เอกสารอ้างอิง

[1] Anomaly, "OpenCode 2.0", anoma.ly/notes/opencode-2-0, 2026. https://anoma.ly/notes/opencode-2-0/
[2] Hacker News, "OpenCode 2.0" (883 คะแนน, 385 ความเห็น), 2026. https://news.ycombinator.com/item?id=50094994
[3] byteiota, "OpenCode 2.0: Shared Service Architecture, Code Mode, and What Breaks", 2026. https://byteiota.com/opencode-2-shared-service
[4] GitHub API, "anomalyco/opencode: repository statistics" (วัด 17 ตุลาคม 2026 เวลา 10:31 UTC), 2026. https://api.github.com/repos/anomalyco/opencode
[5] Hacker News, "กระทู้เรื่องการโหลดไฟล์ตั้งค่าและช่องโหว่ความปลอดภัยของ OpenCode 2.0", 2026. https://news.ycombinator.com/item?id=50075319
[6] GitHub, "earendil-works/pi: issue #10895 security feature request", 2026. https://github.com/earendil-works/pi/issues/10895
[7] OpenCode Docs, "Plugins", 2026. https://opencode.ai/docs/plugins
[8] OpenCode Docs, "Documentation", 2026. https://opencode.ai/docs/
[9] Model Context Protocol, "Introduction", 2026. https://modelcontextprotocol.io/
[10] GitHub, "anomalyco/opencode issues", 2026. https://github.com/anomalyco/opencode/issues