Merge branch 'main' into log-tool-errors

Author: danilbogdan

.github/workflows/tests.yml

@@ -22,6 +22,8 @@ jobs:
           enable-cache: true
       - name: Install dependencies
         run: make sync
+      - name: Verify formatting
+        run: make format-check
       - name: Run lint
         run: make lint
 
@@ -41,6 +43,16 @@ jobs:
 
   tests:
     runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
+      matrix:
+        python-version:
+          - "3.10"
+          - "3.11"
+          - "3.12"
+          - "3.13"
+          # TODO: enable this https://github.com/openai/openai-agents-python/pull/1961/
+          # - "3.14"
     env:
       OPENAI_API_KEY: fake-for-tests
     steps:
@@ -50,6 +62,7 @@ jobs:
         uses: astral-sh/setup-uv@v5
         with:
           enable-cache: true
+          python-version: ${{ matrix.python-version }}
       - name: Install dependencies
         run: make sync
       - name: Run tests with coverage
@@ -71,7 +84,7 @@ jobs:
       - name: Build docs
         run: make build-docs
 
-  old_versions:
+  old_version_tests:
     runs-on: ubuntu-latest
     env:
       OPENAI_API_KEY: fake-for-tests

.github/workflows/update-docs.yml

@@ -19,6 +19,7 @@ on:
       - mkdocs.yml
       - '!docs/ja/**'
       - '!docs/ko/**'
+      - '!docs/zh/**'
 
 permissions:
   contents: write

README.md

@@ -1,4 +1,4 @@
-# OpenAI Agents SDK
+# OpenAI Agents SDK [![PyPI](https://img.shields.io/pypi/v/openai-agents?label=pypi%20package)](https://pypi.org/project/openai-agents/)
 
 The OpenAI Agents SDK is a lightweight yet powerful framework for building multi-agent workflows. It is provider-agnostic, supporting the OpenAI Responses and Chat Completions APIs, as well as 100+ other LLMs.
 

docs/context.md

@@ -68,6 +68,51 @@ if __name__ == "__main__":
 4. The context is passed to the `run` function.
 5. The agent correctly calls the tool and gets the age.
 
+---
+
+### Advanced: `ToolContext`
+
+In some cases, you might want to access extra metadata about the tool being executed — such as its name, call ID, or raw argument string.  
+For this, you can use the [`ToolContext`][agents.tool_context.ToolContext] class, which extends `RunContextWrapper`.
+
+```python
+from typing import Annotated
+from pydantic import BaseModel, Field
+from agents import Agent, Runner, function_tool
+from agents.tool_context import ToolContext
+
+class WeatherContext(BaseModel):
+    user_id: str
+
+class Weather(BaseModel):
+    city: str = Field(description="The city name")
+    temperature_range: str = Field(description="The temperature range in Celsius")
+    conditions: str = Field(description="The weather conditions")
+
+@function_tool
+def get_weather(ctx: ToolContext[WeatherContext], city: Annotated[str, "The city to get the weather for"]) -> Weather:
+    print(f"[debug] Tool context: (name: {ctx.tool_name}, call_id: {ctx.tool_call_id}, args: {ctx.tool_arguments})")
+    return Weather(city=city, temperature_range="14-20C", conditions="Sunny with wind.")
+
+agent = Agent(
+    name="Weather Agent",
+    instructions="You are a helpful agent that can tell the weather of a given city.",
+    tools=[get_weather],
+)
+```
+
+`ToolContext` provides the same `.context` property as `RunContextWrapper`,  
+plus additional fields specific to the current tool call:
+
+- `tool_name` – the name of the tool being invoked  
+- `tool_call_id` – a unique identifier for this tool call  
+- `tool_arguments` – the raw argument string passed to the tool  
+
+Use `ToolContext` when you need tool-level metadata during execution.  
+For general context sharing between agents and tools, `RunContextWrapper` remains sufficient.
+
+---
+
 ## Agent/LLM context
 
 When an LLM is called, the **only** data it can see is from the conversation history. This means that if you want to make some new data available to the LLM, you must do it in a way that makes it available in that history. There are a few ways to do this:

docs/ja/agents.md

@@ -4,16 +4,16 @@ search:
 ---
 # エージェント
 
