ProxynetProxynet

عامل‌های هوش مصنوعی چگونه کار می‌کنند؟

تاریخ انتشار:

16 دقیقه مطالعه

Acar Diveroli
نویسنده: Acar Diveroli
کارت هدفی که به مکعب عامل، تراشه ابزار و پشته حافظه می‌رسد و بالای آن‌ها حلقه بازخورد خط‌چین قرار دارد

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

در این نوشته توضیح می‌دهیم عامل هوش مصنوعی چیست و چه تفاوتی با چت‌بات دارد، حلقه درک، برنامه‌ریزی، اقدام و ارزیابی که عامل در هر گام تکرار می‌کند چگونه است و برنامه‌ریزی، به کار بردن ابزار (function calling) و حافظه چگونه کار می‌کنند. سپس بررسی می‌کنیم عامل‌ها چگونه به وب می‌رسند، چرا اشتباه می‌کنند و چگونه تصمیم بگیریم کاری به عامل نیاز دارد یا به جریان کاری از پیش تعریف‌شده.

عامل هوش مصنوعی چیست و چه تفاوتی با چت‌بات دارد؟

چت‌بات برای هر پیام یک پاسخ تولید می‌کند. ممکن است تاریخچه گفت‌وگو را به یاد داشته باشد، اما خودش اقدامی آغاز نمی‌کند و نتیجه یک کار را بررسی نمی‌کند تا گام تازه‌ای بردارد. شما می‌پرسید، او پاسخ می‌دهد.

عامل هوش مصنوعی به سوی یک هدف کار می‌کند و خودش تصمیم می‌گیرد برای رسیدن به آن چه گام‌هایی بردارد. نوشته Building effective agents از Anthropic مرز را این‌گونه می‌کشد: سامانه‌هایی که مدل زبانی و ابزارها را از راه مسیرهای کدی از پیش تعریف‌شده به هم وصل می‌کنند جریان کاری (workflow) هستند؛ سامانه‌هایی که در آن‌ها مدل فرایند و به کار بردن ابزار را خودش پویا هدایت می‌کند عامل هستند.

ویژگیچت‌باتجریان کاریعامل هوش مصنوعی
چه کسی گام‌ها را تعیین می‌کند؟کاربر، در هر پیامتوسعه‌دهنده، در کدمدل، در زمان اجرا
به کار بردن ابزارندارد یا یک‌بارهبا ترتیبی از پیش تعیین‌شدههنگام نیاز، به انتخاب مدل
تعداد گامیک پاسخثابتمتغیر، بسته به هدف
هنگام شکستکاربر دوباره می‌پرسدمسیر جایگزین تعریف‌شدهمدل راه دیگری را می‌آزماید
پیش‌بینی‌پذیریزیادزیادکم
هزینه و تأخیرکممتوسطزیاد، بسته به تعداد گام
کار مناسبپرسش و پاسخ، تولید متنفرایندهای تکراری و روشنکارهای بازی که گام‌هایشان از پیش معلوم نیست

حلقه عامل چگونه کار می‌کند؟

دقیق‌ترین مدل از شیوه کار عامل تکرار یک حلقه واحد است. حلقه تا رسیدن به هدف یا برقرار شدن شرط توقف ادامه می‌یابد.

  1. درک. عامل وضعیت جاری را گرد می‌آورد: هدف کاربر، تاریخچه گفت‌وگو، نتیجه گام‌های پیشین و هر اطلاعاتی که از حافظه بازیابی شده است. همه این‌ها وارد پنجره زمینه مدل می‌شود.
  2. برنامه‌ریزی. مدل با نگاه به این زمینه اقدام بعدی را برمی‌گزیند. گاهی یک گام است مانند «نخست باید جست‌وجو کنم» و گاهی برنامه‌ای چندگامی.
  3. اقدام. مدل فراخوانی ابزار تولید می‌کند: در قالبی ساخت‌یافته می‌نویسد کدام ابزار را با چه پارامترهایی می‌خواهد اجرا کند. برنامه فراخوانی را در عمل اجرا می‌کند.
  4. ارزیابی. نتیجه ابزار به مدل برگردانده می‌شود. مدل بررسی می‌کند نتیجه آن را به هدف نزدیک‌تر کرده یا نه: داده مورد انتظار رسید، خطایی رخ داد، باید برنامه را تغییر داد؟
  5. تکرار یا پایان. اگر هدف به دست آمده باشد مدل پاسخ نهایی را تولید می‌کند. اگر نه، حلقه به گام نخست برمی‌گردد. شرط‌های توقفی مانند بیشینه تعداد گام، سقف بودجه یا تأیید کاربر نمی‌گذارند حلقه برای همیشه ادامه یابد.

