ให้ OpenCode แก้บั๊กไป โดยคุณยังใช้ working tree เดิมได้

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

วันที่ 6 พฤศจิกายน OpenCode 2.2.6 เพิ่มตัวเลือก worktree สำหรับการเรียกผ่านสคริปต์บรรทัดคำสั่ง OpenCode เป็นเอเจนต์เขียนโค้ดโอเพนซอร์ส มีเทอร์มินัลโต้ตอบและคำสั่งแยกเพื่อรันพรอมป์จากสคริปต์ ตัวเลือกใหม่นี้ให้สคริปต์เริ่มใน Git worktree แยก ตั้งชื่อได้ และปล่อยไดเรกทอรีเดิมให้ใช้งานต่อ รุ่นนี้เพิ่มการแชร์แบบเลือกเปิดสำหรับการเชื่อมต่อ Model Context Protocol (MCP) ที่มีการตั้งค่าตรงกัน ก่อนรันจึงควรถามสองเรื่อง เอเจนต์เปลี่ยนไฟล์ไหนได้ และใช้บริการอะไรได้บ้าง? รุ่น OpenCode v2.2.6 · เอกสาร CLI ของ OpenCode

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

ภาพหน้าจอจากโครงการ OpenCode แสดงแพตช์และเซสชัน สื่อแบรนด์ในแท็กรุ่น แสดงหน้าตาเทอร์มินัล มี ข้อความสัญญาอนุญาต MIT กำกับภาพ Telli.sh ปรับขนาดและเพิ่มขอบ

โฟลเดอร์แยกช่วยให้ตรวจ diff ได้อย่างมั่นใจ

Git worktree ให้แต่ละงานมีไฟล์ทำงานและดัชนีแยกกัน ภาพประกอบโดย Telli.sh

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

รุ่นวันที่ 6 พฤศจิกายนระบุสามวิธี ใช้ opencode run -w หรือ opencode run --worktree เพื่อเปิด worktree ใหม่ และใช้ --worktree=<name> เมื่อต้องการตั้งชื่อ ตัวเลือกนี้ใช้ร่วมกับ --continue หรือ --session ไม่ได้ การรันใหม่ต้องเริ่มด้วยบริบทใหม่ ถ้ารายงานบั๊กมีบทสนทนายาวอยู่แล้ว ให้ยกขั้นตอนทำซ้ำและผลที่คาดไว้เข้าไปในพรอมป์ใหม่ รุ่น OpenCode v2.2.6 · การทำงานและตัวอย่าง worktree

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

ลองแก้เรื่องเล็กก่อนมอบงานใหญ่

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

1. บันทึกจุดเริ่มต้น ในไดเรกทอรีเดิมใช้ git status --short และ git rev-parse HEAD เก็บผลกับรายงานบั๊ก ถ้ามีผลฐานที่ผ่านแล้ว ให้จดวิธีทำซ้ำ ใช้ opencode --version ตรวจว่าเป็นรุ่นที่มีแฟล็กใหม่ รุ่น OpenCode v2.2.6

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

   Shellรันใน เทอร์มินัล

   opencode run --worktree=date-parser "Reproduce the leap-day parsing bug in the date parser tests. Fix the narrow cause, run the targeted tests, and leave the changes uncommitted for review."
   

3. หาไดเรกทอรีใหม่ก่อนดูผล รัน git worktree list จากที่เก็บเดิมแล้วใช้พาธที่แสดง ในที่ใหม่ตรวจ git status --short, git diff และ git diff --cached คำสั่งสุดท้ายมีประโยชน์ถ้าเอเจนต์เพิ่มไฟล์เข้า staging ตรวจไฟล์ที่ยังไม่ถูกติดตามแยกกัน รันการทดสอบซ้ำเองจากไดเรกทอรีเอเจนต์ และดูว่าครอบคลุมวันที่ 29 กุมภาพันธ์ทั้งปีอธิกสุรทินและปีที่วันนั้นใช้ไม่ได้ เอกสาร Git worktree

4. นำกลับมาเฉพาะงานที่ตรวจแล้ว แยกการแก้ไว้จนกว่าจะนำคอมมิตหรือแพตช์ที่ตรวจแล้วลงสาขาเป้าหมายได้ ตรวจสถานะไดเรกทอรีเดิมอีกครั้ง เก็บ worktree เอเจนต์ไว้จนบันทึกสิ่งที่ต้องใช้และยืนยันว่าไม่มีการแก้ค้างที่อยากเก็บ รายการ worktree ของ Git ช่วยระบุว่าไดเรกทอรีไหนเป็นของงานใด เอกสาร Git worktree

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

กำหนดว่าใครทำอะไรได้นอกที่เก็บ

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

