Home / 工作原理
How it works
用 Bridge v1
连接业务面与 AI 面。
业务系统仍是唯一的正本。AI 面（DSH）只保存会话与记忆，需要时以本人委托读取业务数据。两个面通过带版本的 HTTP 协议 Bridge v1 和机器可读的 manifest 连接。
🏢 业务系统
- 业务数据 · 员工与角色
- 规则 · 审批 · 金额 · 审计
- 通知的接收人
Bridge v1
＋ manifest
OpenAPI 3.1
🤖 AI 面
- 会话 · 长期记忆
- 自动任务 · 定时报告
- 9 个插件
💬 聊天
- Slack
- LINE
- Teams 等
业务面持有
业务数据、员工与角色、规则、审批、金额、审计、通知的接收人与本人的通知设置、AI 员工的人设（版本与审计）、操作手册的索引。不保存会话。
AI 面持有
会话、AI 员工的设置（人设与可用工具）、聊天连接、自动任务台账、长期记忆。不保存业务数据，需要时通过工具读取最新值。
Five layers
五个层次
依赖方向为 L5 → L3 / L2 → L1。L3 不认识 L2，只通过 HTTP 通信，所以业务系统不必是 Node.js。
| 层 | 组件 | 作用 |
|---|---|---|
| L1 protocol | @dsh-bridge/protocol | Bridge v1 的 OpenAPI 3.1、manifest 与事件的 JSON Schema、校验库、bridge-validate 命令行、一致性测试（52 项） |
| L2 server-kit | @dsh-bridge/server-kit | 业务系统侧的 Node.js 组件：绑定码、委托、outbox、通知、审批、报告、提案、manifest 下发、个人信息检查等。业务方只写 hooks |
| L3 AI 面 | @dsh-bridge/dsh-core + 9 plugins | 应用注册、业务 API 客户端、委托缓存、工具组件、AI 秘书的消息框架、发送检查 |
| L4 Web | gateway · web-kit | 从业务 Web 的 BFF 到 AI 面的认证网关，以及 React 画面组件 |
| L5 adapter | 你的系统 | manifest、hooks（或现有 API 的别名）、手写的工具与文案模块、审批与提案画面 |
Main flows
主要流程
① 业务变化 → 通知（基于规则，不使用模型）
01业务数据与事件在同一事务中写入（outbox）
02拉取：至少一次 · 重试 · 死信
03业务系统确定收件人
04合并发送 · 免打扰时段 · 渠道优先级
05以 AI 秘书文案发到本人单聊
② 提问与委托（AI 员工以本人权限读取）
01员工在聊天里提问
02按发送方查询身份（未绑定则什么也不返回）
03取得委托：AI 允许列表 ∩ 角色，最长 5 分钟
04只读取本人可见的范围
05在本人单聊中回答
③ 提案与审批（由人决定，只有一次）
01AI 通过读取确认情况
02提案：POST /proposals → pending_review
03人来采纳或驳回（一次）／审批卡片一键决定
04只有采纳时业务系统才写入
④ 自动任务与定时报告
01事件或时间唤醒 AI 员工（playbook）
02以该类工作指定员工的权限读取
03必要时提出提案
04给收件人发一条（固定文案）· 发送前检查
Principals
以谁的身份调用，能做什么
| 主体 | 是谁 | 能做的事 |
|---|---|---|
| 服务 | AI 面（DSH） | 身份查询、发放委托、事件、确定通知对象、审批卡片、manifest。不能读取业务数据 |
| 委托 | 代替员工工作的 AI 员工（最长 5 分钟） | 只能做该员工角色允许的读取与提案。写入、审批、确认返回 403 |
| 员工会话 | 使用业务 Web 的本人 | 生成绑定码、管理自己的绑定、通知设置、采纳提案、审批 |
| BFF | 业务 Web 的服务端 | 助手票据、附件转换、登记本人的机器人 |
🧩
一个 AI 面服务多个系统
会话、记忆、自动任务、通知按应用隔离，令牌与工具也不跨应用。
🧱
无状态的 Bridge v1
会话、限流、绑定码、委托、事件都存放在 PostgreSQL，业务侧可以水平扩展。
🔐
隔离运行的 AI 面
AI 面运行在隔离的目录中，管理令牌不会出现在浏览器里。