یکی از پرارجاع‌ترین بیان‌های این حلقه مقاله ReAct است که در 2022 منتشر شد. مقاله نشان می‌دهد وادار کردن مدل به جابه‌جایی میان «استدلال» (متن استدلالی) و «اقدام» (فراخوانی ابزار) نتیجه بهتری از روش‌هایی می‌دهد که فقط بر استدلال یا فقط بر اقدام تکیه دارند. بیشتر چارچوب‌های عامل امروزی گونه‌ای از این اندیشه را به کار می‌برند.

اسکلت زیر حلقه را مستقل از هر ارائه‌دهنده‌ای نشان می‌دهد. تابع call_model با API مدلی که به کار می‌برید جایگزین می‌شود:

python
MAX_STEPS = 10

def run_agent(goal, tools, call_model):
    messages = [{"role": "user", "content": goal}]
    for step in range(MAX_STEPS):
        reply = call_model(messages, tools)          # plan
        messages.append(reply.as_message())
        if not reply.tool_calls:                      # no tool requested: the job is done
            return reply.text
        for call in reply.tool_calls:                 # act
            try:
                result = tools[call.name](**call.arguments)
            except Exception as exc:                  # give the error back to the model
                result = f"Tool error: {exc}"
            messages.append({"role": "tool", "tool_call_id": call.id, "content": str(result)})
        # evaluation happens on the next call_model call
    return "Step limit reached, the job could not be completed."

دو جزئیات حیاتی حلقه از کد خوانده می‌شود: خطاهای ابزار برنامه را از کار نمی‌اندازند بلکه به مدل برگردانده می‌شوند تا راه دیگری را بیازماید و همیشه شرط توقفی مانند MAX_STEPS وجود دارد.

برنامه‌ریزی چگونه انجام می‌شود؟

برنامه‌ریزی یعنی تقسیم یک هدف بزرگ به گام‌های قابل اجرا از سوی عامل. روش‌های رایج:

  • گام‌به‌گام (به سبک ReAct): مدل در هر حلقه فقط اقدام بعدی را برمی‌گزیند. انعطاف‌پذیر است، چون نتیجه هر گام بر گام بعد اثر می‌گذارد. در کارهای طولانی خطر گم کردن مسیر دارد.
  • نخست برنامه، سپس اجرا: مدل در آغاز برنامه کاملی تولید می‌کند و سپس گام‌ها را به ترتیب اجرا می‌کند. وقتی کار پیش‌بینی‌پذیر است کارآمد است؛ وقتی نتیجه غیرمنتظره‌ای پیش آید برنامه باید دوباره ساخته شود.
  • تقسیم کار: عامل اصلی کار را به زیرکارها تقسیم می‌کند و هر یک را به زیرعامل یا فراخوانی جداگانه مدل می‌سپارد. برای کارهای پژوهشی موازی به کار می‌رود.
  • خودارزیابی (reflection): مدل نتیجه‌ای را که تولید کرده در گامی جداگانه نقد می‌کند و در صورت نیاز اصلاح می‌کند. کیفیت بالا می‌رود، اما هر ارزیابی یعنی هزینه و تأخیر بیشتر.

انتخاب روش به ساختار کار بستگی دارد. برای کاری که گام‌هایش تا حد زیادی از پیش معلوم است برنامه‌ریزی از آغاز مناسب‌تر است؛ برای کار پژوهشی که نتیجه هر گام گام بعد را تعیین می‌کند روش گام‌به‌گام.

به کار بردن ابزار (function calling) چگونه کار می‌کند؟

مدل زبانی خودش نمی‌تواند صفحه وب باز کند، پایگاه داده را پرس‌وجو کند یا فایل بنویسد. برای اینکه بتواند، برنامه به مدل تعریف ابزار می‌دهد. وقتی مدل بخواهد ابزاری را به کار ببرد، به‌جای متن ساده فراخوانی ساخت‌یافته‌ای تولید می‌کند که از طرح آن ابزار پیروی می‌کند. مستندات function calling از OpenAI و مستندات مشابه ارائه‌دهندگان دیگر این جریان را با همین منطق توصیف می‌کنند.

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

json
{
  "name": "get_product_price",
  "description": "Opens the given product page URL and returns the price and currency shown on the page. Only use it for URLs on allowed domains.",
  "input_schema": {
    "type": "object",
    "properties": {
      "url": {
        "type": "string",
        "description": "The full address of the product page, starting with https://"
      },
      "country": {
        "type": "string",
        "enum": ["TR", "DE", "US"],
        "description": "Which country the price should be seen from"
      }
    },
    "required": ["url"]
  }
}

نام فیلد طرح پارامتر از ارائه‌دهنده‌ای به ارائه‌دهنده دیگر فرق می‌کند؛ برخی APIها input_schema و برخی parameters به کار می‌برند. منطق یکسان است.

