เอเจนต์ที่รันระยะยาว - เมื่อเอเจนต์ทำงานต่อเนื่องหลายวัน อะไรเปลี่ยนไปบ้าง

• กำลังเกิดกระบวนทัศน์ใหม่ที่ AI เอเจนต์ไม่ได้ทำงานแค่ในแชตเซสชันเดียว แต่สามารถ ทำงานอัตโนมัติต่อเนื่องตั้งแต่หลายวันถึงหลายสัปดาห์ สลับข้ามหลาย context window และ sandbox กู้คืนจากความล้มเหลว และกลับมาทำต่อจากจุดที่หยุดได้
• เอเจนต์แบบเดิมติดข้อจำกัดเชิงโครงสร้างของ เซสชันเดี่ยว เช่น context window หมด ความมั่นใจเกินจริงในการประเมินตัวเอง และการนำการแก้ไขเดิมที่เคยลบไปกลับเข้ามาอีก
• บริษัทหลักอย่าง Anthropic, Google และ Cursor กำลังค่อย ๆ มาบรรจบกันที่สถาปัตยกรรมแบบ แยก model loop, execution sandbox และ session log
• โจทย์สำคัญของเอเจนต์ที่รันระยะยาวคือ การจัดการสถานะแบบคงอยู่, การตรวจสอบตนเอง, และการบีบอัดคอนเท็กซ์ โดยบทความนี้เสนอแพตเทิร์นการออกแบบ 5 แบบเพื่อแก้ปัญหาเหล่านี้
• พื้นที่ลงทุนที่สร้างความต่างด้านผลิตภาพจริง ๆ ไม่ได้อยู่ที่ตัวโมเดลเท่านั้น แต่คือ เลเยอร์ของ state, session และ structured handoff ที่ห่อหุ้มโมเดลอยู่

---

ความหมาย 3 แบบของคำว่า "รันระยะยาว"

• Long-horizon reasoning: ความสามารถในการวางแผนและลงมือทำผ่านขั้นตอนที่พึ่งพากันจำนวนมาก ซึ่งส่วนใหญ่เป็นปัญหาเรื่องคุณภาพของโมเดล ตามตัวชี้วัด time horizon ของ METR เวลาของงานที่ frontier model สามารถทำสำเร็จได้ด้วยความเชื่อมั่น 50% เพิ่มขึ้นเป็น 2 เท่าทุกประมาณ 7 เดือน นับจากปี 2019 และหากแนวโน้มนี้ยังคงอยู่ งานระดับวันอาจทำได้ในปี 2028 และงานระดับปีในปี 2034
• Long-running execution: โครงสร้างที่โปรเซสของเอเจนต์ทำงานต่อเนื่องหลายชั่วโมงถึงหลายวัน และอาจเรียกโมเดลหลายพันครั้ง ซึ่งส่วนใหญ่เป็นปัญหาด้านการออกแบบ harness
• Persistent agency: รูปแบบที่เอเจนต์คงอัตลักษณ์ของตัวเองข้ามงานเดี่ยว สะสมความทรงจำ และเรียนรู้ความชอบของผู้ใช้ โดย Memory Bank ของ Google เป็นตัวอย่างเด่น
• เอเจนต์ในโปรดักชันจริงมักรวมทั้งสามอย่างเข้าด้วยกัน แต่ปัญหาวิศวกรรมและแนวทางแก้ของแต่ละส่วนแตกต่างกัน

ทำไมเอเจนต์ที่รันระยะยาวจึงสำคัญ

• เอเจนต์ที่รัน 10 นาทีเหมาะกับงานตอบคำถามหรือแก้บั๊กเล็ก ๆ แต่ เอเจนต์ที่รัน 10 ชั่วโมง สามารถพัฒนาฟีเจอร์ทั้งชุด ปิดงาน migration ที่ค้างมา 6 ไตรมาส หรือทำวิจัยได้ระดับนักวิเคราะห์จูเนียร์
• ในการเปิดตัว Claude Sonnet ทาง Anthropic เปิดเผยกรณีทดสอบภายในที่ให้มัน เขียนโค้ดอัตโนมัตินานกว่า 30 ชั่วโมง และสร้างแอปสไตล์ Slack ขนาด 11,000 บรรทัดได้ในรันเดียว
• ใน Project Vend อินสแตนซ์ของ Claude บริหารธุรกิจตู้จำหน่ายสินค้าในออฟฟิศจริงเป็นเวลาหนึ่งเดือน โดยจัดการสต็อก ตั้งราคา และสื่อสารกับซัพพลายเออร์ ระยะแรกให้บทเรียนจากความล้มเหลวที่มีนัยสำคัญ และระยะที่สองดีขึ้นมาก
  • ประเด็นสำคัญไม่ใช่ความสามารถในการทำกำไร แต่คือการสังเกตปัญหาความสม่ำเสมอที่เกิดขึ้นเมื่อเอเจนต์ คงอัตลักษณ์เป็นรายสัปดาห์แทนที่จะเป็นรายเทิร์น

