<div class="key-takeaways"><ul><li>หลีกเลี่ยงการทดสอบ AI Agent ด้วยการตรวจสอบประโยคสุดท้ายแบบตายตัว</li><li>ชุดทดสอบที่ดีควรมี 4 เลเยอร์ ตั้งแต่ Unit Tests ไปจนถึง Human-reviewed evals</li><li>แยกการวัดผลระหว่าง Hard constraints และ Soft quality ออกจากกัน</li><li>ใช้งาน Live-model evaluations เฉพาะเมื่อจำเป็นต้องอาศัยการตัดสินใจเชิงความหมาย</li></ul></div><p>การทำให้การทดสอบ AI-agent กลายเป็นเรื่องเปราะบางและพังง่ายที่สุด คือการเขียนโค้ดเพื่อตรวจสอบประโยคสุดท้ายที่โมเดลตอบกลับมา ยกตัวอย่างเช่น เมื่อผู้ใช้ป้อนคำสั่งค้นหาโรงแรมในปารีส โมเดลอาจตอบกลับด้วยข้อความที่แตกต่างกันเล็กน้อยในแต่ละครั้ง แม้พฤติกรรมการทำงานของระบบจะถูกต้อง แต่การทดสอบกลับล้มเหลวทันที</p><p>เครื่องมือ Agent Development Kit (ADK) ของ Google เข้ามาช่วยยกระดับให้นักพัฒนาสามารถจัดการกับเอเจนต์ได้ใกล้เคียงกับการพัฒนาซอฟต์แวร์ทั่วไปมากขึ้น โดยรวบรวมทั้งองค์ประกอบของเอเจนต์ เครื่องมือ การประสานการทำงาน เซสชัน เหตุการณ์ การประเมิน และการปรับใช้ให้อยู่ในรูปของโค้ดและรันไทม์พริมทิฟ อย่างไรก็ตาม สิ่งนี้ไม่ได้ทำให้โมเดลกลายเป็นระบบแบบ Deterministic แต่เป็นการมอบพื้นที่ที่ดีกว่าเพื่อให้เราสร้างสัญญาการทำงานที่แน่นอนรอบตัวโมเดลได้</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/google_adk_typescript_agents_mthhtudx_inline_1_82ee7b16df.jpg" alt="software engineering architecture diagram whiteboard" loading="lazy" /><p class="color-gray-500 text-sm mt-10">ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง</p></div><p>หลักการสำคัญคือ อย่าทดสอบบุคลิกภาพของเอเจนต์ แต่ให้มุ่งเน้นไปที่การทดสอบการตัดสินใจและขอบเขตการทำงาน ชุดทดสอบเอเจนต์ที่มีประสิทธิภาพควรประกอบด้วยโครงสร้าง 4 เลเยอร์หลักตามลำดับความสำคัญ:</p><ul><li>Small human-reviewed evals: การประเมินโดยมนุษย์ในสเกลเล็ก</li><li>End-to-end trajectory scenarios: สถานการณ์จำลองการทำงานตั้งแต่ต้นจนจบ</li><li>Runtime contracts: สัญญาการทำงานของรันไทม์ ได้แก่ นโยบาย, สถานะ และสรีมา</li><li>Deterministic unit tests for tools and adapters: ยูนิตเทสแบบกำหนดผลลัพธ์ได้แน่นอนสำหรับเครื่องมือและอะแดปเตอร์</li></ul><p>การทดสอบส่วนใหญ่ควรเกิดขึ้นที่เลเยอร์ล่างสุด เนื่องจากมีความรวดเร็ว ต้นทุนต่ำ และให้ผลลัพธ์ที่แน่นอน นักพัฒนาควรเลือกใช้การประเมินแบบ Live-model อย่างตั้งใจและหลีกเลี่ยงการใช้กับทุกๆ การยืนยันผลลัพธ์</p><div class="ai-insight"><p>การทำความเข้าใจสถาปัตยกรรมแบบ 4 เลเยอร์ของ ADK ช่วยให้ทีมพัฒนาซอฟต์แวร์สามารถบริหารจัดการต้นทุนและเวลาในการรัน Test Suite ได้อย่างมีประสิทธิภาพ เพราะการเรียกโมเดลภาษาขนาดใหญ่ (LLM) ในทุกๆ ยูนิตเทสไม่เพียงแต่สิ้นเปลืองค่าใช้จ่าย แต่ยังทำให้กระบวนการ CI/CD ช้าลงอย่างมาก การผลักภาระการทดสอบส่วนใหญ่ไปที่ Deterministic unit tests จึงเป็นแนวทางปฏิบัติสากลที่นำมาปรับใช้ได้กับทุกแพลตฟอร์ม AI</p></div><p>สำหรับเครื่องมือใน ADK TypeScript สามารถแสดงผลได้ผ่าน FunctionTool ร่วมกับ Zod parameter schema ในขณะที่ฟังก์ชันธุรกิจที่อยู่เบื้องหลังยังคงเป็นโค้ด TypeScript ธรรมดาที่ควรได้รับการทดสอบด้วยวิธีการทั่วไป สำหรับการทดสอบแบบ Integration test นักพัฒนาควรเรียกใช้งาน ADK agent พร้อมทั้งรวบรวมเหตุการณ์ทั้งหมด จากนั้นแปลงเหตุการณ์ภายในของเฟรมเวิร์กให้เป็นข้อมูลสรุปที่เป็นของแอปพลิเคชัน เพื่อป้องกันไม่ให้ชุดทดสอบผูกติดกับรายละเอียดภายในของแต่ละอีเวนต์</p><p>การทดสอบเส้นทางที่มีความสุขหรือ Happy-path prompts นั้นไม่เพียงพอต่อการใช้งานจริง ความล้มเหลวในระบบโปรดักชันมักเกิดขึ้นที่ขอบเขตระหว่างคำขอที่ดูสมเหตุสมผลกับการกระทำที่ไม่ปลอดภัย การทดสอบความปลอดภัยที่ดีควรผ่านได้เพราะนโยบายของแอปพลิเคชันบล็อกการกระทำนั้นไว้ ไม่ใช่เพราะโมเดลปฏิเสธไปเองตามความบังเอิญ</p><p>เมื่อโค้ดส่วนปลายทางจำเป็นต้องพึ่งพาวัตถุตอบ a ในรูปแบบที่เอเจนต์สร้างขึ้น นักพัฒนาควรปฏิบัติต่อสิ่งนั้นเสมือนเป็นผลลัพธ์จากภายนอก API สถานการณ์ที่มีคุณค่ามากที่สุดมักมาพร้อมกับเหตุการณ์ความผิดพลาดในอดีต หากเอเจนต์เลือกเครื่องมือผิด ทำการแจ้งเตือนซ้ำ ข้ามขั้นตอนการยืนยัน หรือปฏิบัติกับผลลัพธ์ว่างเปล่าเสมือนเป็นความผิดพลาด ทีมควรบันทึกข้อมูลเส้นทางดังกล่าวโดยมีการปกป้องความเป็นส่วนตัว แล้วนำไปเพิ่มลงในชุดข้อมูลรีเกรสชัน</p><p>แม้เครื่องมือที่กว้างขวางของ ADK จะช่วยสนับสนุนการประเมินและการให้คะแนน แต่แอปพลิเคชันยังคงต้องการกฎเกณฑ์การผ่านหรือตกที่ชัดเจนคะแนนคุณภาพรวมเพียงตัวเดียวไม่ควรถูกนำมาใช้เพื่อปกปิดการเรียกใช้เครื่องมือที่ถูกห้าม ทีมพัฒนาควรแยกการติดตามข้อจำกัดที่เข้มงวดออกจากคุณภาพแบบยืดหยุ่น:</p><ul><li>Hard: ห้ามเขียนข้อมูลโดยไม่ได้รับอนุญาต, สรีมาต้องถูกต้อง, การยืนยันต้องครบถ้วน</li><li>Soft: ความเกี่ยวข้อง, ความสมบูรณ์, น้ำเสียง, ความกระชับ</li><li>Operational: ค่าความหน่วง, จำนวนครั้งที่เรียกใช้โมเดลและเครื่องมือ, การลองใหม่, ต้นทุนที่ประเมินไว้</li></ul><p>การแยกส่วนนี้ช่วยให้ความล้มเหลวสามารถนำไปดำเนินการแก้ไขต่อได้ทันที เนื่องจากปัญหาเรื่องน้ำเสียงและปัญหาการจองที่ไม่ได้รับอนุญาตมีความรุนแรงที่แตกต่างกันอย่างสิ้นเชิง การทดสอบเอเจนต์จึงไม่ใช่การแกล้งทำเป็นว่าโมเดลมีความแน่นอน แต่เป็นการทำให้ระบบรอบตัวโมเดลมีความชัดเจนต่างหาก</p><p class="source-attribution">ที่มา: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/raju_dandigam/testing-google-adk-typescript-agents-without-chasing-sentences-3d25" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

