Skip to content

Harness Engineering: สิ่งที่ต้องจัดรอบโมเดล ก่อนนำ AI Agent ไปใช้งานจริง

VibeSolo
ภาพปก Mike Chambers จาก AWS มีข้อความ I Deployed an Agent with Almost No Code
ภาพปกวิดีโอ Harness Engineering ของ Mike Chambers ข้อความ Almost No Code เป็นพาดหัวต้นทาง เดโมที่บทความเล่ามีส่วน deployment ที่เตรียมไว้แล้ว · ที่มา: AI Engineer • ที่มา

AI Agent ที่ตอบคำถามได้ในเดโมยังเหลือโจทย์เรื่องการทำงานในระบบจริง Mike Chambers ใช้คำว่า harness เพื่อชวนมองส่วนรอบโมเดล ตั้งแต่เครื่องมือและความจำ ไปจนถึงการติดตามและประเมินผล

Mike Chambers จาก AWS นำเสนอ Harness Engineering ทางช่อง AI Engineer โดยชวนออกแบบส่วนรอบโมเดลให้ควบคุม ขยาย และติดตามการทำงานได้ ข้อคิดของ VibeSolo คือเพิ่มคำถามเรื่องระบบเข้ามาควบคู่กับการเลือกโมเดล

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

แยกให้ออกระหว่าง Agent ที่เราใช้ กับ Agent ที่เราสร้าง

Mike Chambers แบ่งโลกของ AI Agent ออกเป็นสองกลุ่มที่หน้าตาคล้ายกัน แต่ความรับผิดชอบต่างกันมาก

  • Agent ที่เราใช้: Mike ยก coding agent อย่าง Claude Code, Cursor และ Kiro เป็นตัวอย่าง
  • Agent ที่เราสร้าง: กลุ่มที่ผู้อื่นจะนำไปใช้ ตัวอย่างสมมติของ VibeSolo ได้แก่ agent ตอบลูกค้า ช่วยทีมขาย หรือค้นคู่มือภายใน

Mike แยกสองกลุ่มนี้เพื่อให้เห็นว่าผู้ใช้ ผู้ดูแล และบริบทการทำงานต่างกัน จึงต้องคิดถึง harness ตามบทบาทของ agent

ตัวอย่างสมมติของ VibeSolo คือ agent ที่เกี่ยวข้องกับคำสั่งซื้อ ส่วนลด หรือข้อมูลลูกค้า ทีมต้องกำหนดขอบเขตงานและวิธีตรวจผลให้ชัด

มอง Harness เป็นระบบควบคุมรอบตัว model

คำว่า harness มีความหมายดั้งเดิมว่าอุปกรณ์รัดหรือสายรัดสำหรับควบคุมสัตว์ Mike นำคำนิยามนี้มาใช้กับ AI โดยแทนคำว่า “สัตว์” ด้วย “model” จึงเห็นภาพทันทีว่า model มีพลังในการสร้างคำตอบ แต่ harness คือส่วนที่กำหนดว่าจะให้พลังนั้นทำงานในขอบเขตใด

คำถามออกแบบต่อจาก VibeSolo คือ ส่วนรอบโมเดลจะกำหนดเรื่องต่อไปนี้อย่างไร

  • ต้องตอบเรื่องใด และควรปฏิเสธเรื่องใด
  • ดึงข้อมูลจากระบบไหนได้บ้าง
  • จำข้อมูลใดได้ และต้องลืมข้อมูลใด
  • ใครมีสิทธิ์สั่งให้ทำงานระดับไหน
  • เมื่อใดต้องส่งเรื่องให้พนักงานตัดสินใจ
  • ธุรกิจจะตรวจย้อนหลังได้อย่างไรว่าคำตอบเกิดจากข้อมูลหรือ tool ใด

จากกรอบที่ Mike นำเสนอ prompt เป็นเพียงส่วนหนึ่งของระบบ คำถามด้านสิทธิ์ ความจำ และการติดตามข้างต้นเป็นการประยุกต์ของ VibeSolo

วางมาตรฐานให้ Agent ที่ทีมงานใช้ทุกวัน

Mike เสนอให้จัดมาตรฐานการทำงานของ coding agent เช่นเดียวกับสมาชิกในทีมวิศวกรรม ตั้งแต่ความจำ ทักษะ และเครื่องมือ ไปจนถึงวิธีปฏิบัติตามมาตรฐานของทีม

ในตัวอย่างของเขา MCP เป็นช่องทางหนึ่งสำหรับเพิ่มเครื่องมือให้ coding agent ประเด็นคือการเลือกและกำกับเครื่องมือใน harness

ตัวอย่างสมมติของ VibeSolo คือแยกสิทธิ์ของงานขาย งานบริการ และงานการเงินตามหน้าที่ แล้วตรวจว่าระบบบังคับขอบเขตนั้นได้อย่างไร

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

หยุด Slop Ops แล้วให้ AI สร้างสิ่งที่เรายังตรวจสอบได้

Mike ใช้คำว่า SlopOps กับการให้ agent ไปสร้างทรัพยากรคลาวด์โดยตรง เขาเสนอให้ agent สร้าง Infrastructure as Code แล้วใช้กระบวนการของทีมจัดการต่อ

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

ออกแบบ Harness สำหรับ Agent ที่ให้ลูกค้าหรือพนักงานจำนวนมากใช้

Mike ยกองค์ประกอบที่ต้องจัดรอบ agent เช่น loop, scaling, payments, memory, identity, skills, runtime และ context พร้อมย้ำบทบาทของ observability กับ evaluations