กำแพง 3 ด้านที่เอเจนต์รันระยะยาวทุกตัวต้องเจอ

• คอนเท็กซ์มีขีดจำกัด: แม้หน้าต่าง 1M โทเคนก็ยังหมดได้อยู่ดี และก่อนหน้าต่างจะเต็ม ก็เกิด context rot (ประสิทธิภาพของโมเดลค่อย ๆ ลดลง) แล้วด้วย การรันต่อเนื่อง 24 ชั่วโมงยังไม่สอดคล้องกับ roadmap ของ context window ใดในตอนนี้
• ไม่มีสถานะแบบคงอยู่: เซสชันใหม่เริ่มจากกระดาษเปล่า Anthropic เปรียบเรื่องนี้ว่าเหมือน วิศวกรที่มารับกะต่อโดยไม่รู้เลยว่าในกะก่อนเกิดอะไรขึ้น
• ไม่มีการตรวจสอบตนเองที่น่าเชื่อถือ: เมื่อโมเดลประเมินงานของตัวเอง จะมีอคติเชิงบวกอย่างสม่ำเสมอ เมื่อถามว่า "เสร็จหรือยัง?" มักตอบว่า "ใช่" บ่อยกว่าความเป็นจริง และหากไม่มีสัญญาณยืนยันแยกต่างหาก มันอาจส่งมอบงานที่เสร็จเพียง 30% พร้อมความมั่นใจเต็มเปี่ยม

Ralph loop: การทำเอเจนต์รันระยะยาวแบบง่ายสำหรับสายปฏิบัติ

• Ralph loop (เทคนิค Ralph Wiggum) คือแพตเทิร์นเอเจนต์รันระยะยาวสำหรับผู้ปฏิบัติที่ Geoffrey Huntley และ Ryan Carson ทำให้เป็นที่นิยม โดย reference implementation มีแค่ bash script ตัวเดียว
• ลำดับการทำงาน: เลือกงานที่ยังไม่เสร็จ (prd.json) → สร้างพรอมป์จากงาน คอนเท็กซ์ และบันทึกช่วยจำ → เรียกเอเจนต์ → รันทดสอบ → เพิ่มผลลัพธ์ลงใน progress.txt → อัปเดตรายการงาน → วนซ้ำ
• หลักการสำคัญคือ ตัวเอเจนต์เองความจำเสื่อม แต่ระบบไฟล์ยังจำได้ prd.json ทำหน้าที่เป็นแผน progress.txt เป็นสมุดบันทึกในแล็บ และ AGENTS.md เป็นคู่มือกฎที่อัปเดตต่อเนื่อง
• Compound Product ของ Ryan Carson เชนหลายลูปเข้าด้วยกันในรูปแบบ ลูปวิเคราะห์ (อ่านรายงานประจำวัน) → ลูปวางแผน (สร้าง PRD) → ลูปปฏิบัติการ (เขียนโค้ด) ซึ่งเป็นเวอร์ชันโอเพนซอร์สของโครงสร้างสามส่วน planner-generator-evaluator ที่ Anthropic ไปถึงด้วยตัวเองเช่นกัน
• แค่มี bash script กับไฟล์ JSON ก็สร้างเอเจนต์รันระยะยาวที่ทำงานข้ามคืนได้แล้ว สิ่งที่ Google และ Anthropic นำมาทำเป็นผลิตภัณฑ์ คือการทำให้แพตเทิร์นนี้ กู้คืนได้ ปลอดภัย และสังเกตการณ์ได้

Anthropic: จาก harness สู่การแยก Brain/Hands/Session

