Disclaimer: 本文内容完全为个人技术心得，其中内容可能会随着系统本身迭代而变化。由于技术更新的特性，本文不代表时下最新技术栈，还请留意。

Sect. 1 架构选型：为什么是这套技术栈？

• 前端选型： 用 Electron 套壳加上 React 和 Vite。没别的原因，因为如今 Web 前端的 UI 组件库太成熟、太好看了。我们要给用户一种“这软件很聪明也很现代”的视觉体验。而且用 Electron 打包，能把极其复杂的配置环境全部藏在水面之下。

• 后端选型： 选 Python 的 FastAPI。既然核心是搞大模型 Agent 和深度学习，Python 是唯一的宿主。FastAPI 写接口非常利索，自带文档，而且天生支持异步，这对于咱们这种动辄要跑好几天的后台任务来说简直是救命稻草。（这里同时排除我个人不会写除了 python 和 js 之外的语言，虽然我清楚 rust/go 这种新的语言貌似编译非常快）

• 隐私至上： 为什么非得费劲巴拉做个本地客户端，而不是直接做个纯网页挂在公网上？因为医疗切片数据属于高度敏感隐私，很多医院和实验室根本不允许数据出内网。本地化部署是打破这个壁垒的唯一出路。（虽然前期的确需要通过公网公共数据集来引流打响知名度）

Sect. 2 前置挑战：如何优雅地塞进一张几十 GB 的病理切片

Sect. 3 核心灵魂：用 Agent 革了“调包侠”的命

1. 大白话提需求： 用户不需要懂什么叫卷积神经网络，只需要在前端输入自然语言，比如“帮我找一下这些切片里的肿瘤细胞，并评估一下恶性程度”。

2. Agent 接管一切： 此时后端的 Agent 开始对齐用户需求。它会自动拆解任务，分析用户上传的切片和标签，自己去写数据预处理的脚本。

3. 全自动炼丹： Agent 会根据任务类型，自动调用底层的 PyTorch 等框架，配置网络结构，自动搜寻合适的超参数，开始漫长的训练过程。

4. 出报告甚至写文章： 模型训完还不算完，Agent 还要负责跑测试集，生成各种花里胡哨的对比图表，最后甚至按照学术论文的格式，把摘要、方法、结果的文本都完完整整的编译成可用的 PDF 档。

Sect. 4 踩坑与玄学

• 异步编程的究极烧脑 在同步流程跑通之后，我立刻意识到，Agent 跑一个任务，轻则几分钟，重则几天。一开始后端接口直接用普通的同步写法，前端点个“开始训练”，浏览器页面直接卡死白屏，HTTP 请求没一会就超时断开了。更糟的是不只 Agent 炼丹这一处在拖时间，这系统里随便拎一个环节出来都是耗时大户：比如后端去几十 GB 的原始扫描文件里实时抠取图像矩阵、在送入模型前跑极其消耗 CPU 的数据预处理、甚至是最后把海量的图表和文本渲染编译成一份完整的 PDF 报告。 血泪教训是这种耗时任务绝对不能阻塞主线程。必须上个后台任务队列。前端发送任务后，后端秒回一个“任务已收到”，然后让前端通过 WebSocket 每隔几秒作 SSE 查询问一下进度，这样 UI 才能不卡顿，还能顺便画个进度条。

• 开发时的跨域拦截 前后端分离的经典保留曲目。前端开发服务器跑在一个端口，后端跑在另一个端口，浏览器默认把这种串门当成黑客攻击给拦了。解决办法倒不难，在 FastAPI 里配好中间件，给前端放行就行。

• 终极地狱：Python 环境打包 这是最让人头秃的一集。把前端界面打包成 exe 很容易，但怎么把庞大的 Python 环境、几十个乱七八糟的依赖包、甚至还要带着厚重的显卡驱动库，一起塞进这个安装包里？目前只能靠类似 PyInstaller 这样的工具硬啃，顺便在 Electron 启动的时候用脚本偷偷把后端服务唤醒，关软件的时候还得记得杀掉后台进程，不然电脑迟早卡死。

• 长期维护的性能优化 这个软件一旦跑起来，动辄产生海量的训练日志、中间权重文件和切片缓存。如果不做自动清理和 PostgreSQL 数据库的定期维护（比如清理膨胀的死元组和历史记录），用户的硬盘迟早被撑爆。另外，庞大的前端视图库和 Node.js 进程跑久了容易产生内存泄漏，如何设计优雅的垃圾回收和重启机制，是后期必须面对的硬骨头。

