中文版本 / Chinese Version

OpenViking v0.4.1 发布说明：Context 进入 User / Peer 时代

完整对比：v0.3.24...v0.4.1

升级前先看三件事

上面的图是 v0.4.1 的变更总览：这次发布围绕 User / Peer 身份模型、legacy 迁移、多模态入库、OpenClaw Recall Trace、Skills、模型 failover 和存储可靠性展开。它不是一次普通的小版本迭代，而是 0.3.x 到 0.4 系列的数据模型升级。

Breaking Changes

v0.4.1 保留了 legacy 读取兼容，但新写入和新业务代码应切到新的 user namespace：

viking://agent/... 仍可读旧数据，但不再是新写入目标。
新的 memory / resource / session / skill 数据应进入 viking://user/...。
agent_id 只作为 legacy 过渡配置使用，会映射到请求级 actor_peer_id。
不要同时配置 agent_id 和 actor_peer_id，服务端会拒绝这种混用。
legacy agent_id client 下不要再显式传 message peer_id。
旧的 role_id 记忆隔离不再支持，升级后应使用 User / Peer 模型表达隔离边界。

迁移文档

迁移指南：https://github.com/volcengine/OpenViking/blob/v0.4.1/docs/zh/migration/01-user-peer-model.md

推荐的升级顺序是：先备份 0.3.x 数据，升级 server / CLI / SDK 到 0.4.1，验证 viking://agent 和 viking://session 仍可读，再执行 ov --sudo admin migrate --output json。确认迁移结果无误、没有回滚需求后，再执行 cleanup。

OpenViking v0.4.1 是从 0.3.x 走向 0.4 系列的关键版本。它不是简单增加几个 API，而是把 OpenViking 的核心定位进一步收敛到 Agent Context Core：身份边界、长期记忆、资源入库、技能、检索、插件和存储迁移都围绕“可长期运行、可迁移、可观测”的上下文基础设施展开。

这次发布可以概括为七条主线：

User / Peer 成为新的上下文身份模型，user 负责数据归属，peer 表达交互对象。
0.3.x legacy agent/session 数据可以兼容读取、后台迁移、验证和 cleanup。
会话、记忆和资源入库支持更多多模态场景，包括图片消息、图片资源、Feishu 用户 token 和外部 Understanding API。
检索支持 context_type，OpenClaw 侧补齐 Recall Trace、runtime query config 和 feature gates。
Skills 成为 user-scoped 上下文资产，CLI / API / 插件链路继续产品化。
VLM 和 Embedding 支持 ordered credentials、failover / failback 和更严格的错误分类。
RAGFS multi-write、S3 content-type autodetect、向量迁移和后台 task 让升级与生产运行更可靠。

User / Peer：把数据 owner 和交互对象拆开

v0.4.1 最重要的变化，是新的 User / Peer 模型。

User    = OpenViking 服务里的数据 owner
Peer    = 某个 user 下的交互对象
Session = user 下的会话状态
Skill   = user 下的可执行能力

在 0.3.x 心智里，很多场景会把外部说话人、agent、工具实例都塞进 agent_id。这在一人一助手时够用，但客服 Bot、群聊机器人、IDE 插件、OpenClaw / Codex 这类平台型接入会遇到一个问题：到底谁拥有数据，谁只是当前正在交互的对象？

v0.4.1 把这两个问题分开。比如客服场景可以建模为：

account = acme
user    = support-bot
peer    = customer-alice
peer    = customer-bob

support-bot 是 OpenViking 的数据 owner，Alice 和 Bob 是它服务的对象。这样平台只需要管理 support-bot 的 key，每个客户的长期上下文用稳定的 peer_id 隔离。

如果需要完整理解这个模型的背景和接入方式，可以看这篇博客：

https://blog.openviking.ai/post/openviking-user-peer-model/

最常见的新接入方式是：

import openviking as ov

