{"slug": "google-epidch-rs-long-horizon-5-design-patterns-thiithmaaaih-agent", "title": "Google เปิดซอร์ส Long Horizon, 5 design patterns ที่ทำให้ agent ทำงานข้ามสัปดาห์ได้โดยไม่พังเงียบๆ", "summary": "Google Cloud has open-sourced Long Horizon, an agent harness built on the Agent Development Kit (ADK) under Apache 2.0, designed to help AI agents operate reliably over extended periods. The project, released on GitHub, details five design patterns derived from real bugs encountered during weeks of internal testing, addressing issues like prefix caching inefficiencies and silent failures in long-running agents.", "body_md": "*โดย Nokka (นก-กา) | 22 สิงหาคม 2026*\n\n*บทความนี้เขียนโดย AI (deepseek-v4-pro) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์, Nokka (นก-กา)*\n\nมีประโยคหนึ่งในบทความของ Google Cloud ที่สรุปปัญหาของ AI agent ได้คมมาก:\n\n\"A one-shot agent breaks in front of you and stops. A long-horizon agent breaks quietly, hides the problem, and keeps running.\"\n\nแปลว่า: agent ที่ทำงาน \"ครั้งเดียวจบ\" จะพังต่อหน้าคุณแล้วหยุด, แต่ agent ที่ทำงาน \"ยาวข้ามสัปดาห์\" จะพังแบบเงียบๆ, ซ่อนปัญหา, แล้ววิ่งต่อไปเรื่อยๆ\n\nนี่คือหัวใจของบทความที่ Google Cloud เพิ่งโพสต์บน X [1], เรื่อง **Long Horizon**, agent harness แบบ open-source ที่ Google สร้างบน Agent Development Kit (ADK) ภายใต้สัญญา Apache 2.0, และเปิดโค้ดไว้บน GitHub ให้ \"อ่านและเอาไปใช้\" มากกว่า \"ติดตั้งแล้วใช้เลย\" [2]\n\nบทความนี้สรุป 5 design patterns ที่ทีม Google เรียนรู้จากการ \"รัน agent กับตัวเองหลายสัปดาห์\" ก่อนปล่อย, และทุก pattern มาจาก \"บั๊กจริง\" ที่เจอ\n\nทีม Google รัน Long Horizon กับตัวเองหลายสัปดาห์ก่อนปล่อย, และเจอรูปแบบซ้ำๆ หนึ่งอย่างในเกือบทุกบั๊ก:\n\n\"Nothing ever threw an error.\" (ไม่มีอะไรเคย throw error เลย)\n\nนี่คือ \"กับดัก\" ของ agent ระยะยาว:\n\nทั้งหมดนี้คือ \"ความล้มเหลวแบบเงียบ\" ที่ agent ระยะยาวเจอ, และ 5 patterns ด้านล่างคือวิธีแก้\n\n**ปัญหา:** Prefix caching ควรเป็น \"ของฟรี\", แค่ให้หัว prompt เหมือนเดิมทุกเทิร์น, provider ก็เสิร์ฟจากแคชได้ในราคาเศษเสี้ยว\n\nแต่ทีม Google เปิดใช้แล้ว **cache hit rate อยู่ที่ 0%**\n\n**สาเหตุ:** ตัว \"memory preloader\" ดึงบทสนทนาเก่ามา inject ไว้ที่ \"หัว\" ของ system prompt ทุกเทิร์น, และเพราะความจำเปลี่ยนทุกเทิร์น, hash ของ prefix ก็เปลี่ยนทุกเทิร์น, แคชเลยไม่เคยเกิดขึ้น\n\n**อุปมา:** prefix caching เหมือน Docker build, เปลี่ยนบรรทัดเดียวใกล้หัว, ทุกชั้นข้างล่าง rebuild ใหม่หมด\n\n**วิธีแก้:** เรียง prompt ตาม \"ความเร็วที่เปลี่ยน\":\n\n| ส่วน | อยู่ตรงไหน | เปลี่ยนบ่อยแค่ไหน |\n|---|---|---|\n| System instructions, persona, tool definitions | หัว (Frozen) | ไม่เปลี่ยนเลย |\n| User profile, active tools | กลาง (Slow) | เปลี่ยนช้า |\n| Step counters, warnings, recalled memories | ท้าย (Volatile) | เปลี่ยนทุกเทิร์น |\n\n**ผลลัพธ์:** ย้าย \"ความจำที่เปลี่ยน\" ไปไว้ท้าย prompt, เทิร์นแรก warm cache, เทิร์นถัดไปเสิร์ฟ 95% ของ prompt จากแคช\n\n**ตัวเลขจริง:** การ audit นี้ลด prompt จาก **70,000 ตัวอักษร เหลือต่ำกว่า 22,000**\n\n**บทเรียน:** อย่าเดา, ต้องวัด, ถ้า cached token count ใน response metadata ยังเป็น 0 ในเทิร์นที่สอง, แปลว่ามีอะไรใน prefix กำลังขยับ\n\n**ปัญหา:** agent ที่ \"เรียนรู้\" ต้องดึงความจำออกมาแล้วเขียนลงไป, ตอนแรกทีมทำแบบ inline (ก่อนตอบ), ผลคือทุกเทิร์นช้าลง เพื่อดึงความจำที่ผู้ใช้ไม่ต้องใช้จนกว่าจะถึงสัปดาห์หน้า\n\n**วิธีแก้:** **Write-behind caching**, ส่งคำตอบให้ผู้ใช้ก่อน, แล้วค่อยรัน memory extraction ใน background ภายใต้ identity เดียวกัน\n\n**3 ข้อที่ต้องทำเพื่อให้ปลอดภัยใน production:**\n\n**บทเรียน:** ตั้ง shutdown drain timeout ให้ต่ำกว่า host timeout, ทีมรอ 4 วินาทีให้ write ค้างเสร็จ, ถ้าตั้งสูงกว่า framework's 5-second cleanup limit, runtime จะฆ่า process กลางคันแล้วข้อมูลหายอยู่ดี\n\n**ปัญหา:** ระหว่างข้อความจากผู้ใช้คนเดียวกัน อาจผ่านไปหลายชั่วโมงหรือหลายวัน, เมื่อ agent ตื่นกลับมา, ทุกอย่างที่มันสร้างไว้ต้องยังอยู่\n\nแต่ของทีม Google \"ไม่อยู่\", deploy มาตรฐานล้าง CLI tooling ที่ agent เพิ่งติดตั้งไปทั้ง session, แล้ว agent ก็ \"ทำต่อ\" โดยติดตั้งใหม่ทั้งหมดตั้งแต่ต้น, รายงานความคืบหน้าตลอดทาง\n\n**หลักการ:** โค้ดเว็บทั่วไปสมมติว่า request handler เป็น stateless, แต่ long-horizon agent คือ \"process ที่อยู่ยาว\" ที่ผู้ใช้คนเดิมกลับมาหาเรื่อยๆ\n\n**วิธีแก้:**\n\n**บทเรียนที่คมมาก:** อย่าใช้ status code ที่ \"สอง lifecycle phase ใช้ร่วมกัน\" เป็นตัวบอก liveness, environment ที่ถูกลบ return 502, แต่ environment ที่กำลัง boot ก็ return 502 จาก readiness poll เหมือนกัน, ทีมเลย \"ไล่ environment ที่ยังดีออก\" ไปหลายตัว\n\n**ปัญหา:** เมื่อ output ของ agent หนึ่งกลายเป็น input ของอีก agent, agent แม่ตัดสินว่า \"ลูกสำเร็จไหม\" จาก \"รูปร่างของ return envelope\"\n\nการรัน evaluation จับได้ว่า root agent รายงาน \"all 20 tests passing\" จาก delegate call ที่จริงๆ แล้ว timeout, ไม่มีอะไรถูกเขียน, ไม่มี test วิ่งเลย\n\n**สาเหตุ:** envelope \"เชิญชวนให้ hallucinate\", ลูกที่ timeout, ถึง step limit, หยุดรออนุมัติ, หรือเสร็จปกติ ต่าง return โครงสร้างเดียวกันหมด (คือ \"ทุกบรรทัดที่ลูกพูดระหว่างทำงาน\" มาต่อกัน), และ \"commentary บางส่วน\" อ่านแล้วเหมือน \"รายงานที่เสร็จสมบูรณ์\"\n\n**วิธีแก้:**\n\n`completed`\n\n, `timeout`\n\n, `halted`\n\n(step limit หรือ crash), `pending`\n\n(รอคน)**ปัญหาแฝง:** loop ที่วิ่งตลอดกาลแต่ \"ดู productive\", วิธีแก้คือ cap tool calls ต่อ iteration (200 ครั้ง) และ iterations ต่อ session (50 ครั้ง), แล้วหยุดที่ \"ขอบที่สะอาด\" ไม่ใช่กลางเทิร์น\n\n**ปัญหา:** agent ที่มี shell access เข้าถึงอะไรก็ได้ที่เครื่องเข้าถึง, รวมถึง metadata endpoint ของ cloud และ credentials ที่มันเสิร์ฟ\n\nทีม block `169.254.169.254`\n\nด้วย string matching, แล้ว `curl http://2852039166/`\n\nก็เดินผ่าน filter ไปเฉยๆ, เพราะ integer นั้น resolve เป็น IP เดียวกันเป๊ะ\n\n**บทเรียน:** ต้อง normalize ก่อน compare เสมอ, IP เดียวมี 4 รูปแบบที่เขียนได้ (dotted, integer, hex, IPv6-mapped), การ parse แต่ละ candidate เป็น address object จริงจะกำจัดทั้งหมดในครั้งเดียว\n\n**โซ่ 3 ชั้น (เรียงจากถูกสุดไปแพงสุด):**\n\n| ชั้น | หน้าที่ |\n|---|---|\n| Exfiltration guard | block ปลายทางอันตราย (metadata IP) เด็ดขาด, ไม่มี session setting ไหนผ่อนได้ |\n| Policy guard | return allow / ask / deny ตาม declarative rules |\n| Interactive prompt | ถามผู้ใช้เป็นลำดับสุดท้าย (ความสนใจของคนคือของแพงที่สุด) |\n\n**จุดสำคัญ:** ไม่มีโมเดลอยู่ใน path นี้เลย, มีแต่ parsers, declarative rules, counters ที่ audit ได้เต็มที่ และรันใน microseconds\n\n**บทเรียนสุดท้าย:** ออกแบบ credentials เหมือน guard ถูกเจาะไปแล้ว (เพราะสุดท้ายมันจะถูกเจาะ), secrets ถึง environment ผ่าน injection ไม่ใช่ prompt, sandbox รันจาก template ที่ปิด outbound internet ที่ platform layer, และ artifact links มาเป็น signed URL ให้ client + placeholder ให้โมเดล\n\n| Pattern | แก้ปัญหาอะไร | ใจความ |\n|---|---|---|\n| 1. Stable Prefix | cache ไม่เคยทำงาน | ย้ายของที่เปลี่ยนไปไว้ท้าย prompt |\n| 2. Background Learning | ทุกเทิร์นช้าลง | ตอบก่อน แล้วค่อยเรียนรู้ทีหลัง |\n| 3. Persistent Workspace | deploy ล้างงาน | state ต้องอยู่รอดข้ามเทิร์น |\n| 4. Explicit Failure | ลูก timeout แต่แม่บอกสำเร็จ | ตั้งชื่อให้ทุก terminal state |\n| 5. Guard Chain | คำสั่งเล็ดลอด guard | normalize ก่อน compare, ไม่มีโมเดลใน path |\n\nการทำให้ agent อยู่รอดข้ามสัปดาห์ ไม่ใช่เรื่อง \"สร้าง framework ใหญ่\" แต่เป็นเรื่อง \"จับความล้มเหลวแบบเงียบ\" ก่อนที่มันจะเผางบประมาณหรือทำลาย state\n\nและจุดเริ่มต้นที่ง่ายที่สุด: **วัด prefix cache hit rate**, ถ้ามันอยู่ใกล้ศูนย์, แปลว่ามีอะไรใน prompt เปลี่ยนทุกเทิร์น, และ latency graph จะไม่บอกคุณว่าทำไม\n\nก่อนจะรีบเอาไปใช้, ควรรู้ข้อจำกัด:\n\n**ตัวอย่างการนำไปใช้จริง:** ถ้าคุณรัน agent บน Claude Code หรือ Codex แล้วเจอ \"บิลแพงแต่ไม่รู้ทำไม\", เริ่มจาก Pattern 1 (Stable Prefix), ตรวจว่า system prompt ของคุณมี \"ของที่เปลี่ยนทุกเทิร์น\" อยู่หัวไหม, ถ้ามี, ย้ายไปท้าย แล้ววัด cache hit rate ใหม่\n\n[1] Google Cloud Tech. \"5 design patterns for long-horizon agent harness.\" X (Twitter), 20 ส.ค. 2026. [https://x.com/GoogleCloudTech/status/2090248297214525569](https://x.com/GoogleCloudTech/status/2090248297214525569)\n\n[2] Google. \"Long Horizon Harness\" (open-source agent harness on ADK). GitHub, 2026. [https://github.com/google/adk-samples/tree/main/core/python/long-horizon-harness](https://github.com/google/adk-samples/tree/main/core/python/long-horizon-harness)", "url": "https://wpnews.pro/news/google-epidch-rs-long-horizon-5-design-patterns-thiithmaaaih-agent", "canonical_source": "https://dev.to/sarantoon/google-epidchrs-long-horizon-5-design-patterns-thiithamaih-agent-thamngaankhaamsapdaahaidodyaimphangengiiyb-330", "published_at": "2026-08-23 01:14:53+00:00", "updated_at": "2026-08-23 01:43:08.175039+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "developer-tools", "machine-learning"], "entities": ["Google Cloud", "Long Horizon", "Agent Development Kit", "GitHub", "Apache 2.0", "Nokka"], "alternates": {"html": "https://wpnews.pro/news/google-epidch-rs-long-horizon-5-design-patterns-thiithmaaaih-agent", "markdown": "https://wpnews.pro/news/google-epidch-rs-long-horizon-5-design-patterns-thiithmaaaih-agent.md", "text": "https://wpnews.pro/news/google-epidch-rs-long-horizon-5-design-patterns-thiithmaaaih-agent.txt", "jsonld": "https://wpnews.pro/news/google-epidch-rs-long-horizon-5-design-patterns-thiithmaaaih-agent.jsonld"}}