เมื่อการส่งต่องานระหว่างโมเดลทำกระบวนการคิดสูญหาย: สิ่งที่ Claude Sonnet 5.5 เข้ามาพลิกโฉมการทำงานแบบ Multi-Agent

ในทีมที่ใช้ coding agent หลายตัว การส่งต่องาน (Task) จากตัวหนึ่งไปยังอีกตัวหนึ่งเกิดขึ้นอยู่ตลอดเวลา บางครั้ง Sonnet ทำหน้าที่เขียนโค้ด ส่วน Opus คอยรีวิว หรือเมื่อ Claude Code Agent เกิดอาการค้าง งานก็จะถูกส่งต่อไปให้ Codex Agent จัดการต่อ แต่ Claude Sonnet 5.5 ที่เปิดตัวเมื่อวันที่ 28 กันยายน ได้ระบุเงื่อนไขไว้อย่างชัดเจนในสิ่งที่เป็นจริงอยู่แล้วส่วนหนึ่ง นั่นคือ กระบวนการคิด (reasoning) ของโมเดลไม่ได้ถูกส่งต่อตามผลงานไปด้วย หน้าเอกสาร what’s new in Sonnet 5.5 ของ Anthropic ระบุว่า thinking block ทุกบล็อก “จะบันทึกไว้ว่าโมเดลใดเป็นผู้สร้าง” และจะไม่มีโมเดลอื่นใดสามารถอ่านบล็อกของ Sonnet 5.5 ได้

ปัญหาสำคัญคือกระบวนการนี้เกิดขึ้นอย่างเงียบเชียบ เมื่อคำขอ (request) ส่งบล็อกที่โมเดลอ่านไม่ออกติดไปด้วย API จะตัดบล็อกนั้นทิ้งไปก่อนที่โมเดลจะได้เห็น คำขอนั้นจะยังคงทำงานสำเร็จ ไม่มีการคิดค่าบริการสำหรับบล็อกที่ถูกตัดทิ้ง และร่องรอยเดียวที่หลงเหลือไว้คือฟิลด์ input_transformations ซึ่งจะปรากฏขึ้นก็ต่อเมื่อคุณส่งเบต้าเฮดเดอร์ thinking-binding-controls-2026-08-01 เท่านั้น ผลลัพธ์คือ Reviewer Agent จะเห็นเฉพาะโค้ดที่มีการเปลี่ยนแปลง (diff) โดยไม่รู้เหตุผลเบื้องหลังเลย ไม่มีการแจ้งเตือนข้อผิดพลาดใด ๆ ทำให้ผลการรีวิวดูเหมือนมีความเข้าใจรอบด้าน ทั้งที่ความจริงไม่ได้เป็นเช่นนั้น

สรุปใจความสำคัญ (TL;DR)

สำหรับการส่งต่อบริบทระหว่างโมเดลของเอเจนต์ มีกฎเหล็กเพียงข้อเดียวคือ บริบทที่จะรอดผ่านการส่งต่อไปได้ มีเพียงสิ่งที่ถูกบันทึกไว้ใน Task เท่านั้น เพราะ thinking block ถูกผูกไว้กับโมเดลที่สร้างขึ้น กับบทสนทนานั้น ๆ โดยเฉพาะ และสำหรับ Sonnet 5.5 ยังถูกผูกไว้กับบัญชีผู้ใช้อีกด้วย ดังนั้น ควรกำหนดให้ Agent ทุกตัวปิดท้ายการทำงานด้วยคอมเมนต์ส่งต่องานเสมอ ซึ่งควรระบุทั้งการตัดสินใจและเหตุผล ข้อสันนิษฐาน สิ่งที่ลองแล้วไม่ได้ผล ประเด็นที่ยังค้างคา ไฟล์ที่มีการแก้ไข และคำสั่งตรวจสอบที่รันไปแล้ว หากคุณพัฒนาฮาร์เนส (harness) ขึ้นมาเอง ควรจัดการประวัติการทำงานแบบ append-only เสมอ

Thinking Block ถูกผูกไว้ 3 ระดับ

