终端服务部¶
上海中侨大学 · 人工智能学院 · 具身智能研究所 —— 终端服务部
一句话定位：我们负责实验室的服务器与算力、网络与设备互联、Agent 平台与工具链、生成式工作流、边缘设备部署、账号与数据服务——让实验室的算力、模型和设备，能被每个项目、每个人稳定地用起来。
一、一句话定位¶
实验室的核心支撑部门：负责构建和维护可靠的技术基础设施，也推动知识管理与智能化工具的开发应用。
所属：上海中侨大学 · 人工智能学院 · 具身智能研究所。英文名 Terminal Service Department（2026-10-15 正式采用），部门口号 Driving Infrastructure, Intelligence & Content。
产出是让实验室的技术能跑起来的那个环境：服务器不出事、网络连得通、模型跑得动、设备接得上、新人上手不用问人。判断标准只有一条：如果一件事的失败会让「整个实验室的很多项目同时做不下去」，那它就是我们的职责。
我们默认这么做¶
下面是建议，不是规定。写在这里是因为它们决定了我们默认怎么判断一件事该不该做、怎么算做完。
- Agent 能解决的让 Agent 解决；解决不了的，先想办法让 Agent 能解决。 同一套手工操作重复三遍以上，就值得写成脚本，或者写成一条 Agent 能跑的工作流。写不出来，通常说明流程还没想清楚。
- 能一条命令的不点十下鼠标，能自动的不靠人盯。 巡检、备份、发布都该是脚本，而不是「记得去做」。
- 先复现，再动手。 修之前先能复现，改完再复现一次。没复现过的「修好了」不算修好。
- 一次弄通，就写下来。 做完当天写，别等下次再想一遍；写不出来，说明这件事还没真弄懂。
- 不确定就说不确定。 没验证的结论标「待验证」，不要和事实混在一起。下判断之前先看日志、看监控，别先猜。
二、职责范围¶
**本节仍在确定中。**下面先保留部门既有的表述（三层核心价值 + 三项核心职能）；其中像「与宣传部协同运营社交媒体」这类条目是否仍由本部门承担，正在部门内部讨论。要确认边界，请直接问部门负责人，不要照本节自行推断。
2.1 三层核心价值¶
| 层次 | 一句话 |
|---|---|
| 稳定器 | 服务器 / NAS / 门户的稳定运行与安全防护 |
| 创新引擎 | AI 智能体与知识管理系统的研发与部署 |
| 放大器 | 用技术内容支撑社交媒体运营，扩大实验室的技术影响力 |
2.2 核心职能¶
- 基础设施运维：服务器和 NAS 的日常运维、门户网站的建设与维护、系统监控与故障排查。
- 知识管理与创新：知识库的构建与维护、智能体（AI Agent）的开发与应用、技术文档的整理与归档。
- 平台运营与内容创作：与宣传部协同运营社交媒体（微博、微信公众号、抖音等）、技术内容的策划与发布、品牌形象建设与对外宣传、社媒内容的技术支撑与后台管理。
2.3 按技术方向的细分¶
六个方向各自对应一页参考文档，具体需求与流程见职责与服务目录。
| 方向 | 管什么 | 边界 | 从哪页看起 |
|---|---|---|---|
| 服务器与算力 | 登录、环境、常驻服务、GPU 排队 | 不替项目调模型 | Linux 服务器运维、GPU 与 CUDA |
| 网络与设备互联 | 组网、内网互访、对外暴露 | 校园网线路与出口归网络中心 | Tailscale 专题 |
| Agent 平台与工具链 | 会话常驻、统一入口、编辑器与 CLI | 不写业务提示词 | Agent 平台部署、VSCode 专题 |
| ComfyUI 与生成式工作流 | 部署、显存与队列、模型存放 | 不负责创作 | ComfyUI 专题 |
| 边缘设备 Agent 部署 | MCU、单板机、现场自启动 | 不碰机械结构与电路 | 设备与 Agent 统一管理 |
| 账号权限与数据服务 | 账号、目录权限、凭据的归属与位置 | 只记录「在哪、谁管」，不入库明文 | 职责与服务目录 |
三、组织与分工¶
负责人与指导老师已确定；六个技术方向的负责人还在认领中。空缺的原因是还没定——见 内部台账。
| 角色 | 负责范围 | 现任 | 备注 |
|---|---|---|---|
| 部门负责人 | 对外接口、资源审批 | 冯周杰 | 尚未指定负责人的事项，默认由部门负责人兜底 |
| 服务器与算力 | 职责 1 | 待认领 | — |
| 网络与设备互联 | 职责 2 | 待认领 | — |
| Agent 平台与工具链 | 职责 3 | 待认领 | — |
| 生成式工作流 | 职责 4 | 待认领 | — |
| 边缘设备 | 职责 5 | 待认领 | — |
| 账号权限与数据服务 | 职责 6 | 待认领 | — |
| 指导老师 | 资源与合规把关 | 刘安骞 | — |
**分工按职责划分。**一人可兼多块，但每块必须有且只有一个负责人。
四、服务对象与对接方式¶
谁可以找我们¶
- 本实验室的项目组与课程：算力、服务器、组网、Agent 平台、ComfyUI、边缘设备。
- 本实验室个人成员：账号开通、开发环境、上手协助。
- 其它部门：与本部门职责交叉的部分（见第七节）。
怎么找¶
统一入口：在知识库仓库开一个「服务请求」Issue。（仓库地址见第九节）不走群里和口头：口头需求没人记录、没人跟踪，下一个遇到同样问题的人得再问一遍。
一份好的服务请求包含什么¶
| 要素 | 说明 |
|---|---|
| 请求类型 | 服务器与算力 / 网络与设备互联 / Agent 平台 / ComfyUI / 边缘设备 / 账号权限 |
| 申请人 | 姓名 + 所属项目或课程 |
| 需求描述 | 要做什么事。写「要一台服务器」看不出用途。说清用途，我们才能给对规格 |
| 时间期望 | 本周内 / 两周内 / 可排期 |
| 验收标准 | 怎么算做完了。例如「能在组网内访问到某服务」 |
**不要在 Issue 里写内网 IP、密码、密钥。**需要这些信息的，我们线下对接。
响应约定¶
紧急情况直接找值班人，别只开 Issue；一般请求、咨询与上手的响应时限见职责与服务目录的五、值班与响应。正式时限还在定，见内部台账 的 A6。
五、现有资源与能力清单（脱敏）¶
**真实的设备台账（主机名、地址、端口、归属人）只放在内部库。**公开库说明「我们有什么类型的能力」，「具体是哪台机器」留在内部库。这是为了不给实验室添麻烦——一台机器的地址泄露出去，风险在于它是一扇门。
有什么¶
- 服务器与算力：通用 Linux 服务器（常驻服务、数据存储、内部系统）、GPU 工作站（训练与推理）、Windows 工作站（图形界面与 Windows 生态工具）。
- 组网与访问：跨地点组网、子网路由（不必逐台配置就能访问内网整段地址）、带访问控制的内部 Web 服务统一入口（不必把服务直接挂到公网）。
- Agent 与工具链：共享的会话常驻环境（断开连接后长任务仍能继续）、共享知识与技能库（可被 Agent 直接调用的技能集合与共享记忆）、常用开发工具链清单（见参考）。
- 生成式工作流：ComfyUI 部署实例、统一的模型存放位置、常用工作流模板。
- 边缘设备：单板计算机与嵌入式 AI 设备若干，用于现场推理与设备接入的验证。
- 能覆盖的技术面：Linux 服务器与权限、服务托管与排障；Docker 编排与数据卷；组网、反向代理、HTTPS；CUDA 与显存管理；Agent 平台与技能库；ComfyUI 部署与调优；嵌入式接入与自启动；巡检、告警与备份。
六、本学年工作重点¶
部门负责人于 2026-10-10 确定了四条工作重点，落到知识库上分别是：
| 工作重点 | 在知识库里的落点 |
|---|---|
| 完善实验室基础设施 | 参考 把服务器怎么装、怎么管、怎么看写成能照着做的步骤；内部库补齐设备台账与网络拓扑 |
| 提高整体技术水平 | 学习 与参考：新人按路径自学；老人把踩过的坑写进经验 |
| 整理文档规范与操作流程 | 本章的职责与服务目录、仓库根的《知识库规范》与 _templates/、提 PR 时自动跑的四道检查 |
| 完成比赛项目 | 项目 按规范留档：比赛做完之后，下一届能照着复现，否则只能看到一张奖状 |
七、与其它部门的协作关系¶
| 对方 | 我们提供 | 我们需要 |
|---|---|---|
| 算法 / 模型方向 | 算力、训练环境、实验数据存储 | 资源需求的规格与时间窗口 |
| 硬件 / 机械方向 | 上位机、设备互联、边缘端部署 | 接口协议与设备侧的改动计划 |
| 课程与教学 | 可用的实验环境、上手文档 | 课程对环境的提前量 |
| 实验室管理 | 设备台账、网络拓扑、资源使用情况 | 采购计划、场地与合规口径 |
| 宣传部 | 社媒内容的技术支撑、后台与平台工具的选型 | 内容日历、发布计划与宣传口径 |
协作原则：跨部门的事情，在文档里写清楚谁负责哪一半，不要靠默契。默契在人员流动时会消失。
八、新人上手路径¶
按顺序走，不要跳：
- 读完本页与职责与服务目录，知道部门在干什么、边界在哪。
- 拿账号：服务器登录、组网接入、共享知识库。
- 按学习路径补概念，再按参考动手：先 Linux 服务器运维，再 Tailscale，然后选一个方向深入。
- 跟一个项目从零复现到跑通。
- 读经验，看别人踩过的坑，这一步最省时间。
- 写第一篇文档：把刚踩的坑按经验页的六节格式记下来。这一步做完才算入门。
新人最常问的三个问题：
| 问题 | 答案 |
|---|---|
| 这个操作不敢做，怕弄坏 | 先查服务目录是否属于「自助可做」；不在就开 Issue，不要试 |
| 文档里没写怎么办 | 说明文档有缺口，做完之后把缺口补上 |
| 某个服务挂了找谁 | 查职责与服务目录的「谁处理」栏 |
九、联系方式与值班¶
联系渠道已确定；值班表还在排，见 内部台账。
| 渠道 | 用途 | 说明 |
|---|---|---|
| 知识库仓库 Issue | 首选：服务请求、文档纠错 | 可追踪、可搜索，结论留得下来 |
| 部门负责人邮箱 | 不适合公开提的事、对外联系 | 冯周杰：2631792752@qq.com 或 z2631792752@gmail.com（两个都在用） |
| 部门讨论群 | 日常沟通、非正式咨询 | 群里的重要结论请回填到文档 |
| 值班人 | 服务中断等紧急情况 | 值班表待排 |
为什么把 Issue 放在首位：群消息会被刷掉，Issue 不会。任何「在群里讨论定了」的方案，没变成文档或 Issue 就等于没定。
本章导航¶
| 你想干什么 | 去这里 |
|---|---|
| 知道这个部门能做什么、边界在哪 | 本页 |
| 查某个操作该谁负责、能不能自己做 | 职责与服务目录 |
| 补概念、学技术、跟项目、看别人的坑 | 参考 · 项目 · 经验 |
| 看人员设备变动、知道哪些信息还没定 | 历史与交接 · 内部台账 |
这份介绍的状态¶
当前状态：草稿。框架已经完整，剩下几处标注「待补」的都还没确定，集中列在 内部台账。我们不编造信息来把文档填满——一份写着「待补」的文档，比一份编了内容让人误以为真的文档有用得多。补齐后请把 front-matter 里的 状态 改成 可用，并更新 更新 日期。