Observability សម្រាប់ Agent៖ អ្នកមិនអាច Debug អ្វីដែលអ្នកមិនអាច Trace

កម្មវិធីប្រពៃណីបរាជ័យតាមរបៀបដូចគ្នាគ្រប់ពេលដែលអ្នកឱ្យ input ដូចគ្នា ដូច្នេះ log file និង stack trace ជាធម្មតាគ្រប់គ្រាន់ដើម្បីរក bug។ Agent មិនដំណើរការបែបនោះទេ។ ឱ្យវានូវ task ដូចគ្នាពីរដង ហើយវាអាចយក path ខុសគ្នាពីរ ជោគជ័យម្ដង បរាជ័យម្ដង ហើយទុកឱ្យអ្នកនូវ log ដែលពន្យល់គ្មានមួយណាទេ។ ពេលប្រព័ន្ធដែលមិន deterministic បរាជ័យតាមរបៀបដែលអ្នកមិនអាចផលិតឡើងវិញ log ក្រោយពេលហេតុការណ៍ ស្ទើរតែឥតប្រយោជន៍ — អ្វីដែលអ្នកត្រូវការគឺកំណត់ត្រាស្មោះត្រង់នៃ អ្វីដែល agent បានធ្វើពិតប្រាកដ មួយជំហានម្ដងៗ លើកដំបូង។ កំណត់ត្រានោះជា trace ហើយការសាងវិន័យដើម្បីចាប់យក និងអានវា — observability — កំពុងស្ងាត់ៗក្លាយជាកម្រាលក្រោមអ្វីៗផ្សេងទៀតដែលអ្នកធ្វើជាមួយ agent។

វាសមនឹងយល់ថា ការស្រាវជ្រាវឆ្នាំ ២០២៦ និយាយថា នេះត្រូវការអ្វីពិតប្រាកដ ព្រោះ “add logging” ប៉ាន់ស្មានវាទាបពេក។ Observability របស់ agent មានផ្នែកពិបាកបី ហើយផ្នែកនីមួយៗជាបញ្ហាដាច់ដោយឡែក។

គម្លាត semantic៖ intent ទល់នឹង action

បញ្ហាទីមួយគឺ agent ធ្វើរបស់ពីរប្រភេទ ហើយ tool របស់អ្នកជាធម្មតាឃើញតែមួយ។ មាន​អ្វីដែល agent មានបំណង — មើលឃើញក្នុង prompt និង reasoning របស់វា — ហើយអ្វីដែលវា បានធ្វើ — មើលឃើញក្នុង system call, file write, និង network traffic របស់វា។ Framework មួយឈ្មោះ AgentSight (arXiv 2508.02736) ដាក់ឈ្មោះអន្ទាក់នោះយ៉ាងជាក់លាក់៖ “existing tools observe either an agent’s high-level intent (via LLM prompts) or its low-level actions (e.g., system calls), but cannot correlate these two views. This blindness makes it difficult to distinguish between benign operations, malicious attacks, and costly failures”។

