AI Agent چیست: پنج نوع کلاسیک، دو تعریف رقیب

قدیمی‌ترین مثال این حوزه، جاروبرقی‌ای است در جهانی با دو خانه، A و B، که هرکدام یا تمیزند یا کثیف.¹ این مثال در هر کتاب درسی زنده مانده چون کوچک‌ترین جهانی است که در آن یک agent می‌تواند درست یا غلط عمل کند.

percept یک جفت است — من کجا هستم، و آیا اینجا کثیف است — و actionها SUCK، LEFT و RIGHT هستند. کل برنامه یک خط است.

type Percept = { dirty: boolean; where?: "A" | "B" };
type Action = "SUCK" | "LEFT" | "RIGHT";

const textbook = (p: Percept): Action =>
  p.dirty ? "SUCK" : p.where === "A" ? "RIGHT" : "LEFT";   

آن را روی همه پیکربندی‌های آغازین جهانِ دوخانه‌ای اجرا کنید:

A dirty, B dirty, start A    -> steps=3 clean=true
A clean, B dirty, start A    -> steps=2 clean=true
A dirty, B clean, start B    -> steps=2 clean=true

این یک simple reflex agent است: فقط بر اساس percept فعلی عمل می‌کند، بدون هیچ حافظه‌ای از آنچه پیش از آن بوده. این یک دسته‌بندی اسباب‌بازی نیست — ترموستات یکی از آن‌هاست، و یک call منفرد به یک مدل زبانی بدون مکالمه متصل هم همین‌طور.

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

const dirtOnly = (p: Percept): Action => (p.dirty ? "SUCK" : "RIGHT");

A dirty, B dirty, start A    -> steps=3   clean=true   still dirty=0
      t=0 at=A percept={dirty:true}  -> SUCK
      t=1 at=A percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:true}  -> SUCK

A dirty, B clean, start B    -> steps=500 clean=false  still dirty=1
      t=0 at=B percept={dirty:false} -> RIGHT
      t=1 at=B percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:false} -> RIGHT
      t=3 at=B percept={dirty:false} -> RIGHT

همان برنامه، دو خانه. از یک state آغازین در سه step تمام می‌کند؛ از دیگری پانصد بار به دیوار سمت راست می‌کوبد و تا مردن باتری ادامه می‌داد. نمی‌تواند تفاوت دو موقعیت را perceive کند، پس نمی‌تواند در آن‌ها متفاوت عمل کند. Russell و Norvig نتیجه کلی را در یک خط بیان می‌کنند: loopهای بی‌نهایت برای simple reflex agentها در محیط‌های partially observable اغلب اجتناب‌ناپذیرند.¹

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

let seed = 12345;
const rnd = () => ((seed = (seed * 1103515245 + 12345) & 0x7fffffff) / 0x7fffffff);

const coin = (p: Percept): Action => (p.dirty ? "SUCK" : rnd() < 0.5 ? "LEFT" : "RIGHT");  

دو هزار run از راهرویی کاملاً کثیف در سه اندازه، با یک generator seedشده در تمام مدت:

تصادفی‌سازی loop را کاملاً حذف می‌کند. اما هزینه هم دارد: هشت اتاق، اگر بدانید چه می‌کنید، به پانزده حرکت نیاز دارد؛ این agent به‌طور میانگین 68.7 حرکت انجام می‌دهد و یک بار 306 حرکت طول کشیده است. این کل فصل در مقیاس کوچک است. هر قابلیتی که اضافه می‌کنیم، در موردی که agent قبلی از پسش برنمی‌آمد درستی می‌خرد، و هزینه‌اش را با ارزی می‌گیرد که اول باید نامش را مشخص کنید.

یک agent محیط خود را از طریق sensorها perceive می‌کند و از طریق actuatorها عمل می‌کند. agent program تابعی از perceptها به actionهاست — هر listing بالا یکی از آن‌هاست. percept sequence همه چیزهایی است که تا اینجا perceive شده، و یک simple reflex agent همه‌اش جز آخرین مورد را نادیده می‌گیرد.

