ایجنت‌های بدون نظارت یک شکاف تله‌متری هستند، نه یک شکاف اعتماد

یافته، به‌دقت بازگو شده

یک‌چهارم استقرارهای ایجنت بدون نظارت اجرا می‌شوند. خوانش رایج سازمانی است: تیم‌ها خیلی سریع عرضه کردند، هیچ‌کس مالک قابلیت اطمینان نبود، حاکمیت عقب ماند. این خوانش راحت است و عمدتاً غلط. وقتی یک سیستم مرز گام پایدار، شناسه همبستگی مشترک و اسکیمای span ندارد، نظارت یک مسئله انضباطی نیست — یک primitive غایب است. نمی‌توانید با داشبورد از معماری‌ای که هرگز رویدادهایی را که می‌خواهید روی آن‌ها هشدار بدهید منتشر نکرده، فرار کنید.

چرا نظارت نادیده گرفته می‌شود

فریم‌ورک‌ها لاگ منتشر می‌کنند، نه تریس. یک حلقه ایجنت معمولی خطوط خوانا برای انسان می‌نویسد: prompt ارسال شد، ابزار انتخاب شد، پاسخ تجزیه شد. خطوط لاگ ارزان تولید می‌شوند و تقریباً برای تجمیع بی‌فایده‌اند. هیچ رابطه والد-فرزندی، هیچ مدت‌زمان، هیچ فیلد وضعیت، هیچ فضای‌نام attribute وجود ندارد. پرس‌وجوی «کدام اجراها ابزار بازپرداخت را بیش از سه بار فراخوانی کردند» به یک تمرین regex روی متن بدون ساختار تبدیل می‌شود، و همین دلیل است که هیچ‌کس آن هشدار را نمی‌سازد.

داده در سیستم‌های مختلف زندگی می‌کند. فراخوانی‌های مدل نزد ارائه‌دهنده inference می‌مانند. فراخوانی‌های ابزار در لاگ‌های اپلیکیشن می‌مانند. بازیابی‌ها در vector store می‌مانند. تصمیمات سیاست در یک gateway می‌مانند. هر سیستم شناسه خودش را برای همان عملیات منطقی دارد و هیچ‌کدام توافق ندارند. بدون یک correlation ID که در مرز اجرا ساخته و از هر hop منتشر شود، بازسازی یک گام ایجنت نیازمند join کردن خروجی‌های چهار فروشنده بر اساس timestamp است — رویکردی که همان لحظه‌ای که دو فراخوانی در یک میلی‌ثانیه بیفتند شکست می‌خورد.

Instrumentation پس از عرضه اضافه می‌شود. تا زمانی که یک تیم تصمیم می‌گیرد به تریس نیاز دارد، ایجنت دو بار بازآرایی شده، ابزارها در منطق retry پیچیده شده‌اند و مرز گام در زنجیره‌ای از callbackهای async حل شده است. retrofit کردن spanها یعنی بازتعریف اینکه یک گام چیست، که یک تغییر طراحی است، نه یک تغییر observability. این کار به‌طور نامحدود به تعویق می‌افتد چون با کار ویژگی رقابت می‌کند و تا اولین حادثه جدی هیچ تأثیر قابل‌مشاهده‌ای بر کاربر ندارد.

Instrumentation به‌عنوان قرارداد زمان ساخت

جایگزین این است که observability را بخشی از رابط ایجنت بدانیم، که همانند یک امضای نوع یا مهاجرت اسکیما اعمال می‌شود.

هر گام یک span منتشر می‌کند. یک گام هر واحدی است که سیستم می‌تواند مستقلاً آن را retry، رد یا صورت‌حساب کند: یک فراخوانی مدل، یک فراخوانی ابزار، یک بازیابی، یک ارزیابی سیاست. span ورودی‌ها، خروجی‌ها، هزینه، تأخیر و تصمیم سیاستی که آن را مجاز کرده حمل می‌کند. هزینه یک متریک مشتق‌شده که بعداً از شمارش token محاسبه شود نیست؛ یک attribute است که در زمان انتشار نوشته می‌شود، چون قیمت‌گذاری تغییر می‌کند و بازمحاسبه گذشته‌نگر در یک پنجره نگهداری طولانی همان جایی است که ردپاهای حسابرسی از بین می‌روند.

Correlation IDها از مرزها منتشر می‌شوند. یک run ID یک بار ساخته می‌شود، سپس از طریق هدرهای HTTP خروجی، زمینه session پایگاه‌داده و متادیتای صف پیام رشته می‌شود. مکانیزم مشخص یک شیء زمینه است که توسط runtime تزریق و توسط هر adapter خوانده می‌شود، بنابراین ابزاری که یک API خارجی را فراخوانی می‌کند نیازی ندارد بداند که در حال ردیابی است — wrapper کلاینت HTTP هدر را ضمیمه می‌کند، درایور پایگاه‌داده یک متغیر session تنظیم می‌کند، ناشر صف فیلد را کپی می‌کند. وقتی یک سرویس پایین‌دستی همان ID را لاگ می‌کند، تریس بدون دوخت دستی سرتاسر بسته می‌شود.

نمونه‌گیری از پیش اعلام می‌شود. ردیابی با وفاداری کامل هر اجرا به‌ندرت در حجم بالا مقرون‌به‌صرفه است. قرارداد زمان ساخت سیاست نمونه‌گیری را بیان می‌کند: کدام اجراها همیشه ردیابی می‌شوند (اقدامات ردشده، اجراهای پرهزینه، N اول در هر استقرار)، کدام‌ها به‌صورت احتمالی نمونه‌گیری می‌شوند و چه چیزی حذف می‌شود. تصمیمات نمونه‌گیری در span ریشه گرفته می‌شوند تا یک اجرای نمونه‌گیری‌نشده به‌طور سازگار غایب باشد نه نیمه‌حاضر، که همان حالت شکستی است که داده تریس را غیرقابل‌اعتماد می‌کند.