• แนวทางแรก (โครงสร้าง harness): 2-agent harness สำหรับพัฒนา full-stack แบบอัตโนมัติ Initializer agent ตั้งค่าสภาพแวดล้อมเริ่มต้นของโปรเจ็กต์ ขยายพรอมป์เป็น feature-list.json และเขียนสคริปต์บูต (init.sh) ส่วน Coding agent จะตื่นขึ้นมาเป็นรอบ ๆ เดินหน้าทีละฟีเจอร์ รันทดสอบ เขียน claude-progress.txt และ commit
  • กฎ test ratchet: "ห้ามลบหรือแก้ไขเทสต์" — เพื่อป้องกันความล้มเหลวที่พบบ่อยซึ่งเอเจนต์ลบเทสต์ที่ไม่ผ่านเพื่อให้ทุกอย่างผ่าน
  • ในเวอร์ชันขยายของ InfoQ ได้พัฒนาเป็นโครงสร้างสามส่วน planner, generator, evaluator เหตุผลสำคัญที่ต้องแยกการสร้างกับการประเมินออกจากกันคือ โมเดลมักประเมินผลงานตัวเองแบบผ่อนปรนเกินไป
• แนวทางที่สอง (แยก Brain/Hands/Session): สถาปัตยกรรมของ Claude Managed Agents (เปิดตัวต้นเดือนเมษายน 2026)
  • Brain: โมเดลและ harness loop
  • Hands: สภาพแวดล้อมรันชั่วคราวแบบ sandbox ที่เครื่องมือถูกเรียกใช้งานจริง
  • Session: event log แบบ append-only ของทุกความคิด การเรียกเครื่องมือ และการสังเกตทั้งหมด
• การวางกรอบสำคัญของ Anthropic คือ "ทุกคอมโพเนนต์ใน harness คือการเข้ารหัสสมมติฐานเกี่ยวกับสิ่งที่โมเดลยังทำเองไม่ได้" ถ้าผูกทุกอย่างไว้ด้วยกัน เมื่อสมมติฐานล้าสมัยก็ต้องเปลี่ยนทั้งระบบ แต่ถ้า แยกส่วน harness จะกลายเป็น stateless และ sandbox ก็ปฏิบัติต่อได้เหมือน cattle (ของใช้สิ้นเปลือง)
• คอนเทนเนอร์ใหม่สามารถเรียก wake(sessionId) เพื่อสร้างสถานะกลับจาก log ได้ ส่งผลให้ time-to-first-token ลดลงประมาณ 60% ที่ p50 และมากกว่า 90% ที่ p95 เพราะเริ่มให้เหตุผลได้ก่อน sandbox จะพร้อม
• แนวคิดเรื่อง session-event-log คือส่วนที่ถูกประเมินค่าต่ำที่สุด แต่มันคือหัวใจที่ทำให้เอเจนต์รันระยะยาวกู้คืนได้ หากไม่มีสิ่งนี้ คอนเทนเนอร์ล่มก็เท่ากับเซสชันล่ม
• สแต็กสำหรับงาน scientific computing: CLAUDE.md (แผนที่มีชีวิตซึ่งเอเจนต์เรียนรู้และแก้ไขต่อ), CHANGELOG.md (สมุดบันทึกในแล็บที่พกพาได้), tmux + SLURM + git (เลเยอร์การรันและประสานงาน), Ralph loop (ใช้ตรวจซ้ำเมื่ออ้างว่างานเสร็จแล้ว)
  • กรณีเด่น: Claude Opus สร้าง Boltzmann solver ข้ามหลายวัน และทำค่าคลาดเคลื่อนต่ำกว่า 1% เมื่อเทียบกับ implementation อ้างอิงของ CLASS เป็นการบีบเวลางานวิจัยจากระดับหลายเดือนถึงหลายปี

Cursor: โครงสร้าง Planner, Worker, Judge

