ตู้กระจกในห้องทดลองมืด ข้างในมีอุปกรณ์และท่อทองเหลือง ด้านหน้ามีโต๊ะทำงานและสายไฟ สื่อถึงการให้ AI รันโค้ดในพื้นที่ที่ควบคุมได้

Strands Python 1.60.0 ให้ AI รันโค้ดได้ แต่ทีมต้องคุมสิทธิ์และข้อมูลที่แชร์

น้องกายEngineering

Strands Agents SDK Python รุ่น 1.60.0 เพิ่มเครื่องมือให้ผู้ช่วย AI รันโค้ด Python ได้ แปลว่าผู้ช่วยลงมือประมวลผลด้วยโปรแกรมได้โดยตรง ตามบันทึกการออกรุ่นบน GitHub วันที่ 12 ต.ค. ครับ แต่ขอบเขตว่าโปรแกรมนั้นแตะไฟล์อะไรได้ เป็นเรื่องที่ทีมสร้างผู้ช่วยต้องตรวจเอง

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

สรุป 30 วินาที: เกิดอะไรขึ้น

ชื่อ SDK หมายถึงชุดเครื่องมือสำหรับนักพัฒนานำไปสร้างผู้ช่วย AI ส่วน agent คือผู้ช่วยที่เรียกใช้เครื่องมือเพื่อลงมือทำงานได้ เอกสาร Strands Quickstart ระบุว่า Strands ทำงานอยู่ในโปรแกรมของทีมเอง รองรับทั้ง Python และ TypeScript ซึ่งเป็นภาษาสำหรับเขียนโปรแกรม

ของใหม่ที่เกี่ยวกับข่าวนี้คือ python_repl เครื่องมือรัน Python ที่โครงการจัดมาให้ ตามข้อเสนอแก้โค้ด หรือ PR ของเครื่องมือนี้ มันส่งโค้ดไปทำงานผ่านระบบ sandbox ของผู้ช่วย คำว่า sandbox หมายถึงสภาพแวดล้อมสำหรับรันงาน แต่ต้องดูต่อว่าแบบที่เลือกแยกจากเครื่องจริงแค่ไหน

อีกเรื่องคือ stash พื้นที่เก็บข้อมูลบริบทที่ย้ายออกจากบทสนทนา เพื่อให้เรียกกลับมาใช้ภายหลัง PR shared stash เปิดทางให้ผู้ช่วยที่ร่วมงานกันอ่านข้อมูลชุดเดียวกันได้ เมื่อผู้เรียกตั้งพื้นที่เก็บร่วมไว้อย่างชัดเจน แต่พฤติกรรมใหม่อาจทำให้อ่านข้อมูลที่เก็บตามตำแหน่งเดิมไม่เจอ

บันทึกยังระบุงานด้านการติดตามระบบและการแก้ปัญหาผู้ให้บริการโมเดลหลายราย อย่างไรก็ตาม release notes บอกเองว่าร่างอัตโนมัติจากรายการแก้โค้ด และมีรายการฝั่ง TypeScript ปะปนอยู่ด้วย จึงต้องอ่านขอบเขตแต่ละรายการก่อนสรุปว่า Python ได้ทุกอย่าง

ทำไมเรื่องนี้เกี่ยวกับคุณ

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

เอกสาร Quickstart ย้ำว่า Strands เป็นไลบรารี หรือส่วนประกอบที่ใส่ในโปรแกรม ไม่ใช่แพลตฟอร์มสำเร็จรูปที่มีระบบควบคุมกลาง ฐานข้อมูล และตัวจัดตารางให้ทั้งหมด การนำไปใช้ในองค์กรจึงยังต้องมีคนดูแลสภาพแวดล้อมและการจัดเก็บข้อมูลของระบบนั้น

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

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

ทำงานยังไง

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

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

เหตุผลที่ต้องตรวจการล็อกดังกล่าวมาจากรีวิวใน PR เดียวกัน ผู้รีวิว strandly-the-agent ระบุว่าแบบใหม่ทำงานบนเครื่องโฮสต์โดยค่าเริ่มต้น โฮสต์คือเครื่องที่รันโปรแกรมของเราอยู่ การมีคำว่า sandbox ในชื่อส่วนประกอบจึงยังไม่ใช่หลักฐานว่าได้แยกงานออกจากเครื่องนั้นแล้ว

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

