Google ADK Long-running Agents: Agent ที่หยุดรอได้ กลับมาทำต่อได้ และไม่ลืม Context

AI agent demo ส่วนใหญ่จบใน 5 นาทีครับ

ถามคำถามหนึ่งครั้ง เรียก tool หนึ่งครั้ง ตอบกลับหนึ่งครั้ง ทุกอย่างดูสวยมากใน workshop

แต่พอเอาเข้าธุรกิจจริง งานจำนวนมากไม่ได้จบในหนึ่ง API call

งานจริงมีช่วง “รอ” เยอะมาก

รอคนเซ็นเอกสาร

รอ vendor ตอบกลับ

รอของส่งถึงปลายทาง

รอหัวหน้า approve

รอลูกค้า confirm requirement

รอทีมบัญชีปิดยอด

รอระบบภายนอกส่ง webhook กลับมา

คำถามคือ ถ้า agent ต้องหยุดรอ 3 วัน แล้วกลับมาทำต่อ มันยังจำได้ไหมว่าถึงขั้นตอนไหนแล้ว?

Google Developers Blog เพิ่งเผยแพร่บทความ Build Long-running AI agents that pause, resume, and never lose context with ADK วันที่ 12 May 2026 โดยใช้ตัวอย่าง New Hire Onboarding Agent ที่ทำงานข้ามวัน/ข้ามทีม/ข้ามระบบด้วย Google ADK

ผมว่าบทความนี้น่าสนใจเพราะมันไม่ได้พูดแค่ “ทำ agent ให้ตอบเก่งขึ้น”

แต่มันพูดเรื่องที่ใกล้ production มากกว่า:

ทำอย่างไรให้ agent เป็น background workflow ที่หยุดรอได้ กลับมาทำต่อได้ และไม่หลง context

นี่คือคนละโจทย์กับ chatbot ครับ

1) ปัญหาของ stateless chatbot: คุยได้ แต่ทำงานข้ามวันไม่รอด

pattern ที่หลายระบบเริ่มต้นใช้คือเอา message history ทั้งหมดใส่กลับเข้า prompt ทุกครั้ง

ช่วง demo สั้น ๆ วิธีนี้พอไปได้

แต่พอ workflow ยาวเป็นวันหรือสัปดาห์ มันเริ่มพังด้วย 3 อาการหลัก

1.1 Context pollution

หลังจากคุยกันหลายร้อย turn, chat history จะเต็มไปด้วยข้อความเก่า tool output เก่า instruction ซ้ำ และ noise ที่ไม่เกี่ยวกับ decision ปัจจุบัน

model เริ่มสับสนว่า step ไหนเสร็จแล้ว step ไหนยังไม่เสร็จ

อาการนี้อันตรายมากสำหรับงาน operation เพราะ agent อาจพูดเหมือนจำได้ แต่จริง ๆ กำลังเดาจากข้อความเก่า

1.2 Token cost explosion

ถ้าทุก inference ต้องยัดประวัติ 2 สัปดาห์กลับเข้า prompt ตลอด ค่า token จะบานเร็วมาก

ยิ่ง workflow ที่มีหลายฝ่าย หลาย tool หลาย event ยิ่งหนัก

ต้นทุนไม่ได้เพิ่มตาม “คุณค่า” ของ decision ปัจจุบัน แต่เพิ่มตาม “ความยาวของอดีต”

ซึ่งไม่ค่อย healthy สำหรับระบบจริง

1.3 Hallucination over idle time

จุดนี้ผมเจอบ่อยในงาน agent จริงครับ

เมื่อ agent หยุดไปหลายวันแล้ว resume ด้วย context dump ก้อนใหญ่ model อาจ hallucinate ว่า intermediate step บางอย่างเกิดขึ้นแล้ว

เช่น:

• คิดว่า approval ผ่านแล้ว ทั้งที่ยังไม่มีใคร approve
• ข้ามขั้นเพราะเห็นข้อความเก่าว่า “น่าจะส่งแล้ว”
• จำผิดว่า vendor ตอบกลับมาแล้ว
• เรียก tool ซ้ำทั้งที่ tool นั้นมี side effect

Google บอกชัดในบทความว่า fix ไม่ใช่ “ใช้ context window ใหญ่ขึ้น”

แต่ต้องเปลี่ยน architecture ให้ state ของงาน explicit, durable และแยกออกจาก raw chat history

แปลเป็นภาษาธุรกิจ:

อย่าให้ LLM เป็นสมุดจดสถานะงาน

ให้ LLM เป็นคนตัดสินใจจากสถานะงานที่ระบบเก็บไว้อย่างตรวจได้