<div class="key-takeaways"><ul><li>Avoid making brittle assertions on final sentences returned by AI agents.</li><li>A robust agent test suite requires four distinct architectural layers.</li><li>Separate hard constraints from soft quality metrics for actionable error tracking.</li><li>Use live-model evaluations deliberately only when semantic judgment is required.</li></ul></div><p>The fastest way to make an AI-agent test flaky is to assert the final sentence of its response. For instance, when asking an agent to look for hotel options in Paris, the model might return a slightly different conversational phrasing each time. Even though the underlying system behavior is completely correct, the automated test fails red.</p><p>Google's Agent Development Kit (ADK) brings agents closer to conventional software engineering by representing agents, tools, orchestration, sessions, events, evaluation, and deployment as code and runtime primitives. This does not magically make the underlying language model deterministic; instead, it provides better architectural places to establish deterministic contracts around it.</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/google_adk_typescript_agents_mthhtudx_inline_1_82ee7b16df.jpg" alt="software engineering architecture diagram whiteboard" loading="lazy" /><p class="color-gray-500 text-sm mt-10">Stock photo for illustration only, not from the actual event</p></div><p>Do not test the agent's personality. Test its decisions and execution boundaries. A useful agent test suite relies on four structured layers:</p><ul><li>Small human-reviewed evals</li><li>End-to-end trajectory scenarios</li><li>Runtime contracts: policy, state, and schema</li><li>Deterministic unit tests for tools and adapters</li></ul><p>Most tests should live near the bottom of this stack because they are fast, cheap, and strictly deterministic. Live-model evaluations should be used deliberately rather than for every single assertion.</p><div class="ai-insight"><p>Understanding ADK's four-layer testing model helps engineering teams optimize CI/CD pipelines and control operational costs. Invoking large language models for every micro-test is computationally expensive and introduces unnecessary latency. Shifting the testing burden toward deterministic unit tests is an industry-standard practice adaptable to various AI frameworks.</p></div><p>ADK TypeScript tools can be expressed using FunctionTool alongside a Zod parameter schema. The business logic underneath remains ordinary TypeScript and should be tested accordingly. For integration testing, engineers should run the ADK agent, collect its events, and convert framework events into an application-owned summary to prevent tests from coupling to internal event details.</p><p>Happy-path prompts alone are never sufficient. Production failures typically lurk at the boundary where a plausible request meets an unsafe action. An ideal safety test passes because an application policy successfully blocked the execution, rather than relying on the model declining it by chance.</p><p>When downstream code relies on an agent-produced object, treat it like an external API response. Valuable testing scenarios often emerge from real-world incidents. If an agent selects the wrong tool, duplicates a notification, skips confirmation, or mishandles empty results, developers should preserve a privacy-safe version of that trajectory and add it to a regression dataset.</p><p>While ADK's broader tooling supports scoring and evaluation, applications still require explicit pass/fail rules. A single aggregate quality score must never mask a prohibited tool call. Hard constraints should be tracked separately from soft quality metrics:</p><ul><li>Hard: no unauthorized write, valid schema, confirmation preserved</li><li>Soft: relevance, completeness, tone, concision</li><li>Operational: latency, model calls, tool calls, retries, estimated cost</li></ul><p>This strict separation makes failures actionable, ensuring that a minor tone regression and an unauthorized booking are handled with appropriate severity levels. Agent testing is ultimately about making the system surrounding the model explicit rather than pretending the model itself is deterministic.</p><p class="source-attribution">Source: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/raju_dandigam/testing-google-adk-typescript-agents-without-chasing-sentences-3d25" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

medium_เทคนิคทดสอบ-google-adk-typescript-agents-ไม่ให้พังง่าย-mthhtudx.jpg

small_เทคนิคทดสอบ-google-adk-typescript-agents-ไม่ให้พังง่าย-mthhtudx.jpg

thumbnail_เทคนิคทดสอบ-google-adk-typescript-agents-ไม่ให้พังง่าย-mthhtudx.jpg

เทคนิคทดสอบ-google-adk-typescript-agents-ไม่ให้พังง่าย-mthhtudx.jpg

แนวทางการทดสอบระบบ AI Agents ด้วย Google Agent Development Kit (ADK) ผ่าน TypeScript และ Zod โดยเน้นที่การตัดสินใจ การสร้างสัญญาการทำงาน และกฎความปลอดภัยที่ชัดเจน

Inewgen

Inewgen

#Zod

เทคนิคทดสอบ Google ADK TypeScript Agents ไม่ให้พังง่าย

Inewgen