OpenHuman 触发器体系与 cron 到工作流的统一迁移设计解析【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman本文基于仓库中的设计方案文档 docs/plans/tinyflows-integration/triggers.md 展开结合 flows/bus_part_01.rs、cron/types.rs、core/events.rs 等源码交叉验证。它回答两个问题OpenHuman 的平台能提供哪些触发器trigger以及如何迁移 cron 让一切自动化都成为工作流。一、核心论点几乎所有自动化行为都长成事件 → 条件 → 动作OpenHuman 中几乎每一种自动化行为本质上都已经是同一形态事件 → 条件 → 动作。cron 任务、Composio 应用事件、频道消息响应、潜意识subconscious升级、会议后续动作、通知分流triage……无一例外。区别只在于今天每一类都有自己的一套专用管道bespoke plumbing。设计文档给出的统一化路径是tinyflows 提供一个统一基底——每次运行都对应一张 tinyagents 状态图持久化、可观测、可审批门控而事件总线src/core/event_bus/events.rs约 130 个DomainEvent变体实际实现见 core/events.rs已经是所有这些信号流通的脊柱。终态工作流Workflow成为用户面对的唯一自动化概念。触发器只是一个播种一次流程运行的订阅subscription触发器目录trigger catalog则是事件总线的精选投影外加时间time与手动manual两个入口点。用户不再需要分别理解 cron、Composio 订阅、频道守卫等零散机制只需要理解工作流。二、引擎现状TriggerKind 声明式模型与宿主分发状态2.1 引擎已经建模的触发器种类tinyflows::model::TriggerKind是声明式的——引擎只负责声明实际由宿主host负责触发触发器种类语义manual手动运行schedule定时调度webhook外部 HTTP 回调app_event第三方应用事件Composioform带类型化输入 schema 的表单触发execute_by_workflow被另一个工作流调用chat_message频道消息触发evaluation评估/回归测试运行system系统内部事件通用事件触发器在宿主端trigger_kind_label见 flows/ops_part_01.rs为每种 kind 提供了稳定的 snake_case 线格式标识与 serde 线上判别符一一对应。2.2 宿主分发状态今天只有三种真正会触发设计文档给出的flows/bus.rs宿主分发状态表对照 flows/bus_part_01.rs 中的FlowTriggerSubscriber实现可以逐条验证Kind状态源码锚点manual✅flows_runRPC / UI Run 按钮flows/bus_part_01.rs 中spawn_run复用flows::ops::flows_runschedule✅ cronJobType::Flow→FlowScheduleTick见下节app_event✅ComposioTriggerReceived匹配toolkit trigger_slughandle_app_event大小写不敏感匹配webhook⏸ 延后Composio 即 webhook 故事Event::handle中仅tracing::debug!观察WebhookIncomingRequest明确不分发chat_message/form/execute_by_workflow/evaluation/system❌ 无分发器无对应 match 分支代码层面的直接证据是 flows/ops_part_01.rs 的trigger_kind_firesfn trigger_kind_fires(kind: TriggerKind) - bool { matches!( kind, TriggerKind::Manual | TriggerKind::Schedule | TriggerKind::AppEvent ) }该函数注释明确写道其余种类webhook、chat_message、form、execute_by_workflow、evaluation、system会被接受并保存但还没有接通分发路径——启用这类流程会导致一个永远不自运行的流程。设计文档与源码据此得出关键结论差距不在引擎能力而在宿主分发器和目录。而且system是一个自由的配置面free config surface——我们完全可以构建一个通用的事件触发器分发器而不是九个专用分发器。2.3 schedule 与 app_event 已经端到端跑通scheduleflows::ops::bind_schedule_trigger注册一个 cronJobType::Flow任务 → 调度器发布DomainEvent::FlowScheduleTick { flow_id }→FlowTriggerSubscriber::handle_schedule_tick重新加载该 flow校验仍为 enabled 且触发器类型仍是schedule然后以空载荷触发运行。对应源码见 flows/bus_part_01.rs。app_eventhandle_app_event遍历所有 enabled flows用matches_app_event做 toolkit/trigger_slug 的大小写不敏感匹配匹配成功即以事件载荷作为 run input 触发运行flows/bus_part_01.rs。由于 Composio 触发器由平台负责投递这就是第三方应用的 webhook 故事无需自己搭建隧道。并发防重FlowTriggerSubscriber内部维护in_flight: ArcMutexHashSetString用try_acquire_dispatchInFlightGuard保证同一 flow 的触发器驱动运行不会重叠guard 在Drop包括 panic时自动释放不会永久卡死后续 tick。三、提案中的触发器目录按来源组织设计文档的核心产出是一份按来源组织的触发器目录。Backing event 指会喂给分发器的现有DomainEvent变体。以下条目中标注的事件名均能在 core/events.rs 中找到对应变体。3.1 时间schedule已通过 cron 上线。把 cron 已有的丰富度全部暴露出来对应CronJob模型见 cron/types.rsCron 表达式今天的路径与间隔每 15 分钟语法糖。Schedule枚举本身已支持三种形态cron/types.rsCron { expr, tz, active_hours }、At { at }一次性、Every { every_ms }并且反序列化器兼容裸字符串0 9 * * 1自动转成Schedule::Cron。一次性One-shot在 T 时刻运行一次——cron 的delete_after_run已经建模了这一语义把它在触发器配置中暴露出来即可。窗口化调度仅工作日、静默时段——尊重scheduler_gate。Schedule::Cron的active_hours字段ActiveHours { start, end }即为此预留。3.2 手动与参数化manual、formManualRun 按钮 / RPC / agent 发起flows_run携带 input。Form一次带类型化输入 schema 的手动运行。触发器配置声明字段UI 渲染表单提交结果成为触发器载荷。这相当于 n8n 的 Form trigger能让每个工作流都获得一个可分享的迷你应用入口。实现成本低校验 在 canvas/运行对话框里生成表单。3.3 外部应用app_event、webhookComposio 触发器已上线Gmail 新消息、Slack 事件、GitHub push、日历事件……平台负责投递宿主按 toolkit/slug 匹配。剩余工作只是订阅生命周期 目录呈现。原始 webhook延后非 Composio 的 HTTP 调用方通过webhooks::ops隧道接入。列入 backlog直到有需求。3.4 对话chat_messageBacking eventsChannelInboundMessage/ChannelMessageReceived/ChannelReactionReceived其中ChannelInboundMessage已在 core/events.rs 确认存在。收到消息带过滤条件——provider/频道 id、发送者、正则或关键词、我、DM 与群聊区分。收到表情回应如在消息上打 ✅ → 归档为一个任务。护栏这些运行消费的是不可信文本——任何agent节点之前必须先做prompt_injection筛查并施加 per-flow 防抖/并发上限复用app_event分发器的 guard 泛化。3.5 Agent 与任务生命周期systemBacking eventsAgentTurnCompleted、SubagentCompleted/SubagentFailed、ApprovalDecided、TaskSourceTaskIngested、TaskRunReclaimed、ThreadGoalUpdated。示例任何子 agent 失败时把摘要贴到我的运维频道任务从任务源被摄取时做富化与打标审批被拒绝时通知发起人的线程。3.6 记忆与知识systemBacking eventsMemoryStored、MemoryIngestionCompleted、MemoryDiffComputed、DocumentCanonicalized、TreeSummarizerHourCompletedMemoryStored见 core/events.rsDocumentCanonicalized见 core/events.rs。示例文档被规范化canonicalized后生成摘要并存储每小时摘要落地后检查是否有 action items。3.7 会议与语音systemBacking eventsMeetingSessionCreated、MeetingSummaryGenerated、BackendMeetTranscript、PttTranscriptCommitted、MeetingAutoJoinTriggered。示例会议摘要生成后提取 action items → 创建任务 → 邮件通知与会者——这是旗舰演示工作流flagship demo workflow。3.8 通知与设备systemBacking eventsNotificationIngested/NotificationTriaged、DevicePaired、DevicePeerOnline/OfflineNotificationIngested见 core/events.rs。示例分流自动化来自应用 X 的通知被摄取时判定紧急/忽略、在场自动化我的手机上线时同步……。3.9 平台与健康systemBacking eventsSystemStartup、HealthChanged、HealthRestarted、AutonomyConfigChanged、McpServerDisconnected、ProviderApiKeyRejected、EmbeddingModelUnhealthy。示例自愈/维护类工作流健康度下降时运行 doctor 并报告。这类应默认require_approval关闭但通知密集。3.10 潜意识升级systemBacking eventsSubconsciousTriggerProcessed、TriggerEvaluated、TriggerEscalatedSubconsciousTriggerProcessed见 core/events.rs。潜意识域本身就是一个迷你自动化引擎evaluate → escalate。长期收敛候选一次升级的动作变成运行流程 X让工作流成为潜意识信号的执行层actuator layer而非一套平行系统。3.11 工作流到工作流execute_by_workflow、evaluationexecute_by_workflow当另一个流程通过sub_workflow/按 id 调用指向本流程时触发——支持组合和共享库流程。evaluation为 eval-harness 对某个流程的运行保留用录制的输入对工作流做回归测试与dry_run_workflow配对。四、设计一个通用事件分发器而非 N 个专用分发器针对 §3.5–3.10 这类大量system事件逐个手写handle_*像handle_app_event那样无法扩展。设计文档提出四项内容1. 触发器目录注册表新增flows/trigger_catalog.rs一个经过挑选的DomainEvent变体 allowlist暴露为触发器——每条形如{ key: meeting.summary_generated, event: variant match, payload_schema, description, risk_class }只有进入目录的事件才可订阅原始事件总线绝不整体暴露raw bus 不向用户/agent 全量开放。2. 通用分发器FlowTriggerSubscriber内每个目录化事件一个 match 分支把事件投影project成稳定的 JSON 载荷然后匹配所有启用的、触发器为kind: system, config: { event: key, filter: jq expr }的流程。可选的过滤器直接复用现有 jq 引擎tinyflows::expr对载荷求值——不引入新的表达式语言。3. RPCflows_list_trigger_catalog()喂给 Phase 3 的触发器配置 UI 和 Phase 5 的 builder agent这样会议结束时……这类自然语言提示能落地到真实的目录 key。4. 护栏非协商项在分发器内强制循环防护流程运行本身也会发出事件由流程产生事件触发的运行携带血缘链provenance chain与最大深度复用 tinyagents 的root_run_id血缘一个流程永远不能触发自己。防抖/限速per-flow 触发器令牌桶 现有 per-flow 并发 guard。载荷卫生目录投影默认剥离 PII 类字段agent节点前做prompt_injection筛查。风险分级目录条目打标签如对话事件 不可信输入类 → 强制筛查健康事件 内部类校验时在 UI 中呈现风险等级。五、cron → 工作流迁移让 cron 退居调度服务之位5.1 现状今天cron运行三种任务类型cron/types.rs::JobType见 cron/types.rsShell、Agent和Flow后者本身已只是给流程发布的 tick——JobType::Flow的注释明确说明触发时调度器发布DomainEvent::FlowScheduleTick { flow_id }实际分发由flows::bus::FlowTriggerSubscriber完成而非 cron 自己执行。反转关系cron 停止作为产品表面product surface转而成为工作流的调度服务schedule service。5.2 M1——模型映射每个遗留任务 单节点流程遗留 cron 任务映射为流程JobType::Shell { command }trigger(schedule)→code节点或专用shelltool_call受与 cron 今天相同的classify_command门控约束JobType::Agent { prompt, agent_id, model, session_target }trigger(schedule)→agent节点prompt/model 放在配置中agent_id在引擎子端口落地后映射到 Phase 5 的 agent 定义引用——在此之前定义 prompt 内联DeliveryConfig/session_target结果投递到主线程 vs 隔离流程级delivery设置或一个显式的终端notify/post节点。更推荐显式节点它在 canvas 上可见而可见正是整个迁移的意义所在delete_after_run一次性调度配置对应 §3.1 的 one-shotSchedule::At5.3 M2——双写桥dual-write bridgecron_add/cron_update的 agent 工具和 RPC 继续可用但在底层创建流程打上legacy_cron标签以保留cron_list的往返兼容。新建一律走流程路径UI 上不再直接创建 cron 任务。5.4 M3——回填迁移升级时的一次性迁移per-user把现有 enabled 的 shell/agent 任务转换为流程——id 保留在 metadata 中、next_run连续性保持、运行历史链接保留CronRun行保持可读新运行变成FlowRun。带 feature flag 和回滚窗口之后才删除遗留路径。5.5 M4——表面整合Settings → Automations 只列出流程cron 内部scheduler.rs、jobs 表保留为 tick 引擎JobType::Flow成为唯一任务类型。cron_*工具族收缩为薄别名agent 仍可调用文档措辞改为创建一个定时工作流。5.6 cron 保留什么、迁移时序cron 保留单一 tokio 调度循环、下次触发时间的持久化、catch-up 语义、scheduler_gate。这些是基础设施——工作流是建立在它之上的产品。时序M1/M2 放进 README Phase 1主要是flows侧工作M3/M4 在 canvas 与运行检查器run inspector成熟之后用户必须能看到迁移后的任务变成了什么即 Phase 3 之后。六、新触发器种类的上线顺序form one-shot/interval 调度语法糖成本低、立即有用。触发器目录 通用system分发器先用一小撮经过审查的集合播种meeting.summary_generated、notification.triaged、subagent.failed、task.ingested、document.canonicalized。chat_message必须先有不可信输入护栏。cron 迁移 M1–M2然后 M3–M4。execute_by_workflow配合 Phase 4b 的按 id 子流程、evaluation最后。每个新分发器上线时的验收清单在 tests/json_rpc_e2e.rs 中新增 E2E 测试目录条目带载荷 schema移除校验警告该 kind 从声明过但从不触发变为活的提供一个演示模板README Phase 4c。这条规则与该计划总纲docs/plans/tinyflows-integration/README.md中每个触发器种类要么真的触发、要么大声警告的 Phase 1 交付目标完全一致。七、在仓库中继续深挖的入口触发器分发的实际实现flows/bus_part_01.rsFlowTriggerSubscriber的 schedule/app_event 分支、in-flight 防重 guard、webhook 延后日志。触发器种类判定与启用警告flows/ops_part_01.rstrigger_kind_label/trigger_kind_fires。cron 任务模型与调度形态cron/types.rsJobType、Schedule的三种形态与裸字符串兼容反序列化、DeliveryConfig、delete_after_run。事件总线变体全集core/events.rsFlowScheduleTick、ComposioTriggerReceived、WebhookIncomingRequest、ChannelInboundMessage、MemoryStored、DocumentCanonicalized、NotificationIngested、SubconsciousTriggerProcessed等。需要说明的是本文§三、§四、§五、§六的内容属于设计提案设计文档以Proposal身份存在其中manual/schedule/app_event三类触发器分发与JobType::Flow的调度路径已由源码证实为已实现状态其余触发器种类与 cron 迁移各阶段仍待按 Phase 计划落地。【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenHuman 触发器体系与 cron 到工作流的统一迁移设计解析
OpenHuman 触发器体系与 cron 到工作流的统一迁移设计解析【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman本文基于仓库中的设计方案文档 docs/plans/tinyflows-integration/triggers.md 展开结合 flows/bus_part_01.rs、cron/types.rs、core/events.rs 等源码交叉验证。它回答两个问题OpenHuman 的平台能提供哪些触发器trigger以及如何迁移 cron 让一切自动化都成为工作流。一、核心论点几乎所有自动化行为都长成事件 → 条件 → 动作OpenHuman 中几乎每一种自动化行为本质上都已经是同一形态事件 → 条件 → 动作。cron 任务、Composio 应用事件、频道消息响应、潜意识subconscious升级、会议后续动作、通知分流triage……无一例外。区别只在于今天每一类都有自己的一套专用管道bespoke plumbing。设计文档给出的统一化路径是tinyflows 提供一个统一基底——每次运行都对应一张 tinyagents 状态图持久化、可观测、可审批门控而事件总线src/core/event_bus/events.rs约 130 个DomainEvent变体实际实现见 core/events.rs已经是所有这些信号流通的脊柱。终态工作流Workflow成为用户面对的唯一自动化概念。触发器只是一个播种一次流程运行的订阅subscription触发器目录trigger catalog则是事件总线的精选投影外加时间time与手动manual两个入口点。用户不再需要分别理解 cron、Composio 订阅、频道守卫等零散机制只需要理解工作流。二、引擎现状TriggerKind 声明式模型与宿主分发状态2.1 引擎已经建模的触发器种类tinyflows::model::TriggerKind是声明式的——引擎只负责声明实际由宿主host负责触发触发器种类语义manual手动运行schedule定时调度webhook外部 HTTP 回调app_event第三方应用事件Composioform带类型化输入 schema 的表单触发execute_by_workflow被另一个工作流调用chat_message频道消息触发evaluation评估/回归测试运行system系统内部事件通用事件触发器在宿主端trigger_kind_label见 flows/ops_part_01.rs为每种 kind 提供了稳定的 snake_case 线格式标识与 serde 线上判别符一一对应。2.2 宿主分发状态今天只有三种真正会触发设计文档给出的flows/bus.rs宿主分发状态表对照 flows/bus_part_01.rs 中的FlowTriggerSubscriber实现可以逐条验证Kind状态源码锚点manual✅flows_runRPC / UI Run 按钮flows/bus_part_01.rs 中spawn_run复用flows::ops::flows_runschedule✅ cronJobType::Flow→FlowScheduleTick见下节app_event✅ComposioTriggerReceived匹配toolkit trigger_slughandle_app_event大小写不敏感匹配webhook⏸ 延后Composio 即 webhook 故事Event::handle中仅tracing::debug!观察WebhookIncomingRequest明确不分发chat_message/form/execute_by_workflow/evaluation/system❌ 无分发器无对应 match 分支代码层面的直接证据是 flows/ops_part_01.rs 的trigger_kind_firesfn trigger_kind_fires(kind: TriggerKind) - bool { matches!( kind, TriggerKind::Manual | TriggerKind::Schedule | TriggerKind::AppEvent ) }该函数注释明确写道其余种类webhook、chat_message、form、execute_by_workflow、evaluation、system会被接受并保存但还没有接通分发路径——启用这类流程会导致一个永远不自运行的流程。设计文档与源码据此得出关键结论差距不在引擎能力而在宿主分发器和目录。而且system是一个自由的配置面free config surface——我们完全可以构建一个通用的事件触发器分发器而不是九个专用分发器。2.3 schedule 与 app_event 已经端到端跑通scheduleflows::ops::bind_schedule_trigger注册一个 cronJobType::Flow任务 → 调度器发布DomainEvent::FlowScheduleTick { flow_id }→FlowTriggerSubscriber::handle_schedule_tick重新加载该 flow校验仍为 enabled 且触发器类型仍是schedule然后以空载荷触发运行。对应源码见 flows/bus_part_01.rs。app_eventhandle_app_event遍历所有 enabled flows用matches_app_event做 toolkit/trigger_slug 的大小写不敏感匹配匹配成功即以事件载荷作为 run input 触发运行flows/bus_part_01.rs。由于 Composio 触发器由平台负责投递这就是第三方应用的 webhook 故事无需自己搭建隧道。并发防重FlowTriggerSubscriber内部维护in_flight: ArcMutexHashSetString用try_acquire_dispatchInFlightGuard保证同一 flow 的触发器驱动运行不会重叠guard 在Drop包括 panic时自动释放不会永久卡死后续 tick。三、提案中的触发器目录按来源组织设计文档的核心产出是一份按来源组织的触发器目录。Backing event 指会喂给分发器的现有DomainEvent变体。以下条目中标注的事件名均能在 core/events.rs 中找到对应变体。3.1 时间schedule已通过 cron 上线。把 cron 已有的丰富度全部暴露出来对应CronJob模型见 cron/types.rsCron 表达式今天的路径与间隔每 15 分钟语法糖。Schedule枚举本身已支持三种形态cron/types.rsCron { expr, tz, active_hours }、At { at }一次性、Every { every_ms }并且反序列化器兼容裸字符串0 9 * * 1自动转成Schedule::Cron。一次性One-shot在 T 时刻运行一次——cron 的delete_after_run已经建模了这一语义把它在触发器配置中暴露出来即可。窗口化调度仅工作日、静默时段——尊重scheduler_gate。Schedule::Cron的active_hours字段ActiveHours { start, end }即为此预留。3.2 手动与参数化manual、formManualRun 按钮 / RPC / agent 发起flows_run携带 input。Form一次带类型化输入 schema 的手动运行。触发器配置声明字段UI 渲染表单提交结果成为触发器载荷。这相当于 n8n 的 Form trigger能让每个工作流都获得一个可分享的迷你应用入口。实现成本低校验 在 canvas/运行对话框里生成表单。3.3 外部应用app_event、webhookComposio 触发器已上线Gmail 新消息、Slack 事件、GitHub push、日历事件……平台负责投递宿主按 toolkit/slug 匹配。剩余工作只是订阅生命周期 目录呈现。原始 webhook延后非 Composio 的 HTTP 调用方通过webhooks::ops隧道接入。列入 backlog直到有需求。3.4 对话chat_messageBacking eventsChannelInboundMessage/ChannelMessageReceived/ChannelReactionReceived其中ChannelInboundMessage已在 core/events.rs 确认存在。收到消息带过滤条件——provider/频道 id、发送者、正则或关键词、我、DM 与群聊区分。收到表情回应如在消息上打 ✅ → 归档为一个任务。护栏这些运行消费的是不可信文本——任何agent节点之前必须先做prompt_injection筛查并施加 per-flow 防抖/并发上限复用app_event分发器的 guard 泛化。3.5 Agent 与任务生命周期systemBacking eventsAgentTurnCompleted、SubagentCompleted/SubagentFailed、ApprovalDecided、TaskSourceTaskIngested、TaskRunReclaimed、ThreadGoalUpdated。示例任何子 agent 失败时把摘要贴到我的运维频道任务从任务源被摄取时做富化与打标审批被拒绝时通知发起人的线程。3.6 记忆与知识systemBacking eventsMemoryStored、MemoryIngestionCompleted、MemoryDiffComputed、DocumentCanonicalized、TreeSummarizerHourCompletedMemoryStored见 core/events.rsDocumentCanonicalized见 core/events.rs。示例文档被规范化canonicalized后生成摘要并存储每小时摘要落地后检查是否有 action items。3.7 会议与语音systemBacking eventsMeetingSessionCreated、MeetingSummaryGenerated、BackendMeetTranscript、PttTranscriptCommitted、MeetingAutoJoinTriggered。示例会议摘要生成后提取 action items → 创建任务 → 邮件通知与会者——这是旗舰演示工作流flagship demo workflow。3.8 通知与设备systemBacking eventsNotificationIngested/NotificationTriaged、DevicePaired、DevicePeerOnline/OfflineNotificationIngested见 core/events.rs。示例分流自动化来自应用 X 的通知被摄取时判定紧急/忽略、在场自动化我的手机上线时同步……。3.9 平台与健康systemBacking eventsSystemStartup、HealthChanged、HealthRestarted、AutonomyConfigChanged、McpServerDisconnected、ProviderApiKeyRejected、EmbeddingModelUnhealthy。示例自愈/维护类工作流健康度下降时运行 doctor 并报告。这类应默认require_approval关闭但通知密集。3.10 潜意识升级systemBacking eventsSubconsciousTriggerProcessed、TriggerEvaluated、TriggerEscalatedSubconsciousTriggerProcessed见 core/events.rs。潜意识域本身就是一个迷你自动化引擎evaluate → escalate。长期收敛候选一次升级的动作变成运行流程 X让工作流成为潜意识信号的执行层actuator layer而非一套平行系统。3.11 工作流到工作流execute_by_workflow、evaluationexecute_by_workflow当另一个流程通过sub_workflow/按 id 调用指向本流程时触发——支持组合和共享库流程。evaluation为 eval-harness 对某个流程的运行保留用录制的输入对工作流做回归测试与dry_run_workflow配对。四、设计一个通用事件分发器而非 N 个专用分发器针对 §3.5–3.10 这类大量system事件逐个手写handle_*像handle_app_event那样无法扩展。设计文档提出四项内容1. 触发器目录注册表新增flows/trigger_catalog.rs一个经过挑选的DomainEvent变体 allowlist暴露为触发器——每条形如{ key: meeting.summary_generated, event: variant match, payload_schema, description, risk_class }只有进入目录的事件才可订阅原始事件总线绝不整体暴露raw bus 不向用户/agent 全量开放。2. 通用分发器FlowTriggerSubscriber内每个目录化事件一个 match 分支把事件投影project成稳定的 JSON 载荷然后匹配所有启用的、触发器为kind: system, config: { event: key, filter: jq expr }的流程。可选的过滤器直接复用现有 jq 引擎tinyflows::expr对载荷求值——不引入新的表达式语言。3. RPCflows_list_trigger_catalog()喂给 Phase 3 的触发器配置 UI 和 Phase 5 的 builder agent这样会议结束时……这类自然语言提示能落地到真实的目录 key。4. 护栏非协商项在分发器内强制循环防护流程运行本身也会发出事件由流程产生事件触发的运行携带血缘链provenance chain与最大深度复用 tinyagents 的root_run_id血缘一个流程永远不能触发自己。防抖/限速per-flow 触发器令牌桶 现有 per-flow 并发 guard。载荷卫生目录投影默认剥离 PII 类字段agent节点前做prompt_injection筛查。风险分级目录条目打标签如对话事件 不可信输入类 → 强制筛查健康事件 内部类校验时在 UI 中呈现风险等级。五、cron → 工作流迁移让 cron 退居调度服务之位5.1 现状今天cron运行三种任务类型cron/types.rs::JobType见 cron/types.rsShell、Agent和Flow后者本身已只是给流程发布的 tick——JobType::Flow的注释明确说明触发时调度器发布DomainEvent::FlowScheduleTick { flow_id }实际分发由flows::bus::FlowTriggerSubscriber完成而非 cron 自己执行。反转关系cron 停止作为产品表面product surface转而成为工作流的调度服务schedule service。5.2 M1——模型映射每个遗留任务 单节点流程遗留 cron 任务映射为流程JobType::Shell { command }trigger(schedule)→code节点或专用shelltool_call受与 cron 今天相同的classify_command门控约束JobType::Agent { prompt, agent_id, model, session_target }trigger(schedule)→agent节点prompt/model 放在配置中agent_id在引擎子端口落地后映射到 Phase 5 的 agent 定义引用——在此之前定义 prompt 内联DeliveryConfig/session_target结果投递到主线程 vs 隔离流程级delivery设置或一个显式的终端notify/post节点。更推荐显式节点它在 canvas 上可见而可见正是整个迁移的意义所在delete_after_run一次性调度配置对应 §3.1 的 one-shotSchedule::At5.3 M2——双写桥dual-write bridgecron_add/cron_update的 agent 工具和 RPC 继续可用但在底层创建流程打上legacy_cron标签以保留cron_list的往返兼容。新建一律走流程路径UI 上不再直接创建 cron 任务。5.4 M3——回填迁移升级时的一次性迁移per-user把现有 enabled 的 shell/agent 任务转换为流程——id 保留在 metadata 中、next_run连续性保持、运行历史链接保留CronRun行保持可读新运行变成FlowRun。带 feature flag 和回滚窗口之后才删除遗留路径。5.5 M4——表面整合Settings → Automations 只列出流程cron 内部scheduler.rs、jobs 表保留为 tick 引擎JobType::Flow成为唯一任务类型。cron_*工具族收缩为薄别名agent 仍可调用文档措辞改为创建一个定时工作流。5.6 cron 保留什么、迁移时序cron 保留单一 tokio 调度循环、下次触发时间的持久化、catch-up 语义、scheduler_gate。这些是基础设施——工作流是建立在它之上的产品。时序M1/M2 放进 README Phase 1主要是flows侧工作M3/M4 在 canvas 与运行检查器run inspector成熟之后用户必须能看到迁移后的任务变成了什么即 Phase 3 之后。六、新触发器种类的上线顺序form one-shot/interval 调度语法糖成本低、立即有用。触发器目录 通用system分发器先用一小撮经过审查的集合播种meeting.summary_generated、notification.triaged、subagent.failed、task.ingested、document.canonicalized。chat_message必须先有不可信输入护栏。cron 迁移 M1–M2然后 M3–M4。execute_by_workflow配合 Phase 4b 的按 id 子流程、evaluation最后。每个新分发器上线时的验收清单在 tests/json_rpc_e2e.rs 中新增 E2E 测试目录条目带载荷 schema移除校验警告该 kind 从声明过但从不触发变为活的提供一个演示模板README Phase 4c。这条规则与该计划总纲docs/plans/tinyflows-integration/README.md中每个触发器种类要么真的触发、要么大声警告的 Phase 1 交付目标完全一致。七、在仓库中继续深挖的入口触发器分发的实际实现flows/bus_part_01.rsFlowTriggerSubscriber的 schedule/app_event 分支、in-flight 防重 guard、webhook 延后日志。触发器种类判定与启用警告flows/ops_part_01.rstrigger_kind_label/trigger_kind_fires。cron 任务模型与调度形态cron/types.rsJobType、Schedule的三种形态与裸字符串兼容反序列化、DeliveryConfig、delete_after_run。事件总线变体全集core/events.rsFlowScheduleTick、ComposioTriggerReceived、WebhookIncomingRequest、ChannelInboundMessage、MemoryStored、DocumentCanonicalized、NotificationIngested、SubconsciousTriggerProcessed等。需要说明的是本文§三、§四、§五、§六的内容属于设计提案设计文档以Proposal身份存在其中manual/schedule/app_event三类触发器分发与JobType::Flow的调度路径已由源码证实为已实现状态其余触发器种类与 cron 迁移各阶段仍待按 Phase 计划落地。【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考