定时工作、群值守与文档评论

这三个入口都可以触发 Agent，但触发条件、上下文和结果去向不同。先选对入口，再验证 系统实际保存或接收了什么，避免把 Agent 的口头承诺当成已经启用的自动化。

入口	触发条件	执行与结果
Schedule	Hub 上保存的时间规则到期	向 Session 提交，或创建子 Task；按其记录查询结果
群值守	已纳入值守的群出现符合条件的新根消息	创建独立话题工作，通过群内话题或卡片呈现
文档评论	已启用能力，负责人在文档评论里 @助手	在对应评论串的 Session 中执行，结果回复评论

请助手安排定时任务

创建前说明执行条件

Agent 必须能使用 amux 定时工具，Hub 需要持续运行，执行 Runtime、专家、凭据和工作区 要在触发时可用。创建 Schedule 不是提前锁定未来的所有权限：每次触发都会重新检查 授权和执行条件。

说明时间、时区、工作范围、专家、输入位置、权限边界和结果查看方式。例如：

@助手 请创建每个工作日 09:00 的仓库检查，按 Hub 本地时区计算。先核对 Hub 时区和 Runtime 上的仓库位置，只做只读检查。创建后回报规则 ID、实际规则、专家、工作区、 下一次触发时间及其时区。结果保存在 Task 记录中，不要把“已安排”当成已经完成检查。

若 Agent 不能确定时区或工作区，应先让运维者核实。上述文字是给 Agent 的请求，不是 新增的飞书命令；话题中没有可用的 /schedule 或 /sched。

创建后核验

1. 记录工具返回的 schedule_id 和 next_run_at，不要只接受“每天会帮你检查”的文字。
2. 请 Agent 用 amux.schedule_get 读取刚创建的规则，核对 enabled、spec、Task 内容 和执行选项。amux.schedule_list 分页返回清单，不能只看第一页就声称没有其他规则。
3. 先用较短的测试周期或明确的未来时间验证一次。不要为了验证而重复创建同名规则。
4. 到期后读取规则历史，找到这一轮的 Task ID，再用 Task 工具查询执行结果。
5. 确认结果满足要求后，再保留正式规则；不需要的测试规则应停用或删除。

运维者可从终端核对：

amux schedule list
amux schedule runs <schedule-id>
amux task show <task-id>
amux task logs <task-id>

MCP schedule_create 默认创建定时子任务（schedule_type=subtask）。子任务不会自动建立 “把结果推回原飞书聊天”的通知承诺；历史记录保存 Task ID，结果通过 amux.task_get / amux.task_stream 获取。若要主动推送，需要另行具备并配置实际的消息发送能力，不能仅凭 保存 Schedule 就假定已经实现。

当 Agent 需要定期唤醒某个 Session 处理监控类工作时，使用 schedule_type=session-prompt， 提供 prompt，并用 session 传入目标 session-ref（形式与 CLI amux schedule create <session-ref> 相同：target/name、Session ID 或名称）；省略 session 时回落到当前 AMUX_SESSION_ID。解析复用 CLI session-ref 路径，到期投递复用 deliverReuseSession（或 new-session-per-run）。最短间隔仍为 1 分钟；不要用会再次无限 创建同向 Session 定时规则的提示词形成自调度死循环。

时间规则、执行类型与失败行为

支持的时间表达式

规则	例子	解释
间隔	every 30m、every 1h30m	最短一分钟，按间隔安排后续触发
每天	daily 09:00	按 Hub 本地时区的每天 09:00
Cron	cron 0 9 * * 1-5	标准五字段，没有“秒”字段；使用 Hub 本地时区
一次性	at 2027-01-15T09:00:00+08:00	明确时间点；示例日期须替换为所需的未来时间

at 2027-01-15 09:00 这样的无偏移时间也按 Hub 本地时区解析。发消息的手机、浏览器和 创建规则的终端时区不会自动覆盖 Hub 时区。让 Agent 把下一次触发时间连同时区一起解释， 不要只核对一个“09:00”。

Session 定时与子任务定时

类型	何时使用	边界
Session 定时	运维者或 Agent 让已有会话定期收到提示；CLI schedule create <session-ref>，或 MCP schedule_create 且 schedule_type=session-prompt 并传 session session-ref（可回落 AMUX_SESSION_ID）	可复用 Session，或使用其设置每次启动新 Session；不是克隆全部历史；到期 Submit（Source: scheduler）可唤醒 Agent
子任务定时	每次做一项有独立结果的工作；CLI create-task，或 MCP schedule_create（默认 / schedule_type=subtask）	每次创建临时子 Task，记录独立 Task ID

定时子任务可用默认权限策略、policy-allow 或 deny-all，不支持 escalate-to-main。 不要为无人值守工作配置一个必须等待已结束主对话来处理的权限流程。策略也不能替代 文件访问权、模型登录和工作区准备。

“触发成功”不等于“任务完成”

记录	含义与下一步
ok	Session 提示已投递，仍需查看 Session 的执行结果
ok:task:<id>	子 Task 已创建，使用该 ID 查询成功、失败或超时
skipped:offline	重复 Session 规则本次目标离线，等待下次计划触发
missed	一次性触发未能完成投递或提交，不会自动再来一次
error: ...	读取实际错误，核对授权、输入、目标或提交资源

重复规则即使本次投递失败，也会推进到后续触发时间；不会针对同一轮无限重试，也不应 期望停机期间每个错过的周期都会补跑。一次性规则在被消费后不自动重试。需要重做时， 先核对是否已有 Task，防止重复工作，再安排新的明确执行。

修改、暂停与删除规则

可以让 Agent 用 amux.schedule_update 修改已有规则，用 amux.schedule_set_enabled 暂停或启用，用 amux.schedule_delete 删除。每次操作后重新读取同一个 ID，确认真实状态。