ศัพท์ caller-scoped storage view หมายถึงมุมมองพื้นที่จัดเก็บที่ผู้เรียกกำหนดขอบเขตไว้เอง ในPR shared stash การตั้ง storage.namespace คือการเลือกพื้นที่ย่อยนั้น หากส่งให้ stash โดยตรง ระบบใหม่จะใช้พื้นที่ที่เลือกเป็นจุดเริ่มเก็บข้อมูล ไม่เติมชั้นแยกตามผู้ช่วยและช่วงการทำงานเหมือนเดิม

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

จุดหักมุม: อ่านข้อมูลร่วมได้ แต่ลบงานแล้วข้อมูลยังอยู่

แต่การทำงานร่วมกันสะดวกขึ้น มีผลต่อการลบข้อมูลด้วยครับ PR shared stash ระบุว่าลบ session หรือช่วงการทำงานแล้ว พื้นที่ stash ที่แชร์จะยังอยู่ เพราะพื้นที่นั้นอาจมีข้อมูลที่ช่วงการทำงานอื่นใช้อยู่ ผู้เรียกต้องดูแลวงจรเก็บและลบเอง

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

เรื่องเงิน / ผลกระทบ

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

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

สำหรับการติดตามงาน รุ่นนี้ระบุการส่งต่อ OTel baggage ใน Python ตามrelease notes OTel ย่อจาก OpenTelemetry ซึ่งเป็นระบบติดตามการทำงาน ส่วน baggage คือข้อมูลประกอบที่ส่งต่อไปตามการทำงานของระบบ ประกาศสั้นนี้ยังไม่บอกว่าต้องตั้งค่าอะไรบ้าง จึงไม่ควรสัญญาว่าอัปเดตแล้วตามปัญหาได้ครบเอง

อีกชื่อคือ auxModel โมเดลสำหรับงานย่อยหรือการเรียกเสริม release notes ระบุรายการนี้ว่าเป็นการย้ายความสามารถมาฝั่ง TypeScript และมีรายการเอกสารของ aux_model กับ auxModel ด้วย แต่แหล่งชุดนี้ไม่มีรายละเอียดการตั้งค่าครบ จึงยังบอกไม่ได้ว่าการแยกโมเดลจะลดบิลให้ทีมคุณเท่าไร

ด้านการแก้ปัญหา บันทึกรุ่น ระบุการเพิ่มขีดจำกัด context window ของ Haiku 5.5 แปลว่ามีการกำหนดขอบเขตข้อมูลที่โมเดลอ่านได้ในคราวเดียว แต่ไม่ได้ให้ค่าขนาดไว้ อีกสองรายการคือจัดรูปแบบข้อมูลวิดีโอของ Gemini และอ่านข้อมูลการใช้งาน OpenAI จากส่วนตอบกลับที่ระบุการจบคำตอบ ทีมที่ใช้บริการเหล่านี้ควรตรวจกรณีเดิมของตนก่อนรับรองผล

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

ฝั่งที่เห็นประโยชน์ คือผู้เสนอ PR tummon ซึ่งอธิบายว่าผู้ช่วยที่ร่วมงานกันควรอ่านบริบทที่อีกตัวเก็บไว้ได้ ส่วน lizradway ให้ความเห็นว่าแนวทางดูดีและขอปรับรายละเอียดบางจุดในPR shared stash นี่เป็นเสียงจากโครงการเอง ไม่ใช่ผลรับรองของผู้ใช้ภายนอกครับ

ฝั่งทักท้วง คือผู้รีวิวบัญชี strandly-the-agent ซึ่งตั้งคำถามว่าเหตุใดเลือกวิธีที่เปลี่ยนพฤติกรรมเดิม ทั้งที่มีข้อเสนออีกแบบให้แต่ละผู้ช่วยเขียนแยกกัน แล้วขยายขอบเขตการอ่าน รีวิวในPR shared stash จัดประเด็นนี้เป็นคำถามการออกแบบที่ไม่ขวางการเปลี่ยนแปลง จึงไม่ควรเล่าว่าเป็นข้อสรุปว่าโค้ดใหม่ใช้ไม่ได้

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

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

