<div class="key-takeaways"><ul><li>งานวิจัย EvolveTrade จาก KAIST แก้ปัญหา AI Agent ใช้เครื่องมือคำนวณแต่ไม่นำผลมาตัดสินใจจริง</li><li>ระบบใช้ Policy agent คอยวิเคราะห์ผลลัพธ์และเขียน Prompt ใหม่ทุกๆ 5 วันทำการ</li><li>ผลทดสอบแสดง Sharpe ratio 4.00 และผลตอบแทนสะสม 10.56% เหนือกว่าแบบดั้งเดิม</li></ul></div><p>การประเมินประสิทธิภาพของ Autonomous agent ส่วนใหญ่ในปัจจุบันมักมองข้ามช่องโหว่สำคัญ นั่นคือการที่โมเดลใช้งานเครื่องมือต่างๆ เช่น API ราคาหุ้น หรือเครื่องมือค้นหาข่าว ควบคู่กับ Python REPL เพียงเพื่อทำตามขั้นตอน แต่ไม่ได้นำผลลัพธ์เชิงปริมาณที่คำนวณได้มาใช้ในการตัดสินใจขั้นสุดท้ายอย่างแท้จริง โมเดลอาจคำนวณความผันผวนย้อนหลัง 20 วันได้ถูกต้อง แต่กลับจัดสรรเงินลงทุนตามหลักการกว้างๆ ที่ตั้งไว้ตั้งแต่ก่อนเปิดใช้งานเครื่องมือ</p><p>เพื่อแก้ปัญหานี้ งานวิจัยชิ้นใหม่จาก KAIST ในชื่อ EvolveTrade (Kim et al., arXiv:2609.17632) ได้นำเสนอแนวทางใหม่โดยหยุดการกำหนดสัญญาการใช้เครื่องมือแบบตายตัวตั้งแต่เริ่มต้น และเปลี่ยนมามอง Prompt ของระบบให้เป็นนโยบายที่ปรับเปลี่ยนได้ด้วยข้อความ (text-parameterized policy)</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/evolvetrade_kaist_ai_agent_prompt_mu5s8p66_inline_1_3ede3725ee.jpg" alt="algorithm code execution monitor screen workspace" loading="lazy" /><p class="color-gray-500 text-sm mt-10">ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง</p></div><p>ในระบบแบบดั้งเดิมที่นักวิจัยทดสอบผ่าน LiveTradeBench เมื่อใช้โมเดลอย่าง GPT-5-mini โมเดลจะรัน Python อย่างขยันขันแข็ง เช่น คำนวณว่า JPMorgan มีผลตอบแทนย้อนหลัง 20 วันอยู่ที่ +3.45% และมี Sharpe ratio 2.105 หรือ Caterpillar อยู่ที่ 1.497 แต่สัดส่วนการลงทุนจริงกลับแทบไม่ขยับจากค่าเริ่มต้น โดย JPMorgan ยังคงอยู่ที่ 6% และ Caterpillar ที่ 4% ตัวเลขเชิงปริมาณทั้งหมดจึงเป็นเพียงแค่เหตุผลประกอบในขั้นตอนการคิดเท่านั้น</p><div class="stat-row"><div class="stat-item"><span class="stat-number">4.00</span><span class="stat-label">Sharpe ratio ของ EvolveTrade</span></div><div class="stat-item"><span class="stat-number">10.56%</span><span class="stat-label">ผลตอบแทนสะสม 50 วัน</span></div><div class="stat-item"><span class="stat-number">2.96%</span><span class="stat-label">Maximum drawdown</span></div></div><p>แนวทางของ EvolveTrade คือการให้ Policy agent แยกต่างหากคอยตรวจสอบร่องรอยการทำงานและผลตอบแทนของพอร์ตทุกๆ 5 วันทำการ จากนั้นทำหน้าที่เขียน Prompt ใหม่เพื่อบอกให้ Trading agent รู้จักวิธีใช้เครื่องมือให้สอดคล้องกับพอร์ตลงทุน ผลลัพธ์จากการทดสอบข้ามภาวะตลาดต่างๆ (เช่น ช่วงตลาดซบเซา ตลาดขาลง และตลาดกระทิง บนโมเดล GPT-5-mini และ Gemini-2.5-Flash) พบว่า Prompt ที่ถูกพัฒนาขึ้นใหม่จะช่วยบังคับให้โมเดลย้ายการคำนวณจากข้อความบรรยายไปสู่โค้ดที่สั่งการได้จริง</p><blockquote class="pull-quote"><p>"In the September 10, 2025 trace highlighted by the authors, the static agent called Python once for aggregate stats. The evolved agent called Python 11 times: running metric calibration, validating risk constraints, and generating exact percentage weights."</p><cite>Kim et al., EvolveTrade</cite></blockquote><div class="ai-insight"><p>แนวคิดการให้ Prompt พัฒนาตัวเองหรือ Prompt Evolution ถือเป็นก้าวสำคัญในการแก้ปัญหา Context Window Degeneration ซึ่งมักเกิดจากการที่คำสั่งสะสมความยาวจนโมเดลสับสน งานวิจัยนี้แสดงให้เห็นว่าระบบอัตโนมัติสามารถขยายและหดขนาดของชุดคำสั่งตามสภาวะตลาดได้เอง (ระหว่าง 5,000 ถึง 20,000 ตัวอักษร) โดยการตัดกฎเกณฑ์ที่ซ้ำซ้อนทิ้งไป กลไกนี้สะท้อนให้เห็นว่าอนาคตของ AI Agent ในงานที่มีความแม่นยำสูง เช่น การเงิน จะต้องพึ่งพาการควบคุมแบบ Deterministic binding มากกว่าการปล่อยให้โมเดลตีความผลลัพธ์ของเครื่องมือด้วยภาษาธรรมชาติอย่างอิสระ</p></div><p>จากการทดสอบระยะเวลา 50 วัน EvolveTrade สามารถทำ Sharpe ratio ได้สูงถึง 4.00 และสร้างผลตอบแทนสะสม 10.56% เทียบกับแบบเดิมที่ได้ Sharpe 2.94 และผลตอบแทน 8.88% พร้อมทั้งจำกัด Maximum drawdown ไว้ที่ 2.96% เทียบกับ 4.40% ของระบบดั้งเดิม บทเรียนสำคัญสำหรับนักพัฒนาซอฟต์แวร์คือ การปล่อยให้การเชื่อมโยงระหว่างข้อมูลเชิงปริมาณและการกระทำขั้นสุดท้ายขึ้นอยู่กับภาษาพูดของ LLM นั้นมีความเปราะบางสูง และการบังคับให้โค้ดผูกมัดกับการกระทำโดยตรงคือหัวใจสำคัญของความสำเร็จ</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/reidmarlow/llm-agents-turn-code-interpreters-into-portfolio-sizing-engines-when-you-evolve-the-prompt-3mbj" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