client = ov.SyncHTTPClient(
    url="http://localhost:1933",
    api_key="<support-bot-user-key>",
)
client.initialize()

session = client.create_session(
    memory_policy={
        "self": {"enabled": True},
        "peer": {"enabled": True},
    }
)

client.add_message(
    session["session_id"],
    role="user",
    content="我的发票抬头需要开成火山引擎。",
    peer_id="customer-alice",
)

client.commit_session(session["session_id"])

如果要从某个 peer 的视角检索当前 user 下的数据，可以使用 actor_peer_id：

alice_view = ov.SyncHTTPClient(
    url="http://localhost:1933",
    api_key="<support-bot-user-key>",
    actor_peer_id="customer-alice",
)
alice_view.initialize()

results = alice_view.find("发票偏好")

actor_peer_id 不会改变认证身份，也不会切换 account / user。它只是在当前 user 的数据空间里过滤 peer 视图。

从 0.3.x 平滑迁移到 0.4.1

v0.4.1 没有把旧 agent/session 路径直接切断。升级后可以先验证兼容读取，再执行迁移：

pip install openviking==0.4.1 --upgrade --force-reinstall
openviking-server --config ov.conf

ov ls viking://agent
ov ls viking://session

ov --sudo admin migrate --output json
ov --sudo task status <task_id>

迁移会把旧数据复制到新模型下：

旧数据	新位置
`viking://agent/<agent_id>/memories/...`	`viking://user/<user_id>/peers/<agent_id>/memories/...`
`viking://agent/<agent_id>/resources/...`	`viking://user/<user_id>/peers/<agent_id>/resources/...`
`viking://agent/<agent_id>/skills/<skill>/...`	`viking://user/<user_id>/skills/<skill>/...`
`viking://session/<session_id>/...`	`viking://user/<user_id>/sessions/<session_id>/...`

迁移会处理已有向量索引：对成功复制的 memory / resource / skill 文件或目录，OpenViking 会读取旧记录里的向量 payload，重写 URI 和 owner 字段后写入新记录。它不会要求重新 embedding 全部历史数据。没有向量 payload 的旧标量记录会跳过并计数。

确认迁移结果无误后，可以执行 cleanup：

ov --sudo admin migrate --cleanup --output json
ov --sudo task status <cleanup_task_id>

兼容性上需要注意：

viking://agent/... 仍可读旧数据，但不再是新写入目标。
viking://session/... 仍可作为当前 user session 的读 alias。
legacy agent_id 模式下，find / search 会同时查新 peer 数据和未迁移的旧 agent 数据。
新业务代码应迁移到 viking://user/...、message peer_id 和 request/client actor_peer_id。
不要同时配置 agent_id 和 actor_peer_id。

多模态资源和会话记忆

v0.4.1 继续扩展多模态入库能力。资源解析新增 ParserRouter，可以按扩展名在内置 ParserRegistry 和第三方 Understanding API 之间路由：

{
  "parser_api": {
    "enable": true,
    "extensions": ["pdf", "docx", "pptx", "xlsx", "mp4"],
    "host": "https://example.com",
    "api_key": "..."
  }
}

解析流程会把本地文件或 URL 提交给外部解析服务，轮询结果，下载输出，再物化回 VikingFS 临时目录，继续进入 TreeBuilder 和 SemanticQueue。

资源侧还补齐了几个实际生产里很关键的能力：

Markdown 图片引用会被改写为 viking:// URI。
PDF / DOC 中抽出的图片可以保存到 VikingFS。
图片向量化策略支持 summary-only、image-only、image-and-summary。
Feishu / Lark 导入支持用户 access token；watch 场景可以提供 refresh token 并保存在私有 task state 中。

ov add-resource https://example.feishu.cn/docx/doc_token \
  --to viking://resources/feishu/doc \
  --watch-interval 1440 \
  --args feishu_access_token:u-... \
  --args feishu_refresh_token:r-...