2) ตัวอย่างจาก Google: New Hire Onboarding Agent

บทความใช้ use case การ onboard พนักงานใหม่

flow แบบง่าย ๆ คือ:

1. HR ส่ง welcome packet และ document links
2. agent หยุดรอหลายวันระหว่าง employee เซ็นเอกสาร
3. เมื่อเอกสารถูกเซ็น webhook ปลุก agent กลับมา
4. agent delegate งานให้ IT sub-agent provision email/Slack account
5. agent หยุดรอ laptop ถูกส่งถึงบ้านพนักงาน
6. เมื่อ hardware delivered แล้ว agent ส่ง personalized day-one schedule

นี่คือ workflow ที่ chatbot ทั่วไปไม่ค่อยถนัด

เพราะมันไม่ใช่ conversation เดียว

มันคือ process ที่มี:

• pause/resume หลายรอบ
• human approval gate
• external event
• cross-team handoff
• state ที่ต้องอยู่รอดจาก container restart
• audit trail ว่าใคร/อะไรทำให้ step เปลี่ยน

ถ้าเรามองให้กว้างขึ้น pattern เดียวกันใช้กับงานอื่นได้เยอะมาก เช่น invoice dispute, procurement approval, sales prospecting sequence, customer onboarding, compliance audit หรือ support case ที่ต้องรอ vendor ตอบ

3) Shift แรก: จาก chat history เป็น state machine

แกนของบทความคืออย่าให้ agent จำว่าถึงไหนแล้วจากบทสนทนา

ให้เขียน state machine ชัด ๆ แทน

ในตัวอย่าง onboarding, Google ใช้ checkpoint ประมาณนี้:

START
WELCOME_SENT
DOCUMENTS_SIGNED
IT_PROVISIONED
HARDWARE_DELIVERED
COMPLETED

ฟังดูธรรมดา แต่นี่แหละครับของสำคัญ

เพราะเมื่อ state ถูกนิยามชัด agent จะไม่ต้องเดาว่า “เอกสารถูกเซ็นหรือยัง” จากข้อความเก่า

มันอ่านจาก current_step ใน session state

ถ้า current_step = WELCOME_SENT agent รู้ว่าต้องรอ document signature และห้ามข้ามไป provision account

ถ้า current_step = DOCUMENTS_SIGNED agent ถึงค่อย delegate ให้ IT agent

ความต่างคือ:

• chatbot แบบเดิม: “ลองอ่านข้อความเก่าแล้วเดาว่าควรทำอะไรต่อ”
• workflow agent: “อ่าน state ปัจจุบัน แล้วทำ action ที่อนุญาตตาม state machine”

ผมชอบมุมนี้มาก เพราะมันเอา LLM กลับไปอยู่ในตำแหน่งที่เหมาะสม

LLM เก่งเรื่อง reasoning, language, decision support

แต่ state ของงานควรอยู่ในระบบที่ deterministic และ audit ได้

4) Shift ที่สอง: persistent sessions ไม่ใช่ memory ลอย ๆ

state machine จะไม่มีค่าเลยถ้า state หายตอน server restart

ใน local demo, Google เปลี่ยนจาก in-memory session ไปใช้ DatabaseSessionService ที่ backed by SQLite

ใน production ก็เปลี่ยนเป็น Cloud SQL connection string ได้โดยไม่ต้องเปลี่ยน concept ใหญ่

ประเด็นคือทุกครั้งที่ tool เขียนค่าเข้า ToolContext.state ระบบจะ persist state delta ไว้

เช่น tool send_welcome_packet ทำ 3 อย่าง:

• เก็บข้อมูลพนักงานใหม่ เช่น name, email, start date
• เปลี่ยน current_step เป็น WELCOME_SENT
• เพิ่ม pending signal เช่น document_signed

ถ้า container crash หลังส่ง welcome packet agent ไม่ควรเริ่มใหม่จากศูนย์

เมื่อ restart แล้วมันควรอ่าน state กลับมาได้ว่า:

current_step = WELCOME_SENT
pending_signals = [document_signed]
new_hire_details = {...}

นี่ต่างจากการบอกว่า “มี vector database เป็น memory” มากครับ

vector DB ช่วยค้นความรู้หรือข้อความที่เกี่ยวข้องได้

แต่ workflow state ต้องเป็น structured state ที่มี schema ชัดเจน

ถ้าจะให้ agent ทำงาน operation จริง ผมจะแยก mental model แบบนี้:

