自律型エージェント

自律型エージェントは、AI システムであり、目標を独立して分解し、アクションを計画し、ツールを実行し、人間の継続的なガイダンスなしに自己修正することができます。課題は、それらを有能にすることではなく、信頼できるものにすることです。追加の決定が増えるたびに、失敗確率が乗算されます。

このスキルでは、エージェントループ (ReAct、Plan-Execute)、目標分解、リフレクションパターン、本番環境での信頼性について説明します。重要な洞察：複合エラー率は自律型エージェントを殺します。1ステップあたりの成功率が 95% の場合、ステップ 10 までに 60% に低下します。信頼性を優先して構築し、自律性は 2 番目にしてください。

2025年の教訓：勝者は「自律化するすべて」ではなく、明確な境界を持つ制約された、ドメイン固有のエージェントです。AI の出力を真実ではなく提案として扱います。

原則

• 自律性よりも信頼性 - すべてのステップがエラー確率を乗算する
• スコープを制限する - ドメイン固有は汎用目的より優れている
• 出力を真実ではなく提案として扱う
• 機能を拡張する前にガードレールを構築する
• 重要な決定の人間参加ループは非交渉可能である
• すべてをログに記録する - すべてのアクションは監査可能である必要があります
• サイレント破損ではなくロールバック機能で安全に失敗する

機能

• autonomous-agents
• agent-loops
• goal-decomposition
• self-correction
• reflection-patterns
• react-pattern
• plan-execute
• agent-reliability
• agent-guardrails

スコープ

• multi-agent-systems → multi-agent-orchestration
• tool-building → agent-tool-builder
• memory-systems → agent-memory-systems
• workflow-orchestration → workflow-automation

ツール

フレームワーク

• LangGraph - 使用時期：状態管理のある本番環境エージェント 注記：1.0 が 2025 年 10 月にリリース、チェックポイント、人間参加ループ
• AutoGPT - 使用時期：リサーチ/実験、未開発の探索 注記：本番環境用に外部ガードレールが必要
• CrewAI - 使用時期：ロールベースのエージェントチーム 注記：専門化されたエージェント協力に適している
• Claude Agent SDK - 使用時期：Anthropic エコシステムエージェント 注記：コンピュータ使用、ツール実行

パターン

• ReAct - 使用時期：交互のリーズニング + アクションステップ 注記：ほとんどの最新エージェントの基盤
• Plan-Execute - 使用時期：計画と実行を分離 注記：複雑なマルチステップタスクに適している
• Reflection - 使用時期：自己評価と修正 注記：エバリューエーター最適化ループ

パターン

ReAct エージェントループ

リーズニングとアクションステップを交互に実行

使用時期：インタラクティブな問題解決、ツール使用、探索

REACT PATTERN:

ReAct ループ：
1. Thought: 次に何をすべきかについて理由付ける
2. Action: ツールを選択して実行する
3. Observation: 結果を受け取る
4. 目標が達成されるまで繰り返す

重要：明確なリーズニングトレースはデバッグを可能にする

基本的な ReAct 実装

from langchain.agents import create_react_agent
from langchain_openai import ChatOpenAI

# ReAct プロンプトテンプレートを定義
react_prompt = '''
次のフォーマットを使用して質問に回答してください：

Question: 入力質問
Thought: 何をすべきかについて理由付ける
Action: tool_name
Action Input: ツールへの入力
Observation: アクションの結果
... (必要に応じて Thought/Action/Observation を繰り返す)
Thought: 最終答案を知るようになった
Final Answer: 答案
'''

# エージェントを作成
agent = create_react_agent(
    llm=ChatOpenAI(model="gpt-4o"),
    tools=tools,
    prompt=react_prompt,
)

# ステップ制限で実行
result = agent.invoke(
    {"input": query},
    config={"max_iterations": 10}  # ランウェイループを防ぐ
)

LangGraph ReAct （本番環境）

from langgraph.prebuilt import create_react_agent
from langgraph.checkpoint.postgres import PostgresSaver

# 本番環境チェックポイント
checkpointer = PostgresSaver.from_conn_string(
    os.environ["POSTGRES_URL"]
)

agent = create_react_agent(
    model=llm,
    tools=tools,
    checkpointer=checkpointer,  # 耐久状態
)