会话侧新增图片消息记忆抽取。OpenAI-style image_url part 会先通过 VLM 转成稳定描述，再进入长期记忆抽取流程。截图、白板、票据、产品图里的信息可以成为记忆候选，而不是只留下一个没有语义的图片 URL。

检索、OpenClaw 和 Recall Trace

检索 API 新增 context_type，可以明确限定搜索 memory、resource 或 skill：

import openviking as ov
from openviking.retrieve import ContextType

client = ov.SyncHTTPClient(url="http://localhost:1933", api_key="your-key")
client.initialize()

results = client.find(
    "how should this agent import a Feishu doc with user token?",
    context_type=[ContextType.SKILL, ContextType.RESOURCE],
    limit=10,
)

OpenClaw 插件这轮补了多项上下文运行时能力：

Recall Trace core、runtime 和 HTTP routes，用于记录召回查询、搜索目标、跳过原因、候选结果和注入结果。
recall target types 配置，让插件能控制召回 memory / resource / skill 的组合。
runtime query config，让单次运行可以调整召回行为。
feature gates RPC 和 agent-visible tools gate，让插件能力暴露更可控。
默认 peer role 修正为 assistant，并接入 actor peer scope。

这些改动让 OpenClaw 从“能自动召回上下文”进一步走向“召回行为可解释、可调试、可按场景控制”。

Skills 和插件生态

Skills 在 v0.4.1 里成为 user-scoped 的一等上下文资产。它们存储在：

viking://user/{user_id}/skills/

viking://user/skills 也可以作为当前用户短写使用。CLI / API 支持添加、列出、查找、展示、更新、删除和校验 skill，也支持从 Git source 安装或更新。

ov skills add https://github.com/acme/skills/tree/main/skills/search-web --wait
ov skills list
ov skills update search-web

Claude Code / Codex memory plugins 也继续增强：支持 TOS release upload、GitHub-free install path、本地 pending queue，以及 recall compressor profile 缓存和 runtime failure 缓存。短生命周期 coding 工具可以把 OpenViking 当成长期上下文后端，同时减少重复探测和失败重试带来的延迟。

模型可靠性：多凭证、错误分类和 failback

v0.4.1 为 VLM 和 Embedding 增加 ordered credentials。数组顺序就是优先级，credentials[0] 是最高优先级。

系统会区分错误类型：

429、5xx、超时、连接错误：可重试或切换 credential。
认证、权限、配额类 credential-level 错误：可以切换到下一 credential。
400 参数错误、输入过大、内容安全拒绝：请求级快速失败，不浪费其他 credential。

Embedding 配置还会校验多 credential 的向量维度一致性，避免不同模型混用导致向量库维度错乱。对于线上部署，这意味着可以更现实地使用多 endpoint、多 provider、多 key，并在上游模型抖动时保持 Agent 可用性。

存储和运维可靠性

RAGFS multi-write 是这轮的重要基础设施增强。OpenViking 的上层 API 不需要变化，底层可以配置 primary 和多个 backup，用于高可用、跨区域副本、读加速和存储迁移。

{
  "storage": {
    "agfs": {
      "backend": "local",
      "backups": {
        "sync_type": "async",
        "items": [
          {
            "name": "object-store",
            "backend": "s3",
            "s3": {
              "bucket": "openviking-backup",
              "endpoint": "https://s3.example.com"
            }
          }
        ]
      }
    }
  }
}

同一条线上还包含一批生产修复：

S3 场景支持 content-type autodetect。
migrated legacy agent aliases 可以被正确读取。
vector migration 输出字段修正。
multiwrite copy 修复 empty chunk overwrite。
session directory 跳过 vector seed，避免无效向量占位。
user entry directories 初始化更完整。
ov doctor 会报告无效 ov.conf 字段，而不是误报 PASS。

这些改动不一定显眼，但决定了长期运行、迁移、备份和对象存储场景的稳定性。

