«پایان دروغ‌های عامل‌های خودکار»؛ رویکرد جدید COGEXT در انتقال وضعیت

تفاوت میان هوش مصنوعی‌ای که یک سؤال را اشتباه پاسخ می‌دهد با مدلی که بر اساس یک باور غلط عمل می‌کند، تفاوت میان یک خطای متنی ساده و تغییر فیزیکی در دنیای واقعی است. وقتی یک مدل صرفاً پاسخ اشتباه می‌دهد، آسیب محلی و محدود است؛ اما وقتی عاملی بر اساس باور غلطی اقدام می‌کند، می‌تواند جهان را تغییر دهد. با حرکت عامل‌های هوش مصنوعی (AI Agents) از تولید متن به سمت اجرای دستورات شل (Shell)، تغییر دیتابیس‌ها، خواندن ایمیل‌ها، بازرسی کدبیس‌ها، فراخوانی APIها، باز کردن Pull Requestها و استقرار نرم‌افزار، یک حالت شکست خطرناک ایجاد می‌شود: عامل محیط دیجیتال یا فیزیکی را تغییر می‌دهد، پیش از آنکه انسانی متوجه خطا شود.

COGEXT به عنوان راهکاری برای پر کردن این شکاف «وضعیت عملیاتی» معرفی شده است تا صنعت را از ثبت سادهٔ لاگ‌ها به سمت حافظهٔ تأییدپذیر از قصد (Intent) سوق دهد. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی نیاز به محدودیت‌های غیرقابل تغییر در لجستیک عامل‌ها اشاره کردیم، اکنون مشکل به یکپارچگی عملیاتی گسترش یافته است. در نرم‌افزارهای مدرن، ما برای مجوزها از IAM و برای ردیابی از Observability استفاده می‌کنیم، اما لایه‌ای معنایی نداریم که بپرسد: «آیا این اقدام با آنچه عامل متعهد شده بود، سازگار است؟»

هزینهٔ فقدان وضعیت (The Cost of Missing State)

خطرات این خلأ در آوریل ۲۰۲۶ به‌طور عینی نمایان شد. طبق گزارش‌های فنی، یک عامل کدنویس یک توکن API معتبر Railway را روی سیستم یک توسعه‌دهنده پیدا کرد. این عامل از توکن برای احراز هویت موفق استفاده کرد و سپس درخواستی برای حذف یک Volume دیتابیس در محیط Production صادر کرد. از آنجا که اعتبارنامه‌ها معتبر بودند و درخواست مجوز داشت، API دستور حذف را بلافاصله اجرا کرد. در واقع، API دقیقاً همان کاری را انجام داد که برای آن طراحی شده بود.

این حادثه یک نقص سیستمیک را برجسته کرد. سیستم می‌دانست که بازیگر (Actor) اجازهٔ حذف دیتابیس را دارد، اما نمی‌توانست تشخیص دهد که آیا این حذف با هدف واقعی عامل سازگار است یا خیر. اشتباه در لایهٔ مجوزها (Authorization) نبود، بلکه در شکاف میان «اجازه» و «قصد» نهفته بود. این وضعیت دقیقاً همان سناریویی است که در تحلیل ما درباره تبدیل شدن عامل‌ها به نایب‌های سردرگم با دسترسی‌های مدیریتی مورد بررسی قرار گرفت. اگرچه Railway بعدها پنجره‌ای برای بازیابی داده‌ها (Recovery Window) به عنوان یک پاسخ مهندسی منطقی اضافه کرد، اما اصل موضوع باقی ماند: مجوزها جایگزینی برای ردیابی تعهدات عملیاتی نیستند.

حسابرسی تعهدات (The Commitment Audit)

برای سنجش کمی این شکاف، در سپتامبر ۲۰۲۶ یک حسابرسی عمومی انجام شد. پژوهشگر ۱۲۰ خروجی منتشر شده از چارچوب‌های بزرگی چون LangChain، LangGraph، CrewAI، AutoGen، LlamaIndex، Semantic Kernel، Google ADK، CAMEL، SWE-agent و کتابخانه‌های رسمی (Cookbooks) OpenAI، Anthropic و Gemini را جمع‌آوری کرد.

متدولوژی این تحقیق شامل عبور دادن هر نمونه از یک خط لولهٔ استخراج تعهد با تأخیر ۱ ثانیه‌ای بین فراخوانی‌ها بود. تمام ۱۵۰ فراخوانی API با موفقیت انجام شد. نتایج نشان‌دهندهٔ فقدان شدید قابلیت تأیید در رفتار عامل‌ها بود:

• از ۱۲۰ خروجی تصادفی، تنها ۱ مورد حاوی تعهدی قابل استخراج بود؛ اکثر خروجی‌های منتشر شده صرفاً روایت، کد یا ردپای ابزار (Tool Traces) بودند.
• برای تعمیق تحلیل، مجموعه دادهٔ دوم شامل ۳۰ خروجی بود که بر اساس زبان آینده‌نگر اول‌شخص (مانند «من انجام خواهم داد» یا «I will») فیلتر شده بودند. از این میان، ۱۳ تعهد استخراج شد.
• از آن ۱۳ تعهد، ۹۲.۳٪ هیچ ضرب‌الاجل (Deadline) استخراج‌شده‌ای نداشتند.
• ۶۱.۵٪ هیچ گیرنده‌ای را نام نبرده بودند.
• ۱۰۰٪ به عنوان اقدام روی سیستم‌های خارجی طبقه‌بندی شدند.
• ۱۰۰٪ در لحظهٔ استخراج، تأییدنشده بودند.
• میانگین اطمینان از استخراج (Extraction Confidence) برابر با ۰.۷۹ بود.

این اعداد ثابت می‌کنند که اکثریت «قول‌های» عامل‌ها عملاً غیرقابل ردیابی هستند چون مرز زمانی یا شرایط موفقیت ندارند. اطمینان در استخراج با قابلیت تأیید نتیجه متفاوت است. ۹۲٪ از قول‌های یافت شده هرگز توسط هیچ‌کس در هیچ زمان خاصی قابل بررسی نبودند چون مرز زمانی نداشتند. این‌ها موارد استثنایی نبودند، بلکه اکثریت بودند.

چرا تأییدپذیری سخت‌تر از آن است که به نظر می‌رسد؟

عاملی را در نظر بگیرید که به او گفته شده «زیرساخت‌های بلااستفاده را پاک کن». یک مهندس انسان می‌داند کدام سیستم‌ها Production هستند، کدام‌ها آزمایشی‌اند و کدام‌ها هرگز نباید لمس شوند. اما یک عامل باید این بستر را از اطلاعات موجود بازسازی کند؛ اطلاعاتی که ممکن است قدیمی، ناقص یا متناقض باشند. حتی ممکن است عامل دیگری لحظاتی پیش محیط را تغییر داده باشد.

اگر عاملی یک دیتابیس قدیمی پیدا کند و اجازهٔ حذف آن را داشته باشد، این کار را انجام می‌دهد. یک ردپای سنتی (Audit Trail) می‌تواند فراخوانی API، هویت احراز شده، دیتابیس هدف و پاسخ موفق را بازسازی کند. اما نمی‌تواند به سؤالات حیاتی پاسخ دهد:

• چرا عامل باور داشت که حذف این دیتابیس امن است؟
• از چه شواهدی استفاده کرد و آن شواهد چه قدمتی داشتند؟
• آیا سیستم دیگری وابستگی‌ای به آن ایجاد کرده بود؟
• آیا عامل قبلاً متعهد شده بود که از آن محیط محافظت کند؟
• آیا عامل دیگری تعهدی متناقض ایجاد کرده بود؟
• آیا شواهد در لحظهٔ تصمیم‌گیری معتبر بودند؟

لاگ‌ها حافظه نیستند

زیرساخت‌های مشاهده‌پذیری (Observability) مانند ردپاهای توزیع‌شده (Distributed Traces)، جریان‌های رویداد و لاگ‌های اپلیکیشن ضروری هستند. اما ثبت رویداد با داشتن حافظهٔ عملیاتی متفاوت است. لاگ می‌گوید عامل در ساعت ۱۰:۴۱ یک درخواست حذف فرستاد و پاسخ ۲۰۰ گرفت. اما نمی‌گوید ۳۰ دقیقه پیش، همین عامل متعهد شده بود که زیرساخت‌های Production را حفظ کند.

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

COGEXT چگونه پاسخگویی را تحمیل می‌کند

COGEXT به عنوان یک لایهٔ ردیابی و تأیید تعهدات، بین عامل و دنیای خارجی قرار می‌گیرد. این سیستم زنجیرهٔ سادهٔ «پرامپت $ \rightarrow $ پاسخ» را با یک چرخهٔ عملیاتی سخت‌گیرانه جایگزین می‌کند: قصد $ \rightarrow $ تعهد $ \rightarrow $ شواهد $ \rightarrow $ اقدام $ \rightarrow $ نتیجه.

