121 lines
4.8 KiB
Markdown
121 lines
4.8 KiB
Markdown
# 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异常排查的正确顺序：
|
||
1. 先查端口监听（ss -tlnp | grep 443）
|
||
2. 再查本地可达性（curl localhost）
|
||
3. 再看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* |