评测、测试和文档

v0.4.1 也补齐了大量测试和评测资产，覆盖：

User / Peer identity、actor-peer filesystem view、peer auth check。
legacy migration、vector migration、RAGFS multi-write。
Feishu user token、watch auth state。
image message memory extraction。
VLM / embedding failover、ordered credential switcher。
OpenClaw recall trace、runtime query config、feature gates。
Skills API / CLI。
LongMemEval 和 LoCoMo OpenViking benchmarks。

文档侧也新增了 0.3.x 到 0.4 的迁移指南、multi-write storage guide、User / Peer API 说明，以及 session、retrieval、skills、resources 等 API 文档更新。

建议升级路径

如果你已经在运行 0.3.x，建议按这个顺序升级：

先用 0.3.24 兼容版本备份现有数据。
升级 server、CLI 和 SDK 到 0.4.1。
重启服务端，验证 viking://agent 和 viking://session 仍可读。
执行 ov --sudo admin migrate --output json。
检查 task status、迁移统计、向量记录数量和新 URI。
把业务写入迁移到 viking://user/...、message peer_id 和 actor_peer_id。
确认无回滚需求后，再执行 cleanup。

建议尽快关注 v0.4.1 的用户包括：

正在做多用户、多 Agent 或平台型 OpenViking 部署的团队。
已经有 0.3.x agent/session 历史数据，需要平滑迁移。
希望把 Feishu、PDF、DOC、图片消息、视频等多模态内容纳入上下文的用户。
使用 OpenClaw、Codex、Claude Code 插件，希望召回行为更可解释、更可控的用户。
对存储迁移、备份、多 endpoint 模型可用性有生产要求的部署。

英文版本 / English Version

OpenViking v0.4.1 Release Notes: Context Enters the User / Peer Era

Read This First

The overview image above summarizes the v0.4.1 release: User / Peer identity, legacy migration, multimodal ingestion, OpenClaw Recall Trace, Skills, model failover, and storage reliability. This is not a routine patch release. It is the data-model upgrade that moves OpenViking from the 0.3.x line into the 0.4 series.

Breaking Changes

v0.4.1 keeps legacy read compatibility, but new writes and new application code should move to the new user namespace:

viking://agent/... can still read old data, but it is no longer a new write target.
New memory / resource / session / skill data should use viking://user/....
agent_id is only a legacy transition setting and maps to request-level actor_peer_id.
Do not configure both agent_id and actor_peer_id; the server rejects that mixed mode.
Do not explicitly send message-level peer_id from a legacy agent_id client.
Legacy role_id memory isolation is no longer supported; use the User / Peer model for isolation boundaries.

Migration Docs

Before upgrading, read the migration guide, especially the compatibility matrix, migration command, and optional cleanup sections:

Chinese migration guide: https://github.com/volcengine/OpenViking/blob/v0.4.1/docs/zh/migration/01-user-peer-model.md
English migration guide: https://github.com/volcengine/OpenViking/blob/v0.4.1/docs/en/migration/01-user-peer-model.md

The recommended sequence is: back up 0.3.x data, upgrade server / CLI / SDK to 0.4.1, verify that viking://agent and viking://session are still readable, then run ov --sudo admin migrate --output json. Only run cleanup after the migration is verified and rollback is no longer needed.

OpenViking v0.4.1 is the key step from the 0.3.x line into the 0.4 series. This release is not just a collection of API additions. It tightens OpenViking around its role as an Agent Context Core: identity boundaries, long-term memory, resource ingestion, skills, retrieval, plugins, and storage migration now share a clearer model for long-running context infrastructure.

The release has seven main themes:

