Julep：给 AI Agent 打造的「中央厨房」

你有没有这种感觉——现在的 AI 助手越来越聪明了，但每次想让它帮你做一件稍微复杂一点的事情，比如「帮我查一下最新的 AI 新闻，总结成报告，发到我的邮箱」，你就会发现：它好像只能做一件事，说完就忘了。

这不是 AI 不够聪明，而是缺少一个调度中枢——没有人告诉 AI「第一步做什么、第二步做什么、中间结果存在哪里、遇到错误怎么办」。Julep 解决的就是这个问题。

从一次「翻车」说起

2023 年底，一位独立开发者 Peter 想要做一个「AI 研究助手」：让 AI 自动搜索新闻、提取关键信息、生成摘要报告、自动发邮件。他尝试了各种 LangChain 方案，最后拼出来一套脚本，跑是能跑，但第二天打开一看——

整个流程断了。

问题出在哪里？他自己也说不清楚：可能是 API 超时，可能是中间结果没存下来，也可能是某一步的输出格式变了。这套「AI 工作流」本质上是一盘散沙，没有任何调度机制、状态管理和容错能力。

Julep 就是为这类场景设计的。它的核心理念很简单：把 AI Agent 的工作流做成一个「厨房流水线」，每个环节标准化、每个步骤可追溯、出了问题能重试。

架构拆解：11 个服务各司其职

Julep 并不是一个单独的应用程序，而是一套微服务架构，包含以下核心组件：

1. agents-api（主厨） 这是整个系统的 CPU，负责定义 Agent（代理）、定义 Task（任务）、管理 Execution（执行）。Agent 持有对话记忆，Task 定义工作流逻辑，Execution 是实际运行实例。代码位于 src/agents-api/agents_api/，核心模块包括：

• routers/ — REST API 路由层
• workflows/ — 任务执行引擎
• worker/ — 后台任务处理器
• activities/ — Temporal 工作流活动单元
• autogen/ — AutoGen 多智能体协作支持
• rec_sum/ — 推荐摘要模块
• queries/ — 数据库查询
• clients/ — 外部服务客户端

2. memory-store（仓库管理员） 基于 PostgreSQL + 向量数据库（CozoDB），负责持久化存储所有数据：Agent 定义、Session 对话历史、Document 文档、File 文件、Secret 密钥。提供 RAG（检索增强生成）所需的向量检索能力。

3. scheduler + Temporal（流水线调度员） 底层使用 Temporal 工作流引擎（类似分布式 Cron + 状态机）。所有异步任务、定时任务、长时任务都在这里调度。这意味着即使某个步骤耗时 30 分钟，Julep 也能保证它最终完成，不会因为进程重启而丢失。

4. llm-proxy（外卖接线员） 基于 LiteLLM，是系统的统一 LLM 网关。一个 API 请求可以路由到 OpenAI GPT-4、Anthropic Claude、Groq、Mistral 等任意 provider，无需修改业务代码。这相当于给所有 AI 模型开了一个「万能转接头」。

5. integrations-service（工具箱） Julep 支持为 Agent 挂载 Tools（工具）：搜索网页、读写文件、调用 API、发邮件、管理日历……这些工具的连接器都在这里。通过 MCP（Model Context Protocol）协议，还可以连接 Browserbase（浏览器自动化）、Spider（网页爬取）、Brave Search（搜索）等外部服务。.mcp.json 文件定义了 MCP 服务器配置。

6. gateway（前台接待） 基于 Traefik 的 API 网关，负责 JWT 鉴权、路由分发。支持单租户（一个 API Key 走天下）和多租户（每个开发者有独立 ID）两种模式。

7. 其他配套服务

• hasura — GraphQL 引擎，提供灵活的数据库查询接口
• analytics — 数据分析（Metabase）
• feature-flags — 基于 Unleash 的特性开关
• blob-store — SeaweedFS 对象存储，用于存放大文件（如 AI 生成的视频、音频）
• monitoring — Grafana 监控面板

