智能助手网
标签聚合 连接

/tag/连接

linux.do · 2026-04-18 17:35:40+08:00 · tech

使用hermes agent 通过MCP的方法将二者连接。 原理大概是这样 Notion ↔ [Notion 官方 MCP] ↔ Hermes Agent ↔ [FNS MCP / SSE] ↔ Obsidian ↑ ↑ hermes与FNS自部署在 VPS 都使用了什么 1.hermes agent 无需多言,类似于小龙虾openclaw这种 2.notion mcp 官方的,使用OA认证挂载后 Agent 能读 / 写 / 创建 / 搜索 Notion 页面 为什么不用 api的形式? 因为闲鱼上卖的都是那种商业试用版,hermes 本身内置了 Notion API 适配,但因为访客账号无法在 workspace 里创建 internal integration、拿不到 integration token,所以只能走官方 MCP 的 OAuth 路径。 3. Fast Note Sync (FNS):Obsidian 插件,把本地 Vault 同步到服务器,同时暂开 SSE 协议的 MCP 服务,Agent 走这个接口读写 Vault,这个插件是L站一位佬友制作的,十分的好用。 为什么要这样做 主要还是看重他notion的AI功能。现在的notion的ai可以去闲鱼,一个月才5块钱,可以基本上无限使用opus4.7这种模型,而且对笔记的优化相当好,这个是obsidian比不了的,但是notion这个始终是云端,而且我觉得分类做的不太好,慢慢就会变成垃圾场那种。 我看过不少人同时用notion和obsidian一起用,但每次都得手动整理,**手动搬的本质是「哪天懒了,整个系统就废了」**现在已经出现了这种例如小龙虾与hermes,利用一下。 使用hermes连接笔记软件有一个好处,你根本不用打开笔记软件,与hermes聊天,聊到一个东西,直接和他说记录到笔记中,他就会帮你整理记录。或者说你在notion中记录,在obsidian中,他都可以帮你找出来,而不用打开软件去操作。 我的notion与obsidian设置 noiton 🗂️ Hermes 知识流转中心 ├─ 📥 待归档 ← 我把要归档的东西什在这里 ├─ ✅ 已归档 ← Hermes 搬完后自动移过来 ├─ 📋 Hermes 操作日志 ← Hermes 每次干活都写一行 └─ 📖 Hermes 使用说明 ← 写给 Hermes 看的手册(关键!) obsidian Vault/ ├─ 00-Inbox/ ← Hermes 搬来的全进这里 ├─ 10-信息/ ├─ 20-配置/ └─ 30-数学/ ← 这些是我手动分类的永久位置 三条铁律 绝不做双向同步,单向: Notion → Obsidian 。搬到 Obsidian 后相当于快照,想改就在 Obsidian 里新写一份,不改已归档的。 Agent 不碰正文,ermes 只做三件事: 读取 · 搬运,加一下标签或者双链。 操作日志必须有。 踩过的坑 1.假如你是在像我一样在VPS中部署的hermes,notion的mcp OA跳转主要注意 VPS 是 headless 环境,Notion MCP 的 OAuth 回调地址默认是 http://127.0.0.1 : ,本地浏览器访问不到服务器的 loopback。解决办法是用 SSH 本地端口转发,然后在本地浏览器点授权链接,回调会落到本地端口再转回服务器完成认证。 2.hermes暂不支持SSE的mcp配置,需要补充上为 Hermes 补上 SSE MCP 支持。 1 个帖子 - 1 位参与者 阅读完整话题

linux.do · 2026-04-18 17:07:58+08:00 · tech

