用途：通过 MCP 在 PostHog 中编写、修改、测试、启用并监控工作流。工作流是一个有向图，由动作节点（actions）和边（edges）组成，且只有一个触发节点。对外统一称“workflow”，HogFlow 只是内部代号。
组装图：节点与边必须符合 references/graph-schema.md 的严格结构，否则能保存但会破坏编辑器视图。函数节点不要猜测模板，先调用 cdp-function-templates-list 与 cdp-function-templates-retrieve 查看实时目录和必需输入。用 workflows-create 创建草稿，此时不执行。
测试：workflows-test-run 逐步运行，从第一步开始（省略 current_action_id 或指向触发节点），传入符合触发真实载荷的示例 globals（{event, person, groups}）。status=skipped 表示该载荷不会触发；伪造载荷要改载荷，来自真实运行则说明过滤条件有误。结果中的 nextActionId 作为下一次的 current_action_id，逐步走到结束；delay 节点跳过；异步副作用默认被模拟，除非 mock_async_functions=false。用 workflows-logs 查看每步轨迹。
编辑：用 workflows-patch-graph 做基于 id 的有序原子操作（update_action 为深合并），比整体替换更小；actions/edges 只能走此接口。workflows-update 只处理 name、description、exit_condition、conversion、trigger_masking、variables 等顶层字段。每次编辑后重测受影响路径。邮件内容用 workflows-patch-action-email，库模板用 workflows-patch-email-template。
启用：workflows-enable 需用户明确同意，之后事件、Webhook 或手动触发才会对真实用户生效。批量和定时工作流需 workflows-run-batch 或 workflows-schedule-create。
监控：从 workflows-global-stats 到 workflows-stats、workflows-list-invocations、workflows-get-invocation、workflows-logs 逐层下钻。
活跃工作流：编辑先写入草稿，用 use_draft=true 测试；workflows-publish 先预览影响并取得 confirm_token，再由用户确认后发布，409 表示草稿已变，400 表示令牌过期（15 分钟）。workflows-discard-draft 可丢弃草稿。回滚用 workflows-list-revisions、workflows-get-revision、workflows-restore-revision 复制到草稿后再走发布流程；rollback 无法撤销已发生副作用和已提前的唤醒时间。
限制：字节码、顶层 trigger、billable_action_types、version、id、created_* 由服务端管理，不要手写。不支持行为定向（如“过去 M 天内至少做了 N 次事件”），批量受众只支持人员属性与静态/属性型人群，事件过滤器会被丢弃或拒绝。模板快照是单向的：改库模板不影响已引用步骤。延迟改动的重排是渐进的，发布后短时间仍有停留属正常。
类别：other-ai-tools（资料仅说明为 PostHog AI 插件工作流能力，未提供更具体的通用分类依据）。