یک اسکیمای حداقلی span به این شکل است:

{
  "trace_id": "run_8f2c...",
  "span_id": "step_01",
  "parent_span_id": null,
  "kind": "model.invoke",
  "started_at": "2025-01-01T10:00:00.000Z",
  "duration_ms": 812,
  "attributes": {
    "model": "...",
    "input_tokens": 1042,
    "output_tokens": 233,
    "cost_units": 0.0041,
    "policy_decision": "allow",
    "polic

مبادله واقعی است: هر adapter باید مشارکت کند و یک ابزار بدون instrumentation زنجیره را می‌شکند. کاهش این مشکل این است که runtime از اجرای ابزاری که شیء زمینه را نمی‌پذیرد امتناع کند — یک بررسی زمان کامپایل یا زمان راه‌اندازی به‌جای یک امید زمان اجرا. این محدودیت در میان تیم‌هایی که می‌خواهند ابزارها را سریع اضافه کنند محبوب نیست و بهای یک تریس است که واقعاً کامل باشد.

![Close-up of automated canning equipment in a modern brewery assembly line.](/media/automated-assembly-line-35ce252236-eb5029.jpg)

## از تریس‌ها به کنترل‌ها

تریس‌ها فقط زمانی مفیدند که به پرسش‌هایی درباره اقدامات مشخص پاسخ دهند.

**قابلیت پرس‌وجو آزمون حسابرسی است.** تریسی که نمی‌توانید آن را بر اساس نام ابزار، هش آرگومان، قاعده سیاست یا actor فیلتر کنید یک کمک اشکال‌زدایی است، نه یک ردپای حسابرسی. این یعنی اسکیما باید فیلدهایی را شامل شود که تنظیم‌کنندگان و پاسخ‌دهندگان به حادثه می‌پرسند، نه فقط فیلدهایی که فریم‌ورک به‌طور تصادفی منتشر می‌کند. اگر پرسش «هر اجرایی را نشان بده که ایجنت ابزار پرداخت را بدون یک span تأیید انسانی فراخوانی کرده» با یک پرس‌وجوی واحد قابل پاسخ نباشد، instrumentation ناقص است.

**روی ناورداهای رفتاری هشدار بدهید.** شمارش خطا ضعیف‌ترین سیگنال در یک سیستم ایجنت است، چون حالت شکست معمولاً یک فراخوانی موفق است که نباید اتفاق می‌افتاد. ناورداهای مفید ساختاری‌اند: نرخ فراخوانی ابزار در هر اجرا در برابر یک سقف اعلام‌شده، هزینه در هر اجرا در برابر یک attribute بودجه، شمارش اقدامات ردشده، نسبت بازیابی‌ها به فراخوانی‌های مدل، و ظاهر شدن یک ابزار خارج از مجموعه سیاست مجازش. این‌ها از spanها قابل محاسبه و در برابر ارتقاءهای مدل پایدارند، برخلاف آستانه‌های تأخیر که با تغییرات ارائه‌دهنده جابه‌جا می‌شوند.

**نگهداری و حذف داده‌های حساس متعلق به اسکیماست.** تصمیم‌گیری بعدی درباره اینکه کدام فیلدها حاوی داده شخصی هستند یعنی بازپردازش تریس‌های تاریخی، که پرهزینه و اغلب پس از از بین رفتن payloadهای خام غیرممکن است. در عوض، هر attribute را در زمان تعریف به‌عنوان نگهداری‌شده، هش‌شده یا حذف‌شده علامت‌گذاری کنید و بگذارید pipeline قاعده را در زمان نوشتن اعمال کند. مبادله کاهش وفاداری اشکال‌زدایی برای فیلدهای حذف‌شده است، و اسکیمایی که باید با تغییر قواعد طبقه‌بندی نسخه‌بندی شود. این هزینه کمتر از کشف این است که در جریان یک درخواست دسترسی موضوع، promptها و خروجی‌های ابزار در فضای ذخیره‌سازی یک فروشنده observability بدون سیاست سطح فیلد نشسته‌اند.

## وقتی این یک الزام زمان ساخت باشد چه تغییر می‌کند

آمار یک‌چهارم ایجنت‌ها جمعیتی را توصیف می‌کند که هرگز primitiveها را نداشته است. تیم‌هایی که یک مرز گام تعریف می‌کنند، یک run ID می‌سازند، آن را از هر adapter منتشر می‌کنند و نمونه‌گیری و نگهداری را پیش از عرضه اعلام می‌کنند، بعداً با یک تصمیم نظارتی روبه‌رو نمی‌شوند — با یک مهاجرت اسکیما روبه‌رو می‌شوند، که یک وظیفه مهندسی خوب‌فهم است. بخش ناخوشایند این است که این کار پیش از وجود هر مشکل قابل‌مشاهده‌ای برای توجیه آن انجام می‌شود و محدود می‌کند که ابزارهای جدید چقدر سریع می‌توانند اضافه شوند. این همان مبادله صادقانه است: یکپارچه‌سازی کندتر ابزار در ازای سیستمی که رفتارش قابل بازسازی، پرس‌وجو و کنترل است. جایگزین ناوگانی از ایجنت‌هاست که دقیقاً به این دلیل مورد اعتمادند که هیچ‌کس نمی‌تواند ببیند چه می‌کنند.