起因 今天在使用WSL上的Centos时, 发现Vscode远程连接上不上了, 然后想起来vscode之前下载claude插件自动更新了一次, 导致它的版本变成了v1.106.0, 然后就连不上了. 从 VS Code 1.99(2025年3月发布) 开始,官方预编译的 VS Code Server 对 Linux 发行版的系统依赖做了升级,要求远端服务器必须满足: glibc >= 2.28 libstdc++ >= 3.4.25 以及对应的动态链接环境 ssh远程连接时错误信息如下: [2026-04-18 03:33:45.663] Starting server: /home/user/.vscode-server/bin/ac4cbdf48759c7d8c3eb91ffe6bb04316e263c57/bin/code-server --host=127.0.0.1 --port=0 --connection-token=1869292326-2464295744-3154885190-4149685785 --use-host-proxy --without-browser-env-var --disable-websocket-compression --accept-server-license-terms --telemetry-level=all [2026-04-18 03:33:45.664] /home/user/.vscode-server/bin/ac4cbdf48759c7d8c3eb91ffe6bb04316e263c57/node: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by /home/user/.vscode-server/bin/ac4cbdf48759c7d8c3eb91ffe6bb04316e263c57/node) [2026-04-18 03:33:45.664] /home/user/.vscode-server/bin/ac4cbdf48759c7d8c3eb91ffe6bb04316e263c57/node: /lib64/libc.so.6: version `GLIBC_2.27' not found (required by /home/user/.vscode-server/bin/ac4cbdf48759c7d8c3eb91ffe6bb04316e263c57/node) [2026-04-18 03:33:45.664] /home/user/.vscode-server/bin/ac4cbdf48759c7d8c3eb91ffe6bb04316e263c57/node: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by /home/user/.vscode-server/bin/ac4cbdf48759c7d8c3eb91ffe6bb04316e263c57/node) [2026-04-18 03:33:45.664] /home/user/.vscode-server/bin/ac4cbdf48759c7d8c3eb91ffe6bb04316e263c57/node: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by /home/user/.vscode-server/bin/ac4cbdf48759c7d8c3eb91ffe6bb04316e263c57/node) 解决方法一: 官方推荐的自定义运行库法 code.visualstudio.com Can I run VS Code Server on older Linux distributions? - Remote Development FAQ This article covers frequently asked questions for each of the Visual Studio Code Remote Development extensions. See the SSH, Containers, and WSL articles for more details on setting up and working with each of their respective capabilities. Or try... 以下是AI关于这个文档的解释: VS Code 1.99 之后,官方发的 VS Code Server 二进制 默认要求远端系统有较新的: glibc >= 2.28 libstdc++ >= 3.4.25 以及相应动态链接环境 如果你的老服务器系统本身太旧,比如 CentOS 7,没有这些库,Server 本体会启动失败 这时候可以额外准备一套“较新的运行库目录”,让 VS Code Server 不要使用系统自带旧 glibc,而是改为加载你提供的那一套新库. 这个“较新的运行库目录”,官方建议你用 Crosstool-ng 去构建,这就是文档里说的 sysroot 准备工具: v0.18.x 以上的 patchelf. Release 0.18.0 · NixOS/patchelf · GitHub 在 rpmfind.net 中找到所需要的 glibc 2.28 地址: RPM resource glibc 选择AlmaLinux 8.10 BaseOS for aarch64 glibc-2.28-251.el8_10.31.aarch64.rpm 在 rpmfind.net 中找到所需要的 libstdc++ 地址: https://www.rpmfind.net/linux/almalinux/8.10/BaseOS/x86_64/os/Packages/libstdc++-8.5.0-28.el8_10.alma.1.i686.rpm 选择AlmaLinux 8.10 BaseOS for aarch64 libstdc++-8.5.0-28.el8_10.alma.1.i686.rpm 不要直接安装 rpm!!! mkdir -p /home/user/lib/vscode_server_linux_root mv glibc-2.28-251.el8.x86_64.rpm /home/user/lib/vscode_server_linux_root/ mv libstdc++-8.5.0-21.el8.x86_64.rpm /home/user/lib/vscode_server_linux_root/ cd /home/user/lib/vscode_server_linux_root # 将rpm文件解压到当前目录 rpm2cpio glibc-2.28-251.el8.x86_64.rpm | cpio -idmv rpm2cpio libstdc++-8.5.0-21.el8.x86_64.rpm | cpio -idmv # 检查下 so 文件中的 ABI 兼容版本是否符合 VSCode 或者 Node.js 的要求 strings ./usr/lib/libc.so.6 | grep -E '^GLIBC_[0-9.]+' | sort strings ./usr/lib/libstdc++.so.6 | grep -E '^GLIBCXX_[0-9.]+' | sort # 设置环境变量, 两个环境变量都试一下 export VSCODE_SERVER_CUSTOM_GLIBC_LINKER=/home/user/my_lib/vscode_server_linux_root/usr/lib # export VSCODE_SERVER_CUSTOM_GLIBC_LINKER=/home/flipped/my_lib/vscode_server_linux_root/usr/lib/ld-linux.so.2 export VSCODE_SERVER_CUSTOM_GLIBC_PATH=/home/user/my_lib/vscode_server_linux_root/usr/lib export VSCODE_SERVER_PATCHELF_PATH=/home/user/my_lib/vscode_server_linux_root/bin 理论上这样之后, node 应该可以正常启动了, 但是我在wsl上的centos7.9进行测试时, 即使设置了环境变量, 服务器上的node也没有到我指定的目录下去找2.28的glibc. 然后我也尝试了手动patch node. 但发现patch后, node --version 都运行不了. [!NOTE] 不一定起作用 若环境变量不生效,可尝试直接修改 VS Code Server 内嵌 Node.js 的动态链接路径: patchelf --set-interpreter ${CUSTOM_LIB_DIR}/usr/lib64/ld-linux-x86-64.so.2 \ --set-rpath ${CUSTOM_LIB_DIR}/usr/lib64 \ ~/.vscode-server/bin/<VSCode版本号>/node 解决方法2: 第三方补丁工具 从社区仓库下载与本地 VS Code 版本匹配的包: 仓库地址: MikeWang000000/vscode-server-centos7 查看本地 VS Code 版本:点击左下角齿轮 → 关于 → 复制版本哈希(如 ac4cbdf48759c7d8c3eb91ffe6bb04316e263c57 ) # 1. 创建VS Code Server目录(若已存在则跳过) mkdir -p ~/.vscode-server # 2. 解压下载的预补丁包 tar xzf vscode-server_*.tar.gz -C ~/.vscode-server --strip-components 1 # 3. 执行补丁脚本 ~/.vscode-server/code-latest --patch-now # 4. 替换官方内嵌的Node.js(替换为预编译的兼容版本) cp -f ~/.vscode-server/cli/servers/Stable-<版本哈希>/server/node \ ~/.vscode-server/bin/<版本哈希>/node 使用这个方案, 我电脑上能够连接到centos了, 但是远程连接后, 无法在vscode的集成终端中使用 code a.log 打开服务器上的文件, 报错如下: user@user:test$ code . Unable to connect to VS Code server: Error in request. Error: connect ENOENT /run/user/1000/vscode-ipc-d2af735a-73ee-499c-9f8c-48fa19a6199e.sock at PipeConnectWrap.afterConnect [as oncomplete] (node:net:1637:16) { errno: -2, code: 'ENOENT', syscall: 'connect', address: '/run/user/1000/vscode-ipc-d2af735a-73ee-499c-9f8c-48fa19a6199e.sock' } 除了上面给出的预编译后的node文件, 在下面这个issue里面针对centos上运行v18以后的nodejs的问题, 也提供了一个预编译好的版本 github.com/nodejs/node Node.js is showing error "node: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by node)" 已打开 05:40AM - 28 Mar 24 UTC 已关闭 08:38PM - 17 May 25 UTC yogeshlc ### Version node-v20.11.0-linux-x64.tar.xz ### Platform Linux yogVM 5.4.17-21 … 36.325.5.1.el7uek.x86_64 ### Subsystem _No response_ ### What steps will reproduce the bug? - Extract node.js tar at location /usr/local - check node --version cmd which is failing with error Error: node --version node: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by node) node: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by node) node: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by node) node: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by node) node: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by node) node: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by node) ### How often does it reproduce? Is there a required condition? _No response_ ### What is the expected behavior? Why is that the expected behavior? node --version v20.11.0 ### What do you see instead? node --version node: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by node) node: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by node) node: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by node) node: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by node) node: /lib64/libc.so.6: version `GLIBC_2.28' not found (required by node) node: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by node) ### Additional information _No response_ 但我用这个, 虽然也能正常连接, 但无法打开vscode中的集成终端. 报错如下. 结尾 佬友们帮忙看看, 为什么我使用官方文档里面的方法, 设置环境变量之后还是没有办法让服务器上的node到我指定的目录下去找glibc. 2 个帖子 - 2 位参与者 阅读完整话题