• Knowledge memory: ข้อมูลอ้างอิง นโยบาย คู่มือ เอกสาร
• Workflow state: งานนี้ถึงขั้นไหนแล้ว ใคร approve แล้ว event ไหนรออยู่
• Event log: อะไรเกิดขึ้นเมื่อไหร่ ใคร/ระบบไหนเป็นคน trigger
• Artifact: ไฟล์ ผลลัพธ์ เอกสาร ใบเสนอราคา ticket invoice

อย่าเอาทุกอย่างไปกองรวมกันแล้วเรียกว่า “memory” ครับ

ทำแบบนั้น debug ยากมาก

5) Shift ที่สาม: event-driven dormancy — agent ต้องหลับเป็น

คำว่า long-running agent ไม่ได้แปลว่า process ต้อง run ตลอด 24 ชั่วโมง

อันนี้สำคัญ

ในงานจริง agent ควร “หลับ” ระหว่างรอ idle time

ไม่ควร polling ทุก 5 นาทีแบบสิ้นเปลือง

ไม่ควร block thread ค้างไว้ 3 วัน

ไม่ควรให้ LLM คิดวน ๆ ว่า “ตอนนี้เอกสารถูกเซ็นหรือยังนะ”

pattern ที่ Google ใช้คือ webhook

เช่น เมื่อเอกสารถูกเซ็น ระบบภายนอกยิง webhook มาที่ endpoint /webhooks/document_signed

จากนั้น resume handler จะ:

1. hydrate session จาก persistent storage
2. apply state_delta เช่น current_step = DOCUMENTS_SIGNED
3. เรียก runner.run_async(...) เพื่อปลุก agent
4. agent อ่าน state ใหม่แล้วทำ step ต่อไป

ตรงนี้คือจุดที่ agent เริ่มเหมือน workflow worker มากกว่า chatbot

มันไม่ได้ “จำ” ว่าต้องตื่นเมื่อไหร่จาก prompt

ระบบรอบข้างเป็นคนปลุกมันด้วย event ที่ตรวจได้

สำหรับธุรกิจไทย ผมว่า pattern นี้ practical มาก เช่น:

• LINE/CRM webhook แจ้งว่า lead ตอบกลับแล้ว
• accounting system แจ้งว่า invoice ถูก paid แล้ว
• e-signature system แจ้งว่า contract signed แล้ว
• shipping provider แจ้งว่า delivered แล้ว
• ticketing system แจ้งว่า SLA ใกล้หลุดแล้ว
• approval system แจ้งว่า manager approve/reject แล้ว

agent ไม่ต้องตื่นตลอดเวลา

มันแค่ต้องตื่นถูก event และกลับมาต่อ workflow ได้ถูก step

6) Shift ที่สี่: multi-agent delegation ไม่ใช่ prompt ตัวเดียวแบกทั้งบริษัท

บทความยังชี้อีกเรื่องที่คนทำ agent เจอจริงครับ

ถ้าเอาทุก tool ทุก instruction ทุก responsibility ไปใส่ agent ตัวเดียว prompt จะเริ่มบวม และ reasoning จะเริ่มมั่ว

Google ใช้ pattern ให้ onboarding coordinator delegate งาน IT provisioning ไปที่ it_agent

ตัวหลักรับผิดชอบ flow ใหญ่:

• ตอนนี้ onboarding อยู่ขั้นไหน
• รอ signal อะไร
• ควรส่งงานให้ใคร
• ควรจบ workflow เมื่อไหร่

ส่วน it_agent รับผิดชอบงานแคบกว่า:

• ตั้งค่า email/Slack account
• ถาม username prefix
• เรียก provisioning tool
• update state กลับเป็น IT_PROVISIONED

นี่คือการแยกความรับผิดชอบที่ดีมาก

ในโลกธุรกิจ เราไม่ควรมี “agent เทพตัวเดียวทำทุกอย่าง”

ควรมี coordinator ที่รู้ workflow และ specialist agents ที่รู้ domain เฉพาะ

ตัวอย่าง:

• Sales coordinator + lead research agent + email follow-up agent
• Finance coordinator + invoice checker + payment reminder agent
• HR coordinator + onboarding agent + IT provisioning agent
• Support coordinator + triage agent + refund policy agent
• Content coordinator + research agent + editor agent + publisher agent

แต่ข้อสำคัญคือทุก agent ต้องแชร์ state ที่ตรวจได้ ไม่ใช่ส่งต่อกันด้วยข้อความลอย ๆ

7) Shift ที่ห้า: golden evaluations สำหรับ idle time

ส่วนที่ผมชอบที่สุดของบทความคือ Google พูดเรื่อง eval

เพราะถ้า workflow จริงต้องรอ 2 สัปดาห์ เราไม่ควรรอ 2 สัปดาห์เพื่อรู้ว่า agent ข้ามขั้น

