ما الذي يرسله وكيل البرمجة فعلياً؟

ما الذي تغطيه فعلياً بيانات القياس عن بُعد لوكيل البرمجة

تتكون بيانات القياس عن بُعد لوكيل البرمجة من أربعة تدفقات منفصلة تشترك في المصطلح نفسه، ولكل تدفق منها وسيلة تحكم خاصة به. تنقل استدلالات النموذج مطالباتك البرمجية وتعليماتك البرمجية إلى الجهة التي تقدم النموذج، ولا يوجد إعداد يعطّل ذلك. تُرسل تحليلات المنتج وتقارير الأعطال إلى المورّد، وغالباً إلى شركة تسجيل يقدّم لها المورّد المقابل المالي. أما الاحتفاظ بالبيانات لأغراض التدريب فهو مسألة تعاقدية وليست مسألة شبكية. والتدفق الرابع هو الذي يغفل عنه الناس: كل تكامل تضيفه يمكن أن يفتح اتصالاً بمضيف لم تختره أنت.

تتغير قائمة الإعدادات الافتراضية الحالية للمورّد بسرعة أكبر من أي جزء آخر في هذا الموضوع. فقد يغيّر إصدار أحد الإعدادات الافتراضية، وقد تضيف ميزة جديدة وجهة لا يغطيها أي مفتاح تبديل موجود. لذلك تتمثل المهارة الدائمة في إجراء تدقيق يمكنك تكراره مع أي وكيل: اقرأ ما يوثقه المورّد، وتحقق من الإعداد الذي طُبّق فعلياً على هذا الجهاز، وراقب العملية من الجهاز نفسه، ثم اختر عناصر التحكم التي تقبل تكلفتها. كل أمر أدناه تشغّله على جهازك أنت، وعلى حركة الشبكة الخاصة بك أنت.

الفئات الأربع، ولماذا تحتاج إلى ضوابط مختلفة

حركة مرور الاستدلال إلى النموذج حتمية. يرسل الوكيل مطالبتك، والملفات التي قرأها، ومخرجات الأوامر التي شغّلها، والنص الذي أنشأه بنفسه إلى نقطة نهاية النموذج. هذا جزء من عمل المنتج. القرار الحقيقي الوحيد هو تحديد الجهة التي تستقبلها: API يديره طرف آخر، أم نموذج تشغّله بنفسك. ينقل حساب سحابي تابع للشركة، مثل Bedrock أو Vertex أو Foundry، الجهة المستقبلة، لكنه لا يلغي تدفق البيانات. لا يقلل أي شيء في بقية هذا المقال من حركة مرور الاستدلال، لذلك افصلها ذهنياً عن الفئات الثلاث الأخرى.

تحليلات المنتج والإبلاغ عن الأعطال تدفق مختلف إلى مضيفين مختلفين. تذهب عدادات الاستخدام، وأرقام زمن الاستجابة، وعمليات البحث عن feature flags، وstack traces عادةً إلى أسماء مضيفين لا علاقة لها بواجهة model API، وغالباً إلى أداة خارجية لتتبع الأخطاء. يوثّق المورّدون هذه البيانات عادةً باسم "metrics" و"error reports"، ويوفّرون عادةً متغير بيئة واحداً لكل فئة. حجم هذه البيانات ضئيل، لذلك لن تكشفه عدادات البايتات. أنت تبحث عن أسماء المضيفين، لا عن عرض النطاق الترددي.

الاحتفاظ بالبيانات والتدريب سياسة، وليسا حزم بيانات. يحدّد البنود المرتبطة بخطتك ما إذا كان المورّد يحتفظ بمطالباتك، والمدة التي يحتفظ بها، وما إذا كان يدرّب نموذجاً مستقبلياً عليها. تختلف الخطط المخصصة للمستهلكين عادةً عن الخطط التجارية، ويكون ترتيب الاحتفاظ الصفري عادةً اتفاقية منفصلة. لا يمكنك التحقق من أي من ذلك باستخدام tcpdump، لأن الحزمة تبدو متطابقة في الحالتين. اقرأ البنود، وإذا كان الأمر مهماً لجهة عملك، فاطلب توثيقه كتابياً.