Rationality واژه‌ای است که بیشتر مقاله‌ها اشتباه می‌فهمند، و درست فهمیدنش بقیه این فصل را قابل استفاده می‌کند. یک agent به‌خودی‌خود rational یا irrational نیست. Russell و Norvig یک rational agent را agentی تعریف می‌کنند که برای هر percept sequence ممکن، actionی را انتخاب می‌کند که انتظار می‌رود performance measure آن را حداکثر کند، با توجه به شواهد آن sequence و هر دانشی که درونش تعبیه شده است.¹ performance measure داخل agent نیست: متعلق به طراح است، و rationality فقط نسبت به آن تعریف می‌شود.

مشخصات معمولاً در قالب چهار چیز نوشته می‌شود، PEAS: performance measure، environment، actuators، sensors.

دقت کنید کدام ردیف وصله ناجور است. تقریباً هر تیمی که در 2026 agent می‌سازد، E و A و S را می‌نویسد — tool schemaها، integrationها، قالب پیام — چون بدون آن‌ها کد اجرا نمی‌شود. تقریباً هیچ‌کس P را نمی‌نویسد. بدون آن، «agent ما خوب کار می‌کند» معنایی ندارد که کسی بتواند بررسی کند، و «rational» اصلاً قابل اعمال به سیستم نیست، فقط به یک نمایش قابل اعمال است. فصل 29 درباره تبدیل P به یک عدد است، و به همین دلیل وجود دارد.

    ┌───────────────────────── the environment ─────────────────────────┐
    │                                                                   │
    │   ┌──────────────────────── the agent ─────────────────────┐      │
    │   │                                                        │      │
 ───┼──►│  sensors  ──►  the agent program  ──►  actuators  ─────┼──────┼──►
percept │                                                        │    action
    │   └────────────────────────────────────────────────────────┘      │
    └───────────────────────────────────────────────────────────────────┘
                                   ▲
              the performance measure lives out here, in the head of
              whoever built the thing, and the agent cannot change it

محیط‌های task همچنین روی هفت محور دسته‌بندی می‌شوند که پنج تای آن‌ها بیشترین دشواری اینجا را تعیین می‌کنند: fully یا partially observable، deterministic یا نه، episodic یا sequential، static یا dynamic، known یا unknown.¹ agentی که با toolهای واقعی روی شبکه واقعی حرف می‌زند، در گوشه سخت هر پنج محور است — حتی در temperature صفر non-deterministic است (فصل 17)، و موردی که دست‌کم گرفته می‌شود، unknown است، چون شما مدل قابل اتکایی از اینکه toolهای خودتان با جهان چه می‌کنند ندارید. به همین دلیل loop فصل 23 بیش از planning به error handling نیاز دارد.

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

        col  0 1 2 3 4 5 6
      row 0  * . . # . . *
      row 1  . # . # . # .
      row 2  . # . S . # .        S = the robot starts here
      row 3  . # . # . # .
      row 4  * . . # . . *

ارتقای بدیهی حافظه است. agent یک نقشه نگه می‌دارد: هر خانه‌ای که روی آن ایستاده و هر خانه‌ای که ضربه‌گیر در آن فعال شده. قاعده‌اش این است که به یک خانه مجاورِ ندیده قدم بگذارد — راست، بعد پایین، بعد چپ، بعد بالا — و وقتی همه چیز اطرافش معلوم است عقب بکشد. این یک model-based reflex agent است: از تاریخچه perceptها state داخلی نگه می‌دارد، پس می‌تواند بر اساس چیزی عمل کند که اکنون نمی‌بیند.

این پیشرفت واقعی است، و هنوز کافی نیست:

5,000 steps allowed -> steps=5,000  distinct squares visited=13/25  still dirty=2/4

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

یک goal-based agent علاوه بر مدلش از جهان، توصیفی از موقعیتی که می‌خواهد پدید آورد نگه می‌دارد، و actionها را با جست‌وجو در sequenceهای آن‌ها انتخاب می‌کند تا یکی را پیدا کند که آنجا تمام می‌شود. goalها انتخاب action را از lookup به search تبدیل می‌کنند.

goal این است که «هیچ خانه کثیفی باقی نماند». search یک پیمایش breadth-first تا نزدیک‌ترین خانه کثیف است، و مسیری که برمی‌گرداند همان plan است.