<div class="key-takeaways"><ul><li>KAIST's EvolveTrade research fixes the gap where AI agents run tools but ignore quantitative output.</li><li>A separate policy agent reviews execution traces and rewrites operational prompts every 5 trading days.</li><li>Testing shows a 4.00 Sharpe ratio and 10.56% cumulative return, outperforming static baselines.</li></ul></div><p>Most autonomous agent benchmarks today evaluate tool use as a superficial information-gathering exercise. Developers hand models API keys for stock prices, search tools for financial news, and a Python REPL, then check if it makes correct API calls before writing a summary. In practice, giving agents a code interpreter does little if the system prompt treats code execution merely as descriptive background chatter while allocating capital using vague qualitative heuristics.</p><p>To fix this, a new paper from KAIST, EvolveTrade (Kim et al., arXiv:2609.17632), stops hardcoding the tool-use contract at deployment. Instead, the researchers treat the operational system prompt as a text-parameterized policy that continuously adapts based on historical performance.</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/evolvetrade_kaist_ai_agent_prompt_mu5s8p66_inline_1_3ede3725ee.jpg" alt="algorithm code execution monitor screen workspace" loading="lazy" /><p class="color-gray-500 text-sm mt-10">Stock photo for illustration only, not from the actual event</p></div><p>In standard setups like LiveTradeBench using GPT-5-mini, the static agent ran Python diligently, calculating that JPMorgan had a 20-day return of +3.45% with a 2.105 Sharpe ratio, and Caterpillar sat at 1.497. Yet, final allocations barely budged from an arbitrary baseline, leaving JPMorgan at 6% and Caterpillar at 4%. The quantitative metrics remained trapped inside the reasoning trace without driving actual portfolio weight adjustments.</p><div class="stat-row"><div class="stat-item"><span class="stat-number">4.00</span><span class="stat-label">EvolveTrade Sharpe ratio</span></div><div class="stat-item"><span class="stat-number">10.56%</span><span class="stat-label">50-day cumulative return</span></div><div class="stat-item"><span class="stat-number">2.96%</span><span class="stat-label">Maximum drawdown</span></div></div><p>Under EvolveTrade, a separate policy agent reviews execution traces and realized returns every five trading days, rewriting the operational prompt to dictate how the trading agent utilizes its tools. Tested across sideways, drawdown, and bull markets with GPT-5-mini and Gemini-2.5-Flash, the evolved prompt systematically shifted metric calculation out of qualitative text and directly into executable code allocation.</p><blockquote class="pull-quote"><p>"In the September 10, 2025 trace highlighted by the authors, the static agent called Python once for aggregate stats. The evolved agent called Python 11 times: running metric calibration, validating risk constraints, and generating exact percentage weights."</p><cite>Kim et al., EvolveTrade</cite></blockquote><div class="ai-insight"><p>The concept of self-evolving prompts tackles a major challenge in production AI systems known as prompt bloat or context degradation. By allowing the policy length to fluctuate non-monotonically (between 5,000 and 20,000 characters) based on market regimes, EvolveTrade demonstrates that automated systems can incorporate validation checks and prune redundant rules dynamically. For developers deploying autonomous financial agents, this proves that deterministic binding between tool execution and final actions is critical to avoid fragile qualitative LLM prose.</p></div><p>Across 50-day testing, EvolveTrade maintained a 4.00 Sharpe ratio and a 10.56% cumulative return against the static agent's 2.94 Sharpe and 8.88% return, while keeping maximum drawdown at 2.96% versus 4.40%. For software engineers building production workflows, the lesson is clear: unless your system prompt explicitly forces models to bind final actions to deterministic calculations, runtime tool outputs will remain underutilized.</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/reidmarlow/llm-agents-turn-code-interpreters-into-portfolio-sizing-engines-when-you-evolve-the-prompt-3mbj" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

medium_evolvetrade-งานวิจัย-kaist-เผย-ai-agent-พัฒนา-prompt-เอง-mu5s8p66.png

small_evolvetrade-งานวิจัย-kaist-เผย-ai-agent-พัฒนา-prompt-เอง-mu5s8p66.png

thumbnail_evolvetrade-งานวิจัย-kaist-เผย-ai-agent-พัฒนา-prompt-เอง-mu5s8p66.png

evolvetrade-งานวิจัย-kaist-เผย-ai-agent-พัฒนา-prompt-เอง-mu5s8p66.png

งานวิจัยใหม่จาก KAIST เสนอ EvolveTrade ให้ AI Agent ปรับปรุง Prompt อัตโนมัติเพื่อเชื่อมโยงผลคำนวณจาก Python เข้ากับการจัดพอร์ต ทำผลงานเด่น Sharpe ratio 4.00

A new KAIST paper introduces EvolveTrade, letting AI agents self-evolve system prompts to bind Python calculations to portfolio allocation, hitting a 4.00 Sharpe ratio.

EvolveTrade: งานวิจัย KAIST เผย AI Agent พัฒนา Prompt เอง

EvolveTrade: KAIST Study Shows AI Agents Evolve Prompts