核心技术栈

整个后端以 Python 为主（FastAPI + Pydantic），前端 SDK 提供 Python（pip install julep）和 Node.js（npm install @julep/sdk）两种选择。工作流定义支持 YAML 语法，CLI 工具 julep 提供命令行管理能力。

AI Framework 层：不绑定特定模型，但默认集成 OpenAI GPT 系列、Anthropic Claude 系列。通过 LiteLLM 支持 30+ LLM provider。通过向量化模型（如 OpenAI text-embedding-3-large）实现语义检索。

向量数据库：使用 CozoDB（轻量级、嵌入式），支持 PostgreSQL 后端，兼顾关系型数据管理和向量检索双重能力。

与同类项目的对比

维度	Julep	LangChain	AutoGen	Vercel AI
定位	完整托管平台	应用框架	多智能体框架	前端 SDK
部署复杂度	高（11+服务）	低（单脚本）	中	低
工作流持久化	有（Temporal）	无	无	无
多租户支持	有	无	无	无
开箱即用 API	有	无	无	无
记忆管理	内置	需自行实现	有限	无

Julep 的差异化在于生产级完整性：大多数 AI Agent 框架只管「怎么调用模型」，Julep 还管「怎么持久化状态、怎么调度任务、怎么管理多个用户」。这让它更像一个完整的 SaaS 后端，而不仅仅是一个开发库。

适用场景与门槛

适合用 Julep 的场景：

• 需要服务多个用户（多租户）的 AI 应用
• 工作流步骤多、耗时长、需要断点重试
• 需要持久化对话历史和用户数据
• 需要灵活接入多种 LLM 和外部工具
• 需要监控和数据分析能力

不太适合的场景：

• 个人快速原型（Docker Compose 11 个服务太重了）
• 简单的一次性脚本
• 对延迟极度敏感的实时交互

上手门槛方面，使用云端 API（dashboard.julep.ai）是零门槛的，5 分钟就能跑起来一个 AI 助手。但自托管部署是另一个故事——.env.example 列出了 40+ 环境变量，每个服务都有独立的 docker-compose 配置，需要理解 Temporal、PostgreSQL、Redis、LiteLLM、Hasura 等一众组件才能顺利跑通。

局限与风险

Julep 目前的局限值得注意：

1. License 不明确：GitHub 上 License 显示为 None，虽然 README 说 Apache 2.0，但代码仓库没有 LICENSE 文件，商业使用前需要确认。

2. 开发活跃但不稳定：default branch 是 dev（非 main），意味着很多功能在开发分支上，生产环境使用有风险。120 个 open issues 也说明当前功能仍在快速迭代中。

3. 复杂度护城河：11 个微服务的架构虽然功能完整，但也意味着维护成本高、学习曲线陡峭。

4. 国产化适配：目前没有针对国内 LLM provider（百度文心、阿里通义、腾讯混元）的内置支持，需要自己扩展 LiteLLM 配置。

行业意义

Julep 代表了 AI Agent 基础设施的一个趋势——从「单点工具」走向「平台化」。随着 Agent 能力越来越强，如何管理多个 Agent 的协作、如何保证工作流的可靠性、如何实现多用户隔离和计费，这些需求会越来越普遍。

它的定位「Firebase for AI agents」并不夸张——Firebase 解决了移动应用后端的问题（数据库、认证、存储、推送），Julep 正在解决 AI Agent 后端的问题（记忆、任务调度、工具集成、多租户）。两者都是让开发者专注于业务逻辑，而非基础设施。

总结一句话：Julep 是一个野心勃勃的生产级 AI Agent 平台，适合有微服务运维能力、需要在生产环境运行复杂 AI 工作流的团队。个人开发者或轻量场景，建议先用它的云端版本试试水，自托管部署请三思而后行。