基于LLM与SSH隧道的集群AI助手PhDbot：架构、部署与安全实践-编程阁

1. 项目概述：一个运行在集群上的AI研究助手

如果你和我一样，每天大部分时间都花在实验室的服务器上，盯着终端跑实验、改配置、看日志，那你肯定也幻想过能随时随地“遥控”这一切。从咖啡厅的沙发上，从通勤的地铁里，甚至是从健身房的跑步机上，都能轻松地检查一下训练进度，或者提交一个新的任务。PhDbot 这个项目，就是把这个幻想变成了现实。

简单来说，PhDbot 是一个轻量级的AI研究助手，它的核心是一个运行在你计算集群（无论是学校的Slurm集群、AWS EC2实例，还是你自己的工作站）上的“智能代理”。你不再需要通过复杂的SSH终端和命令行来管理你的研究任务，而是可以通过一个简单的聊天界面——支持网页、iPhone，甚至Apple Watch——用自然语言告诉它你想做什么。比如，你可以问它：“帮我看看实验exp_20250415的loss曲线”，或者直接命令它：“在GPU节点上启动一个新的训练任务，使用config_v2.yaml这个配置文件”。剩下的，就交给这个“驻守”在服务器上的AI助手去执行。

这个想法的美妙之处在于它的极简和普适。它不试图取代你现有的工作流，而是作为一个无缝的“翻译层”和“执行层”附着在上面。你不需要在服务器上部署一套庞大的Web管理面板，也不需要开放一堆有安全隐患的端口。PhDbot 只依赖最基础的SSH隧道（端口22），将你设备上的聊天指令安全地传递到服务器端的Agent，由Agent理解你的意图，并转化为具体的Shell命令或文件操作来执行。对于经常需要移动办公、但又离不开强大算力的研究者、工程师和学生来说，这无疑是一个解放生产力的利器。

2. 核心架构与工作原理拆解

2.1 整体通信链路：从手表到服务器

PhDbot 的架构设计清晰地划分了“客户端”和“服务端”的界限，并通过标准的、安全的协议将它们连接起来。整个数据流可以概括为：用户指令从最前端的交互界面（Web/iOS/Watch）发出，经由一个本地中继客户端，通过SSH隧道抵达远程服务器上的Agent，Agent调用大语言模型（LLM）理解指令并执行相应操作，最后将结果沿原路返回。

让我们拆解一下上文中那个ASCII架构图里的每一个环节：

Apple Watch: 这是最轻量级的入口。通过WatchConnectivity框架与配对的iPhone应用进行通信。它只负责发送简短的指令（如“状态？”、“停止作业X”）和接收精简的回复。所有复杂逻辑都在iPhone App中处理。
iPhone App (iOS Client): 这是移动端核心。它内置了SSH客户端库（项目使用的是Citadel），负责与远程服务器建立连接。它从Watch或自身UI接收用户输入，将其封装成标准格式的消息，通过建立的SSH隧道发送给服务器上的Agent。
Web Client: 运行在本地浏览器中（通常是localhost:3000）。它通过一个本地的Node.js服务与服务器通信。这个Node.js服务的作用与iPhone App类似，也是作为SSH隧道的前端代理。
Client (Node.js / iOS App): 这是关键的中继层。无论是Web后端还是iOS App，它们都扮演着相同的角色：创建并维护一个到远程服务器的SSH隧道。这个隧道通常是将本地的一个端口（如3001）转发到服务器Agent监听的本地Socket端口（如127.0.0.1:8888）。这样，前端界面（浏览器/手机UI）只需要访问本地的localhost:3001，流量就会被自动、安全地导向远端的Agent。
Agent (Python): 这是整个系统的“大脑”和“执行者”，常驻在集群服务器上。它包含几个核心模块：
- Agent API: 一个基于HTTP或WebSocket的轻量级API服务，监听本地Socket，接收来自SSH隧道的指令。
- LLM Interface: 对接大语言模型（如Gemini）。当收到一条自然语言指令时，Agent会将其与当前上下文（如工作目录、运行中的作业列表）一起发送给LLM，请求LLM将其“翻译”成一条或多条可执行的Shell命令或文件操作。
- Command Executor: 安全地执行LLM生成的命令。这里必须包含严格的沙箱或权限检查，防止恶意指令。
- File Operator: 处理文件读写、查找、编辑等请求。

