فرض مسئولیت
چارچوب‌های حقوقی و مقرراتی برای سیستم‌های خودمختار بر یک مقدمه ساده استوارند: وقتی آسیبی رخ می‌دهد، کسی آن عمل را انتخاب کرده است. مسئولیت با ردیابی آن انتخاب به یک principal که آن را مجاز کرده، یک deployer که آن را پیکربندی کرده، یا یک توسعه‌دهنده که آن را ساخته است، تخصیص می‌یابد. این مقدمه برای نرم‌افزار متعارف برقرار است زیرا اقدامات قطعی هستند و لاگ‌ها توسط کدی که آن‌ها را اجرا می‌کند نوشته می‌شوند. برای عامل‌های LLM برقرار نیست.
سیستم‌های عامل آنچه مدل منتشر کرده را ثبت می‌کنند، نه چرایی آن را. مسیری از tool callها و مشاهدات یک لاگ تصمیم نیست مگر اینکه هر اقدام به یک اختیار اعلام‌شده مقید باشد. بدون آن قید، انتسابی وجود ندارد و مسئولیت به طور پیش‌فرض به deployer می‌افتد صرف‌نظر از اینکه شکست از کجا نشأت گرفته است. پوشش اخیر مسئولیت عامل در استقرارهای سازمانی نقاط فشار را نشان می‌دهد [1]، در حالی که بحث‌های موازی درباره پاسخگویی سیستم‌های خودمختار شکاف بین انتظار حقوقی و واقعیت فنی را برجسته می‌کند [2].
نتیجه یک عدم تطابق است: دادگاه‌ها و تنظیم‌کنندگان زنجیره حضانت بر تصمیمات را می‌خواهند؛ چارچوب‌های عامل جریانی از tokenها و فراخوانی‌های API تولید می‌کنند که نمی‌توان آن‌ها را به یک گام مسئول بازپخش کرد.
یک سابقه قابل انتساب به چه چیزی نیاز دارد
یک سابقه قابل انتساب یک رونوشت نیست. مجموعه‌ای از ورودی‌های امضاشده و فقط-افزودنی است که هر اقدام اختیاری را که تحت آن انجام شده حمل می‌کند: کدام principal، کدام دامنه، کدام نسخه سیاست. promptها و وزن‌های مدل شواهد نیستند. آن‌ها ورودی‌های یک فرآیند تصادفی هستند. یک سابقه اقدام امضاشده شواهد است زیرا یک اقدام را به یک اعطای اختیار مقید می‌کند که می‌توان آن را مستقل از مدلی که آن را تولید کرده تأیید کرد.
یک مکانیزم مشخص را در نظر بگیرید. قبل از اینکه یک عامل یک tool را فراخوانی کند، runtime یک سابقه اقدام با فیلدهای زیر می‌سازد:
{
"action_id": "act_01H...",
"principal": "user:[email protected]",
"delegation_chain": ["grant_01", "grant_02"],
"scope": "payments:read",
"policy_version": "policy_2025_04_01",
"tool": "ledger.read",
"args_hash": "sha256:...",
"timestamp": "2025-04-01T12:00:00Z",
"signature": "ed25519:..."
}
runtime سابقه را با کلیدی که توسط میزبان عامل کنترل می‌شود امضا می‌کند. سابقه به یک لاگ دستکاری‌ناپذیر افزوده می‌شود، برای مثال یک زنجیره هش که در آن هر ورودی خلاصه ورودی قبلی را شامل می‌شود. تأیید به مدل نیاز ندارد. به کلید عمومی و لاگ نیاز دارد.
این یک انتخاب طراحی با بده‌بستان‌هاست. امضای هر اقدام latency و سربار مدیریت کلید را اضافه می‌کند. همچنین runtime را مجبور می‌کند که principal و دامنه را در زمان اقدام بداند، که در سیستم‌های چندعاملی که زمینه به اشتراک گذاشته می‌شود همیشه ساده نیست. جایگزین، ثبت پس از واقعه، سوابقی تولید می‌کند که نمی‌توانند از بازبینی خصمانه جان سالم به در ببرند زیرا می‌توانند توسط همان فرآیندی که آن‌ها را تولید کرده تغییر یابند.
زنجیره از principal تا اقدام
در سیستم‌های چندعاملی، تفویض اغلب ضمنی است. یک عامل والد یک زیرعامل ایجاد می‌کند، یک پنجره زمینه را منتقل می‌کند، و زیرعامل با استفاده از اعتبارنامه‌های ارث‌بری‌شده از والد، toolها را فراخوانی می‌کند. هیچ سابقه تحویلی وجود ندارد. هیچ استنادی به اعطای والد وجود ندارد. زیرعامل بر اساس اختیار والد عمل می‌کند بدون اینکه آن را اعلام کند.
این حالت شکست اصلی برای مسئولیت است. وقتی یک زیرعامل یک اقدام مضر انجام می‌دهد، سابقه یک tool call از یک فرآیند را نشان می‌دهد، نه یک تفویض از یک principal. اختیار والد نامرئی است. بازسازی در زیرعامل متوقف می‌شود و مسئولیت به طور پیش‌فرض به deployer می‌افتد زیرا هیچ principal دیگری قابل شناسایی نیست.
راه‌حل، سوابق تحویل صریح است. یک زیرعامل که بر اساس اختیار والد عمل می‌کند باید به اعطای والد استناد کند، نه اینکه اعتبارنامه‌ها را بی‌صدا ارث‌بری کند. سابقه تحویل باید شامل شناسه اقدا
{
"handoff_id": "hand_01H...",
"parent_action": "act_01H...",
"child_agent": "agent:research-01",
"delegated_scope": "search:read",
"attenuated_from": "search:read,search:write",
"policy_version": "policy_2025_04_01",
"signature": "ed25519:..."
}
لغو باید در طول زنجیره منتشر شود و به عنوان یک رویداد ثبت گردد. اگر یک principal یک اعطا را لغو کند، هر اقدام فرزندی پس از آن لغو باید نامعتبر باشد. لاگ باید شامل یک رویداد لغو با شناسه اعطا و مهر زمانی باشد. بدون این، یک عامل لغوشده می‌تواند به عمل ادامه دهد و سابقه اقداماتی را نشان می‌دهد که مجاز به نظر می‌رسند اما مجاز نیستند.
بده‌بستان پیچیدگی است. زنجیره‌های تفویض صریح نیاز دارند که runtime اعطاها را در میان عامل‌ها ردیابی کند، تضعیف را اجرا کند، و لغوها را منتشر کند. پنجره‌های زمینه مشترک ساده‌تر هستند اما سوابقی تولید می‌کنند که نمی‌توانند به سؤالی که یک دادگاه خواهد پرسید پاسخ دهند: این اقدام تحت اختیار چه کسی رخ داده است؟
طراحی برای دادگاه
لاگ اقدام باید به عنوان یک مصنوع درجه‌یک تلقی شود، که در کنار تعریف عامل نسخه‌بندی می‌شود. وقتی سیاست یا مجموعه toolهای یک عامل تغییر می‌کند، لاگ باید نسخه در حال اجرا در زمان هر اقدام را ثبت کند. این امکان بازسازی را بدون مدل اصلی فراهم می‌کند. سابقه باید مستقل باشد: یک تأییدکننده با لاگ، کلیدهای عمومی، و نسخه‌های سیاست باید بتواند تعیین کند چه اتفاقی افتاده و تحت اختیار چه کسی، حتی اگر مدل منسوخ یا در دسترس نباشد.
سیاست نگهداری یک ورودی حقوقی است، نه یک پیش‌فرض زیرساختی. دوره نگهداری باید توسط الزامات حقوقی و انطباقی که برای دامنه عامل اعمال می‌شود تعیین گردد، نه توسط هزینه ذخیره‌سازی. برای عامل‌ها در بخش‌های تنظیم‌شده، نگهداری ممکن است بر حسب سال اندازه‌گیری شود. فرمت لاگ باید از صادرات به فرمت‌هایی که تیم‌های حقوقی می‌توانند بررسی کنند پشتیبانی کند، و زنجیره هش باید مستقل قابل تأیید باشد.
بازسازی بدون مدل اصلی یک الزام سخت است. اگر سابقه برای تفسیر اقدام به بازپخش مدل وابسته باشد، سابقه نیست. یک شبیه‌سازی است. شبیه‌سازی‌ها شواهد نیستند. سابقه باید حاوی اطلاعات کافی برای پاسخ به این باشد: کدام principal این اقدام را مجاز کرده، تحت کدام دامنه، تحت کدام نسخه سیاست، و آیا آن اختیار در آن زمان معتبر بود.
این رویکرد هزینه‌هایی دارد. نیازمند سرمایه‌گذاری در ابزارسازی runtime، مدیریت کلید، و ذخیره‌سازی لاگ است. اجرای اقدام را کند می‌کند. تیم‌ها را مجبور می‌کند که دامنه‌ها و سیاست‌ها را قبل از استقرار تعریف کنند، نه بعد از آن. اما جایگزین یک رژیم مسئولیت است که نمی‌تواند کار کند زیرا ردپای کاغذی وجود ندارد. سؤال این نیست که آیا سوابق قابل انتساب بسازیم. سؤال این است که وقتی سابقه گم است، چه کسی حسابرس را حسابرسی می‌کند.