یک مهندس نرمافزار ارشد در شرکت Ramp توانست تنها با ایجاد یک حلقه ابزارگذاری، مصرف توکنهای خود را ۲۰٪ کاهش و سرعت جلسات را ۳۰٪ افزایش دهد. در ۱۴ اکتبر ۲۰۲۶، شرکت Anthropic قابلیت خروجی ردپای OpenTelemetry را برای Claude Platform در حالت بتای عمومی عرضه کرد تا توسعهدهندگان راهی استاندارد برای نظارت بر رفتار واقعی عاملهای خود در محیط عملیاتی داشته باشند.
برای اکثر کسبوکارها، عاملهای هوش مصنوعی (AI Agents) — شبیه به کارمندی هستند که دستورات پیچیده را میگیرد اما کسی نمیداند در پشت صحنه دقیقاً چه میکند — همچنان یک «جعبه سیاه» هستند. در این وضعیت، تشخیص اینکه چرا یک گردشکار چندمرحلهای شکست خورده یا تأخیر در کدام نقطه رخ داده، بسیار دشوار است. همانطور که در تحلیل قبلی ما دربارهی مدیریت بازگشتهای تخریبی در Claude Code اشاره کردیم، تمرکز اکنون از کنترل نسخههای محلی به نظارت در سطح سازمانی تغییر یافته است. این بهروزرسانی به تیمها اجازه میدهد با هر نوبتِ اجرای عامل، مانند یک میکروسرویس در پشته نرمافزاری خود برخورد کنند. این رویکرد در واقع تکامل همان استراتژی آنتروپیک برای تبدیل دستیار چت به یک موتور ارکستراسیون است تا مدیریت عاملها از حالت ساده به ساختارهای پیچیده تغییر یابد.
زمینه و یکپارچهسازی
طبق گزارش unite.ai، این سامانه هر نوبتِ اجرای عامل، فراخوانی مدل و استفاده از ابزار را به عنوان یک ردپای استاندارد OpenTelemetry صادر میکند. این ردپاها حاوی دادههای حیاتی شامل تأخیر (Latency)، تعداد توکنها و شناسهها هستند. از آنجا که ردپاهای کلود از کنوانسیونهای معنایی GenAI در OpenTelemetry پیروی میکنند، دادههای حاصل از کلود و سایر ارائهدهندگان میتواند در قالب ابزارها و داشبوردهای یکسانی پردازش و مشاهده شود.
توسعهدهندگان میتوانند این ردپاها به هر ابزار نظارتی که یک نقطه انتهایی استاندارد OTLP را میپذیرد ارسال کنند. این قابلیت برای کسانی که پیش از این ردپاهای Claude Code یا Cowork را به ابزارهای نظارتی ارسال میکردند بسیار کاربردی است، زیرا اکنون عاملهای ساختهشده در پلتفرم کلود نیز در همان مکان و محیط متمرکز ظاهر میشوند. این یکپارچگی در واقع مکمل سازوکار هماهنگکننده در Claude Code است که گذار از مدیریت پوشهای به مدیریت عاملهای موازی را تسهیل میکند.
جزئیات فنی
بر اساس مستندات آنتروپیک، یک «ردپا» (Trace) به عنوان رکورد کامل یک درخواست در کل سیستم تعریف میشود، در حالی که یک «بازه» (Span) نشاندهنده یک گام واحد است؛ مانند استفاده از یک ابزار یا یک درخواست مدل. در مورد عاملهای مدیریتشده (Managed Agents)، هر جلسه برای هر درخواست API یک بازه تولید میکند و برای هر نوبتِ اجرای عامل (Turn)، یک بازه اختصاصی ایجاد میشود. هر نوبتِ اجرا نیز به نوبه خود شامل بازههایی برای هر درخواست مدل، ابزارهای اجرا شده از طریق API و ارزیابی نتایج است.
توسعهدهندگان میتوانند بین دو مسیر اصلی برای راهاندازی انتخاب کنند:
- ردیابی SDK: این روش مستقیماً در کد و از طریق نصب SDK و ثبت یک ارائهدهنده ردیاب (Tracer Provider) پیکربندی میشود. این مسیر نیازی به مجوزهای خاص ندارد و ابزارهای کلاینت که توسط Tool Runner اجرا میشوند، ابزارهای موجود در محیط Sandbox خودمیزبان و درخواستهای API مانند آپلود فایلها را ثبت میکند.
- ردیابی API: این روش از طریق افزودن یک مقصد (Destination) در Claude Console پیکربندی میشود و نیازمند دسترسیهای مدیر (Admin) است. این حالت هر اجرای مدل در یک درخواست، نوبتهای عاملهای مدیریتشده و ابزارهای سروری که توسط API اجرا میشوند را ثبت میکند.
در صورتی که هر دو روش فعال باشند، سیستم آنها را در یک ردپای واحد ادغام میکند، هرچند درخواستهایی که از طریق AWS ارسال میشوند، بازههای API را بهطور مجزا نگه میدارند. برای حسابداری توکنها، به کاربران توصیه شده است که برای هر درخواست، مجموع بازهها را تنها از یک منبع محاسبه کنند (در صورت وجود هر دو، از بازههای API استفاده کنند) تا از شمارش دوبرابر در اثر تلاشهای مجدد ارسال داده (Delivery Retries) جلوگیری شود.
حالتهای محتوا و انطباق
برای مدیریت حریم خصوصی دادهها، آنتروپیک «حالتهای محتوا» (Content Modes) را برای هر مقصد و کلاینت SDK معرفی کرده است:
- فقط متادیتا (پیشفرض): شناسهها، زمانبندی، وضعیت، تعداد توکنها و متون منتخب کاربر، مانند نام سرورهای MCP و توصیفات عامل/ابزار را ثبت میکند.
- محتوای کامل: شامل پرامپتهای واقعی مدل و پاسخهای دریافتی است.
برای جلوگیری از کرش کردن پروکسیهای نظارتی، Anthropic حجم بازههای محتوای کامل را به ۰.۷۵ مگابایت محدود کرده است. این مقدار برای یک پنجره متنی (Context Window) — شبیه به میز کاری که فقط تعداد محدودی کاغذ روی آن جا میشود — ۲۰۰ هزار توکنی انگلیسی کافی است، اما برای پنجره یک میلیون توکنی، سیستم به حدود ۴ مگابایت نیاز دارد. در صورت عبور از این حد، API ویژگی anthropic.content.truncated را روی true تنظیم کرده و ابتدا پرامپت سیستمی و قدیمیترین پیامها را حذف میکند؛ همچنین تصاویر و اسناد تنها به نوع (Type) خود کاهش مییابند.
در زمینه انطباق با قوانین، سازمانهایی که تحت نظارت HIPAA، FERPA یا محدودیتهای جابجایی دادههای K-12 هستند، صرفنظر از تنظیمات، روی خروجی «فقط متادیتا» در مقاصد قفل شدهاند، هرچند بازههای SDK تحت تأثیر این محدودیت نیستند. با این حال، کاربرانی که تحت سیاست «عدم ذخیره دادهها» (Zero Data Retention) هستند، همچنان میتوانند از محتوای کامل استفاده کنند، زیرا API دادهها را فقط تا لحظه تحویل در حافظه نگه میدارد. لازم به ذکر است که عاملهای مدیریتشده کلود واجد شرایط سیاست عدم ذخیره دادهها نیستند.
پذیرش در صنعت
بر اساس بررسی منابع متعدد، پیشروان صنعت از این ردپاها برای بهینهسازی زیرساختهای خود استفاده میکنند. آنتروپیک پلتفرمهای پشتیبانیشده را در سه دسته کاربردی قرار داده است:
- عیبیابی: ابزارهایی مثل Grafana Cloud، Honeycomb، Sentry و Splunk به توسعهدهندگان اجازه میدهند ببینند کدام سرویس باعث کندی یا شکست یک گام شده است.
- بهبود عملیاتی: Arize AI، Braintrust، Datadog، Langfuse، LangSmith by LangChain، New Relic و PostHog برای تبدیل ردپاهای واقعی به مجموعههای ارزیابی (Evals) استفاده میشوند.
- ردیابی مصرف: Databricks Unity Gateway به تیمهای امنیتی اجازه میدهد فعالیتهای غیرعادی را علامتگذاری کرده و مصرف توکن را به تفکیک هر تیم رصد کنند.
رومن استیلمن، همبنیانگذار و مدیر فنی Foxglove، از PostHog برای تحلیل تعاملات عاملهای رباتیک در کنار دادههای استفاده از محصول استفاده میکند. آنکوش شارما، مدیر زیرساخت در FloQast، با اتصال به Grafana Cloud، خط زمانی دقیقی از نحوه مدیریت گردشکارهای ثبت دفتر روزنامه یا تطبیق حسابها توسط عاملها برای حسابرسان فراهم کرده است. هایون لی، مدیر فنی Sterling Labs، تحلیلهای زنده بازار را با استریم کردن مستقیم ردپاها به Langfuse بدون نیاز به ابزارگذاری سفارشی ساده کرده است.
در شرکت Ramp، دیوید ترینا، مهندس نرمافزار ارشد، سیستمی به نام «Reflect» ساخت که ردپاهای Langfuse را امتیازدهی میکند تا شکستهای تکراری را بیابد. ترینا اشاره کرد که خروجی بومی OpenTelemetry مستقیماً به این حلقه بهبود تغذیه میشود و به آنها کمک کرد مصرف توکن را ۱۰ تا ۲۰٪ کاهش و سرعت جلسات را ۳۰٪ افزایش دهند.
این تغییر، سیگنالی از گذار «مهندسی پرامپت» به «مهندسی عامل» است. با تبدیل فراخوانیهای مدل به بازههای ردیابیپذیر، شرکتها میتوانند سختگیریهای سنتی عیبیابی نرمافزار را روی هوش مصنوعی غیرقطعی اعمال کنند. وقتی بهبود بر اساس دادههای سخت تلهمتری باشد و نه گزارشهای پراکنده از شکستها، حلقه ارتقا به صورت علمی پیش میرود.
برای یک صاحب کسبوکار، این یعنی عاملهای هوش مصنوعی از یک «سرمایهگذاری آزمایشی و ریسکی» به «داراییهای پیشبینیپذیر» تبدیل میشوند. وقتی دقیقاً بدانید کدام فراخوانی ابزار باعث کندی ۳۰ درصدی شده است، میتوانید با دقت جراحی، هزینه و سرعت را بهینه کنید.
توسعهدهندگان اکنون باید ارزیابی کنند که آیا پشته نظارتی فعلی آنها آماده دریافت نقاط انتهایی OTLP است تا بتوانند حسابرسی گردشکارهای عاملمحور خود را آغاز کنند.
گام بعدی شما
- بررسی کنید آیا پشته نظارتی فعلی شما (Observability Stack) از نقاط انتهایی OTLP پشتیبانی میکند یا خیر.
- برای کاهش هزینهها، ردپاهای مربوط به توکنها را تحلیل کنید تا حلقههای تکراری یا فراخوانیهای غیرضروری مدل را بیابید.
- در صورت استفاده از عاملهای پیچیده، حالت «محتوای کامل» در محیط تست فعال کنید تا نقاط شکست در استدلال مدل را شناسایی کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.




گفتگو