คำถามประยุกต์ของ VibeSolo สำหรับแต่ละองค์ประกอบคือ

  • Identity และสิทธิ์: จะทดสอบการแยกผู้ใช้และข้อมูลระหว่างลูกค้าอย่างไร
  • Memory: จะเก็บอะไร ที่ใด และให้ใครเข้าถึงได้บ้าง
  • Agent loop: จะสังเกตและจำกัดการวนเรียกเครื่องมืออย่างไร
  • Scaling: จะวัดความสามารถเมื่อจำนวนผู้ใช้และงานเพิ่มขึ้นอย่างไร
  • Payments และต้นทุน: จะติดตามค่าใช้จ่ายและกำหนดงบของงานอย่างไร
  • Observability และ evaluations: เราเห็นเส้นทางการทำงาน และวัดคุณภาพจากเคสจริงได้หรือไม่

Mike ย้ำว่า observability และการประเมินผลควรเริ่มก่อนนำระบบไปใช้งาน เพราะทีมต้องเห็นว่า agent ทำอะไรและผลเป็นอย่างไร

ข้อเสนอประยุกต์ของ VibeSolo คือเก็บโจทย์ที่ตรวจคำตอบได้ไว้เปรียบเทียบเมื่อเปลี่ยนโมเดล เครื่องมือ หรือ prompt โดยเลือกชุดโจทย์ให้เหมาะกับงาน

เริ่มจาก Agent เล็ก แต่แยก memory ออกจากตัว Agent

Mike เริ่มจากโค้ด Strands Agent SDK ที่มี prompt และเครื่องมือ calculator กับเวลา เขาพูดชัดว่าไม่ได้รันตัวอย่างแรก จึงใช้โค้ดนี้อธิบายโครงสร้าง agent ขนาดเล็ก ไม่ใช่ผลทดสอบว่าเครื่องมือทำงานสำเร็จ จากนั้นจึงเปิด agent อีกตัวที่ Kiro ช่วยสร้าง ซึ่งมี session manager และเครื่องมือบันทึกความจำลงไฟล์

เดโม agent ตัวหลังรันในเครื่องของเขา และตอบเรื่องทีมฟุตบอลที่ชอบโดยอาศัยข้อมูลจากการสนทนาก่อนหน้า เขาใช้ Australia เป็นตัวอย่างความจำของ agent ใน session นี้

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

  • ประวัติ session: ข้อมูลที่ใช้ต่อบทสนทนาเดิม ในตัวอย่าง session manager ช่วยนำประวัติกลับมาใช้
  • ความจำที่เก็บแยก: ในตัวอย่าง local agent มีเครื่องมือบันทึกลงไฟล์ ส่วนระบบคลาวด์ที่ผู้พูดนำเสนอต่อมาจัด memory แยกจาก runtime สองตัวอย่างนี้จึงต้องดูวิธีเก็บและเรียกใช้แยกกัน
  • ข้อมูลอ้างอิงและข้อมูลอ่อนไหว: เป็นคำถามเพิ่มเติมของ VibeSolo ว่าทีมจะเลือกแหล่งข้อมูลและกำกับสิทธิ์อย่างไร

Mike ต้องการแยก memory ออกจาก runtime เมื่อย้ายงานขึ้นคลาวด์ เพื่อจัดการสองส่วนต่างหาก ส่วนความคงอยู่ของข้อมูลต้องทดสอบกับวิธีเก็บที่เลือก

เลือก Platform ที่ประกอบส่วนต่างๆ ได้ ไม่บังคับย้ายทั้งระบบ

ผู้พูดเปิดตัวช่วยเริ่มโปรเจกต์ของ Amazon Bedrock AgentCore ซึ่งแสดงตัวเลือกภาษา Python หรือ TypeScript และการเชื่อมต่อ HTTP, MCP หรือ AG-UI ในเดโมเขาเลือก HTTP กับ Strands แล้วใช้โค้ดที่เตรียมไว้ต่อ แทนการ deploy โปรเจกต์ใหม่ทั้งหมดให้ดู

Mike อธิบาย runtime ของ AgentCore ว่ารองรับการแยกผู้ใช้และการขยายงาน รวมถึงแสดงขั้นตอนพัฒนาในเครื่อง การ deploy และการติดตาม trace กับ memory นี่เป็นคำอธิบายและเดโมของผู้ขาย ไม่ใช่การตรวจความปลอดภัยหรือทดสอบโหลดอย่างอิสระ

เขายังเสนอว่าบริการบางส่วน เช่น memory สามารถนำไปประกอบกับ agent ที่มีอยู่ได้ ข้อคิดของ VibeSolo คือพิจารณาองค์ประกอบที่งานต้องการ แล้วตรวจการเชื่อมต่อกับระบบของทีม

เริ่ม Harness เรียบง่าย แล้วเพิ่มองค์ประกอบตามงาน

ช่วงท้าย Mike เสนอว่า harness บางงานอาจเริ่มเรียบง่ายด้วยการตั้งค่าโมเดล system prompt และเครื่องมือ ก่อนเพิ่ม agent loop ตามความต้องการของงาน

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

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

ที่มา: Mike Chambers จาก AWS ทางช่อง AI Engineer อัปโหลดวันที่ 14 กันยายน 2026 เวลา 21:30:38 น. ตามเวลาไทย (14:30:38 UTC) สรุปจากคำบรรยายภาษาอังกฤษที่บันทึกไว้ช่วง 00:16–20:35 ซึ่งขาดช่วงต้นและท้าย ไม่ได้ตรวจโค้ด เดโม หรือความพร้อมใช้ของบริการอย่างอิสระ วันอัปโหลดเป็นวันของแหล่งข้อมูล ไม่ใช่วันเผยแพร่บทความนี้