多模态内容

文本

文本是 GUMem 的主输入。每条 Message 至少需要包含：

字段	说明
role	消息角色，例如 user、assistant、system。
content	原始文本内容，GUMem 会从中抽取 Facts。
metadata	可选业务元数据，例如来源、页面、客户端、附件引用或业务对象 ID。
timestamp	可选发生时间。涉及相对时间时，建议传入准确时间，方便 GUMem 解析时间范围。

文本内容应尽量保留用户原意。调用方不需要手写 Summary，通常只需要把有来源、有时间、有业务上下文的 Message 写入 GUMem。

图片

图片可以进入 GUMem，但 Memory pipeline 不应被理解为图片解码服务。更稳妥的方式是由上游系统先处理图片，再把结果写成 Message。

常见写入方式：

• 把图片 OCR、caption、模型识别结果或人工描述写入 content。
• 在 metadata 中保存图片的附件 ID、外部 URL、MIME 类型、业务对象 ID 或上传来源。
• 如果图片与某条用户消息相关，把图片描述和用户文本放在同一批 Message 中写入。

示例：

{
  "role": "user",
  "content": "User uploaded a receipt image. OCR text: dinner at Bistro A, total 86.40 SGD, paid on 2026-04-24.",
  "metadata": {
    "source": "image_upload",
    "mime_type": "image/png",
    "attachment_id": "att_xxx"
  },
  "timestamp": "2026-04-24T12:30:00Z"
}

如果部署层提供图片上传接口，仍应确认它是否已经把图片内容转成可供 Memory 使用的文本或 metadata。仅有二进制图片本身，不足以让当前 Memory pipeline 生成可召回 Facts。

Video

Video 的处理方式与图片类似。当前 Memory pipeline 处理文本化后的 Message，不直接承诺视频解析、转码、切帧或语音识别。

推荐做法：

• 将视频语音转写为文本后写入 Message。
• 将关键帧识别结果、场景摘要或人工备注写入 Message。
• 在 metadata 中保存 video URL、文件 ID、时长、片段时间码和来源系统。
• 对长视频按片段写入，避免一条 Message 包含过多无关内容。

示例：

{
  "role": "user",
  "content": "Video transcript from 00:02:10 to 00:03:05: user says the preferred onboarding flow should avoid long forms and support SSO first.",
  "metadata": {
    "source": "video_transcript",
    "video_id": "video_xxx",
    "segment_start": "00:02:10",
    "segment_end": "00:03:05"
  }
}

写入建议

• 把多模态内容转成对未来任务有用的文本事实，再写入 GUMem。
• 保留附件、资源和业务对象的引用，方便审计和删除。
• 不要把完整媒体文件当成 Memory 的主要内容。
• 不要把模型不确定的识别结果写成确定 Facts；不确定时在 content 中保留不确定性。

下一步

阅读 新增记忆 查看如何把文本化后的多模态内容写入 GUMem。