Finance Agent

自然言語の株式に関する質問を、カスタムMCPサーバー（yfinanceクオンツツール）とニュースツールの間でルーティングするLangGraphエージェント。手作りの評価セットで検証済み。

MCPサーバーの設計（ツールサーフェス、説明をルーティングロジックとして使う方法）と、ルーティング判断を伴うエージェントオーケストレーションという2つのスキルギャップを埋めるために構築。

アーキテクチャ

User Query
    │
    ▼
┌─────────┐
│  route  │  3-way classifier: quant / news / both
└────┬────┘
     │
     ├──────────────────────┬─────────────────────
     ▼                      ▼
┌─────────┐           ┌──────────┐
│  quant  │           │   news   │
│ (ReAct) │           │  (ReAct) │
└────┬────┘           └────┬─────┘
     │                     │
     └──────────┬───────────┘
                │
        ┌───────┴────────┐
        │                │
        ▼                ▼
┌──────────────┐   ┌───────────┐
│finish_single │   │ synthesize│
│   _source    │   │           │
└──────┬───────┘   └─────┬─────┘
       │                 │
       └────────┬─────────┘
                ▼
             Answer

ノード:

• route — クエリを分類。ツール呼び出しは行わず、判断のみ

• quant — 5つのMCPツールを持つReActエージェント。質問に適したツールを選択

• news — get_recent_news を持つReActエージェント。ニュース/コンテキストに関する質問を処理

• finish_single_source — 単一パスのクエリ用パススルー。結果を answer に昇格

• synthesize — quantとnewsの出力を1つの一貫した回答に統合（"both"クエリ用）

"both" クエリの場合、quant と news は並行して実行され、LangGraphは両方が完了するまで待機してから synthesize を実行します。

Related MCP server: Yahoo Finance MCP Server

MCPサーバー — クオンツツール

各ツールは単一の質問形状にスコープされた5つのツール:

ツールの説明には明示的な否定ケース（「X用ではない、Yに属する」）が含まれています。これは、複数のツールが類似したパラメータ形状を共有しており、そうでなければルーターにとって曖昧になるためです。

セットアップ

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env  # add your ANTHROPIC_API_KEY

使用方法

python -m agent.graph "What's Tesla's P/E ratio?"
python -m agent.graph "Why did NVDA drop this week?"
python -m agent.graph "Has AMZN's stock kept pace with its revenue growth?"

評価

pytest evals/test_agent.py -v

4つのカテゴリ（quant、news、both、adversarial）にわたる18のクエリ。Adversarialケースには、キーワードトラップ（quantの質問を包むニュース言語）と誤った前提のクエリ（説明する前に検証が必要な価格変動に関する主張）が含まれます。

結果: 15/18 → 18/18 — 2つの壊れやすいティッカー文字列アサーションを修正し、ルータープロンプトに誤った前提の分類ルールを追加した後。

主要な設計判断

1. ツール説明をルーティングロジックとして使用。 すべてのツール説明は、扱わないものを明示的に述べています。否定ケースがないと、パラメータ形状が重複するツール（例: get_stock_price と get_price_history_stats はどちらもティッカーと日付のようなパラメータを取る）はLLMルーターにとって曖昧になります。

2. ニュースはプレーンなLangGraphツールであり、2つ目のMCPサーバーではない。 直感は「2つ目のMCPサーバー = 再利用可能なビルディングブロック」でした。それに対して問い詰めました: 何のために再利用可能なのか？具体的な2番目の消費者は存在しませんでした。2つ目のMCPサーバーは、起動と管理が必要な2つ目のサブプロセスを意味します。プレーンな @tool は単一のインプロセス関数です。プロセス境界のオーバーヘッドには、それに見合う利点がありませんでした。

3. ルーターは意図を分類し、エージェントがツールを選択。 ルーターは3方向の分類のみを行います — どのquantツールを呼び出すかは選択しません。LLMによるツール選択（クエリを5つのツール説明の1つにマッチング）は柔軟で非決定的な作業であり、quant ReActループ内に属し、ルータープロンプトに複製すべきではありません。

4. 統合は連結ではなく調整でなければならない。 統合プロンプトは、quantデータとニュースコンテキストを1つの一貫した回答に結び付けるようモデルに明示的に指示します。「両方を別々に列挙するのではなく、それらを結び付けてください。」これがないと、"both"パスは、実際の回答ではなく、2つの段落がステープルで留められたものになります。