关键设计洞察：整个系统唯一需要在防火墙上开放的端口就是22（SSH）。这是几乎所有服务器和集群都默认开放且经过严格安全审计的端口。PhDbot 利用这一点，将所有自定义通信协议都承载在SSH隧道之内，极大地减少了攻击面，也避免了在集群管理严格的机构中申请开放额外端口的麻烦。

2.2 为什么选择“Agent + LLM”的架构？

这可能是你第一个疑问：为什么不直接做一个远程Shell的Web终端？或者一个定制化的集群管理Web面板？PhDbot 选择“智能代理”这条路，是为了解决几个更根本的痛点：

降低操作心智负担：记住sbatch、sinfo、sacct的各种参数及其组合，对于不常使用Slurm的用户来说是门槛。LLM可以将“帮我用两张A100跑一下这个模型”翻译成正确的#SBATCH指令和srun命令。
处理模糊意图：用户指令往往是目标导向的，而非具体命令。例如，“我的实验是不是出错了？” Agent需要理解这个意图，然后自动执行一系列检查：tail最新的日志文件，grep错误关键词，检查GPU使用率，最后汇总成一个人类可读的报告返回。
上下文感知：一个好的研究助手应该记得你之前的工作。Agent可以维护会话上下文，当你问“上一个实验的结果怎么样？”时，它知道指的是哪个实验目录下的哪个结果文件。
可扩展性：基于LLM的Agent架构是“可编程”的。你可以通过修改提示词（Prompt）来教它新的技能，比如学习你们实验室特有的脚本命名规范，或者集成内部的数据可视化工具。这比硬编码所有功能要灵活得多。

当然，这个架构也引入了新的挑战，主要是LLM生成命令的可靠性与安全性。一个胡乱生成的rm -rf /命令将是灾难性的。因此，在Agent的实现中，命令执行前的验证、限制可访问的路径范围、以及关键操作前的二次确认，都是必须严格设计的环节。

3. 详细部署与配置指南

3.1 服务器端（Agent）部署详解

服务器端是PhDbot的“驻守大脑”，它的稳定运行是整个系统的基础。部署过程不复杂，但有几个细节需要注意。

第一步：环境准备与文件传输

假设你的集群登录节点地址是cluster.university.edu，用户名是research。

# 1. 在本地项目目录下，将必要文件打包并传输到服务器 # 注意：我们只传输 server/ 目录和 settings.yml 配置文件，客户端代码不需要放在服务器上。 scp -r server/ settings.yml research@cluster.university.edu:~/phdbot/

这里有一个实操心得：建议在服务器上创建一个独立的项目目录，比如~/phdbot/，并将Agent运行所需的依赖与环境隔离在此目录下。可以使用Python的venv虚拟环境。

第二步：配置 settings.yml

settings.yml是系统的中枢配置文件，需要仔细填写。我们逐项分析：

api: provider: "gemini" # 目前支持Gemini，架构上可扩展其他LLM api_key: "YOUR_GEMINI_API_KEY" # 从Google AI Studio获取，这是Agent“思考”的燃料 model: "gemini-3.1-pro-preview" # 建议使用最新预览版模型，代码生成和理解能力更强 ssh: host: "cluster.university.edu" # 你的集群登录节点地址 port: 22 # 通常都是22，除非管理员改了 username: "research" # 你的登录用户名 password: "your_password" # 你的SSH密码。注意：对于密钥登录，这里可能需要留空或调整客户端代码。 agent: socket_host: "127.0.0.1" # Agent API监听的地址。必须为127.0.0.1，确保只接受来自本机SSH隧道的连接，这是安全关键！ socket_port: 8888 # 监听的端口，可自定义，但需与客户端转发配置对应。

重要安全提示：将包含API Key和密码的settings.yml文件直接上传到服务器存在风险。更佳实践是：
将settings.yml加入.gitignore，避免提交到版本库。
在服务器上，通过环境变量来传递敏感信息。可以创建一个start.sh脚本，在启动前读取环境变量并写入临时配置，或者直接修改Agent代码使其从环境变量读取api_key和ssh.password。

第三步：安装依赖与启动Agent

进入服务器上的项目目录，运行启动脚本：

ssh research@cluster.university.edu cd ~/phdbot/server bash start.sh

让我们看看一个健壮的start.sh脚本应该包含什么：