• ระหว่างการขยายความสามารถการเขียนโค้ดอัตโนมัติระยะยาว Cursor ผ่านการวนออกแบบ 3 รอบ
  • รอบแรก (ประสานงานแบบแบน): เอเจนต์สถานะเท่าเทียมกันเขียนลงไฟล์ที่แชร์ร่วมกันโดยใช้ lock → เกิดคอขวด และเอเจนต์เริ่มหลีกเลี่ยงความเสี่ยงจนเกิด churning (วนไปมาแต่ไม่ commit)
  • รอบที่สอง (optimistic concurrency control): แก้คอขวดได้ แต่ปัญหาการประสานงานยังไม่หาย
  • รอบที่สาม (โปรดักชันปัจจุบัน): Planner (สำรวจ codebase และสร้างงาน สามารถ spawn sub-planner แบบ recursive), Worker (ลงมือทำแบบโฟกัส รับงานอิสระโดยไม่ต้องประสานกับตัวอื่น), Judge (ตัดสินว่ารอบนั้นเสร็จหรือควรรีสตาร์ต)
• สิ่งที่ค้นพบสำคัญคือ "พฤติกรรมของระบบจำนวนมากอย่างน่าประหลาดใจ ขึ้นกับพรอมป์มากกว่าตัว harness หรือโมเดล"
• การจับคู่โมเดลกับบทบาทเป็นส่วนหนึ่งของพื้นผิวการออกแบบ: โมเดล GPT ทำงาน อัตโนมัติระยะยาว ได้ดีกว่า Opus โดย Opus มีแนวโน้มหยุดเร็วและเลือกทางลัด งานเดียวกัน แต่บทบาทต่างกัน โมเดลต่างกัน
• Composer 2 (โมเดล frontier สำหรับเขียนโค้ดของตัวเอง) และ background cloud agent: งานระยะยาวไม่ได้รันในเครื่องอีกต่อไป แต่รันบนโครงสร้างพื้นฐานคลาวด์ของ Anysphere การรีแฟกเตอร์ 8 ชั่วโมงและ migration ทั้ง codebase ยังคงทำต่อได้แม้ปิดโน้ตบุ๊ก
  • เริ่มจากในเครื่องก่อน และถ้าคาดว่าจะใช้เวลามากกว่า 30 นาทีจะย้ายไปรันบนคลาวด์ จากนั้นจึง reconnect ได้ผ่านมือถือ
  • เอเจนต์แต่ละตัวรันใน git worktree ที่แยกกัน และ merge ผ่าน PR
• โครงสร้างสุดท้ายคล้ายกับ Anthropic: แยกบทบาท มี session persistence มี judge วางอยู่ข้าง worker และงานระยะยาวประสานกันใน cloud sandbox แบบอิง git

Google: เอเจนต์รันระยะยาวบน Agent Platform

• ที่งาน Cloud Next '26 Google รวม Vertex AI เป็น Gemini Enterprise Agent Platform และยกระดับเอเจนต์รันระยะยาวเป็นผลิตภัณฑ์ทางการที่มี SLA ชัดเจน
• Agent Runtime: รองรับการ "ทำงานอัตโนมัติต่อเนื่องหลายวัน" มี cold start ระดับต่ำกว่าหนึ่งวินาที และ provisioning sandbox แบบ on-demand ตัวอย่าง use case คือซีเควนซ์การทำ sales prospecting ที่กินเวลาหนึ่งสัปดาห์
• Agent Sessions: เก็บประวัติการสนทนาและอีเวนต์แบบคงอยู่ สามารถแมป session ID แบบกำหนดเองเข้ากับเรคอร์ดใน CRM หรือฐานข้อมูล เพื่อเก็บสถานะของเอเจนต์ไปพร้อมกับสถานะทางธุรกิจ
• Agent Memory Bank: เลเยอร์หน่วยความจำระยะยาวที่ GA (เปิดให้ใช้งานทั่วไป) แล้ว ณ งาน Next '26 ทำหน้าที่คัดสรรความทรงจำจากเซสชัน กำหนดขอบเขตตาม user ID และมี API สำหรับค้นหา ในกรณีของ Payhawk เอเจนต์ที่ใช้ Memory Bank ลดเวลาในการยื่นค่าใช้จ่ายได้มากกว่า 50%
• Agent Sandbox (การรันโค้ดแบบเสริมความแข็งแกร่ง), Agent-to-Agent Orchestration, Agent Registry, Agent Identity, Agent Gateway, Agent Observability, Agent Simulation ฯลฯ ครอบคลุมแทบทุกประเด็นที่จำเป็นต่อการใช้งานในโปรดักชัน รวมถึง ID แบบเข้ารหัสและ audit log ที่องค์กรต้องใช้
• ในเชิงสถาปัตยกรรม นี่คือการทำผลิตภัณฑ์ระดับแพลตฟอร์มจากโครงสร้างแยก brain/hands/session แบบเดียวกับ Anthropic พร้อมแพ็ก ADK (development kit แบบ code-first) และ Agent Studio (เครื่องมือแบบภาพ) สิ่งที่เมื่อ 3 ปีก่อนต้องสร้างเอง ตอนนี้กลายเป็นคำถามว่า จะยืมเวอร์ชันไหนของการแยก brain/hands/session