جریان فراخوانی ابزار:

  1. برنامه درخواست کاربر و تعریف ابزارها را به مدل می‌فرستد.
  2. اگر مدل تصمیم بگیرد به ابزار نیاز دارد، فراخوانی با نام get_product_price و آرگومان‌هایی مانند {"url": "https://...", "country": "TR"} برمی‌گرداند.
  3. برنامه فراخوانی را می‌گیرد، آرگومان‌ها را اعتبارسنجی می‌کند و ابزار را در کد خودش اجرا می‌کند.
  4. نتیجه ابزار ({"price": "...", "currency": "TRY"} یا پیام خطا) به مدل برگردانده می‌شود.
  5. مدل با نتیجه یا ابزار تازه‌ای فرامی‌خواند یا به کاربر پاسخ می‌دهد.

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

MCP پروتکلی برای اشتراک استاندارد ابزارها میان برنامه‌های گوناگون است که آن را در پروتکل MCP چیست و چگونه کار می‌کند؟ توضیح داده‌ایم.

حافظه: کوتاه‌مدت و بلندمدت

مدل‌های زبانی خودشان از یک فراخوانی به فراخوانی بعد چیزی به یاد نمی‌آورند. «حافظه» عامل صرفاً چیزی است که برنامه در هر فراخوانی به مدل می‌دهد.

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

  • خلاصه کردن گام‌های قدیمی‌تر و کنار گذاشتن جزئیات.
  • کوتاه کردن خروجی‌های بزرگ ابزار (مانند کل HTML یک صفحه) یا نگه داشتن فقط بخش لازم.
  • نگه داشتن فقط نتیجه زیرکارهای انجام‌شده.

حافظه بلندمدت بیرون از پنجره زمینه، در پایگاه داده، فایل یا انباره برداری نگه داشته می‌شود. عامل هنگام نیاز با یک ابزار اطلاعات را از این انباره بازیابی می‌کند. ترجیحات کاربر، اطلاعاتی که از کارهای پیشین آموخته شده و مجموعه‌های بزرگ سند این‌گونه ذخیره می‌شوند.

مؤلفهنقشپیاده‌سازی معمول
مدلتفسیر وضعیت، انتخاب اقداممدل زبانی بزرگ
حلقه (هماهنگ‌سازی)فراخواندن مدل، اجرای ابزارها، بررسی شرط توقفکد برنامه، چارچوب عامل
ابزارهاانجام اقدام در دنیای بیرونAPI جست‌وجو، کلاینت HTTP، مرورگر، پایگاه داده
حافظه کوتاه‌مدتزمینه کار جاریتاریخچه پیام، پنجره زمینه
حافظه بلندمدتاطلاعات میان کارهاپایگاه داده، فایل، انباره برداری
نرده‌های محافظمجوزها، محدودیت‌ها و تأییدفهرست مجاز، محدودیت نرخ، تأیید انسانی

عامل چگونه به وب می‌رسد؟

بیشتر عامل‌هایی که اطلاعات به‌روز لازم دارند از یکی از این سه راه به وب می‌رسند:

  • API جست‌وجو. عامل پرس‌وجوی جست‌وجو می‌فرستد و فهرستی از عنوان‌ها، آدرس‌ها و بریده‌های کوتاه می‌گیرد. سریع و ارزان است، اما فقط بریده‌ها را می‌بیند.
  • کلاینت HTTP. عامل آدرس مشخصی را می‌گیرد و HTML یا متن صفحه را دریافت می‌کند. در صفحه‌های ایستا خوب کار می‌کند و در صفحه‌هایی که محتوایشان با جاوااسکریپت بارگذاری می‌شود خالی برمی‌گردد.
  • مرورگر. عامل مرورگر واقعی را هدایت می‌کند: صفحه باز می‌کند، کلیک می‌کند، فرم پر می‌کند و تصویر صفحه می‌گیرد. توانمندترین راه است، اما کندترین و گران‌ترین هم هست.

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

پروکسی در این ساختار در لایه شبکه قرار می‌گیرد و برای سه کار به کار می‌رود:

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

شیوه طراحی این لایه همراه تدابیری در برابر تزریق پرامپت در دسترسی امن LLM به وب: محدودیت نرخ و مجوزها آمده است. نگاه وب‌سایت‌ها به ترافیک عامل و چرایی مسدود شدن عامل‌ها را در چرا سایت‌ها عامل‌های خرید هوش مصنوعی را مسدود می‌کنند؟ بررسی کرده‌ایم. برای نمونه‌ای از اینکه مدل زبانی چگونه برای استخراج داده ساخت‌یافته از صفحه‌های وب به کار می‌رود، وب اسکرپینگ با ⁦GPT-6 Astra⁩ را ببینید.

