平台 · 任务
仪表板显示「3 个问题需要处理」。运营人员阅读后，打开 Asana 创建三个任务，手动复制订单编号，丢失了与批次的关联。关闭 Asana 任务后，还需返回 TradeOS 更新实体。要求供应商执行某项操作——供应商回复「好的」——两天后没有人知道结果如何。每一个告警、每一个异常、每一次交接，都在重复这一过程：平台产生的工作离开平台后便无疾而终。
TradeOS 的任务模块是整个平台的神经系统。每一个事件——订单状态变更、生产 QC 完成、货运延误、发票即将逾期、带有待办事项的消息标记——都会传导至任务引擎。工作随即被路由至正确门户中的正确人员：主应用中的运营人员、客户门户中的客户、供应商门户中的供应商，或 Atlas 本身。统一的任务模型。6 个状态。9 个类别。6 种实体类型。3 个门户。一套神经系统。
状态数
6 · 包含「待审批」和「等待外部」
类别数
9 · 订单、货运、生产、财务及另外 5 项
实体类型数
6 多态类型 · 与订单采用同一模型
视图数
6 · 概述、看板、列表、我的今日、甘特图、日历
操作员任务页面（Board 视图）的真实界面— 4 个状态列、拖放转换、真实分类及实体链接。同一组件在客户和供应商门户中以不同 API 前缀渲染。
当运营工作游离于运营平台之外
运营工作失败只有一个原因：工作与了解批次、订单、合同及交易对手的系统脱节。以下三种失败模式，任何运营团队都亲身经历过。
01 · 重复录入
操作员在 TradeOS 中发现一个异常，在 Asana 中创建任务，随即丢失了与批次的关联。在 Asana 中关闭任务后，还得返回 TradeOS 更新实体。每次异常都需重复录入，久而久之，哪个系统才是唯一数据源变得愈发模糊。
02 · 孤立事件
仪表板显示「3 个问题需要处理」。操作员读完，靠记忆或笔记本管理。三周后，其中一项被遗漏——没有人负责，因为没有人将其转化为任务。
03 · 跨方交接失联
操作员要求供应商处理某事。供应商看到后说「好的」，然后忘记了。操作员两天后跟进——到底怎么了？对话里有问题，操作员心存顾虑，却没有任何地方记录着承诺。
神经系统
任务引擎是 TradeOS 的跨门户编排协议。平台各模块的 8 类事件汇聚其中，任务则分发至 4 个目的地——3 个门户以及 Atlas 本身。无需独立的工作流引擎；这本身就是工作流引擎。
01
同一 TasksPage 组件在运营商、客户和供应商门户中均可渲染——仅 API 前缀不同（/api/tasks · /api/portal/client/tasks · /api/portal/supplier/tasks）。相同的 6 种状态、相同的 4 个优先级、相同的活动流。运营商侧创建的任务，与供应商在其门户中看到的是同一条记录。
02
当实体发生状态变更时（订单进入 in_production、检验结果发布、发票超过到期日），平台判断该事件是否需要人工介入。若需要，系统将创建一条任务，自动继承实体链接、预设分类，并根据责任方历史记录推荐指派人。
03
审批即任务（状态 pending_approval）。跨团队交接即任务（重新指派负责人）。等待对方响应即是一种状态（waiting_external）。我们没有在任务之上另建工作流引擎——任务本身就是工作流引擎。
六种视图 · 一张任务图
同一份数据，六种布局。一键切换标签页。操作员根据工作需要选择视图—— Board 用于状态流转，My Day 用于个人聚焦，Gantt 用于交付时间线，Calendar 用于截止日期密度分析。
01 · 概述
控制中心：按状态显示任务（饼图）、按类别显示任务（柱状图）、逾期任务操作中心、本周待处理任务、近期已完成任务、每周吞吐量图表、团队工作负载分布。
02 · 看板
待办 → 进行中 → 待审批 → 已完成。将卡片跨列拖拽即可更新状态；状态转换通过与其他入口相同的服务处理。
03 · 列表
适合处理积压任务的密集视图。按截止日期或优先级排序，按类别筛选，批量更新状态或负责人，无需打开任务面板即可内联编辑清单进度。
04 · 我的今日
操作员的晨间视图。三个分区——已逾期（红色）、今日到期（橙色）、无截止日期（灰色）。每项任务标注优先级。目标：当日结束前清零。
05 · 甘特图
当操作员需要查看任务与交货日期的先后关系时使用。条形图从任务开始延伸至到期日，状态以颜色标识。悬停可查看实体上下文，点击可打开任务面板。
06 · 日历
展示工作在整月的分布情况。圆点按优先级着色。便于发现任务聚集问题——例如过多「周五」任务，或某个相对空闲的周可以承接额外任务。
实体锚定
六种多态实体类型——订单、货运、生产批次、客户、制造商、发票。每项任务均携带类型化引用。打开实体，内联查看其任务面板。打开任务，一键跳回实体——同时在旁显示关联的消息线程。
审批
凡需要签字确认之事——合同红线修订、样品发货、预算超支、文档版本——工作即转入 pending_approval 状态（六个状态之一），与其他所有事项一同出现在审批人的任务列表中，并通过正常的状态流转完成处理。批准、拒绝与「需要修改」均为状态变更。审计记录存于任务的活动流中。无需检查第二个收件箱。
01
操作员或交易对手在 in_progress 中完成工作后，点击「提交审批」——任务转为 pending_approval。
02
审批人在其按「审批」筛选的列表中查看该任务，打开后审阅可交付成果、活动流及实体上下文。
03
状态流转至 completed（批准）、cancelled（拒绝）或返回 in_progress（修改）。每项决定均在活动流中记录时间戳与原因。
当前在任务引擎上运行的真实审批流程：
ATLAS · 操作界面
大多数 AI 工具发送聊天消息。聊天消息会不断滚动消失。TradeOS Atlas 在检测到需要人工判断的事项时创建任务，附上上下文并推荐负责人。这使 Atlas 的信号可量化：任务是否按时关闭？是否根本没有关闭？一项由 Atlas 创建却未被处理的任务，本身就是一个与任务同等分量的信号。
检测
来源涵盖订单数据、生产数据、财务数据、消息、文档到达情况及交易对手行为。例如：交易对手在活跃线程中突然沉默、某份文档将在 14 天后到期、某张发票的处理时间超出该类别的典型时限、某笔在途订单的利润率跌破阈值。
创建
任务以信号作为标题和描述，以相关实体作为锚点，并根据责任方历史记录推荐负责人，同时附上原始数据作为佐证上下文。类别、优先级和实体关联自动继承——无需操作员手动录入。
解决
操作员像处理其他任务一样处理该任务——更新状态、添加评论、附加文档、标记为完成。Atlas 观察关闭过程并持续学习：该信号是否促成了行动？耗时多久？处理方向是否合理？这一反馈形成闭环。
示例 · Atlas 在操作员列表中创建的任务：
附加上下文：
Atlas 生成指令性标题，附上所观察到的信息，并建议指派负责人。操作员执行；系统观察任务完成情况；闭环随即形成。
对比替代方案
| 功能 | TradeOS | Linear | Asana | ClickUp | Monday |
|---|---|---|---|---|---|
| 关联实体的任务（订单 / 货运 / 批次 / 发票 / 客户 / 供应商） | ✓ 多态 · 6 种类型 | — | — | — | — |
| 相同数据模型在客户与供应商门户中同步展示 | ✓ 3 个门户 · 统一模型 | — | 访客席位 | 访客席位 | 访客席位 |
| 审批运行于同一引擎（非独立功能） | ✓ pending_approval 状态 | — | 审批附加模块 | 工作流 | 审批应用 |
| 由平台事件自动创建（状态变更 · QC 完成 · 发票逾期） | ✓ 原生支持 | — | 集成 | 自动化 | 自动化 |
| 从聊天创建任务（在消息中选中文字后通过工具栏 → 任务） | ✓ | — | — | — | — |
| AI 智能体创建附有上下文的任务（而非聊天消息） | ✓ Atlas | AI 摘要 | AI 辅助 | AI 辅助 | AI 辅助 |
| 六种视图（概述 · 看板 · 列表 · 我的今日 · 甘特图 · 日历） | ✓ | 看板 · 列表 | ✓ | ✓ | ✓ |
| 17 种自定义字段类型（文本 / 数字 / 日期 / 下拉菜单 / 文件 / 人员 / ...） | ✓ | 标签 + 估算 | ✓ | ✓ | ✓ |
这并非对 Linear、Asana、ClickUp 或 Monday 的否定。 Linear 在产品工程的交付速度方面表现卓越。 Asana 在具备工作流与依赖关系的项目管理方面表现卓越。 ClickUp 和 Monday 是面向需要工作负载可视化的团队的优秀通用任务工具。这些工具均为通用工作场景而设计。TradeOS 任务专为贸易运营人员实际承担的工作而构建——锚定于生产批次、发票或货运，通过统一的数据模型在运营商、客户与供应商门户之间共享，并在平台自身检测到需要处理的事项时自动创建。
常见问题
运营负责人在将任务与 Asana 或 Linear 进行评估时，最先提出的五个问题。
Asana、Linear 和 ClickUp 都是出色的通用任务工具——局限性也恰在于此。它们都不知道什么是生产批次、货运舱单长什么样、AQL 2.5 下何种情况构成 QC 不合格，也不知道哪一方负责下一步。它们的任务存储在各自的数据库中；订单存储在您的系统中；沟通记录存储在第三个工具里。TradeOS 的任务与它们所关联的订单、货运、生产批次、发票、索赔和样品共享同一数据模型——因为它们存储在同一个数据库中。打开任务，相关实体一键即达；打开实体，其任务就在眼前。无需外部集成，无需重复录入，没有断链问题。