goal-based (fewest moves)      -> moves=27  battery=52  still dirty=0
      from 2,3 -> 4,6 via 5 moves:  2,3 2,4 3,4 4,4 4,5 4,6
      from 4,6 -> 0,6 via 4 moves:  4,6 3,6 2,6 1,6 0,6
      from 0,6 -> 4,0 via 10 moves: 0,6 0,5 0,4 1,4 2,4 2,3 2,2 3,2 4,2 4,1 4,0
      from 4,0 -> 0,0 via 4 moves:  4,0 3,0 2,0 1,0 0,0

بیست‌وهفت حرکت، کف تمیز. اما به ستون باتری و آخرین بخش plan نگاه کنید. ستون 0 فرش‌شده است: عبور از یک خانه فرش‌شده شش واحد باتری هزینه دارد، از یک خانه کاشی‌شده یک واحد. agent از ستون 0 به خانه برگشت، چون چهار حرکت بود نه هشت، و آن چهار حرکت روی فرش 24 هزینه داشت، در حالی که مسیر دورترِ هشت‌حرکتی 13 هزینه می‌داشت.

نمی‌تواند جور دیگری عمل کند. یک goal یک آزمون binary است: کف تمیز است یا نیست. هر planی که به کف تمیز ختم شود، آن را به‌طور برابر برآورده می‌کند، پس وقتی چند plan موفق می‌شوند agent چیزی برای انتخاب بین آن‌ها ندارد. ترجیح دادن یک موفقیت به موفقیت دیگر، به عددی روی outcomeها نیاز دارد، و آن عدد یک utility function است. agentی که آن را حداکثر می‌کند یک utility-based agent است.

تغییر کد، یک term داخل search است. breadth-first search حرکت‌ها را می‌شمارد؛ کاری کنید هزینه را بشمارد و Dijkstra's algorithm و agentی متفاوت دارید:

const nd = dist.get(k)! + (byCost ? cell.cost : 1);   // <- the entire difference

goal-based    (fewest moves)   -> moves=27  battery=52  still dirty=0
utility-based (cheapest route) -> moves=31  battery=41  still dirty=0
      from 4,0 -> 0,0 via 8 moves: 4,0 4,1 4,2 3,2 2,2 1,2 0,2 0,1 0,0

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

این همچنین نخستین نقطه‌ای است که agent به چیزی نیاز دارد که خودش نمی‌تواند تولید کند. کسی باید تصمیم بگیرد یک واحد باتری نسبت به یک حرکت چقدر می‌ارزد. utility همان performance measure است که به شکلی نوشته شده که agent بتواند با آن محاسبه کند، و نوشتنش کار طراح است. وقتی مردم می‌گویند یک agent «چیز اشتباهی را optimised کرد»، تقریباً هیچ‌وقت منظورشان bug نیست. منظورشان این است که این خط بی‌دقت نوشته شده بود.

حالا بگذارید خاک برگردد. چهار اتاق با چهار نرخ متفاوت دوباره کثیف می‌شوند، و agent هرگز این نرخ‌ها را نمی‌داند. هر tick به یک اتاق سر می‌زند و فقط همان اتاق را می‌بیند. performance measure برابر است با room-tickهایی که طی 4,000 tick کثیف مانده‌اند — کمتر بهتر است.

یک learning agent، در تجزیه کتاب درسی، هرکدام از موارد بالاست به‌علاوه سه بخش: یک learning element که agent را تغییر می‌دهد، یک critic که می‌گوید agent در برابر یک استاندارد عملکرد ثابت چطور عمل می‌کند، و یک problem generator که actionهایی را پیشنهاد می‌کند که به‌خاطر چیزی که یاد می‌دهند ارزش امتحان کردن دارند.¹ سه policy در همان environment. اولی یاد نمی‌گیرد؛ دومی و سومی یک چیز را یاد می‌گیرند و متفاوت از آن استفاده می‌کنند.

