หลังจากที่ Agent รับช่วงต่องาน สิ่งแรกที่ต้องกระชับคือหน่วยงาน

ฉันได้อ่านการอภิปรายมากมายเกี่ยวกับ Agent เมื่อเร็วๆ นี้ และสุดท้ายฉันก็กลับมาถามคำถามเดิมเสมอ: ใครควรมอบงานให้ ควรบรรจุอย่างไรก่อนส่งมอบ และจะยอมรับอย่างไรหลังจากการส่งคืน เมื่อปัญหานี้เกิดขึ้นในโครงการ สิ่งแรกที่เพิ่มขึ้นมักจะไม่ใช่ต้นทุนของแบบจำลอง แต่เป็นความซับซ้อนของหน่วยงาน หากงานถูกตัดใหญ่เกินไป แบบจำลองจะปรากฏ “ราวกับว่าสามารถทำได้”; ปัญหาที่แท้จริงมักอยู่ที่การย้อนกลับ การทำซ้ำ และการยอมรับ

หน่วยงานต้องสามารถได้รับการยอมรับก่อน

ในช่วงไม่กี่วันที่ผ่านมา หลังจากที่รวบรวมบันทึกที่กระจัดกระจายของ Martin Fowler และการอภิปรายหลายครั้งที่ Thoughtworks Future of Software Development Retreat ความรู้สึกที่ชัดเจนที่สุดคือการสนทนาในการประชุมกระจัดกระจายอย่างผิวเผิน แต่จริงๆ แล้วภายใต้การสนทนานั้นวนเวียนอยู่กับสิ่งเดียวเท่านั้น นั่นคือการมอบงานชิ้นใหญ่ให้กับ Agent

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

นี่คือสาเหตุว่าทำไมถึงกล่าวถึงบังเหียนซ้ำแล้วซ้ำอีก การจัดการบริบท เซ็นเซอร์คำนวณ การทดสอบตามคุณสมบัติ วิธีการอย่างเป็นทางการ สิ่งเหล่านี้ฟังดูเหมือนเครื่องมือเพิ่มเติม แต่จริงๆ แล้วพวกมันรวบรวมหน่วยงานต่างๆ บางคนควบคุม agents.md ให้น้อยกว่า 200 บรรทัด ไม่ใช่เพื่อรักษาความเรียบร้อยในรูปแบบ แต่เพื่อบังคับให้ระบบรับเฉพาะข้อมูลส่วนนั้นที่มีประโยชน์จริงๆ และสามารถตรวจสอบได้จริงๆ บริบทหลวมเกินไป แน่นอนว่า Agent สามารถทำงานได้ แต่หลังจากการวิ่งแล้ว ไม่มีใครรู้ว่ามันกลืนกินข้อจำกัดชั้นไหนไป

การโฮสต์ด้วยตนเองช่วยเพิ่มพื้นที่การควบคุม

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

ค่าใช้จ่ายดังกล่าวมักถูกประเมินต่ำไป ในตอนแรกหลายทีมมุ่งเน้นไปที่ “ว่าแบบจำลองนั้นแข็งแกร่งกว่าหรือไม่” แต่ต่อมาได้ค้นพบว่าสิ่งที่กินเวลาจริงๆ คือการถ่ายโอนหน่วยงานที่มีความเสถียรระหว่างแบบจำลองต่างๆ เมื่อใดควรใช้โมเดลขนาดใหญ่ เมื่อใดควรใช้โมเดลแบบเบา และเมื่อใดควรใช้โมเดลเฉพาะที่ มันไม่ได้ขึ้นอยู่กับความชอบทางวาจา แต่ขึ้นอยู่กับชั้นของพื้นผิวการควบคุมที่สามารถใช้เพื่อเบี่ยงเบนและปกปิดได้ หากไม่มีสิ่งเหล่านี้ การโฮสต์ด้วยตนเองจะเปลี่ยนจาก “การริเริ่ม” ไปสู่ ​​"การก้าวข้ามความซับซ้อนในการดำเนินงานและการบำรุงรักษาด้วยตนเอง"

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

การยอมรับและเป้าหมายไม่สามารถจ้างจากภายนอกได้

เพลง “Bring me a Rock” ของแซม รูบี้ นำเสนออีกประเด็นหนึ่งให้กระจ่าง การให้งานแก่โมเดลนั้นเทียบเท่ากับการเพิ่มตัวดำเนินการ ความรับผิดชอบไม่หายไป ผู้จัดการสามารถใช้ LLM ในการสำรวจได้ และพวกเขาสามารถปล่อยให้มันพ่นวิธีแก้ปัญหาของผู้สมัครออกมาก่อน แต่เกณฑ์การยอมรับขั้นสุดท้ายยังต้องตกไปอยู่ในมือของมนุษย์ เป้าหมายที่ซ่อนอยู่นั้นลำบากที่สุด สิทธิ์ ความเป็นส่วนตัว การดำเนินการทำลายล้าง และการรั่วไหลของบริบทมักไม่รวมอยู่ในข้อกำหนดดั้งเดิม

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

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

ประสบการณ์และทักษะการอ่านยังคงดีขึ้น

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

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

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