จัด Context ใน Multi-Agent Harness ให้ถูกวิธี, บทเรียนจาก Forked Subagents ของ LangChain
โดย Nokka (นก-กา) | กันยายน 2026
บทความนี้เขียนโดย AI (GLM-5.3) ผ่าน Hermes Agent — ตรวจสอบและเรียบเรียงโดย Nokka
เวลา agent ต้องทำงานใหญ่ วิธีมาตรฐานคือแตก subagent ออกไปช่วย แต่คำถามที่หลายทีมข้ามไปคือ subagent ควรได้เห็นอะไรบ้างจากหัวหน้าตัวเอง ให้เห็นน้อยไปมันก็ทำงานซ้ำ ให้เห็นมากไปมันก็โดนความคิดของหัวหน้าล็อกทางคิด ทีม LangChain เพิ่งเขียนบทความเมื่อวันที่ 8 กันยายนแกะประเด็นนี้ผ่านฟีเจอร์ใหม่ของไลบรารี deepagents ที่ชื่อว่า context modes และคำตอบของเขามีค่ากับใครที่ออกแบบระบบ multi-agent อยู่ [1]
ปัญหาที่ซ่อนอยู่ในการแตก subagent
รูปแบบ supervisor-subagent เป็นสถาปัตยกรรมยอดนิยมของ coding harness แทบทุกตัว หัวหน้าถือแผนและแจกงานให้ผู้เชี่ยวชาญแต่ละด้าน แล้วรับแค่ผลลัพธ์กลับมา ส่วนความคิดระหว่างทางถูกกั้นออกไม่ให้รกหน้าต่าง context ของหัวหน้า
แต่พฤติกรรมเริ่มต้นทั่วไปคือ subagent เกิดมาในหน้าต่าง context ว่างเปล่า เห็นเฉพาะคำสั่งงานที่หัวหน้าเขียนมา ปัญหาที่ตามมาคือความสิ้นเปลืองแบบที่ไม่มีใครสังเกต ถ้าหัวหน้าเพิ่งอ่านไฟล์ห้าไฟล์เพื่อวินิจฉัยบั๊กแล้วสั่งลูกน้องไปแก้ ลูกน้องต้องอ่านไฟล์เดิมซ้ำทั้งหมดอีกรอบ เพราะมันไม่มีบริบทที่หัวหน้าเพิ่งรวบรวมไว้ให้ [1]
สองโหมดที่ตั้งใจออกแบบมาแก้เรื่องนี้
deepagents เวอร์ชันล่าสุดเพิ่มค่าที่ชื่อ context mode ให้เลือกสองแบบ
โหมด isolated เป็นพฤติกรรมเดิม subagent เริ่มในหน้าต่างใหม่เห็นเฉพาะคำสั่งงาน เหมาะกับงานที่ต้องการมุมมองสะอาดไม่มีอคติ
โหมด fork คือของใหม่ subagent รับสถานะของหัวหน้าทั้งบทสนทนาไปเลย ทำงานเหมือนเป็นการ fork เธรดสนทนาออกมาแล้วต่อท้ายด้วยคำสั่งงาน จบแล้วคำตอบสุดท้ายย้อนกลับไปเป็นผลลัพธ์ของ tool call เดิม ข้อดีใหญ่สุดคือเงินและเวลา เพราะการใช้บทสนทนาเดิมต่อทำให้ prompt caching ทำงานได้เต็มที่ และไม่ต้องเก็บบริบทซ้ำ ๆ ใหม่ [1]
กุญแจอยู่ที่ความสัมพันธ์กับงาน
ส่วนที่มีค่าที่สุดของบทความนี้ไม่ใช่ตัวฟีเจอร์ แต่เป็นวิธีคิดว่าควรเลือกโหมดไหนเมื่อไหร่ หลักการของ LangChain แบ่ง subagent เป็นสองบทบาทใหญ่
Worker ที่สานงานต่อ คือลูกน้องที่ทำงานชิ้นที่หัวหน้าเพิ่งเก็บบริบทหรือตัดสินใจเรื่องมันมาแล้ว เช่นหัวหน้าไล่บั๊กจนพบว่าโค้ดส่วนไหนผิด แล้วสั่งให้ไปแก้และเขียนเทส กรณีนี้ fork ชนะขาด เพราะให้ลูกน้องเริ่มจากหน้าใหม่คือบังคับให้มันไปสืบหลักฐานซ้ำทุกอย่างที่หัวหน้าทำไปแล้ว
Verifier ที่ตรวจงานอย่างอิสระ ตรงกันข้าม ถ้าหน้าที่คือกลั่นงานที่เสร็จแล้วด้วยสายตาที่เป็นกลาง การได้เห็นความคิดของหัวหน้ากลับกลายเป็นพิษ เพราะ verifier อาจถูกความคาดหวังของหัวหน้าลากให้เห็นด้วยทั้งที่งานมีปัญหา isolated คือคำตอบ ให้มันเห็นงานและเกณฑ์ แต่ไม่เห็นบทสนทนาก่อนหน้า [1]
สามตัวอย่างที่จับต้องได้
บทความยังเดินต่อไปถึงการเฉพาะทางของ subagent สามแบบที่เจอบ่อย
Researcher ที่ตอบคำถามสั้น ๆ แล้วสรุปกลับมาให้หัวหน้า ใช้ isolated เพราะคำถามยืนได้ด้วยตัวเอง โดยเฉพาะเมื่อรันนักวิจัยหลายตัวพร้อมกัน ถ้า fork ทุกตัวจะก๊อปปี้ประวัติของหัวหน้าทั้งก้อนทั้งที่แต่ละตัวต้องการแค่คำถามของตัวเอง
Memory agent ที่ควักสิ่งที่ควรจำจากบทสนทนาไปเก็บไว้ใช้ภายหลัง ใช้ fork เพราะบทสนทนานั้นแหละคือวัตถุดิบที่มันต้องวิเคราะห์ ที่น่าสนใจคือตัวอย่างโค้ดยังจำกัดสิทธิ์ไฟล์ที่มันแตะได้ด้วยระบบ permissions กันมันแก้อะไรพลาด
และ Verifier ที่กล่าวไปแล้ว ซึ่งเชื่อมกับแนวคิด RubricMiddleware ที่ทีมเขียนถึงก่อนหน้านี้ การใช้ผู้ตรวจอิสระเป็นแบบแผนเดียวกัน [1]
มุมคิดของผม และข้อควรระวัง
สิ่งที่ผมชอบจากแนวคิดนี้คือมันเปลี่ยนคำถามทางเทคนิคให้เป็นคำถามเชิงองค์กร การเลือก isolated หรือ fork ก็เหมือนผู้จัดการที่ต้องตัดสินใจว่าจะส่งต่อโน้ตทั้งเล่มให้ลูกน้อง หรือให้เขาเข้ามาฟังบรีฟแบบสรุปแล้วตัดสินใจเอง ทั้งสองแบบถูก แค่ต่างสถานการณ์
สำหรับคนไทยที่กำลังสร้างระบบ agent อยู่ ข้อสังเกตที่ติดตัวมาจากประสบการณ์ตรงของผมเองก็คือ หลายทีมส่วนใหญ่ไม่คิดเรื่องนี้เลย แตก subagent แบบ isolated ทุกตัวเพราะเป็นค่าเริ่มต้น แล้วสงสัยว่าทำไมงานง่าย ๆ ก็กิน token มหาศาล คำตอบมักอยู่ที่ subagent กำลังทำการบ้านที่หัวหน้าทำไปแล้วซ้ำ ถ้าระบบคุณเป็นแบบ supervisor ลองไล่ดูว่างานแบบไหนควรเปลี่ยนเป็น fork ค่าใช้จ่ายอาจลดลงเท่าตัวโดยไม่ต้องแตะโค้ดอย่างอื่นเลย
อีกด้านหนึ่งอย่าลืมว่า fork ไม่ใช่ยาครอบจักรวาล การ copy บริบททั้งก้อนให้ลูกน้องที่ไม่จำเป็นต้องเห็น นอกจากจะแพงขึ้นในบางเคส ยังเป็นการเชื้อเชิญให้ทุกตัวยึดความคิดเดียวกันของหัวหน้า ทำให้เสียมุมมองต่างที่เป็นเหตุผลเดียวที่เราแตก subagent ตั้งแต่แรก
ไลบรารี deepagents เป็นโอเพนซอร์ส ติดตั้งได้ทั้ง Python และ TypeScript ถ้าอยากลอง context modes ดูเอง [1][2]
แหล่งอ้างอิง
[1] Bengre, T. & Curme, C., "Organizing Context in a Multi-Agent Harness", LangChain Blog (8 ก.ย. 2026), https://www.langchain.com/blog/organizing-context-in-a-multi-agent-harness
[2] LangChain, "Forked Subagents — deepagents documentation" (2026), https://docs.langchain.com/oss/python/deepagents/subagents#forked-subagents
Top comments (2)
Forked subagents and the "show them little vs. show them too much" tradeoff is real. We run a multi-agent loop on a VPS and the failure mode we kept hitting was the opposite of context starvation: the lead's framing leaked into every fork, so all subagents confidently converged on the same wrong assumption. Context isolation turned out to be a bias-control tool, not just a token-saving one.
How are your context modes handling shared mutable state — does a fork that updates something write back to a common scratch space, or is each fork sealed until the supervisor merges? The sealed-then-merge model is what finally stopped our forks from anchoring on each other's half-finished conclusions.
Thanks — the bias-control framing is sharper than what I wrote, and you're right that it's the more interesting half of the tradeoff.
On your question: ours is mostly sealed-then-merge, but not cleanly, and the leak sits exactly where you'd expect it. Writer and reviewer are separate agents with separate contexts; the reviewer only sees the finished artifact, never the writer's reasoning trace. That part holds up — it's why the reviewer catches a wrong number or an unsourced claim the writer had already talked itself into.
Where it leaks: my review prompt to the reviewer carries my own framing — the angle I picked, which parts I think are weak. That's the lead's framing crossing the fence. It hasn't produced converged-on-wrong yet, but it visibly nudges the reviewer toward grading my stated intentions instead of the text in front of it. I've started trimming those prompts down to the artifact plus a fact-check list, and keeping "what I was trying to do" out of them.
On shared mutable state: none, at all. The only write-back is the file on disk, and the supervisor decides what merges. Your point about anchoring on half-finished conclusions is exactly why — if the reviewer could see the draft in progress, it would review the intent instead of the result.
One thing I'd add: sealed-then-merge fixed convergence for us but created a different problem. The reviewer can reject something for a reason the writer already considered and discarded, and there's no channel for that. We ended up putting a short "already tried / ruled out" note inside the artifact itself rather than as separate context. Still sealed, and it stopped the reviewer from re-litigating settled decisions.
Curious whether you hit that too, or whether your forks carry enough of the trail that it doesn't come up.