99%的人以为“定时任务”就是设个闹钟、按时跑一遍脚本，但真正麻烦的从来不是时间，而是上下文。你可能也遇到过：日报按时生成了，却散落在一堆无关任务里；报表每天更新，却总要重新解释一次规则。Scheduled Tasks 2.0 想解决的，就是这种“准时但没用”的自动化。
Scheduled Tasks 2.0 把“什么时候跑”升级成“在什么地方、带着什么上下文、持续更新哪个成果”。它可以在同一个任务里不断续写，也能让用 Manus 搭建的 Web 应用拥有自己的定时动作，还提供更清晰的日程和历史视图，方便你追踪每一次执行。
据用户反馈，在旧版本里做周报、日报的团队，经常要在十几个任务里来回翻找结果，真正花时间的不是生成内容，而是找回上下文。
定时任务不再只是“按时跑一次”
上下文，比时间更关键
很多人设置定时任务，只盯着“每天 9 点”“每周一”这些时间点，却忽略了一个关键问题：这次执行应该接着哪一段历史继续。日常站会记录、持续跟进的客户线程、长期研究笔记、固定格式的仪表盘更新，这些都严重依赖已有的指令、文件和决策。
旧版 Scheduled Tasks 每次运行都会生成一个全新的任务，时间是对的，但内容被拆散了。结果就是：你要在多个任务里翻找结果、重新补充背景，甚至一遍遍说明“要更新的是同一个报告”。
Scheduled Tasks 2.0 直接把这个问题掐断在源头。现在，定时任务可以选择“继续在同一个任务里执行”，沿用原有的指令、文件、对话和历史结果，让自动化真正像一个持续的工作线程，而不是一堆互不相干的快照。
有用户反馈，把团队周报改成“在同一任务内持续更新”后，历史记录一目了然，新成员只要打开这一个任务，就能从第一周看到最近一周的完整演进。
项目级上下文，一次配置反复复用
很多团队会把文件、技能、连接器、输出规范都集中配置在一个 Project 里，让它成为“这类工作的标准环境”。过去，定时任务更多是独立存在，和 Project 的关系不够紧密。
现在，Scheduled Tasks 2.0 可以直接复用 Project 的共享配置：文件、技能、连接器、指令、输出标准全部继承。你不必在每个定时任务里重复设置一遍，只要把任务挂在对应的 Project 下，后续的定时执行都会自动在这套环境里运行。
我自己试过把“客户反馈周报”挂在一个专门的客户洞察 Project 里，所有数据源、分析模板都在那边维护。每周的定时运行只负责“拉最新数据+按统一格式输出”，维护成本一下子降下去很多。
在同一个任务里持续推进工作
把“重复执行”变成“持续线程”
很多重复性工作，本质上是一个不断延伸的线程，而不是一次次互不相关的事件。比如：
- 每天的 standup 记录和行动项跟进
- 针对同一客户的周期性回访与总结
- 长期研究主题的阶段性更新
- 固定仪表盘的定期刷新与解读
旧版本里，每次定时运行都会生成一个新任务，虽然形式上“按时完成”，但语义上却把一条线拆成了很多段。Scheduled Tasks 2.0 允许你直接指定：这条定时任务要继续在当前任务里执行。这样，所有历史对话、附件、决策和结果都自然串在一起。
一位团队负责人提到，他们把“每周项目健康度检查”改成在同一任务内执行后，半年下来看这个任务，就像一份完整的项目生命线，任何风险点都能追溯到当时的上下文。
项目内的共享环境自动继承
当工作是围绕 Project 组织时，定时任务也可以“住”在 Project 里。它会自动继承：
- 该 Project 下的文件和资料库
- 已配置好的技能和工具
- 外部连接器（如数据源、业务系统）
- 统一的输出格式和质量标准
这样，时间不再是唯一的锚点，“工作所在的位置”才是。定时任务跟着 Project 走，而不是跟着某个孤立的时间规则走。对团队来说，这意味着：只要维护好 Project 的配置，所有挂在其上的定时任务都会受益。
给 Web 应用加上“后台定时大脑”
Web 应用也能自带定时动作
很多用 Manus 搭建的 Web 应用，本身就承担着“看板、报表、工具台”的角色。它们往往需要：
- 定期刷新数据
- 按计划运行脚本
- 更新仪表盘
- 发送提醒或通知
- 生成周期性摘要
Scheduled Tasks 2.0 让这些动作直接成为 Web 应用的一部分。你不需要每天早上点开页面、手动点一下“刷新”，只要在应用里配置好定时动作，Manus 就会在后台按节奏执行。
用户不在线，自动化照样运转
现实里，很多关键动作并不会刚好发生在你盯着屏幕的那一刻。比如：
- 每天清晨拉取前一日的业务数据
- 每周一早上生成上周运营复盘
- 每月初更新财务仪表盘
以前，这些事情往往要有人“想起来、点一下”。现在，定时逻辑直接写进 Web 应用的行为里，哪怕没人打开页面，应用也会在后台按计划运行。
有团队反馈，把“日报生成”做成 Web 应用 + 定时动作后，成员只需要在白天随手往里丢数据，晚上系统会自动汇总成结构化日报，第二天一早就能看到结果。
每一次运行都能被看见、被追溯
更清晰的日程与历史视图
当定时任务分布在任务、Project、Web 应用等不同位置时，光知道“有没有按时跑”已经不够。你还需要：
- 看清接下来会发生什么
- 了解过去都跑了哪些任务
- 快速定位每一次运行的结果
Scheduled Tasks 2.0 提供了更直观的可视化：侧边栏可以集中展示所有定时任务及其关联的运行记录；日程视图和日历视图，让你一眼看出哪天、哪个时间段会有自动化在后台工作。
从“运行卡片”一键跳回结果
每一次定时执行，都会留下清晰的“运行卡片”或标签。你可以直接从这些入口跳回对应的任务，查看那一次执行的具体输出。
对排查问题尤其有用：如果某周的报告数据明显异常，你可以直接点进那次运行，检查当时的上下文、数据源和执行环境，而不是在一堆任务里盲找。
当然，这里也有一个风险点：如果团队对定时任务的命名和归类比较随意，视图再清晰也会显得混乱。所以比较推荐在团队内约定一套简单的命名规范，比如“【项目名】+【频率】+【用途】”。
为每条定时任务选对“运行方式”
在同一任务继续，还是新建任务？
当定时任务不再只是一个时间设置，编辑界面就必须给你更细的控制权。Scheduled Tasks 2.0 把关键选项集中在一个地方，你可以随时调整：
- 提示词 / 指令内容
- 运行频率与时间
- 运行方式：继续在同一任务内，还是每次新建任务
如果你希望所有历史集中在一条时间线里，比如长期研究、持续优化的文档，就选“继续在同一任务内”。如果每次运行都是独立事件，比如“每周为不同客户生成单独报告”，那就更适合“每次新建任务”。
跳过确认、连接外部应用、选择执行环境
Scheduled Tasks 2.0 还提供了一些更“进阶”的控制：
- 跳过确认：对已经验证稳定的流程，可以允许 Manus 直接发送、发布或推送，而不再每次弹出确认。这能明显减少人工打断，但也意味着要更谨慎地测试流程。
- 连接器：为定时任务接入外部应用作为数据源，比如 CRM、分析平台、内部数据库等，让每次运行都能用到最新的业务数据。
- 执行环境：选择具体的 Agent，或者挂载到某个 Project，甚至启用云端算力资源，适合需要大量计算或长时间运行的工作流。
说实话，“跳过确认”这件事听起来有点让人紧张，我也不太确定所有团队都适合一上来就开。但有用户在内部公告、固定格式日报这类低风险场景里用下来，反馈是：节省了大量“点确认”的机械时间。
Scheduled Tasks 2.0 能帮你做到什么
关键能力一览
通过这次升级，你可以更灵活地设计自动化：
- 在同一任务内运行定时工作：让重复任务持续依托同一份指令、文件和历史记录。
- 按需选择运行方式：需要上下文就续写同一任务，需要独立记录就新建任务。
- 复用 Project 配置：让定时任务自动继承 Project 中的文件、连接器、技能和输出标准。
- 把外部应用当数据源：通过连接器，让定时任务直接读取你已经接入 Manus 的工具数据。
- 在可信流程中跳过确认：对已经稳定的工作流，允许 Manus 自动发送或发布结果。
- 为 Web 应用添加定时动作：让应用自己完成数据刷新、脚本运行、仪表盘更新、提醒和摘要生成。
- 用新视图管理所有日程：通过侧边栏、日程视图和日历视图，掌握未来和过去的每一次运行。
- 从运行记录直达结果：从运行卡片或标签一键跳回对应任务，查看具体输出。
有团队统计过，引入定时自动化三个月后，运营同学在“整理日报、周报、月报”上的时间下降了约 40%，而报告的完整度和一致性反而更高了。
怎么告诉 Manus“要帮你定时做什么”
不用记流程，只要去对的地方说清楚
使用 Scheduled Tasks 2.0，不需要学习一套复杂的配置向导。更自然的方式是：先找到这件重复工作真正“属于哪里”，然后在那个地方告诉 Manus 你想要什么样的定时行为。
一个简单的操作路径是：
- 打开这项重复工作所在的任务、Project 或 Web 应用
- 用自然语言告诉 Manus 要做什么、多久做一次
- 如果需要持续更新同一个成果物（比如某个仪表盘、报告、摘要），在描述里把这个“对象”说清楚
- 视情况微调设置：选择运行方式、是否跳过确认、是否添加连接器、是否挂到某个 Project、是否使用云端算力
- 之后，就可以通过侧边栏、日程视图或日历视图，查看未来的运行计划和历史结果
一些可以直接照抄的示例提示
你可以直接用类似这样的语句和 Manus 说话：
- “每个工作日早上 9 点，总结这个任务里还没完成的行动项，并提醒我今天要跟进什么。”
- “每周一，用这个 Project 里的文件和现有格式，更新客户反馈汇总。”
- “在这个 Web 应用里，每天早上刷新仪表盘数据，并生成一段简短的日度摘要。”
这些提示的共同点是：说清楚频率、位置、要更新的对象，以及要沿用的上下文。习惯之后，你会发现配置一个定时任务和跟同事交代一件重复工作，其实没什么本质区别。
现在就能用上 Scheduled Tasks 2.0
Scheduled Tasks 2.0 已向所有用户开放。无论你是在单个任务里维护一条长期线程，在 Project 里管理一类工作，还是用 Manus 搭建 Web 应用，只要那里面有“需要反复发生的事情”，都可以直接告诉 Manus 把它变成定时任务。
如果你正打算把团队里那些“每周都要做、每月都要做”的事情系统化，这套定时机制会是一个很好的起点。等你把几条关键流程跑顺了，再回头看，会发现很多原本需要人盯着的工作，其实完全可以交给自动化接力。
这个判断“该不该自动化”的方法，值得你反复拿出来用一用，也挺适合转给正在搭建团队流程的同事。
常见问题
Q：我怎么判断一个任务适合“继续在同一任务内运行”，还是“每次新建任务”？
A：如果这项工作需要强依赖历史上下文，比如长期研究、持续优化的文档、同一客户的跟进记录，更适合继续在同一任务内运行，这样所有决策和变化都在一条时间线上。反过来，如果每次运行都是独立事件，比如为不同客户生成单独报告、每期活动的独立复盘，就更适合每次新建任务，方便单独归档和分享。一个简单判断标准是：你未来回看时，是更想看到“一条完整的故事线”，还是“一组彼此独立的结果”。
Q：开启“跳过确认”会不会有风险？适合用在什么场景？
A：“跳过确认”确实会增加风险，因为系统会在没有人工审核的情况下直接发送、发布或推送结果。它更适合内容结构稳定、风险较低的场景，比如内部日报、固定格式的运营看板更新、对外不可见的内部通知。在启用前，建议先在“需要确认”的模式下跑一段时间，确认输出稳定、不会误伤用户或业务，再切换到“跳过确认”。同时，可以为高风险动作（如对外群发、修改关键配置）保留人工审核环节。
Q：我已经在 Project 里配置了很多文件和连接器，定时任务会自动用上这些吗？
A：只要你把定时任务挂在对应的 Project 下，它就会自动继承该 Project 的文件、技能、连接器和输出标准，相当于在同一套“工作环境”里运行。这能避免在每个定时任务里重复配置数据源和格式规则。建议在创建定时任务前，先梳理好 Project 的结构，把同一类工作的资源集中在一个 Project 中，这样后续新增的定时任务都能直接复用这些配置，维护成本会低很多。
Q：Web 应用里的定时动作和普通定时任务有什么区别？
A：Web 应用里的定时动作是应用行为的一部分，更偏向“后台服务”，比如定时刷新数据、更新仪表盘、生成摘要等，用户不在线也会照常运行。普通定时任务则更像围绕某个任务或 Project 的自动化线程，通常和具体的协作、文档或对话绑定。选择哪种方式，可以看这件事是“属于某个应用”，还是“属于某个协作任务/项目”。如果你希望用户通过一个统一界面查看结果和操作，Web 应用里的定时动作会更合适。
Q：如果某次定时运行结果异常，我该怎么排查问题？
A：可以先从运行记录视图里找到那一次的“运行卡片”或标签，一键跳回对应任务查看当时的输出和上下文。重点检查三点：一是当时的输入数据是否异常（比如外部数据源更新失败）；二是提示词或指令是否被后续修改过，导致行为变化；三是执行环境是否有变动（如切换了 Agent 或 Project 配置）。排查完原因后，建议在下一次定时运行前，先手动触发一次测试运行，确认问题已修复，再恢复正常节奏。这样的“先定位再回放”的方式，比盲目修改配置要安全得多。