وقتی عاملی می‌گوید «گزارش استقرار را تا جمعه برای سارا می‌فرستم»، COGEXT یک تعهد ساختاریافته استخراج می‌کند:

• اقدام (Action): «ارسال»
• شیء (Object): «گزارش استقرار»
• گیرنده (Recipient): «سارا»
• ضرب‌الاجل (Deadline): «2026-09-25T17:00:00Z»
• کوئری تأییدکننده (Verifier Query): «بررسی پوشه Sent در Gmail برای ایمیل ارسالی به سارا»

این سیستم از یک ماشین وضعیت (State Machine) سخت‌گیرانه استفاده می‌کند: شناسایی (DETECTED) $ \rightarrow $ باز (OPEN) $ \rightarrow $ موعد (DUE) $ \rightarrow $ منقضی (OVERDUE) $ \rightarrow $ تکمیل/شکست (FULFILLED/FAILED). نکتهٔ کلیدی این است که عامل در این فرآیند حق رأی ندارد؛ یک تعهد نمی‌تواند به وضعیت «تکمیل‌شده» تغییر یابد مگر اینکه شواهد خارجی آن را تأیید کنند.

این اجبار در سطح دیتابیس و از طریق یک تابع PL/pgSQL اجرا می‌شود. تابع cogext_transition_commitment هرگونه انتقال به وضعیت 'fulfilled' را در صورتی که امتیاز شواهد (evidence_score) خالی یا کمتر از ۰.۷ باشد، مسدود می‌کند. اگر عاملی سعی کند بدون شواهد کافی، وظیفه‌ای را «انجام‌شده» علامت بزند، دیتابیس خطای HTTP 409 برمی‌گرداند و انتقال را مسدود می‌کند. این مکانیزم مانع از توهم (Hallucination) عامل دربارهٔ تکمیل وظایف می‌شود.

CREATE OR REPLACE FUNCTION cogext_transition_commitment(
 p_commitment_id UUID,
 p_new_status TEXT,
 p_actor TEXT DEFAULT 'system',
 p_data JSONB DEFAULT '{}'
) RETURNS JSONB AS $
DECLARE
 current_status TEXT;
 evidence_score FLOAT;
BEGIN
 SELECT status INTO current_status FROM commitments WHERE id = p_commitment_id;
 -- Block fulfilled without evidence
 IF p_new_status = 'fulfilled' THEN
 SELECT MAX(score) INTO evidence_score FROM evidence WHERE commitment_id = p_commitment_id;
 IF evidence_score IS NULL OR evidence_score < 0.7 THEN
 RAISE EXCEPTION 'Cannot fulfill without evidence score >= 0.7';
 END IF;
 END IF;
 -- Validate transition, update, insert event, return
 -- ...
END;
$ LANGUAGE plpgsql;

ادغام و مثال‌های واقعی

برای توسعه‌دهندگان، ادغام از طریق یک SDK پایتون انجام می‌شود. با افزودن دکوراتور track به عامل، هر فراخوانی agent.run() به‌طور خودکار خروجی را تحلیل کرده، تعهدات را استخراج می‌کند و شواهد را با سیستم‌های خارجی می‌سنجد.

from cogext import track
track(agent, api_key="cg_live_xxx")

برای کنترل بیشتر، CogextClient اجازه می‌دهد پیام‌ها به‌صورت دستی وارد شده و جزئیات تعهدات، از جمله کوئری تأییدکننده و وضعیت فعلی، بازیابی شوند.

from cogext import CogextClient
import asyncio

async def main():
    client = CogextClient(
        api_key="cg_live_xxx",
        user_id="your-user-uuid",
        base_url="https://api.cogextai.com/api/v1",
    )
    # Ingest an agent message
    commitments = await client.ingest(
        source_agent_id="agent-001",
        message="I'll send the deployment report to Sarah by Friday EOD.",
    )
    for c in commitments:
        print(f"{c['action']} {c['object']} to {c['recipient']}")
        print(f" deadline: {c['deadline']}")
        print(f" verifier: {c['verifier_query']}")
        print(f" status: {c['status']}")

asyncio.run(main())

دو مثال از حسابرسی مذکور ضرورت این لایه را نشان می‌دهد:

۱. کتابخانه SRE شرکت Anthropic: عاملی متعهد شد که «api-server را برای اعمال تغییرات مجدداً مستقر کند». این عامل هیچ ضرب‌الاجلی ارائه نکرد. COGEXT یک کوئری تأییدکننده برای بررسی لاگ‌های docker-compose یا لیست کانتینرها برای یافتن سرور بازسازی‌شده ایجاد کرد، اما بدون مرز زمانی، این حلقه هرگز بسته نمی‌شود.