linux.do · 2026-04-17 23:03:48+08:00 · tech

想使用WARP connector连接下本地设备和一个在香港的server,因为server所在的网络比较特殊,只允许80和443的出口流量,所以cloudflared tunnel需要的7844端口用不了,但是WARP应该只需要80或者443的出口流量(我不太确定,我安装之后可以在cloudflare的网站上看到我的设备在线,也能进行test,感觉没有问题),但是还是没办法连接,问了下AI,基本排查了以下问题: splittunnel配置问题,我本地使用的include模式,已经把WARP分配的IP网段包含进去了; 已经开启了WARP to WARP功能,各个WARP设备应该可以相互连接 没有设定任何的访问policy,整个组织只有我一个用户 使用的都是MASQUE协议 1 个帖子 - 1 位参与者 阅读完整话题

linux.do · 2026-04-17 22:15:45+08:00 · tech

笔者一直想通过手机控制电脑,从而将自己的工作空间解放,实现床上、地铁上、咖啡厅肆意办公,前段时间了解到happy coder,并在今天成功使用。但是遇到一个问题,在手机端的对话结束后会显示 并且对话被锁住无法继续。但是在电脑上实际使用该语句则会要求加上 --fork-session(报错如下 Error: --session-id can only be used with --continue or --resume if --fork-session is also specified.) 但是加上后,虽然会重新回到这个对话,但是是本地模式,手机端的happy会话还是无法连接。想问问各位佬友有没有解决办法,球球。 3 个帖子 - 2 位参与者 阅读完整话题