-エージェントはアプリの中核となる構成要素です。エージェントは、指示とツールで構成された大規模言語モデル（ LLM ）です。
+エージェントはアプリの中核となる基本コンポーネントです。エージェントは、instructions と tools で構成された大規模言語モデル（ LLM ）です。
 
 ## 基本構成
 
-エージェントで最も一般的に設定するプロパティは次のとおりです。
+よく設定するエージェントのプロパティは以下のとおりです。
 
--   `name`: エージェントを識別する必須の文字列です。
--   `instructions`: developer メッセージまたは system prompt とも呼ばれます。
--   `model`: どの LLM を使用するかを指定し、任意で `model_settings` により temperature、top_p などのモデル調整パラメーターを設定します。
--   `tools`: エージェントがタスクの達成に使用できるツールです。
+- `name`: エージェントを識別する必須の文字列です。
+- `instructions`: developer message または システムプロンプト とも呼ばれます。
+- `model`: どの LLM を使用するか、また任意の `model_settings` で temperature、top_p などのモデル調整パラメーターを設定できます。
+- `tools`: エージェントがタスクを達成するために使用できるツールです。
 
 ```python
 from agents import Agent, ModelSettings, function_tool
@@ -33,7 +33,7 @@ agent = Agent(
 
 ## コンテキスト
 
-エージェントは `context` 型に対してジェネリックです。コンテキストは依存性注入ツールで、あなたが作成して `Runner.run()` に渡すオブジェクトです。これはすべてのエージェント、ツール、ハンドオフなどに渡され、エージェント実行のための依存関係や状態の寄せ集めとして機能します。コンテキストには任意の Python オブジェクトを指定できます。
+エージェントはその `context` 型についてジェネリックです。コンテキストは依存性注入のためのツールで、あなたが作成して `Runner.run()` に渡すオブジェクトです。これはすべてのエージェント、ツール、ハンドオフなどに渡され、実行時の依存関係や状態をまとめて保持します。コンテキストには任意の Python オブジェクトを渡せます。
 
 ```python
 @dataclass