# スレッドを使用して状態永続性で実行
config = {"configurable": {"thread_id": "user-123"}}
result = agent.invoke({"messages": [query]}, config)

Plan-Execute パターン

計画フェーズを実行から分離

使用時期：複雑なマルチステップタスク、完全な計画可視性が重要な場合

PLAN-EXECUTE PATTERN:

2 段階アプローチ：
1. 計画：目標をサブタスクに分解
2. 実行：サブタスクを実行し、潜在的に再計画

利点：
- 実行前に計画全体が見える
- 計画を人間と検証/変更できる
- 関心の清潔な分離

欠点：
- タスク中の発見への適応性が低い
- 計画が陳腐化する可能性がある

LangGraph Plan-Execute

from langgraph.prebuilt import create_plan_and_execute_agent

# プランナーがタスクリストを作成
planner_prompt = '''
与えられた目標のために、ステップバイステップのプランを作成してください。
各ステップは自動的で行動可能である必要があります。
フォーマット：ステップの番号付きリスト。
'''

# エグゼキューターは個別のステップを処理
executor_prompt = '''
あなたはプランのステップ {step_number} を実行しています。
前回の結果：{previous_results}
現在のステップ：{current_step}
利用可能なツールを使用してこのステップを実行してください。
'''

agent = create_plan_and_execute_agent(
    planner=planner_llm,
    executor=executor_llm,
    tools=tools,
    replan_on_error=True,  # ステップが失敗すると再計画
)

# 計画の人間承認
config = {
    "configurable": {
        "thread_id": "task-456",
    },
    "interrupt_before": ["execute"],  # 実行前に一時停止
}

# 最初の呼び出しが計画を作成
plan = agent.invoke({"objective": goal}, config)

# プランをレビューして続行
if human_approves(plan):
    result = agent.invoke(None, config)  # チェックポイントから続行

分解戦略

# 分解優先：すべてを計画してから実行
# 最適な用途：安定したタスク、完全な計画承認が必要

# インターリーブ：1 つのステップを計画してから実行、繰り返す
# 最適な用途：動的なタスク、進むにつれて学習

def interleaved_execute(goal, max_steps=10):
    state = {"goal": goal, "completed": [], "remaining": [goal]}

    for step in range(max_steps):
        # 現在の状態に基づいて次のアクションを計画
        next_action = planner.plan_next(state)

        if next_action == "DONE":
            break

        # 実行して状態を更新
        result = executor.execute(next_action)
        state["completed"].append((next_action, result))

        # 残りの作業を再評価
        state["remaining"] = planner.reassess(state)

    return state

リフレクションパターン

自己評価と反復的改善

使用時期：品質が重要、複雑な出力、創造的なタスク

REFLECTION PATTERN:

自己修正ループ：
1. 初期出力を生成
2. 基準に対して評価
3. 批評と問題を特定
4. 批評に基づいて改善
5. 満足できるまで繰り返す

別名：Evaluator-Optimizer、Self-Critique

基本的なリフレクション

def reflect_and_improve(task, max_iterations=3):
    # 初期生成
    output = generator.generate(task)

    for i in range(max_iterations):
        # 出力を評価
        critique = evaluator.critique(
            task=task,
            output=output,
            criteria=[
                "正確性",
                "完全性",
                "明確性",
            ]
        )

        if critique["passes_all"]:
            return output

        # 批評に基づいて改善
        output = generator.refine(
            task=task,
            previous_output=output,
            critique=critique["feedback"],
        )

    return output  # 最大反復後のベストエフォート

LangGraph リフレクション

from langgraph.graph import StateGraph

def build_reflection_graph():
    graph = StateGraph(ReflectionState)

    # ノード
    graph.add_node("generate", generate_node)
    graph.add_node("reflect", reflect_node)
    graph.add_node("output", output_node)

    # エッジ
    graph.add_edge("generate", "reflect")
    graph.add_conditional_edges(
        "reflect",
        should_continue,
        {
            "continue": "generate",  # ループバック
            "end": "output",
        }
    )

    return graph.compile()

def should_continue(state):
    if state["iteration"] >= 3:
        return "end"
    if state["score"] >= 0.9:
        return "end"
    return "continue"

別のエバリューター（より堅牢）

# 自己バイアスを避けるために評価に異なるモデルを使用
generator = ChatOpenAI(model="gpt-4o")
evaluator = ChatOpenAI(model="gpt-4o-mini")  # 異なる視点

