从 OpenClaw 到各类 AI 热潮,企业对"数字员工"的期待已经从"能对话"升级为"能干活"。DeepChat 这次更名为 DeepWork,不只是换了个名字——底层框架、向量存储、RAG 架构全部重写,是一次真正意义上的技术重构。
换框架:从自建到 Spring AI
这次更新最硬的改动是把 AI 框架换成了 Spring AI + Spring AI Alibaba。之前 DeepChat 大概率是自建了一套对话管线,现在直接站到 Spring 生态里,好处很直接:
- 对齐 Spring Boot 的依赖管理和自动配置,减少自维护成本
- Spring AI Alibaba 提供了对通义千问等国产模型的适配,省去自己写 Provider
- ChatClient、Advisor、Tool Calling 等抽象已经成型,不用从零搭 Agent 管线
一个最小可运行的 Spring AI Alibaba 对话配置大概是这样:
# application.yml
spring:
ai:
dashscope:
api-key: ${DASHSCOPE_API_KEY} # 从环境变量读取,别硬编码
chat:
options:
model: qwen-plus
temperature: 0.7
// ChatController.java
@RestController
@RequestMapping("/api/chat")
public class ChatController {
private final ChatClient chatClient;
public ChatController(ChatClient.Builder builder) {
// Builder 模式,方便后续挂 Advisor 和 Tool
this.chatClient = builder.build();
}
@PostMapping
public String chat(@RequestBody String userMessage) {
return chatClient.prompt()
.user(userMessage)
.call()
.content();
}
}
启动前确保环境变量 DASHSCOPE_API_KEY 已设置,pom.xml 里加上 spring-ai-alibaba-starter 依赖即可跑起来。后续要加 Function Calling 或 RAG,都是在 ChatClient.Builder 上挂 Advisor,不用改核心流程。
PostgreSQL 当向量库:砍掉一个组件依赖
之前快速启动要额外拉一个 Milvus 或 Chroma,现在默认向量库改成 PostgreSQL(pgvector 扩展)。演示环境用的是 Supabase——它底层就是带 pgvector 的 PostgreSQL,免费层够跑 demo。
这个决策的权衡很清晰:
| 方面 | pgvector | 专用向量库(Milvus等) |
|---|---|---|
| 运维成本 | 和业务库共享实例 | 需要独立部署和维护 |
| 数据一致性 | 向量和业务数据在同一事务 | 跨系统,需同步机制 |
| 极大规模性能 | 百万级以上会吃力 | 专为高维检索优化 |
| 启动门槛 | Docker 一个容器搞定 | 多个组件 + 配置 |
对于大多数企业内部助手场景,文档量在十万级以内,pgvector 完全够用。Spring AI 已经内置了 PgVectorStore:
// 向量存储配置
@Bean
VectorStore vectorStore(EmbeddingModel embeddingModel, JdbcTemplate jdbcTemplate) {
return PgVectorStore.builder(jdbcTemplate, embeddingModel)
.dimension(1536) // 和你用的 Embedding 模型维度对齐
.tableName("deepwork_vectors")
.initializeSchema(true) // 首次启动自动建表
.build();
}
-- Flyway 迁移脚本:V1__init_pgvector.sql
-- 确保扩展已安装(Supabase 默认已开启)
CREATE EXTENSION IF NOT EXISTS vector;
-- PgVectorStore 的 initializeSchema=true 会自动建表,
-- 但如果你要自定义字段或索引,可以手动写:
CREATE TABLE IF NOT EXISTS deepwork_vectors (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
content TEXT,
metadata JSONB,
embedding VECTOR(1536)
);
-- HNSW 索引,检索性能的关键
CREATE INDEX IF NOT EXISTS deepwork_vectors_idx
ON deepwork_vectors USING hnsw (embedding vector_cosine_ops);
注意 dimension 必须和 Embedding 模型输出维度一致——通义千问的 text-embedding-v3 是 1024 维,OpenAI 的 text-embedding-3-small 是 1536 维,别搞混了。
Flyway 入场:数据库版本化
这次集成了 Flyway,实现数据库自动升级。之前每次版本更新,用户要手动跑 SQL 脚本,容易漏步骤导致启动失败。现在 Flyway 在应用启动时自动执行迁移,顺序和完整性都有保障。
实际操作很简单——在 resources/db/migration 下按命名规则放 SQL 文件:
src/main/resources/db/migration/
├── V1__init_pgvector.sql
├── V2__create_agent_config.sql
├── V3__add_workspace_table.sql
# application.yml - Flyway 配置
spring:
flyway:
enabled: true
locations: classpath:db/migration
baseline-on-migrate: true # 已有数据库时首次启用 Flyway 需要
baseline-on-migrate=true 是关键——如果你是从旧版 DeepChat 升级上来,数据库里已经有表了,不加这个 Flyway 会报错认为基线缺失。新部署的环境可以不管。
RAG → 智能体:从检索增强到任务执行
这次更新把 RAG 全面转换为智能体(Agent),这是架构层面最大的变化。传统 RAG 是"检索 → 拼接 → 生成"的线性流程,智能体则是"感知 → 规划 → 工具调用 → 反思"的循环结构。
用 Spring AI 的术语说,就是从 QuestionAnswerAdvisor 升级到带 Tool Calling 的 Agent 循环:
// Agent 配置示例:带工具调用的数字员工
@Bean
ChatClient agentClient(ChatClient.Builder builder,
VectorStore vectorStore,
TaskTool taskTool) {
return builder
.defaultAdvisors(
// 1. RAG 仍然在,但作为 Agent 的一个工具而非唯一路径
new QuestionAnswerAdvisor(vectorStore),
// 2. 可以挂更多 Advisor:日志、限流、记忆等
new SimpleLoggerAdvisor()
)
.defaultTools(taskTool) // 注册自定义工具
.defaultSystem("""
你是 DeepWork 数字员工助手。
当用户提出任务时,先判断需要哪些工具:
- 查内部文档:使用向量检索
- 创建/查询任务:使用 task 工具
- 不确定时,先检索再行动,不要直接编造答案。
""")
.build();
}
// 自定义工具:让 Agent 能操作业务系统
@Component
public class TaskTool {
@Tool(description = "创建一个工作任务,参数:标题、描述、优先级")
public String createTask(String title, String description, String priority) {
// 实际实现调用你的任务管理 API
return "任务已创建: " + title + " (优先级: " + priority + ")";
}
@Tool(description = "查询指定状态的任务列表")
public String listTasks(String status) {
// 实际实现查询数据库或外部系统
return "待办任务: 3条; 进行中: 2条";
}
}
关键区别:RAG 模式下,用户问"怎么提交报销",系统检索文档后拼一段回答;Agent 模式下,系统检索文档后,还可以调用 createTask 直接帮你建一个报销任务。从"告诉你怎么做"变成"帮你做"——这才是 DeepWork 名字的含义。
升级路径与注意事项
如果你是从旧版 DeepChat 迁移,几件事要提前准备:
- 数据库迁移:启动前确认 Flyway 配置了
baseline-on-migrate=true,否则已有表会被当成冲突 - 向量数据迁移:如果之前用的是 Milvus/Chroma,需要写脚本把向量数据导出再灌进 pgvector,维度要对齐
- API Key 管理:Spring AI Alibaba 的 Key 通过 Spring 的外部化配置读取,别在代码里硬编码
- Agent 工具注册:旧版的 RAG 流程要拆解成 Advisor + Tool 的组合,不是简单替换
新部署则更简单——一个 PostgreSQL(或直接用 Supabase 免费层)+ 一个 Spring Boot 应用,Docker Compose 两行搞定:
# docker-compose.yml - 最小启动
services:
postgres:
image: pgvector/pgvector:pg16
environment:
POSTGRES_DB: deepwork
POSTGRES_PASSWORD: ${DB_PASSWORD}
ports:
- "5432:5432"
volumes:
- pgdata:/var/lib/postgresql/data
deepwork:
image: deepwork:latest # 替换为实际镜像名
environment:
SPRING_AI_DASHSCOPE_API_KEY: ${DASHSCOPE_API_KEY}
SPRING_DATASOURCE_URL: jdbc:postgresql://postgres:5432/deepwork
SPRING_DATASOURCE_PASSWORD: ${DB_PASSWORD}
SPRING_FLYWAY_BASELINE_ON_MIGRATE: true
depends_on:
- postgres
ports:
- "8080:8080"
volumes:
pgdata:
先 docker compose up postgres,等数据库就绪后再启动 deepwork 服务,Flyway 会自动完成建表和索引创建。
DeepWork 这次重构的核心逻辑很清晰:用 Spring 生态换掉自建管线,用 pgvector 换掉独立向量库,用 Agent 换掉线性 RAG——每一步都在降低部署复杂度、提升可扩展性。对于想搭企业数字员工的团队,这套架构的起步成本已经压到了"一个数据库 + 一个 Spring Boot 应用"的程度,值得认真看一眼源码。