@@ -52,7 +52,7 @@ agent = Agent[UserContext](
 
 ## 出力タイプ
 
-デフォルトでは、エージェントはプレーンテキスト（つまり `str`）の出力を生成します。特定のタイプの出力をエージェントに生成させたい場合は、`output_type` パラメーターを使用できます。一般的な選択肢は [Pydantic](https://docs.pydantic.dev/) オブジェクトを使うことですが、Pydantic の [TypeAdapter](https://docs.pydantic.dev/latest/api/type_adapter/) でラップできるあらゆる型（dataclasses、リスト、TypedDict など）をサポートします。
+デフォルトでは、エージェントはプレーンテキスト（つまり `str`）の出力を生成します。特定の型の出力を生成させたい場合は、`output_type` パラメーターを使用します。一般的には [Pydantic](https://docs.pydantic.dev/) オブジェクトを使いますが、Pydantic の [TypeAdapter](https://docs.pydantic.dev/latest/api/type_adapter/) でラップできる任意の型（dataclasses、lists、TypedDict など）をサポートします。
 
 ```python
 from pydantic import BaseModel
@@ -73,20 +73,20 @@ agent = Agent(
 
 !!! note
 
-    `output_type` を渡すと、モデルは通常のプレーンテキスト応答ではなく [structured outputs](https://platform.openai.com/docs/guides/structured-outputs) を使用するようになります。
+    `output_type` を渡すと、モデルは通常のプレーンテキスト応答ではなく、[structured outputs](https://platform.openai.com/docs/guides/structured-outputs) を使用するよう指示されます。
 
-## マルチエージェント システムの設計パターン
+## 複数エージェントのシステム設計パターン
 
-マルチエージェント システムを設計する方法は数多くありますが、一般的に幅広く適用できる 2 つのパターンがよく見られます。
+マルチエージェントシステムの設計方法は多数ありますが、幅広く適用できるパターンとして次の 2 つがよく使われます。
 
-1. マネージャー（エージェントをツールとして）: 中央のマネージャー/オーケストレーターが、ツールとして公開された専門のサブエージェントを呼び出し、会話の制御を維持します。
-2. ハンドオフ: 対等なエージェントが、会話を引き継ぐ専門エージェントに制御を引き渡します。これは分散型です。
+1. マネージャー（ツールとしてのエージェント）: 中央のマネージャー／オーケストレーターが、ツールとして公開された専門サブエージェントを呼び出し、会話の主導権を保持します。
+2. ハンドオフ: 対等なエージェント同士が、会話を引き継ぐ専門エージェントに主導権を渡します。これは分散型です。
 
-詳細は、[実践的なエージェント構築ガイド](https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf)をご覧ください。
+詳細は、[エージェント構築の実践ガイド](https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf)をご覧ください。
 
-### マネージャー（エージェントをツールとして）
+### マネージャー（ツールとしてのエージェント）
 
-`customer_facing_agent` はすべてのユーザーとのやり取りを担当し、ツールとして公開された専門のサブエージェントを呼び出します。詳細は [ツール](tools.md#agents-as-tools) のドキュメントを参照してください。
+`customer_facing_agent` がすべてのユーザーとのやり取りを担当し、ツールとして公開された専門サブエージェントを呼び出します。詳しくは [ツール](tools.md#agents-as-tools) のドキュメントをご覧ください。
 
 ```python
 from agents import Agent
@@ -115,7 +115,7 @@ customer_facing_agent = Agent(
 
 ### ハンドオフ
 
-ハンドオフは、エージェントが委任できるサブエージェントです。ハンドオフが発生すると、委任先のエージェントが会話履歴を受け取り、会話を引き継ぎます。このパターンにより、単一タスクに特化して優れた成果を出す、モジュール式の専門エージェントが可能になります。詳細は [ハンドオフ](handoffs.md) のドキュメントをご覧ください。
+ハンドオフは、エージェントが委任できるサブエージェントです。ハンドオフが発生すると、委任先のエージェントが会話履歴を受け取り、会話を引き継ぎます。このパターンにより、単一タスクに長けたモジュール式・専門特化のエージェントを実現できます。詳しくは [ハンドオフ](handoffs.md) のドキュメントをご覧ください。
 
 ```python
 from agents import Agent
@@ -136,7 +136,7 @@ triage_agent = Agent(
 
 ## 動的 instructions
 
-多くの場合、エージェント作成時に instructions を指定できますが、関数を介して動的な instructions を提供することもできます。関数はエージェントとコンテキストを受け取り、プロンプトを返す必要があります。通常の関数と `async` 関数のどちらも使用できます。
+多くの場合、エージェントを作成するときに instructions を指定しますが、関数を通じて動的な instructions を提供することもできます。関数はエージェントとコンテキストを受け取り、プロンプトを返す必要があります。通常の関数と `async` 関数の両方が利用できます。
 
 ```python
 def dynamic_instructions(
@@ -153,15 +153,15 @@ agent = Agent[UserContext](
 
 ## ライフサイクルイベント（フック）
 
-場合によっては、エージェントのライフサイクルを観測したいことがあります。たとえば、イベントをログに記録したり、特定のイベント発生時にデータを事前取得したりすることが考えられます。`hooks` プロパティを使ってエージェントのライフサイクルにフックできます。[`AgentHooks`][agents.lifecycle.AgentHooks] クラスをサブクラス化し、関心のあるメソッドをオーバーライドしてください。
+場合によっては、エージェントのライフサイクルを観察したいことがあります。たとえば、イベントをログ出力したり、特定のイベント発生時にデータを事前取得したりできます。`hooks` プロパティでエージェントのライフサイクルにフックできます。[`AgentHooks`][agents.lifecycle.AgentHooks] クラスを継承し、関心のあるメソッドをオーバーライドしてください。
 
 ## ガードレール
 
-ガードレールにより、エージェントの実行と並行してユーザー入力に対するチェック/バリデーションを実行し、エージェントの出力が生成された時点でもチェックできます。たとえば、ユーザーの入力とエージェントの出力の関連性をスクリーニングできます。詳細は [ガードレール](guardrails.md) のドキュメントをご覧ください。
+ガードレールにより、エージェントの実行と並行して ユーザー入力 に対するチェック／検証を行い、また、エージェントが出力を生成した後にその出力に対してもチェックを実行できます。たとえば、ユーザー入力とエージェント出力を関連性でスクリーニングできます。詳しくは [ガードレール](guardrails.md) のドキュメントをご覧ください。
 
-## エージェントのクローン/コピー作成
+## エージェントのクローン／コピー
 
-エージェントの `clone()` メソッドを使用すると、エージェントを複製し、任意でプロパティを変更できます。
+エージェントの `clone()` メソッドを使うと、エージェントを複製し、任意のプロパティを変更できます。
 
 ```python
 pirate_agent = Agent(
@@ -178,12 +178,12 @@ robot_agent = pirate_agent.clone(
 
 ## ツール使用の強制
 
-ツールのリストを指定しても、LLM が必ずツールを使用するとは限りません。[`ModelSettings.tool_choice`][agents.model_settings.ModelSettings.tool_choice] を設定することでツール使用を強制できます。有効な値は次のとおりです。
+ツールのリストを渡しても、常に LLM がツールを使用するとは限りません。[`ModelSettings.tool_choice`][agents.model_settings.ModelSettings.tool_choice] を設定するとツール使用を強制できます。有効な値は次のとおりです。
 
-1. `auto`: LLM がツールを使うかどうかを判断します。
-2. `required`: LLM にツールの使用を要求します（どのツールを使うかは賢く判断します）。
-3. `none`: LLM にツールを使用しないことを要求します。
-4. 特定の文字列（例: `my_tool`）を設定すると、LLM にその特定のツールの使用を要求します。
+1. `auto`: ツールを使用するかどうかを LLM に任せます。
+2. `required`: LLM にツールの使用を必須にします（どのツールを使うかは知的に判断します）。
+3. `none`: LLM にツールを _使用しない_ ことを要求します。
+4. 特定の文字列（例: `my_tool`）を設定: LLM にその特定のツールの使用を要求します。
 
 ```python
 from agents import Agent, Runner, function_tool, ModelSettings
@@ -201,11 +201,11 @@ agent = Agent(
 )
 ```
 
-## ツール使用の挙動
+## ツール使用の動作
 
-`Agent` の設定にある `tool_use_behavior` パラメーターは、ツール出力の扱い方を制御します。
+`Agent` の設定パラメーター `tool_use_behavior` は、ツール出力の取り扱い方法を制御します。
 
-- `"run_llm_again"`: デフォルト。ツールが実行され、その結果を LLM が処理して最終応答を生成します。
+- `"run_llm_again"`: デフォルト。ツールを実行し、その結果を LLM が処理して最終応答を生成します。
 - `"stop_on_first_tool"`: 最初のツール呼び出しの出力を、その後の LLM 処理なしで最終応答として使用します。
 
 ```python
@@ -224,7 +224,7 @@ agent = Agent(
 )
 ```
 
-- `StopAtTools(stop_at_tool_names=[...])`: 指定したいずれかのツールが呼び出された時点で停止し、その出力を最終応答として使用します。
+- `StopAtTools(stop_at_tool_names=[...])`: 指定したいずれかのツールが呼び出されたら停止し、その出力を最終応答として使用します.
 
 ```python
 from agents import Agent, Runner, function_tool
@@ -248,7 +248,7 @@ agent = Agent(
 )
 ```
 
-- `ToolsToFinalOutputFunction`: ツール結果を処理し、停止するか LLM を続行するかを決定するカスタム関数です。
+- `ToolsToFinalOutputFunction`: ツール結果を処理し、停止するか LLM を継続するかを判断するカスタム関数です。
 
 ```python
 from agents import Agent, Runner, function_tool, FunctionToolResult, RunContextWrapper
@@ -286,4 +286,4 @@ agent = Agent(
 
 !!! note
 
-    無限ループを防ぐため、フレームワークはツール呼び出し後に `tool_choice` を自動的に "auto" にリセットします。この挙動は [`agent.reset_tool_choice`][agents.agent.Agent.reset_tool_choice] で設定できます。無限ループは、ツール結果が LLM に送られ、`tool_choice` のために LLM が再びツール呼び出しを生成し続けることによって発生します。
+    無限ループを防ぐため、フレームワークはツール呼び出し後に `tool_choice` を自動的に "auto" にリセットします。この動作は [`agent.reset_tool_choice`][agents.agent.Agent.reset_tool_choice] で設定できます。無限ループは、ツール結果が LLM に送られ、`tool_choice` により LLM が再度ツール呼び出しを生成し続けることによって発生します。