วิธีที่ Policybazaar ลดค่าใช้จ่ายในการตรวจสอบลง 92% และเร่งการแสดงผลหน้าจอได้มากกว่า 90% โดยใช้เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome สำหรับ Agent และคำแนะนำในการพัฒนาเว็บที่ทันสมัย

Aman Soni

Swetha Gopalakrishnan

เผยแพร่เมื่อ: 10 พฤศจิกายน 2569

Policybazaar เป็นหนึ่งในแพลตฟอร์มประกันภัยชั้นนำของอินเดียที่มีลูกค้าลงทะเบียนมากกว่า 97 ล้านราย ลูกค้าประมาณ 80% เข้าชมเว็บไซต์ทุกเดือน PB Fintech ซึ่งเป็นบริษัทแม่เพิ่งเปิดตัว Pensionbazaar ซึ่งเป็นแพลตฟอร์มการวางแผนเกษียณอายุแบบครบวงจรภายใต้แบรนด์ Paisabazaar Marketing & Consulting Private Limited

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

เพื่อแก้ไขปัญหานี้ ทั้ง 2 บริษัทจึงรวมเครื่องมือ 2 อย่างเข้ากับเวิร์กโฟลว์แบบ Agentic ได้แก่ คำแนะนำในการพัฒนาเว็บที่ทันสมัยเพื่อสอนโมเดลเกี่ยวกับมาตรฐานเว็บสมัยใหม่ และเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome สำหรับ Agent เพื่อให้ Agent เหล่านั้นมีเบราว์เซอร์แบบ Headless แบบเรียลไทม์เพื่อตรวจสอบและยืนยันงานของตน

ผลกระทบมีดังนี้

ความท้าทาย: เขียนโค้ดได้เร็ว แต่ตรวจสอบช้า

Policybazaar และ Pensionbazaar พบปัญหาคอขวด 2 อย่างที่เวิร์กโฟลว์การเขียนโค้ด AI มาตรฐานไม่สามารถเพิ่มประสิทธิภาพในระดับการใช้งานจริงได้

Pensionbazaar: หน้าจอใหม่ที่มีวงจร QA ที่ยาวนาน

Pensionbazaar ต้องการหน้าจอใหม่ที่ซับซ้อนหลายสิบหน้าจอ เช่น เครื่องคำนวณคะแนนอิสรภาพหลังเกษียณแบบหลายขั้นตอน การคาดการณ์ค่าใช้จ่ายในการลงทุนที่ปรับแต่งได้ และรายงานวิดีโอแนะนำอัตโนมัติ ทีมสร้างฟีเจอร์เหล่านี้ด้วยเอเจนต์การเขียนโค้ดและเซิร์ฟเวอร์ MCP ของ Figma แต่มีปัญหา 2 อย่างที่ทำให้วงจร QA ใช้เวลานาน

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

ประการที่ 2 โค้ดที่สร้างขึ้นยังคงเป็นโค้ดแบบเดิม เมื่อไม่ทราบเกี่ยวกับแพลตฟอร์มเว็บสมัยใหม่ เอเจนต์จึงกลับไปใช้วิธีแก้ปัญหาที่ล้าสมัย โดยเขียนโมดัล JavaScript จำนวนมากแทนที่จะใช้องค์ประกอบ <dialog> ในตัว เพิ่ม Polyfill ที่ไม่จำเป็น และละเว้นคำแนะนำด้านประสิทธิภาพ เช่น fetchpriority

Policybazaar: หน้า Landing Page 30 หน้าและการตรวจสอบด้วยตนเอง

ทีมประกันชีวิตของ Policybazaar มีหน้า Landing Page ประมาณ 30 หน้าสำหรับผลิตภัณฑ์ประกันภัยต่างๆ และแต่ละหน้าอาจมีรูปแบบที่แตกต่างกันสำหรับแคมเปญการตลาดที่แตกต่างกัน โดยรวมแล้ว เว็บไซต์เหล่านี้มีผู้เข้าชม 200,000 ถึง 300,000 คนต่อวัน และทุกหน้าจะได้รับการอัปเดตการออกแบบและตรรกะทางธุรกิจเป็นรายเดือน ทีมต้องรักษาคะแนน Core Web Vitals ให้สูงอยู่เสมอ และตรวจสอบว่าตัวแปรทุกรายการยังคงเข้าถึงได้และแสดงผลอย่างถูกต้องในทุกขนาดหน้าจอ

ก่อนที่จะมีระบบอัตโนมัติ วิศวกรจะตรวจสอบแต่ละหน้าด้วยตนเอง ดังนี้

