开始使用
Mirobody 简介
Mirobody 是什么、它运行的三个步骤，以及如何在 Mirobody Cloud 与自部署之间选择。
什么是 Mirobody？
Section titled “什么是 Mirobody？”Mirobody 是一个健康数据引擎。它把任意来源的读数（化验单、可穿戴设备、基因检测、影像）解析到规范编码，存成一份可以互相比较、可供 AI 推理的记录。
名称取自 Mirror Your Body in Data，即用数据映照身体：所有来源统一到同一套标准，一个人的数据因此汇成一份可比较的完整记录，而不是十几份互不兼容的导出文件。
引擎本身是开源的，采用 Apache 2.0 许可。Mirobody Cloud 是它的托管形态：由我们运维存储、模型与密钥，并以兼容 OpenAI 的 /v1 接口对外提供，因此现有的 OpenAI SDK 只需改一个 base URL 和一个密钥即可接入。结构化读数的标准化两者完全一致；如果你更希望在自己的基础设施上运行，请看开源部署标签页。
最快跑通一次调用的路径是快速开始：创建密钥、写入一条记录、提一个问题。
三个步骤：采集、标准化、问答
Section titled “三个步骤：采集、标准化、问答”引擎只做三件事：① 采集 → ② 标准化 → ③ 问答。Cloud 就是同样这三件，只是运维那一半由我们承担。有一处差别需要说明：在 Cloud 上，采集发生在你那一侧。 数据由你获取（设备 OAuth、App 内采集、用户上传一份报告），交给我们；我们负责托管、标准化，并把它交给 AI 回答。
采集：按数据形态选对入口
结构化读数走 POST /v1/data。化验 PDF、照片与表格走 POST /v1/files，它保存原件、抽取文本，并把其中的读数标准化。POST /v1/standardize 同步执行同一套标准化，用于 dry-run 预览，或处理叙事文本。
标准化：每条结构化读数自动完成
名称确定性解析到 LOINC（不让 LLM 猜码），值归一到 UCUM 单位，编码只匹配、不臆造。"血糖(空腹)"、"FBG"、"Glucose, fasting" 归成一条序列。见标准化。
问答：让 AI 在其上工作
向 Answers API 要一条有依据、带证据的回答，或在 Agent API 上构建完整 agent：你自己的工具、存储的对话，openai-agents SDK 开箱即用。回答是标准化数据最直接的用法，而同一批记录也让你可以发掘洞察、生成报告或发出预警。
选择 Mirobody 的运行方式
Section titled “选择 Mirobody 的运行方式”无需安装。在控制台创建 mb_live_* 密钥，直接调用托管集群上兼容 OpenAI 的 /v1 接口。
在你自己的基础设施上运行开源引擎：git clone、./deploy.sh，数据不出你的机器。
两者运行的是同样三个步骤、同一套标准化，区别在于由谁运维存储与模型，以及各自暴露的接口：Cloud 是 /v1，自部署是 /api/* 加一个 /mcp 端点。
两个 API 接口，一套引擎
Section titled “两个 API 接口，一套引擎”POST /v1/responses（兼容 OpenAI Responses）。你的 function 工具、previous_response_id / session_id 状态、response.* 流式。openai-agents SDK 只需改 base URL。
POST /v1/chat/completions。封闭、有据可循的 completion：一个问题、一条有证据的回答。任何 OpenAI SDK 直接替换，也非常适合作为你自己 agent 里的一个工具。
拿不准？选择你的 API。
四种数据形态与对应端点
Section titled “四种数据形态与对应端点”这就是控制台数据页提供的同样三种来源，再加上日记这一种。
| 来源 | 端点 |
|---|---|
| 文件 / 照片 —— 化验单、体检 PDF、手机照片 | POST /v1/files |
| 结构化记录 —— 首要是设备与可穿戴数据，另有手动记录 | POST /v1/data |
| 叙事文本 —— 含读数的笔记或报告 | POST /v1/standardize |
| 纯主观的日记 | POST /v1/responses 带 store: true |
哪种情况用哪个端点、以及可运行的示例，见快速开始。
为什么选 Mirobody
Section titled “为什么选 Mirobody”- 有依据，而非听着合理：回答可附
health_records、citations与服务端采集证据时使用的工具步骤。 - 结构化数据标准化：通过
/v1/data写入或由/v1/standardize存储的记录都会经过 LOINC + UCUM 编码；你的分析与 agent 读取同一份序列。 - 双重 OpenAI 兼容：Chat Completions 与 Responses 两个协议；现有 SDK 与 agent 框架直接可用。
- 天生多租户：一个 key，每个终端用户一个隔离 Subject；按 Subject 的被遗忘权删除。
- 内核开放：Cloud 运行的就是同一个开源引擎，而且是按同样这三个步骤组织的。自己托管时，① 采集也变成我们的一部分：设备 provider 按计划拉取，术语层在你自己的进程里离线运行。见引擎即库。
密钥 → 数据 → 标准化记录 → 第一个 agent，几分钟即可完成。
Answers 与 Agent：两个接口的选择依据。
鉴权、多租户、留存、错误与全部端点。
各集群的选择依据与当前上线情况。
面向 agent 与脚本，整站另有纯文本形式：/llms.txt 是全站页面索引，/llms-full.txt 是单文件全文。