superagent请求问题修复

docs/workflows/user-chat.md

@@ -42,6 +42,13 @@ Network 应显示同源 POST 到精确 app ID 的 completion 路径，Request He
 发送第二个问题时，应在第二次请求中看到上一轮返回的 `session_id` 被放入 `input.session_id`。不要把初始 `finish_reason=null` 或
 断流内容当作最终答案。
 
+页面客户端看到的成功契约不随上游 Trace 开关变化，始终以兼容流最后的
+`output.finish_reason=stop` 为准。服务端到 SuperAgent 的严格判定由
+`FIRE_SAFETY_SUPERAGENT_INCLUDE_TRACE` 控制：默认 `false` 时要求上游最终 AI 消息
+`finish_reason=stop`、非空顶层 `message.final` 和顶层 `event: end`；设置为 `true` 时还要求
+`run.completed(status=success)`。无 Trace 只是不返回工具/步骤轨迹，不代表 SuperAgent 不会
+调用 MCP；要确认 MCP 是否实际执行，必须同时检查服务日志和工具结果。
+
 ## 3. 后续对话
 
 后续请求同时发送 `message` 和前一轮保存的 `conversation_id`。成功流中的 `conversation` 事件返回 `reused=true`，说明复用了原 SuperAgent Session 上下文。
@@ -56,6 +63,12 @@ Network 应显示同源 POST 到精确 app ID 的 completion 路径，Request He
 - 上游超时、协议错误、Run 失败或客户端中途断开：当前实现会使会话映射失效，以免继续复用可能仍有活动 Run 的 Provider Session。
 - 网络断开且没有看到 `done`：结果未知；首版不自动重放原消息，避免重复 Run。
 
+如果上游返回 `open_agent_trace_disabled` 或 HTTP 403，先检查是否将
+`FIRE_SAFETY_SUPERAGENT_INCLUDE_TRACE` 设置为 `true`。当前应用策略关闭 Trace 时，使用
+`include_trace=true` 会被拒绝；同一 Key 使用默认的 `include_trace=false` 可以返回 HTTP 200。
+只有在外部应用策略明确启用 `trace_policy.enabled=true` 后，才应切换为 `true`。修改环境变量后
+必须重建或重新创建运行容器，不能只依赖 `docker compose restart` 重新读取配置。
+
 ## 5. curl 联调
 
 先把 `.env` 显式加载到当前 shell，再启动服务；Go 程序不会自动读取 `.env`：