国安局、网信办要求关闭。

故只展示搜索深度搜索的效果：

md
你是一个深度研究助手，你会使用搜索引擎对用户提出的问题进行深度搜索，并给出调研报告。

# 用户问题：
{{question}}

# 追问对话：
{{re-question}}     
    
# 当前已知资料
{{reference}}

# 当前环境信息
{{meta_info}}

## 需求分析
- 将用户的问题转换为一个个具体的子问题
- 如果用户的问题不够清晰，可以追问用户

## 需求检查
- 若选择追问用户，则不进行搜索和解答，而是提出问题的可能性引导用户，具体提问内容和方向
- 若存在追问环节，则务必遵循先进行追问环节的交互后，才可进入搜索分析环节
- 每轮追问后，获得觉得追问对话仍然不够精准，可持续追问环节最多不超过三轮
- 若存在追问环节，若无用户的许可，则不可直接跳过追问环节
- 最终，对追问环节收集到的用户精准问题充分理解，分析丰富用户的最终需求，优化整理拆解为最终版本的子问题，进行搜索和爬虫环节

## 搜索技巧
- 不要在一次搜索中搜索多个话题，而是拆分为多次搜索
- 对于非地域相关问题，可以使用英文搜索来获取更多信息
- 直接搜索没有得到答案时，尝试使用宽泛的搜索词从侧面获取信息
- 搜索词不要过于偏离主题
- 如果「当前已知资料」还不够全面，或者某些问题细节未被完全覆盖，思考还需要搜索什么信息，输出对应的关键词
- 请确保你的关键词既具体又有足够的搜索价值，能够获取到新的、有补充意义的信息
- 输出的每个关键词要具体到可用于独立检索，包括完整的主语和宾语，避免歧义和代词，不同关键词之间不能有指代关系
- 当你已经无法获得更多对主题有用的信息时，停止搜索
- 如果在搜索过程中发现了新的有价值的话题，沿着这个路径继续搜索

## 爬虫搜集
- 对于有价值的网页，使用爬虫工具获取完整内容
- 注意根据网站的权威情况判断爬取价值
- 调用爬虫时不要重复访问链接

## 检查
- 仔细判断「当前已知资料」是否已经足够全面地回答用户的问题
- 只有在确定「当前已知资料」已经覆盖了全部拆分的话题，和多次搜索后，才进行最终回答

## 输出（你的回答）
- 以 Markdown 格式输出专业调研报告
- 标注数据来源
- 合理运用表格、mermaid 等多种手段直观展示数据

深度研究助手 Docker 镜像部署手册

一、镜像打包和上传

1. 准备工作

bash
# 确保在项目根目录
cd deep_research

# 检查 Docker 是否运行
docker info

# 确保已登录 Docker Hub
docker login

2. 构建镜像

bash
# 方法一：使用脚本自动构建（推荐）
./build-slim.sh

# 方法二：指定构建Linux 版本
## MacOS (ARM架构)
TARGET_PLATFORM=linux/arm64 ./build-slim.sh
## Linux (x86架构)
TARGET_PLATFORM=linux/amd64 ./build-slim.sh

# 方法三：手动构建 Linux 版本
docker build --platform=linux/amd64 \
    --build-arg BUILDPLATFORM=linux/amd64 \
    --build-arg TARGETPLATFORM=linux/amd64 \
    -t golovin0623/deep-research:amd64-slim \
    -f Dockerfile.slim .

本地调试步骤

1. 环境准备

• 安装Python 3.9+（小于3.12）
• 安装Poetry 1.6.1：pip install poetry==1.6.1
• 获取火山方舟API KEY：访问 火山方舟控制台
• 开通DeepSeek-R1模型：在 开通管理页 完成

2. 选择搜索引擎

选择一：使用火山方舟零代码联网应用

• 创建零代码联网应用，获取bot id

• 推荐配置：

  • 推理接入点：Doubao-pro-32k / Doubao-pro-1.5-32k
  • 联网内容插件：开启
  • 智能改写：关闭
  • 调用方式：强制开启
  • 参考资料回复：自定义回复 选择二：使用Tavily搜索引擎

• 获取 Tavily API KEY

New-API 开发调试手册

1. 环境准备

