接入 Open WebUI用 OpenViking Tool Server 把记忆、知识与技能变成原生工具【免费下载链接】OpenVikingSelf-evolving Context Database for AI Agents. Unify Agent Memory, Knowledge RAG and Skills.项目地址: https://gitcode.com/GitHub_Trending/op/OpenViking导读OpenViking 是一个面向 AI Agent 的自进化上下文数据库统一了 Agent 记忆Memory、知识库RAG与技能Skills。本指南讲解仓库中 examples/openwebui-plugin 提供的独立 FastAPI 工具服务器它将 OpenViking 的一组核心 HTTP 端点封装成OpenAPI 工具使 Open WebUI 无需粘贴 Python 脚本、无需在管理后台手动上传即可自动发现并调用ov_search、ov_add_memory等 7 个原生工具。读完本文你将掌握该插件的安装运行、环境变量语义、每个工具的请求/响应结构、底层转发与多租户鉴权原理以及如何按四步流程扩展出你自己的工具。背景Open WebUI 的两种工具集成机制Open WebUI 支持两种工具接入方式Python Functions把一段 Python 函数粘贴到 Open WebUI 管理后台中由 Open WebUI 运行时加载执行外部 OpenAPI 工具服务器提供一个 Web 服务Open WebUI 从/openapi.json自动发现工具清单并把每个操作operation暴露给 LLM 作为可调用工具。本插件实现的是第二种机制。它本质上是一个薄转发层thin translation layer每个工具路由把请求转发给对应的 OpenViking HTTP 端点、附加多租户标识头再把响应原样返回。插件内不包含任何业务逻辑——语义检索、内容写入、资源摄入等能力全部由 OpenViking 服务端完成见 openviking/server/routers 下的search.py、content.py、filesystem.py、resources.py、sessions.py等路由实现。这一设计的好处是同一套工具服务器可以被任何支持 OpenAPI 的客户端复用不仅限于 Open WebUI。插件架构与代码结构插件位于examples/openwebui-plugin/代码量极小共 4 个模块 1 组测试文件职责openviking_openwebui/config.py环境变量解析生成只读Settings数据类openviking_openwebui/client.py基于httpx.AsyncClient的薄 HTTP 客户端负责附加租户头与错误透传openviking_openwebui/tools.pyPydantic 请求模型 7 个 FastAPI 路由处理器openviking_openwebui/server.pycreate_app()组装 FastAPI 应用、生命周期管理与/health探针openviking_openwebui/main.pypython -m openviking_openwebui的入口调用 uvicorn 启动tests/test_tools.py用respx模拟 OpenViking HTTP 层的 9 个测试用例从源码结构可以看出插件启动链路是__main__.py读取环境变量 →server.create_app()在 lifespan 中创建共享OVClient挂到app.state→tools.router中的每个 handler 通过 FastAPI 依赖注入拿到同一个客户端 → 转发请求。依赖见 pyproject.tomlfastapi0.110、uvicorn[standard]0.27、httpx0.27、pydantic2.5要求 Python 3.9。快速开始运行工具服务器cd examples/openwebui-plugin pip install -e . OV_API_KEYyour-key python -m openviking_openwebui默认监听0.0.0.0:8765启动后终端应出现INFO: Uvicorn running on http://0.0.0.0:8765也可以使用pyproject.toml注册的控制台脚本openviking-openwebui直接启动。验证 OpenAPI 规格是否正常对外提供服务curl http://localhost:8765/openapi.json | jq .paths | keys输出应包含 7 个工具路径/tools/ov_search、/tools/ov_recall_memories、/tools/ov_add_memory、/tools/ov_list_memories、/tools/ov_read_resource、/tools/ov_add_resource、/tools/ov_session_status。FastAPI 会根据每个路由的operation_id在tools.py中显式设置自动生成 OpenAPI 文档这正是 Open WebUI 能识别工具名的关键。另外 server.py 还暴露了GET /health探针返回{status: ok, endpoint: OV_ENDPOINT}可用于容器编排与负载均衡的健康检查。接入 Open WebUI进入 Open WebUI →Settings→Tools→Add Tool Server粘贴工具服务器可达的地址例如http://localhost:8765Open WebUI 会自动抓取/openapi.json列出全部 7 个工具并在每次对话轮次中把它们作为可调用工具呈现给 LLM。整个过程无需复制粘贴 Python 文件、无需管理后台上传。tests/test_tools.py中的test_openapi_lists_seven_tools用例专门断言了/openapi.json中至少包含这 7 个operationId确保自动发现机制始终有效。配置全部通过环境变量插件没有配置文件所有配置均来自环境变量这是有意的设计——让部署单元保持一个二进制 一组环境变量。config.py中的load_settings()在进程启动时一次性读取因此修改环境变量后需要重启服务。变量默认值说明OV_ENDPOINThttp://localhost:1933OpenViking 服务端基础 URL末尾/会被自动去除OV_API_KEY空Bearer Token以Authorization: Bearer …头发送为空时不附加该头OV_ACCOUNTdefault租户Tenant以X-OpenViking-Account头发送OV_USERdefault用户以X-OpenViking-User头发送OV_AGENTdefaultActor peer ID以X-OpenViking-Actor-Peer头发送OV_BIND0.0.0.0:8765工具服务器绑定的host:portOV_TIMEOUT30调用 OpenViking 的 HTTP 超时秒几个值得注意的实现细节见 config.pyOV_BIND的解析是容错的bind_host/bind_port属性用partition(:)拆分缺省端口回退到8765解析失败也回退8765memories_uri属性固定返回viking://~/memories/——这是 OpenViking 中个人记忆的约定 URI 前缀ov_recall_memories、ov_add_memory、ov_list_memories三个工具都依赖它所有环境变量都经过strip()处理空字符串视为未设置并回退默认值。OVClient见 client.py在每次请求时统一构造请求头仅当OV_API_KEY非空才附加Authorization头X-OpenViking-Account、X-OpenViking-User、X-OpenViking-Actor-Peer三个租户头则总是附加。这些头正是 OpenViking 服务端鉴权体系识别的字段——在 openviking/server/auth/init.py 中可以看到服务端通过 FastAPIHeader依赖读取同名请求头trusted鉴权模式见 openviking/server/auth/plugins/trusted.py会直接信任并归一化这些头据此确定请求所属的 account/user。工具参考7 个工具的参数与端点映射下表是工具与 OpenViking 端点的完整映射工具OpenViking 端点用途ov_searchPOST /api/v1/search/find跨记忆、资源、技能做语义检索ov_recall_memoriesPOST /api/v1/search/find限定viking://~/memories/针对当前查询召回个人记忆ov_add_memoryPOST /api/v1/content/write写入viking://~/memories/name持久化一条新记忆ov_list_memoriesGET /api/v1/fs/ls?uriviking://~/memories/浏览记忆目录ov_read_resourceGET /api/v1/content/read读取任意viking://URI 的全文ov_add_resourcePOST /api/v1/resources摄入远程 URL 或服务端可达的路径文件ov_session_statusGET /api/v1/sessions/{id}查看会话的消息数、归档状态等元数据所有路由定义都位于 tools.py下面逐一给出源码确认的请求模型字段与约束。ov_search—— 顶层语义检索{query: …, limit: 10, target_uri: null, score_threshold: null}query必填自然语言查询limit默认10约束1 ≤ limit ≤ 100target_uri可选的viking://前缀用于把检索限定到某个子树score_threshold可选的相似度阈值约束0.0 ≤ score_threshold ≤ 1.0。响应为SearchResponsehits是由uri、score、snippet?组成的结构化命中列表外加raw保留 OpenViking 的原始响应。命中结果的展平逻辑在_hits_from_find中实现它会遍历 OpenViking/search/find响应result对象里的memories、resources、skills、results四个桶从每个条目提取uri或target_uri、score、以及snippet/abstract/preview三选一的摘要文本。这也是本工具能跨记忆、资源、技能一起搜的底层原因。ov_recall_memories—— 只搜个人记忆{query: …, limit: 6}与ov_search调用同一个POST /api/v1/search/find但target_uri被强制设为viking://~/memories/因此只检索个人记忆。适合在聊天中回答关于我你记得什么这类问题。limit默认6约束1 ≤ limit ≤ 50——比ov_search更小符合记忆召回的精简优先语义。ov_add_memory—— 持久化新记忆{name: profile.md, content: …, mode: replace, wait: false}name必填viking://~/memories/下的文件名例如profile.md代码中会strip()并去掉开头的/空名返回 400content必填记忆正文纯文本或 Markdownmode枚举replace | append | create默认replacewait布尔值默认false置true时阻塞直到语义索引完成。工具会把name拼成完整viking://~/memories/nameURI再POST /api/v1/content/write。响应为AddMemoryResponse包含最终uri与raw原始响应。测试用例test_ov_add_memory_writes_under_memories验证了请求体确实携带完整 URI 与内容。ov_list_memories—— 浏览记忆目录{recursive: false, limit: 200}对应GET /api/v1/fs/ls查询参数为uriviking://~/memories/、recursive布尔值转小写字符串、node_limit。limit默认200约束1 ≤ limit ≤ 1000透传为服务端的node_limit。测试用例test_ov_list_memories_calls_fs_ls断言了 URL 中这三个参数的编码结果。ov_read_resource—— 读取任意 viking:// 资源{uri: viking://~/memories/a.md, offset: 0, limit: -1}uri必填完整的viking://URIoffset默认0limit默认-1表示读取全部。对应GET /api/v1/content/read三个参数原样透传为查询参数。这是 LLM 拿到命中 URI 后展开全文的标准动作。ov_add_resource—— 摄入远程资源{path: https://example.com/doc.md, to: null, parent: null, reason: , instruction: , wait: false}path必填OpenViking 服务端可达的远程 URL 或本地路径to/parent可选的目标/父目录reason/instruction可选的摄入原因与附加指令wait是否阻塞等待摄入完成。对应POST /api/v1/resources是纯 HTTP 转发——路径/URL 的合法性校验完全由 OpenViking 服务端完成。测试用例test_ov_add_resource_posts_resources验证了请求体包含path与wait字段。ov_session_status—— 查询会话元数据{session_id: sess-42}对应GET /api/v1/sessions/{session_id}返回该会话的消息计数、归档状态、待处理 token 等信息。测试用例test_ov_session_status_gets_session断言了请求 URL 路径为/api/v1/sessions/sess-42。错误透传当 OpenViking 返回非 2xx 时OVClient.request会抛出携带status与响应体的OVError见 client.py路由层的_forward辅助函数见 tools.py会把它转成HTTPException原样保留上游的状态码与错误详情返回给调用方。测试用例test_error_pass_through验证了 404 错误体被完整透传。测试用 respx 模拟上游cd examples/openwebui-plugin pip install -e .[test] pytest tests -x -q测试套件tests/test_tools.py使用respx拦截并模拟 OpenViking 的 HTTP 层断言每个工具调用了正确的方法/路径/请求体并且逐字转发租户头。其中_assert_headers帮助函数集中校验四个请求头authorization: Bearer key-xyzx-openviking-account: acctx-openviking-user: alicex-openviking-actor-peer: webui测试通过create_app(SETTINGS)注入自定义Settings与httpx.ASGITransport无需真实启动网络服务见 server.py 的注释测试可注入自定义 Settings/OVClient。pyproject.toml中开启了pytest-asyncio的asyncio_mode auto因此异步测试函数无需显式标记。局限性与边界不支持流式输出Open WebUI 工具是请求/响应模型实时转录流式传输不在本插件范围内不支持文件上传ov_add_resource只接受远程 URL 或 OpenViking 服务端自身可达的路径。若要上传二进制数据应直接调用 OpenViking 服务端的temp_upload端点POST /api/v1/resources/temp_upload可携带?token临时上传凭证见 openviking/server/upload_token_store.py 与 openviking/server/mcp_endpoint.py无删除/移动类写操作插件按只读为主设计需要破坏性操作的用户请使用 OV CLI单进程单租户租户身份来自环境变量如果需要多租户请为每个(account, user)组合各跑一个工具服务器进程不捆绑 Open WebUI这只是工具服务器Open WebUI 实例需自行准备。扩展路线添加新工具的四步流程README 给出的扩展流程与源码完全对应在 openviking_openwebui/tools.py 中添加 Pydantic 请求模型添加路由 handler并用router.post(/tools/name, operation_idname)装饰——operation_id必须与工具名一致因为 Open WebUI 依赖它识别工具通过OVClientclient.get/client.post转发到对应 OpenViking 端点在 tests/test_tools.py 中仿照现有用例用respxmock 上游并断言转发正确性。社区可能期望的候选工具包括ov_session_create、ov_session_commit、ov_grep、ov_glob、ov_overview、ov_abstract等。由于插件本身是纯转发架构新增工具的边际成本很低——只需定义模型、路由与测试三处改动。安全注意事项切勿把OV_API_KEY提交进版本库一律通过环境变量注入工具服务器自身没有任何鉴权——请绑定到 localhost 或内网或在前端用代理强制鉴权租户身份属于服务端信任模型任何持有OV_API_KEY并伪造X-OpenViking-Account/User头的调用方都能读取该租户的数据。这与 OpenViking 的标准信任模型一致——在服务端trusted鉴权模式下这些头被直接信任见 openviking/server/auth/plugins/trusted.py。因此务必通过访问控制保护好OV_ENDPOINT指向的 OpenViking 服务。小结OpenViking Open WebUI 插件用不到两百行 Python 代码把一个 Agent 记忆/知识/技能后端无缝接入 Open WebUI 的工具生态7 个精心挑选的工具覆盖检索—召回—写入—浏览—读取—摄入—会话诊断的完整闭环全部通过 OpenAPI 自动发现零业务逻辑重复同时用环境变量保持了部署单元的极简。对于希望让 LLM 在对话中真正记住用户、检索知识、沉淀技能的开发者这是一条开箱即用的接入路径也为后续按四步流程扩展更多 OpenViking 能力留下了清晰范式。【免费下载链接】OpenVikingSelf-evolving Context Database for AI Agents. Unify Agent Memory, Knowledge RAG and Skills.项目地址: https://gitcode.com/GitHub_Trending/op/OpenViking创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
接入 Open WebUI：用 OpenViking Tool Server 把记忆、知识与技能变成原生工具
接入 Open WebUI用 OpenViking Tool Server 把记忆、知识与技能变成原生工具【免费下载链接】OpenVikingSelf-evolving Context Database for AI Agents. Unify Agent Memory, Knowledge RAG and Skills.项目地址: https://gitcode.com/GitHub_Trending/op/OpenViking导读OpenViking 是一个面向 AI Agent 的自进化上下文数据库统一了 Agent 记忆Memory、知识库RAG与技能Skills。本指南讲解仓库中 examples/openwebui-plugin 提供的独立 FastAPI 工具服务器它将 OpenViking 的一组核心 HTTP 端点封装成OpenAPI 工具使 Open WebUI 无需粘贴 Python 脚本、无需在管理后台手动上传即可自动发现并调用ov_search、ov_add_memory等 7 个原生工具。读完本文你将掌握该插件的安装运行、环境变量语义、每个工具的请求/响应结构、底层转发与多租户鉴权原理以及如何按四步流程扩展出你自己的工具。背景Open WebUI 的两种工具集成机制Open WebUI 支持两种工具接入方式Python Functions把一段 Python 函数粘贴到 Open WebUI 管理后台中由 Open WebUI 运行时加载执行外部 OpenAPI 工具服务器提供一个 Web 服务Open WebUI 从/openapi.json自动发现工具清单并把每个操作operation暴露给 LLM 作为可调用工具。本插件实现的是第二种机制。它本质上是一个薄转发层thin translation layer每个工具路由把请求转发给对应的 OpenViking HTTP 端点、附加多租户标识头再把响应原样返回。插件内不包含任何业务逻辑——语义检索、内容写入、资源摄入等能力全部由 OpenViking 服务端完成见 openviking/server/routers 下的search.py、content.py、filesystem.py、resources.py、sessions.py等路由实现。这一设计的好处是同一套工具服务器可以被任何支持 OpenAPI 的客户端复用不仅限于 Open WebUI。插件架构与代码结构插件位于examples/openwebui-plugin/代码量极小共 4 个模块 1 组测试文件职责openviking_openwebui/config.py环境变量解析生成只读Settings数据类openviking_openwebui/client.py基于httpx.AsyncClient的薄 HTTP 客户端负责附加租户头与错误透传openviking_openwebui/tools.pyPydantic 请求模型 7 个 FastAPI 路由处理器openviking_openwebui/server.pycreate_app()组装 FastAPI 应用、生命周期管理与/health探针openviking_openwebui/main.pypython -m openviking_openwebui的入口调用 uvicorn 启动tests/test_tools.py用respx模拟 OpenViking HTTP 层的 9 个测试用例从源码结构可以看出插件启动链路是__main__.py读取环境变量 →server.create_app()在 lifespan 中创建共享OVClient挂到app.state→tools.router中的每个 handler 通过 FastAPI 依赖注入拿到同一个客户端 → 转发请求。依赖见 pyproject.tomlfastapi0.110、uvicorn[standard]0.27、httpx0.27、pydantic2.5要求 Python 3.9。快速开始运行工具服务器cd examples/openwebui-plugin pip install -e . OV_API_KEYyour-key python -m openviking_openwebui默认监听0.0.0.0:8765启动后终端应出现INFO: Uvicorn running on http://0.0.0.0:8765也可以使用pyproject.toml注册的控制台脚本openviking-openwebui直接启动。验证 OpenAPI 规格是否正常对外提供服务curl http://localhost:8765/openapi.json | jq .paths | keys输出应包含 7 个工具路径/tools/ov_search、/tools/ov_recall_memories、/tools/ov_add_memory、/tools/ov_list_memories、/tools/ov_read_resource、/tools/ov_add_resource、/tools/ov_session_status。FastAPI 会根据每个路由的operation_id在tools.py中显式设置自动生成 OpenAPI 文档这正是 Open WebUI 能识别工具名的关键。另外 server.py 还暴露了GET /health探针返回{status: ok, endpoint: OV_ENDPOINT}可用于容器编排与负载均衡的健康检查。接入 Open WebUI进入 Open WebUI →Settings→Tools→Add Tool Server粘贴工具服务器可达的地址例如http://localhost:8765Open WebUI 会自动抓取/openapi.json列出全部 7 个工具并在每次对话轮次中把它们作为可调用工具呈现给 LLM。整个过程无需复制粘贴 Python 文件、无需管理后台上传。tests/test_tools.py中的test_openapi_lists_seven_tools用例专门断言了/openapi.json中至少包含这 7 个operationId确保自动发现机制始终有效。配置全部通过环境变量插件没有配置文件所有配置均来自环境变量这是有意的设计——让部署单元保持一个二进制 一组环境变量。config.py中的load_settings()在进程启动时一次性读取因此修改环境变量后需要重启服务。变量默认值说明OV_ENDPOINThttp://localhost:1933OpenViking 服务端基础 URL末尾/会被自动去除OV_API_KEY空Bearer Token以Authorization: Bearer …头发送为空时不附加该头OV_ACCOUNTdefault租户Tenant以X-OpenViking-Account头发送OV_USERdefault用户以X-OpenViking-User头发送OV_AGENTdefaultActor peer ID以X-OpenViking-Actor-Peer头发送OV_BIND0.0.0.0:8765工具服务器绑定的host:portOV_TIMEOUT30调用 OpenViking 的 HTTP 超时秒几个值得注意的实现细节见 config.pyOV_BIND的解析是容错的bind_host/bind_port属性用partition(:)拆分缺省端口回退到8765解析失败也回退8765memories_uri属性固定返回viking://~/memories/——这是 OpenViking 中个人记忆的约定 URI 前缀ov_recall_memories、ov_add_memory、ov_list_memories三个工具都依赖它所有环境变量都经过strip()处理空字符串视为未设置并回退默认值。OVClient见 client.py在每次请求时统一构造请求头仅当OV_API_KEY非空才附加Authorization头X-OpenViking-Account、X-OpenViking-User、X-OpenViking-Actor-Peer三个租户头则总是附加。这些头正是 OpenViking 服务端鉴权体系识别的字段——在 openviking/server/auth/init.py 中可以看到服务端通过 FastAPIHeader依赖读取同名请求头trusted鉴权模式见 openviking/server/auth/plugins/trusted.py会直接信任并归一化这些头据此确定请求所属的 account/user。工具参考7 个工具的参数与端点映射下表是工具与 OpenViking 端点的完整映射工具OpenViking 端点用途ov_searchPOST /api/v1/search/find跨记忆、资源、技能做语义检索ov_recall_memoriesPOST /api/v1/search/find限定viking://~/memories/针对当前查询召回个人记忆ov_add_memoryPOST /api/v1/content/write写入viking://~/memories/name持久化一条新记忆ov_list_memoriesGET /api/v1/fs/ls?uriviking://~/memories/浏览记忆目录ov_read_resourceGET /api/v1/content/read读取任意viking://URI 的全文ov_add_resourcePOST /api/v1/resources摄入远程 URL 或服务端可达的路径文件ov_session_statusGET /api/v1/sessions/{id}查看会话的消息数、归档状态等元数据所有路由定义都位于 tools.py下面逐一给出源码确认的请求模型字段与约束。ov_search—— 顶层语义检索{query: …, limit: 10, target_uri: null, score_threshold: null}query必填自然语言查询limit默认10约束1 ≤ limit ≤ 100target_uri可选的viking://前缀用于把检索限定到某个子树score_threshold可选的相似度阈值约束0.0 ≤ score_threshold ≤ 1.0。响应为SearchResponsehits是由uri、score、snippet?组成的结构化命中列表外加raw保留 OpenViking 的原始响应。命中结果的展平逻辑在_hits_from_find中实现它会遍历 OpenViking/search/find响应result对象里的memories、resources、skills、results四个桶从每个条目提取uri或target_uri、score、以及snippet/abstract/preview三选一的摘要文本。这也是本工具能跨记忆、资源、技能一起搜的底层原因。ov_recall_memories—— 只搜个人记忆{query: …, limit: 6}与ov_search调用同一个POST /api/v1/search/find但target_uri被强制设为viking://~/memories/因此只检索个人记忆。适合在聊天中回答关于我你记得什么这类问题。limit默认6约束1 ≤ limit ≤ 50——比ov_search更小符合记忆召回的精简优先语义。ov_add_memory—— 持久化新记忆{name: profile.md, content: …, mode: replace, wait: false}name必填viking://~/memories/下的文件名例如profile.md代码中会strip()并去掉开头的/空名返回 400content必填记忆正文纯文本或 Markdownmode枚举replace | append | create默认replacewait布尔值默认false置true时阻塞直到语义索引完成。工具会把name拼成完整viking://~/memories/nameURI再POST /api/v1/content/write。响应为AddMemoryResponse包含最终uri与raw原始响应。测试用例test_ov_add_memory_writes_under_memories验证了请求体确实携带完整 URI 与内容。ov_list_memories—— 浏览记忆目录{recursive: false, limit: 200}对应GET /api/v1/fs/ls查询参数为uriviking://~/memories/、recursive布尔值转小写字符串、node_limit。limit默认200约束1 ≤ limit ≤ 1000透传为服务端的node_limit。测试用例test_ov_list_memories_calls_fs_ls断言了 URL 中这三个参数的编码结果。ov_read_resource—— 读取任意 viking:// 资源{uri: viking://~/memories/a.md, offset: 0, limit: -1}uri必填完整的viking://URIoffset默认0limit默认-1表示读取全部。对应GET /api/v1/content/read三个参数原样透传为查询参数。这是 LLM 拿到命中 URI 后展开全文的标准动作。ov_add_resource—— 摄入远程资源{path: https://example.com/doc.md, to: null, parent: null, reason: , instruction: , wait: false}path必填OpenViking 服务端可达的远程 URL 或本地路径to/parent可选的目标/父目录reason/instruction可选的摄入原因与附加指令wait是否阻塞等待摄入完成。对应POST /api/v1/resources是纯 HTTP 转发——路径/URL 的合法性校验完全由 OpenViking 服务端完成。测试用例test_ov_add_resource_posts_resources验证了请求体包含path与wait字段。ov_session_status—— 查询会话元数据{session_id: sess-42}对应GET /api/v1/sessions/{session_id}返回该会话的消息计数、归档状态、待处理 token 等信息。测试用例test_ov_session_status_gets_session断言了请求 URL 路径为/api/v1/sessions/sess-42。错误透传当 OpenViking 返回非 2xx 时OVClient.request会抛出携带status与响应体的OVError见 client.py路由层的_forward辅助函数见 tools.py会把它转成HTTPException原样保留上游的状态码与错误详情返回给调用方。测试用例test_error_pass_through验证了 404 错误体被完整透传。测试用 respx 模拟上游cd examples/openwebui-plugin pip install -e .[test] pytest tests -x -q测试套件tests/test_tools.py使用respx拦截并模拟 OpenViking 的 HTTP 层断言每个工具调用了正确的方法/路径/请求体并且逐字转发租户头。其中_assert_headers帮助函数集中校验四个请求头authorization: Bearer key-xyzx-openviking-account: acctx-openviking-user: alicex-openviking-actor-peer: webui测试通过create_app(SETTINGS)注入自定义Settings与httpx.ASGITransport无需真实启动网络服务见 server.py 的注释测试可注入自定义 Settings/OVClient。pyproject.toml中开启了pytest-asyncio的asyncio_mode auto因此异步测试函数无需显式标记。局限性与边界不支持流式输出Open WebUI 工具是请求/响应模型实时转录流式传输不在本插件范围内不支持文件上传ov_add_resource只接受远程 URL 或 OpenViking 服务端自身可达的路径。若要上传二进制数据应直接调用 OpenViking 服务端的temp_upload端点POST /api/v1/resources/temp_upload可携带?token临时上传凭证见 openviking/server/upload_token_store.py 与 openviking/server/mcp_endpoint.py无删除/移动类写操作插件按只读为主设计需要破坏性操作的用户请使用 OV CLI单进程单租户租户身份来自环境变量如果需要多租户请为每个(account, user)组合各跑一个工具服务器进程不捆绑 Open WebUI这只是工具服务器Open WebUI 实例需自行准备。扩展路线添加新工具的四步流程README 给出的扩展流程与源码完全对应在 openviking_openwebui/tools.py 中添加 Pydantic 请求模型添加路由 handler并用router.post(/tools/name, operation_idname)装饰——operation_id必须与工具名一致因为 Open WebUI 依赖它识别工具通过OVClientclient.get/client.post转发到对应 OpenViking 端点在 tests/test_tools.py 中仿照现有用例用respxmock 上游并断言转发正确性。社区可能期望的候选工具包括ov_session_create、ov_session_commit、ov_grep、ov_glob、ov_overview、ov_abstract等。由于插件本身是纯转发架构新增工具的边际成本很低——只需定义模型、路由与测试三处改动。安全注意事项切勿把OV_API_KEY提交进版本库一律通过环境变量注入工具服务器自身没有任何鉴权——请绑定到 localhost 或内网或在前端用代理强制鉴权租户身份属于服务端信任模型任何持有OV_API_KEY并伪造X-OpenViking-Account/User头的调用方都能读取该租户的数据。这与 OpenViking 的标准信任模型一致——在服务端trusted鉴权模式下这些头被直接信任见 openviking/server/auth/plugins/trusted.py。因此务必通过访问控制保护好OV_ENDPOINT指向的 OpenViking 服务。小结OpenViking Open WebUI 插件用不到两百行 Python 代码把一个 Agent 记忆/知识/技能后端无缝接入 Open WebUI 的工具生态7 个精心挑选的工具覆盖检索—召回—写入—浏览—读取—摄入—会话诊断的完整闭环全部通过 OpenAPI 自动发现零业务逻辑重复同时用环境变量保持了部署单元的极简。对于希望让 LLM 在对话中真正记住用户、检索知识、沉淀技能的开发者这是一条开箱即用的接入路径也为后续按四步流程扩展更多 OpenViking 能力留下了清晰范式。【免费下载链接】OpenVikingSelf-evolving Context Database for AI Agents. Unify Agent Memory, Knowledge RAG and Skills.项目地址: https://gitcode.com/GitHub_Trending/op/OpenViking创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