نرخ‌های پنهان 0.35 برای آشپزخانه، 0.05 برای راهرو، 0.02 برای اتاق کار و 0.01 برای زیرشیروانی بودند — و learner A آن‌ها را پیدا کرد. درست تشخیص داد که آشپزخانه کثیف‌ترین اتاق خانه است، سپس در باقی simulation در هر tick به آشپزخانه رفت، در حالی که سه اتاق دیگر برای همیشه کثیف ماندند. پنج برابر بدتر از این است که اصلاً یاد نگیرد، و خراب نیست.

درس، همان درس بخش utility است. learner A «احتمال اینکه اتاقی که قرار است ببینم کثیف باشد» را حداکثر کرد. performance measure «room-tickهایی که کثیف مانده‌اند» بود. عددهای متفاوت؛ دومی همان چیزی بود که critic امتیازدهی می‌کرد، و هیچ‌کس به agent نگفت. learner B همان نرخ یادگرفته‌شده را در زمان گذشته از آخرین بازدید ضرب می‌کند — خاکی که انتظار دارد پیدا کند، نه شانس پیدا کردن هر مقدار خاک — و patrolی را که از آن شروع کرده بود شکست می‌دهد.

یک جزئیات implementation نتیجه را تعیین کرد. در نسخه اول learner B، اتاقی که در سه بازدید هیچ خاکی در آن پیدا نشده بود نرخ دقیقاً صفر گرفت — و صفر ضربدر هرچیز صفر است، پس هرگز دوباره بازدید نشد و estimate هرگز نمی‌توانست اصلاح شود. smoothing کسر، موفقیت‌ها به‌علاوه یک روی تلاش‌ها به‌علاوه دو، 11,895 را به 1,576 تبدیل کرد. «هنوز مشاهده نشده» و «اندازه‌گیری شد و صفر درآمد» ادعاهای متفاوتی‌اند، و سیستمی که آن‌ها را در یک field ذخیره می‌کند تصمیم‌هایی می‌گیرد که نمی‌تواند برگرداند.

  1  simple reflex    percept ────────────────────────────────► rules ────► action
  2  model-based      percept ──► [state] ──────────────────► rules ────► action
  3  goal-based       percept ──► [state] ──► [goal] ──────► search ───► action
  4  utility-based    percept ──► [state] ──► [goal] ──► [U] ──► argmax ► action
  5  learning         all of the above, plus [critic] ──► changes the parts above

هر پنج‌تا امروز با نامی دیگر در production هستند.

دو ردیف به شکلی که پول هزینه می‌کند، از analogy نزدیک‌ترند.

chat یک model-based reflex agent است که مدلش داخلی نیست. در کتاب درسی، state متغیری داخل agent program است. در chat، transcript است: سمت شما زندگی می‌کند، در هر call کامل دوباره ارسال می‌شود، و هر بار از صفر داخل مدل بازسازی می‌شود. این همان صورت‌حساب quadratic فصل 16 است، و همان شیئی است که کتاب درسی به‌صورت جعبه‌ای با برچسب «state» کشیده بود. این تفاوت است، اندازه‌گیری‌شده روی یک پرسش پیگیری با و بدون دو پیام قبل از آن:

with the transcript      prompt=67  "The current temperature in Lisbon, Portugal is 15°C."
without the transcript   prompt=29  "Lisbon is the capital of Portugal, not a city in Portugal."

همان مدل، همان سه کلمه input کاربر، و دومی همان ربات راهروست که به دیوار می‌کوبد. در آن run هیچ toolی نبود، پس 15 اختراع شده است — اما state همان چیزی است که باعث می‌شود follow-up اصلاً معنایی داشته باشد. شما هر بار آن را بازسازی می‌کنید و برای یک مکالمه دو turnی، 2.3× input token بابتش می‌پردازید. فصل 16 اندازه گرفت این ضریب تا turn چهل به کجا می‌رسد.

Reflexion یک learning agent است که به‌جای program، input خودش را تغییر می‌دهد. در تجزیه کتاب درسی، learning element، performance element را تغییر می‌دهد. Reflexion weightها را دست‌نخورده می‌گذارد و متن reflective را در episodic buffer می‌نویسد که تلاش بعدی آن را می‌خواند.³ learning element یک prompt است، memory یک row در database، performance element یک مدل frozen — و diagram همان diagram کتاب درسی است، بدون تغییر.