www.ithome.com · 2026-04-17 16:10:48+08:00 · tech

IT之家 4 月 17 日消息,vivo 官方今日宣布,vivo TWS 5i 耳机开启预约, 4 月 27 日正式发售 ,官方暂未公布这款耳机的价格。 预约界面显示,这款耳机拥有留白、墨黑、天青三种颜色可选。vivo TWS 5i 耳机拥有 50h 续航,蓝牙 5.4 支持多设备双连接,此外支持 AI 通话降噪功能。 作为参考,前代产品 vivo TWS 3i 发布于 2024 年 10 月,使用蓝牙 5.3 协议,续航约 45 小时(长续航版为 50 小时), 售价 99 元起 : 标准版: 99 元 长续航版:定价 169 元, 首发 129 元 IT之家附前代 vivo TWS 3i 无线耳机亮点功能如下:

linux.do · 2026-04-17 10:32:54+08:00 · tech

Stream disconnected before completion: websocket closed by server before response.completed 如果佬们用过sub2api反代openai时如果打开websocket连接的话,一定会看到上面的提示,即使你在 账号管理 里对每个账号的 WS Mode 都开启了 passthrough 透传,你还是无法使用WS协议连接。 这就导致必须到 config.toml 配置文件里关掉站点的websocket支持,不然每次都会优先尝试WS协议去重试5次才会退回普通的流式。 今天心血来潮去sub2api的github上看了下,发现了官方合并了 Merge pull request from KnowSky404/fix/ws-codex-scheduler-cache-1662 这个pr。 由于官方还没有发版所以我本地pull打包了试了一下,发现还真是可以使用websocket协议了,不会再出现上面提示的错误了。 看了一下pr内容, 原来BUG产生的 原因是: scheduler_cache 在生成账号cache时没有把WS字段写入 redis cache。scheduler选账号时优先读取的是这个快照,而不是数据库原始账号,即使你把账号的 WS Mode 设为 透传(passthrough) ,scheduler 从 cache 看到的仍然是“没有 WS 能力”(或者说WS Mode被设置成关闭)的账号。即便 cache miss 后回源数据库重新构建 cache ,由于 cache 写入逻辑本身就漏字段,重建出来的仍然是错误 cache,所以 WS 选账号时会长期返回 no available OpenAI accounts。 现在opus 4.7也更新了,希望官方尽快发版吧,WS协议我的体感比普通的流式好很多。 2 个帖子 - 2 位参与者 阅读完整话题

www.ithome.com · 2026-04-16 18:36:06+08:00 · tech

