01
不是功能基础不变量
版本、身份、幂等、审计等必须贯穿每个模块，不能单独包装成交付物。
REQUIREMENT MODULES
6 个模块，先把需求说清楚
这里只说明科研用户遇到什么问题、系统需要提供什么，以及怎样才算满足需求。技术方案、接口和工程拆分由工程团队决定。
F1–F6 · 问题 → 需求 → 完成标准先校正层级
自然约束不再占一个“功能”名额
“隔离后才能安全执行”“审批要绑定版本”“动作要有回执”都应自然成立。 我们把它们作为跨模块不变量；只有能形成明确服务边界和交付物的部分，才称为工程模块。
02
工程师直接负责六个工程模块
每个模块只定义需要解决的问题、第一阶段范围和完成标准。
03
按科研场景安装领域适配包
PDF、HPC、样本、仪器和临床等专业语义通过 package 贡献，不写进平台核心。
跨模块不变量
正式产物、审批和外部写入都绑定具体版本，修改后不能冒充原版本。
系统知道是谁在操作，并且只给他完成当前任务所需的权限。
同一操作重复请求也只能生效一次，执行后留下可以核对的结果。
失败、撤回、修改和人工决定都保留历史，不能被后来的结果覆盖。
不同科研场景会补充
- 论文、公式、图表和科学数据的专业结构
- 样本、试剂、设备、时间、位置和单位规则
- HPC、实验记录系统、仪器和传感器连接
- 不同学科的检查规则和评测标准
概念解释
“幂等”是什么意思？
同一个操作无论请求一次还是重复请求多次，最终只产生一次效果。 它解决的是：系统没收到成功回执时，如何安全重试而不重复做事。
Agent 提交一个 HPC 训练任务，并携带唯一幂等键。
key = experiment-42-submit-v3训练任务已经进入队列，只是网络断开，Agent 不知道是否成功。
服务端返回第一次的任务 ID，不会再创建第二个训练任务。
result = existing job-781没有幂等重试 3 次 → 可能启动 3 个训练任务
支持幂等重试 3 次 → 仍然只有 1 个训练任务
幂等不等于“出错就直接再点一次”。如果外部系统不支持幂等键，或者无法确认第一次是否生效，必须先查询和核对外部状态； 状态仍不确定时，应交给人处理，不能盲目重复执行。
六个需求模块
说清楚为什么需要、需要什么
每个模块采用同一种表达方式，避免把技术名词、实现方案和用户需求混在一起。
证据与产物版本服务
保留重要历史版本，让研究人员能查看变化、恢复旧版本，并确认结论、运行和审批使用的是哪一版内容。
为什么需要
科研数据、代码和报告会被多次修改。旧内容容易被覆盖，结论引用的版本也容易说不清；如果每次小改都完整复制文件，还会产生大量重复存储。
第一阶段覆盖
- 代码、配置和 Notebook
- CSV、TSV、JSON、Parquet 等数据
- PDF、图片和研究报告
- 分析生成的图表与结果文件
系统需要做到
- 在提交审阅、批准、运行分析或发布结果时保存重要版本
- 可以查看创建时间、创建者和修改原因，并恢复任意历史版本
- 对文本、代码和表格展示主要变化；其他文件明确提示内容已变化
- 文件只发生少量修改时，不应重复保存大量相同内容
- 说明某次分析、图表、结论和审批分别使用了哪个版本
- 已批准内容再次修改后，新版本需要重新审查
怎样算满足需求
- 历史版本可以准确恢复，新版本不会覆盖旧版本
- 相同内容不会被重复存储，小幅修改不会按完整文件大小增加空间
- 正式结论、运行和审批都能找到对应版本
- 用户能够看懂版本之间的主要变化
Computer Use 线程隔离
多个线程可以同时操作不同界面，每个线程的鼠标、键盘和画面互不干扰。
为什么需要
多个 Agent 线程同时使用电脑时，一个线程的点击、输入或焦点切换可能进入另一个线程，造成误操作、数据泄漏或错误提交。
第一阶段覆盖
- 鼠标与键盘输入
- 窗口焦点与画面
- 剪贴板、下载文件和登录状态
- 用户观察与接管
系统需要做到
- 每个线程只能看到和操作自己的界面
- 一个线程的鼠标和键盘事件不能进入其他线程
- 一个线程切换窗口、卡住或退出时，不影响其他线程
- 剪贴板、下载文件和登录状态不能在线程间混用
- 用户可以明确选择要观察或接管的线程
怎样算满足需求
- 至少四个线程并行操作时，鼠标、键盘、画面和登录状态零串扰
- 停止任意一个线程，其他线程继续正常运行
- 系统做不到真实隔离时，必须限制并发，不能假装已经隔离
长任务持续运行
训练、分析和监测任务可以跨数小时或数天持续运行，不依赖用户一直打开客户端。
为什么需要
科研任务经常运行很久。电脑休眠、网络中断、客户端退出或服务重启后，任务状态容易丢失，也可能被重复提交。
第一阶段覆盖
- 本地长时间分析任务
- HPC 与远程计算任务
- 任务进度、日志和中间结果
- 暂停、恢复、取消和失败处理
系统需要做到
- 客户端关闭或网络断开后，任务仍能继续运行
- 用户重新打开客户端后，可以看到真实进度和历史记录
- 任务可以暂停、恢复和取消
- 失败后尽量从已有进度继续，不重复执行已经完成的外部操作
- 需要人工决定时及时通知，并说明当前状态和可选操作
怎样算满足需求
- 任务连续运行数天，客户端离线和服务重启后状态不丢失
- 恢复任务不会重复提交已经存在的作业
- 无法确认是否成功时明确显示“状态未知”，不误报完成
多人科研工作区
多人可以围绕同一份科研对象共同编辑、审阅、决定和交班，并清楚知道谁做了什么。
为什么需要
科研协作涉及作者、数据人员、方法专家和负责人。仅共享一个文件，无法说明修改来源、审阅意见、最终决定和当前责任人。
第一阶段覆盖
- 共同编辑和评论
- 独立审阅与争议仲裁
- 审批、签名和责任记录
- 任务交班与负责人切换
系统需要做到
- 多人可以同时查看、评论和修改同一科研对象
- 每次修改、审阅和决定都记录真实参与者
- 重要冲突必须明确展示并由有责任的人处理
- 需要独立判断的审阅在提交前互不可见
- 交班后明确新的负责人，避免无人负责或多人重复操作
怎样算满足需求
- 多人并发和断网重连不丢失修改
- 独立审阅在规定时间前不会互相泄漏
- 任一任务都能找到当前负责人、历史决定和对应版本
多客户端同步与通知
研究人员可以在手机、电脑和网页之间接力工作，看到同一个任务、版本和决定。
为什么需要
科研工作发生在办公室、实验室和野外。用户换设备或暂时断网后，容易丢失进度、重复操作或错过需要及时处理的事件。
第一阶段覆盖
- 手机、电脑和网页
- 跨端任务与版本状态
- 扫码、拍照、定位和现场记录
- 离线工作与重要通知
系统需要做到
- 不同设备看到同一个任务、对象版本和处理状态
- 从通知进入后可以直接到达需要处理的内容
- 手机支持现场扫码、拍照、定位、记录和确认
- 断网时可以继续记录，恢复网络后安全同步
- 遇到关键冲突时要求用户确认，不静默覆盖
怎样算满足需求
- 手机、电脑和网页最终显示一致状态
- 长时间离线后同步不丢失、不重复记录
- 用户换设备后能快速回到正确任务和版本
连接器与外部写入网关
Agent 可以连接真实科研系统，在执行外部写入前让用户看清变化，并在执行后留下可核对的结果。
为什么需要
科研任务需要连接 HPC、数据库、实验记录系统和仪器。错误写入、重复提交或使用错误账号可能带来真实损失。
第一阶段覆盖
- HPC 与远程计算系统
- 数据库和对象存储
- ELN、LIMS、EDC 等科研系统
- 仪器和传感器
系统需要做到
- 明确区分读取、生成建议、正式写入和高风险操作
- 正式写入前展示目标、内容和可能影响
- 高风险操作必须由有权限的人确认
- 同一次写入即使重复请求，也只能实际生效一次
- 执行后保存外部系统返回结果，并确认是否真正成功
- 无法确认结果时明确显示状态未知，交给用户核对
怎样算满足需求
- 未经确认的高风险操作不能执行
- 网络中断和重复请求不会造成重复写入
- 每次外部写入都能找到确认人、执行时间和外部结果
这页的边界
需求由科研用户确认，实现方式由工程团队决定。
后续可以把每个模块放进真实科研闭环验证，但不在需求定义中提前规定技术栈和内部实现。
查看真实科研闭环