エージェントとワークフロー：本当にエージェントが必要か先に考える

「エージェント」はここ数年で最も熱い言葉の一つです。何でもエージェントにしないと先進的でないかのようです。

手を動かす前に、一つの問いをはっきりさせておきましょう。あなたのタスクに本当にエージェントが必要でしょうか。この課ではまずエージェントとワークフローをはっきり区別し、次に実験で両者のコストがどれだけ違うかを見て、最後に判断のためのチェックリストを示します。

両者の違い

RepoBot v2 が質問に答える過程を振り返りましょう。質問を書き換える、ドキュメントを検索する、ドキュメントと質問をモデルに渡して答えさせる。この三つのステップはコードに固定で書かれていて、順番は決まっており、毎回同じです。モデルが担当するのは、そのうち二つのステップの具体的な中身だけです。どんな語に書き換えるか、何と答えるか。これをワークフロー（workflow）と呼びます。

エージェント（agent）は違います。目標と一組のツールだけを与え、次に何をするかはモデルが決めます。まず検索し、結果がおかしければ語を変えてもう一度検索するかもしれません。一つのファイルを読み、足りないと思えば別のファイルを読むかもしれません。情報が十分だと思えば、そのまま答えるかもしれません。ステップの数も順番も、前もってはわかりません。

工作流：                          智能体：
  改写问题（固定）                   ┌─▶ 模型决定：下一步做什么？
     ▼                             │       │
  检索文档（固定）                   │   ┌───┴───┬────────┬────────┐
     ▼                             │  搜索   读文件   列目录    回答 ──▶ 结束
  回答（固定）                       │   │       │        │
                                   └───┴───────┴────────┘

両者の間にはっきりした境界線はありません。ワークフローの中で、あるステップで「検索するかどうか」をモデルに決めさせれば、それだけでもうエージェントらしさが少しあります。もっと実用的な問い方は、制御権を誰が握っているかです。制御権をモデルに渡すほど、システムは柔軟になり、同時に予測しにくくなります。

実験：同じ質問を二つのやり方で

モジュール 04 の RAG の流れ（書き換え、ハイブリッド検索、引用つきの回答）と、次の課で書くエージェント（grep_docs、read_doc、list_docs で自分でドキュメントを調べることを決める）に、同じ三つの質問に答えさせます。コードは code/05-agents/workflow_vs_agent.py にあります。私が実行した結果です（途中にあるのはエージェントの各ステップの軌跡です）。

问：httpx 默认会自动跟随重定向吗？
  固定流程：1 次回答调用，2.2 秒，输入 831 词元，输出 109 词元
    不会。与 `requests` 不同，HTTPX 默认不跟随重定向 [1]。默认情况下，HTTPX 对所有 HTTP 方法都不会跟随重定向 [2]。