و این هم حد صادقانه mapping. پنج نوع، agent program را دسته‌بندی می‌کنند. در 2026 این program از وسط دو تکه شده است: بخشی از آن کد شماست، بخشی داخل weightهایی است که شما train نکرده‌اید. وقتی یک مدل خودش تصمیم می‌گیرد toolی را call کند، goal test در program شماست یا در مدل؟ taxonomy پاسخی ندارد، چون وقتی نوشته شد جای دیگری برای آن وجود نداشت — و این پرسش دقیقاً همان‌جایی است که دو تعریف مدرن از هم جدا می‌شوند.

تعریف‌ها بحث‌هایی درباره behaviour هستند، و با یک trace جلوی چشم، قضاوت درباره‌شان بسیار آسان‌تر است.

loop زیر مکالمه را به یک مدل می‌فرستد؛ اگر reply شامل tool call باشد، tool را اجرا می‌کند، نتیجه را append می‌کند و کل چیز را دوباره می‌فرستد. روی یک Qwen2.5-0.5B-Instruct محلی پشت endpointی به شکل OpenAI روی همین ماشین اجرا می‌شود — همان درز فصل 14، پس loop نه می‌داند و نه برایش مهم است پشت port چیست.

const BASE = process.env.LLM_BASE_URL ?? "http://127.0.0.1:8799/v1";

async function loop(question: string, maxTurns = 6) {
  const messages: Msg[] = [
    { role: "system", content: SYSTEM },
    { role: "user", content: question },
  ];

  for (let turn = 1; turn <= maxTurns; turn++) {
    const reply = await call(messages, TOOLS);
    const calls = reply.choices[0].message.tool_calls ?? [];
    messages.push(reply.choices[0].message);

    if (!calls.length) return messages;                      

    for (const c of calls) {
      const out = runTool(c.function.name, JSON.parse(c.function.arguments));
      messages.push({ role: "tool", name: c.function.name, content: out });
    }
  }
  throw new Error("turn cap reached");                       
}

دو خط کل ایده را حمل می‌کنند، و هر دو علامت‌گذاری شده‌اند؛ بقیه bookkeeping است. هر سه behaviour در یک run دیده می‌شود. وقتی چیزی از آن می‌پرسید که خودش می‌تواند انجام دهد، مدل پاسخ می‌دهد. وقتی چیزی می‌پرسید که نمی‌تواند، call می‌کند:

