ทุกวันมีเฟรมเวิร์กใหม่ เกณฑ์มาตรฐานใหม่ การเปิดตัวแบบ "10x" ใหม่เกิดขึ้น คำถามไม่ได้อยู่ที่ "ฉันจะตามให้ทันได้อย่างไร" อีกต่อไป แต่มันกลายเป็น: อะไรคือสัญญาณที่แท้จริง และอะไรคือเสียงรบกวนที่ปลอมตัวมาเป็นความเร่งด่วน
โรดแมปทุกอันล้าสมัยภายในหนึ่งเดือนหลังจากเปิดตัว เฟรมเวิร์กที่คุณเชี่ยวชาญเมื่อไตรมาสที่แล้ว ตอนนี้กลายเป็นของเก่า เกณฑ์มาตรฐานที่คุณปรับให้เหมาะสมถูกนำไปใช้ในทางที่ผิดและถูกแทนที่ เราถูกหล่อหลอมให้เดินตามเส้นทางแบบเดิม: สแต็กที่มีหัวข้อและระดับ ลำดับของงานและอายุงาน การไต่เขาอย่างช้าๆ AI เขียนผืนผ้าใบนั้นใหม่ ทุกคนที่มีพรอมต์ที่ถูกต้องและรสนิยมที่ถูกต้องสามารถส่งงานที่เคยต้องใช้วิศวกรที่มีประสบการณ์ 2 ปีทำงานเป็นสปรินต์ได้แล้ว
ความเชี่ยวชาญยังคงมีความสำคัญ ไม่มีอะไรมาทดแทนการได้เห็นระบบล่ม การดีบักหน่วยความจำรั่วตอนตี 2 การโต้แย้งเพื่อเลือกทางเลือกที่น่าเบื่อมากกว่าทางเลือกที่ฉลาดและถูกต้อง รสนิยมแบบนั้นทบต้น สิ่งที่หยุดทบต้นอย่างที่เคยเป็น: การรู้พื้นผิว API ของเฟรมเวิร์กในสัปดาห์นี้ อีกหกเดือนมันจะแตกต่างออกไป คนที่ชนะในอีกสองปีคือคนที่เลือกพื้นฐานที่คงทนตั้งแต่เนิ่นๆ และปล่อยให้ส่วนที่เหลือผ่านไป
ฉันใช้เวลาสองปีในการสร้างในพื้นที่นี้ ได้ข้อเสนอหลายครั้งที่มากกว่า $250,000 และตอนนี้บริหารงานด้านเทคนิคที่บริษัทในสภาวะลับ นี่คือสิ่งที่ฉันจะส่งให้คนที่ถามว่า "ตอนนี้ฉันควรให้ความสนใจกับอะไรจริงๆ"
มันไม่ใช่โรดแมป สาขาเอเจนต์ยังไม่มีจุดหมายปลายทาง ห้องปฏิบัติการขนาดใหญ่กำลังทำซ้ำในที่สาธารณะ ส่งการถดถอยให้ผู้ใช้หลายล้านคน เขียนบทวิเคราะห์หลังเหตุการณ์ แก้ไขแบบเรียลไทม์ ถ้าทีมที่อยู่เบื้องหลัง Claude Code สามารถส่งการถดถอยประสิทธิภาพ 47% และจับได้หลังจากที่ชุมชนผู้ใช้พบเท่านั้น ความคิดที่ว่ามีแผนที่ที่มั่นคงอยู่ภายใต้ทั้งหมดนี้เป็นเรื่องโกหก ทุกคนกำลังหาคำตอบ สตาร์ทอัพกำลังเฟื่องฟูเพราะยักษ์ใหญ่ก็ไม่รู้เหมือนกัน คนที่ไม่ใช่นักเขียนโค้ดกำลังจับคู่กับเอเจนต์และส่งสิ่งที่นักวิจัย ML ปริญญาเอกเรียกมันว่าเป็นไปไม่ได้เมื่อวันอังคาร
สิ่งที่น่าสนใจเกี่ยวกับช่วงเวลานี้คือสิ่งที่มันทำกับคำถามเรื่องวุฒิการศึกษา เส้นทางแบบเดิมปรับให้คุณเหมาะสมกับวุฒิการศึกษา: ปริญญา บทบาทจูเนียร์ บทบาทอาวุโส บทบาทพนักงาน การสะสมยศอย่างช้าๆ สิ่งนั้นสมเหตุสมผลเมื่อสาขาที่อยู่ใต้คุณไม่เคลื่อนไหว ตอนนี้สาขาเคลื่อนไหวภายใต้ทุกคนอย่างเท่าเทียมกัน ความแตกต่างระหว่างเด็กอายุ 22 ปีที่ส่งเดโมเอเจนต์ในที่สาธารณะกับวิศวกรอาวุโสอายุ 35 ปี ไม่ใช่ความเชี่ยวชาญสแต็กที่สั่งสมมาเป็นเวลาสิบปีอีกต่อไป เด็กอายุ 22 ปีมีผืนผ้าใบว่างเปล่าแบบเดียวกับที่วิศวกรอาวุโสมี และสิ่งที่ทบต้นสำหรับทั้งคู่คือความเต็มใจที่จะส่ง รวมถึงรายการเล็กๆ ของพื้นฐานที่ไม่ล้าสมัยในหนึ่งไตรมาส
นั่นคือกรอบความคิดใหม่ที่บทความทั้งหมดนี้สร้างขึ้น สิ่งที่ตามมาคือวิธีคิดว่าพื้นฐานใดคุ้มค่ากับความสนใจของคุณและการเปิดตัวใดที่ควรปล่อยผ่าน เลือกสิ่งที่เหมาะกับคุณ ทิ้งสิ่งที่ไม่เหมาะ
ตัวกรองที่ใช้ได้จริง
คุณไม่สามารถตามการเปิดตัวรายสัปดาห์ได้ทัน คุณไม่ควรพยายาม สิ่งที่คุณต้องการคือตัวกรอง ไม่ใช่ฟีด
การทดสอบห้าข้อนี้ใช้ได้ผลตลอด 18 เดือนที่ผ่านมา ลองใช้การทดสอบเหล่านี้กับการเปิดตัวก่อนที่จะปล่อยให้มันแตะสแต็กของคุณ
สิ่งนี้จะมีความสำคัญในอีกสองปีหรือไม่? ถ้ามันเป็น wrapper รอบๆ โมเดล frontier, แฟล็ก CLI, หรือ "Devin แต่สำหรับ X" คำตอบมักจะไม่ใช่ ถ้ามันเป็นพื้นฐาน (โปรโตคอล รูปแบบหน่วยความจำ วิธีการแซนด์บ็อกซ์) คำตอบมักจะใช่ ครึ่งชีวิตของ wrappers นั้นสั้น ครึ่งชีวิตของพื้นฐานนั้นยาวนานเป็นปี
มีคนที่คุณเคารพสร้างของจริงบนนั้นและเขียนเกี่ยวกับมันอย่างตรงไปตรงมาหรือไม่? โพสต์การตลาดไม่นับ บทวิเคราะห์หลังเหตุการณ์นับ บล็อกที่ชื่อว่า "เราลองใช้ X ในโปรดักชั่นและนี่คือสิ่งที่พัง" มีค่าเท่ากับประกาศเปิดตัวสิบครั้ง สัญญาณที่ดีในสาขานี้มักเขียนโดยคนที่เสียสละวันหยุดสุดสัปดาห์ให้กับมัน
การนำมาใช้ทำให้คุณต้องทิ้ง tracing, retries, config, auth ของคุณหรือไม่? ถ้าใช่ มันคือเฟรมเวิร์กที่พยายามเป็นแพลตฟอร์ม เฟรมเวิร์กที่พยายามเป็นแพลตฟอร์มมีอัตราการตาย 90% พื้นฐานที่ดีจะสอดแทรกเข้ากับระบบที่มีอยู่ของคุณโดยไม่บังคับให้ย้ายระบบ
การข้ามสิ่งนี้ไปหกเดือนมีค่าใช้จ่ายเท่าไหร่? สำหรับการเปิดตัวส่วนใหญ่ คำตอบคือไม่มีอะไร คุณจะรู้มากขึ้นในอีกหกเดือน เวอร์ชันที่ชนะจะชัดเจนขึ้น นี่คือการทดสอบที่ช่วยให้คุณข้าม 90% ของการเปิดตัวได้โดยไม่ต้องกังวล และเป็นสิ่งที่คนส่วนใหญ่ปฏิเสธที่จะทำเพราะการข้ามรู้สึกเหมือนกำลังตกหล่น มันไม่ใช่
คุณสามารถวัดได้หรือไม่ว่ามันช่วยเอเจนต์ของคุณจริงๆ? ถ้าคุณทำไม่ได้ แสดงว่าคุณกำลังเดา ทีมที่ไม่มี evals ทำงานด้วยความรู้สึกและส่งการถดถอย ทีมที่มี evals สามารถปล่อยให้ข้อมูลบอกพวกเขาว่า GPT-5.5 หรือ Opus 4.7 ชนะในเวิร์กโหลดเฉพาะของพวกเขาในสัปดาห์นี้
ถ้าคุณนำนิสัยเดียวจากบทความทั้งหมดนี้มาใช้ จงทำสิ่งนี้: เมื่อมีอะไรใหม่เปิดตัว ให้เขียนสิ่งที่คุณต้องเห็นในอีกหกเดือนเพื่อเชื่อว่ามันสำคัญ แล้วกลับมาตรวจสอบ ส่วนใหญ่แล้วคำถามจะตอบตัวเอง และคุณจะใช้ความสนใจของคุณกับสิ่งที่ทบต้น
ทักษะที่อยู่ภายใต้การทดสอบเหล่านี้ยากที่จะตั้งชื่อมากกว่าสิ่งใดๆ มันคือความเต็มใจที่จะไม่เจ๋งเกี่ยวกับสิ่งที่คุณไม่รับ เฟรมเวิร์กที่กลายเป็นไวรัลบน Hacker News ในสัปดาห์นี้จะมีกองทัพเชียร์ลีดเดอร์เป็นเวลาสิบสี่วัน และพวกเขาทั้งหมดจะฟังดูฉลาด หกเดือนต่อมา ครึ่งหนึ่งของเฟรมเวิร์กเหล่านั้นไม่ได้รับการบำรุงรักษาและเชียร์ลีดเดอร์ก็ย้ายไปแล้ว คนที่ไม่ได้มีส่วนร่วมช่วยความสนใจของพวกเขาไว้สำหรับสิ่งที่รอดชีวิตจากการทดสอบความน่าเบื่อหลังจากกระแสการเปิดตัวผ่านไป ท่าทางนั้น การยั้งไว้ การดู การพูดว่า "ฉันจะรู้ในอีกหกเดือน" คือทักษะทางอาชีพที่แท้จริงของสาขานี้ ทุกคนสามารถอ่านการเปิดตัวได้ แทบไม่มีใครเก่งในการไม่ตอบสนองต่อพวกเขา
สิ่งที่ต้องเรียนรู้
แนวคิด รูปแบบ โครงสร้างของสิ่งต่างๆ สิ่งเหล่านี้คือความคิดที่ให้ผลตอบแทนแบบทบต้น พวกมันอยู่รอดจากการเปลี่ยนโมเดล การเปลี่ยนเฟรมเวิร์ก การเปลี่ยนกระบวนทัศน์ เข้าใจพวกมันอย่างลึกซึ้ง แล้วคุณสามารถเรียนรู้เครื่องมือใหม่ๆ ได้ภายในวันหยุดสุดสัปดาห์ ข้ามพวกมันไป แล้วคุณจะต้องเรียนรู้กลไกพื้นผิวซ้ำแล้วซ้ำเล่า
วิศวกรรมบริบท (Context engineering)
การเปลี่ยนชื่อที่สำคัญที่สุดในสองปีที่ผ่านมาคือ "วิศวกรรมพรอมต์" กลายเป็น "วิศวกรรมบริบท" การเปลี่ยนแปลงนั้นเป็นจริง ไม่ใช่แค่เครื่องสำอาง
โมเดลไม่ใช่สิ่งที่คุณสร้างคำสั่งที่ชาญฉลาดอีกต่อไป มันคือสิ่งที่คุณประกอบบริบทการทำงานให้ในทุกขั้นตอน บริบทนั้นคือคำสั่งระบบ สคีมาเครื่องมือ เอกสารที่ดึงมา ผลลัพธ์เครื่องมือก่อนหน้า สถานะ scratchpad และประวัติที่ถูกบีบอัดทั้งหมดในคราวเดียว พฤติกรรมของเอเจนต์เป็นคุณสมบัติที่เกิดขึ้นจากสิ่งที่คุณใส่ในหน้าต่าง
ซึมซับสิ่งนี้: บริบทคือสถานะ ทุกโทเค็นของเสียงรบกวนที่ไม่เกี่ยวข้องทำให้คุณภาพการใช้เหตุผลของคุณลดลง การเน่าของบริบทเป็นความล้มเหลวในการผลิตจริง เมื่อถึงขั้นตอนที่แปดของงานสิบขั้นตอน เป้าหมายดั้งเดิมอาจถูกฝังอยู่ใต้ผลลัพธ์ของเครื่องมือ ทีมที่ส่งเอเจนต์ที่เชื่อถือได้จะสรุป บีบอัด ตัดแต่งอย่างจริงจัง พวกเขาใส่เวอร์ชันให้กับคำอธิบายเครื่องมือของพวกเขา พวกเขาแคชส่วนที่คงที่และปฏิเสธที่จะแคชส่วนที่เปลี่ยนแปลง พวกเขาคิดถึงหน้าต่างบริบทแบบเดียวกับที่วิศวกรที่มีประสบการณ์คิดถึง RAM
วิธีที่เป็นรูปธรรมในการรู้สึกถึงสิ่งนี้: นำเอเจนต์ใดๆ ในโปรดักชั่นมาเปิดการบันทึก trace แบบเต็ม ดูบริบทที่ขั้นตอนที่หนึ่ง ดูบริบทที่ขั้นตอนที่เจ็ด นับว่าโทเค็นเหล่านั้นยังคงทำงานได้ดีอยู่กี่ตัว ครั้งแรกที่คุณทำสิ่งนี้ คุณจะรู้สึกอาย จากนั้นคุณจะไปแก้ไขมัน และเอเจนต์ตัวเดิมจะมีความน่าเชื่อถือมากขึ้นอย่างเห็นได้ชัดโดยไม่ต้องเปลี่ยนแปลงโมเดลหรือพรอมต์
ถ้าคุณจะอ่านอะไรสักอย่างเกี่ยวกับเรื่องนี้ ให้อ่าน "Effective Context Engineering for AI Agents" ของ Anthropic จากนั้นอ่านบทวิเคราะห์หลังเหตุการณ์การวิจัยแบบ multi-agent ของพวกเขา ซึ่งใส่ตัวเลขว่าการแยกบริบทมีความสำคัญมากแค่ไหนเมื่อคุณปรับขนาดขึ้น
การออกแบบเครื่องมือ (Tool design)
เครื่องมือคือจุดที่เอเจนต์พบกับธุรกิจของคุณ โมเดลเลือกเครื่องมือตามชื่อและคำอธิบาย โมเดลลองใหม่ตามข้อความแสดงข้อผิดพลาด โมเดลล้มเหลวหรือประสบความสำเร็จตามว่าสัญญาของเครื่องมือตรงกับสิ่งที่ LLM ถนัดในการแสดงออกหรือไม่
เครื่องมือที่ตั้งชื่ออย่างดีห้าถึงสิบตัวดีกว่าเครื่องมือธรรมดายี่สิบตัว ชื่อเครื่องมือควรอ่านเหมือนวลีกริยาภาษาอังกฤษ คำอธิบายควรรวมถึงเมื่อใดควรใช้เครื่องมือและเมื่อใดไม่ควร ข้อความแสดงข้อผิดพลาดควรเป็นคำติชมที่โมเดลสามารถดำเนินการได้ "เกินขีดจำกัด 500 โทเค็น ลองสรุปก่อน" ดีกว่า "ข้อผิดพลาด: 400 Bad Request" อย่างมหาศาล ทีมหนึ่งในงานวิจัยสาธารณะรายงานว่าการวนซ้ำลองใหม่ลดลง 40% หลังจากเขียนข้อความแสดงข้อผิดพลาดใหม่เพียงอย่างเดียว
"Writing tools for agents" ของ Anthropic เป็นจุดเริ่มต้นที่ถูกต้อง หลังจากนั้น ให้ติดตั้งเครื่องมือของคุณเองและดูรูปแบบการเรียกจริง ชัยชนะที่ใหญ่ที่สุดในความน่าเชื่อถือของเอเจนต์มักจะอยู่ฝั่งเครื่องมือ ผู้คนยังคงปรับแต่งพรอมต์และละเลยสถานที่ที่ leverage ที่แท้จริงอยู่
รูปแบบ orchestrator-subagent
การถกเถียงเรื่อง multi-agent ในปี 2024 และ 2025 จบลงด้วยการสังเคราะห์ที่ทุกคนตอนนี้ส่ง ระบบ multi-agent แบบไร้เดียงสา ซึ่งเอเจนต์หลายตัวเขียนไปยังสถานะที่ใช้ร่วมกันแบบขนาน ล้มเหลวอย่างรุนแรงเพราะข้อผิดพลาดทบต้น การวนซ้ำเอเจนต์เดี่ยวสามารถปรับขนาดได้ไกลกว่าที่คุณคาดหวัง มีรูปแบบ multi-agent หนึ่งรูปแบบที่ใช้ได้ในโปรดักชั่น: เอเจนต์ orchestrator ที่มอบหมายงานแบบอ่านอย่างเดียวที่มีขอบเขตแคบให้กับ subagent ที่แยกออกมา จากนั้นสังเคราะห์ผลลัพธ์ของพวกมัน
นี่คือวิธีการทำงานของระบบวิจัยของ Anthropic นี่คือวิธีการทำงานของ subagent ของ Claude Code มันเป็นรูปแบบที่ Spring AI และเฟรมเวิร์กการผลิตส่วนใหญ่ตอนนี้ทำให้เป็นมาตรฐาน Subagent ได้รับบริบทที่เล็กและโฟกัส พวกมันไม่สามารถกลายพันธุ์สถานะที่ใช้ร่วมกันได้ Orchestrator เป็นเจ้าของการเขียน
เรียงความ "Don't Build Multi-Agents" ของ Cognition และ "How we built our multi-agent research system" ของ Anthropic ดูเหมือนตรงกันข้ามและกำลังพูดสิ่งเดียวกันในคำศัพท์ที่แตกต่างกัน อ่านทั้งสองอย่าง
ค่าเริ่มต้นคือเอเจนต์เดี่ยว ใช้ orchestrator-subagent เฉพาะเมื่อเอเจนต์เดี่ยวชนกำแพงจริง: แรงกดดันหน้าต่างบริบท ความหน่วงจากการเรียกเครื่องมือตามลำดับ หรือความหลากหลายของงานที่ได้ประโยชน์จากบริบทที่โฟกัสอย่างแท้จริง การสร้างสิ่งนี้ก่อนที่คุณจะรู้สึกถึงความเจ็บปวดจะส่งความซับซ้อนที่คุณไม่ต้องการ
Evals และชุดข้อมูลทองคำ (Evals and golden datasets)
ทุกทีมที่ส่งเอเจนต์ที่เชื่อถือได้มี evals ทุกทีมที่ไม่มี ก็ไม่มี นี่คือนิสัยที่มี leverage สูงที่สุดในสาขา และเป็นสิ่งที่ลงทุนน้อยที่สุดที่ฉันเห็นในทุกบริษัทที่ฉันดู
สิ่งที่ใช้ได้ผล: เก็บเกี่ยว traces การผลิตของคุณ ติดป้ายความล้มเหลว ถือว่ามันเป็นชุดการถดถอย เพิ่มเข้าไปเมื่อใดก็ตามที่มีความล้มเหลวใหม่เกิดขึ้น ใช้ LLM-as-judge สำหรับส่วนที่เป็นอัตนัย ใช้การตรวจสอบแบบ exact-match หรือ programmatic สำหรับส่วนที่เหลือ รันชุดก่อนการเปลี่ยนแปลงพรอมต์ โมเดล หรือเครื่องมือใดๆ บล็อกวิศวกรรมของ Spotify รายงานว่าเลเยอร์ผู้พิพากษาของพวกเขายับยั้งผลลัพธ์ของเอเจนต์ประมาณ 25% ก่อนที่จะส่ง หากไม่มีมัน หนึ่งในสี่ของผลลัพธ์ที่ไม่ดีจะถึงมือผู้ใช้
แบบจำลองทางความคิดที่ทำให้สิ่งนี้ติด: eval คือการทดสอบหน่วยที่ทำให้เอเจนต์ซื่อสัตย์ในขณะที่ทุกอย่างอื่นเปลี่ยนแปลงไปภายใต้มัน โมเดลได้รับเวอร์ชันใหม่ เฟรมเวิร์กปล่อยการเปลี่ยนแปลงที่ทำลายความเข้ากันได้ ผู้ขายเลิกใช้เอนด์พอยต์ Evals ของคุณเป็นสิ่งเดียวที่บอกคุณได้ว่าเอเจนต์ของคุณยังคงทำงานอยู่หรือไม่ หากไม่มีพวกมัน คุณกำลังเขียนระบบที่ความถูกต้องขึ้นอยู่กับความปรารถนาดีของเป้าหมายที่เคลื่อนที่
เฟรมเวิร์ก eval (Braintrust, Langfuse evals, LangSmith) ก็ใช้ได้ ไม่มีตัวไหนเป็นคอขวด คอขวดคือการมีชุดที่ติดป้ายตั้งแต่แรก สร้างมันในวันแรก ก่อนที่คุณจะปรับขนาดอะไร ตัวอย่างห้าสิบตัวอย่างแรกสามารถติดป้ายด้วยมือได้ในบ่ายวันเดียว ไม่มีข้อแก้ตัว
ไฟล์ระบบเป็นสถานะและลูปคิด-ทำ-สังเกต (File-system-as-state and the think-act-observe loop)
สำหรับเอเจนต์ใดๆ ที่ทำงานหลายขั้นตอนจริง สถาปัตยกรรมที่ทนทานคือ: คิด ทำ สังเกต ทำซ้ำ ไฟล์ระบบหรือที่เก็บที่มีโครงสร้างเป็นแหล่งความจริง ทุกการกระทำถูกบันทึกและเล่นซ้ำได้ Claude Code, Cursor, Devin, Aider, OpenHands, goose พวกมันทั้งหมดมาบรรจบกันที่สิ่งนี้ด้วยเหตุผล
โมเดลไม่มีสถานะ ตัวควบคุมต้องมีสถานะ ไฟล์ระบบเป็นพื้นฐานที่มีสถานะที่นักพัฒนาทุกคนเข้าใจอยู่แล้ว เมื่อคุณยอมรับกรอบนี้แล้ว ระเบียบวินัยของตัวควบคุมทั้งหมด (การตั้งจุดตรวจสอบ, ความสามารถในการดำเนินการต่อ, การตรวจสอบ subagent, การดำเนินการในแซนด์บ็อกซ์) จะเป็นผลมาจากการให้ความสำคัญกับรูปแบบอย่างจริงจัง
สิ่งที่ลึกซึ้งกว่านี้กำลังสอนคุณ: ตัวควบคุมทำงานหนักกว่าโมเดลในเอเจนต์การผลิตใดๆ ที่คุ้มค่ากับค่าใช้จ่ายในการคำนวณ โมเดลเลือกการกระทำถัดไป ตัวควบคุมตรวจสอบความถูกต้อง รันในแซนด์บ็อกซ์ จับภาพผลลัพธ์ ตัดสินใจว่าจะป้อนอะไรกลับ ตัดสินใจว่าจะหยุดเมื่อใด ตัดสินใจว่าจะตั้งจุดตรวจสอบเมื่อใด ตัดสินใจว่าจะสร้าง subagent เมื่อใด สลับโมเดลเป็นตัวอื่นที่มีคุณภาพใกล้เคียงกัน และตัวควบคุมที่ดีก็ยังคงส่งงานได้ สลับตัวควบคุมเป็นตัวที่แย่กว่า และโมเดลที่ดีที่สุดในโลกก็ยังคงสร้างเอเจนต์ที่ลืมสิ่งที่มันกำลังทำอยู่แบบสุ่ม
ถ้าคุณกำลังสร้างอะไรที่ซับซ้อนกว่าการเรียกเครื่องมือครั้งเดียว ตัวควบคุมคือที่ที่คุณควรใช้เวลาของคุณ โมเดลเป็นส่วนประกอบภายในนั้น
MCP ในเชิงแนวคิด (MCP, conceptually)
อย่าแค่เรียนรู้วิธีเรียก MCP servers เรียนรู้โมเดล การแยกที่ชัดเจนระหว่างความสามารถของเอเจนต์ เครื่องมือ และทรัพยากร ด้วยเรื่องราว auth และ transport ที่ขยายได้ภายใต้ เมื่อคุณเข้าใจแล้ว ทุก "เฟรมเวิร์กการรวมเอเจนต์" อื่นๆ ที่คุณเห็นจะดูเหมือนเวอร์ชันที่แย่กว่าของ MCP และคุณจะประหยัดเวลาในการประเมินแต่ละตัว
Linux Foundation ตอนนี้เป็นผู้ดูแล ทุกผู้ให้บริการโมเดลรายใหญ่สนับสนุน การเปรียบเทียบ "USB-C ของ AI" แม่นยำมากกว่าแดกดันแล้ว
การแซนด์บ็อกซ์เป็นพื้นฐาน (Sandboxing as a primitive)
เอเจนต์การเขียนโค้ดทุกตัวในโปรดักชั่นทำงานในแซนด์บ็อกซ์ เอเจนต์เบราว์เซอร์ทุกตัวถูกโจมตีด้วย indirect prompt injection เอเจนต์แบบ multi-tenant ทุกตัวมีบั๊กการกำหนดขอบเขตสิทธิ์ที่ส่งออกไปในบางจุด ปฏิบัติต่อการแซนด์บ็อกซ์เป็นโครงสร้างพื้นฐานพื้นฐาน ไม่ใช่ฟีเจอร์ที่คุณเพิ่มเมื่อลูกค้าถาม
เรียนรู้พื้นฐาน การแยกกระบวนการ การควบคุม egress เครือข่าย การกำหนดขอบเขตความลับ ขอบเขต auth ระหว่างเอเจนต์และเครื่องมือ ทีมที่ต่อท้ายสิ่งนี้หลังจากรีวิวความปลอดภัยของลูกค้าคือทีมที่เสียดีล ทีมที่สร้างมันตั้งแต่สัปดาห์แรกผ่านการจัดซื้อขององค์กรโดยไม่ต้องกังวล
สิ่งที่ต้องสร้างด้วย
ตัวเลือกเฉพาะ เมษายน 2026 สิ่งเหล่านี้จะเปลี่ยนไป แต่ช้าๆ เลือกอย่างน่าเบื่อที่นี่
Orchestration
LangGraph เป็นค่าเริ่มต้นในการผลิต ประมาณหนึ่งในสามของบริษัทขนาดใหญ่ที่รันเอเจนต์ใช้มัน สิ่งที่เป็นนามธรรมตรงกับรูปร่างที่แท้จริงของระบบเอเจนต์: สถานะที่พิมพ์, ขอบแบบมีเงื่อนไข, เวิร์กโฟลว์ที่ทนทาน, จุดตรวจสอบแบบมนุษย์อยู่ในลูป ข้อเสียคือความ verbose ข้อดีคือความ verbose นั้นตรงกับสิ่งที่คุณต้องควบคุมจริงๆ เมื่อเอเจนต์อยู่ในโปรดักชั่น
ถ้าคุณใช้ TypeScript, Mastra คือตัวเลือกโดยพฤตินัย แบบจำลองทางความคิดที่สะอาดที่สุดในระบบนิเวศนั้น
ถ้าทีมของคุณรัก Pydantic และต้องการ type safety ในฐานะพลเมืองชั้นหนึ่ง Pydantic AI เป็นตัวเลือกกรีนฟิลด์ที่สมเหตุสมผล มันถึง v1.0 ในปลายปี 2025 และโมเมนตัมเป็นจริง
สำหรับงานแบบ provider-native (computer use, voice, real-time) ให้ใช้ Claude Agent SDK หรือ OpenAI Agents SDK ภายใน โหนด LangGraph ของคุณ อย่าพยายามทำให้ตัวใดตัวหนึ่งเป็น orchestrator ระดับบนสุดสำหรับระบบที่ต่างกัน พวกมันถูกปรับให้เหมาะสมสำหรับเลนของพวกมัน
เลเยอร์โปรโตคอล (Protocol layer)
MCP, หยุดแค่นั้น สร้างการรวมเครื่องมือของคุณเป็น MCP servers ใช้การรวมภายนอกในลักษณะเดียวกัน registry ได้ข้ามจุดที่คุณสามารถหาเซิร์ฟเวอร์ได้เกือบทุกครั้งก่อนที่คุณจะต้องสร้าง การเดินสาย plumbing เครื่องมือที่กำหนดเองในปี 2026 จ่ายภาษีโดยไม่มีอะไรตอบแทน
หน่วยความจำ (Memory)
เลือกตามระดับอิสระ ไม่ใช่ตามกระแส
Mem0 สำหรับการปรับแต่งส่วนบุคคลแบบแชท การตั้งค่าผู้ใช้ ประวัติเบาๆ Zep สำหรับระบบสนทนาในการผลิตที่สถานะพัฒนาและคุณต้องการการติดตามเอนทิตี Letta เมื่อเอเจนต์รักษาความสอดคล้องข้ามวันหรือสัปดาห์ของการทำงาน ทีมส่วนใหญ่จะไม่ต้องการสิ่งนี้ ทีมที่ต้องการ ต้องการสิ่งนี้อย่างแน่นอน
ความผิดพลาดคือการเอื้อมถึงเฟรมเวิร์กหน่วยความจำก่อนที่คุณจะมีปัญหาหน่วยความจำ เริ่มต้นด้วยสิ่งที่หน้าต่างบริบทของคุณสามารถเก็บได้บวกกับ vector store เพิ่มระบบหน่วยความจำเมื่อคุณสามารถอธิบายโหมดความล้มเหลวที่มันแก้ไขได้
การสังเกตการณ์และ evals (Observability and evals)
Langfuse เป็นค่าเริ่มต้น OSS โฮสต์เองได้, สัญญาอนุญาต MIT, ครอบคลุม tracing, การกำหนดเวอร์ชันพรอมต์, และ evals LLM-as-judge พื้นฐาน ถ้าคุณเป็นร้าน LangChain อยู่แล้ว, LangSmith จะรวมกันได้แน่นกว่า Braintrust เป็นตัวเลือกที่เหมาะสมสำหรับเวิร์กโฟลว์ eval แบบวิจัยที่มีการเปรียบเทียบอย่างเข้มงวด OpenLLMetry / Traceloop คือคำตอบถ้าคุณต้องการเครื่องมือ OpenTelemetry ที่เป็นกลางต่อผู้ขายในสแต็กแบบหลายภาษา
คุณต้องการทั้ง tracing และ evals Tracing ตอบว่า "เอเจนต์ทำอะไรจริงๆ?" Evals ตอบว่า "เอเจนต์ดีขึ้นหรือแย่ลงกว่าเมื่อวาน?" อย่าส่งโดยไม่มีทั้งสองอย่าง ค่าใช้จ่ายของการทำงานแบบไม่เห็นอะไรเลยนั้นสูงกว่าค่าใช้จ่ายของการเดินสายนี้อย่างถูกต้องในวันแรกถึงสิบเท่า
รันไทม์และแซนด์บ็อกซ์ (Runtime and sandbox)
E2B สำหรับการดำเนินการโค้ดในแซนด์บ็อกซ์ทั่วไป Browserbase (จับคู่กับ Stagehand) สำหรับระบบอัตโนมัติของเบราว์เซอร์ Anthropic Computer Use เมื่อคุณต้องการการควบคุมเดสก์ท็อประดับ OS จริง Modal สำหรับการระเบิดระยะสั้น อย่ารันการดำเนินการโค้ดที่ไม่มีการแซนด์บ็อกซ์ เด็ดขาด รัศมีการระเบิดของเอเจนต์ที่ถูก prompt-injected เพียงตัวเดียวในสภาพแวดล้อมการผลิตของคุณเป็นเรื่องที่คุณไม่อยากเล่า
โมเดล (Models)
การไล่ล่าเกณฑ์มาตรฐานนั้นเหนื่อยและส่วนใหญ่ไม่มีประโยชน์ ในทางปฏิบัติ ในเดือนเมษายน 2026:
Claude Opus 4.7 และ Sonnet 4.6 สำหรับการใช้เครื่องมือที่เชื่อถือได้ ความสอดคล้องหลายขั้นตอน และการกู้คืนความล้มเหลวอย่างสง่างาม Sonnet คือจุดที่คุ้มค่าด้านต้นทุน-ประสิทธิภาพสำหรับเวิร์กโหลดส่วนใหญ่ GPT-5.4 และ 5.5 เมื่อคุณต้องการการใช้เหตุผล CLI/terminal ที่แข็งแกร่งที่สุดหรือคุณอยู่ในโครงสร้างพื้นฐานของ OpenAI Gemini 2.5 และ 3 สำหรับงานที่เน้นบริบทยาวหรือมัลติโมดัลหนัก DeepSeek-V3.2 หรือ Qwen 3.6 เมื่อต้นทุนสำคัญกว่าประสิทธิภาพระดับสูงสุด โดยเฉพาะอย่างยิ่งสำหรับงานที่แคบและกำหนดไว้อย่างดี
ปฏิบัติต่อโมเดลเป็นสิ่งที่สลับกันได้ ถ้าเอเจนต์ของคุณทำงานกับโมเดลเดียวเท่านั้น นั่นคือกลิ่น ไม่ใช่คูเมือง ใช้ evals เพื่อตัดสินใจว่าจะปรับใช้อะไร ประเมินใหม่ทุกไตรมาส ไม่ใช่ทุกสัปดาห์
สิ่งที่ควรข้าม
คุณจะถูกบอกให้เรียนรู้และสร้างด้วยทั้งหมดนี้ คุณไม่จำเป็นต้องทำ ค่าใช้จ่ายในการข้ามนั้นต่ำ เวลาที่ประหยัดได้นั้นมาก
AutoGen และ AG2 สำหรับการผลิต เฟรมเวิร์กของ Microsoft ย้ายไปบำรุงรักษาชุมชน การปล่อยหยุดชะงัก สิ่งที่เป็นนามธรรมไม่ตรงกับสิ่งที่ทีมผลิตต้องการจริงๆ ใช้ได้ดีสำหรับการสำรวจทางวิชาการ อย่าผูกผลิตภัณฑ์กับมัน
CrewAI สำหรับการสร้างผลิตใหม่ มันมีอยู่ทุกที่เพราะมันสาธิตได้ง่าย วิศวกรที่สร้างระบบจริงได้ย้ายออกจากมันแล้ว ใช้มันสำหรับต้นแบบถ้าคุณต้องการ อย่าผูกมัดกับมัน
Microsoft Semantic Kernel เว้นแต่คุณจะถูกล็อคอยู่ในสแต็กองค์กรของ Microsoft และผู้ซื้อของคุณสนใจว่าคุณเป็น มันไม่ใช่ที่ที่ระบบนิเวศกำลังมุ่งหน้าไป
DSPy เว้นแต่คุณกำลังปรับโปรแกรมพรอมต์ให้เหมาะสมในวงกว้างโดยเฉพาะ คุณค่าทางปรัชญา ผู้ชมเฉพาะ ไม่ใช่เฟรมเวิร์กเอเจนต์ทั่วไป อย่าเลือกมันเป็นหนึ่งเดียว
เอเจนต์เขียนโค้ดแบบสแตนด์อโลนเป็นตัวเลือกสถาปัตยกรรมของคุณ Code-as-action เป็นงานวิจัยที่น่าสนใจ มันยังไม่ใช่รูปแบบค่าเริ่มต้นในการผลิต และคุณจะต่อสู้กับการต่อสู้ด้านเครื่องมือและความปลอดภัยที่คู่แข่งของคุณไม่มี
การนำเสนอ "เอเจนต์อัตโนมัติ" สายเลือด AutoGPT และ BabyAGI ตายแล้วในรูปแบบผลิตภัณฑ์ กรอบที่ซื่อสัตย์ที่อุตสาหกรรมตกลงกันคือ "วิศวกรรมเอเจนต์": ภายใต้การดูแล มีขอบเขต ประเมินผล ใครก็ตามที่ยังคงขายเอเจนต์อัตโนมัติแบบ deploy-and-forget ในปี 2026 กำลังขายปี 2023 ให้คุณ
ร้านค้าแอปและตลาดเอเจนต์ สัญญาตั้งแต่ปี 2023 ไม่เคยได้รับแรงฉุดในองค์กร องค์กรไม่ซื้อเอเจนต์ที่สร้างไว้ล่วงหน้าทั่วไป พวกเขาซื้อเอเจนต์แนวตั้งที่เชื่อมโยงกับผลลัพธ์ หรือพวกเขาสร้างเอง อย่าจัดโครงสร้างธุรกิจของคุณรอบความฝันของร้านค้าแอป
แพลตฟอร์มเอเจนต์องค์กรแนวนอน "สร้างเอเจนต์ใดก็ได้" ในฐานะลูกค้า (Google Agentspace, AWS Bedrock Agents, Microsoft Copilot Studio tier) พวกมันจะมีประโยชน์ในที่สุด ตอนนี้พวกมันสับสน ส่งช้า และคณิตศาสตร์ซื้อ-เทียบกับ-สร้างยังคงสนับสนุนการสร้างเอเจนต์แคบๆ ด้วยตัวเองหรือซื้อเอเจนต์แนวตั้ง Salesforce Agentforce และ ServiceNow Now Assist เป็นข้อยกเว้นเพราะพวกเขาชนะโดยการฝังอยู่ในระบบเวิร์กโฟลว์ที่คุณใช้อยู่แล้ว
การไล่ล่าอันดับ SWE-bench และ OSWorld นักวิจัยของ Berkeley บันทึกไว้ตลอดปี 2025 ว่าเกณฑ์มาตรฐานสาธารณะเกือบทุกตัวสามารถถูกเอาเปรียบได้โดยไม่ต้องแก้ปัญหาพื้นฐาน ตอนนี้ทีมใช้ Terminal-Bench 2.0 และ evals ภายในของตัวเองเป็นสัญญาณจริง ปฏิบัติต่อการก้าวกระโดดของตัวเลขเดียวด้วยความสงสัยเป็นค่าเริ่มต้น
สถาปัตยกรรม multi-agent แบบขนานที่ไร้เดียงสา เอเจนต์ห้าตัวแชทผ่านหน่วยความจำที่ใช้ร่วมกันดูน่าประทับใจในเดโมและพังทลายในโปรดักชั่น ถ้าคุณไม่สามารถวาดไดอะแกรม orchestrator-subagent ที่สะอาดพร้อมขอบเขตอ่าน/เขียนบนผ้าเช็ดปากได้ อย่าส่งมัน
ราคา SaaS ต่อที่นั่งสำหรับผลิตภัณฑ์เอเจนต์ใหม่ ตลาดย้ายไปตามผลลัพธ์และการใช้งานแล้ว การตั้งราคาต่อที่นั่งทำให้เงินหายไปและส่งสัญญาณให้ผู้ซื้อว่าคุณไม่ไว้วางใจผลิตภัณฑ์ของคุณเองในการส่งมอบผลลัพธ์
เฟรมเวิร์กถัดไปที่คุณเห็นบน Hacker News ในสัปดาห์นี้ รอหกเดือน ถ้ามันยังคงสำคัญ มันจะชัดเจน ถ้ามันไม่ คุณประหยัดการย้ายระบบได้
วิธีเคลื่อนไหวจริงๆ
ถ้าคุณกำลังพยายามนำเอเจนต์มาใช้ ไม่ใช่แค่ตามให้ทัน ลำดับนี้ใช้ได้ผล มันน่าเบื่อ มันใช้ได้ผล
เลือกผลลัพธ์เดียวที่สำคัญอยู่แล้ว ไม่ใช่ moonshot ไม่ใช่โครงการ "แพลตฟอร์มเอเจนต์" แนวนอน บางสิ่งที่วัดได้ซึ่งธุรกิจของคุณใส่ใจอยู่แล้ว การเปลี่ยนเส้นทางตั๋วสนับสนุน การร่างการตรวจสอบทางกฎหมายรอบแรก การคัดกรองลีดที่เข้ามา การสร้างรายงานประจำเดือน เอเจนต์ประสบความสำเร็จเมื่อผลลัพธ์นั้นเคลื่อนที่ นี่กลายเป็นเป้าหมาย eval ของคุณในวันแรก
เหตุผลที่ขั้นตอนนี้สำคัญกว่าสิ่งอื่นใดคือมันจำกัดทุกการตัดสินใจที่ตามมา ด้วยผลลัพธ์ที่เฉพาะเจาะจง คำถามของ "เฟรมเวิร์กไหน" หยุดเป็นเรื่องปรัชญา คุณเลือกอันที่ส่งผลลัพธ์ของคุณเร็วที่สุด คำถามของ "โมเดลไหน" หยุดเป็นข้อโต้แย้งเรื่องเกณฑ์มาตรฐาน คุณเลือกอันที่ evals ของคุณบอกว่าใช้ได้กับงานเฉพาะนี้ คำถามของ "เราต้องการหน่วยความจำ / subagents / ตัวควบคุมที่กำหนดเองหรือไม่" หยุดเป็นการทดลองทางความคิด คุณเพิ่มเฉพาะสิ่งที่โหมดความล้มเหลวเฉพาะของคุณต้องการ ทีมที่ข้ามขั้นตอนนี้ลงเอยด้วยการสร้างแพลตฟอร์มแนวนอนที่ไม่มีใครขอ ทีมที่ให้ความสำคัญกับมันลงเอยด้วยการส่งเอเจนต์แคบๆ ตัวเดียวที่จ่ายค่าตัวเองในหนึ่งไตรมาส และเอเจนต์ที่ส่งตัวเดียวนั้นสอนพวกเขาเกี่ยวกับสาขานี้มากกว่าการอ่านสองปี
ตั้งค่า tracing และ evals ก่อนที่คุณจะส่งอะไร เลือก Langfuse หรือ LangSmith เดินสายมัน สร้างชุดข้อมูลทองคำขนาดเล็กด้วยมือถ้าจำเป็น ตัวอย่างที่ติดป้ายห้าสิบตัวอย่างก็เพียงพอที่จะเริ่มต้น คุณจะไม่สามารถปรับปรุงสิ่งที่คุณไม่สามารถวัดได้ ค่าใช้จ่ายในการสร้างสิ่งนี้ทีหลังมีค่าประมาณ 10 เท่าของค่าใช้จ่ายในการสร้างตอนนี้
เริ่มต้นด้วยลูปเอเจนต์เดี่ยว เลือก LangGraph หรือ Pydantic AI เลือก Claude Sonnet 4.6 หรือ GPT-5 เป็นโมเดล ให้เอเจนต์มีเครื่องมือที่ออกแบบมาอย่างดีสามถึงเจ็ดตัว ให้ไฟล์ระบบหรือฐานข้อมูลเป็นสถานะ ส่งให้ผู้ชมกลุ่มเล็ก ดู traces
ปฏิบัติต่อเอเจนต์เป็นผลิตภัณฑ์ ไม่ใช่โครงการ มันจะล้มเหลวในแบบที่คุณไม่ได้คาดการณ์ ความล้มเหลวเหล่านั้นคือโรดแมปของคุณ สร้างชุดการถดถอยจาก traces การผลิตจริง ทุกการเปลี่ยนแปลงพรอมต์ ทุกการสลับโมเดล ทุกการเปลี่ยนแปลงเครื่องมือต้องผ่าน evals ก่อนการปรับใช้ นี่คือจุดที่ทีมส่วนใหญ่ลงทุนน้อยเกินไป นี่คือจุดที่ความน่าเชื่อถือส่วนใหญ่มาจาก
เพิ่มขอบเขตเมื่อคุณได้รับมันเท่านั้น Subagent เข้ามาเมื่อบริบทเป็นคอขวด เฟรมเวิร์กหน่วยความจำเข้ามาเมื่อบริบทหน้าต่างเดียวไม่สามารถเก็บสิ่งที่คุณต้องการได้ Computer use หรือ browser use เข้ามาเมื่อ API พื้นฐานไม่มีจริงๆ อย่าสถาปัตยกรรมล่วงหน้าเหล่านี้ ปล่อยให้โหมดความล้มเหลวดึงพวกมันเข้ามา
เลือกโครงสร้างพื้นฐานที่น่าเบื่อ MCP สำหรับเครื่องมือ E2B หรือ Browserbase สำหรับแซนด์บ็อกซ์ Postgres หรือที่เก็บข้อมูลใดก็ตามที่คุณรันอยู่แล้วสำหรับสถานะ สแต็ก auth และการสังเกตการณ์ที่มีอยู่ของคุณ โครงสร้างพื้นฐานที่แปลกใหม่แทบจะไม่ใช่ชัยชนะ ระเบียบวินัยคือ
ดูเศรษฐศาสตร์ต่อหน่วยของคุณตั้งแต่วันแรก ต้นทุนต่อการกระทำ อัตราการตีแคช ต้นทุนลูปลองใหม่ การกระจายการเรียกโมเดล เอเจนต์ดูถูกใน PoC และระเบิดที่สเกล 100x เว้นแต่คุณจะวัดต้นทุนต่อผลลัพธ์ตั้งแต่เริ่มต้น PoC ที่ $0.50/รันกลายเป็น $50K/เดือนที่ปริมาณปานกลาง ทีมที่ไม่เห็นมันมา จะได้พบกับ CFO ที่พวกเขาไม่ชอบ
ประเมินโมเดลใหม่ทุกไตรมาส ไม่ใช่ทุกสัปดาห์ ล็อคอินเป็นเวลาหนึ่งไตรมาส เมื่อสิ้นสุดไตรมาส รันชุด eval ของคุณกับ frontier ปัจจุบันและสลับถ้าข้อมูลบอกให้สลับ คุณจะได้รับประโยชน์จากการปรับปรุงโมเดลโดยไม่มีความโกลาหลของการไล่ล่าทุกการปล่อย
การอ่านกระแสน้ำ
สัญญาณที่เป็นรูปธรรมว่าบางสิ่งเป็นสัญญาณ:
สิ่งที่ควรจับตามอง
ทีมวิศวกรรมที่น่าเชื่อถือเขียน postmortem พร้อมตัวเลข ไม่ใช่แค่การอ้างว่ามีการนำไปใช้ มันเป็น primitive (protocol, pattern, infra) ไม่ใช่ wrapper หรือ bundle มันทำงานร่วมกับสิ่งที่คุณใช้อยู่แล้วแทนที่จะมาแทนที่ การนำเสนออธิบาย failure mode ที่มันแก้ไข ไม่ใช่ความสามารถที่มันเปิดใช้งาน มันมีมานานพอที่จะมีบล็อกโพสต์ "อะไรที่ใช้ไม่ได้ผล" เขียนถึงมัน
สัญญาณที่บ่งบอกว่าบางอย่างเป็น noise:
วิดีโอสาธิตที่ไม่มีกรณีศึกษาการผลิตจริงหลังจากสามสิบวัน Benchmark leaps ที่ดูดีเกินจริง การนำเสนอที่ใช้คำว่า "autonomous," "agent OS," หรือ "build any agent" โดยไม่มีคำอธิบายเพิ่มเติม Framework ที่เอกสารสมมติว่าคุณจะทิ้ง tracing, auth, และ config ที่มีอยู่ Star count ที่เพิ่มขึ้นอย่างรวดเร็วโดยไม่มี commits, releases, และ contributors เพิ่มขึ้นตาม Twitter velocity ที่ไม่มี GitHub velocity
นิสัยประจำสัปดาห์ที่มีประโยชน์: จองเวลาสามสิบนาทีในวันศุกร์สำหรับวงการนี้ อ่านสามอย่าง บล็อกวิศวกรรมของ Anthropic บันทึกของ Simon Willison Latent Space อ่าน postmortem หนึ่งหรือสองชิ้นถ้ามี ข้ามทุกอย่างอื่นในสัปดาห์นั้น คุณจะรู้ว่าสิ่งไหนสำคัญ
สิ่งที่ควรจับตามอง
สิ่งที่ควรให้ความสนใจในสองไตรมาสถัดไป ไม่ใช่เพราะมันเป็นความสำเร็จที่แน่นอน แต่เพราะคำถามที่ว่า "นี่คือสัญญาณหรือไม่?" ยังไม่ได้รับการตอบอย่างสมบูรณ์:
โมเดล parallel forking ของ Replit Agent 4 ความพยายามจริงจังครั้งแรกที่ "multiple agents ทำงานแบบขนาน" โดยไม่สะดุดกับ shared state ถ้ามันใช้ได้ในระดับใหญ่ orchestrator-subagent default อาจเปลี่ยนไป
ความสมบูรณ์ของ outcome-based pricing เส้นทางรายได้ของ Sierra และ Harvey ยืนยันว่ามันใช้ได้ใน verticals แคบๆ คำถามคือมันจะขยายไปใช้นอกเหนือจากนั้นได้หรือไม่ หรือจะยังคงเป็นโมเดลเฉพาะ vertical
Skills ในฐานะ packaging layer การแพร่กระจายของ AGENTS.md และ skills directories ทั่ว GitHub แสดงให้เห็นถึงวิธีการใหม่ในการบรรจุความสามารถของ agent คำถามที่ยังเปิดอยู่คือมันจะกลายเป็นมาตรฐานแบบที่ MCP ทำสำหรับ tools หรือไม่
Claude Code's April 2026 quality regression และ postmortem Agent ชั้นนำของอุตสาหกรรมมีประสิทธิภาพลดลง 47% และถูกจับได้โดยผู้ใช้ก่อนที่การตรวจสอบภายในจะจับได้ นั่นคือบทเรียนเกี่ยวกับความยังไม่สมบูรณ์ของ production agent eval practices แม้แต่ในหมู่ผู้นำ ถ้าสิ่งนี้กระตุ้นให้เกิดการลงทุนใน online evals ที่ดีขึ้นทั่วทั้งอุตสาหกรรม การแก้ไขนี้ก็เป็นสิ่งที่ดี
Voice ในฐานะ support surface เริ่มต้น ช่องทาง voice ของ Sierra แซงหน้า text ในปลายปี 2025 ถ้ารูปแบบนี้เกิดขึ้นใน verticals อื่นๆ ข้อจำกัดในการออกแบบ (latency, interruption, real-time tool use) จะกลายเป็นลำดับความสำคัญอันดับแรก และสถาปัตยกรรมปัจจุบันจำนวนมากต้องได้รับการปรับปรุงใหม่
Open-model agent capability ที่ปิดช่องว่าง DeepSeek-V3.2 พร้อม native thinking-into-tool-use Qwen 3.6 ภาพรวม open landscape Cost-performance สำหรับงาน agent แคบๆ กำลังเปลี่ยนแปลง closed-source default ไม่ใช่สิ่งถาวร
แต่ละอย่างมีคำตอบที่ชัดเจนสำหรับ "ฉันต้องเห็นอะไรในหกเดือนถึงจะเชื่อ" นั่นคือการทดสอบ ติดตามคำตอบ ไม่ใช่การประกาศ
การเดิมพันที่ไม่ธรรมดา
ทุก framework ที่คุณไม่นำมาใช้คือ migration ที่คุณไม่ต้องทำ ทุก benchmark ที่คุณไม่ไล่ตามคือไตรมาสแห่งโฟกัสที่คุณรักษาไว้ บริษัทที่ชนะในรอบนี้ (Sierra, Harvey, Cursor ในโดเมนของตน) เลือกเป้าหมายที่แคบ สร้างวินัยที่น่าเบื่อ และปล่อยให้ noise ในวงการผ่านไป
เส้นทางเดิมคือ: เลือก stack, เชี่ยวชาญมันเป็นเวลาหลายปี, ไต่บันไดขึ้นไป สิ่งนั้นใช้ได้เมื่อ stack มีเสถียรภาพเป็นเวลาหนึ่งทศวรรษ ตอนนี้ stack เปลี่ยนทุกไตรมาส คนที่ชนะหยุดปรับให้เหมาะสมกับความเชี่ยวชาญใน stack และเริ่มปรับให้เหมาะสมกับ taste, primitives, และ ship velocity พวกเขาสร้างสิ่งเล็กๆ ในที่สาธารณะ พวกเขาเรียนรู้โดยการ ship พวกเขาถูกดึงเข้าไปในห้องโดยสิ่งที่พวกเขาสร้างไว้แล้ว ข้อมูลประจำตัวคือ artifact
ลองคิดดูสักครู่ เพราะนี่คือประเด็นที่แท้จริงของทั้งหมดนี้ พวกเราส่วนใหญ่ถูกเลี้ยงดูมาด้วยโมเดลการทำงานที่สมมติว่าโลกหยุดนิ่งนานพอที่ข้อมูลประจำตัวจะทบต้น คุณไปโรงเรียน คุณได้รับปริญญา คุณไต่บันได สองปีที่นี่ สามปีที่นั่น และในที่สุด resume ก็กลายเป็นสิ่งที่เปิดประตู เครื่องจักรทั้งหมดนั้นสมมติว่ามีอุตสาหกรรมที่มั่นคงอยู่อีกด้านหนึ่ง
ตอนนี้พื้นที่ agent ไม่มีด้านที่มั่นคงอีกด้านหนึ่งในขณะนี้ บริษัทที่คุณอาจอยากทำงานด้วยมีอายุหกเดือน Framework ที่พวกเขาสร้างขึ้นมีอายุสิบแปดเดือน Protocol ที่อยู่ภายใต้พวกเขามีอายุสองปี ครึ่งหนึ่งของโพสต์ที่ถูกอ้างถึงมากที่สุดในสาขานี้เขียนโดยคนที่ไม่ได้อยู่ในสาขานี้เมื่อสามปีก่อน ไม่มีบันไดให้ไต่เพราะตัวอาคารเปลี่ยนชั้นอยู่ตลอดเวลา สิ่งที่เหลืออยู่ เมื่อบันไดใช้ไม่ได้ คือวิธีการที่เก่ากว่ามาก: สร้างบางอย่าง วางไว้บนอินเทอร์เน็ต ปล่อยให้งานแนะนำคุณ มันเป็นเส้นทางที่ไม่ธรรมดาเพราะมันไม่สนใจระบบการรับรอง มันยังเป็นเส้นทางเดียวที่ทบต้นในสาขาที่เคลื่อนที่
นี่คือสิ่งที่ยุคสมัยนี้ดูเหมือนจากภายใน แม้แต่ยักษ์ใหญ่ก็ยังทำซ้ำในที่สาธารณะ ship regressions, เขียน postmortems, patch แบบเรียลไทม์ ทีมที่ ship สิ่งที่น่าสนใจที่สุดในปีนี้รวมถึงคนที่ไม่ได้อยู่ในสาขานี้เมื่อสิบแปดเดือนก่อน คนที่ไม่ใช่นักเขียนโค้ดกำลังจับคู่กับ agents และ ship ซอฟต์แวร์จริง PhDs กำลังถูกแซงโดย builders ที่เลือก primitives ที่ถูกต้องและเริ่มลงมือทำ ประตูเปิดอยู่ คนส่วนใหญ่ยังคงพยายามหาใบสมัคร
ทักษะที่คุณต้องพัฒนาในตอนนี้ไม่ใช่ "agents" มันคือวินัยในการหาว่างานไหนที่ทบต้นในสาขาที่พื้นผิวเปลี่ยนแปลงตลอดเวลา Context engineering ทบต้น Tool design ทบต้น Orchestrator-subagent pattern ทบต้น Eval discipline ทบต้น Harness mindset ทบต้น การรู้ API ของ framework ที่เปิดตัวเมื่อวันอังคารไม่ทบต้น เมื่อคุณแยกแยะสิ่งเหล่านี้ออกได้ กระแสการเปิดตัวรายสัปดาห์จะหยุดรู้สึกเหมือนแรงกดดันและเริ่มรู้สึกเหมือน noise ที่คุณสามารถเพิกเฉยได้
คุณไม่จำเป็นต้องเรียนรู้ทุกอย่าง คุณต้องเรียนรู้สิ่งที่ทบต้นและข้ามสิ่งที่ไม่ได้ผล เลือกผลลัพธ์หนึ่งอย่าง ตั้งค่า tracing และ evals ก่อนที่คุณจะ ship ใช้ LangGraph หรือสิ่งที่เทียบเท่าของทีมคุณ ใช้ MCP Sandbox runtime ของคุณ Default เป็น single-agent เพิ่ม scope เมื่อ failure modes ดึงมันเข้ามา ประเมิน models ทุกไตรมาส อ่านสามอย่างในวันศุกร์
นั่นคือ playbook ที่เหลือคือ taste, ship velocity, และความอดทนที่จะไม่ไล่ตามสิ่งที่ไม่สำคัญ สร้างสิ่งต่างๆ วางไว้บนอินเทอร์เน็ต ยุคสมัยนี้ให้รางวัลกับคนที่สร้างสิ่งต่างๆ มากกว่าคนที่สามารถอธิบายสิ่งต่างๆ ไม่เคยมีช่วงเวลาที่ดีกว่านี้ในการเป็นคนที่สร้าง