IT之家 4 月 16 日消息,据 Tom's Hardware 报道,IPv6 协议是构成互联网骨干网的重要基础之一,于 1998 年设计,旨在取代地址数量有限的 IPv4。尽管 IPv6 提供了 2^128(2 的 128 次方)个可用地址,能一次性解决所有网络地址分配问题,但早期却被视作实施复杂、令人头疼、几乎不可能普及的累赘方案。 随着时间推移,现实需求迫使局面发生改变。谷歌的监测数据显示, 在 3 月 28 日某一时刻,全球 50% 的用户通过 IPv6 连接访问其服务,创下历史性首次 。亚太网络信息中心 APNIC 的统计表明,全球已有 43% 的用户在使用该协议,亚洲和美洲正逐步逼近 50%。与此同时,Cloudflare 数据显示,40% 的网络流量基于 IPv6 传输,如果考虑到其统计的是实际传输数据包而非仅统计地址,这一数据相当可观。 据IT之家了解,久经考验的 IPv4 诞生于 1980 年,采用我们熟知的 255.255.255.255 格式,理论上可提供约 43 亿个地址,实际可用约 37 亿。这一数字听起来一直很庞大,但没人能预料到互联网设备的爆发式增长速度。 负责管理北美 IPv4 地址的 IANA 机构在 2011 年左右耗尽了地址;欧洲对应的 RIPE NCC 则在近七年前的 2019 年就已无 IPv4 地址可分配。亚洲、非洲和拉丁美洲的 IP 地址管理机构也在同一时期耗尽地址。 联网设备的井喷式增长彻底耗尽了 IPv4 地址空间:家用电脑率先大量占用地址,随后联网智能手机迅速跟进。在过去十几年里,物联网设备与云计算的兴起,让仅剩的零星地址也被迅速瓜分。早在 2019 年,单个 IPv4 地址就已卖到 50 美元,如今仍是稀缺资源,甚至整段地址被用作贷款抵押。 如今,大多数人都能轻松开通云服务器,但要让其面向公网,就必须分配公网地址。亚马逊从 2024 年起将这种稀缺性转化为商业模式,为每个 IPv4 地址按每小时 0.005 美元收费。乍一看这一做法略显“鸡贼”,但确实推动了不少工程师为服务添加 IPv6 支持,从而打破普及过程中“先有鸡还是先有蛋”的循环。 如今,从技术层面看,几乎没有理由不使用 IPv6,尽管工程师们总爱抱着早已过时的顾虑不放。早期,IPv6 隧道穿透 IPv4 的方案繁琐且不稳定;而后来广泛使用的 NAT(网络地址转换)技术让多台设备可共用一个地址(就像大多数家庭网络),也让反对者认为没必要部署 IPv6。 还有人认为,IPv6 数据包头部多出的约 20 字节会导致明显带宽损耗、更高 CPU 占用,甚至带来额外运维麻烦。事实是,早在 11 年前,Facebook 的测试就发现 IPv6 连接整体速度快 10%–15%;网络巨头 Akamai 则观察到移动端页面加载速度提升 5%。速度提升的核心原因几乎可以确定:在 IPv6 环境下,几乎不需要 NAT、代理等复杂转换处理,绝大多数场景下设备都能直接互联。 不过,最大的原因或许还是那句老话:没坏就不用修。再加上大多数企业只关注下一季度的业绩,而不是几个月甚至几年后才会产生实际成本的问题。

www.ithome.com · 2026-04-16 15:33:04+08:00 · tech

IT之家 4 月 16 日消息,科大讯飞现已在京东上架一款 AI 智能鼠标 AM50pro,其内置 AI 功能、支持星闪连接, 定价为 498 元(附带充电底座和鼠标垫) 。 该鼠标可选黑白红三种配色,整体重量 66g,支持有线 / 接收器(星闪)/蓝牙连接,鼠标采用光微动,按键寿命约 7000 万次,其有线模式回报率至高可达 4KHz、接收器模式(星闪)模式至高可达 2KHz,DPI 覆盖 100-16000。 官方强调该鼠标内置 Qwen Plus、混元、豆包、讯飞星火、DeepSeek 大模型调用功能,可以轻松利用 AI 独立按键唤醒操作。 IT之家附产品参数: 京东 科大讯飞 AI 智能鼠标 AM50 pro 498 元 直达链接

www.ithome.com · 2026-04-15 21:57:11+08:00 · tech

IT之家 4 月 15 日消息,Logitech 罗技现已推出 Alto Keys 琥珀 K98M / K98S Plus 机械键盘,售价分别为 399 元和 499 元。 IT之家注意到,相较无 Plus 后缀的原版, 新款为此前仅能充电的 USB-C 接口补足数据传输功能 ,支持 1kHz 回报率有线连接;加上此前就有的蓝牙 LE 和罗技 Bolt,K98M / K98S Plus 正式成为“三模”产品。 这两款键盘的整体配置与此前相比并无重大变化,仍然是 UniCushion 结构搭配大理石轴 (K98M Plus) 或轻音粉轴 (K98S Plus),调整之处包括 续航从 1 年延长到 550 天 、 白色背光现在支持 6 种模式 。 京东 罗技 K98M Plus 键盘 499 元 直达链接 京东 罗技 K98S Plus 键盘 599 元 直达链接