=== a question the model cannot answer, one tool available
  turn 1  prompt= 187  out= 21  finish=tool_calls  CALL get_temperature({"city": "Oslo"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
  turn 2  prompt= 238  out= 12  finish=stop        TEXT "The current temperature in Oslo is 4
                                                        degrees Celsius."
  => model calls=2  prompt tokens=425  output=33  wall=6,257 ms
  => stopped by: the model produced text instead of a call

و متوقف می‌شود — behaviour سوم، و آسان‌ترین برای ندیدن، چون شبیه هیچ اتفاقی افتادن است. loop تمام می‌شود چون turn 2 بدون tool call برگشت. هیچ‌کس این را تصمیم نگرفت؛ مدل با تولید prose تصمیم گرفت. termination condition این program، نشانه یک absence است.

دو run دیگر ارزش جا گرفتن دارند. وقتی از آن خواسته می‌شود دو شهر را مقایسه کند، مدل هر دو tool call را در یک turn صادر می‌کند، هر دو reading را می‌گیرد، و مقایسه را اشتباه انجام می‌دهد:

  turn 1  prompt= 188  out= 43  finish=tool_calls  CALL get_temperature({"city": "Oslo"}),
                                                        get_temperature({"city": "Lisbon"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
          tool  get_temperature -> {"city":"Lisbon","celsius":19}
  turn 2  prompt= 284  out= 13  finish=stop        TEXT "Oslo is currently warmer than Lisbon
                                                        at 4°C."

toolها کار کردند. call موازی کار کرد. loop کار کرد. پاسخ غلط است، در حالی که هر دو عدد درست در transcript نشسته‌اند. پیچیدن یک مدل در loop باعث نمی‌شود reason کند؛ به مدلی که غلط است توانایی می‌دهد بر اساس غلط بودنش عمل کند — که پیشاپیش فصل 30 است، و نصف فصل 29.

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

  turn 1  prompt= 187  out= 21  CALL get_temperature({"city": "Oslo"})
  turn 2  prompt= 238  out= 12  TEXT "The current temperature in Oslo is 4 degrees Celsius."
  turn 3  prompt= 261  out= 30  TEXT "Could you please specify the exact location you're..."
  turn 4  prompt= 302  out= 14  TEXT "Sure! Could you tell me which city you're interested in?"
  turn 5  prompt= 327  out= 35  TEXT "I'm sorry, but I need more details to provide an..."
  turn 6  prompt= 373  out= 12  TEXT "Which city would you like to know the temperature for?"
  => model calls=6  prompt tokens=1,688  output=124  wall=25,261 ms  stopped by: turn cap

چهار برابر input token، چهار برابر wall clock، و پایانی که در آن agent فراموش کرده چه از او پرسیده بودند و از کاربر درباره پرسشی بازجویی می‌کند که او در turn اول پاسخ داده بود. پاسخ درست در turn 2 روی صفحه بود، و هر turn بعد از آن transcript را بدتر کرد.

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

هر دو نقل‌قول می‌شوند نه paraphrase، چون paraphraseها همان‌جایی‌اند که سردرگمی ساخته می‌شود.

تعریف اول مرز را روی این می‌گذارد که چه کسی flow را کنترل می‌کند. نوشته Anthropic با عنوان Building effective agents ابهام را نام‌گذاری می‌کند و درباره‌اش حکم می‌دهد:

«در Anthropic، ما همه این variationها را agentic systems دسته‌بندی می‌کنیم، اما یک تمایز معماری مهم بین workflowها و agentها می‌گذاریم: workflowها سیستم‌هایی هستند که در آن‌ها LLMها و toolها از طریق مسیرهای کد ازپیش‌تعریف‌شده orchestrate می‌شوند. agentها، در مقابل، سیستم‌هایی هستند که در آن‌ها LLMها به‌صورت dynamic processها و tool usage خود را هدایت می‌کنند و کنترل اینکه taskها را چگونه انجام دهند حفظ می‌کنند.»⁴

آزمون، پرسشی درباره source code شماست: چه کسی step بعدی را انتخاب کرد؟ یک switch در program شما: workflow. مدل: agent. همان سند می‌گوید agentها «معمولاً فقط LLMهایی هستند که بر اساس environmental feedback در یک loop از toolها استفاده می‌کنند» — که دقیقاً همان listing بالاست.

تعریف دوم مرز را روی استقلال از کاربر می‌گذارد. نوشته OpenAI با عنوان A practical guide to building agents صفحه تعریفی خود را این‌طور آغاز می‌کند:

«در حالی که software متعارف به کاربران امکان می‌دهد workflowها را streamline و automate کنند، agentها می‌توانند همان workflowها را با درجه بالایی از استقلال به نمایندگی از کاربران انجام دهند. agentها سیستم‌هایی هستند که taskها را مستقلانه به نمایندگی از شما انجام می‌دهند.»⁵

دو جمله بعد، در همان صفحه، این‌ها را کنار می‌گذارد:

«Applicationهایی که LLMها را integrate می‌کنند اما از آن‌ها برای کنترل workflow execution استفاده نمی‌کنند — مثلاً chatbotهای ساده، LLMهای single-turn، یا sentiment classifierها — agent نیستند.»⁵

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

زیر آن یک برخورد واژگانی هست، و در جلسه‌های واقعی بحث ایجاد می‌کند. در سند اول، workflow یک architecture است، و همان چیزی است که agent نیست. در سند دوم، workflow «sequenceای از stepهاست که باید برای رسیدن به goal کاربر اجرا شوند» — خودِ کار، که هر agent یکی از آن دارد. «ما workflow را با یک agent جایگزین کردیم» تحت تعریف اول منسجم است و تحت تعریف دوم تقریباً بی‌معنا.

سه سیستم که در 2026 وجود دارند، زیر هر دو تعریف.

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

تعریف‌ها به این دلیل برخورد می‌کنند که هرکدام دو پرسش مستقل را در یک واژه collapse می‌کند. جداشان کنید و اختلاف به یک table تبدیل می‌شود، که از یک verdict مفیدتر است.

هر تعریف روی یک cell متفاوت اختلاف دارد، و دو cell دیگر اصلاً محل اختلاف نیستند. پس وقتی label مهم است — در contract، risk review، postmortem — دو جمله‌ای که ارزش نوشتن دارند «آیا agent است» نیستند، بلکه چه کسی step بعدی را انتخاب کرد و چه کسی تماشا می‌کرد هستند. هر دو با خواندن کد answerable هستند، هیچ‌کدام به تعریف کسی نیاز ندارند، و با هم همه پیامدهایی را حمل می‌کنند که label قرار بود نماینده‌شان باشد.

هیچ‌کدام از این‌ها جدید نیست. Wooldridge و Jennings در 1995 کاربردهای رقیب «agent» را بررسی کردند؛⁶ Franklin و Graesser در 1996 پرسش همین فصل را پرسیدند، تعریف‌های در گردش را گرد آوردند و دیدند که با هم اختلاف دارند.⁷ یک survey در 2023 هنوز agentها را از اصول اولیه تعریف می‌کند — «موجودیت‌های مصنوعی که environment خود را sense می‌کنند، decision می‌گیرند و action انجام می‌دهند»⁸ — چون چیز تثبیت‌شده‌ای وجود نداشت که به آن cite شود، و CoALA به‌جای کشیدن مرز، اجزا را توصیف می‌کند.⁹ سی سال خودداری از توافق می‌گوید این واژه بیش از یک کار انجام می‌دهد.

حالا پیامدی که قبل از فلسفه می‌رسد: صورت‌حساب.

هر measurement اینجا یک شکل دارد. call منفرد 39 input token هزینه داشت؛ همان پرسش با یک tool، طی دو call، 420 هزینه داشت؛ loopی که stopping rule آن حذف شد، طی شش call، 1,688 هزینه داشت. رشد بدتر از خطی است، چون turn n هر turn قبلی را همراه خود دارد: ستون prompt در آن run شش turnی این بود: 187، 238، 261، 302، 327، 373. فصل 16 نتیجه گرفت که total برابر $\Theta(n^2)$ است و curve را روی یک مکالمه واقعی fit کرد. یک agent هر task را به آن مکالمه تبدیل می‌کند، چه انسانی هرگز آن را ببیند چه نبیند.

اگر آن token countهای اندازه‌گیری‌شده به endpoint تجاری با نرخ‌هایی می‌رفتند که فصل 16 در 6 سپتامبر 2026 خواند — $2.00 برای هر یک میلیون input token و $12.00 برای هر یک میلیون output — چهار run این‌طور قیمت‌گذاری می‌شدند:

ردیف دو نسبت به ردیف یک، عددی است که باید نگه داشت. هفت‌ونیم برابر هزینه، برای پاسخی بدتر به پرسشی که مدل از قبل می‌دانست. هیچ چیزی misconfigured نبود: tool وجود داشت، پس مدل از آن استفاده کرد — و یافته فصل 18، اینکه قیمت یک catalogue و نه accuracy آن است که آسیب می‌زند، ارزان‌ترین نمایش خود را اینجا با catalogueی تک‌عضوی دارد.

به همین دلیل نیمه مفید هر دو سند همان نیمه‌ای است که درباره نساختن این صحبت می‌کند. سند Anthropic صریح است: ساده‌ترین راه‌حل ممکن را پیدا کنید و complexity را فقط وقتی لازم است اضافه کنید، که «ممکن است یعنی اصلاً agentic system نسازید»، چون agentic systemها «latency و cost را با performance بهتر task معاوضه می‌کنند» و «برای بسیاری از applicationها، معمولاً optimise کردن single LLM callها با retrieval و in-context example کافی است».⁴ مورد آن به نفع agent محدود است: مسئله‌های open-ended که نمی‌توانید تعداد stepها را پیش‌بینی کنید و نمی‌توانید path را hardcode کنید، در environmentی که به آن اعتماد دارید، با پذیرش «هزینه‌های بالاتر، و احتمال compounding errorها».⁴ صفحه OpenAI تصویر آینه‌ای است — judgement پیچیده، rule setهای غیرقابل‌نگهداری، داده unstructured — و همان‌طور تمام می‌شود: «در غیر این صورت، یک deterministic solution ممکن است کافی باشد».⁵

پس، در taxonomy این فصل: تعداد ثابت stepها در ترتیب ثابت یک pipeline است، و agent نامیدنش سریع‌ترش نمی‌کند. اگر تعداد stepها به چیزی بستگی دارد که در مسیر پیدا می‌کنید، یک loop می‌خواهید — و این flexibility را با N call، transcriptی quadratic، و سیستمی می‌خرید که می‌تواند به‌جای یک بار، N بار غلط باشد.

حالا taxonomy، هر دو تعریف مدرن، دو محوری که آن‌ها را سازگار می‌کند، و loop کوتاهی را دارید که پاسخ می‌دهد، call می‌کند و می‌ایستد.

آن loop یک راه برای پایان دارد: مدل دیگر درخواست tool نمی‌کند. فصل 23 آن را عمداً هفت بار می‌شکند، و هر شکست یک تکه اضافه می‌کند. taskی ناممکن، و هرگز تمام نمی‌شود — turn cap. یک شب اجرا، و صورت‌حساب می‌رسد — budget به دلار. toolی که fail می‌شود — errorی که مدل می‌تواند بر اساسش عمل کند. همان call دو بار — idempotency key. فایلی که نباید به آن دست می‌زد — human approval. restart در میانه — session persistence. toolی که سه دقیقه در سکوت طول می‌کشد — progress و cancellation. خروجی، یک harness است؛ فایلی که بقیه این دوره روی آن اجرا می‌شود.

این، پرسشی را باقی می‌گذارد که قطر مورد اختلاف این فصل واقعاً درباره‌اش بود. loopی که step بعدی خودش را انتخاب می‌کند باید تصمیم بگیرد چه زمانی متوقف شود، و ما تازه دیدیم وقتی نتواند چه می‌شود: شش turn، چهار برابر صورت‌حساب، و agentی که از کاربر درباره پرسشی بازجویی می‌کند که خودش قبلاً پاسخ داده بود. توقف یک condition نیست. چندتاست، و کدام‌یک اول fire می‌شود؟

نوشته Lilian Weng با عنوان LLM Powered Autonomous Agents (2023) شناخته‌شده‌ترین تجزیه یک language agent به planning، memory و tool use است، و در کنار دو سند vendor بهترین خواندن بعدی است؛ سه component آن به‌ترتیب فصل‌های 23، 24 و 18 این دوره‌اند.

هر عدد در این فصل روی همین ماشین تولید شد و هیچ‌چیز estimate نشد. راهرو، floor plan، چهار agentی که در آن راه می‌روند و سه patrol policy همان TypeScript بالاست، اجراشده روی Node 22؛ اعداد agent تصادفی‌شده میانگین‌هایی روی 2,000 run seedشده برای هرکدام هستند و اعداد patrol، runهای single seedشده 4,000 tickی‌اند. traceهای مدل از Qwen2.5-0.5B-Instruct در float32 روی CPU با greedy decoding می‌آیند، که از طریق loopback توسط endpoint کوچک محلی Python سرو شده؛ endpointی که weightها را load می‌کند و به شکل OpenAI chat-completions حرف می‌زند — همان درز دوباره، با tensorها در سمت Python و loop در سمت TypeScript — پس token countها از tokenizer همان مدل‌اند و latencyها از همان ماشین. تنها اعدادی که از جای دیگر گرفته شده‌اند دو قیمت در جدول هزینه‌اند، که نرخ‌هایی هستند که فصل 16 در 6 سپتامبر 2026 از صفحه pricing OpenAI خواند، و اینجا به‌عنوان illustration روی token countهای محلی اندازه‌گیری‌شده اعمال شده‌اند، نه به‌عنوان invoice مشاهده‌شده.