# 十个子系统，分别负责什么 (/docs/subsystems)

## 先看职责，再看部署 [#先看职责再看部署]

这里的十个子系统是逻辑模块，并不表示第一版要部署十个服务。平台底座和 Agent 运行时提供公共能力，其余八个模块负责具体业务。

| 子系统 | 它负责的核心记录 | 最重要的边界 |
| --- | --- | --- |
| [平台底座](/docs/subsystems/platform) | 身份、成员关系、文件、对象引用、事件 | 提供通用机制，工程规则归业务模块 |
| [项目与设计基础](/docs/subsystems/projects) | 需求、目标、设计基础、资源与里程碑 | 管项目约定，不复制实验或计算事实 |
| [Agent 与工具运行时](/docs/subsystems/agent) | 会话、任务、工具调用、提案、执行轨迹 | 组织工作，正式业务结果归所属模块 |
| [研究规划与迭代](/docs/subsystems/research) | 问题、假设、证据关联、研究决策 | 决定研究方向，不改写原始实验 |
| [实验与数据](/docs/subsystems/experiments) | 计划、Run、样品、原始数据、分析版本 | 记录真实实验与可复现分析 |
| [工艺模型与图纸](/docs/subsystems/process) | 工程对象、连接、工况引用、图纸视图 | 维护工程语义，计算委托求解器 |
| [计算与仿真](/docs/subsystems/simulation) | 模型、计算工况、运行、结果、误差 | 保存可复现计算，不替代研究判断 |
| [知识与资产](/docs/subsystems/assets) | 文献、标准、模板、模型包、Skills | 管复用与适用范围，项目事实留在原处 |
| [安全与环境分析](/docs/subsystems/safety-environment) | 分析范围、偏差、措施、污染源、结论 | 基于明确输入与方法组织专业分析 |
| [评审、变更与交付](/docs/subsystems/delivery) | 问题、变更协调、评审、发布包、确认 | 管协作和发布，不越过源模块修改数据 |

## 模块怎样互相配合 [#模块怎样互相配合]

项目给出目标，研究提出问题，实验提供事实，计算验证模型，工艺形成方案，专业分析补充判断，交付把确定的版本呈现给客户。

知识资产支撑每一环；Agent 通过工具推进过程；平台负责身份、访问、文件与引用。

## 拆出去后仍需要什么 [#拆出去后仍需要什么]

独立产品要带上最小公共底座，并声明可选依赖。例如实验产品可以导出数据供外部仿真；仿真产品可以通过文件导入输入，不要求同时安装实验产品。

各模块页面都包含内部结构、交互边界、异常处理和首期验证内容。它们是架构提案，后续按试点项目调整。