[第 1 步] grep_docs({"keyword": "follow_redirects"}) → compatibility.md:19: response = client.get(url, follow_redirects=True) | compatibility.md:
[第 1 步] grep_docs({"keyword": "redirect"}) → advanced/transports.md:178: Or this example, which uses a custom transport and `httpx.Moun
[第 2 步] read_doc({"path": "compatibility.md", "start": 8, "end": 30}) → 8: ## Redirects | 9:  | 10: Unlike `requests`, HTTPX does **not follow redirects by defaul
[第 2 步] read_doc({"path": "quickstart.md", "start": 430, "end": 445}) → 430: [] | 431: >>> r.next_request | 432: <Request('GET', 'https://github.com/')> | 433: ``
  智能体：  3 次调用，3.8 秒，输入 3261 词元，输出 457 词元
    **不会。httpx 默认不自动跟随重定向。**

问：怎么给 httpx 设置代理？
  固定流程：1 次回答调用，3.7 秒，输入 1550 词元，输出 518 词元
    可以，以下是文档中提到的几种设置代理的方式。
（智能体的轨迹省略）
  智能体：  4 次调用，5.8 秒，输入 6756 词元，输出 732 词元
    httpx 设置代理主要有三种方式：

问：httpx 的超时分成哪几种？每种管什么？
  固定流程：1 次回答调用，2.6 秒，输入 991 词元，输出 208 词元
    httpx 的超时分为四种：**connect**、**read**、**write** 和 **pool** [1]。
（智能体的轨迹省略）
  智能体：  3 次调用，4.1 秒，输入 3731 词元，输出 546 词元
    httpx 的超时一共分成 **四种**（依据 `advanced/timeouts.md:45-61`）：

（固定のワークフローは回答の 1 回の呼び出しだけを集計しています。質問の書き換えの呼び出し結果はすでにキャッシュされていました。）

どちらのやり方も三問すべてに正解しました。しかしエージェントは 1 問あたり 3～4 回モデルを呼び出し、入力トークンは固定のワークフローのおよそ 4 倍で、時間も 1～2 秒多くかかりました。

理由はわかりやすいものです。エージェントは各ステップで、それまでのすべてのステップを送り直さなければなりません。第 1 ステップで grep の結果を読めば、第 2 ステップの入力にはそれが含まれます。第 2 ステップで二つのファイルを読めば、第 3 ステップの入力にはその二つのファイルの内容が含まれます。ステップが多いほど、入力は長くなります。

こうした「事実を一つ調べる」質問では、1 回の検索で答えが見つかるので、エージェントの柔軟さには出番がなく、余分なお金と時間だけが残ります。

エージェントのコスト

• 高く、遅い。何度も呼び出し、コンテキストが一歩ごとに長くなります。
• 予測できない。同じ質問でも、今回は 3 ステップ、次は 6 ステップかかるかもしれません。今回は正しいファイルを調べても、次は間違った方向にどんどん進んでいくかもしれません。
• テストとデバッグが難しい。ワークフローなら各ステップの入力と出力が決まっていて、単独でテストできます。エージェントの問題は実行の軌跡をたどらないと見つかりません。
• リスクが大きい。モデルが自分でツールの呼び出しを決められるので、ツールがデータを変更したり、メッセージを送ったり、お金を使ったりできるなら、一つの誤った判断や一回の攻撃の成功（第 8 課）が実際の結果をもたらします。

エージェントの価値

エージェントを使う価値があるのは、ステップを前もって決められないタスクです。

• 何を調べるかが、前のステップで何が見つかったかによって決まる。たとえばエラーの調査。まずエラーメッセージを見て、それをもとに対応するソースコードを探し、さらにソースコードをもとに関係する設定を探す。
• いくつもの方法を試す必要があるかもしれない。最初の検索で見つからなければ、キーワードを変え、場所を変えてもう一度探す。
• タスクの形が千差万別で、それぞれに固定のワークフローを書くことができない。たとえばコーディングアシスタント。ユーザーはバグの修正、機能の追加、テストの作成、ドキュメントの修正を頼むかもしれません。

RepoBot v2 は「既定では最大何回までリダイレクトに従うか」に答えられません。答えがドキュメントになく、ソースコードにしかないからです。「ドキュメントを検索して答える」という固定の流れは、「ドキュメントになければソースコードを探す」ことが本質的にできません。ここにこそエージェントが必要で、第 9 課で作ります。

判断のためのチェックリスト

新しい機能を作る前に、順番に自問してください。

1. 1 回のモデル呼び出しでうまくできるか？ 多くのタスクは、よく書けたプロンプトと適切な資料があれば十分です。できるなら、そこで考えるのをやめましょう。
2. ステップを前もって固定で書けるか？ 固定のフローチャート（A の次に B、X なら C）を描けるなら、コードでワークフローとして書きます。各ステップでモデルを呼んでもかまいませんが、流れを制御するのはあなたのコードです。
3. 途中の結果に応じて次のステップを決めなければならないか？ そうであり、しかも場合が多すぎて一つずつ分岐に書けないときに、初めてエージェントを検討します。
4. 間違えたときの代償を受け入れられるか？ エージェントは間違えます。そのツールはどんな結果をもたらしうるのか。危険な操作を先に人に確認させる方法はあるか。
5. コストと遅延を受け入れられるか？ エージェントのタスク 1 回は、ワークフローの何倍もの費用と時間がかかるかもしれません。

実用的な戦略は、まずワークフローとして作り、それで扱えない場合が出てきたら、その部分だけをエージェントに任せることです。たとえば RepoBot は、まず固定の RAG の流れで進め、検索結果が「ドキュメントにない」ことを示したときだけ、ソースコードを調べられるエージェントを起動する、という形にできます。

よくある誤解

「ツール呼び出しを使えば、エージェントだ」。モジュール 03 第 3 課のプログラムもツール呼び出しを使っていましたが、「モデルがバージョンを調べたければ 1 回調べる」だけで、流れはとても固定的でした。ツールがあるかどうかは本質ではなく、本質はステップがモデルによって動的に決められるかどうかです。

「エージェントのほうが高度だから、効果もよい」。この課の実験では、三問とも固定のワークフローとエージェントの両方が正解しましたが、エージェントは 4 倍のお金を使いました。ステップが固定のタスクでは、エージェントがより正確になることはなく、高く、遅く、予測しにくくなるだけです。

「まず何でもできる汎用エージェントを作ろう」。ツールが多く、タスクが広いほど、モデルはツールを選び間違え、方向を誤りやすくなります。実際のプロジェクトでより確実なのは、一つのエージェントは一種類のタスクだけを担当し、与えるツールもその種類のタスクに関係するものだけにすることです。

練習問題

1. workflow_vs_agent.py に質問を一つ加えてください。「httpx は既定で最大何回までリダイレクトに従いますか？」（答えはソースコードにあり、ドキュメントには書かれていません）。二つのやり方はそれぞれどう答えるでしょうか。
2. 仕事で行っているタスクを一つ思い浮かべ（顧客のチケット処理、週報の作成など）、この課のチェックリストに沿って考え、結論を書き留めてください。1 回の呼び出し、ワークフロー、エージェントのどれを使うか。なぜか。この問題に正解はありません。

確認テスト

1. ワークフローとエージェントの根本的な違いは何ですか？

制御権を誰が握っているかです。ワークフローではステップと順番がコードに固定で書かれ、モデルは各ステップの具体的な中身だけを担当します。エージェントでは目標とツールだけを与え、次に何をするかはモデル自身が決め、ステップの数も順番も前もってはわかりません。

2. 同じ質問に答えるのに、エージェントの入力トークンがワークフローの何倍にもなるのはなぜですか？

エージェントはモデルを何度も呼び出し、そのたびにそれまでのすべてのステップ、つまりツール呼び出しの要求と返ってきた結果を持っていく必要があります。ステップが多いほど各ステップの入力が長くなり、合計すると 1 回の呼び出しよりずっと多くなります。

3. どんなタスクならエージェントを使う価値がありますか？

ステップを前もって決められないタスクです。次に何をするかが前のステップの結果によって決まり、何度も試す必要があるかもしれず、場合が多すぎて固定の分岐として一つずつ書けないものです。1 回の呼び出しや固定の流れでうまくできるタスクには、エージェントを使うべきではありません。