<div class="key-takeaways"><ul><li>Google AI เปิดตัว EnvHarness เลเยอร์โปรแกรมมิ่งสำหรับสภาพแวดล้อม AI</li><li>ช่วยเปลี่ยน static environments ให้กลายเป็น adaptive training worlds</li><li>รองรับ 6 สแตรนดาร์ดสิ่งแวดล้อมและมาพร้อมโค้ด Apache-2.0 Python</li><li>ทดสอบแล้วบน ALFWorld, WebArena, SWE-bench Verified และอื่นๆ</li></ul></div><p>ทีมวิจัยจาก Google AI ได้นำเสนอ EnvHarness ซึ่งเป็นเลเยอร์แบบโปรแกรมมิ่งที่ถูกออกแบบมาเพื่อแก้ไขข้อจำกัดของสภาพแวดล้อมการทดสอบ AI แบบเดิมที่มักจะหยุดนิ่งและไม่ยืดหยุ่น โดยเครื่องมือนี้เปิดให้ใช้งานในรูปแบบ Apache-2.0 Python พร้อมไดรเวอร์สำหรับการจำลอง 6 สภาพแวดล้อม เพื่อช่วยให้เอเจนต์ปัญญาประดิษฐ์สามารถเรียนรู้และพัฒนาความสามารถได้อย่างมีประสิทธิภาพมากขึ้นในโลกจำลองที่ปรับเปลี่ยนได้ตามความเหมาะสม</p><p>ในปัจจุบัน LLM agents มักเรียนรู้นอกจากข้อความที่ถูกคัดสรรแล้วยังต้องพึ่งพาสภาพแวดล้อมแบบอินเทอร์แอกทีฟ ซึ่งสภาพแวดล้อมเหล่านี้มักถูกสร้างขึ้นด้วยมือและมีความตายตัว คือจะมีพฤติกรรมเหมือนเดิมทุกครั้งไม่ว่าเอเจนต์จะพัฒนาไปมากแค่ไหน ทำให้ไม่สามารถเจาะจุดอ่อนของนโยบาย (policy) ได้ และไม่มีอะไรจะสอนต่อได้เมื่อเอเจนต์แก้ปัญหานั้นได้แล้ว แนวทางแก้ปัญหาดั้งเดิมคือการสร้างสภาพแวดล้อมเพิ่มขึ้น แต่ก็มีต้นทุนสูงทั้งในแง่ของไปป์ไลน์การสร้างเฉพาะโดเมนและตัวตรวจสอบที่เขียนโดย LLM ซึ่งต้องผ่านการกรองอย่างหนักหน่วง</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/google_ai_envharness_ai_mtgfaeam_inline_1_e2b6b9cab6.jpg" alt="software code development computer screen no logo" loading="lazy" /><p class="color-gray-500 text-sm mt-10">ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง</p></div><div class="stat-row"><div class="stat-item"><span class="stat-number">62.4 - 68.3</span><span class="stat-label">ALFWorld average</span></div><div class="stat-item"><span class="stat-number">49.88 - 52.58</span><span class="stat-label">SWE-bench Verified</span></div></div><p>แนวทางของ EnvHarness จึงสลับมุมมองโดยสิ้นเชิง ด้วยการห่อหุ้มสภาพแวดล้อมที่ถูกแช่แข็ง (frozen environment) ไว้ด้วยส่วนประกอบปลั๊กอินที่ทำงานผ่านอินเทอร์เฟซมาตรฐาน reset() / step() โดยไม่มีการแทรกแซงไปยังแบ็กเอนด์ของตัวจำลอง ทำให้งานแต่ละชิ้นยังคงรักษาตัวตรวจสอบดั้งเดิมที่มนุษย์สร้างขึ้นเอาไว้ได้ นอกจากนี้ยังมีคอมโพเนนต์หลักที่ปล่อยออกมาพร้อมกัน เช่น EnvRigger ซึ่งทำหน้าที่สังเกตการณ์ เรียกใช้กระบวนการทดลอง และตรวจสอบความถูกต้องเพื่อคัดกรองตัวเลือกที่ยากหรือซ้ำซากจนเกินไป</p><div class="ai-insight"><p>การพัฒนาสภาพแวดล้อมฝึกฝนสำหรับ AI แบบดั้งเดิมมักประสบปัญหาเรื่องความสิ้นเปลืองของทรัพยากรในการสร้างโจทย์ใหม่ๆ และความซับซ้อนในการควบคุมระดับความยากง่ายไม่ให้ยากหรือหลุดกรอบจนเกินไป การใช้เลเยอร์แบบโปรแกรมมิ่งอย่าง EnvHarness ที่เข้าไปปรับแต่งเฉพาะส่วนอินเทอร์เฟซโดยไม่แตะต้องระบบจำลองหลัก จึงช่วยให้โมเดลภาษาขนาดใหญ่ (LLM) ได้รับชุดฝึกฝนที่ท้าทายและตรงจุดต่อการพัฒนาศักยภาพเชิงเหตุผลมากขึ้นอย่างเป็นระบบ</p></div><p>ผลการทดสอบบนแพลตฟอร์มต่างๆ เช่น ALFWorld, WebArena, SWE-bench Verified, OfficeQA และ SpreadsheetBench ชี้ให้เห็นว่าทักษะที่ถูกขุดขึ้นมาผ่านการเหนี่ยวนำสามารถเอาชนะชุดควบคุมได้ในงานที่ถูกกันไว้ไม่ได้เห็นมาก่อน โดยคะแนนเฉลี่ยของ ALFWorld ขยับขึ้นจาก 62.4 สู่ 68.3 ส่วนอัตราการแก้ปัญหาของ SWE-bench Verified ขยับจาก 49.88 ไปเป็น 52.58 พร้อมกับจำนวนขั้นตอนเฉลี่ยที่ลดลงจาก 55.01 เหลือ 49.61</p><blockquote class="pull-quote"><p>"An agent harness makes a frozen LLM capable through plug-in tools, memory and skills. EnvHarness applies that idea to the other side of the loop..."</p><cite>Google AI Research Team</cite></blockquote><p>นอกจากนี้ภายใต้การทดสอบด้วย RL บนโมเดล Qwen3-8B-base สภาพแวดล้อมที่ถูกปรับรูปร่างใหม่ยังสามารถเอาชนะสภาพแวดล้อมเดิมใน 3 จาก 4 เมตริก และยังช่วยยกระดับการขยายตัวของสภาพแวดล้อมไปถึง 54.79 ที่จำนวน 300 สภาพแวดล้อม เปรียบเทียบกับ 52.13 ของสภาพแวดล้อมเดิม นักพัฒนาที่สนใจสามารถศึกษาเอกสารวิจัยฉบับเต็มและโค้ดโปรแกรมผ่านทาง GitHub ได้ทันที</p><p class="source-attribution">ที่มา: <img src="https://www.google.com/s2/favicons?domain=www.marktechpost.com&sz=64" alt="MarkTechPost" class="source-logo" width="16" height="16" /> <a href="https://www.marktechpost.com/2026/08/30/google-ai-introduces-envharness-a-programmable-layer-that-turns-static-agent-environments-into-adaptive-training-worlds/" target="_blank" rel="noopener noreferrer">MarkTechPost</a></p>