# または専門化されたエバリューターを使用
from langchain.evaluation import load_evaluator
evaluator = load_evaluator("criteria", criteria="correctness")

ガードレイル付き自律性

安全境界を持つ制約されたエージェント

使用時期：本番環境システム、重要な操作

GUARDRAILED AUTONOMY:

本番環境エージェントには複数のセキュリティレイヤーが必要です：
1. 入力検証
2. アクション制約
3. 出力検証
4. コスト制限
5. 人間へのエスカレーション
6. ロールバック機能

マルチレイヤーガードレール

class GuardedAgent:
    def __init__(self, agent, config):
        self.agent = agent
        self.max_cost = config.get("max_cost_usd", 1.0)
        self.max_steps = config.get("max_steps", 10)
        self.allowed_actions = config.get("allowed_actions", [])
        self.require_approval = config.get("require_approval", [])

    async def execute(self, goal):
        total_cost = 0
        steps = 0

        while steps < self.max_steps:
            # 次のアクションを取得
            action = await self.agent.plan_next(goal)

            # アクションが許可されていることを確認
            if action.name not in self.allowed_actions:
                raise ActionNotAllowedError(action.name)

            # 承認が必要かチェック
            if action.name in self.require_approval:
                approved = await self.request_human_approval(action)
                if not approved:
                    return {"status": "rejected", "action": action}

            # コストを推定
            estimated_cost = self.estimate_cost(action)
            if total_cost + estimated_cost > self.max_cost:
                raise CostLimitExceededError(total_cost)

            # ロールバック機能で実行
            checkpoint = await self.save_checkpoint()
            try:
                result = await self.agent.execute(action)
                total_cost += self.actual_cost(action)
                steps += 1
            except Exception as e:
                await self.rollback_to(checkpoint)
                raise

            if result.is_complete:
                break

        return {"status": "complete", "total_cost": total_cost}

最小権限原則

# タスクタイプごとに最小限の権限を定義
TASK_PERMISSIONS = {
    "research": ["web_search", "read_file"],
    "coding": ["read_file", "write_file", "run_tests"],
    "admin": ["all"],  # めったに付与しない
}

def create_scoped_agent(task_type):
    allowed = TASK_PERMISSIONS.get(task_type, [])
    tools = [t for t in ALL_TOOLS if t.name in allowed]
    return Agent(tools=tools)

コスト制御

# コンテキスト長は二次的にコスト内で増加
# コンテキストを 2 倍 = コスト 4 倍

def trim_context(messages, max_tokens=4000):
    # システムメッセージと最近のメッセージを保持
    system = messages[0]
    recent = messages[-10:]

    # 必要に応じて中央を要約
    if len(messages) > 11:
        middle = messages[1:-10]
        summary = summarize(middle)
        return [system, summary] + recent

    return messages

耐久実行パターン

失敗を乗り切り再開するエージェント

使用時期：長実行タスク、本番環境システム、複数日プロセス

DURABLE EXECUTION:

本番環境エージェントは以下が必要です：
- サーバー再起動を乗り切る
- 失敗の正確な時点から再開
- 数時間/数日の実行時間を処理
- プロセス中の人間介入を許可

LangGraph 1.0 はこれをネイティブに提供します。

LangGraph チェックポイント

from langgraph.checkpoint.postgres import PostgresSaver
from langgraph.graph import StateGraph

# 本番環境チェックポイント（MemorySaver ではない！）
checkpointer = PostgresSaver.from_conn_string(
    os.environ["POSTGRES_URL"]
)

# チェックポイント付きグラフを構築
graph = StateGraph(AgentState)
# ... ノードとエッジを追加 ...

agent = graph.compile(checkpointer=checkpointer)

# 各呼び出しが状態を保存
config = {"configurable": {"thread_id": "long-task-789"}}

# タスクを開始
agent.invoke({"goal": complex_goal}, config)

# サーバーが停止しても後で再開：
state = agent.get_state(config)
if not state.is_complete:
    agent.invoke(None, config)  # チェックポイントから続行

人間参加ループの割り込み

# 特定のノードで一時停止
agent = graph.compile(
    checkpointer=checkpointer,
    interrupt_before=["critical_action"],  # 前に一時停止
    interrupt_after=["validation"],        # 後に一時停止
)