تضيف عمليات التكامل قفزة إضافية دون وضوح. خادم MCP (بروتوكول سياق النموذج)، أو سوق الإضافات، أو فحص التحديث التلقائي، أو أداة بحث الويب، أو فحص أمني يحل عنوان URL قبل جلبه: كل واحد منها يرسل طلباً إلى مضيف ليس نقطة نهاية النموذج. هنا تحدث المفاجآت، لأن harness قد يوجّه عملاً افترضت أنه محلي عبر خدمة خاصة به، وقد يبدأ إصدار جديد بفعل ذلك من دون تغيير أي سطر في إعداداتك. تعامل مع كل أداة تضيفها باعتبارها وجهة جديدة إلى أن تراقبها عبر الشبكة.

الخطوة 1: ماذا توثّق الجهة المورّدة؟

افتح مرجع الإعدادات وصفحة استخدام البيانات الخاصة بالوكيل، واقرأهما مع قائمة كلمات أمامك: المقاييس، والتحليلات، والإبلاغ عن الأخطاء، والتعطّل، والملاحظات، والاستبيان، والتحقق من وجود تحديثات، والتحقق من الأمان، والسوق. تكون كل واحدة من هذه الكلمات عادةً مفتاح تبديل منفصلاً. دوّن أسماء المتغيرات بدقة، لأن الخطوة 2 تبحث عنها باستخدام grep.

ستضللك إحدى الكلمات. في عدة وكلاء، تعني كلمة "telemetry" في الوثائق تصديراً عبر OpenTelemetry تُعدّه لإرسال المقاييس إلى مجمّع تشغّله أنت، وهذا عكس إرسال البيانات إلى الجهة المورّدة. يُعد Claude Code أحد هذه الوكلاء: يؤدي ضبط CLAUDE_CODE_ENABLE_TELEMETRY=1 إلى بدء تصدير إلى نقطة النهاية التي تحددها في OTEL_EXPORTER_OTLP_ENDPOINT، ولا علاقة لذلك بالتحليلات الخاصة بالجهة المورّدة، التي لها إعداد مختلف لإلغاء الاشتراك. حدّد اتجاه تدفق البيانات قبل ضبط أي شيء.

توقّع وجود مفتاح تبديل رئيسي، وتوقّع وجود ثغرات في نطاقه. اعتباراً من August 2026، يعطّل CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC في Claude Code المقاييس وتقارير الأخطاء وأمر الملاحظات واستبيانات الجلسات معاً، وتذكر الوثائق نفسها أنه لا يشمل فحص أمان النطاق في WebFetch، الذي يرسل اسم المضيف الذي توشك على جلبه إلى API الخاص بالجهة المورّدة وله إعداد منفصل خاص به. هذه ليست ملاحظة عن منتج واحد. هذه هي طبيعة المشكلة في كل مكان: يغطي مفتاح التبديل الرئيسي الفئات الموجودة عند كتابة الوثائق.

توقّع أيضاً أن يترتب على إلغاء الاشتراك أثر جانبي. تذكر الوثائق نفسها أن تعطيل القياس عن بُعد يعطّل كذلك تقييم أعلام الميزات التي تعتمد عليها بعض الميزات، ولذلك قد يؤدي تبديل المفتاح لأسباب تتعلق بالخصوصية إلى تعطيل ميزة تستخدمها، من دون ظهور رسالة خطأ تربط الأمرين. اقرأ الجملة الموجودة بجوار المفتاح، ولا تكتفِ باسم المفتاح.

الخطوة 2: ما الإعداد الذي طُبِّق فعلياً؟

الإعداد الذي كتبته ليس بالضرورة الإعداد الذي طُبِّق. تدمج الوكلاء الإعدادات من عدة ملفات، وقد يكون أحدها داخل المستودع الذي نسخته للتو من شخص آخر. ابدأ ببيئة shell الخاصة بك.

env | grep -Ei 'telemetry|otel|analytics|error_report|do_not_track|proxy'

ثم اطبع كل ملف إعدادات تقرؤه الأداة، بالترتيب الوارد في الوثائق. بالنسبة إلى Claude Code، اعتباراً من August 2026، يشمل ذلك ملف المستخدم، وملفي المشروع، ودليل سياسة مُدار على Linux.

for f in ~/.claude/settings.json .claude/settings.json .claude/settings.local.json; do
  echo "== $f"; [ -f "$f" ] && cat "$f"
done
ls -l /etc/claude-code/ 2>/dev/null

ملف المشروع الذي وصل مع git clone هو إعداد كتبه شخص آخر، ويمكنه إعادة تفعيل ما عطّله ملف المستخدم لديك. إذا كان الوكيل يوفّر أمراً لعرض الحالة ويسرد مصادر الإعدادات التي حمّلها، فهذا أسرع مصدر موثوق للحالة الفعلية: يطبع Claude Code مصادر الإعدادات المحمّلة في /status.