#!/bin/bash # start.sh # 进入脚本所在目录 cd "$(dirname "$0")" # 检查Python版本，推荐3.10+ if ! command -v python3 &> /dev/null; then echo "Python3 not found. Please install Python 3.10 or higher." exit 1 fi # 创建并激活虚拟环境（推荐） if [ ! -d "venv" ]; then echo "Creating virtual environment..." python3 -m venv venv fi source venv/bin/activate # 安装依赖 echo "Installing Python dependencies..." pip install --upgrade pip pip install -r requirements.txt # 检查配置文件是否存在 if [ ! -f "../settings.yml" ]; then echo "Error: ../settings.yml not found!" exit 1 fi # 启动Agent echo "Starting PhDbot Agent..." python agent.py

requirements.txt通常包含flask(或fastapi用于API)、google-generativeai(用于Gemini)、pyyaml(用于读取配置) 等库。

启动后，Agent会在后台运行，监听127.0.0.1:8888。你可以用ps aux | grep agent.py检查进程，或者用curl 127.0.0.1:8888/health（如果设计了健康检查端点）来测试。

3.2 客户端部署与连接

客户端是你的“遥控器”。PhDbot 提供了Web和iOS两种客户端，它们核心功能一致：建立SSH隧道并提供一个聊天界面。

Web客户端部署：

Web客户端是一个典型的Node.js前后端应用。前端（React/Vue）负责聊天界面，后端（Express/Koa）负责创建SSH隧道。

# 1. 克隆或下载项目后，进入客户端目录 cd client # 2. 安装Node.js依赖 npm install # 这里可能会安装 `ssh2` 或类似的SSH2客户端库，以及Web框架和前端构建工具。 # 3. 启动开发服务器 npm start # 这个命令通常会同时启动后端隧道服务和前端开发服务器，并打开浏览器访问 http://localhost:3000

启动后，浏览器打开localhost:3000。在连接界面，你需要填写：

SSH隧道目标：即你的服务器地址和端口（cluster.university.edu:22）。
SSH认证信息：用户名和密码（或私钥路径）。
本地转发规则：将本地某个端口（如3001）转发到服务器的127.0.0.1:8888。

点击连接，如果一切正常，WebSocket或HTTP连接将通过隧道建立，你就可以开始聊天了。

iOS客户端部署：

iOS客户端的部署稍微复杂，因为它涉及到Xcode和苹果开发者账号。

打开项目：用Xcode打开ios/PhDBot.xcodeproj。
添加依赖：按照指引，通过Swift Package Manager添加https://github.com/Joannis/Citadel.git库。这是一个纯Swift的SSH2客户端实现，比绑定OpenSSL库更简洁。
配置签名：在Xcode的Signing & Capabilities中，选择你的个人开发团队（需要免费的Apple ID开发者身份）或付费开发者账号。这是能在真机上运行App的前提。
修改连接配置：你需要在iOS App的代码中（可能是一个配置页面或硬编码的初始设置）填入服务器的SSH信息和Gemini API Key。出于安全考虑，绝对不要将敏感信息硬编码在提交的代码中。更好的做法是让用户在App首次启动时输入，并安全地存储在iOS Keychain里。
运行：用USB连接你的iPhone，在Xcode顶部选择你的设备作为运行目标，然后点击运行按钮。Xcode会自动编译、签名并安装App到你的手机上。

连接逻辑与Web客户端类似：App启动后，在设置页面填入服务器地址、用户名、密码和API Key，点击连接。App内部的Citadel库会建立SSH隧道，连接至服务器Agent。

3.3 Apple Watch 扩展的实现要点

将控制延伸到Apple Watch是提升便捷性的点睛之笔。实现的核心是WatchConnectivity框架。

架构：Watch App本身不直接处理SSH或网络请求。它只是一个极其简化的UI，用于输入简短语音或文字，以及显示结果。
通信：当用户在Watch上发送一条指令时，Watch App通过WCSession的sendMessage(_:replyHandler:errorHandler:)方法，将消息发送给配对的iPhone上正在运行的iOS主App。
中继：iOS主App收到来自Watch的指令后，将其放入与服务器Agent的通信队列中，就像处理自己UI发出的指令一样。当从服务器收到回复后，再通过WCSession将回复传回Watch App进行显示。
设计限制：由于Watch的性能和屏幕尺寸限制，交互必须极度精简。通常只设计几个预设的快速操作按钮（如“查看队列状态”、“停止最新作业”）和一个用于自定义简单命令的输入框。复杂的多轮对话和长文本浏览仍应在iPhone或Web端完成。

4. 核心功能模块深度解析

4.1 Agent API 的设计与实现

Agent API 是服务器端Python Agent的核心，它负责接收指令、协调LLM、执行命令并返回结果。一个健壮的API设计应该考虑以下几点：