1. เรียกใช้ PageSpeed Insights เพื่อรวบรวมข้อมูลผู้ใช้จริง
2. ประเมินคะแนนและคำแนะนำของ Core Web Vitals
3. ตรวจสอบบิลด์เวอร์ชันพัฒนาหรือเวอร์ชันทดลอง วินิจฉัยปัญหาที่อยู่เบื้องหลังคะแนน และใช้การแก้ไขโค้ด

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

ก่อนที่จะเปลี่ยนเวิร์กโฟลว์ ทีมได้ตั้งเป้าหมายไว้ 3 ข้อ ได้แก่ ลดเวลาที่นักพัฒนาซอฟต์แวร์ใช้ในการตรวจสอบประสิทธิภาพลงมากกว่า 80% พร้อมทั้งทำให้การตรวจสอบครอบคลุมอย่างต่อเนื่อง ลดเวลาในการดำเนินการ QA ด้วยรายงานที่ได้รับการยืนยัน และลดข้อบกพร่องของ UI ที่เกิดขึ้นเนื่องจากหน้าจอไม่ตรงกับ Wireframe

วิธีแก้ปัญหา: ลูปการยืนยันด้วยรหัส

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

วิดีโอต่อไปนี้แสดงการทำงานของลูปนี้ Agent จะอ่านการออกแบบ Figma สำหรับหน้าจอใหม่ นำไปใช้ แล้วใช้เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome สำหรับ Agent เพื่อตรวจสอบหน้าเว็บที่แสดงผลและแก้ไขความแตกต่างที่พบ

ขั้นตอนที่ 1: ปูพื้นฐานให้ Agent เกี่ยวกับมาตรฐานเว็บสมัยใหม่

ทีม Pensionbazaar ต้องการให้โค้ดที่สร้างขึ้นเป็นไปตามแนวทางปฏิบัติแนะนำสำหรับเว็บสมัยใหม่ ใช้ฟีเจอร์ของแพลตฟอร์มปัจจุบัน และยังคงทำงานในเบราว์เซอร์รุ่นเก่าได้ การตรวจสอบด้วยตนเองเป็นเรื่องน่าเบื่อ และตัวแทนก็อาจไม่ทราบข้อมูลล่าสุดเกี่ยวกับแพลตฟอร์มเสมอไป คำแนะนำในการพัฒนาเว็บที่ทันสมัยช่วยแก้ปัญหานี้ได้ ซึ่งเป็นทักษะของ Agent ที่เขียนและดูแลโดยผู้เชี่ยวชาญด้านเว็บจาก Chrome และชุมชนเว็บ ซึ่งครอบคลุมกรณีการใช้งานมากกว่า 200 กรณี โดยจะแนะนำตัวแทนให้ใช้ API ของแพลตฟอร์มเว็บสมัยใหม่ รวมถึงแนวทางปฏิบัติแนะนำด้านประสิทธิภาพและการช่วยเหลือพิเศษที่เหมาะกับเป้าหมาย Baseline ของคุณ หากไม่ได้ตั้งค่าเป้าหมาย ระบบจะใช้ค่าเริ่มต้นเป็นBaseline ที่พร้อมใช้งานในวงกว้าง

หลังจากที่ Agent ดึงบริบทจากไฟล์ Figma แล้ว Agent จะใช้คำแนะนำในการพัฒนาเว็บที่ทันสมัยขณะเขียนโค้ด สำหรับ Pensionbazaar การเปลี่ยนแปลงนี้ส่งผลต่อโค้ดใน 3 ด้าน ได้แก่

• องค์ประกอบแบบเนทีฟแทนที่วิธีแก้ปัญหาชั่วคราวของ JavaScript ตัวแทนใช้<dialog>องค์ประกอบในตัวและPopover APIสำหรับโมดัลรายละเอียดแผน และ CSS Grid และ Flexbox สำหรับการ์ดสรุปทางการเงิน
• Agent ได้เพิ่มคำแนะนำด้านประสิทธิภาพที่โมเดลพื้นฐานมักจะละเว้น ซึ่งรวมถึง fetchpriority="high" ในรูปภาพ LCP หลัก, loading="lazy" ในการ์ดแพ็กเกจที่อยู่ครึ่งหน้าล่าง และงบประมาณการดำเนินการตามเวลาด้วย scheduler.yield() เพื่อปกป้อง Interaction to Next Paint (INP)
• ฟีเจอร์ที่ทันสมัยไม่ได้ทำให้เบราว์เซอร์รุ่นเก่าใช้งานไม่ได้ Pensionbazaar รองรับเบราว์เซอร์เวอร์ชันเก่า ซึ่งกำหนดไว้ใน Browserslist User Agent ใช้ฟีเจอร์ต่างๆ เช่น คลาสเทียม CSS :user-invalid และ autoComplete="one-time-code" ในช่องรหัสผ่านแบบใช้ครั้งเดียว (OTP) เบราว์เซอร์รุ่นเก่าจะละเว้นฟีเจอร์เหล่านี้ และฟังก์ชันหลักจะยังคงทำงานต่อไป