ผู้รีวิว strandly-the-agent ยังตั้งคำถามเรื่องชื่อ python_repl เพราะผู้ย้ายจากเครื่องมือเดิมอาจคาดว่าตัวแปรคงอยู่ต่อ และตั้งคำถามเรื่องไม่มีเพดานผลลัพธ์กับการรันบนโฮสต์ในPR ขณะเดียวกันรีวิวหลังการแก้ยืนยันว่าการส่งผลลัพธ์บางส่วนเมื่อหมดเวลาได้รับการทดสอบแล้ว ข้อเท็จจริงเหล่านี้บอกพฤติกรรมบางส่วน แต่ไม่ใช่คำรับรองความปลอดภัยทุกสภาพแวดล้อม

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

แล้วเราควรทำอะไร

ขั้นตอนต่อไปนี้เป็นคำแนะนำสำหรับตรวจรับงาน ไม่ใช่รายงานว่าผมทดสอบแล้วครับ โดยตั้งต้นจากพฤติกรรมใน PR python_repl และการเปลี่ยนพื้นที่เก็บใน PR shared stash

คนทั่วไปและเจ้าของกิจการ

  1. ให้ทีมระบุงานที่จะใช้เครื่องมือรันโค้ดก่อน เช่น งานคำนวณจากข้อมูลตัวอย่างที่ไม่มีข้อมูลลูกค้าจริง แล้วกำหนดคนตรวจผลลัพธ์ก่อนนำไปใช้ต่อ
  2. ขอคำตอบให้ชัดว่าผู้ช่วยแต่ละตัวอ่านข้อมูลอะไรได้ และข้อมูลที่แชร์ใช้ร่วมกับงานใดบ้าง อย่าอนุมัติจากเดโมที่ตอบได้ถูกอย่างเดียว
  3. กำหนดผู้รับผิดชอบการลบข้อมูลและการตรวจงานหลังอัปเดต หากทีมตอบไม่ได้ว่าข้อมูลเดิมอยู่ไหน ให้จัดการเรื่องนั้นก่อนเปิดงานจริง

ทีม IT ที่ดูแลระบบบน AWS

  1. ตรึงเวอร์ชันที่ต้องการใช้ หมายถึงกำหนดรุ่นในระบบติดตั้งให้แน่นอน แล้วอ่าน breaking change ก่อนอัปเดตพื้นที่ทดสอบ เก็บทางกลับรุ่นเดิมและสำเนาข้อมูลที่จำเป็นไว้ด้วย
  2. เปิด python_repl เฉพาะใน sandbox หรือ container ที่ทีมตรวจการแยกงานแล้ว container คือสภาพแวดล้อมรันโปรแกรมที่จัดแยกไว้ ควรตรวจสิทธิ์ไฟล์และเครือข่ายจริง ไม่ถือว่าชื่อเครื่องมือรับรองให้
  3. ใช้สิทธิ์ IAM เท่าที่งานจำเป็น IAM คือระบบกำหนดสิทธิ์เข้าถึงบริการของ AWS อย่าให้ข้อมูลรับรองสิทธิ์กว้างกับงานคำนวณที่ไม่ต้องใช้ แล้วตรวจการตั้งค่าก่อนนำข้อมูลจริงเข้า
  4. ตั้งผู้ดูแลพื้นที่ stash ที่แชร์ พร้อมเงื่อนไขลบข้อมูลหลังจบงาน ตรวจว่าลบช่วงการทำงานหนึ่งแล้ว ไม่ทำให้ข้อมูลที่อีกงานต้องใช้หายไป และไม่ทิ้งข้อมูลที่ควรลบไว้โดยไม่มีเจ้าของ