Thinking block คือกระบวนการคิดและใช้เหตุผลที่โมเดลสร้างขึ้นในแต่ละรอบ (turn) โดยส่งกลับมาพร้อมลายเซ็นกำกับที่ API จะตรวจสอบความถูกต้องก่อนที่คำขอถัดไปจะนำไปใช้ได้ หน้าเอกสาร preserved thinking ได้อธิบายการผูกข้อมูล (binding) ไว้ 3 ระดับ ซึ่งตรงกับลักษณะการส่งต่องานที่ทีมของคุณใช้อยู่เป็นประจำ

โมเดล (Model) Sonnet 5.5 สามารถอ่านบล็อกความคิดจาก Sonnet 5, Opus 4.8, Haiku 4.5 และโมเดลรุ่นก่อนหน้าได้ แต่ไม่สามารถอ่านบล็อกของ Opus 5, Opus 5.5, Fable หรือ Mythos ได้ ทิศทางการส่งต่อมีความสำคัญมาก จากบันทึกของ Anthropic เรื่องการสลับโมเดลระหว่างบทสนทนา ระบุว่า หากบทสนทนาย้ายจาก Sonnet 5 มายัง Sonnet 5.5 กระบวนการคิดจะยังคงอยู่ แต่หากย้ายจาก Sonnet 5.5 ไปยังโมเดลอื่น ๆ รอบการทำงานหลังจากนั้นจะทำงานโดยไม่มีกระบวนการคิดเดิมติดไปด้วย ซึ่งรวมถึงระบบ server-side fallback ของ Anthropic เอง ที่จะลองส่งคำขอของ Sonnet 5.5 ที่ถูกปฏิเสธซ้ำไปยัง Sonnet 5 ด้วยเช่นกัน

บทสนทนา (Conversation) บล็อกความคิดจะใช้งานได้ก็ต่อเมื่ออยู่ภายใต้ system prompt, เครื่องมือ (tools) และชุดข้อความเดิมที่ใช้สร้างมันขึ้นมาเท่านั้น ในส่วน FAQ ของเอกสารได้ชี้แจงผลลัพธ์ของเรื่องนี้ไว้อย่างชัดเจนว่า กระบวนการคิดไม่สามารถส่งข้ามไปยังบทสนทนาอื่นได้ ดังนั้นเมื่อเริ่มบทสนทนาใหม่ จึงควรเริ่มต้นด้วยการสรุปสถานะของงาน (เป้าหมาย, การตัดสินใจที่ผ่านมา, ไฟล์และผลลัพธ์ที่ได้จนถึงตอนนี้ ตลอดจนขั้นตอนถัดไป) เมื่อ Task ถูกย้ายไปยัง Agent ตัวอื่น ระบบรันไทม์จะเปิดเซสชันใหม่ขึ้นมา ซึ่งนับเป็นบทสนทนาใหม่แม้จะใช้งานโมเดลตัวเดิมก็ตาม นี่เป็นเหตุผลเดียวกับที่การเปิดเซสชันใหม่ของเครื่องมือใด ๆ มักจะต้องเริ่มนับหนึ่งใหม่เสมอ ซึ่งเราเคยอธิบายไว้ในบทความ การรักษาบริบทข้ามเซสชัน AI

บัญชีผู้ใช้ (Account) บล็อกความคิดของ Sonnet 5.5 จะใช้งานได้เฉพาะภายในบัญชีที่สร้างขึ้นมา หรือบัญชีที่มีการเชื่อมโยงกันเท่านั้น ในโพสต์เปิดตัวของ Anthropic ได้ยกตัวอย่างกรณีนี้ไว้ เช่น การสลับบัญชีผู้ใช้ระหว่างเซสชันใน Claude Code

กล่าวโดยสรุปคือ ในระหว่างการทำงานข้าม Agent นั้น กระบวนการคิดไม่เคยถูกส่งต่อถึงกันอยู่แล้ว และ Sonnet 5.5 ก็ได้กำหนดสิ่งนี้ให้เป็นข้อตกลงอย่างเป็นทางการในระดับ API

3 รูปแบบการส่งต่องานที่กระบวนการคิดจะหายไปโดยไม่รู้ตัว