โมเดลพื้นฐานก็ไม่ได้แตกต่างกันมากนัก โดยทีมพบว่าโมเดลพื้นฐานมีประสิทธิภาพสอดคล้องกับแนวทางปฏิบัติแนะนำประมาณ 70% รายงานของ Agent เองระบุถึงกฎคำแนะนำในการพัฒนาเว็บที่ทันสมัย 12 ข้อที่ช่วยปิดช่องว่างที่เหลืออยู่ ตัวอย่าง 4 รายการมีดังนี้

สำหรับ Pensionbazaar สิ่งสำคัญอันดับแรกของเราคือการสร้างโค้ดที่มีคุณภาพตั้งแต่วันแรกเพื่อหลีกเลี่ยงหนี้ทางเทคนิคในภายหลัง คำแนะนำในการพัฒนาเว็บที่ทันสมัยช่วยให้ Agent การเขียนโค้ดของเรานำมาตรฐานเว็บสมัยใหม่และแนวทางปฏิบัติแนะนำด้านประสิทธิภาพมาใช้ โดยยังคงคำนึงถึงเป้าหมายความเข้ากันได้กับเบราว์เซอร์ที่เฉพาะเจาะจงของเรา ซึ่งทำให้การรีวิวโค้ดฟรอนท์เอนด์ของเราง่ายขึ้นและเร็วขึ้นอย่างมาก และช่วยปรับปรุงเวลาในการพัฒนาของเราในท้ายที่สุด

Aman Soni ผู้จัดการฝ่ายวิศวกรรมของ Policybazaar

ขั้นตอนที่ 2: ให้เบราว์เซอร์แก่ Agent

เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome สำหรับ Agent คือชุดเครื่องมือ ซึ่งรวมถึงเซิร์ฟเวอร์ MCP, CLI และทักษะของ Agent ที่ช่วยให้ Agent การเขียนโค้ดเข้าถึงข้อมูลการแก้ไขข้อบกพร่องรันไทม์แบบเรียลไทม์ได้ เช่น บันทึกคอนโซล การจราจรของข้อมูลในเครือข่าย แผนผังการช่วยเหลือพิเศษ และความสามารถอื่นๆ ของเครื่องมือสำหรับนักพัฒนาเว็บ

ทีมได้ติดตั้งเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome สำหรับ Agent เป็นปลั๊กอินใน Agent การเขียนโค้ด Claude Code ดังนี้

# Add the marketplace registry
/plugin marketplace add ChromeDevTools/chrome-devtools-mcp

# Install the plugin (MCP server and skills)
/plugin install chrome-devtools-mcp@chrome-devtools-plugins

ทีมต้องการให้การทดสอบทุกครั้งทำงานในอินสแตนซ์เบราว์เซอร์ที่สะอาด เพื่อไม่ให้ส่วนขยาย Chrome ที่ติดตั้งไว้ส่งผลต่อผลลัพธ์ และไม่ให้ข้อมูลส่วนบุคคลหรือข้อมูลที่ละเอียดอ่อนรั่วไหล หากต้องการรับสิทธิ์ดังกล่าว ให้เพิ่ม --isolated ลงในอาร์เรย์ args ในการกำหนดค่าเซิร์ฟเวอร์ MCP

{
  "args": ["-y", "chrome-devtools-mcp@latest", "--isolated"]
}

หากการทดสอบต้องใช้เซสชันเบราว์เซอร์ที่มีการลงชื่อเข้าใช้อยู่แล้ว ให้ใช้ --autoConnect แทน

ขั้นตอนที่ 3: ให้ Agent ตรวจสอบและแก้ไขงานของตนเอง

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