<div class="key-takeaways"><ul><li>Google AI introduces EnvHarness programmable layer for AI environments</li><li>Converts static evaluation setups into adaptive training worlds</li><li>Ships with Apache-2.0 Python license and drivers for six environments</li><li>Tested thoroughly across ALFWorld, WebArena, and SWE-bench Verified</li></ul></div><p>Researchers at Google AI have introduced EnvHarness, a programmable layer designed to overcome the limitations of traditional, static AI testing environments. Released under an Apache-2.0 Python license with reproduction drivers for six environments, this tool enables artificial intelligence agents to learn and refine their capabilities within dynamic worlds that adapt to their evolving skill levels.</p><p>Historically, LLM agents have relied on interactive environments that are hand-built and completely static. These environments behave identically regardless of how much an agent has improved, failing to target specific policy weaknesses once solved. While generating more environments is a common solution, it incurs high costs due to domain-specific generation pipelines and unreliable LLM-written verifiers that require heavy filtering.</p><p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/google_ai_envharness_ai_mtgfaeam_inline_1_e2b6b9cab6.jpg" alt="software code development computer screen no logo" loading="lazy" /><p class="color-gray-500 text-sm mt-10">Stock photo for illustration only, not from the actual event</p></div><div class="stat-row"><div class="stat-item"><span class="stat-number">62.4 - 68.3</span><span class="stat-label">ALFWorld average</span></div><div class="stat-item"><span class="stat-number">49.88 - 52.58</span><span class="stat-label">SWE-bench Verified</span></div></div><p>EnvHarness takes the opposite approach by wrapping frozen environments in plug-in components operating strictly through standard reset() and step() interfaces. Because no interventions reach the simulator backend, every reshaped task retains its original human-built verifier. Key components like EnvRigger treat policies as black boxes, observing rollouts, diagnosing flaws, and validating generated Python hooks in isolated subprocesses.</p><div class="ai-insight"><p>Traditional AI training environment generation often suffers from high resource overhead and difficulties in controlling task difficulty levels. By introducing a programmable wrapper layer like EnvHarness that modifies only the interface without touching the underlying simulator, large language models can receive systematically challenging and targeted training regimens to improve reasoning performance.</p><p>Evaluations across benchmarks such as ALFWorld, WebArena, SWE-bench Verified, OfficeQA, and SpreadsheetBench demonstrate that skills mined through this framework outperform controls on held-out tasks. The average score on ALFWorld rose from 62.4 to 68.3, while SWE-bench Verified resolved rates shifted from 49.88 to 52.58 alongside a decrease in average steps from 55.01 to 49.61.</p><blockquote class="pull-quote"><p>"An agent harness makes a frozen LLM capable through plug-in tools, memory and skills. EnvHarness applies that idea to the other side of the loop..."</p><cite>Google AI Research Team</cite></blockquote><p>Furthermore, under reinforcement learning with Qwen3-8B-base, reshaped environments outperformed original ones across three out of four metrics. Environment scaling reached 54.79 at 300 environments compared to 52.13 for originals. Researchers and developers can access the research paper, project page, and GitHub repository for further exploration.</p><p class="source-attribution">Source: <img src="https://www.google.com/s2/favicons?domain=www.marktechpost.com&sz=64" alt="MarkTechPost" class="source-logo" width="16" height="16" /> <a href="https://www.marktechpost.com/2026/08/30/google-ai-introduces-envharness-a-programmable-layer-that-turns-static-agent-environments-into-adaptive-training-worlds/" target="_blank" rel="noopener noreferrer">MarkTechPost</a></p>

medium_google-ai-เปิดตัว-envharness-เปลี่ยนสภาพแวดล้อม-ai-mtgfaeam.png

small_google-ai-เปิดตัว-envharness-เปลี่ยนสภาพแวดล้อม-ai-mtgfaeam.png

thumbnail_google-ai-เปิดตัว-envharness-เปลี่ยนสภาพแวดล้อม-ai-mtgfaeam.png

google-ai-เปิดตัว-envharness-เปลี่ยนสภาพแวดล้อม-ai-mtgfaeam.png

Google AI เสนอ EnvHarness เลเยอร์แบบโปรแกรมมิ่งที่ช่วยแปลงสภาพแวดล้อม static ของ AI ให้กลายเป็นโลกฝึกฝนแบบ adaptive

Google AI proposes EnvHarness, a programmable layer that transforms static AI agent environments into adaptive training worlds.

Google AI เปิดตัว EnvHarness เปลี่ยนสภาพแวดล้อม AI

Google AI Introduces EnvHarness for Adaptive Training