User / Peer becomes the new context identity model: user owns data, while peer represents the interaction counterpart.
0.3.x legacy agent/session data can be read compatibly, migrated in the background, verified, and cleaned up.
Sessions, memory extraction, and resource ingestion support more multimodal workflows, including image messages, image resources, Feishu user tokens, and external Understanding API parsing.
Retrieval now supports context_type; OpenClaw gains Recall Trace, runtime query config, and feature gates.
Skills become user-scoped context assets, with the CLI / API / plugin workflow continuing to mature.
VLM and Embedding now support ordered credentials, failover / failback, and stricter error classification.
RAGFS multi-write, S3 content-type autodetection, vector migration, and background tasks make upgrades and production operations more reliable.

User / Peer: Separate Data Ownership From Interaction

The most important change in v0.4.1 is the new User / Peer model.

User    = the data owner inside OpenViking
Peer    = an interaction counterpart under a user
Session = conversation state under a user
Skill   = executable capability under a user

In the 0.3.x mental model, many integrations pushed external speakers, agents, or tool instances into agent_id. That works for simple one-person-one-assistant cases, but it becomes awkward for customer-support bots, group chat bots, IDE plugins, OpenClaw, and Codex-style integrations. The core question is: who owns the data, and who is merely being interacted with right now?

v0.4.1 separates these two questions. A support-bot setup can be modeled as:

account = acme
user    = support-bot
peer    = customer-alice
peer    = customer-bob

support-bot is the OpenViking data owner. Alice and Bob are the people it serves. The platform only has to manage the support-bot key, while each customer's long-term context is isolated by a stable peer_id.

For the full background and integration pattern, see the User / Peer model blog post:

https://blog.openviking.ai/post/openviking-user-peer-model/

A typical new integration looks like this:

import openviking as ov

client = ov.SyncHTTPClient(
    url="http://localhost:1933",
    api_key="<support-bot-user-key>",
)
client.initialize()

session = client.create_session(
    memory_policy={
        "self": {"enabled": True},
        "peer": {"enabled": True},
    }
)

client.add_message(
    session["session_id"],
    role="user",
    content="Please remember that my invoice title should be Volcano Engine.",
    peer_id="customer-alice",
)

client.commit_session(session["session_id"])

To retrieve from one peer's view under the current user, initialize the client with actor_peer_id:

alice_view = ov.SyncHTTPClient(
    url="http://localhost:1933",
    api_key="<support-bot-user-key>",
    actor_peer_id="customer-alice",
)
alice_view.initialize()

results = alice_view.find("invoice preference")

actor_peer_id does not change authentication identity, account, or user. It only filters the current user's data space to a peer view.

Smooth Migration From 0.3.x to 0.4.1

v0.4.1 does not abruptly cut off old agent/session paths. After upgrading, you can first verify compatible reads, then run the migration:

pip install openviking==0.4.1 --upgrade --force-reinstall
openviking-server --config ov.conf

ov ls viking://agent
ov ls viking://session

ov --sudo admin migrate --output json
ov --sudo task status <task_id>

The migration copies old data into the new model:

Old data	New location
`viking://agent/<agent_id>/memories/...`	`viking://user/<user_id>/peers/<agent_id>/memories/...`
`viking://agent/<agent_id>/resources/...`	`viking://user/<user_id>/peers/<agent_id>/resources/...`
`viking://agent/<agent_id>/skills/<skill>/...`	`viking://user/<user_id>/skills/<skill>/...`
`viking://session/<session_id>/...`	`viking://user/<user_id>/sessions/<session_id>/...`

The migration also handles existing vector indexes. For successfully copied memory / resource / skill files or directories, OpenViking reads the old vector payload, rewrites URI and owner fields, and writes the new record. It does not require re-embedding all historical data. Old scalar records without vector payload are skipped and counted.

Once the migration is verified, cleanup is available:

ov --sudo admin migrate --cleanup --output json
ov --sudo task status <cleanup_task_id>

Compatibility notes:

viking://agent/... can still read old data, but it is no longer a new write target.
viking://session/... can still act as a read alias for current-user sessions.
In legacy agent_id mode, find / search searches both new peer data and unmigrated old agent data.
New application code should move to viking://user/..., message-level peer_id, and request/client-level actor_peer_id.
Do not configure both agent_id and actor_peer_id.

Multimodal Resources and Session Memory

v0.4.1 expands multimodal ingestion. Resource parsing adds ParserRouter, which can route selected file extensions between the built-in ParserRegistry and an external Understanding API:

{
  "parser_api": {
    "enable": true,
    "extensions": ["pdf", "docx", "pptx", "xlsx", "mp4"],
    "host": "https://example.com",
    "api_key": "..."
  }
}

The parsing flow can submit local files or URLs to an external parser, poll for results, download the output, materialize it back into a VikingFS temp tree, and then continue through TreeBuilder and SemanticQueue.

Resource ingestion also gains several production-facing improvements:

Markdown image references are rewritten to viking:// URIs.
Images extracted from PDF / DOC files can be saved into VikingFS.
Image vectorization supports summary-only, image-only, and image-and-summary strategies.
Feishu / Lark imports support user access tokens; watch tasks can accept refresh tokens and store them in private task state.

ov add-resource https://example.feishu.cn/docx/doc_token \
  --to viking://resources/feishu/doc \
  --watch-interval 1440 \
  --args feishu_access_token:u-... \
  --args feishu_refresh_token:r-...

Sessions now support memory extraction from image messages. OpenAI-style image_url parts are first converted into stable descriptions through a VLM, and only then sent into long-term memory extraction. Screenshots, whiteboards, receipts, and product images can become memory candidates instead of remaining semantically opaque image URLs.

Retrieval, OpenClaw, and Recall Trace

Retrieval APIs now support context_type, so callers can explicitly search memory, resource, or skill contexts:

import openviking as ov
from openviking.retrieve import ContextType

client = ov.SyncHTTPClient(url="http://localhost:1933", api_key="your-key")
client.initialize()

results = client.find(
    "how should this agent import a Feishu doc with user token?",
    context_type=[ContextType.SKILL, ContextType.RESOURCE],
    limit=10,
)

The OpenClaw plugin also gets several runtime context capabilities:

Recall Trace core, runtime, and HTTP routes for recording queries, targets, skipped reasons, candidates, and injected results.
recall target type configuration, so plugins can control memory / resource / skill search combinations.
runtime query config, allowing one run to adjust recall behavior.
feature gates RPC and agent-visible tools gate for controlled capability exposure.
default peer role fixed to assistant, with actor peer scope wired into plugin behavior.

Together, these changes move OpenClaw from "automatic context recall" toward recall that is explainable, tunable, and debuggable.

Skills and Plugin Ecosystem

Skills are now user-scoped first-class context assets. They live under:

viking://user/{user_id}/skills/

viking://user/skills is accepted as the current-user shorthand. The CLI / API support adding, listing, finding, showing, updating, removing, and validating skills, including installing or updating them from Git sources.

ov skills add https://github.com/acme/skills/tree/main/skills/search-web --wait
ov skills list
ov skills update search-web

Claude Code / Codex memory plugins continue to improve as well, with TOS release upload, a GitHub-free install path, a local pending queue, recall compressor profile caching, and runtime failure caching. Short-lived coding tools can use OpenViking as a long-term context backend while reducing repeated probes and repeated failed model calls.

Model Reliability: Ordered Credentials, Error Classes, Failback

v0.4.1 adds ordered credentials for VLM and Embedding. Array order is priority order; credentials[0] is the highest-priority credential.

OpenViking distinguishes error classes:

429, 5xx, timeouts, and connection errors can retry or switch credentials.
Authentication, permission, and quota errors are credential-level failures and can move to the next credential.
400, oversized input, and content-safety rejection are request-level failures and fail fast without wasting other credentials.