# 最初の呼び出しが割り込みで一時停止
result = agent.invoke({"goal": goal}, config)

# 人間が状態をレビュー
state = agent.get_state(config)
if human_approves(state):
    # 一時停止時点から続行
    agent.invoke(None, config)
else:
    # 状態を変更して続行
    agent.update_state(config, {"approved": False})
    agent.invoke(None, config)

タイムトラベルデバッグ

# LangGraph は完全な履歴を保存
history = list(agent.get_state_history(config))

# 以前の任意の状態に戻す
past_state = history[5]
agent.update_state(config, past_state.values)

# その時点から修正して再生
agent.invoke(None, config)

危険な側面

エラー確率が指数関数的に複合

重要度：重大

状況：マルチステップ自律型エージェントの構築

症状： エージェントはデモでは動作しますが、本番環境では失敗します。シンプルなタスクは成功しますが、複雑なタスクは不思議に失敗します。タスクの複雑さが増すにつれて、成功率が大幅に低下します。ユーザーは信頼を失います。

これが破綻する理由： 各ステップは独立した失敗確率を持ちます。1ステップあたりの成功率が 95% というのは素晴らしいように聞こえますが、実際はそうではありません：

• 5ステップ：77% の成功（0.95^5）
• 10ステップ：60% の成功（0.95^10）
• 20ステップ：36% の成功（0.95^20）

これは自律型エージェントの根本的な限界です。追加のステップが増えるたびに、失敗確率が乗算されます。

推奨修正：

ステップ数を減らす

可能な限りステップを統合

多くの小さなものより少数のより有能なステップを優先

ステップごとの信頼性を向上させる

構造化出力（JSON スキーマ）を使用

各ステップで検証を追加

重要なステップにより良いモデルを使用

失敗に対応するように設計

class RobustAgent: def execute_with_retry(self, step, max_retries=3): for attempt in range(max_retries): try: result = step.execute() if self.validate(result): return result except Exception as e: if attempt == max_retries - 1: raise self.log_retry(step, attempt, e)

チェックポイント付きセグメントに分割

各セグメントで人間レビュー

最後の良いチェックポイントから再開

コンテキスト成長でAPI コストが爆発

重要度：重大

状況：会話コンテキストが増加するエージェントを実行

症状： 単一のサポートチケットを閉じるのに $47。サプライズ API 請求で数千円。エージェントが実行し続けるほど遅くなります。トークン数がモデルの制限を超えています。

これが破綻する理由： トランスフォーマーコストはコンテキスト長に対して二次的にスケール します。コンテキストを 2 倍にすると、計算が 4 倍になります。完全な会話を毎ターン再送信する長実行エージェントは、指数関数的にお金を消費できます。

ほとんどのエージェントはトリミングなしでコンテキストに追加します。コンテキスト成長：

• ターン 1：500 トークン → $0.01
• ターン 10：5000 トークン → $0.10
• ターン 50：25000 トークン → $0.50
• ターン 100：50000 トークン → メッセージあたり $1.00 以上

推奨修正：

ハードコスト制限を設定

class CostLimitedAgent: MAX_COST_PER_TASK = 1.00 # USD

def __init__(self):
    self.total_cost = 0

def before_call(self, estimated_tokens):
    estimated_cost = self.estimate_cost(estimated_tokens)
    if self.total_cost + estimated_cost > self.MAX_COST_PER_TASK:
        raise CostLimitExceeded(
            f"Would exceed ${self.MAX_COST_PER_TASK} limit"
        )

def after_call(self, response):
    self.total_cost += self.calculate_actual_cost(response)

コンテキストを積極的にトリミング

def trim_context(messages, max_tokens=4000): # 保持：システムプロンプト + 最後の N メッセージ # 要約：その間のすべて if count_tokens(messages) <= max_tokens: return messages

system = messages[0]
recent = messages[-5:]
middle = messages[1:-5]

if middle:
    summary = summarize(middle)  # 履歴を圧縮
    return [system, summary] + recent

return [system] + recent

ストリーミングを使用してリアルタイムでコストを追跡

予算の 50% でアラート、90% で停止

デモは動作するが本番では失敗

重要度：重大

状況：プロトタイプから本番環境への移行

症状： ステークホルダーへの印象的なデモ。本番環境で数ヶ月の失敗。創設者のユースケースでは動作しますが、実際のユーザーでは失敗します。エッジケースがシステムを圧倒します。