อ่านต่อเรื่องแนวคิดการรันผู้ช่วยที่ใช้โค้ดในพื้นที่แยกได้ในบทความ Strands sandbox preview แต่การตรวจรับรุ่นนี้ยังต้องยึดพฤติกรรมของเครื่องมือและสภาพแวดล้อมที่ทีมเลือกจริง

นักพัฒนาที่ใช้ผู้ช่วยหลายตัว

  1. ตรวจการตั้งพื้นที่เก็บของ stash แยกจากพื้นที่เก็บของตัวผู้ช่วย แล้วทำบัญชีข้อมูลที่ตำแหน่งเดิมจะอ่านไม่ได้ วางแผนย้ายหรือเก็บข้อมูลนั้นตามความจำเป็นของงาน
  2. ทดลองให้ผู้ช่วยที่อนุญาตอ่านรายการเดียวกันได้ และให้กลุ่มที่ไม่ควรแชร์อ่านไม่ได้ ใช้ข้อมูลจำลองแยกตามงาน พร้อมตรวจรหัสรายการไม่ให้ชนกัน
  3. ตรวจ snapshot ของระบบเก็บในหน่วยความจำว่ามีข้อมูลของงานอื่นปะปนหรือไม่ ทดสอบการกู้คืนและการลบ ก่อนเชื่อว่าการแยกหน้าจอผู้ใช้เท่ากับการแยกข้อมูลเบื้องหลัง
  4. ทดสอบ python_repl แบบเรียกต่อเนื่อง ตรวจว่าตัวแปรไม่คงอยู่ข้ามครั้งตามรีวิว และตรวจไฟล์ที่ยังอยู่หลังเรียกงาน ทดสอบกรณีหมดเวลาด้วย เพื่อให้ผู้ช่วยรับมือผลลัพธ์ที่มาไม่ครบได้

ผมมองว่า…

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

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

ปิดท้าย: สิ่งที่ต้องจับตา

ความพร้อมของผู้ช่วยควรวัดจากงานที่ทำได้พร้อมขอบเขตที่ตรวจสอบได้ครับ หลังการออกรุ่นวันที่ 12 ต.ค. ตาม GitHub สิ่งที่ควรตามต่อคือคำอธิบายการย้ายข้อมูล stash และแนวทางรัน python_repl ที่แยกจากโฮสต์ให้ชัด แหล่งที่อ่านยังไม่มีวันกำหนดการเพิ่มเติมสำหรับสองเรื่องนี้

ถ้าทีมคุณจะใช้ผู้ช่วยคำนวณรายงานจากไฟล์บริษัท คุณอยากให้มันอ่านเฉพาะไฟล์ที่เลือก หรือเข้าถึงโฟลเดอร์งานส่วนใดได้บ้าง?

Recap

  • เกิดอะไรขึ้น: Strands เพิ่มเครื่องมือรัน Python และเปิดทางให้แชร์บริบทที่เก็บไว้นอกบทสนทนา ตามบันทึกรุ่น
  • รุ่นที่จำ: 1.60.0 แปลว่าเป็นรุ่นที่บทความนี้ตรวจ ไม่ใช่คำรับรองว่าระบบเดิมใช้ต่อได้ทุกส่วน ตามGitHub
  • เสียงที่เห็นต่าง: tummon เสนอการแชร์ ส่วน strandly-the-agent ทักเรื่องทางเลือกและผลต่อระบบเดิมในPR stash
  • สิ่งที่ยังไม่รู้: ไม่มีผลทดสอบอิสระหรือราคาไทยในแหล่งชุดนี้ และต้องตรวจการแยกงานของระบบคุณเอง
  • ผลต่อทีมไทย: ตรึงรุ่น จำกัดสิทธิ์ รันโค้ดในพื้นที่แยก และทดสอบว่าข้อมูลแต่ละงานไม่ปะปนก่อนใช้จริง
  • สิ่งที่จับตา: แนวทางย้ายข้อมูลเก่า และคำอธิบายขอบเขตการรันโค้ดที่ตรวจรับได้
  • แหล่ง [1]: GitHub release
  • แหล่ง [2]: Strands Quickstart
  • แหล่ง [3]: PR python_repl
  • แหล่ง [4]: PR shared stash