博客 · 指南 · 2026年10月28日
用 AEGIS 运行定时智能体:计划、运行,以及失败时你会看到什么
声明:AEGIS 由 100monkeys.ai 开发,因此请把这篇指南当作开发方的说明来读。它由我们的一个 AI 智能体根据公开的 AEGIS 文档(英文)起草,主要是 Schedules 页面和 Schedule Tools 参考,并经公司审阅;这个简体中文版是英文原版指南的译文。下面的每个字段、路由和消息都引自这些页面,引文保留英文原文,译文附在旁边。为写这篇指南,我们没有运行这些调用;文档没有交代的步骤,我们会直接说明。
AEGIS by 100monkeys.ai, in beta,是一个自托管编排器,在隔离且强制执行策略的运行时中运行自主智能体。本指南把你的一个智能体放到定时器上,回读每次触发做了什么,并展示一次触发可能出现的四种结果,让没有发生的运行和发生了的运行一样清楚可见。
什么是计划
文档用一句话定义它:"A schedule starts one of your agents or workflows as you, either once at a time you choose or again and again on a recurrence."(计划以你的身份启动你的某个智能体或工作流,可以在你选定的时间运行一次,也可以按重复规则一次又一次地运行。)由此得出三点,每一点都决定了下面的步骤。
- 计划是你自己的对象,"never a field of the agent or workflow it runs"(从来不是它所运行的智能体或工作流的一个字段)。
- 它以一个人的身份运行。"A schedule always runs as a person. A service account, or an operator acting for no person, cannot make, change, pause, resume, run or delete one."(计划总是以一个人的身份运行。服务账户,或者不代表任何人的运维者,都不能创建、修改、暂停、恢复、运行或删除计划。)
- 每次触发都是一次普通的运行。"At each fire the orchestrator starts the run exactly as
aegis.task.executeoraegis.workflow.runwould for you, with the schedule's intent, input and connections."(每次触发时,编排器启动运行的方式与aegis.task.execute或aegis.workflow.run为你启动时完全一样,使用计划的 intent、输入和连接。)
第 1 步:选好智能体和时间
用一个你已经用 aegis task execute <AGENT> 手动运行过一次的智能体,这样你知道一次好的运行是什么样子。
然后在两种时间方式中选一种。只能给其中一种。
- 一次:
at,一个 RFC 3339 时间,"at least one minute from now and at most a year ahead"(至少在一分钟之后,最多在一年之内)。 - 重复:
recurrence,带有cron、timezone和jitter_seconds。cron 有五个字段(分、时、日、月、星期),"no seconds field and no@daily-style shorthand"(没有秒字段,也没有@daily这类简写)。时区是 IANA 名称,默认UTC。jitter 会让每次运行随机延迟,最多那么多秒,上限 3600。
规划时要考虑两个限制:"A schedule runs at most once every 5 minutes"(一个计划最多每 5 分钟运行一次),以及你最多可以持有 25 个未删除的计划。
第 2 步:选定运行能访问的范围
定时运行只能访问其 profile 或 contexts 指定的连接,而 "a schedule with neither reaches none of your connections."(两者都没有的计划访问不到你的任何连接。)一个计划只带其中之一,不会两者都带。如果你的智能体要读邮件或仓库,现在就指定 profile;否则触发会因为缺少连接而被拒绝,拒绝信息也会这么说。
第 3 步:创建计划
CLI Reference 中没有 aegis schedule 这条 shell 命令。你可以用 REST 路由 POST /v1/schedules(作用域 schedule:write)、MCP 工具 aegis.schedule.create,或在 Zaru 的 Schedules 页面创建计划。按参考中的列法,这个工具接受以下参数:
aegis.schedule.create {
"name": "Morning inbox triage",
"target_kind": "workflow",
"target": "email-inbox-triage",
"intent": "Sort the new mail",
"input": { "mailbox": "ann@example.com" },
"recurrence": { "cron": "*/30 * * * *", "timezone": "UTC", "jitter_seconds": 300 }
}
这个示例是文档自己的计划。把 target_kind 换成 agent,把 target 换成你的智能体名称。返回的是 {"schedule": {...}},包含其 state、next_run_at 和 last_run。离开之前,先回读一下 next_run_at。
第 4 步:现在就触发一次
不要等到第一个计划时间才知道它是否有效。所有者可以用 POST /v1/schedules/{id}/run 或 aegis.schedule.run_now 立即启动一次运行。它的运行方式 "exactly as a fire starts it: as the owner, with the schedule's target, input, connections or profile, and attachments"(与一次触发启动它完全一样:以所有者身份,使用计划的目标、输入、连接或 profile 以及附件),而且 "nothing else changes"(其他一切都不变):计划保持原有的状态和时间安排。
第 5 步:阅读运行记录
aegis.schedule.runs { "schedule_id": "<id>", "limit": 20 }
路由是 GET /v1/schedules/{id}/runs?limit=。运行按从新到旧排列,每条都有 scheduled_time(立即启动的运行为 null)、fired_at、outcome、detail 和 execution(其 id、kind 和 status)。要读运行本身,把执行 ID 拿到 CLI 里:aegis task logs <EXECUTION_ID>,只想看失败时加上 --errors-only。
第 6 步:了解四种结果
每次触发在每个计划时间只记录一次,所以 Temporal 重复的触发会 "answers the first fire's record instead of starting a second run"(返回第一次触发的记录,而不是启动第二次运行)。每条记录有一个结果:
started:运行已启动,触发记录下它的执行 ID。skipped_overlap:"The run the previous fire started is still running, so this fire starts nothing."(上一次触发启动的运行仍在进行,所以这次触发什么也不启动。)Zaru 把它显示为 "Skipped: the last run was still running"(已跳过:上一次运行仍在进行)。skipped_paused:计划已暂停。refused:"The run could not start. The fire records the refusal's sentence, for example a required connection that was not chosen."(运行无法启动。触发会记录拒绝的原话,例如没有选择某个必需的连接。)
started 只说明运行开始了,不说明它成功了。运行自身的状态在 execution.status 中,失败原因在它的日志里。
第 7 步:了解触发持续失败时会怎样
"When the last three fires of a recurring schedule were all refused, the schedule pauses itself, with the reason 'Paused after three runs could not start: <the last refusal>.'"(当一个重复计划的最近三次触发都被拒绝时,计划会自行暂停,原因是 'Paused after three runs could not start: <最后一次拒绝>.'。)读取计划上的 paused_reason,修复原因,然后用 aegis.schedule.resume 恢复。编排器重启期间错过的触发 "is still made up to 10 minutes late; later than that, the time is skipped."(在延迟 10 分钟以内仍会补上;超过这个时间,这一次就跳过。)
第 8 步:审批依然有效
定时运行以你的身份行事,"so every tool call that waits for your approval in a conversation waits for it in a scheduled run too"(所以在对话中等待你批准的每个工具调用,在定时运行中也同样等待)。在 Zaru 中,这类请求会在 Approvals 页面上以 "From your schedule <name>"(来自你的计划 <name>)列出。
文档尚未回答的问题
- shell 命令。CLI Reference 没有列出 schedule 子命令,所以自托管用户要用 REST 路由或 MCP 客户端。
- 在本地栈上"你"是谁。计划以一个人的身份运行,并需要
schedule:write,而aegis init栈运行时没有 IAM。文档没有说明在那里计划归谁所有;我们没有测试。
下一步
要在定时智能体和它发送的任何东西之间加一个人,请阅读如何给编排器加上审批步骤。要读懂一次运行做了什么,请阅读读懂 AEGIS 执行日志。