diff --git a/en/self-host/deploy/configuration/environments.mdx b/en/self-host/deploy/configuration/environments.mdx
index f989f21b3..435e14978 100644
--- a/en/self-host/deploy/configuration/environments.mdx
+++ b/en/self-host/deploy/configuration/environments.mdx
@@ -1226,8 +1226,8 @@ Traces of app runs are delivered to the configured LLMOps provider (Langfuse, La
 | Variable | Default | Description |
 |---|---|---|
 | `OPS_TRACE_UNIFIED_ENABLED` | `false` | Set to `true` to give LangSmith and Arize/Phoenix traces a common structure for workflow runs, nodes, and their parent-child relationships. The default `false` uses each provider's original tracing implementation. Other providers are unaffected.<br/><br/>Each app still needs LLMOps enabled and a provider configured. |
-| `OPS_AGENT_TRACE_ENABLED` | `false` | Set to `true` to include Agent model and tool calls in the traces of Agent apps and of Workflow and Chatflow apps with an Agent node. Agents inside a [workflow tool](/en/self-host/use-dify/workspace/tools#workflow) that the app calls aren't included. Also set `DIFY_AGENT_APPLICATION_TRACING_ENABLED` to `true`.<br/><br/>While this is `false`, the tracing settings of Agent, Workflow, and Chatflow apps say Agent tracing isn't available. Each app still needs tracing enabled, a provider configured, and **Capture Agent internals** on (the default). |
-| `DIFY_AGENT_APPLICATION_TRACING_ENABLED` | `false` | The agent backend's half of `OPS_AGENT_TRACE_ENABLED`; set both to `true` to trace Agents.<br/><br/>Set it in `docker/envs/core-services/dify-agent.env`, not `shared.env`: the agent backend doesn't read that file. |
+| `OPS_AGENT_TRACE_ENABLED` | `false` | Set to `true` to include Agent model and tool calls in the traces of Agent apps and of Workflow and Chatflow apps with a new Agent node. Agents inside a [workflow tool](/en/self-host/use-dify/workspace/tools#workflow) that the app calls aren't included. Also set `DIFY_AGENT_APPLICATION_TRACING_ENABLED` to `true`.<br/><br/>While this is `false`, the tracing settings of Agent, Workflow, and Chatflow apps say Agent tracing isn't available. Each app still needs tracing enabled, a provider configured, and **Capture Agent internals** on (the default). |
+| `DIFY_AGENT_APPLICATION_TRACING_ENABLED` | `false` | The agent backend's half of `OPS_AGENT_TRACE_ENABLED`; set both to `true` to trace Agents.<br/><br/>Set it in `docker/envs/core-services/dify-agent.env`, not `shared.env`: the agent backend doesn't read that file.<br/><br/>While it's on, an Agent run that its app traces goes to the app's tracing provider instead of [trajectory export](#agent-trajectory-export). |
 | `ENABLE_APPLICATION_TRACE_RECONCILE_TASK` | `true` | Used only when `OPS_AGENT_TRACE_ENABLED` is `true`. Runs a background job every 30 seconds that resends Agent traces still waiting for delivery and deletes the Agent trace data Dify stores after the retention period (7 days by default). Traces already delivered to your tracing provider stay there. |
 | `OPS_TRACE_RETRYABLE_DISPATCH_MAX_RETRIES` | `780` | How many times a trace delivery is retried after a transient failure before the trace is dropped. <br/><br/>The default retry window (retries × `OPS_TRACE_RETRYABLE_DISPATCH_DELAY_SECONDS`) is sized to outlast the one-hour workflow limit plus the export grace period. <br/><br/>Today only Arize/Phoenix tracing of nested workflows hits this path (a child trace arriving before its parent's context). Cannot be `0`. |
 | `OPS_TRACE_RETRYABLE_DISPATCH_DELAY_SECONDS` | `5` | Seconds between those retries; the total tolerance window is delay × max retries (about 65 minutes at defaults).<br/><br/>Lower delivers nested traces sooner but exhausts the retry budget faster. Cannot be `0`. |
@@ -1439,10 +1439,16 @@ Replaces the former `DIFY_AGENT_SHELLCTL_AUTH_TOKEN`, which still works as a leg
 
 Default: `true`
 
-Shows the new Agent in the web UI: the **Agents** item in the main navigation and the new Agent node in the workflow node picker. 
+Shows the new Agent in the web UI: the **Agents** item in the main navigation and the new Agent node in the node picker of Workflow apps.
 
 Set to `false` to hide it and fall back to the classic Agent node. Replaces `ENABLE_AGENT_V2`, which still works as a fallback.
 
+### NEXT_PUBLIC_ENABLE_AGENT_V2_IN_CHATFLOW
+
+Default: `false`
+
+Set to `true` to add the new Agent node to the node picker of Chatflow apps too. Works only while `NEXT_PUBLIC_ENABLE_AGENT_V2` is `true`.
+
 ### UPLOAD_SKILL_FILE_SIZE_LIMIT
 
 Default: `50`
@@ -1556,7 +1562,7 @@ Before switching to `openshell`, have these in place:
 - An OpenShell gateway, version 0.0.106 or later, reachable from the `agent_backend` container.
 - Gateway credentials: a bearer token, an mTLS client certificate pair, or both. Compose ships no certificate mount, so mount the files into `agent_backend` yourself, read-only and readable by UID 1001.
 - A runtime image that the gateway can start sandboxes from.
-- A shared volume for the persistent files agents keep across conversations, created outside Compose so that `docker compose down -v` can't delete it.
+- A shared volume for the persistent files agents keep across conversations, created outside Compose so that `docker compose down -v` can't delete it. If the deployment serves tenants that don't trust each other, give each its own OpenShell workspace and volume. A shared volume can't reliably keep one tenant out of another's persistent files.
 - A network path from the sandboxes back to Dify:
   - Callback addresses the sandboxes can reach.
   - A route to the agent backend's `/agent-stub` path. The base Compose file doesn't publish the agent backend's port 5050, and that port also serves the API that starts agent runs, so expose only `/agent-stub`, for example through a reverse proxy.
@@ -1582,7 +1588,7 @@ The bundled sandbox's egress proxy doesn't cover OpenShell sandboxes. To restric
 | `DIFY_AGENT_OPENSHELL_INSECURE` | `false` | Connects to the gateway over plaintext gRPC instead of TLS, without using the TLS paths. A bearer token, if set, is still sent over that connection.<br/><br/>Only for local development against a plaintext gateway. |
 | `DIFY_AGENT_OPENSHELL_WORKSPACE` | `default` | OpenShell workspace in which the agent backend creates and manages sandboxes. This is a namespace on the gateway, not a Dify workspace. |
 | `DIFY_AGENT_OPENSHELL_SANDBOX_IMAGE` | `docker.io/library/dify-agent-runtime:latest` | Container image the gateway starts for each sandbox. The default is the tag that the build command in the OpenShell setup guide produces.<br/><br/>The image must be available to the gateway's compute driver, not only to the Docker daemon running Dify: load it into the gateway's Docker daemon, or push it to a registry the gateway pulls from and use that reference.<br/><br/>Set it explicitly. If no env file sets it, the agent backend falls back to `langgenius/dify-agent-local-sandbox:latest`, which may be an older image that can't start under OpenShell. |
-| `DIFY_AGENT_OPENSHELL_DRIVER_CONFIG` | (empty) | Required for the `openshell` backend. JSON the gateway's compute driver applies to every sandbox; it must mount the shared volume at `DIFY_AGENT_OPENSHELL_SHARED_MOUNT_PATH`. Its shape depends on the driver.<br/><br/>Invalid JSON or an empty object stops the agent backend from starting. Dify doesn't check the mounts themselves, so the agent backend starts even if the volume is mounted at another path. Double-check the target.<br/><br/>Example for the Docker driver: `{"docker":{"mounts":[{"type":"volume","source":"dify-agent-shared","target":"/mnt/dify-agent-shared","read_only":false}]}}` |
+| `DIFY_AGENT_OPENSHELL_DRIVER_CONFIG` | (empty) | Required for the `openshell` backend. JSON the gateway's compute driver applies to every sandbox; it must mount the shared volume at `DIFY_AGENT_OPENSHELL_SHARED_MOUNT_PATH`. Its shape depends on the driver.<br/><br/>Invalid JSON or an empty object stops the agent backend from starting. Dify doesn't check the mounts themselves, so the agent backend starts even if the volume is mounted at another path. Double-check the target.<br/><br/>Example for the Docker driver (single-tenant, such as local development): `{"docker":{"mounts":[{"type":"volume","source":"dify-agent-shared","target":"/mnt/dify-agent-shared","read_only":false}]}}` |
 | `DIFY_AGENT_OPENSHELL_SHARED_MOUNT_PATH` | `/mnt/dify-agent-shared` | Where the shared volume is mounted inside each sandbox; must match the mount target in `DIFY_AGENT_OPENSHELL_DRIVER_CONFIG`. Agents' persistent files are saved here each time you click **Apply** in an Agent's build chat.<br/><br/>Must be an absolute path, or the agent backend won't start. |
 | `DIFY_AGENT_OPENSHELL_SHELLCTL_AUTH_TOKEN` | (empty) | Required for the `openshell` backend; the agent backend won't start without it. Shared secret that authenticates the agent backend to the command service it starts inside each sandbox. Set any random string.<br/><br/>Separate from `DIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKEN`, which secures the bundled sandbox. |
 | `DIFY_AGENT_OPENSHELL_EGRESS_ALLOW` | (empty) | Comma-separated `host:port` endpoints that sandboxes may connect to, with no scheme or path. Empty sends no network policy, so egress follows the gateway's default.<br/><br/>When set, sandboxes reach only the listed endpoints, so package installs and web access stop working unless their hosts are listed. Include the hosts of `DIFY_AGENT_STUB_API_BASE_URL` and `DIFY_AGENT_SANDBOX_FILES_BASE_URL`, or agent runs can't call back into Dify.<br/><br/>A malformed entry stops the agent backend from starting.<br/><br/>Example: `agent.example.com:443,dify.example.com:443` |
@@ -1595,11 +1601,13 @@ The bundled sandbox's egress proxy doesn't cover OpenShell sandboxes. To restric
 
 ### Agent Trajectory Export
 
-To see what your agents did in a tracing backend you already run, turn on trajectory export. The agent backend then sends a trace of each agent run, with its model requests and tool calls, to an OpenTelemetry collector over OTLP/HTTP. One collector receives the runs of every workspace on the deployment.
+To see what your agents did in a tracing backend you already run, turn on trajectory export. The agent backend then sends traces of agent runs, with their model requests and tool calls, to an OpenTelemetry collector over OTLP/HTTP. One collector receives the runs of every workspace on the deployment.
 
 Every span carries the IDs of its workspace, app, agent, end user, conversation, workflow run, and node, so you can narrow traces to one app or one conversation by attributes such as `dify.app_id` or `dify.conversation.id`. These IDs are exported even with content export off.
 
-Trajectory export is separate from [LLMOps Trace Delivery](#llmops-trace-delivery), which app builders set up per app with providers such as Langfuse, and from the [OpenTelemetry instrumentation](#otlp-/-opentelemetry-configuration) of the API and Worker. Their settings don't affect it.
+Trajectory export is separate from the [OpenTelemetry instrumentation](#otlp-/-opentelemetry-configuration) of the API and Worker.
+
+It isn't separate from [LLMOps Trace Delivery](#llmops-trace-delivery), which app builders set up per app with providers such as Langfuse. With Agent tracing turned on there, a run that its app traces goes only to the app's tracing provider, and every other Agent run reaches the collector.
 
 To turn it on:
 
diff --git a/en/self-host/use-dify/build/new-agent/build.mdx b/en/self-host/use-dify/build/new-agent/build.mdx
index 99324f8b5..50dd0d663 100644
--- a/en/self-host/use-dify/build/new-agent/build.mdx
+++ b/en/self-host/use-dify/build/new-agent/build.mdx
@@ -223,11 +223,11 @@ To share the agent across workspaces, click **Export Agent** from its menu. This
 
 <AccordionGroup>
   <Accordion title="Agents doesn't appear in the navigation or the node list">
-    The deployment's `.env` predates 1.16.0, so the Agents switch is missing or still off.
+    If only Chatflow apps lack the node, turn on [`NEXT_PUBLIC_ENABLE_AGENT_V2_IN_CHATFLOW`](/en/self-host/deploy/configuration/environments#next_public_enable_agent_v2_in_chatflow); it's off by default.
 
-    Sync it with `.env.example` (the switch is [`NEXT_PUBLIC_ENABLE_AGENT_V2`](/en/self-host/deploy/configuration/environments#next_public_enable_agent_v2)), then recreate the web container (`docker compose up -d web`) and hard-refresh the browser.
+    Otherwise, the deployment's `.env` predates 1.16.0, so the Agents switch is missing or still off.
 
-    In Chatflow apps the node's absence is expected: it's available in Workflow apps only.
+    Sync it with `.env.example` (the switch is [`NEXT_PUBLIC_ENABLE_AGENT_V2`](/en/self-host/deploy/configuration/environments#next_public_enable_agent_v2)), then recreate the web container (`docker compose up -d web`) and hard-refresh the browser.
 
     If other members see **Agents** but you don't, the cause is your workspace role: the entry needs the Editor role or above.
   </Accordion>
diff --git a/en/self-host/use-dify/build/skills.mdx b/en/self-host/use-dify/build/skills.mdx
index a65c6a5be..6874c5277 100644
--- a/en/self-host/use-dify/build/skills.mdx
+++ b/en/self-host/use-dify/build/skills.mdx
@@ -13,7 +13,7 @@ You can keep up to 500 skills in the library and share them workspace-wide. When
 Use skills in:
 
 - [Agent apps](/en/self-host/use-dify/build/new-agent/build#skills)
-- [New Agent nodes](/en/self-host/use-dify/nodes/agent#new-agent) in Workflow apps
+- [New Agent nodes](/en/self-host/use-dify/nodes/agent#new-agent) in Workflow and Chatflow apps
 
 <Info>
 Creating and managing skills requires the Editor role or above.
diff --git a/en/self-host/use-dify/monitor/analysis.mdx b/en/self-host/use-dify/monitor/analysis.mdx
index f2152c73e..7c727fd35 100644
--- a/en/self-host/use-dify/monitor/analysis.mdx
+++ b/en/self-host/use-dify/monitor/analysis.mdx
@@ -14,11 +14,9 @@ The dashboard tracks four metrics over time to show how your application perform
 **Average User Interactions**: Engagement depth per session  
 **Token Usage**: Resource consumption and costs
 
-Use the time selector to view trends over different periods. Click **"Tracing app performance"** to connect external observability platforms like Langfuse or LangSmith for deeper analytics.
+Use the time selector to view trends over different periods. Click **"Tracing app performance"** to connect external observability platforms like [Langfuse](/en/self-host/use-dify/monitor/integrations/integrate-langfuse) or [LangSmith](/en/self-host/use-dify/monitor/integrations/integrate-langsmith) for deeper analytics.
 
-For an Agent, open the same tracing settings from the Agent's **Monitoring** section.
-
-To see inputs and outputs in the traces of an Agent app or a workflow with an Agent node, turn on **Capture content** under **Agent data capture**. It covers every node in those traces, not only the Agent.
+For an [Agent](/en/self-host/use-dify/build/new-agent/overview), open the same tracing settings from the Agent's **Monitoring** section. They apply to the Agent's own runs, such as its chats, web app, and API calls. When the Agent runs inside a Workflow or Chatflow, that app's tracing settings apply instead.
 
 <Note>
 Agent tracing is off by default. Enable it by setting:
@@ -27,4 +25,11 @@ Agent tracing is off by default. Enable it by setting:
 - `DIFY_AGENT_APPLICATION_TRACING_ENABLED` = `true`
 
 See [Environment Variables](/en/self-host/deploy/configuration/environments#llmops-trace-delivery) for details.
-</Note>
\ No newline at end of file
+</Note>
+
+In the tracing settings, **Agent data capture** sets what the traces include for Agent apps and for workflows with a [new Agent node](/en/self-host/use-dify/nodes/agent#new-agent):
+
+- **Capture Agent internals**: the Agent's model and tool calls. Turn it off to keep these steps out of your tracing provider; the trace then shows the Agent as a single step.
+- **Capture content**: the inputs and outputs of every step in the trace, not only the Agent's. Turning it on sends prompts, user messages, and replies to your tracing provider.
+
+In other workflows, including those with only a classic Agent node, these switches have no effect.
\ No newline at end of file
diff --git a/en/self-host/use-dify/nodes/agent.mdx b/en/self-host/use-dify/nodes/agent.mdx
index 8fe537089..5e3faf92d 100644
--- a/en/self-host/use-dify/nodes/agent.mdx
+++ b/en/self-host/use-dify/nodes/agent.mdx
@@ -128,7 +128,7 @@ description: Run an agent as a step in your workflow, reasoning and using tools
   </Warning>
 
   <Note>
-  The new Agent node is in beta and available in Workflow apps only. It's on by default on Docker Compose, with its runtime bundled in.
+  The new Agent node is in beta. It's on by default on Docker Compose, with its runtime bundled in. In Chatflow apps, it's available once you turn on [`NEXT_PUBLIC_ENABLE_AGENT_V2_IN_CHATFLOW`](/en/self-host/deploy/configuration/environments#next_public_enable_agent_v2_in_chatflow).
 
   For production, replace [`DIFY_AGENT_SERVER_SECRET_KEY`](/en/self-host/deploy/configuration/environments#dify_agent_server_secret_key) and [`DIFY_AGENT_API_TOKEN`](/en/self-host/deploy/configuration/environments#dify_agent_api_token) with your own random values.
   </Note>
@@ -230,5 +230,13 @@ description: Run an agent as a step in your workflow, reasoning and using tools
 
   The node fails if the model's answer has no route or names one that doesn't exist. To keep the workflow running instead of stopping there, set **Error Handling** to **Fail Branch** and connect that branch to a fallback.
 
+  <a id="in-a-chatflow"></a>
+
+  ## In a Chatflow
+
+  Each turn picks up where the last one left off, so the agent can build on what the user already said. Two Agent nodes in the same Chatflow remember separately.
+
+  When you update the agent, in **Agents** or on the node, conversations already in progress keep the setup they started with. Start a new conversation to try the change.
+
   </Tab>
 </Tabs>
\ No newline at end of file
diff --git a/ja/self-host/deploy/configuration/environments.mdx b/ja/self-host/deploy/configuration/environments.mdx
index b277b6b5d..601d97f89 100644
--- a/ja/self-host/deploy/configuration/environments.mdx
+++ b/ja/self-host/deploy/configuration/environments.mdx
@@ -1224,8 +1224,8 @@ Dify はアカウント招待、パスワードリセット、ログインコー
 | 変数 | デフォルト値 | 説明 |
 |---|---|---|
 | `OPS_TRACE_UNIFIED_ENABLED` | `false` | `true` にすると、LangSmith と Arize/Phoenix のトレースに共通の構造を使います。ワークフロー実行、ノード、それらの親子関係を記録します。デフォルトの `false` では、各プロバイダーの従来のトレース実装を使います。他のプロバイダーには影響しません。<br/><br/>各アプリで LLMOps を有効にし、プロバイダーを設定する必要があります。 |
-| `OPS_AGENT_TRACE_ENABLED` | `false` | `true` にすると、Agent のモデル呼び出しとツール呼び出しがトレースに含まれます。対象は Agent アプリと、Agent ノードを含む Workflow アプリおよび Chatflow アプリです。アプリが呼び出す [ワークフローツール](/ja/self-host/use-dify/workspace/tools#workflow) 内の Agent は含まれません。あわせて `DIFY_AGENT_APPLICATION_TRACING_ENABLED` も `true` にしてください。<br/><br/>`false` の間は、Agent、Workflow、Chatflow アプリのトレース設定に、Agent トレースを利用できない旨が表示されます。各アプリでトレースを有効にしてプロバイダーを設定し、**Agent の内部処理を収集** をオンのままにしておく必要もあります（デフォルトはオン）。 |
-| `DIFY_AGENT_APPLICATION_TRACING_ENABLED` | `false` | `OPS_AGENT_TRACE_ENABLED` と対になる Agent バックエンド側の設定です。Agent をトレースするには両方を `true` にしてください。<br/><br/>`docker/envs/core-services/dify-agent.env` で設定します。Agent バックエンドは `shared.env` を読み込まないため、そちらに設定しても反映されません。 |
+| `OPS_AGENT_TRACE_ENABLED` | `false` | `true` にすると、Agent のモデル呼び出しとツール呼び出しがトレースに含まれます。対象は Agent アプリと、新しい Agent ノードを含む Workflow アプリおよび Chatflow アプリです。アプリが呼び出す [ワークフローツール](/ja/self-host/use-dify/workspace/tools#workflow) 内の Agent は含まれません。あわせて `DIFY_AGENT_APPLICATION_TRACING_ENABLED` も `true` にしてください。<br/><br/>`false` の間は、Agent、Workflow、Chatflow アプリのトレース設定に、Agent トレースを利用できない旨が表示されます。各アプリでトレースを有効にしてプロバイダーを設定し、**Agent の内部処理を収集** をオンのままにしておく必要もあります（デフォルトはオン）。 |
+| `DIFY_AGENT_APPLICATION_TRACING_ENABLED` | `false` | `OPS_AGENT_TRACE_ENABLED` と対になる Agent バックエンド側の設定です。Agent をトレースするには両方を `true` にしてください。<br/><br/>`docker/envs/core-services/dify-agent.env` で設定します。Agent バックエンドは `shared.env` を読み込まないため、そちらに設定しても反映されません。<br/><br/>有効にしている間、アプリでトレースされる Agent 実行は、[トラジェクトリのエクスポート](#agent-トラジェクトリのエクスポート) ではなく、そのアプリのトレースプロバイダーに送られます。 |
 | `ENABLE_APPLICATION_TRACE_RECONCILE_TASK` | `true` | `OPS_AGENT_TRACE_ENABLED` が `true` の場合のみ有効です。30 秒ごとにバックグラウンドジョブを実行し、配信待ちの Agent トレースを再送します。保持期間（デフォルトで 7 日）を過ぎると、Dify が保存している Agent トレースデータも削除します。トレースプロバイダーにすでに配信されたデータは削除されません。 |
 | `OPS_TRACE_RETRYABLE_DISPATCH_MAX_RETRIES` | `780` | 一時的な失敗後にトレース配信をリトライする最大回数。超えるとそのトレースは破棄されます。<br/><br/>デフォルトのリトライ時間（回数 × `OPS_TRACE_RETRYABLE_DISPATCH_DELAY_SECONDS`）は、1 時間のワークフロー上限とエクスポート猶予期間を上回るよう設定されています。<br/><br/>現在この経路に入るのは、Arize/Phoenix でネストしたワークフローをトレースする場合のみです。子トレースが親のコンテキストより先に届くと発生します。`0` は指定できません。 |
 | `OPS_TRACE_RETRYABLE_DISPATCH_DELAY_SECONDS` | `5` | リトライの間隔（秒）。許容ウィンドウは間隔 × 最大回数（デフォルトで約 65 分）です。<br/><br/>小さくするとネストしたトレースが早く届く一方、リトライ回数を早く使い切ります。`0` は指定できません。 |
@@ -1433,7 +1433,13 @@ openssl rand -base64 32
 
 デフォルト値：`true`
 
-新しい Agent を Web UI に表示します。メインナビゲーションの **Agents** 項目と、ワークフローのノード一覧の新しい Agent ノードです。`false` にすると非表示になり、クラシック Agent ノードにフォールバックします。`ENABLE_AGENT_V2` を置き換えるもので、こちらは引き続きフォールバックとして機能します。
+新しい Agent を Web UI に表示します。表示されるのは、メインナビゲーションの **Agents** 項目と、Workflow アプリのノード一覧にある新しい Agent ノードです。`false` にすると非表示になり、クラシック Agent ノードにフォールバックします。`ENABLE_AGENT_V2` を置き換えるもので、こちらは引き続きフォールバックとして機能します。
+
+### NEXT_PUBLIC_ENABLE_AGENT_V2_IN_CHATFLOW
+
+デフォルト値：`false`
+
+`true` にすると、Chatflow アプリのノード一覧にも新しい Agent ノードが表示されます。`NEXT_PUBLIC_ENABLE_AGENT_V2` が `true` の場合のみ有効です。
 
 ### UPLOAD_SKILL_FILE_SIZE_LIMIT
 
@@ -1548,7 +1554,7 @@ Agent のサンドボックスをどこで実行するかを選択します：
 - `agent_backend` コンテナから到達できる OpenShell ゲートウェイ（バージョン 0.0.106 以降）を用意します。
 - ゲートウェイの認証情報として、Bearer トークン、mTLS クライアント証明書のペア、またはその両方を用意します。Compose には証明書のマウント設定が含まれていないため、ファイルを読み取り専用で `agent_backend` に自分でマウントし、UID 1001 から読み取れるようにします。
 - ゲートウェイがサンドボックスの起動に使うランタイムイメージを用意します。
-- Agent が会話をまたいで保持する永続ファイル用に、共有ボリュームを用意します。`docker compose down -v` で削除されないよう、Compose の外で作成します。
+- Agent が会話をまたいで保持する永続ファイル用に、共有ボリュームを用意します。`docker compose down -v` で削除されないよう、Compose の外で作成します。互いを信頼できない複数のテナントが同じデプロイを使う場合は、テナントごとに OpenShell ワークスペースとボリュームを分けてください。共有ボリュームでは、あるテナントが別のテナントの永続ファイルにアクセスすることを確実には防げません。
 - サンドボックスから Dify へ戻るネットワーク経路を確保します：
   - サンドボックスから到達できるコールバックアドレスを用意します。
   - Agent バックエンドの `/agent-stub` パスへのルートを用意します。ベースの Compose ファイルは、Agent バックエンドのポート 5050 を公開しません。このポートは Agent の実行を開始する API も提供しているため、リバースプロキシなどを使って `/agent-stub` だけを公開します。
@@ -1574,7 +1580,7 @@ OpenShell に切り替えるには、次の手順を実行します：
 | `DIFY_AGENT_OPENSHELL_INSECURE` | `false` | TLS ではなく平文の gRPC でゲートウェイに接続し、TLS のパスは使わない。Bearer トークンを設定している場合は、この接続でも送信される。<br/><br/>平文のゲートウェイを使うローカル開発専用。 |
 | `DIFY_AGENT_OPENSHELL_WORKSPACE` | `default` | Agent バックエンドがサンドボックスを作成・管理する OpenShell ワークスペース。ゲートウェイ上の名前空間であり、Dify のワークスペースではない。 |
 | `DIFY_AGENT_OPENSHELL_SANDBOX_IMAGE` | `docker.io/library/dify-agent-runtime:latest` | ゲートウェイが各サンドボックス用に起動するコンテナイメージ。デフォルトは、OpenShell セットアップガイドのビルドコマンドが生成するタグ。<br/><br/>Dify を動かす Docker デーモンだけでなく、ゲートウェイのコンピュートドライバーからも利用できる必要がある。ゲートウェイの Docker デーモンにイメージを読み込むか、ゲートウェイがプルできるレジストリにプッシュして、その参照を指定する。<br/><br/>明示的に設定すること。どの env ファイルでも設定しない場合、Agent バックエンドは `langgenius/dify-agent-local-sandbox:latest` にフォールバックする。このイメージは古い可能性があり、その場合は OpenShell で起動できない。 |
-| `DIFY_AGENT_OPENSHELL_DRIVER_CONFIG` | （空） | `openshell` バックエンドでは必須。ゲートウェイのコンピュートドライバーがすべてのサンドボックスに適用する JSON。共有ボリュームを `DIFY_AGENT_OPENSHELL_SHARED_MOUNT_PATH` にマウントする必要がある。形式はドライバーによって異なる。<br/><br/>JSON が不正、または空のオブジェクトだと Agent バックエンドは起動しない。Dify はマウント自体を確認しないため、ボリュームが別のパスにマウントされていても Agent バックエンドは起動する。マウント先は必ず再確認すること。<br/><br/>Docker ドライバーの例：`{"docker":{"mounts":[{"type":"volume","source":"dify-agent-shared","target":"/mnt/dify-agent-shared","read_only":false}]}}` |
+| `DIFY_AGENT_OPENSHELL_DRIVER_CONFIG` | （空） | `openshell` バックエンドでは必須。ゲートウェイのコンピュートドライバーがすべてのサンドボックスに適用する JSON。共有ボリュームを `DIFY_AGENT_OPENSHELL_SHARED_MOUNT_PATH` にマウントする必要がある。形式はドライバーによって異なる。<br/><br/>JSON が不正、または空のオブジェクトだと Agent バックエンドは起動しない。Dify はマウント自体を確認しないため、ボリュームが別のパスにマウントされていても Agent バックエンドは起動する。マウント先は必ず再確認すること。<br/><br/>Docker ドライバーの例（ローカル開発などのシングルテナント構成向け）：`{"docker":{"mounts":[{"type":"volume","source":"dify-agent-shared","target":"/mnt/dify-agent-shared","read_only":false}]}}` |
 | `DIFY_AGENT_OPENSHELL_SHARED_MOUNT_PATH` | `/mnt/dify-agent-shared` | 各サンドボックス内で共有ボリュームをマウントする場所。`DIFY_AGENT_OPENSHELL_DRIVER_CONFIG` のマウント先と一致させる。Agent のビルドチャットで **適用** をクリックするたびに、Agent の永続ファイルがここに保存される。<br/><br/>絶対パスでなければ、Agent バックエンドは起動しない。 |
 | `DIFY_AGENT_OPENSHELL_SHELLCTL_AUTH_TOKEN` | （空） | `openshell` バックエンドでは必須。未設定だと Agent バックエンドは起動しない。Agent バックエンドが各サンドボックス内で起動するコマンドサービスに対し、自身を認証するための共有シークレット。任意のランダムな文字列を設定する。<br/><br/>同梱サンドボックスを保護する `DIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKEN` とは別のもの。 |
 | `DIFY_AGENT_OPENSHELL_EGRESS_ALLOW` | （空） | サンドボックスが接続できる `host:port` エンドポイントのカンマ区切りリスト。スキームやパスは付けない。空の場合はネットワークポリシーを送らず、外向き通信はゲートウェイのデフォルトに従う。<br/><br/>設定すると、サンドボックスはリストにあるエンドポイントにしか接続できない。パッケージのインストールや Web アクセスも、そのホストをリストに入れない限り機能しなくなる。`DIFY_AGENT_STUB_API_BASE_URL` と `DIFY_AGENT_SANDBOX_FILES_BASE_URL` のホストも含めること。含めないと、Agent の実行が Dify にコールバックできない。<br/><br/>形式が不正なエントリがあると、Agent バックエンドは起動しない。<br/><br/>例：`agent.example.com:443,dify.example.com:443` |
@@ -1587,11 +1593,13 @@ OpenShell に切り替えるには、次の手順を実行します：
 
 ### Agent トラジェクトリのエクスポート
 
-すでに運用しているトレーシングバックエンドで Agent の動作を確認するには、トラジェクトリのエクスポートを有効にします。有効にすると、Agent バックエンドは各 Agent 実行のトレースを OTLP/HTTP で OpenTelemetry コレクターに送信します。トレースには、モデルへのリクエストとツール呼び出しが含まれます。デプロイ内のすべてのワークスペースの実行が、1 つのコレクターに届きます。
+すでに運用しているトレーシングバックエンドで Agent の動作を確認するには、トラジェクトリのエクスポートを有効にします。有効にすると、Agent バックエンドは Agent 実行のトレースを OTLP/HTTP で OpenTelemetry コレクターに送信します。トレースには、モデルへのリクエストとツール呼び出しが含まれます。デプロイ内のすべてのワークスペースの実行が、1 つのコレクターに届きます。
 
 各スパンには、ワークスペース、アプリ、Agent、エンドユーザー、会話、ワークフロー実行、ノードの ID が付与されます。`dify.app_id` や `dify.conversation.id` などの属性で、トレースを 1 つのアプリや 1 つの会話に絞り込めます。これらの ID は、コンテンツのエクスポートを無効にしていてもエクスポートされます。
 
-トラジェクトリのエクスポートは、[LLMOps トレース配信](#llmops-トレース配信) とは別の仕組みです。LLMOps トレース配信は、アプリ作成者がアプリごとに Langfuse などのプロバイダーで設定します。API と Worker の [OpenTelemetry 計装](#otlp-/-opentelemetry-設定) とも別で、どちらの設定もトラジェクトリのエクスポートには影響しません。
+トラジェクトリのエクスポートは、API と Worker の [OpenTelemetry 計装](#otlp-/-opentelemetry-設定) とは別の仕組みです。
+
+一方、[LLMOps トレース配信](#llmops-トレース配信) の設定はトラジェクトリのエクスポートに影響します。LLMOps トレース配信は、アプリ作成者がアプリごとに Langfuse などのプロバイダーを選んで設定するものです。LLMOps トレース配信で Agent トレースを有効にすると、アプリでトレースされる実行は、そのアプリのトレースプロバイダーにだけ送られます。それ以外の Agent 実行はコレクターに届きます。
 
 有効にするには、次の手順を実行します：
 
diff --git a/ja/self-host/use-dify/build/new-agent/build.mdx b/ja/self-host/use-dify/build/new-agent/build.mdx
index 55e0a9ab3..913d19edb 100644
--- a/ja/self-host/use-dify/build/new-agent/build.mdx
+++ b/ja/self-host/use-dify/build/new-agent/build.mdx
@@ -223,11 +223,11 @@ Agent をワークスペース間で共有するには、Agent のメニュー
 
 <AccordionGroup>
   <Accordion title="ナビゲーションに Agents が表示されない、またはノード一覧に Agent ノードがない">
-    デプロイの `.env` が 1.16.0 より古く、Agents のスイッチが存在しないか、オフのままになっています。
+    Chatflow アプリにだけこのノードがない場合は、[`NEXT_PUBLIC_ENABLE_AGENT_V2_IN_CHATFLOW`](/ja/self-host/deploy/configuration/environments#next_public_enable_agent_v2_in_chatflow) を有効にしてください。デフォルトではオフです。
 
-    `.env.example` と同期してください（スイッチは [`NEXT_PUBLIC_ENABLE_AGENT_V2`](/ja/self-host/deploy/configuration/environments#next_public_enable_agent_v2)）。その後、web コンテナを再作成（`docker compose up -d web`）し、ブラウザを強制リロードします。
+    それ以外の場合は、デプロイの `.env` が 1.16.0 より古く、Agents のスイッチが存在しないか、オフのままになっています。
 
-    Chatflow アプリでこのノードが見当たらないのは仕様です。新しい Agent ノードは Workflow アプリでのみ使用できます。
+    `.env.example` と同期してください（スイッチは [`NEXT_PUBLIC_ENABLE_AGENT_V2`](/ja/self-host/deploy/configuration/environments#next_public_enable_agent_v2)）。その後、web コンテナを再作成（`docker compose up -d web`）し、ブラウザを強制リロードします。
 
     ほかのメンバーには **Agents** が表示されるのに自分には表示されない場合は、ワークスペースのロールが原因です。この項目にはエディター以上のロールが必要です。
   </Accordion>
diff --git a/ja/self-host/use-dify/build/skills.mdx b/ja/self-host/use-dify/build/skills.mdx
index 7180e937d..2aea92d80 100644
--- a/ja/self-host/use-dify/build/skills.mdx
+++ b/ja/self-host/use-dify/build/skills.mdx
@@ -15,7 +15,7 @@ description: 1 つのタスクと関連ファイルを再利用可能なスキ
 スキルは次の場所で利用できます：
 
 - [Agent アプリ](/ja/self-host/use-dify/build/new-agent/build#skills)
-- Workflow アプリ内の [新しい Agent ノード](/ja/self-host/use-dify/nodes/agent#new-agent)
+- Workflow アプリと Chatflow アプリ内の [新しい Agent ノード](/ja/self-host/use-dify/nodes/agent#new-agent)
 
 <Info>
 スキルの作成と管理には、エディター以上のロールが必要です。
diff --git a/ja/self-host/use-dify/monitor/analysis.mdx b/ja/self-host/use-dify/monitor/analysis.mdx
index 57d61bb64..ac4244c18 100644
--- a/ja/self-host/use-dify/monitor/analysis.mdx
+++ b/ja/self-host/use-dify/monitor/analysis.mdx
@@ -15,11 +15,9 @@ description: "Dify の組み込み分析ダッシュボードを通じて、パ
 **Average User Interactions**：セッションごとのエンゲージメントの深さ  
 **Token Usage**：リソース消費とコスト
 
-時間セレクターを使用して、異なる期間のトレンドを確認します。**「アプリのパフォーマンスのトレース」** をクリックして、Langfuse や LangSmith などの外部可観測性プラットフォームに接続し、より深い分析を行います。
+時間セレクターを使用して、異なる期間のトレンドを確認します。**「アプリのパフォーマンスのトレース」** をクリックして、[Langfuse](/ja/self-host/use-dify/monitor/integrations/integrate-langfuse) や [LangSmith](/ja/self-host/use-dify/monitor/integrations/integrate-langsmith) などの外部可観測性プラットフォームに接続し、より深い分析を行います。
 
-Agent の場合は、Agent の **モニタリング** セクションから同じトレース設定を開きます。
-
-**Agent データ収集** の **内容を収集** をオンにすると、トレースに入力と出力が含まれます。対象は Agent アプリと、Agent ノードを含むワークフローです。この設定は Agent だけでなく、トレース内のすべてのノードに適用されます。
+[Agent](/ja/self-host/use-dify/build/new-agent/overview) の場合は、Agent の **モニタリング** セクションから同じトレース設定を開きます。この設定が適用されるのは、チャット、Web アプリ、API 呼び出しなど、Agent 自身の実行です。Agent が Workflow または Chatflow 内で実行される場合は、そのアプリのトレース設定が適用されます。
 
 <Note>
 Agent トレースはデフォルトで無効です。次の変数を設定して有効にします：
@@ -29,3 +27,10 @@ Agent トレースはデフォルトで無効です。次の変数を設定し
 
 詳細は [環境変数](/ja/self-host/deploy/configuration/environments#llmops-トレース配信) を参照してください。
 </Note>
+
+トレース設定の **Agent データ収集** で、トレースに含める内容を設定します。対象は Agent アプリと、[新しい Agent ノード](/ja/self-host/use-dify/nodes/agent#new-agent) を含むワークフローです。
+
+- **Agent の内部処理を収集**：Agent のモデル呼び出しとツール呼び出しです。これらのステップをトレースプロバイダーに送りたくない場合はオフにします。オフにすると、トレース上の Agent は 1 つのステップとして表示されます。
+- **内容を収集**：Agent だけでなく、トレース内のすべてのステップの入力と出力です。オンにすると、プロンプト、ユーザーメッセージ、応答がトレースプロバイダーに送信されます。
+
+それ以外のワークフロー（クラシック Agent ノードしかないものを含む）では、これらのスイッチを設定しても効果はありません。
diff --git a/ja/self-host/use-dify/nodes/agent.mdx b/ja/self-host/use-dify/nodes/agent.mdx
index 9f49ab70a..89a68e4ac 100644
--- a/ja/self-host/use-dify/nodes/agent.mdx
+++ b/ja/self-host/use-dify/nodes/agent.mdx
@@ -130,7 +130,7 @@ description: "ワークフローの 1 ステップとして Agent を実行し
   </Warning>
 
   <Note>
-  新しい Agent ノードはベータ版で、Workflow アプリでのみ使用できます。Docker Compose ではデフォルトで有効になっており、ランタイムも同梱されています。
+  新しい Agent ノードはベータ版です。Docker Compose ではデフォルトで有効になっており、ランタイムも同梱されています。Chatflow アプリで使うには、[`NEXT_PUBLIC_ENABLE_AGENT_V2_IN_CHATFLOW`](/ja/self-host/deploy/configuration/environments#next_public_enable_agent_v2_in_chatflow) を有効にしてください。
 
   本番環境では、[`DIFY_AGENT_SERVER_SECRET_KEY`](/ja/self-host/deploy/configuration/environments#dify_agent_server_secret_key) と [`DIFY_AGENT_API_TOKEN`](/ja/self-host/deploy/configuration/environments#dify_agent_api_token) を独自のランダムな値に置き換えてください。
   </Note>
@@ -230,5 +230,13 @@ description: "ワークフローの 1 ステップとして Agent を実行し
 
   モデルの回答にルートが含まれていないか、存在しないルートを指していると、ノードは失敗します。ワークフローを止めずに実行を続けるには、**例外処理** を **例外分岐** に設定し、その分岐をフォールバック先につなげてください。
 
+  <a id="in-a-chatflow"></a>
+
+  ## Chatflow での動作
+
+  各ターンは前のターンの続きから始まるため、Agent はユーザーがすでに伝えた内容を踏まえて作業を進められます。同じ Chatflow に Agent ノードが複数ある場合、記憶はノードごとに別々です。
+
+  **Agents** またはノード上で Agent を更新しても、進行中の会話は開始時の設定のまま動作します。変更を試すには、新しい会話を始めてください。
+
   </Tab>
 </Tabs>
diff --git a/zh/self-host/deploy/configuration/environments.mdx b/zh/self-host/deploy/configuration/environments.mdx
index 1378e59fd..40b77a7b6 100644
--- a/zh/self-host/deploy/configuration/environments.mdx
+++ b/zh/self-host/deploy/configuration/environments.mdx
@@ -1224,8 +1224,8 @@ Dify 发送邮件用于账户邀请、密码重置、登录验证码和人工输
 | 变量 | 默认值 | 说明 |
 |---|---|---|
 | `OPS_TRACE_UNIFIED_ENABLED` | `false` | 设为 `true` 后，LangSmith 和 Arize/Phoenix 的追踪数据采用统一结构，记录工作流运行、节点及其父子关系。默认值 `false` 保留各供应商原有的追踪实现。其他供应商不受影响。<br/><br/>各应用仍需单独开启 LLMOps 并配置供应商。 |
-| `OPS_AGENT_TRACE_ENABLED` | `false` | 设为 `true` 后，Agent 应用以及含 Agent 节点的 Workflow、Chatflow 应用，其追踪数据会包含 Agent 的模型调用和工具调用。应用调用的 [工作流工具](/zh/self-host/use-dify/workspace/tools#workflow) 内部的 Agent 不在其中。还需将 `DIFY_AGENT_APPLICATION_TRACING_ENABLED` 设为 `true`。<br/><br/>为 `false` 时，Agent、Workflow 和 Chatflow 应用的追踪设置中会提示 Agent 追踪不可用。各应用仍需单独开启追踪、配置供应商，并保持 **采集 Agent 内部过程** 开启（默认开启）。 |
-| `DIFY_AGENT_APPLICATION_TRACING_ENABLED` | `false` | Agent 后端一侧的开关，与 `OPS_AGENT_TRACE_ENABLED` 配套；两者都设为 `true` 才能追踪 Agent。<br/><br/>在 `docker/envs/core-services/dify-agent.env` 中设置，不要写在 `shared.env`：Agent 后端不读取这个文件。 |
+| `OPS_AGENT_TRACE_ENABLED` | `false` | 设为 `true` 后，Agent 应用以及含新 Agent 节点的 Workflow、Chatflow 应用，其追踪数据会包含 Agent 的模型调用和工具调用。应用调用的 [工作流工具](/zh/self-host/use-dify/workspace/tools#workflow) 内部的 Agent 不在其中。还需将 `DIFY_AGENT_APPLICATION_TRACING_ENABLED` 设为 `true`。<br/><br/>为 `false` 时，Agent、Workflow 和 Chatflow 应用的追踪设置中会提示 Agent 追踪不可用。各应用仍需单独开启追踪、配置供应商，并保持 **采集 Agent 内部过程** 开启（默认开启）。 |
+| `DIFY_AGENT_APPLICATION_TRACING_ENABLED` | `false` | Agent 后端一侧的开关，与 `OPS_AGENT_TRACE_ENABLED` 配套；两者都设为 `true` 才能追踪 Agent。<br/><br/>在 `docker/envs/core-services/dify-agent.env` 中设置，不要写在 `shared.env`：Agent 后端不读取这个文件。<br/><br/>开启后，如果 Agent 运行已由所在应用追踪，就会发往该应用的追踪供应商，不再进入 [轨迹导出](#agent-轨迹导出)。 |
 | `ENABLE_APPLICATION_TRACE_RECONCILE_TASK` | `true` | 仅在 `OPS_AGENT_TRACE_ENABLED` 为 `true` 时生效。每 30 秒运行一次后台任务，重新发送仍在等待投递的 Agent 追踪数据，并在保留期（默认 7 天）结束后删除 Dify 自己存储的 Agent 追踪数据。已经发送到追踪供应商的数据不受影响。 |
 | `OPS_TRACE_RETRYABLE_DISPATCH_MAX_RETRIES` | `780` | 追踪投递遇到瞬时失败后的最大重试次数，超出后该条追踪数据被丢弃。<br/><br/>默认重试窗口（次数 × `OPS_TRACE_RETRYABLE_DISPATCH_DELAY_SECONDS`）按覆盖一小时工作流上限加导出宽限期设定。<br/><br/>目前只有 Arize/Phoenix 追踪嵌套工作流时会触发（子追踪先于父级上下文到达）。不能设为 `0`。 |
 | `OPS_TRACE_RETRYABLE_DISPATCH_DELAY_SECONDS` | `5` | 两次重试的间隔秒数；总容忍窗口约为间隔 × 最大次数（默认约 65 分钟）。<br/><br/>调低可让嵌套追踪更快送达，但重试次数消耗更快。不能设为 `0`。 |
@@ -1435,10 +1435,16 @@ openssl rand -base64 32
 
 默认值：`true`
 
-在 Web 界面中显示新 Agent：主导航中的 **Agents** 项，以及工作流节点选择器中的新 Agent 节点。
+在 Web 界面中显示新 Agent：主导航中的 **Agents** 项，以及 Workflow 应用节点选择器中的新 Agent 节点。
 
 设为 `false` 可隐藏它并回退到经典 Agent 节点。此变量替代了 `ENABLE_AGENT_V2`，后者仍可作为回退。
 
+### NEXT_PUBLIC_ENABLE_AGENT_V2_IN_CHATFLOW
+
+默认值：`false`
+
+设为 `true` 后，Chatflow 应用的节点选择器中也会出现新 Agent 节点。仅在 `NEXT_PUBLIC_ENABLE_AGENT_V2` 为 `true` 时生效。
+
 ### UPLOAD_SKILL_FILE_SIZE_LIMIT
 
 默认值：`50`
@@ -1552,7 +1558,7 @@ API 访问 Agent 后端所用的地址。在 Docker Compose 中保持默认值
 - OpenShell 网关，版本不低于 0.0.106，且 `agent_backend` 容器能访问到它。
 - 网关凭证：Bearer 令牌、mTLS 客户端证书对，或两者兼有。Compose 未内置证书挂载，需自行将证书文件以只读方式挂载到 `agent_backend`，并确保 UID 1001 可读取。
 - 网关可用来启动沙箱的运行时镜像。
-- 一个共享卷，用于存放 Agent 跨对话保留的长期文件。该卷需在 Compose 之外创建，以免被 `docker compose down -v` 删除。
+- 一个共享卷，用于存放 Agent 跨对话保留的长期文件。该卷需在 Compose 之外创建，以免被 `docker compose down -v` 删除。如果部署要服务彼此不信任的租户，请为每个租户分别准备 OpenShell 工作空间和卷。多个租户共用一个卷时，无法可靠地阻止一个租户访问另一个租户的长期文件。
 - 沙箱回连 Dify 的网络路径：
   - 沙箱可访问的回调地址。
   - 通往 Agent 后端 `/agent-stub` 路径的路由。基础 Compose 文件没有发布 Agent 后端的 5050 端口。这个端口同时承载启动 Agent 运行的 API，所以不要整个暴露，只暴露 `/agent-stub` 路径，比如通过反向代理。
@@ -1578,7 +1584,7 @@ API 访问 Agent 后端所用的地址。在 Docker Compose 中保持默认值
 | `DIFY_AGENT_OPENSHELL_INSECURE` | `false` | 改用明文 gRPC 而非 TLS 连接网关，不使用 TLS 路径。若设置了 Bearer 令牌，仍会通过该连接发送。<br/><br/>仅用于对接明文网关的本地开发。 |
 | `DIFY_AGENT_OPENSHELL_WORKSPACE` | `default` | Agent 后端创建和管理沙箱所在的 OpenShell 工作空间。这是网关上的命名空间，不是 Dify 工作空间。 |
 | `DIFY_AGENT_OPENSHELL_SANDBOX_IMAGE` | `docker.io/library/dify-agent-runtime:latest` | 网关为每个沙箱启动的容器镜像。默认值即 OpenShell 配置指南中构建命令生成的标签。<br/><br/>网关的计算驱动必须能取到该镜像，只放在运行 Dify 的 Docker 守护进程上还不够：将镜像加载到网关的 Docker 守护进程中，或推送到网关可拉取的镜像仓库，并在此填写对应的镜像引用。<br/><br/>请显式设置此变量。若没有任何 env 文件设置它，Agent 后端会回退到 `langgenius/dify-agent-local-sandbox:latest`，该镜像可能版本较旧，无法在 OpenShell 下启动。 |
-| `DIFY_AGENT_OPENSHELL_DRIVER_CONFIG` | （空） | 使用 `openshell` 后端时必填。网关的计算驱动会给每个沙箱应用一份 JSON 配置，这份配置必须把共享卷挂载到 `DIFY_AGENT_OPENSHELL_SHARED_MOUNT_PATH`。具体结构取决于驱动。<br/><br/>JSON 无效或为空对象时，Agent 后端无法启动。Dify 不检查挂载本身，即使共享卷挂载到了其他路径，Agent 后端也会照常启动，因此请仔细核对挂载目标。<br/><br/>Docker 驱动示例：`{"docker":{"mounts":[{"type":"volume","source":"dify-agent-shared","target":"/mnt/dify-agent-shared","read_only":false}]}}` |
+| `DIFY_AGENT_OPENSHELL_DRIVER_CONFIG` | （空） | 使用 `openshell` 后端时必填。网关的计算驱动会给每个沙箱应用一份 JSON 配置，这份配置必须把共享卷挂载到 `DIFY_AGENT_OPENSHELL_SHARED_MOUNT_PATH`。具体结构取决于驱动。<br/><br/>JSON 无效或为空对象时，Agent 后端无法启动。Dify 不检查挂载本身，即使共享卷挂载到了其他路径，Agent 后端也会照常启动，因此请仔细核对挂载目标。<br/><br/>Docker 驱动示例（单租户，例如本地开发）：`{"docker":{"mounts":[{"type":"volume","source":"dify-agent-shared","target":"/mnt/dify-agent-shared","read_only":false}]}}` |
 | `DIFY_AGENT_OPENSHELL_SHARED_MOUNT_PATH` | `/mnt/dify-agent-shared` | 共享卷在每个沙箱内的挂载位置，必须与 `DIFY_AGENT_OPENSHELL_DRIVER_CONFIG` 中的挂载目标一致。每次在 Agent 的构建对话中点击 **应用** 时，Agent 的长期文件都会保存到这里。<br/><br/>必须为绝对路径，否则 Agent 后端无法启动。 |
 | `DIFY_AGENT_OPENSHELL_SHELLCTL_AUTH_TOKEN` | （空） | 使用 `openshell` 后端时必填，未设置时 Agent 后端无法启动。Agent 后端会在每个沙箱内启动命令服务，并用这个共享密钥向该服务证明身份。可设为任意随机字符串。<br/><br/>与保护内置沙箱的 `DIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKEN` 相互独立。 |
 | `DIFY_AGENT_OPENSHELL_EGRESS_ALLOW` | （空） | 沙箱允许连接的 `host:port` 端点，以逗号分隔，不带协议前缀或路径。留空时不下发网络策略，出站访问遵循网关的默认设置。<br/><br/>设置后，沙箱只能访问列出的端点，除非列出相应主机，否则安装软件包、访问网页都会失败。需包含 `DIFY_AGENT_STUB_API_BASE_URL` 和 `DIFY_AGENT_SANDBOX_FILES_BASE_URL` 的主机，否则 Agent 运行无法回调 Dify。<br/><br/>任一条目格式有误，Agent 后端都无法启动。<br/><br/>示例：`agent.example.com:443,dify.example.com:443` |
@@ -1591,11 +1597,13 @@ API 访问 Agent 后端所用的地址。在 Docker Compose 中保持默认值
 
 ### Agent 轨迹导出
 
-想在已有的追踪后端中查看 Agent 做了什么，可开启轨迹导出。开启后，Agent 后端会通过 OTLP/HTTP 把每次 Agent 运行的追踪数据（包括模型请求和工具调用）发送到 OpenTelemetry 收集器。部署中所有工作空间的运行都发往同一个收集器。
+想在已有的追踪后端中查看 Agent 做了什么，可开启轨迹导出。开启后，Agent 后端会通过 OTLP/HTTP 把 Agent 运行的追踪数据（包括模型请求和工具调用）发送到 OpenTelemetry 收集器。部署中所有工作空间的运行都发往同一个收集器。
 
 每个 span 都带有所属工作空间、应用、Agent、终端用户、对话、工作流运行和节点的 ID，因此可按 `dify.app_id`、`dify.conversation.id` 等属性，把追踪数据筛选到单个应用或单个对话。即使关闭内容导出，这些 ID 也会导出。
 
-轨迹导出独立于 [LLMOps 追踪投递](#llmops-追踪投递)（由应用构建者为每个应用单独配置 Langfuse 等供应商），也独立于 API 和 Worker 的 [OpenTelemetry 插桩](#otlp-/-opentelemetry-配置)，两者的设置都不影响轨迹导出。
+轨迹导出独立于 API 和 Worker 的 [OpenTelemetry 插桩](#otlp-/-opentelemetry-配置)。
+
+[LLMOps 追踪投递](#llmops-追踪投递) 则会影响它。LLMOps 追踪投递需要应用开发者在每个应用中单独配置 Langfuse 等供应商。在其中开启 Agent 追踪后，已由所在应用追踪的运行只发往该应用的追踪供应商，其余 Agent 运行仍进入收集器。
 
 按以下步骤开启轨迹导出：
 
diff --git a/zh/self-host/use-dify/build/new-agent/build.mdx b/zh/self-host/use-dify/build/new-agent/build.mdx
index 614384ec8..004c189ab 100644
--- a/zh/self-host/use-dify/build/new-agent/build.mdx
+++ b/zh/self-host/use-dify/build/new-agent/build.mdx
@@ -223,11 +223,11 @@ Agent 工作时会直接修改面板中的配置，所有更改都会列在 **Bu
 
 <AccordionGroup>
   <Accordion title="导航中没有 Agents 入口，节点列表中也没有 Agent 节点">
-    部署的 `.env` 早于 1.16.0，Agents 开关缺失或仍处于关闭状态。
+    如果只有 Chatflow 应用里没有该节点，请开启 [`NEXT_PUBLIC_ENABLE_AGENT_V2_IN_CHATFLOW`](/zh/self-host/deploy/configuration/environments#next_public_enable_agent_v2_in_chatflow)，它默认关闭。
 
-    将它与 `.env.example` 同步（开关是 [`NEXT_PUBLIC_ENABLE_AGENT_V2`](/zh/self-host/deploy/configuration/environments#next_public_enable_agent_v2)），然后重建 web 容器（`docker compose up -d web`）并强制刷新浏览器。
+    如果 Workflow 应用里也没有，或导航中没有 Agents 入口，说明部署的 `.env` 早于 1.16.0，Agents 开关缺失或仍处于关闭状态。
 
-    在 Chatflow 应用中看不到该节点则属正常：新 Agent 节点仅在 Workflow 应用中可用。
+    将它与 `.env.example` 同步（开关是 [`NEXT_PUBLIC_ENABLE_AGENT_V2`](/zh/self-host/deploy/configuration/environments#next_public_enable_agent_v2)），然后重建 web 容器（`docker compose up -d web`）并强制刷新浏览器。
 
     若其他成员能看到 **Agents** 而你看不到，原因在于你的工作空间角色：该入口需要「编辑」及以上角色。
   </Accordion>
diff --git a/zh/self-host/use-dify/build/skills.mdx b/zh/self-host/use-dify/build/skills.mdx
index a79aa2674..fd0c3bb1f 100644
--- a/zh/self-host/use-dify/build/skills.mdx
+++ b/zh/self-host/use-dify/build/skills.mdx
@@ -15,7 +15,7 @@ Skill 库最多可保存 500 个 Skill，并在整个工作空间内共享。发
 Skill 可用于：
 
 - [Agent 应用](/zh/self-host/use-dify/build/new-agent/build#skills)
-- Workflow 应用中的 [新 Agent 节点](/zh/self-host/use-dify/nodes/agent#new-agent)
+- Workflow 和 Chatflow 应用中的 [新 Agent 节点](/zh/self-host/use-dify/nodes/agent#new-agent)
 
 <Info>
 创建和管理 Skill 需要编辑及以上角色。
diff --git a/zh/self-host/use-dify/monitor/analysis.mdx b/zh/self-host/use-dify/monitor/analysis.mdx
index a7d28957d..6f3aae3f9 100644
--- a/zh/self-host/use-dify/monitor/analysis.mdx
+++ b/zh/self-host/use-dify/monitor/analysis.mdx
@@ -16,17 +16,22 @@ description: "通过 Dify 内置的分析仪表盘监控性能、成本和用户
 **Average User Interactions**：每次会话的参与深度  
 **Token Usage**：资源消耗和成本
 
-使用时间选择器查看不同时间段的趋势。点击 **"Tracing app performance"** 以连接外部可观察性平台，如 Langfuse 或 LangSmith，以获得更深入的分析。
+使用时间选择器查看不同时间段的趋势。点击 **"Tracing app performance"** 以连接外部可观察性平台，如 [Langfuse](/zh/self-host/use-dify/monitor/integrations/integrate-langfuse) 或 [LangSmith](/zh/self-host/use-dify/monitor/integrations/integrate-langsmith)，以获得更深入的分析。
 
-Agent 也有同样的追踪设置，在它的 **监控** 区域中打开。
-
-在 **Agent 数据采集** 下开启 **采集内容** 后，Agent 应用和含 Agent 节点的工作流发出的追踪数据才会带上输入和输出。这个开关管的是整条追踪里的所有节点，不只是 Agent。
+[Agent](/zh/self-host/use-dify/build/new-agent/overview) 也有同样的追踪设置，在它的 **监控** 区域中打开。这些设置只作用于 Agent 自己的运行，比如它的对话、Web 应用和 API 调用。Agent 在 Workflow 或 Chatflow 应用中运行时，以该应用的追踪设置为准。
 
 <Note>
-Agent 追踪默认关闭。通过设置以下变量启用：
+Agent 追踪默认关闭。设置以下变量即可启用：
 
 - `OPS_AGENT_TRACE_ENABLED` = `true`
 - `DIFY_AGENT_APPLICATION_TRACING_ENABLED` = `true`
 
 详见 [环境变量](/zh/self-host/deploy/configuration/environments#llmops-追踪投递)。
 </Note>
+
+追踪设置里的 **Agent 数据采集** 用来决定追踪数据包含哪些内容，适用于 Agent 应用和含 [新 Agent 节点](/zh/self-host/use-dify/nodes/agent#new-agent) 的工作流：
+
+- **采集 Agent 内部过程**：Agent 的模型调用和工具调用。不想把这些步骤发给追踪供应商时，可关闭它，追踪中的 Agent 随之只显示为一个步骤。
+- **采集内容**：追踪中每个步骤（不只是 Agent）的输入和输出。开启后，提示词、用户消息和回复都会发送到追踪供应商。
+
+其他工作流（包括只含经典 Agent 节点的工作流）中，这两个开关都不起作用。
diff --git a/zh/self-host/use-dify/nodes/agent.mdx b/zh/self-host/use-dify/nodes/agent.mdx
index fbde59502..3ee9415bd 100644
--- a/zh/self-host/use-dify/nodes/agent.mdx
+++ b/zh/self-host/use-dify/nodes/agent.mdx
@@ -130,7 +130,7 @@ description: 将 Agent 作为工作流中的一步运行，通过推理和调用
   </Warning>
 
   <Note>
-  新 Agent 节点目前处于 Beta 阶段，仅在 Workflow 应用中可用。它在 Docker Compose 部署中默认启用，运行时也已随部署打包。
+  新 Agent 节点目前处于 Beta 阶段。它在 Docker Compose 部署中默认启用，运行时也已随部署打包。在 Chatflow 应用中，需要开启 [`NEXT_PUBLIC_ENABLE_AGENT_V2_IN_CHATFLOW`](/zh/self-host/deploy/configuration/environments#next_public_enable_agent_v2_in_chatflow) 后才能使用。
 
   生产环境使用前，将 [`DIFY_AGENT_SERVER_SECRET_KEY`](/zh/self-host/deploy/configuration/environments#dify_agent_server_secret_key) 和 [`DIFY_AGENT_API_TOKEN`](/zh/self-host/deploy/configuration/environments#dify_agent_api_token) 替换为你自己的随机值。
   </Note>
@@ -230,5 +230,13 @@ description: 将 Agent 作为工作流中的一步运行，通过推理和调用
 
   如果模型的回答里缺少路由，或给出的路由并不存在，节点就会失败。要让工作流继续运行，可将 **异常处理** 设为 **异常分支**，再把这条分支连到兜底步骤。
 
+  <a id="in-a-chatflow"></a>
+
+  ## 在 Chatflow 中
+
+  对话中的每一轮都会延续前面的内容，Agent 可直接用上用户已经说过的信息。同一个 Chatflow 中的两个 Agent 节点各自保留记忆。
+
+  在 **Agents** 中或在节点上更新 Agent 后，进行中的对话仍沿用开始时的配置。要试用改动，请开启新对话。
+
   </Tab>
 </Tabs>