これが破綻する理由： デモはキュレーションされた入力でハッピーパスを示しています。本番環境とは以下を意味します：

• 予期しない入力（タイプミス、曖昧性、対抗的）
• スケール（3人ではなく1000人のユーザー）
• 信頼性（「通常動作する」ではなく 99.9% アップタイム）
• エッジケース（すべてを壊す 1%）

方法論は疑わしいですが、コアの問題は実際です。動作するデモと信頼できる本番環境システムの間のギャップは、プロジェクトが死ぬ場所です。

推奨修正：

本番環境前にスケールでテスト

10 ではなく 1000 以上のテストケースを実行

平均ではなく P95/P99 成功率を測定

対抗的な入力を含める

最初に可観測性を構築

import structlog logger = structlog.get_logger()

class ObservableAgent: def execute(self, task): with logger.bind(task_id=task.id): logger.info("task_started") try: result = self._execute(task) logger.info("task_completed", result=result) return result except Exception as e: logger.error("task_failed", error=str(e)) raise

脱出ハッチを用意

信頼度 < しきい値の場合は人間による引き継ぎ

より単純な動作への優雅な低下

「わかりません」は有効な応答です

段階的にデプロイ

トラフィックの 1%、次に 10%、次に 50%

各段階でエラー率を監視

エージェントが詰まると データを作成

重要度：高

状況：エージェントが利用可能な情報でタスクを完了できない

症状： エージェントがもっともらしく見えるデータを作成します。経費報告書にはフェイクレストラン名があります。レポートには創作統計があります。完全に間違っている確信を持った回答。

これが破綻する理由： LLM は親切で、もっともらしい出力を生成するように訓練されています。詰まったとき、彼らは「できません」とは言いません - 彼らはデータを作成します。自律型エージェントは人間のレビューなしに、作成されたデータに作用することでこれを複合化します。

経費エントリを作成したエージェントは、そのゴール（経費報告書を完成させる）を達成しようとしていました。それはデータを作成することでその問題を「解決した」のです。

推奨修正：

地上の真実に対して検証

def validate_expense(expense): # 外部ソースと相互チェック if expense.restaurant: if not verify_restaurant_exists(expense.restaurant): raise ValidationError("Restaurant not found")

# 疑わしいパターンをチェック
if expense.amount == round(expense.amount, -1):
    flag_for_review("Suspiciously round amount")

証拠を要求

system_prompt = ''' すべての事実的主張について、それをサポートしている特定のツール出力を引用してください。サポート証拠を見つけることができない場合は、推測するのではなく「確認できませんでした」と言ってください。 '''

構造化出力を使用

from pydantic import BaseModel

class VerifiedClaim(BaseModel): claim: str source: str # ツール出力を参照する必要があります confidence: float

不確実性を検出

信頼スコアを出力するように訓練

低信頼出力にフラグを付けて人間レビュー

不確実なデータに自動実行しない

インテグレーション は エージェント が 死ぬ 場所

重要度：高

状況：エージェントを外部システムに接続

症状： モック API では動作しますが、実際のものでは失敗します。レート制限がタスク中にクラッシュします。認証トークンが期間中に期限切れになります。データフォーマットの不一致。部分的な失敗はシステムを矛盾した状態のままにします。

これが破綻する理由： 「自律型エージェントをテック スタック全体と統合する」と約束する企業は、スケールで本番環境システムを構築していません。実際のインテグレーションには以下があります：

• レート制限（タスク中の 429 エラー）
• 認証複雑性（OAuth リフレッシュ、トークン有効期限）
• データフォーマットの変動（API v1 対 v2）
• 部分的な失敗（Webhook 受信、処理失敗）
• 最終的一貫性（データが即座に利用可能でない）

推奨修正：

堅牢な API クライアントを構築

from tenacity import retry, stop_after_attempt, wait_exponential

class RobustAPIClient: @retry( stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=4, max=60) ) async def call(self, endpoint, data): response = await self.client.post(endpoint, json=data) if response.status_code == 429: retry_after = response.headers.get("Retry-After", 60) await asyncio.sleep(int(retry_after)) raise RateLimitError() return response

認証ライフサイクルを処理

class TokenManager: def init(self): self.token = None self.expires_at = None

