Laya（laya）是一个开源、本地优先的 AI 通知指挥中心（Notification Command Center），它能聚合 Slack、Gmail、GitHub、Jira、Notion、Outlook、Calendar 等 10+ 平台的通知，并借助本地 LLM（如 Ollama、LM Studio）进行智能分类与摘要。但 Laya 真正的"杀手锏"是Egress 出站系统：你可以直接在 Laya 里回复邮件、批准 PR、关闭 Jira 工单，而不必切回各个平台。本文带你完整拆解 Laya Egress 出站架构的六大设计原则、Preview-Before-Send 安全执行模式，以及覆盖 10 个平台的能力矩阵，帮你理解一个"只编排、不执行"的 AI 安全执行引擎是如何设计的。

Laya 的通知卡片界面：每张卡片都带有 Done、Dismiss、Archive 等快捷操作按钮，这正是 Egress 能力的入口之一

从"只读收件箱"到"双向指挥中心"：为什么需要 Egress

Laya 在出站之前，已经非常擅长入站（Ingestion）——把 9+ 个平台的通知汇总成一个统一的 AI 处理信息流。但问题在于：看到 Gmail 的邮件提醒后，你还得打开 Gmail 去回复；看到 Jira 工单提醒后，还得打开 Jira 去评论。这让 Laya 沦为一个"只读通知浏览器"。

Egress 系统要解决的就是这件事：让你在 Laya 内部直接对任意平台执行操作，无论是点击卡片上的按钮，还是用一句自然语言"批准 PR 23"。

Laya 的 AI 聊天面板：所有 Egress 出站能力都可以通过自然语言对话触发，聊天是一等控制面

六大设计原则：Laya 只编排，从不执行

打开架构文档 engine/docs/egress-architecture.md，你会发现 6 条不可妥协的设计原则，这是整个 Egress 系统的灵魂：

一个绝妙的类比：LLM 是大脑，Laya 是脊髓，n8n 是手和脚。这种分层让 Laya 保持轻量、可移植，并且专注"智能"而非"干活"。

Egress 模块结构：一个极简的公开 API

整个 Egress 模块位于 engine/laya/egress/，Engine 对外只看到 6 个函数（定义在 engine/laya/egress/init.py）：

• execute()—— 执行出站动作（唯一入口）
• preview()—— 预览动作会做什么，但不真正执行
• get_capabilities()—— 查询某平台支持哪些动作
• list_connections()/connect()/disconnect()—— 连接与凭证管理

内部则划分为清晰的层次：

engine/laya/egress/ ├── models.py 数据模型：EgressRequest / EgressResult / EgressPreview ├── router.py 路由：把请求分发给最佳执行后端 ├── connections.py 连接代理：统一凭证管理 ├── registry.py 平台能力注册表（platform → action 映射） ├── tools.py 聊天驱动的 LLM 工具定义 ├── tool_handlers.py 工具执行处理器（preview → confirm → execute） ├── backends/ 可插拔执行后端 │ ├── n8n.py n8n webhook 执行器（主后端） │ └── smtp.py SMTP 邮件兜底后端 └── platforms/ 10 个平台各自的适配器 ├── gmail.py ├── jira.py ├── github.py ├── bitbucket.py ├── slack.py ├── linear.py ├── notion.py ├── outlook.py ├── calendar.py └── smtp.py

每个平台的数据（能力、字段映射、终结事件、草稿 Schema）都封装在自己的 engine/laya/egress/platforms/ 文件里——新增一个平台 = 写一个新文件，而不是修改十几张全局表。

Preview-Before-Send：安全执行引擎的核心

这是 Laya Egress 最值得学习的设计：任何出站动作在真正执行前，必须先展示预览并获得用户确认。整个流程分三步：

① Preview（预览）—— 聊天工具或 UI 调用egress.preview()，返回人类可读的摘要（如"向 sarah@co.com 发送邮件，主题 Re: Nav redesign"）、结构化详情、警告列表（如"这将发送给 5 位收件人"）和影响等级（low / medium / high）。预览路径会走与执行完全相同的 payload 富化逻辑，保证"你看到的"就是"将要发送的"（见 engine/laya/egress/router.py 的build_preview()）。

② Confirm（确认）—— 系统为预览请求生成一个签名的一次性执行令牌（execute_token），有效期仅5 分钟，用 HMAC 签名防止伪造。用户口头或点击确认后，LLM 才调用confirm_egress提交令牌。令牌过期、已用或签名不符，一律拒绝执行（实现见 engine/laya/egress/tool_handlers.py）。