<div class="key-takeaways"><ul><li>ความผิดพลาดของ AI Agent ไม่ใช่เหตุการณ์อิสระ แต่เชื่อมโยงกันผ่านบริบท (Context)</li><li>เมื่อเกิดข้อผิดพลาด ขั้นตอนถัดไปจะมีความน่าจะเป็นที่จะผิดพลาดเพิ่มขึ้น (p_c > p)</li><li>ความเสียหายจาก Cascade จะเติบโตแบบ Super-linear ตามจำนวนขั้นตอนการทำงาน (N)</li><li>การแก้ปัญหาไม่ใช่การทำให้ความผิดพลาดเป็นศูนย์ แต่เป็นการหยุดยั้งไม่ให้ความผิดพลาดขยายวงกว้าง</li></ul></div><p>นักพัฒนาหลายคนมักประเมินความผิดพลาดของ AI Agent แบบสถิติทั่วไป โดยวัดอัตราความผิดพลาดต่อขั้นตอน เช่น มีความผิดพลาด 10% ในแต่ละสเต็ป แล้วสันนิษฐานว่าข้อผิดพลาดเหล่านั้นเป็นอิสระต่อกัน แปลว่าหากสเต็ปไหนผิดพลาดไปแล้ว สเต็ปที่เหลือก็ควรจะดำเนินต่อไปได้ปกติ แต่เมื่อเราเฝ้าดูการทำงานจริง (Trajectory) กลับพบภาพที่ต่างออกไปโดยสิ้นเชิง</p><p>ในความเป็นจริง หากสเต็ปที่ 4 ได้ข้อเท็จจริงที่คลาดเคลื่อนเล็กน้อย สเต็ปที่ 5 จะนำข้อมูลที่ผิดพลาดนั้นมาประมวลผลต่อและยึดถือเป็นความจริงที่หนักแน่นขึ้น สเต็ปที่ 6 จะเริ่มดำเนินการต่อโดยอ้างอิงจากฐานที่ผิดทั้งสองส่วน และพอถึงสเต็ปที่ 8 เอเจนต์จะกำลังทำตามแผนงานที่ล่มสลายตั้งแต่สเต็ปที่ 4 ไปด้วยความมั่นใจเต็มร้อย กลายเป็นว่าข้อผิดพลาดเดียวเติบโตกลายเป็นห้าข้อผิดพลาด เพราะความผิดพลาดไม่ได้เป็นอิสระต่อกัน แต่ถูกผูกเข้าไว้ด้วยกันผ่านชุดบริบท (Context)</p><div class="stat-row"><div class="stat-item"><span class="stat-number">1.61</span><span class="stat-label">ความผิดพลาดต่อการรัน (แบบจำลองที่เชื่อมโยง)</span></div><div class="stat-item"><span class="stat-number">57%</span><span class="stat-label">สัดส่วนการรันที่มีข้อผิดพลาดปนเปื้อน</span></div><div class="stat-item"><span class="stat-number">x2.01</span><span class="stat-label">อัตราการขยายตัวเมื่อเทียบกับรุ่นอิสระ</span></div></div><p>ปรากฏการณ์นี้เรียกว่า <strong>Cascade</strong> หรือการลุกลามของความผิดพลาดในแนวตั้ง ซึ่งแตกต่างจากปัญหาในระบบจำหน่าย (Distributed Retry Patterns) ที่ความผิดพลาดกระจายตัวในแนวนอนไปยังหลายเวิร์กเกอร์พร้อมกัน ปัญหา Cascade จะกระจายตัวไปตามกาลเวลาภายในงานรันเดียว เพราะผลลัพธ์ในอดีตของเอเจนต์คืออินพุตในอนาคตของตัวมันเอง</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/ai_agent_msohosok_inline_1_28b6e4b1ce.jpg" alt="data flow chart diagram analytics" loading="lazy" /><p class="color-gray-500 text-sm mt-10">ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง</p></div><p>ฟังก์ชันแบบไร้สถานะ (Stateless Function) ทั่วไปเมื่อล้มเหลวก็จะแค่ส่งค่า Error กลับมา แต่เอเจนต์ที่ล้มเหลวจะทำสิ่งที่แย่กว่านั้นคือการบันทึกความล้มเหลวลงในที่ที่มันจะอ่านเจอได้อีก กลไกเดียวกันนี้เองที่ทำให้เอเจนต์ทำงานได้ ทรานสคริปต์จะสะสมและทุกขั้นตอนจะขึ้นอยู่กับข้อมูลก่อนหน้าทั้งหมด ซึ่งเป็นช่องทางเดียวกับที่ความผิดพลาดเดินทางผ่าน</p><div class="ai-insight"><p>ในมุมมองเชิงสถาปัตยกรรมซอฟต์แวร์ ปัญหา Cascade เกิดจากธรรมชาติของ LLM ที่อิงบริบท (In-context learning) ทำให้บริบทเก่ากลายเป็นความจริงเสมือน (Ground Truth) ของสเต็ปถัดไป การป้องกันจึงต้องอาศัยกลไกการตรวจสอบระหว่างทาง (Interruption points) มากกว่าการหวังพึ่งโมเดลที่สมบูรณ์แบบตั้งแต่ต้น</p></div><blockquote class="pull-quote"><p>"One bad step is not one bad step. It's a starting condition, and the agent will faithfully build on it until something makes it stop."</p><cite>Loop &amp; Retry</cite></blockquote><p>ความรุนแรงของ Cascade ยังเพิ่มขึ้นตามความยาวของการรัน (Run length) โดยหากเปรียบเทียบจำนวนขั้นตอน N จะเห็นการขยายตัวที่ชัดเจน:</p><ul><li>N=4: ขยายตัว 1.5 เท่า</li><li>N=8: ขยายตัว 2.0 เท่า</li><li>N=16: ขยายตัว 2.7 เท่า</li><li>N=25: ขยายตัว 3.2 เท่า</li></ul><p>ความผิดพลาดแบบอิสระจะเติบโตเป็นเส้นตรงตามค่า N แต่ข้อผิดพลาดแบบลุกลามจะเติบโตแบบ Super-linear เพราะการรันที่ยาวขึ้นเปิดโอกาสให้ข้อผิดพลาดตั้งต้นมีเวลาไปปนเปื้อนขั้นตอนปลายทางได้มากขึ้น ซึ่งมีรูปทรงกราฟเดียวกับ O(N²) token curve นั่นเอง</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/loopandretry/one-bad-step-n-bad-steps-how-agent-failures-cascade-538g" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

<div class="key-takeaways"><ul><li>Agent errors are not independent events but are coupled through the running context.</li><li>A contaminated context increases the probability of failure for every subsequent step (p_c > p).</li><li>Cascade severity scales super-linearly with the run length (N).</li><li>The leverage lies in stopping the first mistake from propagating, not in achieving zero errors.</li></ul></div><p>Many developers who reason about AI agents statistically often misjudge how errors behave. They measure a per-step error rate—such as 10% of steps producing incorrect outputs—and assume errors are entirely independent. Under this assumption, a single wrong step stays contained while the rest of the run proceeds normally. However, observing a real execution trajectory reveals a starkly different reality.</p><p>In practice, if step 4 gets a fact slightly off, step 5 reasons on top of that erroneous premise and commits to it even harder. Step 6 then takes an action based on both accumulated flaws, and by step 8, the agent is executing a doomed plan with absolute confidence. One mistake transforms into five because the errors are coupled through the context, turning a modest 10% step-error rate into a severely corrupted run.</p><div class="stat-row"><div class="stat-item"><span class="stat-number">1.61</span><span class="stat-label">Faults per run (coupled model)</span></div><div class="stat-item"><span class="stat-number">57%</span><span class="stat-label">Runs contaminated with at least one fault</span></div><div class="stat-item"><span class="stat-number">x2.01</span><span class="stat-label">Amplification factor over independent model</span></div></div><p>This phenomenon is known as a <strong>cascade</strong>: a single fault amplifying vertically down a trajectory. Unlike the horizontal spread seen in distributed retry patterns where a bad condition hits multiple workers simultaneously, a cascade spreads through time within a single run because an agent's past output serves as its future input.</p><<div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/ai_agent_msohosok_inline_1_28b6e4b1ce.jpg" alt="data flow chart diagram analytics" loading="lazy" /><p class="color-gray-500 text-sm mt-10">Stock photo for illustration only, not from the actual event</p></div><p>A stateless function that fails simply returns an error. An agent that fails does something far more dangerous: it writes the failure down into its transcript where it can read it again. The exact mechanism that makes agents functional—accumulating transcripts where every step conditions on prior history—is the exact channel down which mistakes travel.</p><div class="ai-insight"><p>From a software architecture perspective, cascades stem from the in-context learning nature of LLMs, where past outputs become treated as immutable ground truth by downstream steps. Mitigation requires active runtime interruption points rather than relying solely on baseline model accuracy.</p></div><blockquote class="pull-quote"><p>"One bad step is not one bad step. It's a starting condition, and the agent will faithfully build on it until something makes it stop."</p><cite>Loop &amp; Retry</cite></blockquote><p>The severity of cascades worsens with run length (N), distinguishing it clearly from independent noise:</p><ul><li>N=4: 1.5x amplification</li><li>N=8: 2.0x amplification</li><li>N=16: 2.7x amplification</li><li>N=25: 3.2x amplification</li></ul><p>Independent faults scale linearly with N, whereas cascading faults scale super-linearly because a longer run gives an early fault more downstream steps to poison. This shares the same curve shape as the O(N²) token curve.</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/loopandretry/one-bad-step-n-bad-steps-how-agent-failures-cascade-538g" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

