AI agentとは何か：古典的な5タイプと、競合する2つの定義

この分野で最も古い例は、AとBという2つのマスからなる世界の掃除機です。それぞれのマスは clean か dirty のどちらかです。¹ どの教科書にも残っているのは、agentが正しいか間違っているかを判定できる最小の世界だからです。

perceptはペアです。自分がどこにいるか、ここが汚れているか。そしてactionは SUCK、LEFT、RIGHT です。プログラム全体は1行です。

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";   

2マス世界のすべての開始状態に対して実行します。

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だけに基づいて行動し、それ以前の記憶を一切持ちません。おもちゃの分類ではありません。サーモスタットはこれですし、会話履歴を付けない言語モデルへの単発呼び出しもこれです。

では、現実がそうするように壊してみます。実際の掃除ロボットには汚れセンサーとバンパーがありますが、カーペットの下に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

同じプログラム、2つのマス。ある開始状態では3ステップで終わります。別の開始状態では右側の壁に500回突っ込み、バッテリーが切れるまで続けるでしょう。2つの状況の違いをperceiveできないので、それらに対して違う行動を取れません。RussellとNorvigは一般的な結果を1行で述べています。部分観測可能な環境では、simple reflex agentにとって無限ループはしばしば避けられません。¹

1行で直せる修正があります。記憶も不要です。もっと賢いものに手を伸ばす前に、測る価値があります。

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

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

すべて汚れた廊下を3つのサイズで2,000回実行し、全体で1つのseeded generatorを使いました。

ランダム化はループを完全に取り除きます。同時にコストもかかります。やるべきことが分かっていれば8部屋は15手で済みますが、このagentは平均68.7手、最大で306手かかりました。これが本章全体の縮図です。追加するすべての能力は、前のagentが扱えなかったケースで正しさを買います。そしてその代金は、まず名前を付けなければならない通貨で請求されます。

agent は sensor を通じて環境をperceiveし、actuator を通じて行動します。agent program はperceptからactionへの関数です。上のすべてのリストがそれです。percept sequence はこれまでにperceiveしたすべてであり、simple reflex agentは最後の項目以外をすべて無視します。

合理性 は、ほとんどの記事が間違える言葉です。ここを正しく押さえると、この章の残りが使えるものになります。agentはそれ自体で合理的または非合理的なのではありません。RussellとNorvigは、合理的agentを、可能な各percept sequenceについて、そのsequenceの証拠と、agentが持つ組み込み知識を前提に、performance measure を最大化すると期待されるactionを選ぶもの、と定義しています。¹ performance measureはagentの中にあるのではありません。設計者に属します。そして合理性は、それに対して相対的にしか定義されません。

仕様は慣例的に4つのもの、PEAS として書かれます。performance measure、environment、actuators、sensorsです。

どの行が仲間外れかに注目してください。2026年にagentを作っているほぼすべてのチームは、E、A、Sを書きます。ツールスキーマ、integration、メッセージ形式です。コードはそれなしでは動かないからです。Pを書く人はほとんどいません。それがなければ、「うちのagentはうまくやっている」には誰も検証できる意味がありませんし、「合理的」はシステムにはまったく適用できず、デモにしか適用できません。第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

タスク環境はさらに7つの軸で分類されます。そのうちここで難しさの大半を決めるのは5つです。完全観測可能か部分観測可能か、決定論的かそうでないか、episodicかsequentialか、staticかdynamicか、knownかunknownかです。¹ 実ネットワーク越しに実ツールと話すagentは、この5つすべてで難しい側にいます。temperature zeroでも非決定論的であり（第17章）、過小評価されがちな点として unknown です。なぜなら、自分のツールが世界に何をするかについて、信頼できるモデルを持っていないからです。だから第23章のループには、planningよりもerror handlingが必要になります。

現実の床は1次元ではないので、世界を見取り図に昇格させます。ハッシュは壁、アスタリスクは汚れ、ロボットは中央の部屋から始まります。

        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履歴から内部状態を維持するので、現在見えていないものに基づいて行動できます。

これは本物の改善ですが、それでも十分ではありません。

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

