ردیابی توزیع‌شده در Cognivern؛ پایان عصر «باستان‌شناسی لاگ‌ها» در عامل‌های

اگر همین حالا یک عامل هوش مصنوعی برای مدیریت دارایی‌های شما تصمیم بگیرد و شما ندانید «چرا» این اتفاق افتاده، در واقع یک سیستم مال‌مالی دارید، نه یک ابزار مهندسی. برای توسعه‌دهندگان Cognivern، عیب‌یابی یک عامل خودمختار بیشتر شبیه به باستان‌شناسی بود تا مهندسی نرم‌افزار؛ آن‌ها باید ساعت‌ها میان هزاران خط کد می‌گشتند تا بفهمند چرا یک پیشنهاد قیمت خاص امضا شده یا چرا هزینه‌های توکن ناگهان جهش کرده است.

این عامل که برای اجرای مزایده‌های قیمت‌گذاری مهروموم‌شده در Canton DevNet برای درخواست‌های مناقصه سازمانی (RFP) طراحی شده، در چرخه‌های بسته عمل می‌کند: درخواست مناقصه (RFP) را می‌خواند، از یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده and حالا با همان لحن کتاب‌ها جواب می‌دهد — کمک می‌گیرد، یک پیشنهاد قیمت را انتخاب می‌کند، آن را امضا کرده و به یک قرارداد Daml ارسال می‌کند؛ تمام این مراحل بدون هیچ دخالت انسانی در حلقه (Human-in-the-loop) انجام می‌شود. طبق گزارش تیم فنی، ساخت منطق مناقصه ساده بود، اما پاسخ به سوالات بنیادین دشوار بود: عامل در واقع چه کاری انجام داد، این چرخه دقیقاً چقدر هزینه داشت و آیا موتور سیاست‌گذاری به دلیل درستی اجازه این اقدام را داده است یا خیر؟

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی زیرساخت‌های عامل‌محور اشاره کردیم، اکثر این سیستم‌ها به جای یک فراخوانی واحد، مجموعه‌ای از رویدادهای گسسته هستند. این چالش‌ها به‌ویژه در مدیریت هزینه‌ها مشهود است، جایی که معماری‌های لایه‌ی دروازه تلاش می‌کنند از تخلیه سریع بودجه در عامل‌های مالی جلوگیری کنند. پیش از ادغام یک پشته‌ی نظارت‌پذیری (Observability Stack) مناسب، «عیب‌یابی» به معنای جست‌وجو (grepping) در خروجی کنسول چهار سرویس مجزا و امید به این بود که مهر و زمان (Timestamp) آن‌ها با هم هم‌خوانی داشته باشد. در مورد Cognivern، یک حلقه تصمیم‌گیری واحد، زنجیره‌ای پیچیده است که شامل خواندن RFP و پیش‌بینی قیمت، یک مسیریاب LLM برای انتخاب مدل و اجرا با مکانیسم جایگزین (Fallback)، یک سرویس حاکمیتی برای ارزیابی مجاز بودن اقدام و در نهایت یک سرویس حسابرسی برای ثبت رکورد است. بدون یک شناسه مشترک، توسعه‌دهنده مجبور است برای درک دلیل رد شدن یک پیشنهاد یا علت کندی یک فراخوانی LLM، میان چهار لاگ مجزا جابجا شود که این امر باعث سردرگمی و اتلاف وقت می‌شود.

به نقل از مستندات پروژه، تیم برای حل این مشکل از OpenTelemetry (OTel) و SigNoz استفاده کرد. آن‌ها تمام ابزارسازی‌ها (Instrumentation) را در یک فایل واحد otel.ts متمرکز کردند که توسط تمام سرویس‌ها فراخوانی می‌شود. این تنظیمات یک NodeTracerProvider و یک اکسپورتر OTLP gRPC را پیکربندی می‌کند که داده‌ها را به یک نمونه میزبانی‌شده (Self-hosted) از SigNoz می‌فرستد. با پیوست کردن ویژگی‌های منابع (Resource Attributes)، اسپان‌های (Spans) مربوط به سرویس‌های مختلف همچنان به عنوان بخشی از یک اجرای واحد از عامل شناخته می‌شوند.

معماری یک تصمیم

به دلیل استفاده از این پیکربندی مشترک توسط runtime عامل، مسیریاب LLM، سرویس اجرای سیاست‌ها و سرویس لاگ حسابرسی، همه‌ی آن‌ها یک traceId یا شناسه ردیابی یکسان دارند. این شناسه، لاگ‌های پراکنده را به یک داستان خواندنی تبدیل می‌کند. حالا مسیر کامل یک تصمیم، از اولین جرقه تا ثبت نهایی در رکورد حسابرسی، به جای یک تمرین حافظه، یک توالی قابل کلیک است.