នោះជាចំណុចស្នូល។ ការលុប file គឺល្អ ប្រសិនបើ agent មានបំណងសម្អាត ហើយជាគ្រោះមហន្តរាយ ប្រសិនបើ prompt injection ប្រាប់វាឱ្យធ្វើ — ហើយអ្នកមិនអាចប្រាប់ថាមួយណាពី syscall តែឯង ឬពី prompt តែឯងទេ។ អ្នកត្រូវការពួកវា correlate។ ស្រមៃការ review ហេតុការណ៍៖ ការ monitor របស់អ្នកបង្ហាញថា agent បានធ្វើ network call ចេញទៅ host មិនស៊ាំមួយនៅ 3am។ តើនោះជា data exfiltration ពី agent ដែលត្រូវ hijack ឬ agent ទាញ dependency ស្របច្បាប់ដែលវា reason ថាវាត្រូវការ? Syscall log មិនអាចនិយាយទេ។ មានតែដោយតម្រៀប network event នោះទល់នឹង reasoning ដែលនាំមុនវា — តើ agent សម្រេចធ្វើនេះ ហើយហេតុអ្វី? — ទើបអ្នកអាចចាត់ថ្នាក់វា។ Observability tool ដែលបង្ហាញអ្នកនូវផ្នែកពាក់កណ្ដាលនៃរូបភាពនោះ មិនមែនកំពុងឱ្យអ្នកនូវចម្លើយពាក់កណ្ដាលទេ វាកំពុងឱ្យអ្នកនូវចម្លើយឥតមួយ ព្រោះអត្ថន័យទាំងមូលនៅក្នុង correlation។ វិធីសាស្ត្ររបស់ AgentSight “boundary tracing” មើល agent “from outside their application code at stable system interfaces using eBPF” — intercept traffic LLM ដែលបាន encrypt សម្រាប់ intent, kernel event សម្រាប់ effect, ហើយដេរទាំងពីរចូលគ្នា។ ផលចំណេញគឺ view ដែល correlate នេះ “detects prompt injection attacks, identifies resource-wasting reasoning loops, and reveals hidden coordination bottlenecks in multi-agent systems” — failure mode បីដែលមើលមិនឃើញចំពោះ stream ណាមួយតែឯង។ ហើយវាធ្វើបែបនេះ instrumentation-free, framework-agnostic, និងនៅ “less than 3% performance overhead,” ដែលសំខាន់ ព្រោះ observability layer ដែលអ្នកត្រូវ bolt ចូលគ្រប់ agent ហើយដែលយក tax លើគ្រប់ run នឹងមិនរស់រានពេលប៉ះ production ទេ។

Trace ជា structured — ហើយរបៀបដែលអ្នកតំណាងវាជា infrastructure

បញ្ហាទីពីរលេចឡើងពេលអ្នក មាន trace៖ trace របស់ agent មិនមែនជា chat log ទេ ហើយការប្រព្រឹត្តវាដូចជា chat log ធ្វើឱ្យអ្វីៗ downstream ទាំងអស់អន់ថយ។ ក្រដាសឆ្នាំ ២០២៦ ស្ដីពី View-oriented Conversation Compiler (VCC) (arXiv 2603.29678) ដាក់ចំណុចនេះយ៉ាងមុត៖ ការសន្ទនា agent សម័យទំនើប “contain deeply structured content, including nested tool calls and results, chain-of-thought reasoning blocks, sub-agent invocations, context-window compaction boundaries, and harness-injected system directives, whose complexity far exceeds that of simple user-assistant exchanges. Feeding such traces to a reflector or other analytical mechanism in plain text, JSON, YAML, or via grep can materially degrade analysis quality”។

ការដោះស្រាយ — compile trace log ឆៅទៅជា structured view ដែលសាងសម្រាប់គោលបំណង — បង្កើតជ័យជម្នះជាក់លាក់ និងវាស់បាន។ ក្នុងការពិសោធរបស់ពួកគេ “replacing only the reflector’s input format, from raw JSONL to VCC-compiled views, leads to higher pass rates across all three model configurations tested, while cutting reflector token consumption by half to two-thirds”។ ផ្លាស់ប្ដូរគ្មានអ្វី លើកលែងតែរបៀបដែល trace ត្រូវ តំណាង ហើយ analysis ក្លាយជាទាំងល្អ និងថោកជាងយ៉ាងខ្លាំង។ សេចក្តីសន្និដ្ឋានរបស់ពួកគេជារបស់ដែលត្រូវធ្វើឱ្យជាប់ខ្លួន៖ “message format functions as infrastructure for context engineering, not as an incidental implementation choice”។ Observability មិនមែនគ្រាន់តែចាប់យក trace ទេ វាជាការតំណាងវាដើម្បីឱ្យអ្វីមួយអាច reason លើវាបានពិតប្រាកដ — ដែលជា វិន័យ context-engineering ដូចគ្នាដែលតម្រង់ចូលក្នុង log ផ្ទាល់ខ្លួនរបស់អ្នក។

