การมอบหมายตัวแทน:
ตัวแทนพัฒนาของคุณมอบหมายการทดสอบ
การมอบหมายตัวแทนช่วยให้ตัวแทนพัฒนาของคุณสามารถทำฟีเจอร์ให้เสร็จและส่งการตรวจสอบไปยังตัวแทน QA แยกต่างหาก ตัวแทนพัฒนายังคงส่งโค้ดด้วยโมเดลที่คุณไว้วางใจในปัญหาที่ยาก ตัวแทน QA จะทำการทดสอบบนโมเดลที่มีค่าใช้จ่ายถูกกว่า ทั้งสองฝ่ายสื่อสารผ่านเซิร์ฟเวอร์ MCP ของ AgentsRoom ดังนั้นการมอบหมายตัวแทนจึงทำงานได้ตลอดทั้งกระบวนการโดยที่คุณไม่ต้องคัดลอกอะไรไปมา
คุณหยุดจ่ายราคา Opus สำหรับการคลิกในเบราว์เซอร์ คุณหยุดทำให้บริบทของตัวแทนพัฒนาของคุณบวมด้วยภาพหน้าจอและการดัมพ์ DOM การมอบหมายตัวแทนจะส่งงานแต่ละงานไปยังโมเดลที่ถูกต้องในราคาที่ถูกต้อง และเมื่อตัวแทน QA เสร็จสิ้น มันจะส่งสัญญาณกลับไปยังตัวแทนพัฒนาของคุณเพื่อให้วงจรปิดเอง
การมอบหมายตัวแทนในทางปฏิบัติ: ตัวแทนพัฒนาของ Codex เสร็จสิ้นฟีเจอร์ เรียกใช้ run_qa_test ตัวแทน QA เปิดเบราว์เซอร์บนโมเดลที่มีค่าใช้จ่ายถูกกว่าและรายงานกลับ
นี่คือปัญหาที่การมอบหมายตัวแทนช่วยแก้ไข คุณใช้ตัวแทนพัฒนาที่แข็งแกร่ง (Claude Opus, Codex, โมเดลที่ออกแบบ API หรือปรับปรุงร้านค้า) ตัวแทนส่งฟีเจอร์ใน 10 นาที จากนั้นใช้เวลาอีก 8 นาทีในการคลิกไปรอบๆ ในเบราว์เซอร์เพื่อตรวจสอบว่าฟีเจอร์ทำงานหรือไม่ อัตราโทเค็นที่มีค่าใช้จ่ายสูงเท่าเดิม โมเดลเดียวกันที่คิดอย่างหนักเกี่ยวกับตรรกะโดเมนของคุณ ตอนนี้กำลังอ่านป้ายชื่อปุ่ม
การมอบหมายตัวแทนแก้ไขปัญหานั้น เมื่อฟีเจอร์เสร็จสิ้น ตัวแทนพัฒนาจะเรียกใช้เครื่องมือ MCP เพียงตัวเดียวคือ run_qa_test พร้อมกับสถานการณ์ AgentsRoom จะสร้างตัวแทน QA ชั่วคราวบนโมเดลที่คุณเลือกสำหรับ QA: Claude Haiku, Codex mini, GPT-4 mini หรืออะไรก็ได้ที่คุณต้องการ ตัวแทน QA จะได้รับ MCP ของ AgentsRoom Browser ขับเคลื่อนหน้าเว็บ ยืนยันผลลัพธ์ และตอบกลับด้วยคำตัดสิน ตัวแทนพัฒนาจะอ่านคำตัดสินและดำเนินการต่อ
นั่นคือการมอบหมายตัวแทน และนั่นคือวงจรเดียวที่หน้าครอบคลุม หนึ่งตัวแทนพัฒนา หนึ่งตัวแทน QA หนึ่ง MCP แนวคิดเดียวกันกับวิศวกรอาวุโสที่มอบหมายการทดสอบการถดถอยให้กับผู้ช่วยหรือตัวแทน QA: วิศวกรอาวุโสยังคงออกแบบ ผู้ช่วยทำรายการตรวจสอบ การมอบหมายตัวแทนให้คุณแยกโมเดลได้เช่นเดียวกัน
การมอบหมายตัวแทนที่แสดงให้เห็น: ตัวแทนพัฒนาหลัก (Codex) และตัวแทน QA ลูก (Claude) ปรากฏในรายการตัวแทนเดียวกัน โดยมีการส่งต่อจาก Dev ไปยัง QA ที่ชัดเจน
ทำไมการมอบหมายตัวแทนจึงคุ้มค่าที่จะเชื่อมต่อ
ประการแรก เงิน การผ่านการทดสอบบน Claude Opus และการผ่านการทดสอบบน Claude Haiku มีค่าใช้จ่ายที่แตกต่างกันอย่างมาก เบราว์เซอร์เดียวกัน การยืนยันเดียวกัน ภาพหน้าจอเดียวกัน การมอบหมายตัวแทนช่วยให้โมเดลที่มีค่าใช้จ่ายถูกทำงานที่มีค่าใช้จ่ายถูก การรายงานจากผู้ที่เปิดใช้งานนี้บอกว่าค่าใช้จ่ายโทเค็นของพวกเขาลดลงในวันที่มีการ QA หนักโดยมีปัจจัยที่วัดได้จริง ไม่ใช่ 5 ถึง 10 เปอร์เซ็นต์
ประการที่สอง บริบท เมื่อตัวแทนพัฒนาทำการทดสอบเอง ทุกภาพหน้าจอ ทุกการดัมพ์ DOM ทุกบันทึกคอนโซลจะอยู่ในหน้าต่างบริบทของตัวแทนพัฒนา ยี่สิบนาทีของการคลิกคือเมกะไบต์ของเสียงรบกวนที่ตัวแทนพัฒนาต้องแบกรับตลอดเซสชันที่เหลือ การมอบหมายตัวแทนแยกเสียงรบกวนนี้ออกไปในตัวแทน QA ชั่วคราว ตัวแทนพัฒนาจะได้รับข้อความ 'ผ่าน' หรือ 'ไม่ผ่าน' กลับมา ไม่มีอย่างอื่น
ประการที่สาม มุมมองทางนิเวศวิทยา การมอบหมายตัวแทนแต่ละครั้งช่วยประหยัดการคำนวณจริง การใช้ Haiku แทนที่ Opus จะลดรอยเท้าพลังงานในขั้นตอนนั้นลงครึ่งหนึ่ง คูณด้วยทุกคนในทีมและทุกวงจรการทดสอบในหนึ่งปี และการมอบหมายตัวแทนจะกลายเป็นปัจจัยที่ไม่ธรรมดาในด้านคาร์บอนของสแต็กของคุณ
ประการที่สี่ ความเชื่อถือได้ ตัวแทนพัฒนาที่ขับเคลื่อนเบราว์เซอร์เองมักจะหลงทาง สองภาพหน้าจอเข้าไป มันลืมสิ่งที่มันพยายามจะตรวจสอบ ตัวแทน QA ในการมอบหมายตัวแทนมีงานเดียวและคำสั่งเดียว มันทดสอบ รายงาน และตาย วงจรสั้น คาดเดาได้ และง่ายต่อการดีบัก
การไหลเดียวที่การมอบหมายตัวแทนครอบคลุมที่นี่
ตัวแทนพัฒนาหนึ่งตัว ตัวแทน QA หนึ่งตัว การเรียก MCP หนึ่งครั้ง การมอบหมายตัวแทน ตลอดทั้งกระบวนการ
ตัวแทนพัฒนาส่งฟีเจอร์
ตัวแทนพัฒนาของคุณ (Claude Opus, Codex reasoning สูง โมเดลที่มีค่าใช้จ่ายสูงที่คุณไว้วางใจ) เสร็จสิ้นการดำเนินการ จุดสิ้นสุดใหม่ หน้าจอใหม่ กระบวนการใหม่ โค้ดถูกเขียน ไฟล์ถูกบันทึก
ตัวแทนพัฒนาจะเรียกใช้ run_qa_test
แทนที่จะเปิดเบราว์เซอร์เอง ตัวแทนพัฒนาจะเรียกใช้เครื่องมือ MCP เพียงตัวเดียวจากเซิร์ฟเวอร์ AgentsRoom Test Runner: run_qa_test พร้อมกับสถานการณ์ภาษาอังกฤษธรรมดา นั่นคือพื้นผิว API การมอบหมายตัวแทนทั้งหมด
AgentsRoom สร้างตัวแทน QA
AgentsRoom Test Runner สร้าง QA agent ชั่วคราวบนโมเดลที่ถูกกว่าที่คุณกำหนด (Claude Haiku, Codex mini, GPT-4 mini). QA agent จะได้รับเครื่องมือ MCP ของ AgentsRoom : นำทาง, คลิก, พิมพ์, ถ่ายภาพหน้าจอ, ประเมิน, get_logs, get_state.
QA agent รันการทดสอบ
QA agent เปิดหน้าเว็บ, เดินผ่านสถานการณ์, ยืนยันผลลัพธ์, ถ่ายภาพหน้าจอหากจำเป็นและอ่านบันทึกคอนโซลเพื่อตรวจจับข้อผิดพลาดในระหว่างการทำงานที่ agent นักพัฒนาจะพลาด.
QA agent ส่งคำตัดสิน
เมื่อเสร็จแล้ว, QA agent จะเรียก submit_verdict พร้อมผลลัพธ์ที่ผ่าน, ล้มเหลว หรือไม่ชัดเจนและสรุปสั้นๆ. ภาพหน้าจอและบันทึกจะถูกแนบ. กระบวนการ QA agent จะถูกทำลาย. หน้าต่างบริบทของมันจะหายไปด้วย.
Dev agent อ่านคำตัดสินและดำเนินการต่อ
Dev agent จะได้รับคำตัดสินกลับเป็นการตอบสนองต่อ run_qa_test. เมื่อผ่าน, dev agent จะทำการ commit หรือย้ายไปยังตั๋วถัดไป. เมื่อไม่ผ่าน, dev agent จะอ่านสรุปความล้มเหลว, แก้ไขข้อบกพร่องและกระตุ้นรอบการมอบหมาย agent ใหม่. วงจรจะปิดตัวเอง.
เศรษฐศาสตร์ของการมอบหมาย agent
ทำไมการแบ่งงานระหว่าง dev ที่ชาญฉลาดกับ QA จึงช่วยลดค่าใช้จ่าย AI ของคุณโดยไม่ลดมาตรฐานของคุณ.
การทดสอบเบราว์เซอร์เป็นการทำซ้ำ. เปิดหน้าเว็บ, คลิกปุ่ม, อ่านป้าย, ตรวจสอบการแจ้งเตือน. โมเดลที่ราคา 50 ดอลลาร์ต่อหนึ่งล้านโทเคนทำงานได้ดีเท่ากับโมเดลที่ราคา 3 ดอลลาร์ต่อหนึ่งล้านโทเคน. อาจจะดีกว่า, เพราะโมเดลราคาถูกไม่รู้สึกเบื่อ. การมอบหมาย agent ทำให้โมเดลราคาถูกทำงานในครึ่งหนึ่งของงานที่น่าเบื่อ.
ตัวเลขจริงจากเซสชันจริง : การทดสอบแบบ end to end ปกติในกระบวนการที่ซับซ้อนใช้โทเคนระหว่าง 60k ถึง 200k ระหว่างภาพหน้าจอ, การดัมพ์ DOM และขั้นตอนการให้เหตุผล. บน Opus, นั่นคือเงินจริงต่อการทดสอบ. บน Haiku, นั่นคือเงินเปล่า. การมอบหมาย agent เปลี่ยนพฤติกรรม QA รายวันจากความกังวลเรื่องงบประมาณเป็นการตอบสนองฟรี.
คูณด้วยทุกวงจร. วันทำงานปกติของนักพัฒนาบนฟีเจอร์ที่ไม่ธรรมดาจะรันการทดสอบห้าถึงยี่สิบครั้ง. การมอบหมาย agent จะสะสมในระหว่างการทำซ้ำเหล่านั้น. Dev agent ยังคงมีค่าใช้จ่ายสูง (คุณต้องการให้มันมีค่าใช้จ่ายสูง), QA agent ยังคงมีค่าใช้จ่ายต่ำ, และช่องว่างนั้นคือการประหยัดล้วนๆ.
การมอบหมาย agent ยังเป็นมิตรต่อโลกมากขึ้น. การใช้คอมพิวเตอร์น้อยลงในงานเดียวกันหมายถึงการใช้พลังงานน้อยลง, น้ำในศูนย์ข้อมูลน้อยลง, คาร์บอนน้อยลง. ไม่ใช่เหตุผลเดียวในการเชื่อมต่อการมอบหมาย agent, แต่เป็นผลข้างเคียงที่ยุติธรรมของการจัดการงานไปยังโมเดลที่มีขนาดเหมาะสม.
การแบ่งโมเดลจริงสำหรับการมอบหมาย agent
สิ่งที่ผู้คนเชื่อมต่อเข้ากับด้านนักพัฒนาและด้าน QA ของการมอบหมาย agent.
ด้านนักพัฒนา (ตั้งใจให้มีค่าใช้จ่ายสูง)
- Claude Opus 4.7
- Claude Sonnet 4.6
- Codex high reasoning
- GPT-4 ที่มีการให้เหตุผลลึก
- Gemini 3 Pro
ด้าน QA (มอบหมายให้ถูกกว่า)
- Claude Haiku 4
- Claude Sonnet 4 (ความพยายามต่ำ)
- Codex mini
- GPT-4 mini
- Gemini 3 Flash
การมอบหมาย agent ไม่ล็อคเมทริกซ์. คุณกำหนดโมเดล QA ต่อโปรเจกต์. คุณสามารถมอบหมาย agent ไปยังผู้ให้บริการที่แตกต่างกันได้ : Opus บน dev, Codex mini บน QA, ไม่มีบริบทที่แชร์, แค่การเรียก MCP.
สิ่งที่การมอบหมาย agent ทำจริงๆ ภายใต้ฝาก
การมอบหมาย agent นั่งอยู่บนสแต็ก MCP ของ AgentsRoom. Dev agent ทำงานภายใน CLI ของมัน (Claude Code, Codex, Antigravity, OpenCode, Aider, Grok Build, Mistral Vibe, Kimi Code). AgentsRoom จะฉีดเซิร์ฟเวอร์ Test Runner MCP เข้าไปใน agent นั้น. Test Runner จะเปิดเผยเครื่องมือหนึ่ง : run_qa_test. นั่นคือจุดเริ่มต้นของการเรียกการมอบหมาย agent ทุกครั้ง.
เมื่อ run_qa_test ทำงาน, AgentsRoom จะสร้างกระบวนการ CLI ใหม่ในโปรเจกต์เดียวกัน โดยมีการตั้งค่าที่แตกต่างกัน การตั้งค่านั้นมี MCP ของเบราว์เซอร์แนบอยู่, คำสั่งระบบ QA แนบอยู่, และโมเดลถูกเปลี่ยนเป็นสิ่งที่คุณตั้งไว้ในด้าน QA กระบวนการใหม่เป็นตัวแทน QA ชั่วคราว: มันมีชีวิตอยู่ในระยะเวลาของการทดสอบและตายหลังจาก submit_verdict.
ในขณะที่ตัวแทน QA ทำงาน, ตัวแทน dev จะถูกหยุดชั่วคราวที่การเรียก run_qa_test. AgentsRoom แสดงตัวแทน QA ในรายการตัวแทนเดียวกัน, ย่อใต้ตัวแทน dev (มองเห็นในภาพด้านบน). เมื่อตัวแทน QA เสร็จสิ้น, คำตัดสินของมันจะถูกส่งกลับเป็นผลลัพธ์ของ run_qa_test และตัวแทน dev จะกลับมาทำงานต่อ การมอบหมายตัวแทนเป็นการเดินทางรอบ MCP เดียวจากมุมมองของตัวแทน dev.
ตัวแทน dev จะไม่ได้รับเครื่องมือเบราว์เซอร์เลย. AgentsRoom จะลบเครื่องมือ browser_* ออกจากรายการที่อนุญาตของตัวแทน dev ในเวลาที่สร้าง. นั่นคือส่วนที่ทำให้การมอบหมายตัวแทนเชื่อถือได้: ตัวแทน dev ไม่สามารถกลับไปทำการทดสอบเองได้, แม้ว่าความรู้สึกของมันจะต้องการจับภาพหน้าจอ. เส้นทางเดียวที่ไปข้างหน้าคือ run_qa_test. การมอบหมายตัวแทนโดยการลบ, ไม่ใช่โดยการร้องขอ.
ที่ไหนการมอบหมายตัวแทนทำงานในวันนี้, และที่ไหนต่อไป
การมอบหมายตัวแทนใน AgentsRoom เป็นแบบเบราว์เซอร์ก่อนในวันนี้. รูปร่างเดียวกัน, มีพื้นผิวมากขึ้นกำลังมา.
วันนี้: การมอบหมายการทดสอบเบราว์เซอร์
ตัวแทน QA ขับเบราว์เซอร์ที่ฝังอยู่ใน AgentsRoom ผ่าน MCP ของเบราว์เซอร์. เซิร์ฟเวอร์ dev บน localhost, อุโมงค์พรีวิวสาธารณะ, URL staging, อะไรก็ตามที่ Chromium สามารถเรนเดอร์ได้. ฟอร์ม, โมดัล, ลากและวาง, กล่องโต้ตอบ, บันทึกคอนโซล, ข้อผิดพลาดเครือข่าย. การมอบหมายตัวแทนครอบคลุมพื้นผิวทั้งหมดที่วิศวกร QA เว็บจะครอบคลุม.
การมอบหมายการทดสอบแอป Electron
หากคุณส่งแอป Electron เอง, คุณสามารถติดตั้งไลบรารี AgentsRoom Electron MCP ในโปรเจกต์ของคุณ. ตัวแทน QA เชื่อมต่อกับแอป Electron ของคุณในลักษณะเดียวกับที่มันเชื่อมต่อกับแท็บ Chromium. การมอบหมายตัวแทนข้ามเข้าสู่การทดสอบแอปเดสก์ท็อปโดยไม่เปลี่ยนด้าน dev เลย.
การมอบหมายการทดสอบแอป React Native (แผนงาน)
รูปร่างการมอบหมายตัวแทนเดียวกันกำลังจะมาที่ React Native. ตัวแทน QA จะขับซิมูเลเตอร์ iOS หรือ Android ผ่าน AgentsRoom React Native MCP. ตัวแทน dev ส่งหน้าจอ, ตัวแทน QA แตะผ่านมัน. การเรียก run_qa_test เดียวกัน, การส่งต่อจาก dev ไปยัง QA เดียวกัน, เป้าหมายมือถือ.
ไม่มีการมอบหมายตัวแทน vs มีการมอบหมายตัวแทน
ฟีเจอร์เดียวกัน, การผ่าน QA เดียวกัน. บิลที่แตกต่างกัน, บริบทที่แตกต่างกัน, ความเชื่อถือได้ที่แตกต่างกัน.
ไม่มีการมอบหมายตัวแทน
- : ตัวแทน dev (ราคาแพง) เปิดเบราว์เซอร์เอง.
- : ทุกภาพหน้าจอ, ทุกการดึง DOM และทุกบันทึกคอนโซลจะอยู่ในบริบทของตัวแทน dev.
- : 20 นาทีของการคลิกเผาผลาญโทเค็น Opus ในงานที่โมเดลที่ถูกกว่าทำได้.
- : ตัวแทน dev ลืมสิ่งที่มันกำลังทำอยู่หลังจากสองภาพหน้าจอ.
- : คุณจ่ายราคาเต็มสำหรับการคลิกเบราว์เซอร์, โลกจ่ายราคาเต็มเช่นกัน.
ด้วยการมอบหมายตัวแทน
- : ตัวแทน dev เรียก run_qa_test และรอ.
- : ตัวแทน QA ที่ถูกกว่าเป็นผู้คลิก, การยืนยัน, การจับภาพหน้าจอ.
- : เพียงคำตัดสิน (ผ่าน, ล้มเหลว, สรุป) ที่ถึงตัวแทน dev.
- : ตัวแทน QA เป็นชั่วคราว: มันตายหลังจาก submit_verdict, ไม่มีการบวมของบริบท.
- : บิลโทเค็นลดลง, ตัวแทน dev ยังคงมุ่งเน้น, วงจรปิดตัวเอง.
การมอบหมายตัวแทนเป็นการชนะความเชื่อถือได้ที่ถูกที่สุดที่คุณสามารถเชื่อมต่อเข้ากับการตั้งค่าตัวแทนการเขียนโค้ด.
การโทรมอบหมายตัวแทนดูเป็นอย่างไร
นี่คือรูปแบบทั้งหมดของการมอบหมายตัวแทนจากนักพัฒนาสู่ QA ตัวแทนพัฒนาจะส่งสิ่งนี้ผ่าน Test Runner MCP และรอการตอบกลับ
การเรียกเครื่องมือ MCP (ตัวแทนพัฒนา)
run_qa_test({
scenario: "เปิด http://localhost:3000/login.\n พิมพ์ผู้ใช้ทดสอบที่ถูกเตรียมไว้ในฟิลด์อีเมล.\n ส่งแบบฟอร์ม.\n ยืนยันว่า URL แดชบอร์ดถูกเข้าถึงและชื่อผู้ใช้แสดงในส่วนหัว.\n บันทึกภาพหน้าจอเมื่อสำเร็จ บันทึกบันทึกคอนโซลเมื่อไม่สำเร็จ."
})FAQ
การมอบหมายตัวแทนใน AgentsRoom คืออะไร ?
การมอบหมายตัวแทนคือการส่งต่อจากนักพัฒนาสู่ QA ระหว่างตัวแทนการเขียนโค้ด AI สองตัว ตัวแทนพัฒนาจะเสร็จสิ้นฟีเจอร์ เรียกเครื่องมือ MCP เดียว (run_qa_test) และตัวแทน QA ชั่วคราวจะทำการทดสอบบนโมเดลที่แตกต่าง ตัวแทนพัฒนาจะอ่านคำตัดสินและดำเนินการต่อ กระบวนการมอบหมายตัวแทนทั้งหมดเกิดขึ้นผ่านเซิร์ฟเวอร์ MCP ของ AgentsRoom
ทำไมฉันถึงต้องการการมอบหมายตัวแทน ?
สามเหตุผล เงิน: ตัวแทน QA ทำงานบนโมเดลที่ถูกกว่า ดังนั้นการทดสอบที่ผ่านจึงมีค่าใช้จ่ายเพียงเศษเสี้ยวของสิ่งที่พวกเขาจะใช้บนโมเดลพัฒนา บริบท: ตัวแทนพัฒนาจะสะอาด ทุกภาพหน้าจอและการดัมพ์ DOM จะตายไปพร้อมกับตัวแทน QA ความน่าเชื่อถือ: ตัวแทน QA มีงานเดียว ดังนั้นมันจึงทดสอบได้ดีกว่าตัวแทนพัฒนาที่ทำหลายงานพร้อมกันในการคลิกเบราว์เซอร์
โมเดลใดบ้างที่ทำงานสำหรับการมอบหมายตัวแทน ?
โมเดลใดก็ได้ที่ AgentsRoom รองรับ: Claude (Opus, Sonnet, Haiku), Codex (high, mini), Antigravity (Pro, Flash), OpenCode, Aider, Grok Build, Mistral Vibe, Kimi Code การมอบหมายตัวแทนเป็นแบบข้ามผู้ให้บริการ การแบ่งทั่วไปคือ Claude Opus หรือ Codex บนด้านพัฒนาและ Claude Haiku หรือ Codex mini บนด้าน QA แต่คุณเลือกได้
การมอบหมายตัวแทนใช้ได้เฉพาะสำหรับการทดสอบเบราว์เซอร์หรือไม่ ?
วันนี้ ใช่ ตัวแทน QA ขับเบราว์เซอร์ Chromium ที่ฝังอยู่ใน AgentsRoom วันพรุ่งนี้ รูปแบบการมอบหมายตัวแทนเดียวกันจะครอบคลุมแอป Electron (ติดตั้งไลบรารี AgentsRoom Electron MCP ในโปรเจกต์ Electron ของคุณ) และแอป React Native (แผนงาน, ตัวจำลอง iOS และ Android)
การมอบหมายตัวแทนหลีกเลี่ยงไม่ให้ตัวแทนพัฒนาทำการทดสอบเองได้อย่างไร ?
AgentsRoom จะลบเครื่องมือ browser_* ออกจากตัวแทนพัฒนาที่เวลาสร้าง ตัวแทนพัฒนาจริงๆ ไม่สามารถเรียก browser_navigate หรือ browser_screenshot ได้ เส้นทางเบราว์เซอร์เดียวคือ run_qa_test ซึ่งจะเริ่มการมอบหมายตัวแทน ข้อจำกัดนี้เป็นเชิงกล ไม่ใช่คำขอที่สุภาพในคำสั่ง
การมอบหมายตัวแทนเป็นแบบคลาวด์หรือท้องถิ่น ?
เน้นที่ท้องถิ่น ตัวแทนพัฒนา ตัวแทน QA ชั่วคราว สะพาน MCP และเบราว์เซอร์ทั้งหมดทำงานบนเครื่องของคุณ การมอบหมายตัวแทนใช้คลาวด์เฉพาะเมื่อโมเดลพื้นฐาน (Claude, Codex, Antigravity) ติดต่อกับผู้ให้บริการของตนเอง เช่นเดียวกับการเรียกตัวแทนปกติ
การมอบหมายตัวแทนช่วยประหยัดเงินจริงหรือไม่ ?
ใช่ โดยมีปัจจัยที่มีความหมายสำหรับวันที่มี QA หนัก การทดสอบแบบ end-to-end ที่ซับซ้อนบน Opus หรือ Codex high เทียบกับการทดสอบเดียวกันบน Haiku หรือ Codex mini มีความแตกต่างในค่าใช้จ่ายประมาณ 10 เท่า การมอบหมายตัวแทนในวันพัฒนาทั่วทั้งทีมจะขยายช่องว่างนั้นอย่างรวดเร็ว
ตัวแทนพัฒนาจะได้รับอะไรจากการมอบหมายตัวแทน ?
คำตัดสินที่มีโครงสร้างสั้น: ผ่าน, ล้มเหลว หรือไม่ชัดเจน พร้อมกับสรุป เส้นทางภาพหน้าจอที่เลือกได้ และบันทึกคอนโซลที่เลือกได้ ไม่มีภาพหน้าจอดิบในบริบท ไม่มีการดัมพ์ DOM นั่นคือจุดประสงค์ทั้งหมดของการมอบหมายตัวแทน: แยกเสียงรบกวน QA ภายในตัวแทน QA
ตัวแทน QA สามารถสร้างตั๋วค้างเมื่อมันล้มเหลวได้หรือไม่ ?
ใช่ การมอบหมายตัวแทนให้ตัวแทน QA มี Backlog MCP ความล้มเหลวสามารถลงเอยเป็นตั๋วค้างในโครงการ โดยมีสถานการณ์ ภาพหน้าจอ และบันทึกคอนโซลแนบ ตัวแทนพัฒนาจะอ่านคำตัดสินและตั๋วค้างจะมีรายละเอียดในรูปแบบยาว
การมอบหมายตัวแทนอยู่ที่ไหนเมื่อเปรียบเทียบกับฟีเจอร์อื่น ๆ ของ AgentsRoom ?
การมอบหมายตัวแทนอยู่บนสุดของการทำงานอัตโนมัติของเบราว์เซอร์ (ซึ่งให้ตัวแทน QA มีเบราว์เซอร์) และเซิร์ฟเวอร์ MCP ของ AgentsRoom (ซึ่งให้เครื่องมือของตัวแทนแต่ละตัว) Agent Teams คือโปรแกรมแก้ไขการทำงานร่วมกันของหลายตัวแทนที่กว้างขึ้น: การมอบหมายตัวแทนคือรสชาติจากนักพัฒนาสู่ QA ของการทำงานร่วมกันนั้น แต่เปิดเผยเป็นการเรียก MCP เดียวเพื่อให้ตัวแทนใด ๆ ในผู้ให้บริการใด ๆ สามารถใช้ได้โดยไม่ต้องกำหนดกราฟ
เข้ากันได้ดีด้วย
การทำงานอัตโนมัติของเบราว์เซอร์
ชั้น MCP ของ Chromium และเบราว์เซอร์ที่ตัวแทน QA ขับเคลื่อนอยู่ เบราว์เซอร์ที่คงอยู่จริงต่อโปรเจกต์
ทีมตัวแทน
ตัวแก้ไขเวิร์กโฟลว์แบบมัลติเอเจนต์ที่มองเห็นได้ การมอบหมายเอเจนต์คือรสชาติจากนักพัฒนาสู่ QA ส่วน Agent Teams คือเวอร์ชันกราฟเต็มรูปแบบที่มี N โหนดและวงจรฟีดแบ็ก
AgentsRoom MCP
เซิร์ฟเวอร์ MCP ที่ทำให้การมอบหมายเอเจนต์เป็นไปได้: Test Runner, Browser, Backlog, Terminal Commands, Prompt Library
Multi-Provider
เรียกใช้ Claude, Codex, Antigravity, OpenCode, Aider, Grok Build, Mistral Vibe และ Kimi Code ข้างกัน การมอบหมายเอเจนต์คือมุมมองข้ามผู้ให้บริการของแนวคิดเดียวกัน
การใช้โทเค็น Claude Code
มิเตอร์โทเค็นสดต่อเซสชัน วิธีที่เร็วที่สุดในการยืนยันการประหยัดดอลลาร์ที่การมอบหมายเอเจนต์มอบให้คุณในทางปฏิบัติ
Backlog สาธารณะ
เมื่อเอเจนต์ QA ล้มเหลวในการมอบหมายเอเจนต์ บั๊กจะลงที่นี่ ลูกค้าและเพื่อนร่วมทีมเห็นการถดถอย เอเจนต์นักพัฒนาจะหยิบมันขึ้นมา
หยุดจ่ายราคา Opus สำหรับคลิก QA
ดาวน์โหลด AgentsRoom และลองการมอบหมายเอเจนต์ เชื่อมต่อเอเจนต์นักพัฒนาของคุณกับโมเดลที่คุณไว้วางใจ เอเจนต์ QA ของคุณกับโมเดลที่ถูกกว่า และปล่อยให้การส่งต่อจากนักพัฒนาสู่ QA เกิดขึ้นเองผ่าน MCP
แอปคู่หู: ตรวจสอบตัวแทนของคุณได้ทุกที่
นำของคุณเอง: Claude, Codex, Antigravity CLI, หรือผู้ให้บริการ AI อื่น ๆ
ส่งข้อบกพร่องและคำขอไปยังแบ็คล็อกสาธารณะของคุณโดยตรง
มองเห็น AgentsRoom ในการทำงาน