یک چرخه تصمیم‌گیری معمولی اکنون به شکل یک درخت ردیابی (Span Tree) دیده می‌شود:

• agent.sapience.forecast_cycle (۸۴۲ میلی‌ثانیه)
  • llm.execute_with_fallback (۳۸۸ میلی‌ثانیه)
  • governance.evaluate_decision (۱۱۲ میلی‌ثانیه)
  • audit.log_action (۴۴ میلی‌ثانیه)

از ردیابی تا داشبوردهای انسانی

ردیافت‌ها برای کالبدشکافی پس از وقوع خطا (Post-mortem investigation) زمانی که یک تصمیم خاص مورد تردید است، بسیار مفید هستند. اما برای نظارت کلی بر سلامت سیستم، تیم به راهی نیاز داشت تا مشکلات را در یک نگاه شناسایی کند. بر اساس بررسی‌های فنی، آن‌ها معیارهای OTel را برای هزینه‌ی توکن، تعداد اقدامات (تأییدشده در برابر ردشده) و تأخیر ارائه‌دهندگان استخراج کردند. این داده‌ها به سه داشبورد بومی در SigNoz تبدیل شدند که مستقیماً در صفحه /observability اپلیکیشن وب Cognivern تعبیه شده‌اند. این بدان معناست که اپراتور برای نظارت بر سلامت عامل، نیازی به ورود جداگانه به پنل SigNoz ندارد.

این رویکرد نظارتی، پیش‌نیازی برای اتوماسیون‌های پیشرفته‌تر است؛ برای مثال، برخی سیستم‌ها اکنون از مدل‌های Llama-3.1 برای تحلیل ریشه‌ای خطاها از طریق تله‌متری SigNoz استفاده می‌کنند تا سرعت بازیابی سیستم را افزایش دهند.

• نمای کلی حاکمیت (Governance Overview): ردیابی تعداد اقدامات پذیرفته یا رد شده و دلیل دقیق (Reasoning) پشت هر یک از این تصمیمات.
• هزینه توکن (Token Cost): بررسی هزینه هر چرخه برای شناسایی سریع حلقه‌های بی‌نهایت LLM پیش از آنکه این هزینه‌ها در صورت‌حساب ماه آینده ظاهر شوند.
• سلامت ارائه‌دهندگان (Provider Health): بصری‌سازی تأخیر و رفتار جایگزینی (Fallback) در زنجیره ارائه‌دهندگان مدل‌های زبانی.

به دلیل پشتیبانی SigNoz از لینک‌های عمیق (Deep-linking)، کلیک بر روی یک رویداد حاکمیتی در داشبورد، کاربر را مستقیماً به همان ردیابی (Trace) می‌برد که آن تصمیم را ایجاد کرده است. این پیوند، دسترسی فوری به کل زمینه (Context) مدل زبانی، استدلال سیاست‌گذاری و محتویات امضا شده (Signed Payload) را فراهم می‌کند. سرویس حسابرسی، traceId را در کنار هر رکورد ثبت‌شده ذخیره می‌کند. در نتیجه، یک ورودی حسابرسی دیگر نه صرفاً بیانیه‌ای است که می‌گوید «اقدام X در زمان Y مجاز بود»، بلکه یک اشاره‌گر دائمی به ردیابی است که توضیح می‌دهد «چرا» این اتفاق افتاد. برای سیستمی که تصمیمات مالی خودمختار، امضاشده و روی زنجیره (On-chain) می‌گیرد، توانایی پاسخ به این سوال که «چرا این کار را کرد»، کل هدف و فلسفه وجودی سیستم است.

وضعیت واقعی دفتر کل

این سیستم در حال حاضر با داده‌های واقعی روی Canton در حال اجرا است و نه یک شبیه‌ساز. داشبورد نمای کلی حاکمیت، دیدی فوری از وضعیت دفتر کل (Ledger State) را فراهم می‌کند بدون اینکه نیاز به پرس‌وجوهای دستی از دفتر کل Canton باشد. طبق آخرین بررسی سرور (VPS) فعال، سه دور مناقصه واقعی (که همگی دارای برچسب backend: canton هستند) فعال می‌باشند:

