الانتقال إلى المحتوى الرئيسي

مسارات تدقيق الوكلاء مشكلة سجل كتابة مسبقة، لا مشكلة لوحة تحكم

مساءلة الوكيل لا يمكن إثباتها إلا عندما يُضاف كل استدعاء أداة واستخدام بيانات اعتماد وانتقال حالة قبل تنفيذه، مما يجعل السجل تبعية وقت التشغيل.

صورة قريبة لرف خوادم يظهر وحدات تخزين مكدسة وأضواء مؤشرات وكابلات في ممر مركز بيانات معتم.

فجوة المساءلة في مراقبة الوكلاء

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

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

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

دلالات الكتابة المسبقة لتشغيلات الوكلاء

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

تشغيل وكيل مطابق يضيف، بالترتيب، قبل إطلاق أي أثر جانبي:

  1. الإجراء المقصود — اسم الأداة، الوسائط المعيارية، المورد الهدف.
  2. قرار السياسة المانح للتفويض — أي قاعدة طابقت، أي أصل استدعى التشغيل، أي قيود طُبقت.
  3. بيانات الاعتماد المحلولة — أي هوية ستعمل بها الأداة، ونطاق تلك الهوية.

Close-up of a modern building facade with red steel beams in geometric patterns against a blue sky

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

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

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

ما يجب أن يحتويه السجل

مخطط أدنى لإدخال إضافة واحد:

{
  "seq": 41822,
  "run_id": "run_7f3a...",
  "parent_step": 41819,
  "ts_monotonic": 918273645,
  "kind": "tool.intent",
  "tool": "http.fetch",
  "args_hash": "sha256:9c1f...",
  "policy_rule": "net.egress.allowlist.v4",
  "credential": "svc-fetch-readonly@proj-9",
  "context_refs": ["doc_31a", "doc_88b"]
}

عدة حقول تحمل وزنًا غير متناسب.

تجزئة الوسائط، لا الوسائط. التجزئة تبقي الأسرار خارج السجل مع ربط الإدخال بالمدخل الدقيق. حيث يجب أن تكون الوسائط قابلة للاستعادة لإعادClose-up of stacked rusty industrial pipes showing corrosion and texture خاصة به.

Circuit board macro

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

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

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

العواقب التشغيلية

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

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

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

الموقف

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

مشاركةXLinkedInرابط دائم5 دقيقة قراءة

قراءات ذات صلة

الأسئلة التي يجيب عنها هذا

Why can't existing observability dashboards serve as an audit trail?

Dashboards sample, aggregate and downsample telemetry, so they cannot reconstruct the exact ordered sequence of decisions that preceded an incident. They are also typically written by the same process they describe, which means a compromised agent can suppress or rewrite its own entries. Audit requires an append-only record written before execution by a separate process.

What does write-ahead logging change about agent runtime behaviour?

The log becomes a runtime dependency. The intended action, the authorising policy decision and the resolved credential are appended durably before any side effect fires. If the log writer is unavailable, the action does not proceed. On crash or kill, replay of the recorded trajectory decides whether the action is retried, rolled back or quarantined.

What is the minimum content of an agent audit entry?

Tool name, argument hash, the policy rule that matched, the credential identity the tool will act as, and the parent step that requested the action. Retrieved context should be referenced by identifier and content hash so a poisoned document can be traced to every run that consumed it. Ordering should come from orchestrator-assigned monotonic sequence numbers rather than per-worker wall-clock timestamps.

What are the main costs of adopting write-ahead auditing for agents?

Write amplification and retention become first-class budget lines alongside inference, and a log outage becomes a capability outage because actions are blocked until the append is acknowledged. Log schemas also need explicit versioning from the start, since incident review often happens months after the code changed.