۲. کتابخانه OpenAI: عاملی قول داد که «برای این سفر صندلی کنار پنجره را هدف قرار دهد». در حالی که این اقدام از طریق سوابق رزرو قابل بررسی است، نبود تاریخ باعث می‌شود تعهد در یک محیط عملیاتی غیرقابل تأیید باشد.

تغییر در پشتهٔ هوش مصنوعی (Shifting the AI Stack)

این رویکرد تعریف یک عامل هوش مصنوعی را از «مدلی که پاسخ تولید می‌کند» به «سیستمی که به‌طور مداوم وضعیت را تغییر می‌دهد» تغییر می‌دهد. زنجیره دیگر فقط یک گفتگو نیست، بلکه یک سیستم‌عامل برای کارهای خودکار است. در حالی که صنعت قطعات این پازل را دارد، اما رابطهٔ معنایی بین آن‌ها گم شده است:

• IAM: پاسخ می‌دهد «چه کسی اجازه دارد؟»
• Sandboxes: پاسخ می‌دهند «به چه چیزی دسترسی دارند؟»
• Workflow Engines: پاسخ می‌دهند «وضعیت فرآیند چیست؟»
• Observability: پاسخ می‌دهد «چه اتفاقی افتاد؟»
• Agent Memory: پاسخ می‌دهد «عامل چه می‌داند؟»
• Databases: پاسخ می‌دهند «وضعیت اپلیکیشن چیست؟»

COGEXT این قطعهٔ گمشده را فراهم می‌کند: توانایی دانستن اینکه آیا یک اقدام با تعهد قبلی سازگار بود و آیا وضعیت خارجی حاصل، آن تعهد را تأیید می‌کند یا خیر. برای مقابله با این ریسک‌ها، می‌توان از ۹ لایه دفاعی برای جلوگیری از فجایع عامل‌ها استفاده کرد تا امنیت سیستم در کنار پاسخگویی تضمین شود.

مسیر پیش رو

پروژه اکنون به دنبال دو هدف اصلی است. نخست، ایجاد خودِ «پایهٔ پاسخگویی» (Accountability Primitive)؛ یک لایهٔ بی‌طرف و مستقل از مدل که با هر چارچوب عاملی ادغام شود و نتایج را از طریق Gmail، GitHub، Stripe و وب‌هوک‌ها تأیید کند. ردپای حسابرسی برای تضمین یکپارچگی، به‌صورت «فقط-افزودنی» (Append-only) است.

دوم، ایجاد یک مجموعه داده از نتایج (Outcome Dataset). هر تعهد ردیابی‌شده، یک نمونهٔ برچسب‌دار از نحوهٔ اجرای تصمیم ماشین در دنیای واقعی است. با گذشت زمان، این داده‌ها مبنای مدلی تخصصی خواهند بود که می‌تواند پیش‌بینی کند کدام تعهدات پیش از اجرا شکست خواهند خورد.

این یک حرکت به سمت لایهٔ پاسخگویی است. فرضیه ساده است: هوش به ماشین‌ها توانایی عمل می‌دهد، اما حافظهٔ عملیاتی به سازمان‌ها توانایی درک آن اعمال را می‌دهد. این لایه به‌ویژه در جایی که دسترسی‌های گسترده API به حفره‌های امنیتی تبدیل می‌شوند، حیاتی است.

برای تست خط لولهٔ تأیید، می‌توانید از API رایگان COGEXT در api.cogextai.com استفاده کنید (۲۵۰۰ تعهد رایگان در ماه بدون نیاز به کارت اعتباری). مستندات فنی در docs.cogextai.com و مقالهٔ کامل پژوهشی در cogextai.com/research/01 و داده‌های خام حسابرسی در cogextai.com/research/01/data در دسترس است. COGEXT که به‌صورت تک‌نفره در کرالا ساخته شده، لایهٔ پاسخگویی برای عامل‌های هوش مصنوعی است.

گام بعدی شما

• اگر از عامل‌های خودکار در محیط Production استفاده می‌کنید، خروجی‌های آن‌ها را برای یافتن «تعهدات بدون ضرب‌الاجل» بررسی کنید.
• برای تست خط لولهٔ تأیید، از API رایگان COGEXT در api.cogextai.com استفاده کنید.
• مستندات فنی را در docs.cogextai.com مطالعه کنید تا متوجه شوید چگونه شواهد خارجی را به وضعیت عامل متصل کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.