يتحقق الاختبار الأقوى من العملية قيد التشغيل بدلاً من أي ملف. امنح الوكيل أولاً حساب مستخدم Linux خاصاً به، فهذا يجعل كل أمر في هذا المنشور أقصر، ثم اقرأ البيئة التي بدأت بها العملية.

pgrep -u agent -a node
sudo tr '\0' '\n' < /proc/$(pgrep -u agent -n node)/environ | grep -Ei 'telemetry|proxy|otel'

يعرض /proc/<pid>/environ المتغيرات التي كانت موجودة لدى العملية وقت exec، ولذلك يكشف حالة عدم وصول عملية .bashrc export إلى خدمة بدأها systemd. إذا كان متغير عيّنته مفقوداً هنا، فلم يكن مفعّلاً قط، مهما قالت ملفات dotfiles لديك.

الخطوة 3: ما المضيفات التي يتصل بها؟

ابدأ بالمقابس المفتوحة، مع تصفيتها وفقاً للحساب الذي يعمل به الوكيل.

sudo ss -tnpe state established

يضيف -e حقلاً uid: إلى كل سطر، لذلك يمكنك فصل اتصالات الوكيل عن اتصالات متصفحك من دون قراءة أسماء العمليات. دوّن العناوين البعيدة، ثم احصل على الأسماء المرتبطة بها. أفضل مصدر للأسماء هو مصافحة TLS (أمان طبقة النقل)، لأن كل اتصال جديد يبدأ برسالة ClientHello تتضمن حقلاً SNI (إشارة اسم الخادم)، وهو اسم المضيف الذي طلبه العميل.

sudo apt install -y tshark
sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' \
  -T fields -e ip.dst -e tls.handshake.extensions_server_name

تحصل على سطر واحد لكل اتصال جديد، وهذا يمثل قائمة الجرد المطلوبة تماماً: واجهة برمجة نموذج الذكاء الاصطناعي، وخادم التحديثات، ومضيف التحليلات، ومتتبع الأخطاء، وأي شيء أضافه أحد التكاملات. يعني فراغ عمود الاسم أن العميل استخدم ECH (ClientHello مشفّراً)، ولذلك لا يظهر اسم المضيف على الشبكة، وعليك استخدام عنوان IP الوجهة، أو إجراء بحث عكسي، أو استخدام الوكيل في الخطوة 4.

يُعد عرض DNS (نظام أسماء النطاقات) عملية تحقق مفيدة، لأنه يعرض الأسماء التي بحث عنها الوكيل حتى للاتصالات التي لم يكتمل إنشاؤها.

sudo tcpdump -ni any -l 'udp port 53'

ينتهي كل سطر استعلام بنوع السجل والاسم، بالتنسيق A? host.example.net. (39). التقط البيانات على any بدلاً من الواجهة الخارجية، لأن التطبيق مع systemd-resolved يتصل بمستمع stub محلي على 127.0.0.53، ولا يتصل بالخارج إلا هذا الـstub. إذا لم ترَ أي حركة DNS على الإطلاق بينما يعمل الوكيل بوضوح، فإن بيئة التشغيل هذه تنفّذ DNS over HTTPS بنفسها، ولن تحصل على الأسماء إلا في الخطوة 4.

نفّذ الالتقاط أثناء إنجاز الوكيل لعمل فعلي. ابدأ جلسة، واطلب منه قراءة ملف، واطلب منه تشغيل أمر، واجعله يفشل في خطوة ما. لا تظهر حركة الشبكة التي تحدث مرة واحدة عند بدء التشغيل، أو التي تحدث فقط عند إلقاء استثناء، في التقاط أثناء الخمول. والتقاط حركة أثناء الخمول هو أكثر الطرق شيوعاً لوصول التدقيق إلى نتيجة خاطئة تبدو مقنعة.

الخطوة 4: ماذا تحتوي الطلبات؟

توضح أسماء المضيفين الجهة التي تتصل بها. لمعرفة محتوى الطلبات، ضع proxy تتحكم فيه أمام agent، واجعل runtime يثق بجهة إصدار الشهادات (CA) الخاصة به. الأداة المعتادة لذلك هي mitmproxy. يوصي المشروع باستخدام الملفات التنفيذية المستقلة من mitmproxy.org، ويوثّق uv tool install mitmproxy باعتباره مسار استخدام حزمة Python.

