代理框架與上下文基礎設施
OpenViking 0.4.16 Enables VikingBot to Load Skills Remotely and Removes the Resource Relations API
The new release integrates centralized agent skill storage, search, and caching into VikingBot, while adding per-user memory retrieval policies and persistent background imports. The upgrade also removes the experimental relations API and CLI commands, requiring existing integrations to migrate first.

OpenViking 0.4.16 officially brings remote Skills to VikingBot: agents can discover, read, cache, and execute skills from an OpenViking server, eliminating the need to copy the complete `SKILL.md` and supporting files to every execution host in advance. OpenViking handles skill storage, search, and authentication, while VikingBot selects skills within AgentLoop, invokes models and tools, and writes the results back to the Session.
For multi-agent deployments, this separation provides more than centralized management. Skill summaries can be added to the context progressively, with full instructions loaded only after a match; when local files or executable resources are required, the corresponding version is materialized in the sandbox. Teams can therefore let multiple Bots share the same skill library while updating versions and permissions on the server. However, cache invalidation, version pinning, and whether an active Session permits hot updates remain behaviors that must be validated during deployment.
The release also adds a per-user `memory_policy`. Administrators can restrict the types of memory each user is allowed to retrieve; existing Sessions without a policy will adopt the new configuration on their next commit. `viking://~` now serves as an alias for the currently authenticated caller’s user root directory, reducing the need for multi-tenant applications to hard-code full URIs. When resource imports use `wait=false`, source preparation is moved to a persistent background task, with the queued stage and context count reported; 4xx errors from the vector database are no longer swallowed.
The migration risk comes from the complete removal of Resource Relations: `/api/v1/relations`, `ov relations`, `ov link`, and `ov unlink` have all been deleted. Applications that depend on relation edges must switch to other metadata or an external graph database. On security, the official documentation explicitly states that the `direct` sandbox inherits the Bot process’s permissions and does not provide strong isolation. If remote skills include Shell, network, or file operations, services exposed to untrusted users should use an isolated backend and define explicit filesystem and outbound network policies.