คุณเริ่มทำฟีเจอร์หนึ่งใน Claude Code แล้วมันไปติดอยู่กับ type error ที่ยุ่งเหยิง คุณเลยส่ง repo เดียวกันนั้นให้ Codex ซึ่งเก่งกว่ากับงานแนวนี้ Codex แก้มันได้ แต่ตอนนี้มันไม่รู้เลยว่าฟีเจอร์นี้มีไว้ทำไม ไฟล์ไหนที่คุณตกลงกันไว้แล้วว่าจะไม่แตะ หรือคำว่า "เสร็จ" ในบริบทนี้หมายถึงอะไร คุณต้องอธิบายทุกอย่างใหม่หมดจากความจำ สิบนาทีต่อมาคุณสลับกลับ แล้ว Claude Code ก็ลืมไปแล้วเช่นกัน โค้ดเดินหน้าไป แต่ context ไม่ได้ไปด้วย
นี่คือภาษีที่ต้องจ่ายเมื่อคุณใช้ coding agent มากกว่าหนึ่งตัว แต่ละเครื่องมือเก็บความจำของตัวเองในรูปแบบของตัวเองและใน session ของตัวเอง ดังนั้นทันทีที่งานข้ามจาก agent หนึ่งไปยังอีกตัว ทุกอย่างยกเว้น diff ก็ร่วงหล่นหายไป การรักษา context เมื่อสลับระหว่าง coding agent หมายถึงการทำให้ context นั้นอาศัยอยู่ที่ไหนสักแห่งนอกตัว agent ใดตัวหนึ่ง ในรูปแบบที่ตัวถัดไปอ่านได้โดยไม่ต้องให้คุณเล่าเอง
บทความนี้จะพาคุณดูวิธีทำสิ่งนั้น โดยใช้ Sharkly เป็น workflow: เลเยอร์ที่วางอยู่เหนือ coding agent ของคุณ และทำให้ context ความคืบหน้า อุปสรรค ผลลัพธ์ และการรีวิวโดยมนุษย์มองเห็นได้ตั้งแต่คำขอจนถึงการปล่อย คุณมี coding agent อยู่แล้ว ปัญหาตรงนี้คือรอยต่อระหว่างพวกมัน ซึ่งจะยิ่งกว้างขึ้นทุกครั้งที่คุณเพิ่ม agent
ทำไม context ถึงไม่เดินทางระหว่าง agent
Context สำหรับงานเขียนโค้ดอาศัยอยู่ในสามที่ และมีเพียงที่เดียวเท่านั้นที่พกพาได้
ที่แรกคือไฟล์คำสั่ง: CLAUDE.md, AGENTS.md, GEMINI.md กฎถาวร ธรรมเนียมปฏิบัติ คำสั่งสำหรับรันเทสต์ ที่สองคือสถานะของ session: ประวัติการสนทนาที่คุณและ agent เพิ่งคุยกัน สิ่งที่มันลอง สิ่งที่มันตัดออก ที่สามคือ artifact เอง คือ diff บนดิสก์หรือ branch
มีเพียงที่ที่สามเท่านั้นที่เดินทางได้ฟรี agent ตัวอื่นอ่านโค้ดได้ แต่มันอ่านบทสนทนาที่ตัวเองไม่ได้เป็นส่วนหนึ่งไม่ได้ และมันก็จะไม่อ่านไฟล์คำสั่งที่เขียนถึงเครื่องมืออื่น นั่นคือขอบเขตที่ควรพูดให้ชัด: การสลับ agent รักษาโค้ดไว้และทิ้งเหตุผลไป commit รอดชีวิต แต่ "ทำไม" อยู่ใน scrollback buffer ที่ agent ตัวหนึ่งเห็นและอีกตัวจะไม่มีวันได้เห็น
ดังนั้นการรักษา context ข้ามการสลับจึงเป็นสองงานจริง ๆ: ทำให้กฎถาวรอ่านได้โดยทุก agent และทำให้สถานะงานที่กำลังดำเนินอยู่มีตัวตนในรูปแบบอื่นที่ไม่ใช่ความจำของเครื่องมือใดเครื่องมือหนึ่ง สองส่วนถัดไปจะพูดถึงตามลำดับ (ถ้าปัญหาของคุณคือการสูญเสีย context ระหว่างการรันของ agent ตัวเดียวกัน นั่นเป็นปัญหาที่เกี่ยวข้องแต่แยกกัน ครอบคลุมอยู่ใน การรักษา context ข้าม session ของ AI)
ทำให้กฎถาวรเป็นไฟล์เดียวที่ทุก agent อ่าน
เริ่มจากชัยชนะที่ราคาถูกก่อน Claude Code อ่าน CLAUDE.md Codex อ่าน AGENTS.md Gemini CLI อ่าน GEMINI.md งานเดียวกัน แต่สามชื่อไฟล์ ถ้าคุณดูแลแยกกัน มันจะคลาดเคลื่อนจากกัน และ agent ที่คุณสลับไปหาก็จะทำตามกฎที่ล้าสมัยอยู่ ขณะที่คุณเข้าใจว่ามันไม่ได้ทำอย่างนั้น
เขียนกฎครั้งเดียวแล้วชี้ชื่อไฟล์อื่น ๆ มาที่มัน บน macOS หรือ Linux:
# AGENTS.md is the source of truth; the others are aliases
ln -s AGENTS.md CLAUDE.md
ln -s AGENTS.md GEMINI.md
git add AGENTS.md CLAUDE.md GEMINI.md
ตอนนี้ทุก agent ที่เปิด repo จะอ่านธรรมเนียมปฏิบัติเดียวกัน และมีไฟล์เดียวให้อัปเดตเมื่อมันเปลี่ยน เก็บให้สั้นและเป็นข้อเท็จจริง: คำสั่งรันเทสต์ ไดเรกทอรีที่ห้ามแตะ กฎการรีวิว commit ควรมีหน้าตาอย่างไร นี่คือสัญญาร่วมที่แต่ละ agent ได้รับทันทีที่มันเริ่มทำงาน ไม่ว่าคุณจะสลับไปตัวไหน
โหมดความล้มเหลวที่ต้องระวัง: การใส่รายละเอียดเฉพาะงานลงในไฟล์เหล่านี้ ไฟล์คำสั่งมีไว้สำหรับกฎที่เป็นจริงกับทุกงานใน repo "เราใช้ Vitest ไม่ใช่ Jest" อยู่ในนี้ได้ แต่ "ทำ logic การ retry ของ checkout ให้เสร็จแล้วอย่าแตะ auth middleware" ไม่ควรอยู่ เพราะมันเป็นจริงสำหรับงานเดียวในสัปดาห์นี้และผิดในสัปดาห์หน้า การปนสองอย่างเข้าด้วยกันหมายความว่าทุก agent จะอ่านคำสั่งที่ตั้งใจไว้สำหรับงานที่ปล่อยไปแล้ว
พา context ที่กำลังทำงานไปด้วย ไม่ใช่แค่กฎ
ไฟล์กฎพา agent ตัวใหม่มาถึงเส้นสตาร์ท แต่มันไม่ได้พูดอะไรเกี่ยวกับงานที่กำลังดำเนินอยู่: อะไรที่ตัดสินใจไปแล้ว อะไรที่ทำไปครึ่งทาง อะไรที่ยังไม่แน่นอน ความรู้นั้นคือสิ่งที่ระเหยหายไปตอนคุณสลับ เพราะมันอาศัยอยู่ใน session ของ agent ตัวก่อนเท่านั้น
วิธีแก้แบบ manual คือโน้ตส่งงาน ก่อนสลับ agent ให้ตัวปัจจุบันเขียนลงไปว่ามันอยู่ตรงไหน: เป้าหมาย ไฟล์ที่มันแก้ อะไรที่มันตรวจสอบแล้ว และสิ่งเดียวที่มันยังไม่แน่ใจ วางโน้ตนั้นลงใน agent ตัวถัดไปเป็นข้อความแรก วิธีนี้ได้ผล และสำหรับการสลับครั้งเดียวมันก็เพียงพอ รูปแบบนี้คุ้มค่าที่จะทำจนติดเป็นนิสัย รูปร่างของโน้ตส่งงานที่ดีครอบคลุมอยู่ใน เทมเพลตการส่งงานระหว่าง agent
โหมดความล้มเหลวคือโน้ตนั้นไม่ได้อยู่ในที่ที่คงทนถาวร มันเป็นย่อหน้าหนึ่งใน terminal ที่คุณจะปิด หรือข้อความที่คุณพิมพ์ซ้ำทุกครั้ง สลับไปสลับมาสองครั้งคุณก็กำลังดูแลโน้ตส่งงานด้วยมือ ในหัวคุณ ข้ามสามเครื่องมือ Context มีอยู่ แต่คุณกลายเป็นฐานข้อมูลที่มันถูกเก็บไว้ สิ่งนี้ใช้ได้กับงานเดียว แต่ใช้ไม่ได้เมื่อคุณรันหลายงาน ซึ่งเป็นจุดที่วิธี DIY ไปต่อไม่ไหว
จุดที่ setup แบบ DIY ไปต่อไม่ไหว
กฎแบบ symlink บวกโน้ตส่งงานที่วางมือพาคุณไปได้ไกลพอสมควรกับหนึ่ง repo และสอง agent เพิ่ม agent ตัวที่สาม repo ที่สอง หรืองานที่กินเวลาทั้งวัน แล้วเลขคณิตก็พลิกกลับมาสู้คุณ ทุกการสลับคือการ export และ re-import ด้วยมือ ทุกงานมีเส้นด้ายของ "อะไรเสร็จแล้ว" ที่อยู่เฉพาะที่ที่ agent ตัวสุดท้ายทิ้งไว้ ไม่มีอะไรบอกคุณว่า Backend Agent ทำ endpoint ที่ Frontend Agent รออยู่เสร็จแล้ว เพราะ "การบอก" คือข้อความใน terminal ที่ไม่มีใครดูอยู่
ถึงจุดนั้นวิธีแก้ไม่ใช่โน้ตที่ดีขึ้น แต่คือการย้าย context ที่กำลังทำงานออกจาก agent ทั้งหมด ไปยัง Task ที่ใช้ร่วมกัน ซึ่งทุก agent และทุกคนอ่านจากมันและเขียนกลับไปที่มัน Task ใน Sharkly เก็บเป้าหมาย เกณฑ์การยอมรับ diff อุปสรรค และการสนทนาไว้ในบันทึกเดียว การทำงาน อุปสรรค ผลลัพธ์ และการติดตามผลกลับคืนสู่ไทม์ไลน์ของ Task นั้น ดังนั้นการสลับ agent จึงไม่ใช่การ export อีกต่อไป คุณเพียงมอบหมาย Task ใหม่ให้ agent ตัวถัดไปอ่านบันทึกเดียวกับที่ตัวก่อนเขียนไว้
นี่ก็เป็นจุดที่การแบ่งงานระหว่างมนุษย์กับ agent ชัดเจนขึ้น Agent ค้นคว้า ลงมือทำ ทดสอบ และรายงานกลับไปที่ Task คนกำหนดทิศทาง ให้อำนาจ และยอมรับผลลัพธ์ ระบบอัตโนมัติหยุดตรงจุดที่ต้องใช้ดุลพินิจของทีม และบันทึกที่ผู้ทำงานคนถัดไปอ่านคือบันทึกเดียวกับที่ reviewer อ่าน สิ่งนี้ทำงานได้ก็เพราะ context ไม่ได้ติดอยู่ใน session อีกต่อไป
นี่คือคู่การตัดสินใจแบบตรงไปตรงมา ถ้าคุณรัน agent ตัวเดียวใน terminal เดียวบน repo เดียว คุณไม่จำเป็นต้องใช้สิ่งเหล่านี้เลย เพราะ context ไม่เคยออกไปไหน จึงไม่มีอะไรต้องรักษา ให้หันมาใช้ Task ที่ใช้ร่วมกันทันทีที่ context ต้องอยู่รอดข้ามการสลับ ไม่ว่าการสลับนั้นจะเป็น agent-ถึง-agent, agent-ถึง-มนุษย์ หรือแค่คุณในเช้าวันพรุ่งนี้ ถ้าคุณอยากใช้ coding agent หลายตัวต่อไปแทนที่จะผูกติดกับ ecosystem เดียว ความสามารถในการพกพานั่นแหละคือประเด็น: workflow ของคุณอยู่รอดไม่ว่าคุณจะเลือก agent ตัวไหนต่อไป เพราะ context ไม่เคยถูกเก็บไว้ในตัวมันเลย นั่นก็เป็น setup ที่ทำให้คุณ รัน Claude Code และ Codex ด้วยกันบน codebase เดียว ได้โดยที่ไม่มีตัวไหนตาบอดตอนส่งงาน และมันเข้ากันได้อย่างเป็นธรรมชาติกับ worktree แบบ one checkout ต่อหนึ่งงาน เพื่อไม่ให้ agent ที่ทำงานขนานกันชนกัน
เช็กลิสต์ที่คุณทำได้วันนี้
ไล่ทำตามลำดับนี้ สามข้อแรกไม่มีค่าใช้จ่าย ข้อที่สี่คือสิ่งที่คุณจะขยับไปทำเมื่อสามข้อแรกตามไม่ทันแล้ว
- รวมไฟล์กฎให้เป็นหนึ่งเดียว Symlink
CLAUDE.md,AGENTS.mdและGEMINI.mdไปที่แหล่งเดียว เก็บไว้แค่ธรรมเนียมปฏิบัติระดับ repo เท่านั้น ไม่มีรายละเอียดเฉพาะงาน - เขียนโน้ตส่งงานก่อนทุกการสลับ เป้าหมาย ไฟล์ที่แก้ อะไรที่ตรวจสอบแล้ว คำถามที่เปิดอยู่ Agent ตัวปัจจุบันร่างให้ได้ แล้วคุณวางมันลงในตัวถัดไป
- ตัดสินใจสลับจากงาน ไม่ใช่จากความเคยชิน จับคู่ agent กับงานที่อยู่ตรงหน้าคุณ โดยใช้คู่มือการจัดเส้นทาง แทนที่จะใช้ค่าเริ่มต้นคือ terminal ตัวไหนที่เปิดอยู่
- ย้าย context ออกจาก agent เมื่อโน้ตเริ่มตามไม่ทัน เมื่อคุณต้อง juggle agent หรือ repo มากกว่าสองสามตัว ให้วางเป้าหมาย สถานะ และการรีวิวไว้บน Task ที่ใช้ร่วมกัน เพื่อให้การสลับเป็นการมอบหมายงานใหม่ ไม่ใช่การอธิบายซ้ำ
ถ้าคุณใช้ agent หลายตัวอยู่แล้วและต้องเล่า context เดิมซ้ำทุกครั้งที่สลับ นั่นคือปัญหาที่ Sharkly ถูกสร้างขึ้นมาเพื่อแก้: ที่เดียวที่งาน ความคืบหน้า และผลลัพธ์ของแต่ละ agent ยังคงมองเห็นได้ เพื่อให้ context มีอายุยืนกว่าการสลับ
