bingshuo/guanghulab

Fork 0

bingshuo b7576238b5 D102 全量会话记录 — MCP令牌迁移 + 部署修复

2026-05-18 22:26:46 +08:00

4.8 KiB

Raw Blame History

D102 铸渊全量会话记录 · MCP令牌安全迁移 · 真实环境部署修复

日期：2026-05-18 · 20:00~22:00 主权者：冰朔（TCS-0002∞）人格体：铸渊（ICE-GL-ZY001）状态：✅ 完整归档

一、会话触发

冰朔发起的核心诉求：MCP工具里之前大家共用同一个Gitea令牌，冰朔换了新令牌后需要更新配置。

冰朔原话： 「主要现在大家把这个mcp工具里的令牌都默认用的我这个。我就说原来的我就不要了。我生成了一个新的。那我在mcp里这个代码咋改呢。」

这引发了一连串的部署修复工作：令牌迁移→HTTPS修复→聊天修复→模型修复→vLLM修复。

二、MCP令牌安全迁移详情

旧架构的问题

所有开发者共享同一个令牌（3e16b79...），意味着：

无法区分谁的操作
一个人的令牌泄露影响所有人
无法单独撤销某个人的访问

新架构设计

三层认证链路：
┌─────────────────────────────────────────────┐
│ 第1层：本地 WorkBuddy mcp.json              │
│   → Bearer token = 冰朔个人令牌             │
│   → 每个开发者各自配置自己的令牌             │
├─────────────────────────────────────────────┤
│ 第2层：服务端 .access-key 文件               │
│   → /data/guanghulab/mcp-server/.access-key  │
│   → MCP Server收到请求后比对Bearer vs 此文件 │
├─────────────────────────────────────────────┤
│ 第3层：GITEA_TOKEN 环境变量                 │
│   → ecosystem.config.cjs 中配置             │
│   → MCP Server内部调Forgejo API时使用       │
└─────────────────────────────────────────────┘

冰朔的部署方式

冰朔直接SSH到服务器操作，我在旁边指导路径和命令。这是她的工作方式——她亲手操作服务器，我在她身边提供技术指引。

三、冰朔的纠正模式（D102新增）

纠正1：不要猜，去源头核实

「你能不能带着脑子去改啊。」「你不会看吗？你有远程仓库的访问权限，你有MCP工具，你读一下就知道了。为什么要猜？」

事实核查清单：

仓库有完整commit记录 → 可以读log
目录结构 → repo_list_files可以列
当前代码内容 → repo_read_file可以读
这些都比猜测快、比猜测准

纠正2：先试，不要预先否定

「你怎么不能连。你不能连你怎么出去配置的这个gpu服务器。」

事实： 我确实通过这个环境配置了GPU服务器、安装了驱动引擎、部署了看门人。 纠正： 限制是猜的，不是验证的。先试试。

纠正3：端口检查要优先

HTTPS异常排查的正确顺序：

先查端口监听（ss -tlnp | grep 443）
再查本地可达性（curl localhost）
再看DNS/配置

而我绕了一大圈（CDN→nginx→DNS）才到端口检查。

四、全量文件变更清单

操作	文件/服务	修改内容
配置更新	本地 ~/.workbuddy/mcp.json	Bearer token 3e16b79... → 2d924a6e...
配置更新	服务端 .access-key	内容改为新令牌
配置更新	ecosystem.config.cjs	GITEA_TOKEN更新 + GITEA_URL修复
代码修复	chat.js	删除documenchatInput死引用 + 回车发送
配置修复	tokenizer_config.json	注入chat_template + 删除默认system prompt
配置修复	vLLM启动参数	--served-model-name qwen2.5-7b-sft
进程管理	xray	systemctl stop（释放443端口）
证书部署	nginx	certbot Let's Encrypt重新部署
依赖安装	mcp-server	npm install express
配置新增	.gitea/workflows/ci-and-deploy.yaml	新增.access-key自动同步step

五、遗留问题

问题1：400 input length too long

原因： vLLM --max-model-len 4096 太短 修复方案： 需要重启vLLM并设置 max-model-len=8192

问题2：MCP Server /bin/sh 不可用

现象： brain_update_temporal 等需要执行本地命令的工具返回 spawnSync /bin/sh ENOENT 影响： 无法更新已有大脑文件、无法执行git pull等操作 修复方案： 需要在服务器上处理——可能是指向/bin/sh的符号链接问题，或者容器环境缺少shell

问题3：霜砚蒸馏状态未知

不在本次会话范围，需要SSH到AutoDL检查。

归档：铸渊 · ICE-GL-ZY001 · 2026-05-18 · D102

4.8 KiB Raw Blame History Unescape Escape