• مناقصه حسابرسی امنیتی (Security Audit RFP): در حال حاضر باز است و دو پیشنهاد قیمت برای آن ارسال شده است.
• قرارداد مشاوره حقوقی ۲۰۲۶ (Legal-Counsel Retainer for 2026): قیمت‌ها فاش شده‌اند. این مناقصه توسط حساب bob-cognivern::122003aa7c491e00a453145c4d2cd3dbf5db8908b4e663c9944baed57fd66effa668 با پیشنهاد برنده ۱۸۵,۰۰۰ واحد به دست آمده است.
• تعهد ۳ ساله زیرساخت ابری (Cloud-Infrastructure 3-Year Commit): در حال حاضر باز است و یک پیشنهاد قیمت برای آن ثبت شده است.

هزینه بازسازی زیرساخت

توسعه‌دهنده این پروژه اشاره می‌کند که نگاه به ردیابی (Tracing) به عنوان یک ابزار «ضمیمه» یا Bolt-on برای زمانی که چیزها خراب می‌شوند، یک اشتباه استراتژیک بنیادین در سیستم‌های عامل‌محور است. تا زمانی که یک شکست شناسایی شود، زمینه‌های حیاتی — مانند اینکه کدام مدل پاسخ داده، موتور سیاست‌گذاری چه چیزی را ارزیابی کرده یا مبلغ دقیق پیشنهاد قیمت چقدر بوده — معمولاً از حافظه کنسول پاک شده و به بیرون رانده شده‌اند. ابزارسازی تمام بخش‌ها از ابتدا، حتی موارد به‌ ظاهر خسته‌کننده مانند audit.log_action است که عیب‌یابی پس‌ینی (Post-hoc debugging) را ممکن می‌کند. اگر فقط فراخوانی‌های LLM ردیابی می‌شدند، سیستم شفافیت هزینه داشت اما «داستان حاکمیتی» خود را گم می‌کرد.

همچنین در بحث‌های اخیر، پتانسیل پروتکل MCP برای کاهش هزینه‌های تحلیل ریشه‌ای خطاها در عامل‌ها مورد بحث قرار گرفته که نشان می‌دهد استانداردسازی در سطح پروتکل می‌تواند عیب‌یابی را حتی از ردیابی دستی نیز بهینه‌تر کند.

افزودن یک traceId مشترک از روز اول، یک اقدام با بهره‌وری بالا است. اگرچه بازسازی یک فایل تنظیمات در چهار سرویس در این مورد خاص ساده بود، اما نویسنده هشدار می‌دهد که اگر این کار پس از واگرا شدن روش‌های لاگ‌گذاری در سرویس‌های مختلف انجام می‌شد، به این سادگی نبود.

برای عامل‌هایی که تصمیمات مالی خودمختار می‌گیرند، سندی که صرفاً می‌گوید «تأیید شد»، یک مهر تکراری است، نه یک ردپای حسابرسی. با میزبانی شخصی (Self-hosting) SigNoz در کنار پشته‌ی عامل، Cognivern تضمین می‌کند که داده‌های حساس تله‌متری — شامل پرامپت‌های LLM و زمینه محتویات امضاشده — هرگز از زیرساخت تحت کنترل آن‌ها خارج نشود.

اگر در حال ساخت سیستم‌هایی هستید که عملیات امضا، هزینه یا مناقصه را مدیریت می‌کنند، قانون روشن است: سیستم را پیش از آنکه به آن نیاز پیدا کنید، ابزارسازی کنید. هزینه افزودن زودهنگام آن، تنها یک فایل تنظیمات است؛ اما هزینه افزودن دیرهنگام آن، بازنویسی کامل پشته‌ی نظارت‌پذیری شماست.

برای مشاهده پیاده‌سازی کامل، می‌توانید پروژه را در گیت‌هاب در آدرس github.com/thisyearnofear/cognivern بررسی کنید، از سایت فعال در cognivern.persidian.com بازدید نمایید یا مستندات OpenTelemetry را در opentelemetry.io/docs مطالعه کنید.

گام بعدی شما

• اگر در حال ساخت عامل‌های مالی هستید، ردیابی (Tracing) را به جای لاگ‌گذاری ساده، به عنوان هسته معماری قرار دهید.
• از ابزارهای Open-source مانند SigNoz برای میزبانی داده‌های حساس تله‌متری در محیط‌های درون‌سازمانی استفاده کنید.
• هر تصمیم اتوماتیک را با یک traceId یکتا به استدلال مدل زبانی متصل کنید تا قابلیت حسابرسی (Auditability) داشته باشید.

اما پیچیدگی‌های اجرای این سیستم روی زنجیره‌های توزیع‌شده حتی عمیق‌تر است — به تحلیل ما درباره‌ی قراردادهای Daml و شبکه‌های Canton مراجعه کنید.