แยกตำแหน่งที่ไฟล์เปลี่ยนออกจากการอนุมัติเครื่องมือและสิทธิ์ของรันไทม์ ภาพประกอบโดย Telli.sh

เอกสารสิทธิ์ V2 ของ OpenCode ระบุกฎเรียงลำดับสำหรับแต่ละการกระทำ ผลได้แก่ allow, ask และ deny โดยกฎที่ตรงตัวสุดท้ายมีผล ตัวอย่างทางการถามก่อนคำสั่ง shell แล้วอนุญาตคำสั่งตรวจทั่วไปและห้าม push ถ้าจะรันโดยไม่มีผู้อนุมัติ ให้ลองพฤติกรรมของ ask ในขั้นตอนนั้นก่อนตั้งเป็นงานประจำ เขียนข้อห้ามให้ชัดในการตั้งค่าและใช้ข้อมูลรับรองอายุสั้นที่จำกัดเฉพาะบริการจำเป็น เอกสารสิทธิ์ OpenCode

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

แชร์การเชื่อมต่อเมื่อโครงการมีขอบเขตร่วมกันอยู่แล้ว

MCP ให้เอเจนต์ใช้เครื่องมือจากโปรแกรมอื่น เช่น ระบบค้นเอกสารหรือติดตามปัญหา รุ่นวันที่ 6 พฤศจิกายนใช้ pool: true ให้ไดเรกทอรีที่อยู่ใต้เซิร์ฟเวอร์ OpenCode เดียวใช้การเชื่อมต่อซ้ำเมื่อการตั้งค่าที่เกี่ยวข้องตรงกัน เอกสาร V2 ระบุว่าใช้กับโปรโตคอลฉบับ 2026-07-28 หากเซิร์ฟเวอร์เลือกฉบับเก่ากว่า การเชื่อมต่อยังแยกกัน การตรงกันมากกว่าชี้สองโครงการไปที่เดียวกัน การตั้งค่าระยะไกลและบัญชีที่ยืนยันแล้วต้องตรง ส่วนเซิร์ฟเวอร์ในเครื่องต้องตรงทั้งคำสั่ง สภาพแวดล้อม และไดเรกทอรีทำงาน รุ่น OpenCode v2.2.6 · เอกสารการแชร์ MCP ของ OpenCode

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

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

การรันจากสคริปต์ยังต้องมีจุดจบ

OpenCode 2.2.6 เพิ่ม --archived ให้เซสชันจากสคริปต์หรือ CI เริ่มในสถานะเก็บถาวรและไม่ขึ้นในรายการปกติ นี่เปลี่ยนวิธีแสดงเซสชัน เก็บผลงาน พาธ worktree และผลทดสอบไว้ให้คนตรวจพบ ใช้แฟล็กเมื่อมีทางหาแพตช์ได้แน่นอนแม้รายการปกติว่าง บันทึกวันที่ 6 พฤศจิกายนระบุว่า --continue จะข้ามเซสชันเก็บถาวร รุ่น OpenCode v2.2.6

รุ่นนี้ปรับวงจรการรันสคริปต์ด้วย โดยรอคำสั่งเบื้องหลัง เอเจนต์ย่อย และงานภาพที่พรอมป์เริ่มก่อนปิด ตามบันทึก การรอไม่มีขีดจำกัดเวลาภายใน เซิร์ฟเวอร์พัฒนาหรือตัวเฝ้าไฟล์จึงทำให้รันค้างได้ สำหรับการทดสอบอัตโนมัติ ใช้คำสั่งที่จบเมื่อตรวจเสร็จและกำหนดเวลาสูงสุดให้ขั้น CI ที่ครอบอยู่ แยกการยกเลิก การทดสอบไม่ผ่าน และการรายงานสำเร็จของเอเจนต์ หากหมดเวลา ตรวจสภาพการแก้จริงก่อนรันใหม่หรือนำเข้า รุ่น OpenCode v2.2.6

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

เช็กเอาต์สะอาดทำให้เห็นความรับผิดชอบชัด

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

แหล่งข้อมูล

• ภาพหน้าจอเทอร์มินัลทางการของ OpenCode และ สัญญาอนุญาตที่เก็บ

• OpenCode v2.2.6 วันที่ 6 พฤศจิกายน 2026

• เอกสาร CLI ของ OpenCode

• สิทธิ์ OpenCode V2

• การแชร์การเชื่อมต่อ MCP ใน OpenCode

• คู่มือ Git worktree

---

หากต้องการเก็บการตัดสินใจและการทดลองเบื้องหลังงานไว้ให้ค้นได้ สร้างบัญชี Telli.sh.