5,000手動いても、床の半分を一度も見ていません。地図は正しく、ルールも正しい。agentにできないのは、どこかへ行くために地図を使うことです。ルールが答えられるのは常に「4つの隣のどれに踏み込むべきか」だけなので、隣に未訪問のマスがなくなると、8手先に未訪問のマスがあり、私はそこに立ちたい という考えを表現する方法がありません。自分がどこにいるかは知っています。どこにいたいかは知りません。

goal-based agent は、世界のモデルに加えて、実現したい状況の記述を持ちます。そして、そこに到達するsequenceを見つけるまでaction sequenceを探索して、actionを選びます。goalはaction選択をlookupからsearchへ変えます。

goalは「汚れたマスが残っていない」です。searchは最も近い汚れたマスまでのbreadth-first walkで、返ってくる経路が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

27手で床は clean になります。しかしバッテリー列とplanの最後の脚を見てください。列0はカーペット敷きです。カーペットのマスを横切るにはバッテリー6単位、タイルのマスなら1単位かかります。agentは列0を上って帰りました。8手ではなく4手だからです。しかしその4手のカーペット移動は24かかり、8手の迂回なら13で済みました。

agentには他の選択ができません。goalは binary なテストです。床が clean か、そうでないか。cleanな床で終わるplanはすべて等しくgoalを満たすので、複数が成功すると、agentにはそれらを選び分けるものがありません。ある成功を別の成功より好むには、結果に対する数値が必要です。その数値が utility function です。それを最大化するagentが utility-based agent です。

コードの変更は、search内の1項だけです。breadth-first searchは手数を数えます。それにcostを数えさせれば、Dijkstraのアルゴリズムになり、別の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

4手余分に動き、バッテリーは11単位少なく済みました。21パーセント安い。goalも地図も同じで、コードも1項を除いて同じです。2つのagentの違いは、何をうまくやろうとしているかだけであり、帰り道が変わります。

ここは、agentが自分では作れないものを必要とする最初の地点でもあります。誰かが、1単位のバッテリーが1手に対してどれだけの価値を持つかを決めなければなりません。utilityは、agentが計算できる形で書かれたperformance measureです。そしてそれを書くのは設計者の仕事です。人々がagentが「間違ったものを最適化した」と言うとき、ほとんどの場合それはbugを意味しません。この行が不用意に書かれた、という意味です。

今度は汚れが戻ってくるようにします。4つの部屋が4つの異なる速度で再び汚れ、agentにはその速度が知らされません。agentは1 tickに1部屋を訪れ、その部屋だけを見ます。performance measureは4,000 tickの間に部屋がdirtyで過ごしたroom-ticksです。低いほど良い。

教科書の分解では、learning agent は上記のどれかに3つの部品を足したものです。agentを変える learning element、固定されたperformance standardに対してagentがどうしているかを伝える critic、そして学べることのために試す価値のあるactionを提案する problem generator です。¹ 同じ環境で3つのpolicy。1つ目は学習せず、2つ目と3つ目は同じものを学び、それを違う形で使います。

隠れたrateは、kitchenが0.35、hallが0.05、studyが0.02、atticが0.01でした。そしてlearner Aはそれを見つけました。家でいちばん汚い部屋がkitchenだと正しく特定し、その後のsimulationの残りすべてのtickでkitchenへ行きました。その間、他の3部屋は永遠にdirtyのままです。まったく学習しない場合より5倍悪く、しかも壊れてはいません。

教訓はutilityの節と同じです。learner Aは「これから訪れる部屋がdirtyである確率」を最大化しました。performance measureは「dirtyで過ごしたroom-ticks」でした。異なる数値です。criticがscoreしていたのは後者であり、誰もagentにそれを伝えていませんでした。learner Bは同じ学習済みrateに、前回訪問からの時間を掛けます。何かを見つける確率ではなく、見つかると期待される汚れです。そして出発点だったpatrolに勝ちます。

結果を決めたのは1つの実装詳細でした。learner Bの最初のバージョンでは、3回訪問して一度も汚れが出なかった部屋のrateは正確にゼロになりました。そしてゼロに何を掛けてもゼロなので、その部屋は二度と訪問されず、推定値は修正できませんでした。分数をsmoothingし、successes plus one over trials plus twoにしただけで、11,895が1,576になりました。「まだ観測されていない」と「測定した結果ゼロだった」は異なる主張です。それらを同じfieldに保存するシステムは、取り消せないdecisionを下します。

  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