Sect. 5 展望未来 (画饼时间)

• 支持预训练： 目前系统更多还是在做下游任务。未来的大饼是支持无监督或自监督的预训练（当然是在用户有合适的资源训练的时候支持）。毕竟医疗数据标注太贵了，让系统自己去啃海量的无标签切片，训出一个强悍的病理 Foundation Model，这才是真的降维打击。

• 缓解 Agent 乱讲话的问题： Agent 虽然聪明，但大模型骨子里“一本正经胡说八道”的幻觉毛病依然存在。在医疗科研这种严谨领域，如何引入强大的 RAG（检索增强生成）和医学知识图谱，让 Agent 写的每一段分析、每一行代码都有迹可循，是接下来的核心难点。

• 类似 HuggingFace 的社区建设： 既然医院的隐私数据绝对不能出内网，那就直接搞一个病理界的专属社区，用户可以在本地利用自己的私有数据训练模型，然后只把“模型权重”或“Agent 提示词工作流”分享或交易到云端社区。做到“数据不动，模型出去”，保护隐私的同时，大家还能一起推进全人类的医疗 AI 进度。

Appendix. A 术语

我之前从来没有入门过 full-stack development, 请你能够从 B/S 架构的基本名词开始，逐步介绍一些概念吗？

一、 前端（Frontend）—— 餐厅的大堂 / 顾客看到的样子

• HTML (超文本标记语言): 网页的“骨架”。就像餐厅里的桌椅板凳、墙壁结构。它决定了网页上哪里是标题，哪里是图片。

• CSS (层叠样式表): 网页的“皮肤”。就像餐厅的装修、灯光、桌布颜色。它负责把网页打扮得漂亮（排版、颜色、动画）。

• JavaScript (JS): 网页的“肌肉”。就像餐厅里的各种互动，比如你按下桌上的服务铃，铃会响。JS 让网页“动”起来，比如点击按钮弹出窗口、轮播图滚动。

• 前端框架 (Framework): 比如 Vue.js 或 React。你可以把它们理解为“精装修套餐”或者“预制菜”，它们提供了一套现成的工具和规则，让你不用从零开始写代码，能更快地建好一个复杂的网页。

二、 后端（Backend）—— 餐厅的厨房 / 幕后的处理中心

• Server (服务器): 其实就是一台24小时开机、连着互联网的超级电脑。用来接收和处理大家发来的请求。

• 后端语言: 比如 Java、Python、Node.js、Go。这就是大厨们做菜的手艺和流程，用来写“如何计算购物车总价”、“如何验证密码是否正确”的逻辑代码。

• API (应用程序接口): 这是前后端沟通的“桥梁”。你可以把它完美地想象成餐厅的“服务员”。你在前端（大堂）点击了“查看订单”，前端就会叫服务员（API）去后端（厨房）拿数据，后端查好后，再由服务员（API）把数据端给前端显示出来。

三、 数据库（Database）—— 餐厅的仓库 / 数据的家

• Database (DB / 数据库): 专门用来永久保存数据的地方，比如用户的账号、密码、发布的文章、商品列表。

• 关系型数据库 (SQL): 比如 MySQL。就像是有着严格格式的 Excel 表格，数据一行一行、一列一列排列得非常规整，适合存订单、用户信息。

• 非关系型数据库 (NoSQL): 比如 Redis 或 MongoDB。类似于一个个储物箱，存放方式更自由、读取速度极快，通常用来存一些需要秒开的数据（比如网页的热门排行榜）。

四、 网络通信（Network）—— 沟通的规则

• HTTP / HTTPS: 浏览器和服务器之间互相传递信息的“语言规则”。加了 "S" (Secure) 代表信息经过了加密，更安全。

• Request (请求) & Response (响应): 你在浏览器输入网址按下回车，或者点击“登录”按钮，就是向服务器发出了一个 Request (请求)；服务器处理完，把网页画面或登录成功的信息传回给你，这就是一次 Response (响应)。

• JSON: 一种轻量级的数据打包格式。前端和后端在传递数据时，通常会把信息打包成这种格式，因为它体积小且双方都能轻松读懂。

什么是 Electron？（把餐厅开到顾客家里）

Appendix. B 系统总体架构