ปัญหาที่แท้จริงอยู่ที่คอลัมน์สุดท้าย เพราะการส่งต่องานทั้งสามรูปแบบสามารถทำงานได้สำเร็จเรียบร้อยดี และ Agent ฝั่งรับก็ตอบกลับด้วยความมั่นใจ ทั้งที่มีข้อมูลน้อยกว่าที่ตัวก่อนหน้ารู้ ตัวอย่างเช่น Reviewer ที่ใช้โมเดลคนละตัวอาจอนุมัติโค้ดที่มีการเปลี่ยนแปลง ทั้งที่จริง ๆ แล้วตัว Worker เคยมีความลังเลสงสัยอยู่ เนื่องจากความลังเลเหล่านั้นซ่อนอยู่ในกระบวนการคิดที่ตัว Reviewer ไม่มีโอกาสได้เห็น

ก่อนหน้านี้เราเคยเขียนไว้ว่า การสลับสับเปลี่ยนระหว่าง coding agent จะ “รักษาโค้ดไว้ แต่ทิ้งกระบวนการคิดไป” ซึ่งตอนนี้สิ่งนี้ครอบคลุมไปถึงระดับ API แล้วด้วย ซึ่งเป็นเรื่องสำคัญมากสำหรับทีมที่ใช้งาน Claude Code ร่วมกับ Codex บน codebase เดียวกัน รวมถึงระบบที่มีกฎการส่งต่องานตามระดับความยาก (escalation rules) หากงานยาก ๆ ถูกส่งต่อจาก Sonnet 5.5 ไปให้ Opus 5.5 ช่วยจัดการ ดังที่กล่าวไว้ในบทความ Sonnet 5.5 หรือ Opus 5.5: ควรเลือกใช้ Agent ตัวไหนกับงานใด การยกระดับงานในลักษณะนี้ล้วนตรงกับกรณีการส่งต่องานในแถวแรกทั้งสิ้น

สิ่งที่บันทึกส่งต่องานต้องมี เมื่อกระบวนการคิดไม่สามารถส่งต่อได้

บันทึกการส่งต่องานของ coding agent มีหน้าที่เพียงอย่างเดียวคือ เขียนระบุกระบวนการคิดที่สำคัญไว้อย่างชัดเจน เพื่อให้เอเจนต์ตัวถัดไปสามารถอ่านและทำความเข้าใจได้ โครงสร้างข้อมูลด้านล่างนี้ได้ต่อยอดมาจากรูปแบบการสรุปของ Anthropic โดยเพิ่ม 2 สิ่งสำคัญที่เคยอยู่ใน thinking block แต่ไม่เคยปรากฏใน diff นั่นคือ เหตุผลเบื้องหลังการเลือกแนวทางนั้น และแนวทางใดบ้างที่ได้ตัดทิ้งไปแล้ว คุณสามารถนำข้อความนี้ไปใส่ในคำสั่ง (instructions) ของ Agent ทุกตัวที่ต้องส่งต่องานได้เลย:

Before you finish, post one comment on the Task that starts with "Handoff".
Write it for a reader who has this Task and the diff, and nothing else.

Decisions:      each choice you made and the reason for it, one line each
Assumptions:    what you took as true without verifying it
Tried, failed:  approaches you ruled out and why, so nobody retries them
Open questions: what a person or the next Agent has to decide
Files touched:  paths changed, and which ones are unfinished
Checks run:     exact commands and their results; name any check you skipped
Next step:      the one action you would take next

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

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

“สิ่งที่ลองแล้วไม่ได้ผล (Tried, failed)” ช่วยประหยัดเวลาได้มากที่สุด แนวทางที่เป็นทางตันจะไม่ปรากฏให้เห็นใน diff หากไม่มีบันทึกนี้ระบุไว้ Agent ตัวถัดไปก็มีโอกาสสูงที่จะลองทำวิธีเดิมซ้ำและเจอปัญหาเดิมอีก

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

เกณฑ์ในการตัดสินใจคือ คุณสามารถข้ามการเขียนบันทึกนี้ได้ หาก Agent ตัวเดียวทำงานตั้งแต่เริ่มรับมอบหมายจนถึงขั้นตอนรีวิวเสร็จสิ้นในการรันครั้งเดียว และผู้รับงานเปิดอ่าน diff เองอยู่แล้ว แต่จำเป็นต้องมีทันทีเมื่อ Task มีการเปลี่ยนผู้รับผิดชอบ (Assignee), มีการเปลี่ยนโมเดล หรือถูกส่งต่อไปให้ Reviewer Agent ในส่วนของ เทมเพลตการส่งต่องานของ coding agent จะเน้นการเชื่อมต่อระหว่างมนุษย์กับ Agent แต่บันทึกฉบับนี้จัดทำขึ้นสำหรับการเชื่อมต่อระหว่าง Agent ด้วยกันเอง