5つはすべて、今日、本番環境で別の名前のもとに存在しています。

2つの行は、単なる類推より近い関係にあり、その近さはお金がかかる形で現れます。

chatは、modelが内部にないmodel-based reflex agentです。 教科書では、stateはagent program内の変数です。chatでは、それはtranscriptです。あなた側に存在し、毎回の呼び出しで全体が再送され、モデル内で毎回ゼロから再構築されます。それが第16章の二次関数的な請求であり、教科書が「state」と書かれた箱として描いたのと同じ対象です。違いを、直前の2メッセージがある場合とない場合の1つのfollow-up questionで測るとこうなります。

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."

同じモデル、同じ3語のuser input。そして2つ目は、廊下ロボットが壁に突っ込む場合です。この実行にはツールがなかったので15は捏造です。しかしstateこそが、follow-upに意味を持たせています。あなたはそれを毎回再構築し、2ターンの会話でそのために2.3倍のinput tokenを払います。第16章では、その倍率が40ターン目にどこまで達するかを測りました。

Reflexionは、programではなくinputを変えるlearning agentです。 教科書の分解では、learning elementはperformance elementを変更します。Reflexionは重みをそのままにし、次の試行が読むepisodic bufferにreflective textを書きます。³ learning elementはprompt、memoryはdatabase row、performance elementはfrozen modelです。そして図は教科書のものから変わりません。

そして、ここが対応づけの正直な限界です。5つのタイプは agent program を分類します。2026年、そのprogramは真ん中で割れています。一部はあなたのコードであり、一部はあなたが訓練していない重みの中にあります。モデルが自分でツールを呼ぶことを決めるとき、goal testはあなたのprogram内にあるのでしょうか、それともモデル内にあるのでしょうか。分類法は答えを持ちません。書かれた当時、それが存在し得る場所は他になかったからです。そしてその問いこそが、2つの現代的定義が分かれる場所です。

定義は振る舞いについての議論であり、traceを目の前に置くとはるかに判断しやすくなります。

下のloopは会話をモデルへ送り、replyにtool callが含まれていればツールを実行し、結果を追加して全体をもう一度送ります。このmachine上のOpenAI型endpointの背後にあるlocal Qwen2.5-0.5B-Instructに対して動きます。第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");                       
}

2行が全体の考え方を担っており、どちらも印を付けてあります。残りはbookkeepingです。1回の実行で3つの振る舞いすべてが見えます。自分でできることを聞かれると、モデルは 答えます。できないことを聞かれると、呼びます。

=== 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

そして 止まります。3つ目の振る舞いであり、最も見落としやすいものです。何も起きていないように見えるからです。turn 2がtool callなしで戻ってきたのでloopは終わります。誰かがそう決めたのではありません。モデルがproseを出力することで決めました。このprogramのtermination conditionは、不在のしるしです。

あと2つの実行にも紙幅を割く価値があります。2つの都市を比較するよう頼まれると、モデルは1ターンで 両方の tool callを発行し、両方の値を受け取り、比較を間違えます。

  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."

ツールは動きました。parallel callも動きました。loopも動きました。答えは false で、正しい2つの数値はどちらも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は4倍、wall clockも4倍。そして結末では、agentは何を聞かれたのか忘れ、ユーザーがturn 1で答えた質問についてユーザーを尋問しています。正しい答えはturn 2で画面に出ていました。それ以降のすべてのturnは、transcriptを悪化させました。

だからagentはloopではありません。loop に、それを抜けるルールを足したもの です。そしてこのloopには、そのルールが正確に1つだけあります。第23章では5つ見つけ、それぞれが欠けると何が壊れるかを示します。

言い換えではなく引用します。混乱が作られるのは、言い換えの側だからです。

定義1は、誰がflowを制御するかに境界を置きます。 Anthropicの Building effective agents は曖昧さに名前を付け、判断を下しています。

