让每一个 IT 系统，
成为会思考、会行动的
AI 员工的职场。
Biz Assistant 为过去只会“等待”增删改查的业务系统加上一座小小的“桥”。于是 AI 员工诞生了：它在每位员工自己的聊天里通知、请托、起草、记忆。无需改写业务逻辑，做决定的始终是人。
LEGACY SYSTEMCRUD
| 订单号 | 状态 | 发货期限 |
|---|---|---|
| A-10231 | 已受理 | 11/12 |
| A-10232 | 已受理 | 11/12 ⚠ |
| A-10238 | 待确认 | 11/12 ⚠ |
| A-10240 | 已发货 | 11/10 |
| A-10244 | 已受理 | 11/11 ⚠ |
v1
有 3 笔订单已超过发货期限。
▶ 请在订单画面确认发货日期。
去确认
审批已等待超过 2 小时，已请负责人处理。
Biz Assistant Framework 是什么
一个把现有或新建业务系统变成“AI 员工职场”的开源框架。给业务系统加一座小小的“桥”（Bridge v1），AI 员工就会在每位员工自己的聊天工具里通知、请求、起草和记忆。决定权始终在人。
| 做什么 | 把业务变化通知给相关员工、请求审批、起草文档、定时汇报、记住约定事项 |
| 在哪里 | 每位员工自己的聊天工具（Slack、LINE、Microsoft Teams、企业微信、飞书等 12 种） |
| 安全原则 | AI 只能提议。确定、审批和支付由人在业务系统中完成。只能读取本人权限范围内的数据 |
| 接入方式 | 不改写业务逻辑。增加读取与提议接口、manifest 和收件人规则，用 52 项一致性测试验证 |
| 许可证 | Apache License 2.0（开源，商用免费）。源码：GitHub 上的 ITC-cloud-soft/biz-ai |
| 提供方 | 株式会社アイテーシー（东京），同时提供导入咨询，以及由 AI 承担运维保守的姊妹产品“运维 AI Bot” |
IT 从“记录的工具”，
变成“一起工作的同事”。
信息早已在系统之中。缺少的，是把它送到人面前、让事情动起来的机制。
记录的时代
台账与录入。人输入数据，人去查找。
画面的时代
增删改查与业务逻辑。人打开画面、确认、追着负责人跑。
智能的时代
AI 员工盯着、通知、请托、起草、记忆。人在聊天里做决定。
BEFORE —— 等待的系统
- 没人打开画面，什么都不会发生
- 不去看，就发现不了重要的变化
- 为了审批、提交追着负责人跑
- 收集数据写报告
AFTER —— 会思考、会行动的系统
- AI 员工先一步发现变化
- 只送达相关的人，就在他自己的聊天里
- 审批在聊天里一键完成
- 早晚各收到一份汇总
会思考。会记忆。会主动行动。
AI 员工是在每位员工权限范围内工作的 AI 助手。
思考
在本人权限范围内读取业务数据，分辨当下要紧的事，起草计划书和修正方案。
记忆
记住每个人的偏好和待办、组织的流程与约定、之前的对话。不记个人信息。
主动行动
盯着变化，只通知相关的人，请合适的人处理，没进展就催促，并按时汇总。
AI 负责读取与提案。确认、审批、金额的决定，始终由人来做。
有 AI 员工的一天。
需要处理 2 件，供参考 1 件。
原定 09:00 开始的作业还没有开始。
请确认 10 月份的账单。
审批
有 2 条 AI 提案，请决定采纳还是暂缓。
画面均为虚构示例。
业务系统仍是唯一的正本。
AI 员工在桥的另一边工作。
用带版本的小型 HTTP 协议 Bridge v1，以及机器可读的自我介绍 manifest，连接业务面与 AI 面。
🏢 业务系统
- 业务数据 · 员工与角色
- 规则 · 审批 · 金额 · 审计
- 通知的接收人
Bridge v1
🤖 AI 面
- 会话 · 长期记忆
- 自动任务 · 定时报告
- 9 个插件
💬 聊天
- Slack
- LINE
- Teams 等
业务变化与业务数据在同一事务中记录
发给谁，由业务系统决定
AI 员工以本人权限读取并提出方案
人在聊天中决定，结果记录在业务系统里
安全不靠提示词，
靠代码与配置来守护。
由人来决定
AI 的写入只能是“提案”。采纳与审批由人完成，且只有一次。
不超出本人权限
AI 的权限 ＝ 允许 AI 的操作 ∩ 该员工的角色。令牌最长 5 分钟。
收件人由业务系统决定
AI 不选择收件人，只送达给相关的人。
不携带个人信息
事件只含 ID、日期、件数。发送前检查，或使用固定文案。
默认关闭
群聊、无人值守的处理、发送目标，默认都是关闭的。
52 项验证
承诺由一致性测试来证明。发布要求 52 / 52，且没有跳过项。
旧系统也好，新系统也好。
无需改写业务逻辑，但也不是一行不改就能接入。首次诊断会列出需要补充的内容。
要加的只是“桥”
- 读取业务数据的接口，以及接收 AI 提案的接口
- manifest（系统的自我介绍）
- 员工绑定自己的聊天账号（用系统自己的登录）
- 由业务系统决定收件人的规则
- 状态变化与事件在同一事务中写入
- 审批规则 · 定时报告（只有件数）
生来就与 AI 员工一起工作
- 基于 server-kit 开发，“桥”的部分由组件提供
- 你只写业务、hooks、manifest 和画面
- 可以参考示例业务系统的结构与写法
const bridge = await createBridgeApp({ manifest: { file: './bridge.manifest.yaml' }, store, serviceToken, bffSecret, hooks: { employees, authenticate, isSessionLive, recipientsFor, approvals, proposalKinds, reports, piiScan }, })
不改代码，把桥放在外面
- 登录可以从外部验证（OIDC / SAML）
- 可以以本人身份调用 API
- 提交后会通知变化（webhook / CDC）
- 有审批与写入的 API
规范是 OpenAPI。承诺由测试来证明。
用 manifest 描述系统，接上 hooks，用 52 项一致性测试来验证。源码已在 GitHub 公开，并附带供 AI 编程智能体使用的导入 skill。
bridge: 1 system: { id: order-desk, name: Order Desk } roles: manager: { delegation: propose } staff: { delegation: read } events: order.overdue: payload: [orderId, dueDate, count] # IDs, dates, counts only notify: { template: order.overdue } tools: - name: order_list_overdue http: GET /api/orders/overdue access: read roles: [manager, staff]
$ node --test packages/protocol/conformance/http.test.mjs ✔ P1–P6 protocol hygiene ✔ L1–L10 link yourself only · B1–B4 personal bots ✔ D1–D7 delegation = allow-list ∩ role ✔ S1–S5 assistant tickets bound to the session ✔ PR1–PR3 · A1–A4 AI proposes, people decide ✔ E1–E4 · N1–N3 · R1–R3 · M1–M3 no personal data 52 passed, 0 known gaps, 0 skipped
团队常用的聊天工具，就是 AI 员工的职场。
蓝框：组织机器人 ／ 全部：员工自己绑定的个人机器人 ／ email 仅用于通知
而且，
系统也会自己成长。
运维 AI Bot 守护、修复并培育系统本身：受理问题、调查、修复与测试、提交 PR、经审批后发布，并记住学到的东西。生产环境始终需要人工审批。
越用越聪明
常见问题
现有系统的代码可以完全不改吗？
不需要改写业务逻辑，但需要加一座“桥”（读取与提案的接口、manifest、本人的聊天绑定、收件人规则、事件记录等）。首次诊断会列出要加的内容和工作量。
AI 会擅自审批或付款吗？
做不到。AI 的写入只是“提案”，确认、审批、付款和金额的决定都由人在业务系统中完成。这由协议和测试来保证。
支持哪些聊天工具？
Slack、LINE、Microsoft Teams、WeCom（企业微信）、微信、飞书等。员工自己绑定的“个人机器人”支持 12 种聊天工具。email 只用于通知。
个人信息如何处理？
业务变化的记录（事件）和通知只包含 ID、日期、件数，发送前还会检查。AI 员工的记忆中也不保留个人信息。