1. 通信协议选择：

HTTP RESTful API：实现简单，易于调试。可以使用Flask或FastAPI快速搭建。适合请求-响应模式。
WebSocket：更适合需要双向、持续通信的场景，比如需要服务器主动推送任务进度（如日志尾部实时输出）。PhDbot 的聊天场景更贴近WebSocket。
混合模式：一个WebSocket连接用于传输聊天消息和实时流式输出，同时提供几个HTTP端点用于健康检查、文件上传等。

2. 消息格式定义：客户端和Agent之间需要约定一个统一的消息格式。通常采用JSON。

{ "type": "command", // 消息类型：command, chat, file_operation "id": "req_123456", // 唯一请求ID，用于匹配响应 "content": "请列出当前用户下所有正在运行的Slurm作业。", // 用户原始指令 "context": { // 可选，会话上下文 "current_working_directory": "/home/research/projects/llm_finetune", "previous_commands": ["cd ~/projects", "ls"] } }

Agent的响应格式也类似：

{ "type": "response", "id": "req_123456", "success": true, "content": "以下是您的作业列表：\nJOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)\n123456 gpu train_job research R 2:30 1 gpu-node-01", "error": null, "metadata": { "executed_commands": ["squeue -u research"], "working_directory": "/home/research" } }

3. 核心处理流程：当Agent API收到一条消息后，其内部处理流水线如下：

接收消息 -> 解析验证 -> 构建LLM Prompt -> 调用LLM API -> 解析LLM响应 -> 安全验证命令 -> 执行命令 -> 收集结果 -> 格式化回复 -> 发送响应

其中，安全验证命令环节至关重要。必须建立一个“允许命令”列表或正则表达式规则，来过滤危险操作。例如，可以禁止任何以sudo开头、包含rm -rf /模式、或尝试访问/etc、/root等敏感路径的命令。

4.2 与LLM（Gemini）的集成策略

LLM是Agent的“翻译官”和“规划师”。如何有效地与Gemini API交互，决定了Agent的智能程度。

1. Prompt工程：Prompt是引导LLM正确工作的指令。一个针对集群管理的Prompt模板可能长这样：

你是一个专业的Linux系统和高性能计算集群助手。用户会给你一些用自然语言描述的任务，你需要将其转化为安全、准确、高效的bash命令序列。 当前上下文： - 用户名：{username} - 当前工作目录：{cwd} - 集群类型：Slurm - 可用命令白名单：['ls', 'cd', 'cat', 'grep', 'tail', 'squeue', 'sinfo', 'sacct', 'sbatch', 'scancel', 'git', 'python', 'nvidia-smi'] （禁止使用sudo、rm等危险命令） 用户请求：{user_query} 请按以下格式输出： THOUGHT: [你的思考过程，分析用户意图，规划命令步骤] COMMAND: [要执行的一条或多条bash命令，用分号隔开。确保命令在cwd下执行是安全的。]

通过提供上下文和白名单，可以极大地提高命令生成的安全性和准确性。

2. 处理长上下文与流式输出：复杂的任务可能需要LLM生成多步计划。Agent可以设计成支持多轮对话，将上一步的执行结果作为上下文，再请求LLM生成下一步命令。对于执行时间较长的命令（如tail -f log.txt），Agent可以支持流式（streaming）响应，将标准输出和标准错误实时地、分块地传回客户端，实现类似终端的“打字机”效果。这需要WebSocket协议的支持。

3. 错误处理与重试：LLM API调用可能失败（网络超时、额度不足）。Agent需要实现重试机制和优雅降级。例如，当Gemini API不可用时，可以回退到一个简单的关键字匹配规则，处理像ls、pwd这样的基础命令。

4.3 文件操作与安全沙箱

除了执行命令，管理研究代码和配置文件也是高频需求。PhDbot 需要支持基本的文件操作。

1. 安全文件访问：Agent必须将文件操作限制在用户的家目录（/home/{username}）或指定的项目目录内。任何试图访问../进行目录穿越的路径都必须被拒绝。可以使用Python的os.path.abspath和os.path.commonprefix来检查解析后的绝对路径是否在以允许的根目录开头。

2. 实现文件列表、读取、编辑：

列表：对应ls -la命令，解析后以结构化的JSON返回，便于前端展示。
读取：对应cat或head/tail。对于大文件，应支持分页或指定行范围读取。
编辑：这是一个复杂功能。简单的实现是：前端将整个文件内容发送过来，Agent备份原文件后覆写。更优雅的做法是实现一个简单的差异（diff）补丁，但复杂度较高。务必在编辑前备份文件！

3. 虚拟环境/沙箱：为了防止恶意或错误的命令影响服务器稳定性，可以考虑在Docker容器或systemd-nspawn等轻量级容器内运行Agent。将Agent及其执行的所有命令限制在一个容器环境中，即使执行了rm -rf /，破坏的也只是容器内部。这对于多用户共享的集群环境尤为重要。

5. 高级功能与定制化扩展

5.1 集成Slurm集群管理

对于高性能计算（HPC）环境，Slurm是最常见的作业调度系统。PhDbot 可以深度集成Slurm，提供更语义化的操作。

实现思路：

封装Slurm命令：在Agent内部创建一组Slurm工具函数，而不是每次都让LLM生成原始的squeue、sbatch命令。
解析Slurm输出：将squeue、sacct等命令的表格化输出解析成结构化的JSON数据，方便前端以更友好的方式（如表格、图表）展示作业状态、资源使用率。
模板化作业提交：用户可以预定义几个常用的作业提交模板（如“GPU单卡训练”、“CPU多节点推理”）。当用户说“用模板A提交作业”时，Agent读取对应的Slurm脚本模板，替换其中的变量（如实验名、代码路径），然后提交。
状态监控与通知：Agent可以定期轮询用户的作业状态。当作业完成、失败或达到某个检查点时，主动通过集成的通知渠道（如Server酱、Telegram Bot、甚至回传到客户端显示通知）告知用户。

示例：一个高级的Slurm交互Prompt

用户问：“我的GPU作业跑得怎么样了？” Agent内部执行：`squeue -u $USER -o "%i %P %j %u %T %M %l %D %R"`，然后解析输出。 LLM Prompt补充：“当前用户有3个作业。JOBID 123456 在gpu分区，状态为RUNNING，已运行2小时，使用1个节点gpu-01。JOBID 123457 状态为PENDING，原因是Resources。请用口语化总结。” 最终回复：“你有两个作业。一个（ID 123456）正在gpu-01节点上正常运行，已跑了2小时。另一个（ID 123457）在排队等待，因为资源暂时不足。”

5.2 支持多模型与自定义工具

PhDbot 的架构不应绑定于单一的Gemini模型。设计一个可插拔的LLM提供商接口是很有价值的。

多模型支持：

定义一个抽象的LLMProvider类，包含generate(prompt: str) -> str等方法。
为Gemini、OpenAI GPT、Claude、本地部署的Llama等分别实现具体的Provider类。
在settings.yml中通过provider字段动态选择。

自定义工具（Function Calling）：更高级的Agent可以利用LLM的“函数调用”功能。除了生成命令，你还可以让Agent直接调用你编写好的Python函数。例如，你可以定义一个plot_training_curve(experiment_path: str)的工具函数。当用户说“画出实验exp1的损失曲线”时，LLM会识别出意图，并请求Agent调用这个工具函数。函数内部会读取日志文件，用matplotlib生成图片，保存后返回图片路径或直接编码成base64传给前端显示。这比让LLM生成复杂的python plot_script.py命令更可靠、更强大。

5.3 性能优化与稳定性保障

当PhDbot从个人玩具发展为团队工具时，性能和稳定性成为关键。

连接池与长连接：为每个客户端新建SSH隧道和WebSocket连接开销很大。可以实现一个连接管理器，复用已认证的SSH会话，并保持WebSocket长连接，通过心跳包保活。
异步处理：使用Python的asyncio库构建Agent，可以同时处理多个客户端的请求，并在执行长时间命令（如模型训练）时不会阻塞其他请求。
日志与监控：Agent需要记录详细的日志，包括谁在什么时候执行了什么命令、结果如何。这对于审计和故障排查至关重要。可以集成像structlog这样的结构化日志库，方便后续接入ELK等日志系统。
错误恢复：Agent进程可能因为异常而崩溃。使用systemd或supervisor来托管Agent进程，配置为自动重启，并设置重启次数限制。

6. 安全考量与最佳实践

将服务器权限通过一个AI Agent暴露出来，安全是重中之重。以下是一些必须遵守的原则：

最小权限原则：运行Agent的系统用户权限应该尽可能低。绝对不要用root运行。最好创建一个专用用户（如phdbot），并严格限制其权限和可访问的文件目录。
命令白名单与过滤：这是第一道防线。建立一个允许执行的命令列表。对于不在白名单内的命令，尤其是文件删除 (rm)、权限修改 (chmod)、提权 (sudo) 等，必须直接拒绝。可以使用正则表达式进行模式匹配过滤危险参数。
输入验证与转义：所有从客户端接收的输入，在拼接成命令或文件路径前，都必须进行严格的验证和转义，防止命令注入攻击。
API密钥管理：Gemini API Key是付费凭证，必须妥善保管。不要硬编码在代码或配置文件中。使用环境变量、密钥管理服务（如HashiCorp Vault）或服务器提供的秘密存储功能。
网络隔离：确保Agent只监听127.0.0.1。依赖SSH隧道进行访问，本身就利用了SSH的安全特性（加密、认证）。不要将Agent的端口（如8888）暴露在公网或集群内网。
审计日志：记录所有操作，包括原始用户指令、生成的命令、执行结果、执行用户、时间戳和来源IP（客户端IP）。这些日志是事后追溯和攻击分析的唯一依据。
定期更新与漏洞扫描：保持项目依赖库（Python/Node.js packages）的更新，定期进行安全审计。

7. 故障排查与常见问题

在实际部署和使用中，你可能会遇到以下问题：

问题1：客户端无法连接，提示“SSH连接失败”或“隧道建立失败”。

检查SSH基础连接：首先在终端手动执行ssh username@host，确认密码或密钥认证是否正常。网络是否可达？防火墙是否屏蔽了22端口？
检查服务器Agent状态：登录服务器，用ps aux | grep agent.py和netstat -tlnp | grep 8888确认Agent进程是否在运行，以及是否在正确端口监听。
检查SSH隧道命令：客户端建立的隧道命令类似于ssh -L 3001:127.0.0.1:8888 username@host -N。确认本地端口（3001）未被占用，转发目标地址端口（127.0.0.1:8888）正确。

问题2：连接成功，但发送指令后无反应或超时。

检查Agent日志：查看服务器上Agent打印的日志，看是否收到了请求，处理过程中是否有Python异常。
检查LLM API：确认Gemini API Key有效且未过期。尝试在服务器上直接用Python脚本调用Gemini API，看是否正常。
检查命令执行权限：Agent运行用户是否有权限执行你要求的命令（如squeue）？可以尝试在Agent代码中先执行一个简单的pwd命令测试。

问题3：LLM生成的命令不正确或危险。

优化Prompt：你的Prompt可能不够清晰。在Prompt中更详细地描述环境约束、安全规则和命令格式。
增加后置验证：在LLM生成命令后、执行前，加入一个强规则验证层。例如，检查命令是否以白名单中的单词开头，是否包含黑名单中的危险模式。
使用更低风险的模型或模式：Gemini API可能有“安全设置”，可以适当调整。或者，对于高风险操作，可以配置为LLM只提供建议，需要用户在前端手动确认后才能执行。

问题4：文件操作（尤其是编辑）导致文件损坏。

强制备份：在任何写文件操作前，自动在相同目录下创建带时间戳的备份文件（如config.yaml.backup_20250415_102030）。
实现原子写入：先将新内容写入一个临时文件，写入成功后再用os.rename原子性地替换原文件。这可以防止写入过程中程序崩溃导致文件内容不全。
提供版本对比：在文件编辑功能中，集成一个简单的diff视图，让用户能清晰地看到修改了哪些地方，确认后再保存。

问题5：在Slurm集群上，提交的作业参数不对。

提供交互式作业提交：不要完全依赖LLM从零生成一个Slurm脚本。可以设计一个表单化的前端界面，让用户填写关键参数（分区、GPU数量、时间限制、邮箱通知），由Agent根据模板生成脚本。LLM可以辅助填充这些表单的默认值。
预定义脚本库：在服务器上维护一个常用的、经过测试的Slurm脚本模板库。用户可以说“用模板A，把代码路径改成/my/new/code”，Agent只需做简单的字符串替换，可靠性远高于LLM自由发挥。

这个项目本质上是一个桥梁，将前沿的LLM能力与传统的、强大的计算基础设施连接起来。它的价值不在于替代熟练的研究者手动操作，而在于消除那些琐碎的、需要记忆的中间步骤，让你能更专注于研究本身的核心逻辑。从我的使用经验来看，最大的收益不是节省了多少时间，而是它改变了工作状态切换的成本。当你离开实验室，思维的连续性不会被复杂的登录和命令行操作打断，一个简单的提问就能让你重新接入研究现场，这种流畅感对于保持创造力和生产力至关重要。