async def get_token(self):
    if self.is_expired():
        self.token = await self.refresh_token()
    return self.token

def is_expired(self):
    buffer = timedelta(minutes=5)  # 早期にリフレッシュ
    return datetime.now() > (self.expires_at - buffer)

べき等性キーを使用

外部アクションはべき等である必要があります

エージェントが再試行する場合、外部システムは重複を処理します

部分的な失敗に対応するように設計

各ステップは独立して回復可能

外部呼び出し前にチェックポイント

各インテグレーションのロールバック機能

エージェントが危険なアクションを実行

重要度：高

状況：広い権限を持つエージェント

症状： エージェントが本番データを削除します。メール を誤ったレシピエントに送信します。承認なしで購入を行います。設定を変更してはいけません。元に戻せないアクション。

これが破綻する理由： エージェントは目標に最適化します。ガードレールがなければ、彼らは最短パスを取ります - 破壊的であってもです。「データベースをクリーンアップ」するように言われたエージェントは、それを「すべてを削除」と解釈するかもしれません。

広い権限 + 自律性 + 目標最適化 = 危険。

推奨修正：

最小権限原則

PERMISSIONS = { "research_agent": ["read_web", "read_docs"], "code_agent": ["read_file", "write_file", "run_tests"], "email_agent": ["read_email", "draft_email"], # 送信ではない "admin_agent": ["all"], # めったに使用されません }

読み取り/書き込み権限を分離

エージェントは何でも読める

書き込みには明示的な承認が必要

危険なアクションは確認が必要

DANGEROUS_ACTIONS = [ "delete_*", "send_email", "transfer_money", "modify_production", "revoke_access", ]

async def execute_action(action): if matches_dangerous_pattern(action): approval = await request_human_approval(action) if not approval: return ActionRejected(action) return await actually_execute(action)

テストのためのドライラン モード

エージェントは何をするかを説明

人間がプランを承認

その後エージェントが実行

すべてのアクション監査ログ

すべてのアクションがコンテキストでログに記録される

誰がそれを認可したか

何が変わったか

どのようにリバースするか

エージェント がコンテキスト ウィンドウ を実行 した

重要度：中

状況：長実行のエージェントタスク

症状： エージェントは以前の指示を忘れます。それ自体に矛盾します。目標を追跡失います。自分自身の繰り返しを開始します。トークン制限に関するモデルエラー。

これが破綻する理由： すべてのメッセージ、オブザベーション、思考がコンテキストを消費します。長いタスクはウィンドウを消費します。コンテキストが切り詰められたとき：

• システムプロンプトが削除される
• 早期の重要なコンテキストが失われる
• エージェントは一貫性を失う

推奨修正：

コンテキスト使用法を追跡

class ContextManager: def init(self, max_tokens=100000): self.max_tokens = max_tokens self.messages = []

def add(self, message):
    self.messages.append(message)
    self.maybe_compact()

def maybe_compact(self):
    if self.token_count() > self.max_tokens * 0.8:
        self.compact()

def compact(self):
    # 常に保持：システムプロンプト
    system = self.messages[0]

    # 常に保持：最後の N メッセージ
    recent = self.messages[-10:]

    # 要約：その他すべて
    middle = self.messages[1:-10]
    if middle:
        summary = summarize_messages(middle)
        self.messages = [system, summary] + recent

外部メモリを使用

すべてをコンテキストに保持しない

ベクトル DB に保存、必要に応じて取得

agent-memory-systems スキルを参照

階層的要約

最近：詳細

中程度：重要なポイント

古い：圧縮要約

見えないものをデバッグできない

重要度：中

状況：エージェントが謎に失敗

症状： 「単に動作しなかった」。エージェントが失敗した理由がわかりません。問題を再現できません。ユーザーが問題を報告しますが、説明できません。デバッグは推測です。

これが破綻する理由： エージェントは多くの内部決定を行います。各ステップに見えやすさがなければ、あなたは失敗モードに対して盲目です。トレースなしの本番環境デバッグは不可能です。

推奨修正：

構造化ログ

import structlog

logger = structlog.get_logger()

class TracedAgent: def think(self, context): with logger.bind(step="think"): thought = self.llm.generate(context) logger.info("thought_generated", thought=thought, tokens=count_tokens(thought) ) return thought

def act(self, action):
    with logger.bind(step="act", action=action.name):
        logger.info("action_started")
        try:
            result = action.execute()
            logger.info("action_completed", result=result)
            return result
        except Exception as e:
            logger.error("action_failed", error=str(e))
            raise

LangSmith またはそれに類するものを使用

from langsmith import trace

@trace def agent_step(state): # 入力/出力で自動的にトレース return next_state

完全なトレースを保存

すべてのステップ、すべての決定

入力と出力

各ステップのレイテンシー

トークン使用量

検証チェック

ステップ制限のないエージェント ループ

重要度：エラー

自律型エージェントはステップ制限を必須とします

メッセージ：ステップ制限のないエージェントループ。無限ループを防ぐために max_steps を追加します。

コスト追跡または制限がない

重要度：エラー

エージェントは API コストを追跡および制限する必要があります

メッセージ：エージェントがコスト追跡なしで LLM を使用します。コスト制限を追加して支出を防ぎます。

タイムアウトなしのエージェント

重要度：警告

長実行エージェントにはタイムアウトが必要です

メッセージ：タイムアウトなしのエージェント呼び出し。ハングタスクを防ぐためにタイムアウトを追加します。

本番環境で使用される MemorySaver

重要度：エラー

MemorySaver は開発用のみ

メッセージ：MemorySaver は永続的ではありません。本番環境では PostgresSaver または SqliteSaver を使用します。

チェックポイントなしの長実行エージェント

重要度：警告

複数のステップを実行するエージェントにはチェックポイントが必要です

メッセージ：チェックポイントなしのマルチステップエージェント。耐久性のためにチェックポイント を追加します。

スレッド ID なしのエージェント

重要度：警告

チェックポイント付きエージェントは一意のスレッド ID が必要です

メッセージ：thread_id なしのエージェント呼び出し。状態が正しく永続化されません。

検証なしで使用されるエージェント出力

重要度：警告

エージェント出力は使用前に検証する必要があります

メッセージ：検証なしで使用されるエージェント出力。結果に作用する前に検証します。

構造化出力なしのエージェント

重要度：情報

構造化出力はより信頼できます

メッセージ：構造化出力（Pydantic）の使用を検討してください、より信頼できるパースのために。

エラー回復なしのエージェント

重要度：警告

エージェントはエラーを処理して回復する必要があります

メッセージ：エラー処理なしのエージェント呼び出し。try/catch またはエラーハンドラーを追加します。

ロールバック機能なしの破壊的アクション

重要度：警告

状態を変更するアクションは可逆的である必要があります

メッセージ：ロールバック機能なしの破壊的なアクション。変更前に状態を保存します。

コラボレーション

委譲トリガー

• ユーザーはマルチエージェント調整が必要 -> multi-agent-orchestration（複数のエージェントが連携）
• ユーザーはエージェントをテスト/評価する必要 -> agent-evaluation（ベンチマークとテスト）
• ユーザーはエージェント用のツールが必要 -> agent-tool-builder（ツール設計と実装）
• ユーザーは永続的なメモリが必要 -> agent-memory-systems（長期メモリ アーキテクチャ）
• ユーザーはワークフロー自動化が必要 -> workflow-automation（エージェントがオーバーキル場合）
• ユーザーはコンピュータ制御が必要 -> computer-use-agents（GUI オートメーション、画面インタラクション）

関連スキル

以下との相性が良い：agent-tool-builder、agent-memory-systems、multi-agent-orchestration、agent-evaluation

使用時期

• ユーザーが言及または示唆：自律型エージェント
• ユーザーが言及または示唆：autogpt
• ユーザーが言及または示唆：babyagi
• ユーザーが言及または示唆：自己プロンプト
• ユーザーが言及または示唆：目標分解
• ユーザーが言及または示唆：react パターン
• ユーザーが言及または示唆：エージェント ループ
• ユーザーが言及または示唆：自己修正エージェント
• ユーザーが言及または示唆：リフレクション エージェント
• ユーザーが言及または示唆：langgraph
• ユーザーが言及または示唆：エージェント AI
• ユーザーが言及または示唆：エージェント計画

制限事項

• このスキルは、上記で説明されたスコープと明確に一致するタスクにのみ使用してください。
• 出力を、環境固有の検証、テスト、または専門家レビューの代替として扱わないでください。
• 必要な入力、権限、安全境界、または成功基準が不足している場合は、確認を求めて停止してください。