mitmdump -w /tmp/agent-flows.mitm

ينشئ التشغيل الأول CA في ~/.mitmproxy/، حيث يكون mitmproxy-ca-cert.pem هو الشهادة وحدها. في shell الذي ستشغّل منه agent، وجّه client إلى proxy وإلى تلك الشهادة.

export HTTP_PROXY=http://127.0.0.1:8080
export HTTPS_PROXY=http://127.0.0.1:8080
export NODE_EXTRA_CA_CERTS="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export REQUESTS_CA_BUNDLE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export SSL_CERT_FILE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"

تعمل كثير من واجهات CLI الخاصة بـagent كبرامج Node، ويقرأ Node القيمة NODE_EXTRA_CA_CERTS عند بدء العملية. لذلك صدّرها قبل تشغيل agent، وليس في terminal آخر بعد ذلك. تقرأ عملاء Python القيمة REQUESTS_CA_BUNDLE أو SSL_CERT_FILE، بينما يقرأ ملف Go التنفيذي الذي يستخدم المكتبة القياسية القيمة SSL_CERT_FILE على Linux. أثبت أن المسار يعمل باستخدام curl قبل أن تلقي اللوم على agent.

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

يطبع proxy العامل 200، ويظهر الطلب في مخرجات mitmdump. تؤدي CA غير الموثوقة إلى curl: (60) SSL certificate problem: self-signed certificate in certificate chain، ويظهر المكافئ من agent يعمل على Node في خطأ يحمل الرمز SELF_SIGNED_CERT_IN_CHAIN. اقرأ التدفقات المحفوظة بعد ذلك باستخدام عارض وحدة التحكم، حيث يمكنك فتح طلب واحد وقراءة رؤوسه ومتنِه.

mitmproxy -r /tmp/agent-flows.mitm

توجد أربع نتائج تستحق التمييز. قد ترى الطلبات، وعندها اقرأها واتخذ قرارك. وقد يرفض agent بدء التشغيل بسبب خطأ في الشهادة. هذه مشكلة ثقة في ذلك runtime، وليست دليلاً على شيء يتعلق بالمورّد. وقد ترى واجهة API الخاصة بالنموذج فقط. يعني ذلك أن الفئات الأخرى معطّلة، أو أنها تعمل استجابةً لحدث لم تُشغّله. وقد لا ترى شيئاً على الإطلاق بينما يعمل agent بوضوح. يعني ذلك أن client يتجاهل متغيرات بيئة proxy أو يثبّت شهاداته، ولا يمكن الوثوق بأي إعداد للتطبيق ليخبرك بالحقيقة. هذه هي النتيجة الأهم، وهي تعيدك إلى الخطوة 3، لأن التقاط الحزم لا يمكن إقناعه بعدم رؤية اتصال.

الضوابط، من الأضعف إلى الأقوى

إعدادات إلغاء الاشتراك. هي الأقل تكلفة والأضعف، لأنها تعتمد على التزام المورّد بها، ولأنها تغطي فئة موجودة مسبقاً. اضبطها في موضع يبقى بعد إعادة التشغيل وفتح طرفية جديدة، مثل ملف إعدادات المستخدم أو ملف تعريف الصدفة. أضف DO_NOT_TRACK=1 أثناء ذلك أيضاً؛ فهو اصطلاح تحترمه أدوات كثيرة لسطر الأوامر، بما في ذلك بعض الوكلاء، ولا يكلّف شيئاً. ثم أعد تشغيل الخطوة 3 بعد التحديث التالي، لأن التغطية تتغير في تلك اللحظة.

تقييد الاتصالات الصادرة. هنا تتوقف عن طلب الالتزام وتبدأ بفرضه. شغّل الوكيل باستخدام مستخدم مستقل، ثم اسمح لذلك المستخدم بالاتصال بـloopback وDNS، وأسقط بقية الاتصالات. يضيف هذا جدولاً خاصاً به، لذلك لا يغيّر قواعد الجدار الناري الموجودة.

table inet agentegress {
  chain output {
    type filter hook output priority filter; policy accept;
    meta skuid "agent" ip daddr 127.0.0.0/8 accept
    meta skuid "agent" udp dport 53 accept
    meta skuid "agent" counter log prefix "agent-egress-drop " drop
  }
}