「Anthropicでは、これらすべてのvariationをagentic systemsとして分類していますが、workflowsとagentsの間に重要なarchitecture上の区別を置いています。Workflowsは、LLMsとツールが事前定義されたコードパスを通じてorchestrateされるシステムです。一方Agentsは、LLMsが自分自身のprocessとツール使用を動的に指揮し、taskをどのように達成するかについて制御を維持するシステムです。」⁴

テストはあなたのソースコードについての問いです。次のステップを選んだのは誰か。 program内の switch ならworkflow。モデルならagent。同じ文書は、agentsは「通常、environmental feedbackに基づいてloop内でツールを使うLLMsにすぎない」と述べています。これは上のlistingそのものです。

定義2は、ユーザーからの独立性に境界を置きます。 OpenAIの A practical guide to building agents は、定義ページをこう始めています。

「従来のsoftwareは、ユーザーがworkflowsを効率化し自動化することを可能にしますが、agentsは高い独立性をもって、ユーザーに代わって同じworkflowsを実行できます。Agentsは、あなたに代わって独立してtaskを達成するシステムです。」⁵

同じページの2文後で、これは除外されます。

「LLMsを組み込んでいるが、workflow executionを制御するために使っていないapplications――simple chatbots、single-turn LLMs、sentiment classifiersのようなもの――はagentsではありません。」⁵

これらの引用を順に読んでください。冒頭の文は 独立性 で線を引いています。これは私なしでどこかへ行き、仕事を終わらせるのか。4つ目は executionの制御 で線を引いています。これはAnthropicの線そのものです。同じページに異なるテストがあります。そして実際に、その2つで判定が分かれるシステムが存在します。

その下には語彙の衝突があり、実際の会議で議論を引き起こします。1つ目の文書では、workflow はarchitectureであり、agent ではない ものです。2つ目では、workflow は「ユーザーのgoalを満たすために実行されなければならない一連のstep」です。つまり仕事そのものであり、すべてのagentが持つものです。「workflowをagentに置き換えた」は1つ目の定義では筋が通り、2つ目ではほとんど無意味です。

2026年に存在する3つのシステムを、両方の定義で見ます。

3つのうち2つは側が変わります。これはどちらかの文書の失敗ではありません。ある種の会議への警告です。2人が、システムが何をするかについて完全に合意しているのに、それを何と呼ぶかで1時間対立するような会議です。

定義が衝突するのは、それぞれが2つの独立した問いを1語に畳み込んでいるからです。分ければ、不一致は表になります。判定よりも表の方が役に立ちます。

各定義は異なるcellに異議を唱えており、他の2つはまったく争われていません。だからlabelが重要なとき――契約、risk review、postmortem――書く価値のある2つの文は「agentか」ではなく、次のstepを選んだのは誰か と 誰が見ていたのか です。どちらもコードを読めば答えられます。誰かの定義は要りません。そして2つを合わせると、そのlabelが代わりに担っていたすべての帰結を運べます。

これは新しい話ではありません。WooldridgeとJenningsは1995年に「agent」の競合する意味をsurveyしました。⁶ FranklinとGraesserは1996年に本章の問いを立て、当時流通していた定義を集め、それらが一致しないことを見つけました。⁷ 2023年のsurveyも、agentsを第一原理から定義しています――「環境をsenseし、decisionを下し、actionを取る人工的entity」⁸――引用できる合意済みの現代的定義が存在しなかったからです。そしてCoALAは境界を引くのではなく、部品を記述しています。⁹ 30年間合意を避けてきたということは、この言葉が複数の仕事をしているということです。

哲学より先に到着する帰結、つまり請求です。

ここでのすべての測定は同じ形をしています。単発呼び出しは39 input token。同じ質問に1つのツールを付けると、2回の呼び出し合計で420。同じloopからstopping ruleを外すと、6回で1,688。増え方は線形より悪いです。turn n はそれ以前のすべてのturnを運ぶからです。その6ターン実行のprompt列は187、238、261、302、327、373です。第16章は合計が $\Theta(n^2)$ であることを導き、実際の会話で曲線をfitしました。agentは、人間が見るかどうかにかかわらず、すべてのtaskをその会話に変えます。