medium_ai-agent-msohosok.jpg

small_ai-agent-msohosok.jpg

thumbnail_ai-agent-msohosok.jpg

ai-agent-msohosok.jpg

ทำไมความผิดพลาดเพียง 10% ในแต่ละขั้นตอนของ LLM Agent ถึงทวีคูณจนทำให้งานพังทั้งระบบ และวิธีรับมือกับปัญหา Cascade

Why a 10% per-step error rate in AI agents snowballs into total failure and how to stop context-driven contamination.

เจาะลึกความล้มเหลว AI Agent: เมื่อข้อผิดพลาดเดียวลุกลามเป็นลูกโซ่

One Bad Step, N Bad Steps: How LLM Agent Failures Cascade

<div class="key-takeaways"><ul><li>บทเรียนสอนการสร้างหน่วยความจำ AI มักใช้โค้ด 3 บรรทัดที่พังได้ง่ายในงานจริง</li><li>Agent ระยะยาวสะสมความจำ 4 ประเภทที่มีอายุขัยและการใช้งานต่างกัน</li><li>การใช้ฟีเจอร์ metadata ของ Mem0 ช่วยสร้างระบบจำแนกประเภทข้อมูลได้ทันที</li><li>การแบ่งประเภทความจำช่วยลดปริมาณโทเค็นที่เรียกใช้ลงได้ถึงราว 40%</li></ul></div><p>บทเรียนส่วนใหญ่เกี่ยวกับการเพิ่มความจำให้ LLM Agent มักจะแสดงตัวโค้ดแบบเดิมๆ เพียงสามบรรทัด เช่น การใช้คำสั่ง m = Memory() ตามด้วย m.add() และ m.search() วิธีนี้ใช้ได้ดีในระดับเดโม แต่จะพังไม่เป็นท่าเมื่อนำไปใช้กับ Agent จริงที่ต้องรันต่อเนื่องนานหลายสัปดาห์ เนื่องจากระบบปฏิบัติต่อทุกข้อเท็จจริงว่ามีความสำคัญและคงอยู่ถาวรเท่ากันหมด ในความเป็นจริง Agent จะสะสมความจำอย่างน้อย 4 ประเภทที่สลายตัว ถูกเรียกค้น และหมดอายุในรูปแบบที่ต่างกันโดยสิ้นเชิง หากเก็บข้อมูลทั้งหมดด้วยวิธีเดียวกัน จะส่งผลให้เกิดปัญหาใหญ่สองอย่างคือ Agent อ่านสถานะโปรเจกต์ที่เก่าไปแล้วว่าเป็นเรื่องจริง หรือหน้าต่าง Context Window เต็มไปด้วยเรื่องไม่สำคัญทุกครั้งที่มีการเรียกค้นข้อมูล</p><p>บทความนี้จะพาไปดูตัวอย่างการใช้สกีมาความจำแบบระบุชนิด (typed memory schema) บน Mem0 พร้อมโค้ดที่ใช้งานได้จริงเพื่อแก้ปัญหาทั้งสองจุด สมมติว่า Agent ของคุณเป็นผู้ช่วยเขียนโค้ดที่ทำงานข้ามเซสชันบนคลังโค้ดเดิม ตลอดระยะเวลาหลายสัปดาห์มันจะได้เรียนรู้ข้อมูลหลากหลายรูปแบบ</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/context_window_llm_agent_structured_memory_mem0_ms5m9z12_inline_1_5729c9d827.jpg" alt="code editor dashboard screen" loading="lazy" /><p class="color-gray-500 text-sm mt-10">ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง</p></div><p>แม้ข้อมูลเหล่านี้จะดูคล้ายกันในรูปของข้อความ แต่วิธีการทำงานของมันต่างกันอย่างสิ้นเชิง การเรียกคำสั่งแบบแบนราบอย่าง memory.add(text) ไม่สามารถระบุความแตกต่างเหล่านี้ได้ เมื่อคุณเรียกใช้คำสั่ง search() ในภายหลัง การจัดอันดับความเกี่ยวข้องของ Mem0 จะดึงบันทึกเรื่องกำหนดส่งงานเมื่อสามสัปดาห์ก่อนขึ้นมาปะปนกับค่าความชอบถาวรของผู้ใช้ได้อย่างหน้าตาเฉย เนื่องจากทั้งคู่มีความคล้ายคลึงทางความเหมือนของข้อความกับคำค้นหาของคุณ</p><div class="ai-insight"><p>การจัดการความจำของ AI ในลักษณะหน่วยความจำแบบแฟลต (flat memory) มักสร้างปัญหาคอขวดเมื่อระบบต้องทำงานในระยะยาว เนื่องจาก LLM ไม่มีกลไกแยกแยะความสำคัญตามบริบทเวลา การเพิ่มระบบโครงสร้างประเภทข้อมูลจึงเป็นหัวใจสำคัญในการเปลี่ยน AI จากแค่แชทบอทตอบคำถามเฉพาะหน้า ให้กลายเป็นผู้ช่วยทำงานจริงที่จดจำสถานะงานได้ถูกต้องเหมือนมนุษย์</p></div><p>ฟังก์ชัน add() ของ Mem0 รองรับการใส่ metadata แบบกำหนดเองได้ และคำสั่ง search() กับ get_all() ก็รองรับการกรองข้อมูลผ่านส่วนนี้เช่นกัน ซึ่งเพียงพอสำหรับการสร้างระบบประเภทข้อมูลน้ำหนักเบาโดยไม่ต้องแก้ไขโค้ดภายในของ Mem0 เลย หน่วยความจำประเภทสถานะโปรเจกต์คือตัวการสำคัญที่ทำให้เกิดบั๊กเมื่อข้อมูลล้าสมัย เนื่องจาก Mem0 ไม่มีระบบลบความจำอัตโนมัติ คุณจึงต้องสร้างกลไกการหมดอายุลงในเส้นทางการอ่านข้อมูล (read path) ไม่ใช่แค่ที่เส้นทางการเขียนข้อมูล (write path) เท่านั้น</p><p>ความไม่มีประสิทธิภาพที่ใหญ่ที่สุดในการใช้งาน Mem0 คือการเรียกคำสั่ง search() หนึ่งครั้งต่อหนึ่งเทิร์น ด้วยข้อความดิบของผู้ใช้เป็นคำค้นหาที่ค่าเริ่มต้น top_k สำหรับความจำทุกประเภท ซึ่งเท่ากับการค้นหาแบบเวกเตอร์ 3-4 ครั้งและดึงข้อความขนาดหลายกิโลไบต์ต่อหนึ่งเทิร์น</p><div class="stat-row"><div class="stat-item"><span class="stat-number">40%</span><span class="stat-label">ลดปริมาณโทเค็นที่ใช้ต่อเทิร์น</span></div></div><p>การแบ่งหน่วยความจำตามประเภทแทนที่จะใช้ที่เก็บข้อมูลแบบแบนราบ ให้ผลลัพธ์ที่ชัดเจนสามประการใน Agent เขียนโค้ดระยะยาวของผู้เขียน ได้แก่ การหยุดอ่านบันทึกงานที่กำลังทำอยู่ซึ่งล้าสมัยไปแล้วให้กลายเป็นข้อความปัจจุบัน, ช่วยให้การแก้ไขพฤติกรรมทำงานได้อย่างสม่ำเสมอ และลดจำนวนโทเค็นความจำที่ดึงมาใช้ต่อเทิร์นลงประมาณ 40% โดยการเปิดให้ระบบหมดอายุและการแคชข้อมูลสามารถทำงานได้ตั้งแต่แรก ทั้งหมดนี้ไม่ต้องพึ่งพาเครื่องมืออื่นใดนอกจากที่ mem0ai มีให้อยู่แล้ว นั่นคือ metadata และตัวกรอง</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/mukesh_13/stop-stuffing-your-llm-agents-context-window-structured-memory-categories-with-mem0-4l8i" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