طبّقه باستخدام sudo nft -f /etc/nftables.d/agent.nft، وراقب العداد باستخدام sudo nft list table inet agentegress، واقرأ الاتصالات المسقطة باستخدام sudo journalctl -k -g agent-egress-drop. ارتفاع عداد الإسقاط مع ظهور اسم مضيف لم تتوقعه هو الهدف الأساسي من هذا الإجراء. هناك حدّان مهمّان. يطابق meta skuid المستخدم الذي يملك الـsocket، لذلك يظل فعالاً فقط ما دام ذلك الحساب لا يستطيع التحول إلى مستخدم آخر: إن كان لدى الوكيل sudo دون كلمة مرور، تتحول هذه القاعدة إلى اقتراح فقط. كما أن ترك UDP 53 مفتوحاً لأي خادم يترك قناة يمكنها إخراج البيانات ضمن أسماء الاستعلامات، لذا أغلقها أيضاً إذا كان نموذج التهديد لديك يتطلب ذلك، وذلك بتوجيه محلّل أسماء الوكيل إلى مضيف تديره أنت. يجب وضع قوائم السماح لأسماء المضيفين في proxy بدلاً من nftables، لأن نقاط نهاية API تعمل خلف شبكات توصيل المحتوى التي تتغير عناوين IP الخاصة بها دون إشعارك. تكلفة هذا الضبط هي الأعطال والصيانة: تفشل عمليات تثبيت الحزم، وgit عبر SSH، وفحص التحديث الخاص بالوكيل إلى أن تسمح بها، وتصبح أنت مسؤولاً عن صيانة هذه القائمة. إذا كنت تهيئ ذلك على خادم بدلاً من حاسوب محمول، فإن تخطيط الحساب والجدار الناري نفسه يشكل أساس تشغيل Claude Code بأمان على VPS.

جهاز مؤقت. امنح الوكيل جهازاً افتراضياً (VM) لا يحتوي على أي بيانات اعتماد تهمك، ودمّره في نهاية المهمة. لا يقلل ذلك مما يرسله الوكيل، بل يقلل ما يمكن للوكيل الوصول إليه لإرساله، وهذا هو الخطر الذي يهمك عادةً. ادمجه مع قواعد الاتصالات الصادرة أعلاه، لأن جهاز VM جديداً مع وصول غير مقيّد إلى الإنترنت يظل قادراً على الوصول إلى كل مضيف ضمن نطاق الالتقاط لديك. يشرح تشغيل وكلاء البرمجة في VM مؤقت الطريقة والحالة التي يجب إعادة بنائها في كل مرة، بينما يناقش تشغيل وكيل برمجة على VPS مسألة تحديد الموارد.

استضافة النموذج ذاتياً. هذا هو الضبط الوحيد الذي يزيل تدفق الاستدلال، لأن الموجّه لا يغادر أجهزتك. التكلفة حقيقية: لا يمكنك استضافة نموذج مغلق ذاتياً، لذا يعني ذلك اختيار أوزان مفتوحة وقبول فجوة في القدرات عند تنفيذ المهام الصعبة، إضافة إلى توفير العتاد اللازم لتشغيلها. يشرح ما إذا كان بإمكانك استضافة Claude ذاتياً هذه المفاضلة، بينما يوضح الفروق بين Claude Code وCursor وCodex وCopilot اختلافات القدرات بين الوكلاء الرئيسيين.

لا يغيّر أي من هذه الضوابط الأربعة ما يُسمح للوكيل بقراءته من القرص، وتحمل حركة الاستدلال كل ما يقرأه. إذا كان ملف .env موجوداً في دليل العمل، فإنه يصل إلى النموذج فور بحث الوكيل عن اسم متغير باستخدام grep. منع وصول الوكيل إلى هذه المواد مهمة منفصلة، ويغطيها إبعاد الأسرار عن سياق وكيل الذكاء الاصطناعي.

ما يجب فحصه بعد كل تحديث

1. قارن صفحات إعدادات المورّد واستخدام البيانات بما سجّلته في المرة السابقة، وابحث عن مفاتيح تبديل جديدة وخدمات جديدة مسمّاة.
2. أعد قراءة بيئة العملية من /proc/<pid>/environ للتأكد من أن خيارات إلغاء الاشتراك ما زالت مطبّقة على العملية قيد التشغيل.
3. اطبع ملفات إعدادات المشروع مرة أخرى، لأن git pull قد يجلب ملف إعدادات غيّره أحد الزملاء.
4. شغّل التقاط SNI خلال جلسة عمل فعلية كاملة، ثم قارن قائمة أسماء المضيفين بالقائمة السابقة.
5. افحص عدّاد الحزم التي أسقطها الجدار الناري، لأن وجهة جديدة تظهر فيه عادةً قبل أن تلاحظها في أي مكان آخر.