វិន័យនៅក្មេង — បញ្ហា integration នៅបើកចំហ

របស់ទីបីដែលត្រូវដឹងគឺគ្មាននរណាដោះស្រាយ stack ពេញលេញនៅឡើយទេ ដូច្នេះកាលីប្រេតការរំពឹងទុករបស់អ្នក។ ការ survey ឆ្នាំ ២០២៦ ស្ដីពី AI observability កំណត់ scope៖ ការ monitor ដែលលាតសន្ធឹង “the full stack — from model internals to GPU kernels,” រៀបចំជា taxonomy ប្រាំ layer ឆ្លងកាត់ model-internal probe, chain-of-thought monitorability, infrastructure tracing, និងផ្សេងទៀត។ សេចក្តីវិនិច្ឆ័យស្មោះត្រង់របស់វាគឺថា ខណៈ “individual monitoring layers have matured rapidly, the integration challenge — connecting model-level confidence signals with infrastructure-level anomalies into coherent operational intelligence — remains the defining open problem for the field”។

ម្យ៉ាងទៀត៖ មាន tool ល្អៗសម្រាប់ layer នីមួយៗ ហើយគ្មាន product turnkey ដែលចងពួកវាចូលជារូបភាពស៊ីសង្វាក់មួយ។ នោះជាគម្លាតមួយដែលត្រូវរៀបចំជុំវិញ — អ្នកនឹង assemble observability ពីផ្នែកៗមួយរយៈពេលទៀត — ប៉ុន្តែវាក៏ពិតជាប្រភេទនៃបញ្ហាបើកចំហ ដែលវិស្វកម្មយ៉ាងម៉ត់ចត់ មិនមែនដើមទុន សម្រេចថានរណាសាងសង់របស់ល្អ។

Observability ជាកម្រាលក្រោមអ្វីៗផ្សេងទៀត

ថយក្រោយ ហើយកត់សម្គាល់ថា observability មិនមែនជាការព្រួយបារម្ភ agent មួយទៀតក្បែរ evaluation, debugging, និង security ទេ — វាជា substrate ដែលទាំងបីឈរលើ។ អ្នកមិនអាចវាយតម្លៃ trajectory របស់ agent ប្រសិនបើអ្នកមើល trajectory មិនឃើញ យើងបានអះអាងក្នុង the leaderboard lies about your agent ថាអ្នកគួរអាន trace មិនមែន column pass/fail — ហើយនោះអាចទៅរួចតែប្រសិនបើ trace មានវត្តមាន និងអាចអានបាន។ អ្នកមិនអាច debug ការអន់ថយដែលអ្នកមិនអាច reconstruct។ អ្នកមិនអាចបញ្ជាក់ថា sandbox មួយបានទប់ស្កាត់ហេតុការណ៍ ឬថា prompt injection ត្រូវបានចាប់ ដោយគ្មានកំណត់ត្រា correlate នៃ intent និង action ទេ។ វិន័យផ្សេងទៀតគ្រប់យ៉ាងក្នុង agentic stack សន្មតថាអ្នកអាចមើលឃើញអ្វីដែល agent បានធ្វើ។ Observability ជាការសន្មតដែលធ្វើឱ្យពិត។

នោះជាមូលហេតុដែលវាកំពុងក្លាយជាលក្ខខណ្ឌមុនសម្រាប់ production មិនមែនជា nice-to-have ទេ។ Agent ដែលអ្នកមិនអាច trace ជា agent ដែលអ្នកមិនអាចទុកចិត្តនៅ scale ព្រោះការបរាជ័យឥតពន្យល់ដំបូងរបស់វា ក៏ជា clue ចុងក្រោយរបស់វាដែរ។

