智叟云集系统 · 架构与职责分层
多终端任务调度：从业务请求到结果汇总
公开技术展示稿 · 基于 2026 年 11 月 3 日项目情况。代码为教学示例，不包含生产核心实现。扩展建议不代表已部署能力。
01 / 从业务请求到可追踪的工作单元
智叟云集系统面向多终端、多平台的任务协作场景。业务方提交的是问题和目标平台，服务侧需要把它们组织成独立、可跟踪、可汇总的工作单元。例如，3 个问题对应 8 个平台，可以形成 24 个子任务。每个子任务拥有自己的处理状态，同一批提交则保留统一入口，方便查看整体进度。
这种结构允许快平台先回传，慢平台继续处理。一个平台暂时不可用，不应影响其他平台已经形成的结果。提交负责表达用户意图，批次负责组织关联，任务负责执行，结果负责承载内容；这四种对象不能被一个"处理中"字段替代。
图 1 · 多终端调度系统的职责分层。职责示意，不表示实际部署节点数量。
02 / 任务模型：稳定身份与可变状态
稳定标识让跨页面、跨请求的追踪成为可能。提交编号关联一次业务请求，批次编号关联一组相关任务，任务编号标识独立工作单元。标识应保持稳定，不应编码设备密钥、账号信息或内部路由规则。页面可以展示短编号，但业务查询仍应使用完整标识。
|------|----------------|-----------|
| 对象 | 表达内容 | 设计边界 |
| 提交 | 问题集合、提交时间、业务来源 | 不绑定某次临时连接 |
| 批次 | 相关任务和完成情况 | 不存放完整附件内容 |
| 任务 | 平台、状态、时间与结果引用 | 不覆盖此前处理历史 |
| 执行记录 | 一次处理的阶段与耗时 | 不替代最终业务结果 |
独立教学示例 · 非生产实现
from dataclasses import dataclass
from enum import Enum
class State(str, Enum):
QUEUED = "queued"
RUNNING = "running"
SUCCEEDED = "succeeded"
FAILED = "failed"
@dataclass(frozen=True)
class TaskSummary:
task_id: str
batch_id: str
platform: str
state: State
created_at: str
# 只展示公开的数据组织方式。
# 分配策略、状态转换与权限校验由内部服务负责。03 / 在线不等于具备接单条件
终端长连接解决通信问题，接单资格解决业务问题。终端即使已连接，也可能处于忙碌状态，或者目标平台尚未准备好、授权到期、可用额度不足。管理页应分别展示连接状态、执行状态、平台可用性和授权状态，让运维人员知道应该检查网络、应用环境还是业务配置。
同一终端上的界面型工作通常需要串行处理，多终端之间则可以并行。这样可以避免两个任务争用前台窗口、输入区域以及结果回传上下文。增加终端数量能够提高整体吞吐，但不会直接改变目标平台自身的响应时间。
|------|-------------|----------|
| 状态维度 | 展示示例 | 管理价值 |
| 通信 | 已连接、断开、重连中 | 判断消息能否送达 |
| 执行 | 空闲、处理中、暂停 | 判断当前容量 |
| 平台 | 可用、待检查、暂不可用 | 判断目标环境 |
| 授权 | 有效、到期、受限 | 判断业务访问资格 |
图 2 · 可见的任务生命周期。职责示意，不表示实际部署节点数量。
04 / 调度界面应该回答的问题
一个有效的管理界面应回答：任务正在什么阶段、由哪台终端处理、为什么还在等待、最后一次有效进度是什么时候。只有旋转图标，会把正常等待、通信中断和平台无响应混为一谈。提示应指向可执行的下一步，例如检查某个平台的登录状态，而不只是展示缺乏说明的错误码。
批次统计也应保留部分成功的事实。24 个任务中完成 20 个，并不等于全部完成；剩余任务需要分别显示处理中、失败或取消。结果完整度与任务状态也可以不同：处理已经结束，但部分材料可能缺失。这种差异需要公开、清楚地展示。
05 / 当前实现与扩展路径
当前工程以 Python 服务组织任务接口与业务处理，通过持久化数据库保存任务和过程信息，并提供终端长连接与健康上报接口。逻辑职责清晰，并不意味着每一层已经是独立服务。现阶段应先确保业务状态与查询口径一致，再根据真实负载决定是否拆分部署。
当规模增长，可以按接入、调度、后台处理、附件服务逐步拆分。独立消息系统、PostgreSQL、对象存储和缓存服务都可以成为扩展选项，但它们不是当前已经全部部署的组件。是否引入，应由并发量、数据体积、数据库等待和运维能力共同决定，不能仅凭架构图推断系统容量。
06 / 如何评价一个调度系统
|--------|----------------|
| 验收场景 | 应观察的结果 |
| 批量提交 | 业务编号清楚，子任务数量正确 |
| 单个平台失败 | 其他平台结果仍可访问 |
| 终端断开 | 任务状态有明确解释 |
| 部分任务完成 | 批次统计与子任务记录一致 |
| 历史查询 | 处理过程与最终结果保持关联 |
公开技术展示的价值在于说明职责和工程取舍，而不是披露内部竞争控制、设备匹配权重和异常转派实现。清晰的数据模型、可解释的管理状态与可追踪的过程记录，构成了后续扩展的基础。