چرا عامل‌ها اشتباه می‌کنند؟

شکست‌های سامانه‌های عامل با اشتباه‌های یک فراخوانی منفرد مدل فرق دارد، چون خطاها در طول گام‌ها انباشته می‌شوند.

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

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

جریان کاری یا عامل؟

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

  • برای کاری که گام‌هایش از پیش معلوم است و هر بار به همان ترتیب انجام می‌شود (گرفتن روزانه قیمت از همان 50 صفحه و نوشتن در جدول)، جریان کاری تعریف‌شده در کد ارزان‌تر، سریع‌تر و پیش‌بینی‌پذیرتر است. مدل زبانی را می‌توان درون همین جریان فقط در یک گام مشخص به کار برد، برای نمونه استخراج داده از متن نامنظم.
  • برای کاری که گام‌هایش با وضعیت تغییر می‌کند و از پیش معلوم نیست به کدام منابع باید نگاه کرد (گردآوری اطلاعات درباره بازاری تازه از منابع پراکنده)، عامل معنا دارد.

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

کاربردها

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

اشتباهات رایج

  • ساختن عامل برای کاری که جریان کاری ساده از پسش برمی‌آید. هزینه، تأخیر و پیش‌بینی‌ناپذیری بی‌دلیل بالا می‌رود.
  • نگذاشتن شرط توقف. عامل بدون سقف گام، سقف بودجه یا timeout می‌تواند هزینه بی‌مهار بسازد.
  • نوشتن توضیح کوتاه و مبهم برای ابزار. مدل ابزار را در وضعیت نادرست یا با آرگومان‌های نادرست فرامی‌خواند.
  • اعتبارسنجی نکردن آرگومان‌های ابزار. هر مقداری که مدل تولید می‌کند باید ورودی نامطمئن دانسته شود.
  • دستور دانستن محتوای وب. متن یک صفحه نباید همان اعتبار درخواست کاربر را داشته باشد.
  • بی‌تأیید گذاشتن اقدام‌های حیاتی. اقدام‌های برگشت‌ناپذیر مانند پرداخت، فرستادن ایمیل یا حذف داده باید تأیید انسانی بخواهند.
  • معلق کردن قواعد سایت برای عامل. هر صفحه‌ای که عامل باز می‌کند تابع همان محدودیت‌های نرخ و شرایطی است که صفحه باز شده به دست اسکرپر. برای چارچوب حقوقی، آیا وب اسکرپینگ قانونی است؟ را ببینید.

راهنمای انتخاب

ساختار کار شماپیشنهاد
یک پرسش، یک پاسخیک فراخوانی منفرد مدل
گام‌ها ثابت و از پیش معلوم‌اندجریان کاری تعریف‌شده در کد
جریان ثابت، متن نامنظم در یک گامجریان کاری همراه فراخوانی مدل در همان گام
گام‌ها با وضعیت تغییر می‌کنندعامل، با سقف گام و بودجه
عامل به وب دسترسی خواهد داشتفهرست مجاز، محدودیت نرخ، ثبت رویداد و کنترل خروج
اقدام‌های برگشت‌ناپذیر وجود داردعامل همراه تأیید انسانی
اشتراک ابزارها میان چند برنامهسرور MCP

پرسش‌های متداول

تفاوت اصلی عامل هوش مصنوعی و چت‌بات چیست؟

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

آیا عامل خودش ابزارها را اجرا می‌کند؟

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

حافظه عامل کجا نگه داشته می‌شود؟

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

عامل هنگام جمع‌آوری داده از وب‌سایت‌ها از کدام قواعد باید پیروی کند؟

همان قواعدی که اسکرپر پیروی می‌کند: robots.txt، شرایط سایت، محدودیت‌های نرخ و قانون‌های داده شخصی. سامانه هوش مصنوعی بودن این قواعد را تغییر نمی‌دهد؛ چون می‌تواند سریع کار کند، اعمال محدودیت‌ها در سطح سامانه حتی مهم‌تر است.

چرا عامل‌ها برای یک کار نتیجه‌های متفاوت می‌دهند؟

مدل‌های زبانی ممکن است در هر فراخوانی خروجی دقیقاً یکسان تولید نکنند و مسیری که عامل در هر گام برمی‌گزیند بر گام بعد اثر می‌گذارد. همچنین چون منابع بیرونی مانند وب تغییر می‌کنند، یک پرس‌وجو ممکن است به داده متفاوتی برسد. برای کارهایی که تکرارپذیری مهم است، روش جریان کاری مناسب‌تر است.

از کجا بفهمم کاری به عامل می‌خورد؟

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

خلاصه

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

پرسش از ChatGPTپرسش از Claude