③ Execute（执行）—— 令牌校验通过后，请求才真正路由到 n8n 或 SMTP 后端执行，结果（成功链接或错误信息）回传给用户。

这套机制的价值：AI 永远不会在用户不知情时发出邮件、合并代码或关闭工单。即使 LLM 被诱导产生了错误意图，没有用户的显式确认，任何高影响操作都过不了第二道门。

10 平台能力矩阵：从回邮件到合并 PR

Laya Egress 目前覆盖 10 个平台，每个平台支持的动作由能力注册表统一管理。以下是核心能力一览（完整矩阵见 engine/docs/egress-platform-matrix.md）：

能力注册表（engine/laya/egress/registry.py）同时服务于三个消费者：Stager（生成卡片上的建议动作）、卡片 UI（决定显示哪些按钮）、聊天 LLM（告知它有哪些动作可用）。这意味着三处永远一致——平台没连接，按钮和 LLM 都不会出现对应能力。

聊天 = 一等控制面：用自然语言驱动出站

Egress 系统提供了一组 LLM 工具（定义在 engine/laya/egress/tools.py，设计细节见 engine/docs/egress-chat-tools.md）：send_email、comment_on_ticket、transition_ticket、create_ticket、pr_action、send_slack_message、open_compose、confirm_egress。

四种典型交互模式，新手一看就懂：

1. 直接命令—— "批准 PR 23" → LLM 找到 PR → 展示预览 → 你确认 → 执行
2. 智能纠错—— "关闭 PAY-89"（不存在）→ LLM 模糊搜索后建议 PAY-98，绝不瞎猜
3. 打开编辑器—— "回复 Sarah 的邮件" → LLM 打开预填好上下文的撰写编辑器，由你审阅后发送
4. 跨平台组合—— "关闭 PROJ-123 并在 Slack 通知 Sarah" → 两个预览一起展示，一次确认，顺序执行

全局撰写（Compose）编辑器：顶部可切换 Gmail、Outlook、Jira Cloud、Notion、GitHub、Bitbucket、Linear 等平台，表单字段随平台动态变化，还支持 AI Assist 生成草稿

连接代理（Connection Broker）：一键搞定凭证

最让人头疼的从来不是"发一封邮件"，而是在哪里配置凭证。Laya 的 Connection Broker（engine/laya/egress/connections.py，设计文档 engine/docs/egress-connection-broker.md）让用户只在 Laya 设置页操作一次，凭证按三种流程流转：

关键点：用户永远不需要打开 n8n 面板。不同 Space 还可以使用同一平台的不同凭证，做到多账号隔离。

后端路由策略：n8n 优先，SMTP 兜底

路由器（engine/laya/egress/router.py）按优先级为每个请求选择执行后端：

1. SMTP 后端—— 平台为smtp时直接使用。这是唯一在 Laya 进程内执行的通道，因为通用 SMTP 节点无法可靠处理邮件线程头（In-Reply-To）、各家邮件服务商的怪癖和附件编码
2. n8n 后端（主路径）—— 解析空间感知的 webhook URL，构建 payload 后 POST 到对应 executor 工作流，带重试逻辑（engine/laya/egress/backends/n8n.py）
3. MCP 后端（规划中）—— 未来可为配置了 MCP Server 的平台提供可选执行路径

n8n 侧的执行工作流全部以 JSON 形式内置在 n8n/workflows/（如github-executor.json、jira-executor.json、slack-executor.json等），安装后由 Laya 自动导入。对 Engine 而言这一切完全透明——它只调用egress.execute()，不知道也不关心邮件究竟走了 n8n 还是 SMTP。

关键文件速查表

总结：值得借鉴的三个设计决策

Laya Egress 架构给"AI 能代表我操作外部系统"这个命题提供了一个务实而安全的答案：

1. 编排与执行彻底分离—— Laya 只做决策和路由，n8n 做体力活，LLM 做智能，职责清晰、各自可替换
2. Preview-Before-Send 成为默认路径—— 签名令牌 + 5 分钟 TTL + 显式确认，让"AI 误操作"从架构上变得不可能
3. 能力注册表单一事实源—— 卡片按钮、LLM 工具、Stager 建议全部从同一份能力清单派生，永远不出现"按钮能点但后端不支持"的尴尬

对于想给本地 AI 应用添加出站执行能力的开发者，这套 engine/laya/egress/ 模块就是一个可以直接参考的完整范例：一个约 6 个公开函数、10 平台适配器、双后端路由 + 预览确认机制的轻量级安全执行引擎。