• ตรวจสอบแผนผัง DOM และ CSS ที่คำนวณแล้ว และเปรียบเทียบกับการออกแบบ Figma
• ปรับขนาดหน้าเว็บเป็นวิวพอร์ตบนอุปกรณ์เคลื่อนที่เพื่อทดสอบการปรับเปลี่ยนตามอุปกรณ์
• บันทึกการติดตามประสิทธิภาพเพื่อค้นหาเฟรมของภาพเคลื่อนไหวที่ใช้เวลานาน (LoAF) ซึ่งเกิดจากสคริปต์ ทรัพยากรที่บล็อกการแสดงผล และปัญหาด้านประสิทธิภาพอื่นๆ
• เขียนโค้ดใหม่เพื่อแก้ไขความไม่สอดคล้องกันของการออกแบบ ปัญหาด้านประสิทธิภาพ และข้อยกเว้นของคอนโซลก่อนที่วิศวกรจะตรวจสอบ

ตารางต่อไปนี้แสดงเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome สำหรับ Agent ที่รองรับการตรวจสอบแต่ละรายการ

เมื่อ Agent พบปัญหา เช่น ข้อความถูกตัดในหน้าจอขนาดเล็ก, Flex Wrap เสีย หรือรูปภาพที่ไม่ได้เพิ่มประสิทธิภาพซึ่งทำให้เลย์เอาต์เปลี่ยน Agent จะเรียกใช้ลูปการแก้ไขสั้นๆ ดังนี้

1. เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome สำหรับ Agent จะบันทึกข้อผิดพลาดที่แน่นอน
2. Agent จะวิเคราะห์ข้อมูลและเขียน CSS หรือ JavaScript ที่มีปัญหาใหม่
3. ตัวแทนโหลดหน้าเว็บซ้ำเพื่อยืนยันการแก้ไข

ในหน้าจอหนึ่ง ตัวแทนแสดงผลหน้าเว็บและพบว่าเลย์เอาต์ส่วนหัว ระยะห่าง และการไล่ระดับสีไม่ตรงกับการออกแบบ ระบบแก้ไขไฟล์ .scss ที่เกี่ยวข้องแล้ว นอกจากนี้ยังโต้ตอบกับหน้าเว็บด้วย เช่น ขยาย Accordion เพื่อตรวจสอบว่าสถานะเปิดตรงกับการออกแบบหรือไม่

ขั้นตอนที่ 4: ส่งรายงานที่ยืนยันแล้วให้ทีม QA

เมื่อการยืนยันเสร็จสิ้น Agent จะส่งโค้ดที่พร้อมใช้งานจริงพร้อมกับรายงานการตรวจสอบให้ทีม QA รายงานนี้มีข้อมูลต่อไปนี้

• การเปรียบเทียบภาพกับการออกแบบ Figma ที่ไฮไลต์ความแตกต่างของพิกเซล ซึ่งสร้างจากภาพหน้าจอ, สแนปชอต DOM และสไตล์ที่คำนวณแล้ว
• ภาพหน้าจอของหน้าที่แสดงผลในหน้าจอขนาดต่างๆ
• Core Web Vitals และการวินิจฉัยประสิทธิภาพจาก performance_start_trace และ performance_analyze_insight เช่น Speed Index และเวลาทั้งหมดในการบล็อก (TBT)
• คะแนน Lighthouse สำหรับ SEO, แนวทางปฏิบัติแนะนำ และการช่วยเหลือพิเศษจาก lighthouse_audit
• การตรวจสอบการโต้ตอบว่าผ่านหรือไม่ผ่าน เช่น การยุบแถวและปุ่มเปิด/ปิด รวมถึงข้อผิดพลาดของคอนโซลและการเปลี่ยนแปลงสถานะของแอปพลิเคชัน เช่น การแก้ไขแถว การลบแถว และสถานะว่างเปล่า

ใช้แนวทางเดียวกันกับหน้าแคมเปญ 30 หน้า

ในแพลตฟอร์มหลัก Policybazaar ได้เปลี่ยนจากการเรียกใช้ PageSpeed Insights ด้วยตนเองมาเป็นการตรวจสอบผ่านเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome สำหรับ Agent ใน Kiro ก่อนที่หน้าแคมเปญจะเผยแพร่ วิศวกรจะเรียกใช้การตรวจสอบกับ URL สำหรับทดลองใช้สำหรับอุปกรณ์เคลื่อนที่และเดสก์ท็อป Agent จะเรียกใช้การตรวจสอบประสิทธิภาพและ Lighthouse และเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome สำหรับ Agent จะดึงข้อมูลภาคสนามของรายงานประสบการณ์ของผู้ใช้ Chrome (CrUX) ในชีวิตจริงควบคู่ไปกับข้อมูลในห้องทดลองโดยอัตโนมัติ ซึ่งจะแทนที่ขั้นตอน PageSpeed Insights ทั้งหมด

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