មាន arc ភាពចាស់ទុំមួយនៅទីនេះដែលសមនឹងដាក់ឈ្មោះ។ របស់ដំបូងដែលក្រុម instrument គឺតម្លៃ — token spend ក្នុងមួយ run — ព្រោះវាលេចលើ bill។ ទីពីរគឺ latency។ ប៉ុន្តែ trace ជារបស់ដែលឆ្លើយ ហេតុអ្វី ពិតប្រាកដ ហើយវាជារបស់ដែលក្រុមភាគច្រើនបន្ថែមតែក្រោយពេលហេតុការណ៍ដែលពួកគេមិនអាចពន្យល់បាន បង្ខំ។ ការផ្លាស់ប្ដូរដែលការស្រាវជ្រាវកំពុងរុញគឺ ប្រព្រឹត្ត trace ដែល correlate និង format ល្អ ជា first-class ពីថ្ងៃទីមួយ — តាមរបៀបដូចគ្នាដែលក្រុមកម្មវិធីចាស់ទុំ ប្រព្រឹត្ត distributed tracing ជា table stakes ជាជាងការប្រញាប់ post-mortem។ Agent លើកកម្ពស់ភាគហ៊ុនលើមេរៀននោះ ព្រោះគម្លាតរវាង “វាដំណើរការក្នុង demo” និង “វាបានធ្វើអ្វីដែលពន្យល់មិនបានក្នុង production” គឺទូលាយជាង ហើយមកដល់លឿនជាងកម្មវិធី deterministic។

ហេតុអ្វីនេះអនុគ្រោះអាស៊ីអាគ្នេយ៍

នេះជាផ្នែកដែលសំខាន់សម្រាប់តំបន់នេះ ហើយវាជារូបរាងស៊ាំឥឡូវ ជាមួយអំណោយបន្ថែមមួយ។ ការសាង observability សម្រាប់ agent — ចាប់យក trace ដែល correlate, compile វាទៅជា view ដែលអានបាន, តម្រៀប layer ចូលជាអ្វីដែលវិស្វករ on-call អាចប្រើបានពិតប្រាកដ — ជា tooling និងការវិនិច្ឆ័យ មិនមែនដើមទុន។ វា run លើវិន័យវិស្វកម្ម មិនមែន GPU cluster ហើយវាជាជំនាញឥតលំអ ដែលបំបែកក្រុមដែលអាច operate agent ក្នុង production ពីក្រុមដែលអាចតែ demo ពួកវា។

អំណោយបន្ថែមនៅក្នុងវិធីសាស្ត្រ instrumentation-free ដូចជា boundary tracing៖ ព្រោះពួកវាមើល agent ពីខាងក្រៅ នៅ system interface អ្នកអាច monitor agent ដែលអ្នកមិនបានសាង និង framework ដែលអ្នកមិនបានគ្រប់គ្រង ហើយ tooling របស់អ្នករស់រានពេលមាន breaking API change បន្ទាប់។ សម្រាប់តំបន់ដែលសាងលើ open model និង agent ភាគីទីបី ជាជាង stack ផ្ទាល់ខ្លួនកម្មសិទ្ធិ នោះពិតជារូបរាងត្រឹមត្រូវ — មើលនៅ boundary, កាន់កាប់ operational layer, ហើយកុំពឹងលើ vendor ណាមួយដើម្បី instrument code របស់ពួកគេជំនួសអ្នក។ ក្រុមដែលឈ្នះការទុកចិត្តជាមួយ agent ក្នុង production នឹងមិនមែនជាក្រុមដែលមាន demo ភ្លឺបំផុតទេ។ ពួកគេនឹងជាក្រុមដែលអាចឆ្លើយ យ៉ាងជាក់លាក់ និងក្រោយពេលហេតុការណ៍ នូវសំណួរដែលសម្រេចគ្រប់ហេតុការណ៍៖ តើ agent បានធ្វើអ្វីពិតប្រាកដ?