<div class="key-takeaways"><ul><li>Most tutorials on giving AI agents memory use simple three-line code that breaks in production.</li><li>Long-running agents accumulate four distinct memory types with different lifecycles and behaviors.</li><li>Leveraging Mem0 metadata enables the creation of a lightweight type system instantly.</li><li>Categorizing memories cuts retrieved token volume per turn by roughly 40 percent.</li></ul></div><p>Most tutorials on giving an LLM agent memory show you the exact same three lines of code, such as initializing m = Memory() and calling m.add() followed by m.search(). This approach works fine in a demo, but it completely falls apart in a real agent that runs for weeks because it treats every piece of fact as equally important and permanent. In practice, an agent accumulates at least four different kinds of memory that decay, get retrieved, and get invalidated in entirely different ways. Storing all of them the same way leads to two major failure modes: the agent reads stale project states as if they are still current, or it floods its context window with low-value trivia every time a search query runs.</p><p>This article walks through a typed memory schema built on top of Mem0 that fixes both problems, complete with working code. Imagine your agent is a coding assistant working across sessions on the exact same repository. Over the course of a few weeks, it learns various kinds of information.</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/context_window_llm_agent_structured_memory_mem0_ms5m9z12_inline_1_5729c9d827.jpg" alt="code editor dashboard screen" loading="lazy" /><p class="color-gray-500 text-sm mt-10">Stock photo for illustration only, not from the actual event</p></div><p>While these entries look similar as plain text, they behave completely differently in practice. A flat memory.add(text) call has no native way to express this distinction. When you later execute a search() call, Mem0's relevance ranking will happily surface a three-week-old schedule note right alongside a permanent user preference because both score similarly on semantic similarity to your query.</p><div class="ai-insight"><p>Flat memory architectures in AI agents often create severe bottlenecks during long-running tasks because large language models lack innate temporal context filtering. Introducing a structured typing layer is crucial to transition AI from a simple transactional chatbot into a reliable assistant that maintains accurate working states.</p><p>Mem0's add() method accepts arbitrary metadata, and both search() and get_all() support filtering on it. That is all it takes to build a lightweight type system without ever touching Mem0's internal codebase. Project-state memories are precisely the ones that trigger actual bugs when they become stale. Because Mem0 does not automatically expire memories, developers must build expiration logic directly into the read path rather than just the write path.</p><p>The single biggest inefficiency observed in Mem0 integrations involves calling search() once per conversational turn using the raw user message as the query at default top_k settings for every single memory kind. This results in multiple vector searches and several kilobytes of retrieved text per turn.</p><div class="stat-row"><div class="stat-item"><span class="stat-number">40%</span><span class="stat-label">Reduction in per-turn tokens</span></div></div><p>Splitting memory categories instead of relying on a single flat store achieved three concrete results in a long-running coding agent maintained by the author: it halted stale in-progress notes from being misinterpreted as current facts, allowed behavioral corrections to apply consistently rather than relying on semantic luck, and cut average retrieved-memory tokens per turn by roughly 40 percent by enabling proper expiration and caching mechanisms in the first place. None of this demands anything beyond what mem0ai already exposes out of the box.</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/mukesh_13/stop-stuffing-your-llm-agents-context-window-structured-memory-categories-with-mem0-4l8i" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

medium_article-711.jpg

small_article-711.jpg

thumbnail_article-711.jpg

article-711.jpg

แนวทางการแก้ปัญหาการจัดการความจำของ AI Agent ระยะยาวด้วยการแบ่งประเภทข้อมูลแบบมีโครงสร้างผ่าน Mem0 เพื่อลดการใช้โทเค็นและป้องกันข้อมูลเก่าค้างในระบบ

A practical guide to solving long-term AI agent memory management by implementing a typed memory schema using Mem0 to reduce token consumption and prevent stale data.

หยุดยัดข้อความทุกอย่างลง Context Window ของ LLM Agent ด้วยระบบ Structured Memory จาก Mem0

Stop Stuffing Your LLM Agent's Context Window: Structured Memory Categories with Mem0