ตอนนี้ตัวแทนสามารถตรวจสอบประสิทธิภาพได้ถึง 12 ครั้งในระยะเวลาที่วิศวกรใช้ในการตรวจสอบเพียงครั้งเดียว ซึ่งช่วยลดเวลาที่ต้องทำงานด้วยตนเองได้ถึง 92%

ประสิทธิภาพของเว็บเป็นสิ่งสำคัญในการรักษาประสบการณ์ที่ดีของผู้ใช้ แต่การตรวจสอบด้วยตนเอง การประเมิน Waterfall และการติดตามหน้า Landing Page หลายสิบหน้าเป็นเรื่องที่น่าเบื่อและเป็นคอขวดที่สำคัญ เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome สำหรับ Agent ได้เปลี่ยนกระบวนการนี้และลดเวลาในการตรวจสอบประสิทธิภาพของวิศวกรลง 92% ทำให้วิศวกรมีเวลามากขึ้นในการมุ่งเน้นที่งานที่ซับซ้อนกว่า

Aman Soni ผู้จัดการฝ่ายวิศวกรรมของ Policybazaar

ผลกระทบ

คำแนะนำในการพัฒนาเว็บที่ทันสมัยและเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome สำหรับ Agent เปลี่ยนการทดสอบฟรอนท์เอนด์ที่ Policybazaar และ Pensionbazaar จากกระบวนการที่ต้องทำด้วยตนเองและเป็นแบบเชิงรับให้เป็นกระบวนการอัตโนมัติและเชิงรุก ตารางต่อไปนี้เปรียบเทียบเวิร์กโฟลว์ก่อนและหลังการเปลี่ยนแปลง

การลดลง 92% นี้สูงกว่าเป้าหมายของทีมที่ตั้งไว้มากกว่า 80% การถดถอยของหน้า Landing Page จะได้รับการตรวจจับก่อนที่จะเข้าสู่ขั้นตอนการทดลองใช้หรือ QA ใน Pensionbazaar โค้ดจะได้รับการตรวจสอบแล้วพร้อมภาพหน้าจอสำหรับวิวพอร์ตหลายรายการ ซึ่งช่วยลดการทำงานไปมาที่ซ้ำซ้อนระหว่างการออกแบบ วิศวกรรม และ QA

ประเด็นสำคัญสำหรับทีมของคุณ

• ให้ Agent ทำงานโดยอิงตามคำแนะนำที่เชื่อถือได้ คำแนะนำที่คัดสรรมาอย่างดี เช่น คำแนะนำในการพัฒนาเว็บที่ทันสมัย จะช่วยป้องกันไม่ให้ Agent ใช้รูปแบบที่ล้าสมัย และช่วยให้โค้ดของคุณอยู่ภายในเป้าหมายพื้นฐาน
• อย่าให้ Agent ทำเครื่องหมายงานฟรอนท์เอนด์ว่าเสร็จสิ้นจนกว่าจะตรวจสอบหน้าเว็บที่แสดงผลแล้ว เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome สำหรับ Agent ช่วยให้ Agent ตรวจสอบเลย์เอาต์ วิวพอร์ต และการติดตามประสิทธิภาพในเบราว์เซอร์จริงได้
• กำหนดเกณฑ์การออกจากลูปที่ชัดเจน กำหนดขีดจำกัดของขั้นตอนและเงื่อนไขการผ่านและไม่ผ่านที่ชัดเจน เพื่อไม่ให้ Agent ทำงานวนซ้ำและสิ้นเปลืองโทเค็น
• เริ่มต้นด้วยหน้าเว็บที่ใช้เทมเพลตซึ่งมีการเข้าชมสูง เวิร์กโฟลว์แบบ Closed-loop จะมีประสิทธิภาพมากที่สุดเมื่อความเร็วในการตอบสนองเป็นสิ่งสำคัญ
• เรียกใช้การตรวจสอบในเบราว์เซอร์ที่ไม่มีข้อมูลใดๆ ใช้--isolatedเพื่อให้ส่วนขยายและข้อมูลที่แคชไว้ไม่ส่งผลต่อผลลัพธ์หรือเปิดเผยข้อมูลส่วนตัว

แหล่งข้อมูล

• คำแนะนำในการพัฒนาเว็บที่ทันสมัย
• ที่เก็บแหล่งที่มาของคำแนะนำในการพัฒนาเว็บที่ทันสมัย
• เอกสารประกอบเกี่ยวกับเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome สำหรับ Agent
• เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome สำหรับ Agent บน GitHub