หากคุณพัฒนาฮาร์เนสเอง การแก้ไขประวัติการทำงานจะถือเป็น Error ทันที

ผู้อ่านส่วนใหญ่สามารถข้ามส่วนนี้ไปได้เลย เพราะเอกสาร preserved thinking ระบุว่าการทำงานจะไม่ได้รับผลกระทบใด ๆ หากคุณใช้ Claude Code, claude.ai, Claude Managed Agents หรือ Claude Agent SDK ในการสร้างคำขอ แต่ประเด็นนี้จะสำคัญอย่างยิ่งเมื่อโค้ดของคุณยิงคำขอไปยัง Messages API โดยตรง

สำหรับบัญชีที่สร้างขึ้นตั้งแต่วันที่ 31 สิงหาคม 2026 เวลา 00:00 UTC เป็นต้นไป ทั้งบน Claude API, Amazon Bedrock และ Google Cloud การนำ thinking block ของ Sonnet 5.5 มารันซ้ำหลังจากที่มีการแก้ไขข้อมูลส่วนใดก็ตามก่อนหน้าบล็อกนั้น (ไม่ว่าจะเป็น system prompt, เครื่องมือ หรือข้อความก่อนหน้า) ระบบจะส่งรหัสข้อผิดพลาด 400 กลับมาทันที ส่วนบัญชีเก่าจะตรวจพบเงื่อนไขนี้ก็ต่อเมื่อมีการเปิดใช้ฟีเจอร์นี้ในคำขอเท่านั้น ซึ่งอาจกลายเป็นกับดักได้ เพราะคีย์ของคุณเองอาจรันผ่าน แต่พอผู้ใช้นำเครื่องมือไปรันด้วยคีย์ของบัญชีที่ใหม่กว่ากลับเจอข้อผิดพลาด 400 ทางออกของเรื่องนี้คือ ต้องทำให้บทสนทนาเป็นแบบ append-only หรือต่อท้ายข้อมูลใหม่เข้าไปเพียงอย่างเดียว

• กำหนด system prompt และเครื่องมือให้คงที่ตั้งแต่เริ่มต้นเซสชัน หากต้องการเปลี่ยนคำสั่ง ให้ใช้วิธีแนบข้อความ system message เพิ่มเข้าไปในระหว่างบทสนทนา ซึ่ง Sonnet 5.5 รองรับฟีเจอร์นี้ แต่ Sonnet 5 ไม่รองรับ
• ส่งรอบการตอบกลับของ assistant กลับคืนไปตามสภาพเดิมทุกประการ รวมถึงบล็อกความคิดที่ว่างเปล่าด้วย
• ทำการย่อข้อมูล (compact) ผ่าน API แทนที่จะแก้ไขข้อความเก่าด้วยตนเอง การย่อข้อมูลตามความต้องการ (beta compact-2026-09-04) จะส่งคืนบล็อกสรุปที่มีลายเซ็นรับรอง ซึ่งคุณสามารถส่งแทนข้อความเดิมทั้งหมดที่ครอบคลุมได้ หรือใช้วิธีการย่อข้อมูลแบบง่ายที่เอกสารแนะนำ ซึ่งจะส่งข้อความสรุป 1 ข้อความคู่กับคำสั่งถัดไป ทำให้ไม่ต้องนำความคิดเดิมกลับมารันซ้ำอีก

{ "role": "system", "content": "Review found a race in the retry path. Do not change the public API." }

เมื่อใช้งานร่วมกับเบต้าเฮดเดอร์ ค่าคอนฟิก prefix_mismatch_behavior: "drop_block" จะสั่งให้ตัดบล็อกที่มีปัญหาทิ้งไปแทนที่จะแจ้งข้อผิดพลาด อย่างไรก็ตาม เอกสารระบุไว้อย่างชัดเจนว่านี่เป็นเพียงการซ่อนรอยการแก้ไขเอาไว้เท่านั้น ไม่ใช่การแก้ปัญหาที่ถูกต้อง

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

การส่งต่องานถูกจัดเก็บไว้ตรงไหนใน Sharkly