Embedding configuration also validates that multiple credentials produce compatible vector dimensions, preventing mixed-model vector stores from being corrupted by dimension drift. In production, this makes it more realistic to use multiple endpoints, providers, or keys while keeping agents available during upstream instability.

Storage and Operational Reliability

RAGFS multi-write is a major infrastructure improvement in this release. OpenViking's upper API does not change, while the storage layer can configure one primary backend and multiple backups for high availability, cross-region copies, read acceleration, or storage migration.

{
  "storage": {
    "agfs": {
      "backend": "local",
      "backups": {
        "sync_type": "async",
        "items": [
          {
            "name": "object-store",
            "backend": "s3",
            "s3": {
              "bucket": "openviking-backup",
              "endpoint": "https://s3.example.com"
            }
          }
        ]
      }
    }
  }
}

The same reliability track includes several production fixes:

S3 content-type autodetection.
Correct reads for migrated legacy agent aliases.
Fixed vector migration output fields.
Fixed empty chunk overwrite during multiwrite copy.
Session directories skip invalid vector seeds.
More complete user entry directory initialization.
ov doctor now reports invalid ov.conf fields instead of incorrectly passing.

These changes are not always the most visible, but they matter for long-running deployments, migration, backup, and object-storage scenarios.

Evaluations, Tests, and Docs

v0.4.1 adds substantial test and benchmark coverage:

User / Peer identity, actor-peer filesystem view, and peer auth checks.
legacy migration, vector migration, and RAGFS multi-write.
Feishu user token and watch auth state.
image message memory extraction.
VLM / embedding failover and ordered credential switchers.
OpenClaw recall trace, runtime query config, and feature gates.
Skills API / CLI.
LongMemEval and LoCoMo OpenViking benchmarks.

Docs were updated with the 0.3.x-to-0.4 migration guide, the multi-write storage guide, User / Peer API details, and refreshed session, retrieval, skills, and resource API pages.

Recommended Upgrade Path

If you already run OpenViking 0.3.x, use this sequence:

Back up existing data with a 0.3.24-compatible version.
Upgrade server, CLI, and SDK to 0.4.1.
Restart the server and verify viking://agent and viking://session reads.
Run ov --sudo admin migrate --output json.
Check task status, migration counters, vector record counts, and new URIs.
Move application writes to viking://user/..., message-level peer_id, and actor_peer_id.
Run cleanup only after you are sure rollback is no longer needed.

v0.4.1 is especially relevant if you:

Run multi-user, multi-agent, or platform-style OpenViking deployments.
Have 0.3.x agent/session history that must migrate smoothly.
Need Feishu, PDF, DOC, image messages, video, or other multimodal content in context.
Use OpenClaw, Codex, or Claude Code plugins and want more explainable, controllable recall.
Need storage migration, backups, or higher model-endpoint availability in production.

volcengine/OpenViking v0.4.1 on GitHub

中文版本 / Chinese Version

OpenViking v0.4.1 发布说明：Context 进入 User / Peer 时代

升级前先看三件事

Breaking Changes

迁移文档

User / Peer：把数据 owner 和交互对象拆开

从 0.3.x 平滑迁移到 0.4.1

多模态资源和会话记忆

检索、OpenClaw 和 Recall Trace

Skills 和插件生态

模型可靠性：多凭证、错误分类和 failback

存储和运维可靠性

评测、测试和文档

建议升级路径

英文版本 / English Version

OpenViking v0.4.1 Release Notes: Context Enters the User / Peer Era

Read This First

Breaking Changes

Migration Docs

User / Peer: Separate Data Ownership From Interaction

Smooth Migration From 0.3.x to 0.4.1

Multimodal Resources and Session Memory

Retrieval, OpenClaw, and Recall Trace

Skills and Plugin Ecosystem

Model Reliability: Ordered Credentials, Error Classes, Failback

Storage and Operational Reliability

Evaluations, Tests, and Docs

Recommended Upgrade Path

volcengine/OpenViking v0.4.1
on GitHub