例如：“停用规则 <schedule_id>，保留记录供检查。告诉我是否还有之前创建的 Task 在运行， 先不要把停用规则当成已取消这些 Task。”

运维者暂停未来触发：

amux schedule disable <schedule-id>
amux schedule runs <schedule-id>

停用或删除规则不会代替取消已创建的 Task。要停止那一轮执行，按 Task ID 单独取消， 然后核对最终状态。重新启用规则也不代表自动重跑此前失败的 Task。

自动处理群里的新话题

开启与验证

群值守适合告警分析、对新问题做初步处理等场景。它要求目标群使用话题模式，机器人能够 接收或读取对应消息，并且有可用的执行专家与资源。

1. 负责人在目标群 @机器人发送 开启群值守。
2. 检查确认卡上的群名称与助手，确认把该群纳入值守。
3. 通过群 /amux 或私聊管理卡检查本群已加入、值守已开启。
4. 发送一条符合发送者规则的新根消息做验证；测试自动入口时不用 @当前机器人， 否则会进入普通的提及路由。
5. 查看是否出现新话题工作和进度卡，并核对实际使用的专家和输入材料。

同一机器人可以对不同群设置不同发送者类型，例如一个群只处理应用告警，另一个群处理 用户提问。每群覆盖规则只改变发送者筛选，不会把未加入的群自动加入值守。

分别设置每个群

私聊 /amux 打开群值守，在目标群旁点击 设置本群值守；群设置卡也提供同一入口。 可以调整本群启停、继承/自定义任务配置、专家、运行引擎、模型、思考强度、处理过程展示、 活跃会话上限（1–500）和自动休眠（60–604800 秒）。继承任务配置使用本群普通会话默认值。 保存整份表单只影响本群，重新打开可查看已保存值。选项较多时使用翻页按钮，翻页和刷新 模型会保留已填写内容；过期卡片须重新打开后再保存。

未单独保存的群继续使用原有 Bot 级值守默认值。全局暂停仍会暂停所有群。已有 Session 保留执行参数，新会话使用保存后的专家和休眠阈值。

什么消息会被处理

条件	当前行为
群已纳入且值守启用	仍需通过发送者类型、消息内容、容量和访问检查
用户或应用发出的新根消息	按有效的发送者允许列表筛选；不是所有回复都会新建工作
文字或有效的图片、文件、合并转发	可作为输入；只有材料时使用材料描述继续处理
提及当前机器人	走普通提及入口，避免值守再重复创建
应用告警只提及人	仍可能符合值守条件
应用消息提及其他机器人	排除自动处理，避免机器人之间形成循环
管理命令、空或已删除消息、自己的机器人输出	不作为普通新告警启动
重复事件或达到活动会话上限	去重或容量限制可能阻止新执行

除实时事件外，值守还有受回看窗口限制的历史轮询，用于发现最近消息；它不是全群历史 重放。不能用一条很久以前的消息判断新启用的值守是否正常。

应用告警还有可选的内容去重，默认关闭。启用后，同群、同发送应用的匹配告警在配置窗口 内可能被抑制，不产生新的 Session；用户消息和不同群分别处理。含糊的机器人提及解析 或内容去重可能需要读取群机器人列表权限，缺权限时应检查能力提示，不要通过重复发送 同一告警来判断“没有反应”。

停止值守与独立群配置

负责人发送 关闭群值守 并按卡片确认，将本群移出值守；这停止后续自动接入，不等于 取消已经创建的话题工作。需要停止已有执行时，处理对应话题或 Task。

独立群配置优先决定本群是否采用话题路由，值守可在机器人全局使用 singleton、而目标群 独立使用 thread 的情况下工作。切换本群为连续会话前必须关闭该群值守；关闭群独立配置 实验后，已经独立配置的群会暂停自动工作，保留原设置。

从文档评论发起工作

文档评论是单独的接入能力。当前版本要求已确认的机器人负责人发起；开启群协作不会让 所有群成员自动获得文档评论入口。

1. 负责人在私聊 /amux 的助手设置中启用文档评论接入，按能力检查提示准备所需平台 权限与文档访问条件。
2. 在可访问文档的一条评论中，通过飞书提及功能 @助手并写出具体请求，例如“检查此段 方案的边界条件，在评论回复建议，先不要改正文”。
3. 系统读取评论与可获得的相关文档上下文；读不到评论或具体请求时会提示失败，不会 假装已经分析。
4. 在同一评论串再次 @助手继续讨论；不同根评论各自绑定独立 Session。
5. 查看评论回复。如收到需要授权的提示，到机器人私聊处理权限卡，再回到评论看结果。

输入以评论及选定的相关上下文为中心，不保证把整篇文档无限制装入对话。结果通过评论 返回，不会因为启用接入就自动修改正文；是否写文档取决于 Agent 工具、你的要求和授权。 同一事件会去重，不应把平台重复投递视为新的工作要求。

自动化没有发生时

现象	检查顺序
Agent 说已安排，但没有规则	索取 schedule_id，读取规则；检查工具是否可用
到时间没收到飞书通知	先查触发历史和 Task，区分执行结果与未配置的消息推送
规则成功，Task 却失败	ok:task 只表示创建成功，读取 Task 错误、工作区和凭据条件
群值守没有处理测试消息	群是否加入、是否 thread、是否新根消息、发送者类型、提及对象和容量
重复应用告警没有产生新卡	检查消息去重与可选告警内容去重窗口
文档评论没有启动	是否负责人、能力和权限是否可用、是否真正 @、评论请求是否可读取
文档工作卡住	查看机器人私聊里的权限请求，以及评论中的失败说明

精确参数见 CLI和 MCP参考； 当前接入边界见 Bridge 模型。