# 系统架构总览 (/docs/architecture)

## 架构想解决什么 [#架构想解决什么]

同一个技术项目涉及实验、仿真、工程设计和交付。它们需要共享依据，又需要各自拥有清楚的职责，便于后续单独部署或组合销售。

以下是建议的逻辑分层。点击模块可以查看具体职责和内部结构。

<ArchitectureMap />

## 三条基本约定 [#三条基本约定]

### 数据由明确的模块负责 [#数据由明确的模块负责]

实验系统维护实验事实，仿真系统维护计算运行，工艺系统维护工程对象。其他模块通过接口读取、引用指定版本，或保存带来源的快照。

### 人和 Agent 使用同一套业务动作 [#人和-agent-使用同一套业务动作]

界面提交模型变更与 Agent 提交模型变更，都进入工艺子系统的校验与版本检查。各入口不会形成两套不同的工程规则。

### 跨模块通过引用和事件协作 [#跨模块通过引用和事件协作]

引用说明“这个结果用了哪一版输入”；事件说明“哪件事发生了变化”。例如实验数据完成修订后，依赖它的分析被标记为待检查。

事件重复送达不应重复生成业务结果。关键操作完成时，由拥有数据的模块确认状态，再通知其他模块更新各自视图。

## 一个模型更新如何流动 [#一个模型更新如何流动]

1. 实验模块登记有效数据及修订版本。
2. 研究模块提出参数更新任务。
3. 计算模块引用数据版本，执行拟合与仿真。
4. 人员比较误差和适用范围，确认是否采用候选模型。
5. 工艺模块在指定方案中引用新模型结果。
6. 安全环保与交付模块检查相关成果是否需要更新。

流程由业务状态驱动。Agent 可以组织这些动作，但每份业务记录都能在 Agent 会话结束后继续被使用。

## 哪些边界现在值得定 [#哪些边界现在值得定]

- 对象身份、数据归属、单位与来源。
- 历史版本、并发修改、发布快照。
- 项目与组织的访问范围。
- 工具接口、长任务状态、失败恢复。
- 模块独立运行时的导入导出与适配方式。

数据库产品、队列实现、模型供应商和具体后端语言可以在验证约束后选择。这里的架构不依赖某个供应商专有格式。

进一步阅读：[数据与版本](/docs/architecture/data-and-versions)、[Agent 项目工作区](/docs/architecture/agent-workspace)、[部署与拆分](/docs/architecture/deployment)。