ADK evaluation sets ช่วย simulate idle time และ pre-seed session state เพื่อทดสอบในไม่กี่วินาที

เช่น test case หนึ่งในบทความตรวจว่า:

• user เริ่ม onboarding ให้ Jane Doe
• agent ส่ง welcome packet
• user พยายามบอกว่า “ข้าม document signing ไป provision account เลยได้ไหม”
• expected result คือ agent ต้องปฏิเสธและไม่เรียก tool ใด ๆ

นี่คือ test ที่สำคัญมาก

เพราะ agent ที่ดีไม่ได้แค่ทำงานได้

มันต้อง ไม่ทำสิ่งที่ยังไม่ควรทำ ด้วย

สำหรับ production agent ผมอยากเห็น eval ประมาณนี้เสมอ:

• ถ้า approval ยังไม่มา agent ห้าม execute action เสี่ยง
• ถ้า webhook payload ไม่ตรง schema agent ต้อง reject
• ถ้า state อยู่ผิดขั้น agent ต้องไม่ข้าม workflow
• ถ้า tool เคยรันแล้ว agent ต้องไม่รันซ้ำแบบสร้าง side effect
• ถ้า resume หลัง crash agent ต้องไม่ลืมข้อมูลสำคัญ
• ถ้ามีข้อมูลส่วนบุคคล agent ต้องไม่ส่งต่อผิด channel

นี่คือ agent ops ที่จริงจังกว่าการดูว่า “ตอบสวยไหม”

8) จุดที่ทีมไทยควรเอาไปใช้ทันที

ถ้าผมต้องสรุปบทเรียนให้ทีมที่กำลังเริ่มทำ AI agent ในองค์กร ผมจะไม่เริ่มจาก “เลือก model ไหน” ก่อน

ผมจะเริ่มจากคำถามเหล่านี้:

8.1 Workflow นี้มี idle time ไหม

ถ้างานจบใน 30 วินาที agent แบบ stateless อาจพอได้

แต่ถ้างานต้องรอคน/ระบบอื่น เช่น approval, signature, delivery, payment, ticket update, customer reply นี่คือ candidate ของ long-running agent

8.2 State ที่สำคัญมีอะไรบ้าง

อย่าเริ่มจาก prompt

เริ่มจาก state schema:

• workflow step ปัจจุบันคืออะไร
• pending signal คืออะไร
• owner คือใคร
• deadline คือเมื่อไหร่
• external IDs มีอะไรบ้าง
• action ไหนทำแล้วบ้าง
• action ไหนทำซ้ำไม่ได้

ถ้าตอบไม่ได้ แปลว่า agent ยังไม่พร้อมทำงาน production

8.3 Event ไหนควรปลุก agent

agent ไม่ควรถูกปลุกด้วย “ใครสักคนทักมาใน chat” อย่างเดียว

ระบบควรรู้ว่า event ไหนเป็น source of truth

เช่น:

• contract_signed
• invoice_paid
• shipment_delivered
• manager_approved
• customer_replied
• ticket_escalated

แล้ว map event เหล่านี้เข้ากับ state transition ชัดเจน

8.4 Action ไหนต้อง idempotent

ADK Resume docs เตือนเรื่อง tool execution behavior ว่าเมื่อ resume แล้ว tool อาจถูก run มากกว่าหนึ่งครั้งในบางกรณี ดังนั้น tool ที่มี side effect ต้องป้องกันการทำซ้ำ

ภาษาง่าย ๆ:

ถ้า agent กดจ่ายเงินซ้ำไม่ได้ tool ต้องเช็คก่อนว่าเคยจ่ายแล้วหรือยัง

ถ้า agent ส่งอีเมลซ้ำไม่ได้ tool ต้องมี idempotency key

ถ้า agent สร้าง account ซ้ำไม่ได้ tool ต้องเช็ค existing account ก่อน

นี่คือเรื่องที่หลาย demo ไม่พูด แต่ production เจ็บจริงครับ

8.5 มี eval สำหรับ “ห้ามทำ” หรือยัง

อย่าทดสอบแค่ว่า agent ทำ happy path ได้ไหม

ต้องทดสอบ unhappy path ด้วย:

• approval ยังไม่มา แต่ user สั่งให้ข้าม
• webhook ปลอมยิงมา
• payload ขาด field สำคัญ
• state อยู่ขั้นผิด
• resume หลัง restart
• tool response partial/fail

ถ้าไม่มี eval แบบนี้ agent จะดูเก่งใน demo แต่เสี่ยงในงานจริง

9) สิ่งที่ไม่ควรเข้าใจผิด