• Node.js 环境
• Go 开发环境
• Git
• 编辑器（推荐 VSCode 或 GoLand）

2. 项目初始化

bash
# 克隆项目
git clone https://github.com/Calcium-Ion/new-api.git
cd /Users/liangfeng/evn/projects/new-api

# 创建环境配置文件
cp .env.example .env

3. 开发模式一：前端开发模式

适用于主要进行前端代码修改的场景。

3.1 启动后端服务

bash
cd /Users/liangfeng/evn/projects/new-api
FRONTEND_BASE_URL=http://localhost:5173 go run main.go

生产环境数据库数据异常丢失问题复盘排查报告

1. 问题概述

生产环境中，一个基于 SOFA 框架的定时任务在执行过程中，出现了严重的数据不一致现象：任务调度执行上游服务 A 创建指令数据，服务 A 在逻辑中（同事通过手动事务）进行了提交；随后调用服务 B，服务 B 能成功查询到该指令数据，但在尝试更新数据状态时失败（异常被内部捕获处理）。然而，流程结束后检查数据库，发现服务 A 创建的指令数据完全消失，且数据库层面未记录到该数据的成功提交日志。此现象不符合预期的业务逻辑和数据库 ACID 特性。

令人比较费解的是，尽管在异常流程中，服务 B 能够成功查询到由服务 A 创建的数据，并且其内部尝试更新数据时发生的失败异常得到了妥善的捕获和处理（未向外抛出），服务 A 创建的本应持久化的数据最终却从数据库中完全消失，同时数据库层面也未能追踪到该数据成功提交的事务日志。

后续通过一项关键的验证步骤——在生产环境中临时移除对服务 B 的调用后，此数据丢失问题便不再复现。

2. 问题背景与详细现象描述

• 技术环境:
  • 应用框架: SOFA 框架
  • 核心组件: 定时任务调度机制
  • 数据库: MySQL
  • 事务管理: 主要依赖 Spring 的声明式事务 (@Transactional)，但服务 A 早期被描述为“手动提交事务”，可能存在手动 JDBC 事务代码与 @Transactional 的混合使用。系统中未使用分布式事务中间件（如 Seata）。
• 业务流程:
  1. SOFA 定时任务按预定时间触发。
  2. 定时任务调用服务 A 的业务逻辑。
  3. 服务 A: 生成一条指令数据，并将其持久化到数据库。
  4. 服务 A: 调用服务 B 的接口，传递相关指令信息。
  5. 服务 B: 接收到调用后，首先根据指令 ID 查询数据库，验证指令是否存在。
  6. 服务 B: 如果查询到指令，则尝试更新该指令的状态等信息。
• 异常现象详细记录:
  • (✓) 查询成功: 服务 B 在执行更新逻辑前，通过日志确认能够成功查询到由服务 A 创建并（理论上已）保存的指令数据。
  • (✗) 更新失败: 服务 B 在对该指令数据执行 UPDATE 操作时发生错误。具体错误原因未在本次排查中明确（可能是锁竞争、约束违反等），但这本身不是数据丢失的直接原因。
  • (✓) 异常内部处理: 服务 B 的代码使用了 try-catch 块捕获了 UPDATE 操作抛出的异常，仅在日志中打印了 error 信息，没有将异常重新抛出。因此，从调用栈来看，服务 B 的方法是“正常”返回给服务 A 的。
  • (✓) 后续流程正常: 服务 B 捕获异常后，其后续的业务代码（如果有的话）继续执行，并且调用服务 B 的服务 A 以及整个定时任务的后续流程（如果服务 A/定时任务在调用 B 后还有其他步骤）在日志层面看起来是正常执行完毕的，没有记录到其他的业务或框架级异常。
  • (✗) 数据最终丢失: 在整个定时任务执行完毕后，通过数据库客户端或后续查询发现，服务 A 最初创建的那条指令数据在数据库中消失了，无法找到。
  • (✗) 无数据库提交日志: DBA 通过检查数据库的相关日志（如 Binlog、Commit Log 等），确认没有找到服务 A 创建的那条指令数据的最终成功提交记录。
  • (✓) 无显式删除逻辑: 通过代码审查，确认在服务 A 或服务 B 的正常业务逻辑以及异常处理逻辑中，没有显式编写 DELETE 语句来删除这条指令数据的代码。