<div class="key-takeaways"><ul><li>LLM Agent คือโมเดลที่ทำงานในลูปการคิด การกระทำ และการสังเกต</li><li>การจำลองวงจรด้วย Finite State Machine (FSM) ช่วยให้ระบบควบคุมได้และชัดเจนขึ้น</li><li>เมื่อระบบซับซ้อนขึ้น Hierarchical State Machines (HSM) ช่วยจัดการโครงสร้างย่อยได้ดี</li><li>LangGraph เป็นหนึ่งในเฟรมเวิร์กที่รองรับการใช้งาน StateGraph และ Subgraphs ได้อย่างสะอาดตา</li></ul></div><p>ในบทความก่อนหน้านี้ เราได้นิยามความหมายของเอเจนต์ในทางปฏิบัติว่าเป็นโมเดล LLM ที่อยู่ในวงจรซึ่งสามารถหาเหตุผล ลงมือทำ สังเกตผลลัพธ์ และตัดสินใจขั้นตอนต่อไปได้ ถึงแม้คำนิยามนี้จะถูกต้อง แต่ก็ยังคงมีความเป็นนามธรรมสูงเกินไปในทางปฏิบัติ</p><p>ทุกวันนี้ผู้คนจำนวนมากนิยมสร้างเอเจนต์ด้วยแนวทาง vibe coding โดยการขอให้โมเดลเขียนโค้ดชุดหนึ่งให้ คัดลอกไปใช้งานต่อทันที เนื่องจากโมเดลปัจจุบันมีความสามารถในการเขียนโค้ดที่ยอดเยี่ยม กระบวนการนี้จึงให้ความรู้สึกราวกับเวทมนตร์ แต่ปัญหาที่มักตามมาคือการนำโซลูชันไปใช้งานโดยปราศจากความเข้าใจในแนวคิดพื้นฐานที่แท้จริง</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/ai_agent_state_machine_hierarchical_state_machines_ms1xxqli_inline_1_5faa733dca.jpg" alt="coding workflow diagram" loading="lazy" /><p class="color-gray-500 text-sm mt-10">ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง</p></div><p>เมื่อขาดความเข้าใจในหลักการ โมเดลอาจแนะนำโซลูชันที่มีความซับซ้อนเกินความจำเป็น เช่น การเสนอให้ใช้ Hierarchical State Machine ทั้งที่การใช้ Finite State Machine แบบง่ายก็เพียงพอแล้ว เพื่อหลีกเลี่ยงปัญหานี้และสร้างความชัดเจน เราจึงควรจำลองวงจรการทำงานของเอเจนต์ให้ออกมาในรูปแบบของเครื่องมือควบคุมสถานะอย่างชัดเจนและควบคุมได้</p><div class="ai-insight"><p>การใช้แนวคิด State Machine เข้ามาจับกับการทำงานของ AI Agent ช่วยเปลี่ยนจากการพึ่งพาคำสั่ง prompt ยาวๆ ให้กลายเป็นสถาปัตยกรรมซอฟต์แวร์ที่มีโครงสร้างแน่นอน ทำให้การตรวจสอบข้อผิดพลาด (debugging) ทำได้ง่ายขึ้นและคาดเดาพฤติกรรมของเอเจนต์ได้ดีกว่าเดิม</p></div><p>วงจรพื้นฐานที่สุดของเอเจนต์สามารถจำลองเป็น Finite State Machine (FSM) ได้ โดยสถานะจะประกอบด้วยงาน โค้ด ผลการสังเกตล่าสุด และสถานะปัจจุบัน ซึ่งการเปลี่ยนผ่านระหว่างสถานะจะขึ้นอยู่กับผลลัพธ์ในแต่ละขั้นตอน ตัวอย่างโค้ดจำลองแสดงลูปการทำงานตั้งแต่วิธีคิด ไปจนถึงการลงมือทำผ่านเครื่องมือและการสังเกตผลลัพธ์</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/xvierd/agentes-101-02-el-ciclo-del-agente-como-state-machine-y-hierarchical-state-machines-5986" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

<div class="key-takeaways"><ul><li>An LLM agent operates inside a loop of reasoning, acting, and observing.</li><li>Modeling the agent loop as a Finite State Machine provides explicit and controllable execution.</li><li>Hierarchical State Machines (HSMs) help manage complexity as agent systems grow.</li><li>LangGraph offers clean primitives like StateGraph and Subgraphs to implement these patterns.</li></ul></div><p>In our previous article, we defined an agent practically as an LLM model operating within a loop where it can reason, act, observe results, and decide the next steps. While correct, that definition remains somewhat abstract for hands-on development.</p><p>Nowadays, many developers build agents using vibe coding. They ask the model to generate an agent script, copy the code, and run with it. Because current models are exceptionally skilled at writing code, the process feels magical. However, the catch is implementing architectures without grasping the foundational concepts underneath.</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/ai_agent_state_machine_hierarchical_state_machines_ms1xxqli_inline_1_5faa733dca.jpg" alt="coding workflow diagram" loading="lazy" /><p class="color-gray-500 text-sm mt-10">Stock photo for illustration only, not from the actual event</p></div><p>Without understanding core concepts, models may suggest overly complex solutions. For instance, recommending a Hierarchical State Machine when a simple Finite State Machine would more than suffice. To build clearly, controllably, and scalably, we must model the agent lifecycle explicitly as a state machine.</p><div class="ai-insight"><p>Applying State Machine principles to AI agents shifts the implementation away from messy prompt chains toward deterministic software architecture. This makes debugging significantly easier and behavior vastly more predictable in production environments.</p><p>The fundamental agent loop can be mapped directly to a Finite State Machine (FSM), where state transitions depend entirely on the output of each discrete step—moving between thinking, acting, and observing states until completion.</p></div><p>A flat FSM works well for straightforward agents, but growing systems demand Hierarchical State Machines to cleanly segregate concerns like investigation, implementation, and validation phases using frameworks like LangGraph.</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/xvierd/agentes-101-02-el-ciclo-del-agente-como-state-machine-y-hierarchical-state-machines-5986" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

medium_ai-agent-state-machine-hierarchical-state-machines-ms1xxqli.jpg

small_ai-agent-state-machine-hierarchical-state-machines-ms1xxqli.jpg

thumbnail_ai-agent-state-machine-hierarchical-state-machines-ms1xxqli.jpg

ai-agent-state-machine-hierarchical-state-machines-ms1xxqli.jpg

ทำความเข้าใจวงจรการทำงานของ LLM Agent ผ่านแนวคิด Finite State Machine และวิธีขยายระบบด้วย LangGraph

Dive deep into LLM agent lifecycles using Finite State Machines, Hierarchical State Machines, and LangGraph.

เจาะลึกการสร้าง AI Agent ด้วย State Machine และ Hierarchical State Machines

Agentic Workflows 101: Modeling AI Agents with State Machines

Inewgen

Inewgen

#LLM Agents

EvolveTrade: งานวิจัย KAIST เผย AI Agent พัฒนา Prompt เอง

Inewgen

Google AI เปิดตัว EnvHarness เปลี่ยนสภาพแวดล้อม AI

Inewgen

เจาะลึกความล้มเหลว AI Agent: เมื่อข้อผิดพลาดเดียวลุกลามเป็นลูกโซ่

Inewgen

หยุดยัดข้อความทุกอย่างลง Context Window ของ LLM Agent ด้วยระบบ Structured Memory จาก Mem0

Inewgen

เจาะลึกการสร้าง AI Agent ด้วย State Machine และ Hierarchical State Machines

Inewgen