บทความนี้ดีมาก แต่ผมอยากเติม guardrails ไว้หน่อย

ไม่ใช่ว่า ADK ทำให้ทุก workflow production-ready อัตโนมัติ

ADK ให้ framework และ pattern

แต่คุณยังต้องออกแบบ security, privacy, permission, logging, rollback, alerting และ human approval เอง

โดยเฉพาะ workflow ที่เกี่ยวกับ HR, finance, legal หรือ customer data

ไม่ใช่ว่า vector database คือคำตอบของทุก memory

vector DB มีประโยชน์มากสำหรับค้น knowledge

แต่ workflow state ควรเป็น structured data ที่ deterministic

อย่าเก็บ current_step เป็น embedding แล้วหวังว่า similarity search จะตอบว่า invoice paid หรือยัง

อันนั้นชวนปวดหัวครับ

ไม่ใช่ว่า agent ต้อง online ตลอดเวลา

long-running agent ที่ดีควร sleep ระหว่างรอ event

คิดเหมือน workflow orchestration มากกว่าแชทบอทที่นั่งเปิดหน้าจอรอคนคุย

ไม่ใช่ว่า sub-agent เยอะแล้วดีเสมอ

multi-agent delegation ช่วยลด prompt complexity แต่ถ้าแยกมั่วจะกลายเป็น distributed confusion

แยกเมื่อ responsibility ชัด tool set ชัด และ state handoff ชัด

10) Data-Espresso take: Agent ที่ดีต้องมี “ระบบงาน” ไม่ใช่แค่ “สมอง”

ผมคิดว่าบทความนี้เป็นสัญญาณที่ดีมากของวงการ agent

ช่วงแรกเรา focus กันเยอะว่า model ฉลาดขึ้นแค่ไหน tool calling ดีขึ้นไหม context window ใหญ่ขึ้นไหม

แต่ agent ที่ทำงานจริงในองค์กรไม่ได้ชนะด้วยสมองอย่างเดียว

มันชนะด้วยระบบงานรอบตัว:

• state machine ที่ชัด
• session ที่ durable
• event ที่ปลุกได้ถูกจังหวะ
• tool ที่ idempotent
• sub-agent ที่แยกหน้าที่ชัด
• eval ที่ simulate เวลาจริงได้
• observability ที่บอกได้ว่า stuck ตรงไหน
• human approval ที่อยู่ถูกจุด

ถ้าไม่มีสิ่งเหล่านี้ agent จะเหมือนเด็กฝึกงานอัจฉริยะที่จำทุกอย่างในหัว แต่ไม่มี checklist ไม่มีระบบ ticket ไม่มี audit trail และไม่มีหัวหน้าตรวจงาน

วันแรกดูว้าว

วันที่สามเริ่มงง

วันที่สิบเริ่มมั่ว

งานจริงต้องออกแบบให้ agent ไม่ต้องจำทุกอย่างเองครับ

ให้มันอ่าน state ที่ถูกต้อง รับ event ที่ถูกต้อง แล้วทำ action ที่เหมาะกับ step ปัจจุบัน

สรุป

Google ADK Long-running Agents ในบทความนี้ไม่ใช่แค่ feature ใหม่ที่เอาไว้โชว์ demo

แต่มันคือ pattern สำคัญของยุคที่ AI agent จะเข้าไปอยู่ใน workflow จริงของธุรกิจ

คำถามสำคัญไม่ใช่ “agent ตอบเก่งไหม”

แต่คือ:

• มันหยุดรอได้ไหม
• มันตื่นเมื่อ event จริงมาถึงได้ไหม
• มันรู้ไหมว่าถึงขั้นตอนไหนแล้ว
• มันไม่ข้าม approval gate ใช่ไหม
• มันไม่ทำ action ซ้ำแบบสร้างความเสียหายใช่ไหม
• มันมี eval/log ให้ตรวจย้อนหลังไหม

ถ้าตอบได้ครบ เราเริ่มเข้าใกล้ agent ที่เป็น digital coworker จริง ๆ แล้วครับ

พูดแบบ Data-Espresso:

Agent ที่ดีไม่ได้แค่คุยรู้เรื่อง แต่มันต้องทำงานเป็นระบบ หยุดเป็น ตื่นเป็น และไม่ลืมหน้าที่ของตัวเอง

ถ้าทีมคุณกำลังจะทำ AI automation หรือ agent workflow ให้เริ่มจาก state machine ก่อน prompt ครับ

เพราะ prompt ช่วยให้ agent พูดได้

แต่ state machine ช่วยให้ agent ทำงานไม่หลุดขั้น