系统架构

这一页回答三个问题：平台由哪几个部分组成、一次对话或一次工作流运行在你的界面上会经历哪些阶段、多人使用与扩容时你会感受到什么。服务清单、部署拓扑与内部地址属于运维范畴，见部署架构；这里只讲你能感知到的行为。

三个部分，各管一件事

数据层由几类存储分工完成：业务记录、检索索引与文件资产各放在合适的位置。具体用到哪些组件、如何备份与恢复，见部署架构与存储。

把界面与执行分开，是为了让「页面」只是观察窗口：页面关掉不影响任务，任务结果也不会只存在某台机器或某个浏览器里。

一次对话会经过哪些阶段

发送消息 → 排队 → 执行（思考 / 检索 / 工具 / 生成）→ 流式返回 → 完成

1. 发送：消息立刻出现在会话里，运行随即在平台侧开始，不依赖页面保持打开。
2. 排队：同一时刻运行较多时，界面先显示「排队中」。正常情况下很快开始；如果长时间毫无进展，通常是执行容量不足或执行服务不可用，应联系运维，不要反复点击发送。
3. 执行：模型逐轮思考，按需检索知识库、调用工具、生成图片或视频。思考过程、工具调用卡片与引用会逐步出现在会话里。
4. 流式返回：回复边生成边显示。关闭页面、刷新或切换会话都不会中断本轮执行；回来后继续接收剩余内容，已显示的部分不会重复渲染。
5. 需要你回答：模型向你提问时，运行停在「等待回答」，不会继续往下猜。填写并提交后，同一轮从暂停处继续，而不是重新开始。
6. 结束：点停止才真正结束本轮；手动停止、失败或被中断的运行不会自动重跑——重跑会重复执行有副作用的工具调用，所以需要由你重新发送。

一次工作流运行会经过哪些阶段

1. 提交：通过运行表单，或由外部调用、定时任务、Webhook 触发。只有已发布的工作流能被正式运行，草稿只能调试。
2. 排队：与对话一样先进入待执行状态，容量不足时表现为排队时间变长。
3. 按图执行：互不依赖的分支可以同时进行，依赖未满足的节点等待上游完成。每个节点记录自己的输入、输出、状态与耗时。
4. 停下来等人：遇到审批节点时整次运行停在「等待审批」，提交反馈后从暂停处继续，已完成的节点不会重跑。
5. 结束：最终输出、每个节点的轨迹、耗时、Token 与错误都可以在运行详情里回看。

多副本与扩容对你意味着什么

• 状态不在页面上：平台可以在多台机器上同时运行多份相同服务。无论哪一份处理你的请求，会话与运行记录都来自同一份数据，所以刷新、换设备、排队后被另一份服务接手，看到的内容完全一致。
• 扩容买到的是并发，不是单次速度：增加容量意味着更多人能同时跑任务；单个运行受模型与工具本身的速度限制，不会因为扩容而变快。容量不足时最先出现的现象是排队变长。
• 不同任务分开排队：对话运行、文档处理、工作流运行各有自己的执行通道，部署可以单独扩某一类。是否互不影响取决于容量是否按使用结构分配充足。
• 结果可复现：工作流的路径由编排决定，同一份输入、同一个已发布版本，执行顺序与输出保持一致，不受运行在哪台机器上影响。

容量规划、副本数与高可用方案见高可用与扩展。

权限与数据边界

• 资源归属团队：团队成员按角色访问，团队之外的访问默认不可见。
• 私有资源只有创建者能访问；跨团队共享默认只读（例如知识库共享）。
• 超级管理员可以越过团队边界，但仍会留下操作记录。
• 删除、发布、恢复版本、审批这类操作会写入审计记录，包含操作者与改动前后的内容。

详见团队与安全与权限参考。

参见：

• 部署架构 — 服务拓扑、数据存放与网络入口
• Agent、工作流、知识库 — 三类核心资源
• 团队与安全 — 多租户、角色与审计