5 แพตเทิร์นสำหรับเอเจนต์รันระยะยาวในโปรดักชัน

• Checkpoint-and-resume: ความล้มเหลวหลายวันแบบที่พบบ่อยที่สุดคือ การสูญเสียคอนเท็กซ์ หากประมวลผลเอกสารไป 200 ฉบับแล้วพังที่ฉบับที่ 201 ถ้าไม่มี checkpoint ก็ต้องเริ่มใหม่ทั้งหมด ควรปฏิบัติต่อเอเจนต์เหมือน server process ที่รันยาว: บันทึกสถานะกลางลงดิสก์ ทำ checkpoint ทุก N หน่วยงาน และรองรับการกู้คืนจากความขัดข้อง จุดสำคัญคือการกำหนด granularity ของ checkpoint ที่เหมาะสม ไม่ถี่ทุกขั้นเกินไป และไม่รอไปจนจบทั้งหมด
• Delegated approval(human-in-the-loop): implementation แบบเดิมมัก serialize state เป็น JSON → ส่ง webhook → รอคำตอบ แต่เกิดปัญหาสถานะ stale และการแจ้งเตือนหายไป ใน runtime สำหรับงานระยะยาว เอเจนต์สามารถ หยุดชั่วคราวโดยยังคงเก็บ reasoning chain, working memory, history ของเครื่องมือ และ action ที่ค้างอยู่ครบทั้งหมด ช่วงที่มนุษย์กำลังตรวจทาน ไม่ใช้ compute เลย และกลับมาทำต่อได้ด้วย latency ต่ำกว่าหนึ่งวินาที Mission Control ของ Google ทำหน้าที่เป็น inbox สำหรับกรณีนี้
• Memory-layered context: เอเจนต์ที่รัน 7 วันต้องการมากกว่าสถานะของเซสชัน มีทั้ง Memory Bank (ความทรงจำระยะยาวที่ผ่านการคัดสรร) และ Memory Profiles (การเรียกใช้แบบ latency ต่ำ) failure mode ในโปรดักชันคือ memory drift — เอเจนต์เรียนรู้ทางลัดเชิงกระบวนการจากปฏิสัมพันธ์ที่ไม่เป็นโครงสร้าง แล้วนำไปใช้กว้างเกินควร จึงต้อง กำกับดูแลเมมโมรีเหมือนไมโครเซอร์วิส ด้วย Agent Identity (สิทธิ์อ่าน/เขียน), Agent Registry (ติดตามเวอร์ชันเอเจนต์), และ Agent Gateway (บังคับใช้นโยบาย)
• Ambient processing: เอเจนต์ที่ไม่ได้คุยกับมนุษย์ แต่ตอบสนองต่ออีเวนต์จากสตรีม Pub/Sub หรือ BigQuery table เช่น content moderation, anomaly detection, inbox classification หากไม่นำ policy ไป hardcode ในเอเจนต์ แต่ นิยามไว้ที่ Gateway ก็จะเปลี่ยนนโยบายให้เอเจนต์หลายร้อยตัวได้โดยไม่ต้อง redeploy
• Fleet orchestration: ในระบบจริงมักไม่ได้มีเอเจนต์ตัวเดียว แต่มีตัวประสานงานที่มอบหมายงานย่อยให้ผู้เชี่ยวชาญ เช่น Lead Researcher Agent, Scoring Agent, Outreach Agent โดยผู้เชี่ยวชาญแต่ละตัวมี Identity ของตัวเอง (เช่น Outreach Agent เข้าถึงข้อมูลการเงินสำหรับงาน Scoring ไม่ได้), policy ของตัวเอง, และรายการใน Registry ของตัวเอง ขณะที่ ADK จัดการแบบ declarative ผ่าน workflow แบบกราฟ
• แพตเทิร์นเหล่านี้ผสมกันได้ ตัวอย่างระบบ compliance: ใช้ checkpointing กับการประมวลผลเอกสาร + delegated approval ที่จุด review gate + memory layering สำหรับความรู้ข้ามเซสชัน + fleet orchestration สำหรับการประสานผู้เชี่ยวชาญ