これらの測定token数が、第16章が2026年9月6日に読んだ商用endpointの料金――input token 100万あたり$2.00、output 100万あたり$12.00――に送られていたなら、4つの実行の価格はこうなります。

2行目を1行目と比べた数字を覚えておくべきです。モデルがすでに知っていた質問に対して、悪い答えを得るために7.5倍のcost。 設定ミスはありませんでした。ツールが存在したので、モデルがそれを使っただけです。そして第18章の発見、つまり害になるのはカタログの正確性ではなくカタログの価格だという点は、ここでは1つだけのカタログによって最も安く示されています。

だからこそ、両方の文書で有用なのは「これを作らない」話をしている半分です。Anthropicは率直です。可能な最も単純な解決策を見つけ、必要なときだけ複雑性を足せ、と述べています。それは「agentic systemsをまったく作らないことを意味するかもしれない」。agentic systemsは「より良いtask performanceと引き換えにlatencyとcostを払う」ものであり、「多くのapplicationsでは、retrievalとin-context examplesで単一のLLM呼び出しを最適化するだけで通常は十分」だからです。⁴ agentを支持するcaseは狭いものです。step数を予測できず、pathをhardcodeできないopen-ended problemsで、信頼できるenvironmentにおいて、「より高いcostと、compounding errorsの可能性」を受け入れる場合です。⁴ OpenAIのscreenはその鏡像です。複雑なjudgement、保守不能なrule set、unstructured data。そして同じ結論で終わります。「そうでなければ、deterministic solutionで十分かもしれない」。⁵

したがって本章のtaxonomyでは、固定数のstepを固定順で実行するものはpipelineであり、agentと呼んでも速くはなりません。step数が途中で見つけたものに依存するなら、欲しいのはloopです。そしてそのflexibilityは、N回の呼び出し、二次関数的なtranscript、そして1回ではなくN回間違え得るシステムと引き換えに買います。

これで、taxonomy、2つの現代的定義、それらを両立させる2つの軸、そして答え、呼び、止まる短いloopを手にしました。

そのloopが終わる方法は1つです。モデルがツールを求めるのをやめること。第23章では、それを意図的に7回壊し、各破壊が1つの部品を追加します。不可能なtaskで、終わらない――turn cap。夜通し走って、請求が来る――ドル建てbudget。ツールが失敗する――モデルが対処できるerror。同じcallが2回――idempotency key。触るべきでなかったfile――human approval。途中でrestart――session persistence。3分間黙っているツール――progressとcancellation。出てくるのはharnessです。このcourseの残りがその上で動くfileです。

残るのは、本章の争点だった対角線が本当に扱っていた問いです。自分で次のstepを決めるloopは、いつ止まるかも決めなければなりません。そして止められないと何が起きるかを、私たちは今見ました。6ターン、4倍の請求、そしてすでに答えた質問についてユーザーを尋問するagent。停止は1つの条件ではありません。いくつあり、どれが最初に発火するのでしょうか。

Lilian Wengの LLM Powered Autonomous Agents (2023) は、language agentをplanning、memory、tool useに分解したものとして最もよく知られており、2つのvendor documentsと並べて読む次の資料として適しています。その3 componentsは、このcourseの第23章、第24章、第18章にこの順で対応します。

この章のすべての数値はこのmachine上で生成され、推定はありません。廊下、floor plan、それを歩く4つのagents、3つのpatrol policiesは上のTypeScriptであり、Node 22上で実行しました。randomized agentの数値はそれぞれ2,000 seeded runsのmeanであり、patrol figuresは4,000 ticksのsingle seeded runsです。model tracesはCPU上float32の Qwen2.5-0.5B-Instruct から来ています。weightsをloadしOpenAI chat-completions shapeを話す小さなlocal Python endpointによってloopback上でserveされました。ここでも同じ継ぎ目です。tensorはPython側、loopはTypeScript側です。したがってtoken countsはそのモデルのtokenizerによるもので、latenciesはそのmachineのものです。外部から取った唯一の数値はcost tableの2つのpriceであり、第16章が2026年9月6日にOpenAIのpricing pageから読んだratesです。ここではlocally measured token countsに適用したillustrationであり、実際のinvoiceとして観測されたものではありません。