parallel-monitor

Web Monitor

操作：$ARGUMENTS

GA Monitor 命令需要 parallel-cli ≥ 0.4.0。如果缺少某个 Monitor 命令或选项，请告知用户通过其安装方式更新（参见 https://docs.parallel.ai/integrations/cli），然后重试。

此技能的功能

Monitor 是长时间运行的服务端任务，会按固定频率重新检查 Web，并在发生变化时发出事件。与 search/research/findall（一次性查找）不同，Monitor 会一直运行，直至被取消；也可以选择通过 webhook 传递检测到的事件。创建 Monitor 并不会建立持续运行的 Agent 通知服务：请说明如何读取服务端事件，或使用已配置的 webhook，不要承诺会通过聊天或电子邮件发送提醒。

默认类型为 event_stream，频率为 1d，服务端处理器为 lite。snapshot Monitor 需要一个现有的 Task 运行 ID。只创建或修改用户所请求的资源；不要仅仅为了演示此技能而创建 Monitor。

确定操作

解析用户请求并选择一项：

意图	操作
“跟踪 / 关注 / 监控 / 在 X 发生时提醒我”	创建
“我在监控什么？” / “列出 Monitor”	列出
“有什么变化？” / “显示 Monitor X 的事件”	事件
“显示 Monitor X” / “获取 X 的详细信息”	获取
“更改 X 的频率 / webhook”	更新
“现在检查 Monitor X” / “立即运行”	触发
“显示事件组 X 的完整负载”	使用 --event-group-id 的 事件
“停止 / 删除 Monitor X”	取消（永久操作；请核实操作权限和确切 ID）

创建 Monitor

parallel-cli monitor create "<query>" --frequency 1d --json

频率接受 <n><unit> 格式，其中 unit 为 h、d 或 w（例如 1h、1d 或 1w），支持范围为 1 小时至 30 天。也接受 hourly、daily、weekly 和 every_two_weeks 这些别名。根据用户的请求以及来源实际变化的频率来设置检查频率。

可选标志：

• --webhook https://example.com/hook — 将检测到的事件传递到某个 URL
• --metadata '{"team":"competitive-intel"}' — 附加 JSON 元数据，供你自行记录
• --output-schema '<json>' — 对事件负载进行结构化设置（高级）

收到响应后，立即保存 monitor_id，并同时记录查询、频率和请求的设置。使用该 ID 调用 get，验证 Monitor 已创建。告知用户：

• Monitor 已创建，并提供其 ID
• 频率（让用户了解 Monitor 的检查间隔）
• 最近的事件可在服务端查看——用户之后可以运行 parallel-cli monitor events $MONITOR_ID 查看发生了什么变化

如果创建或其他变更操作超时，或响应丢失，请先查明现有 Monitor / 操作的状态，再重试。使用已保存的 ID，调用 get 和 events 恢复操作；不要自动重新创建。重新创建可能导致重复的持续监控和计费。

列出 Monitor

parallel-cli monitor list -n 10 --json

默认使用 -n 10，以获得简洁的输出。list 默认只返回活动中的 Monitor；如果用户要求包含已取消的 Monitor，请添加 --status active --status cancelled。只有在 Monitor 数量更多时才提高上限。以表格形式展示：ID、查询或 Task Run（截断）、频率、创建时间。

注意：monitor list 按创建时间从新到旧排序。如果用户正在确认创建结果，优先使用创建时返回的 ID 调用 monitor get $MONITOR_ID，而不是扫描列表。

查看监控器的事件

parallel-cli monitor events "$MONITOR_ID" --json

事件按时间倒序返回。如果响应包含 next_cursor，请通过 --cursor 传入该值以获取下一页。

事件列表为空，并不能证明检查已完成且未发现变化。若要同时查看完成历史记录和检测到的事件：

parallel-cli monitor events "$MONITOR_ID" --include-completions --limit 10 --json

区分已检测到的类型化事件、无变化的 completion 事件和 error 事件。使用其实际时间戳并报告失败。完成历史记录为空不能证明任务已执行。如有 event_id 和 event_group_id，请予以保留；它们用于标识事件和执行记录，而不是监控器 ID。

若要深入了解特定事件组：

parallel-cli monitor events "$MONITOR_ID" --event-group-id "$EVENT_GROUP_ID" --json

事件组详情会忽略分页参数。请将检测到的变更与完成记录／错误分别总结，并注明日期或时间戳。读取类型化的 output 或 changed_output 以及可用的 basis；事实性陈述请引用其来源 URL。如果负载中没有依据，请勿臆造来源。指出响应中的警告，并仅在所请求的时间段需要时继续分页。

获取／更新／触发／取消

parallel-cli monitor get "$MONITOR_ID" --json
parallel-cli monitor update "$MONITOR_ID" --frequency 1w --json
parallel-cli monitor update "$MONITOR_ID" --webhook https://example.com/hook --json
parallel-cli monitor trigger "$MONITOR_ID" --json
parallel-cli monitor cancel "$MONITOR_ID" --json

只提供用户要求更新的字段。仅更新 webhook 不会改变频率；更新操作没有默认频率。也可以通过命令行更新元数据和高级事件流设置，但查询和 Task 运行身份不可更改。若要使用不同查询，必须在单独授权下创建新的监控器，并审慎决定如何处理旧监控器；不要擅自重新创建或取消旧监控器。

trigger 会将一次真实的、按需执行的任务加入队列并产生费用，但不会更改常规计划。它不是模拟 webhook 测试，也不能替代测试通知送达情况的请求。成功的触发响应仅确认任务已加入队列，不代表执行已完成。只有发现实质性变化时才会发出已检测到的事件；若执行未发现变化，请检查完成历史记录。已取消的监控器无法触发。

取消操作不可撤销，既不是删除，也不是临时暂停。请说明这一点，并针对确切的监控器 ID 获取确认，除非用户已授权永久取消该监控器，或清理特定的临时监控器。取消后，请通过 get 验证其状态。绝不要自动重新创建监控器来恢复监控。

遇到身份验证或 API 错误时，请报告实际错误并保留 ID，以便后续处理。不要将所有错误都归因于 CLI 过时，也不要将所有权限错误都归因于额度不足。读取失败不能证明监控器已停止；读取事件不会取消监控器。

设置

需要已安装并完成身份验证的 parallel-cli。检查 parallel-cli --version 和 parallel-cli auth --json；即使 authenticated 为 false，身份验证命令也可能成功退出。缺少二进制文件、不支持的命令／选项和身份验证失败需要不同的处理方式：安装、通过现有安装方式升级，或在终端中登录。请参阅 https://docs.parallel.ai/integrations/cli。身份验证失败时，请停止处理受影响的请求；不要在聊天中索要机密，也不要更改账户策略来绕过被阻止的设置流程。