يستغرق ذلك نحو عشر دقائق، وهو الجزء الوحيد من العملية الذي لا تصبح معلوماته قديمة. الإعداد الافتراضي الذي تحققت منه في August 2026 هو حقيقة تخص August 2026. أما الالتقاط فهو حقيقة تخص اليوم.

FAQ

هل يمكنني منع وكيل البرمجة من إرسال التعليمات البرمجية الخاصة بي إلى النموذج؟

لا. وأي إعداد يدّعي ذلك يصف أمراً آخر. إرسال المطالبة، والملفات التي قرأها الوكيل، ومخرجات الأوامر التي شغّلها إلى نقطة نهاية النموذج هو آلية الاستدلال. لذلك، المتغير الوحيد هو الجهة التي تستقبلها. يمكنك تغيير الجهة المستقبلة بتوجيه الوكيل إلى حساب سحابي تابع لشركتك أو إلى نموذج تستضيفه بنفسك. ويمكنك تقليل ما يرسله بتقييد الملفات التي يُسمح له بقراءتها. لا يؤثر إيقاف التحليلات والإبلاغ عن الأخطاء في هذا التدفق إطلاقاً.

كيف أعرف المضيفات التي يتصل بها وكيل البرمجة؟

شغّل الوكيل باستخدام مستخدم Linux مستقل، ثم التقط رسالة TLS ClientHello لكل اتصال جديد أثناء استخدامه: sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' -T fields -e ip.dst -e tls.handshake.extensions_server_name. يظهر سطر واحد لكل اتصال، ويتضمن عنوان الوجهة واسم المضيف المطلوب. قارن الأسماء باستخدام sudo tcpdump -ni any 'udp port 53'، والتقط الحزم على any لأن stub المحلي لمحلّل الأسماء على 127.0.0.53 يعالج الاستعلام أولاً. أجرِ الالتقاط أثناء تنفيذ الوكيل لعمل فعلي، لأن اختبارات الاتصال عند بدء التشغيل وتقارير الأعطال لا تظهر في الالتقاط أثناء الخمول.

لا يعرض الـproxy لدي أي حركة مرور أثناء عمل الوكيل. ما الخطأ؟

إما أن العميل يتجاهل HTTP_PROXY وHTTPS_PROXY، أو أنه يثبّت شهاداته ويرفض CA الخاص بك. اختبر المسار أولاً باستخدام curl: إذا وصل curl إلى الإنترنت عبر الـproxy ولم يظهر الوكيل في قائمة التدفقات، فهذا يعني أن الوكيل لا يستخدم متغيرات بيئة الـproxy. تحتاج بعض بيئات التشغيل إلى توفير CA بطريقة محددة. ويقرأ Node، على وجه الخصوص، NODE_EXTRA_CA_CERTS عند بدء العملية فقط، لذلك لن يفيد تصديره بعد تشغيل الوكيل. عندما لا يستطيع الـproxy رؤية حركة المرور، استخدم التقاط الحزم بديلاً، إذ لا يمكن لأي إعداد للتطبيق تجاوز ذلك.

هل يؤدي إيقاف القياس عن بُعد إلى منع استخدام التعليمات البرمجية الخاصة بي في التدريب؟

لا. التحليلات والإبلاغ عن الأعطال تدفقان مختلفان عن الاستدلال. لذلك يؤدي تعطيلهما إلى إزالة عدادات الاستخدام وتتبعات المكدس، بينما تظل كل مطالبة مرسلة إلى النموذج كما هي تماماً. تحدد شروط خطتك ما إذا كانت هذه المطالبات ستُحتفظ بها، وما إذا كانت ستُستخدم لتدريب نموذج مستقبلي. وتختلف الخطط الاستهلاكية والخطط التجارية عادةً في هذا الجانب. هذه مسألة تعاقدية يجب قراءتها، وليست حزمة ينبغي التقاطها. لذلك راجع صفحة استخدام البيانات الخاصة بخطتك، وعندما يكون الأمر مهماً، أبرم اتفاقية تجارية أو اتفاقية احتفاظ صفري بالبيانات قبل الجلسة الأولى.