วิธีลงมือสร้างจริง

• นักพัฒนาที่ต้องการงานเขียนโค้ดระยะยาวในรีโปของตัวเอง: ใช้ Claude Code, Antigravity, Cursor, Codex ฯลฯ ดูแล AGENTS.md เหมือนเช็กลิสต์นักบิน (สั้น และมีเฉพาะข้อที่ได้มาจากความล้มเหลวจริง) เพิ่ม hook สำหรับ typecheck และ lint เขียนไฟล์แผนก่อนเริ่ม และเมื่อเอเจนต์อ้างว่างานเสร็จให้ ตรวจซ้ำด้วย Ralph loop งานหลายชั่วโมงหรือข้ามคืนควรรันใน worktree เพื่อให้ทำงานต่อได้แม้ปิดโน้ตบุ๊ก และ commit ทุกครั้งที่ถึงหน่วยงานที่มีความหมาย นี่คือ เส้นทางที่ให้ leverage สูงสุดสำหรับคนส่วนใหญ่
• การสร้างผลิตภัณฑ์เอเจนต์แบบโฮสต์: อย่าสร้าง runtime เองถ้าไม่จำเป็น ให้เลือกแบบ managed ปัจจุบันมีตัวเลือกใช้งานจริง 3 แบบ: Google Agent Platform (Agent Engine + Memory Bank + Sessions), Claude Managed Agents, หรือโฮสต์เองบน ADK, Claude Agent SDK, Codex SDK การใช้ managed จะได้การแยก brain/hands/session, observability, identity และ audit trail มาเป็นค่าเริ่มต้น ส่วน self-hosted ให้การควบคุมและการใช้โมเดลเฉพาะทางมากกว่า
• งานอัตโนมัติและงานปฏิบัติการ (monitoring, research, operations): ต้องการ persistence แบบ Memory Bank โดยสแต็ก ADK + Memory Bank + Cloud Run + Cloud Scheduler ดูเป็นทางเลือกที่สะอาดที่สุดสำหรับรูปแบบ "รันเอเจนต์ทุก N ชั่วโมง, สะสมสถานะ, แจ้งเตือนเมื่อถึง threshold"

แนวปฏิบัติสำคัญไม่ว่าคุณจะเลือกเส้นทางไหน

• กำหนดเงื่อนไขเสร็จงานให้ชัดก่อนเริ่มเอเจนต์: นี่คือคันโยกที่แรงที่สุดสำหรับงานรันระยะยาว เขียนเกณฑ์เสร็จงานที่ชัดเจนและทดสอบได้ไว้ในไฟล์ภายนอก เพื่อกันไม่ให้เอเจนต์นิยามคำว่า "เสร็จ" ใหม่ระหว่างการทำงาน
• แยก evaluator ออกจาก generator: การตรวจการบ้านตัวเองคือ failure mode หลัก pipeline แบบ planner/worker/judge หรือคู่ generator/evaluator ไม่ใช่เรื่องสไตล์ แต่เป็น แพตเทิร์นสถาปัตยกรรมจริง แม้จะใช้โมเดลเดียวกันก็ควรแยกบทบาทและพรอมป์
• ลงทุนกับ session log มากกว่าพรอมป์: event log แบบ append-only ทำให้เอเจนต์กู้คืน ดีบัก และ audit ได้ หากคุณไม่สามารถสร้างภาพการทำงานของเอเจนต์ในช่วง 24 ชั่วโมงที่ผ่านมาใหม่จาก persistent storage ได้ สิ่งนั้นก็เป็นเพียง shell script สำหรับรัน LLM ระยะยาวเท่านั้น
• ให้ความสำคัญกับการบีบอัดและการรีเซ็ตคอนเท็กซ์ในระดับ first-class: Anthropic พบว่าในการทำงานที่ยาวมาก การบีบอัดด้วยสรุปอย่างเดียวไม่พอ และ harness จำเป็นต้องถอดเซสชันออกทั้งหมดแล้ว สร้างใหม่จาก structured handoff file ซึ่งโดยแก่นแท้แล้วเหมือนกระบวนการ onboarding วิศวกรคนใหม่