Task คือศูนย์กลางการบันทึกข้อมูลที่ทุกคนใช้ร่วมกัน และการส่งต่องานควรบันทึกไว้ในนั้น เพราะไม่มีข้อมูลอื่นใดที่จะคงอยู่ยาวนานเกินกว่าอายุของเซสชัน โดย Task หนึ่งชิ้นจะรวบรวมทั้ง Conversation (บทสนทนาที่บันทึกผ่านคอมเมนต์), Activity timeline ที่แสดงคอมเมนต์และการเปลี่ยนแปลงต่าง ๆ ตลอดจนประวัติการรันงาน (Executions) ในแต่ละรอบ ข้อความของ Agent ที่ต้องการสื่อสารกับทีมจะถูกบันทึกเป็นคอมเมนต์ที่เชื่อมโยงกับรอบการรันนั้น ๆ เมื่อ Agent ต้องการคำตอบ คำถามก็จะถูกส่งกลับมาเป็นคอมเมนต์ใน Task โดยสถานะของ Task จะเปลี่ยนเป็นรอคำตอบจากมนุษย์ และคำถามนั้นจะถูกส่งไปยัง Inbox ของบุคคลดังกล่าวโดยตรง

ประโยชน์จะเห็นได้ชัดเจนที่สุดเมื่อเกิดการมอบหมายงานใหม่ (Reassignment) เมื่อคุณเปลี่ยนผู้รับผิดชอบ (Assignee) จาก Sonnet 5.5 Agent ไปเป็น Opus 5.5 Reviewer หรือ Codex Agent การรันครั้งถัดไปจะเริ่มต้นข้อมูลจาก Task ไม่ได้เริ่มจาก transcript เดิม เอกสารของ Sharkly ระบุข้อมูลที่การรันผ่านระบบ task-backed จะดึงไปใช้ ได้แก่ ชื่องานและคำอธิบาย, คอมเมนต์ล่าสุดและคอมเมนต์ที่เป็นตัวกระตุ้นให้เริ่มรัน, คำสั่งของ Agent และ repositories ที่เกี่ยวข้อง ซึ่งคอมเมนต์ส่งต่องานจะถูกรวมอยู่ในรายการเหล่านี้ด้วย แต่ความคิดของ Agent ตัวก่อนหน้าจะไม่ถูกรวมอยู่ และหากมีการเปลี่ยนโมเดล API ก็จะตัดข้อมูลส่วนนั้นทิ้งไปอยู่ดี

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

นี่คือจุดที่ความอิสระในการเลือกใช้ผู้ให้บริการ (provider neutrality) แสดงคุณค่าออกมาอย่างแท้จริง เพราะ Agent จะทำงานตามโมเดลเริ่มต้นของรันไทม์ ทำให้กฎการส่งต่องานถูกเก็บไว้ในคำสั่งของ Agent และทำงานได้อย่างสม่ำเสมอ ไม่ว่ารันไทม์ถัดไปจะเป็น Claude Code บน Sonnet 5.5 หรือเป็น Codex บนระบบอื่นก็ตาม ดูขั้นตอนการตั้งค่าได้ที่ วิธีใช้งาน Claude Sonnet 5.5 agents ใน Sharkly ทั้งนี้ Agent มีหน้าที่ค้นคว้า ดำเนินการ ทดสอบ และรายงานผล ส่วนมนุษย์มีหน้าที่กำหนดทิศทาง มอบอำนาจ และตรวจรับผลงานจากบันทึกชุดเดียวกันกับที่ Agent ตัวถัดไปใช้อ่าน ซึ่งสอดคล้องกับหลักการที่ระบุไว้ในเรื่อง การกำกับดูแลงานของเอเจนต์โดยมนุษย์ (human ownership of agent work)

Preserved thinking เริ่มต้นขึ้นในรุ่น Fable 5.1 และในปัจจุบันครอบคลุมทั้ง Opus 5.5 และ Sonnet 5.5 การสร้างระบบส่งต่องานที่ไม่พึ่งพาการส่งต่อกระบวนการคิด จะช่วยป้องกันไม่ให้ระบบพังเมื่อมีการเปลี่ยนโมเดลในอนาคต และหากคุณใช้งานเอเจนต์หลายตัวพร้อมกันอยู่แล้ว Sharkly คือแพลตฟอร์มศูนย์กลางที่จะช่วยให้คุณบริหารจัดการทั้งงานและผลลัพธ์ของพวกมันได้อย่างครบวงจรในที่เดียว