Manus 发布 Scheduled Tasks 2.0:定时任务进入上下文感知时代
据 Manus 官方博客介绍,Scheduled Tasks 2.0 已完成全量推送。该版本将定时任务从"按时触发"升级为"按上下文运行",支持在同一会话中延续历史记录、为 Web 应用配置后台操作,并提供独立的调度视图与运行历史追踪。所有用户现已可在任务、Project 或自建 Web 应用中直接启用。

核心升级:从定时触发到上下文感知
早期版本的定时任务仅解决"何时运行"问题。据 Manus 团队说明,2.0 版本的核心转向是处理"在哪里运行"以及"携带什么上下文"。当工作流嵌入不同产品场景时,执行环境变得更为复杂:有时需要每日更新 Web 应用数据,有时希望固定自动化按日运行,有时则要求回到同一对话继续推进而非创建新任务。
新版本允许用户在创建时明确指定运行模式。关键区别在于是否在同一会话中继续:若选择延续模式,Manus 将基于已有指令、文件、对话记录和历史结果继续执行;若选择独立模式,则每次运行生成新的独立任务。这种设计让周期性工作能够关联到具体的产物(dashboard、报告或摘要),而非简单重复。
同任务延续与 Project 配置复用
对于依赖历史上下文的场景,Scheduled Tasks 2.0 支持在同一任务内继续运行。日常站会、周期性跟进、状态检查或研究线程等场景,往往依赖此前积累的指令、附件和决策记录。旧版本中每次运行生成独立任务,用户需要跨任务查找结果或重建上下文。

若任务归属于某个 Project,定时任务可复用该 Project 的共享配置,包括文件库、skills、connectors(连接器)、指令模板和输出标准。调度机制跟随工作所在的组织位置,而非仅跟随日历时间。据官方文档,这一改进减少了重复配置的成本,尤其适用于需要统一数据源的周期性报告场景。
Web 应用的后台定时操作
另一个重要场景是 Web 应用本身。使用 Manus 构建的 Web 应用现可内置定时操作,用于数据刷新、脚本运行、dashboard 更新、提醒发送或周期性摘要生成。调度成为应用行为的一部分,用户无需每次打开页面来推动例行工作。

具体实现上,开发者可在 Web 应用内设置每日早晨更新数据或每周生成报告的规则。Manus 将这些调度附加到应用本身,使后台自动化与前端展示解耦。这一能力让基于 Manus 的 Web 应用具备了传统 SaaS 产品中常见的后台任务特性。
可视化管控与执行环境配置
随着定时任务进入更多上下文,可见性变得关键。Scheduled Tasks 2.0 新增了侧边栏调度面板、日历视图和运行历史追踪。用户可查看即将执行的任务、已完成的运行记录,并通过运行卡片或标签直接跳转到关联任务检查具体输出。

编辑界面提供了更细粒度的控制:运行选项(同任务继续或独立任务)、跳过确认(允许可信工作流在发送、发布或提交时无需逐次审批)、connectors(用于接入外部数据源)。高级设置中还可选择具体的 agent、关联 Project 以继承其配置,或在需要时启用云端计算资源。
使用路径与典型场景
官方推荐的使用流程包含四个步骤:打开目标位置(任务、Project 或 Web 应用)、向 Manus 描述定时需求、必要时明确指定要持续更新的产物名称、通过编辑界面调整运行选项与执行环境。

官方提供的示例提示词展示了三类典型场景:“每个工作日上午 9 点总结本任务中的待办事项并提醒今日跟进项”(同任务延续)、“每周一使用本 Project 已有文件和格式更新客户反馈摘要”(Project 配置复用)、“在此 Web 应用中每日早晨刷新 dashboard 数据并生成简短日报”(Web 应用后台操作)。
考虑到当前功能已全量开放,实际稳定性与多用户并发场景下的表现仍需开发者结合具体业务验证。对于需要精确控制执行时机或依赖外部 API 配额的工作流,建议先通过小规模测试观察运行可靠性。
据 Manus 官方文档,Scheduled Tasks 2.0 的核心设计思路是:将定时机制从简单的时钟触发器转变为上下文感知的工作流编排。是否采用同任务延续、是否跳过确认、是否连接外部数据源,这些选项的引入本质上是在"自动化执行"与"人工干预边界"之间提供了更灵活的配置空间。
考虑到该功能上线时间尚短,其在复杂 Project 结构或高频定时场景下的实际表现,尤其是云端资源调度与外部 connectors 的稳定性,仍需通过真实业务负载检验。对开发者而言,当前最实际的验证路径是:从单一、低风险的定时任务入手,测试同任务延续的上下文保持能力,再逐步扩展到需要 Project 级配置复用或 Web 应用后台操作的场景。
评论 ···