ข้อจำกัดเชิงปฏิบัติในปัจจุบัน

• ต้นทุน: การรัน 24 ชั่วโมงด้วย frontier model มีค่าใช้จ่ายสูงมาก หากไม่มีงบประมาณ circuit breaker และ hard cap สำหรับการใช้เครื่องมือ งบ API รายสัปดาห์อาจหมดได้ภายในแค่ครึ่งวันบ่าย
• ความปลอดภัย: เอเจนต์รันระยะยาวที่มี API key, สิทธิ์เข้าถึงคลาวด์ และสิทธิ์รัน shell command มี พื้นผิวการโจมตี กว้างกว่าแชตเซสชันมาก แพตเทิร์นแยก brain/hands จึงสำคัญ — ต้องรักษาไม่ให้ sandbox ที่รันโค้ดซึ่งโมเดลสร้างขึ้น เข้าถึง credential ได้
• Alignment drift: เอเจนต์ค่อย ๆ ลอยออกจากเป้าหมายเดิมเมื่อผ่านหลาย context window เป้าหมายเดิมถูกสรุป แล้วสรุปซ้ำ จนความเที่ยงตรงลดลง hook และ judge มีไว้เพื่อป้องกันสิ่งนี้ และนี่คือสาเหตุที่พบบ่อยที่สุดของกรณี "เอเจนต์ทำงานที่ไม่ได้ถูกขอ"
• การตรวจสอบ: การ audit กิจกรรมอัตโนมัติ 24 ชั่วโมงยังเป็นปัญหาเรื่องเวลาของมนุษย์ สิ่งที่ช่วยทำให้จัดการได้คือ observability และผลลัพธ์แบบมีโครงสร้าง เช่น PR, commit, briefing และผลการรันทดสอบ
• บทบาทของมนุษย์: การ นิยามงานให้ละเอียดพอที่เอเจนต์จะรันได้ทั้งวัน ยากกว่าการลงมือทำเองเสียอีก ทักษะที่มูลค่าเพิ่มขึ้นจึงไม่ใช่การเขียนโค้ด แต่เป็น การเขียนสเปกที่รอดจากการปะทะกับผู้ปฏิบัติการอัตโนมัติได้

ทิศทางถัดไป

• Google, Anthropic และ Cursor กำลังมาบรรจบกันที่โครงสร้างเดียวกัน: แยก model loop, execution sandbox และ session log, แยกการวางแผน การสร้าง และการประเมิน, ฝังการบีบอัด hook และ context reset ไว้ในระบบ และเปิดเมมโมรีเป็น managed service
• ความต่างอยู่ที่ พื้นผิว: Google Agent Platform คือสแต็กระดับองค์กร (มี identity และ audit trail ในตัว), Claude Managed Agents คือ "เวอร์ชันโฮสต์ของ harness จาก Anthropic", ส่วน background agent ของ Cursor คือ "การย้ายงานเขียนโค้ดระยะยาวจาก IDE ไปไว้บนคลาวด์"
• ปัญหาที่ยากกว่าในอีก 1 ปีข้างหน้าไม่ใช่แต่ละเลเยอร์เดี่ยว ๆ แต่คือ การประสานงานเหนือเลเยอร์เหล่านั้น: การเดินระบบเอเจนต์ระยะยาวหลายตัวบน codebase ร่วมกัน, เอเจนต์ที่อ่าน trace ของตัวเองและแพตช์ harness ของตัวเอง, และ harness ที่ประกอบเครื่องมือกับคอนเท็กซ์แบบ JIT (just-in-time) ให้เหมาะกับงาน
• โมเดลยังคงสำคัญ แต่ช่องว่างระหว่างหน้าต่างแชตกับเอเจนต์ที่ปล่อยรันข้ามคืนได้ ส่วนใหญ่เกิดจาก state, session และ structured handoff และนี่คือจุดที่ควรลงทุนเวลาเรียนรู้ในตอนนี้

[jjpark78]

ผมเริ่มใช้ hermes เพื่อแก้ปัญหานี้อยู่เหมือนกัน รู้สึกว่าไม่เลวเลยครับ 555