01
安装 oo-cli
先装好命令行入口。
给开发者的 Studio + CLI 函数工作流
写好函数，直接交付
用 OOMOL Studio 的 AI Agent 写好业务函数，发布到 Cloud 后，再通过 oo-cli 在 Codex 或 Claude Code 中直接调用这些能力。
CLI QUICKSTART
安装 oo-cli，登录后开始调用已发布函数。
先装上 CLI，再把第一次搜索和运行跑通。
02
登录账号
执行 oo login。
03
搜索并运行已发布函数
先搜，再跑。
INSTALL ONCE
两条命令，先把 CLI 装好并登录
30 秒装好一次，后面直接用。
$ bun install -g @oomol-lab/oo-cli$ oo loginFIRST RUN DEMO
把第一次使用压缩成搜索、检查、运行三段
直接看第一次怎么跑通。
01
Search
自然语言搜索
$ oo search "generate a QR code"02
Inspect
查看 package info
$ oo package info foo/bar@latest03
Run
运行并取回结果
$ oo cloud-task run foo/[email protected] --block-id main --data '{"text":"OOMOL"}'$ oo cloud-task result <task-id>为开发者提效而设计的 Studio
给开发者的真实编码环境：让 Agent 帮你生成函数，在本地验证后，直接交付为 API、MCP 工具或自动化任务。
我们想要的，不是另一个要求开发者迁就平台的工具，而是一个能真正写函数、编排节点、调试依赖、验证结果的工作环境。
「为什么我必须学习专有的 JSON 语法才能写一个 if/else 语句？」
「为什么我不能直接导入一个库？为什么我必须等待平台支持它？」
「为什么我要在一个没有自动补全的文本框里写代码？」
对开发者来说，问题从来不只是“能不能拖拽”，而是一旦进入真实交付，最终还是绕不开代码、依赖、调试和环境。
所以 Studio 的角色很明确：它不是为了替代工程环境，而是把函数生成、本地验证和后续交付重新放回工程环境里。
1. 节点即函数，编排即组合
Studio 不引入新的定义语言，而是直接把标准代码组织成可运行能力。
在 OOMOL 中，节点背后仍然是函数。输入是参数，输出是返回值。
你不是在配置一个黑盒平台，而是在写一份之后还能继续维护和交付的代码。
2. 不降级你的开发体验
可视化不该以牺牲开发体验为代价。
所以每个函数单元里都保留了熟悉的编辑、补全、类型和调试能力。
这样 Agent、代码和工具链才能一起工作，而不是彼此割裂。
3. 本地与云端环境一致，交付更省心
函数能力真正麻烦的地方，往往不是写出来，而是依赖、环境和运行结果不可控。
Studio 用标准容器把这些问题收拢起来。
先在本地把依赖装好、把结果跑通，再把同一份能力继续发布成 API、MCP 工具或自动化任务。
为什么交付会卡住
真正费时间的，不是把函数写出来
一旦你希望能力能被 AI、API 和自动化任务稳定调用，真正开始膨胀的往往是接口封装、环境对齐、部署上线和后续维护。
01
写完业务，还要再搭一套后端
实现已经有了，但为了对外提供 API 或任务能力，还要重新封装接口、部署流程和运行方式。
02
本地能跑，不等于交付能跑
开发环境、依赖环境和发布环境脱节，问题往往不是代码本身，而是它换了地方就不成立。
03
同一份能力，被重复包装
为了 API、MCP 工具和自动化任务，团队经常围着同一份实现反复改造，交付成本被重复放大。
Cloud 负责把函数稳定跑在线上
如果 Studio 负责把函数写出来，那么 OOMOL Cloud 就是统一的运行和交付层。CLI 登录之后，Codex / Claude Code 实际调用的也是这里部署的云函数。
更快上线，更少运维
Cloud
把已经跑通的函数托管成统一的线上能力，作为 CLI、API 和自动化任务共用的运行层，不必再重搭接口、运行时和扩缩容。
适合希望把函数稳定提供给 AI、应用或自动化任务的开发者和小团队。
查看 OOMOL Cloud
沿用 Studio 中已经跑通的实现，由 OOMOL Cloud 承接运行、鉴权和对外交付，CLI 登录后调用的也是这里的云函数。
云端交付
同一份已经验证过的函数实现，可以继续交付为 API、MCP 工具或自动化任务，作为 AI 和应用都能稳定调用的统一能力层。
API 服务
把函数直接交付成可调用的接口，不必单独搭服务框架和运行层。
MCP 工具
让同一份实现直接进入 Agent 和 AI 应用的调用链，而不是另外维护一套工具服务。
自动化任务
把同一份实现继续交付为定时任务或自动化流程，让线上运行和后续迭代复用同一份能力。
交付负担
少补一层服务
Cloud 承接函数的线上运行和对外交付，让你不用再围着同一份能力重做一套接口工程。
运行负担
更稳定地在线上用
把精力放回函数本身，而不是持续处理环境、调度、扩缩容和线上维护。
真实案例
这条 Studio -> Cloud -> CLI 链路已经跑在真实产品里
以 pdf.oomol.com 为例，OOMOL 不只是把函数跑通，而是把同一套能力发布到 Cloud，再接到网页工具、桌面应用、CLI 和线上服务里，并稳定对外提供。
真实项目
pdf.oomol.com
这不是内部 Demo，而是一个持续对外提供 PDF 与出版处理工具的真实项目。
同站点多场景
转换 / 翻译 / 生成
同一个项目里已经上线 PDF 转换、EPUB 翻译、漫画翻译与着色等多个入口，不是只有一个孤立页面。
背后实现
OOMOL 函数 / Cloud / CLI
这些能力不是分别重搭后端，而是沿着同一套 Studio、Cloud 和 CLI 链路被交付成真实可用的服务，CLI 登录后调用的也是这里的云函数。
写过一次的函数，应该继续被团队复用
函数不该只活在某个项目里。发布之后，它还可以继续被装回本地、接进 AI 工作流，或者作为后续服务的基础能力。
随时装回自己用
把已经发布过的函数重新装回自己的环境，下一次开发不用再从零开始。
逐步积累自己的函数资产
每次发布都会留下可复用的能力，逐步积累成你自己的函数资产。
继续拼出新的服务
基于已经发布的函数继续组合和扩展，把已有能力不断变成新的作品和服务。
开发者福利
先把链路跑通，再决定投入多少
把成本说明放在后面。先解决模型接入和轻量任务验证，让你更容易完成从 Studio 到 CLI 再到线上交付的第一次闭环。
Studio 福利
当前推荐
GLM-5
支持接入自有模型
接入你自己的模型，Studio 起步成本更低
OOMOL Studio 支持配置你自己的 AI 模型。如果你已经有现成的模型额度，就不需要再为本地开发额外购买一套模型服务。目前我们更推荐开发者直接接入 GLM-5。
如果你已经有现成模型额度，按教程配好之后，通常就够先把 Studio 跑起来并完成本地验证。
Cloud 福利
每月赠送
200 分钟
Cloud Task 免费时长
每月赠送 200 分钟 Cloud Task，先把轻量任务跑起来
我们每个月都会赠送 200 分钟 Cloud Task 使用时长。对定时任务、轻量自动化、个人验证这类场景来说，通常已经够你把真实线上任务先跑起来。
如果你在做个人项目或轻量应用，可以先用免费额度验证交付链路，再决定是否继续投入。
从下一个函数开始，让 AI 直接调用
下载 OOMOL Studio，用 AI Agent 写好业务函数并发布到 Cloud，再通过 oo-cli 在 Codex 或 Claude Code 中直接调用。仅支持 Apple Silicon Mac