让公司的每一个智能体，都可被看见、调用和改进。

00 · VISUAL OVERVIEW

先用六张图看懂 Multiflow

不用先理解所有模块。只要记住：公司组织能力，项目承载工作，智能体负责执行，所有过程沉淀为可复用的组织记忆。

01 · NORTH STAR

不是另一个聊天工具，而是智能体组织系统

智能体可以运行在员工电脑、公司服务器或云端；Multiflow 不替代模型与编码工具，而是提供统一的组织、调度、工作记录和治理层。

02 · CONTROL PLANE

公司级智能体控制面

管理者看到的是稳定的“能力与责任”，底层运行位置和工具可以变化。项目是组织边界，智能体是可调用责任单元，会话是一次具体执行环境。

关键抽象：项目归类能力；智能体承诺能力；会话承载上下文；issue 承载可审计工作。项目本身也是一个可对话入口——问项目现状由服务端直接作答，不需要任何执行端在线。

03 · SESSION MODEL

智能体只有一种，开放范围决定协作边界

系统不再把“协作智能体”和“普通智能体”建模为两种对象。智能体是稳定的能力身份，它的开放范围决定谁能调用；会话只是可替换的执行端，不是另一类智能体。对话可以指向智能体，也可以直接指向项目——项目前台由服务端用项目数据作答，不需要任何智能体在线。

产品界面只保留一个“智能体工作台”：会话是智能体下面的运行上下文；“管理”负责配置身份与权限，不再与“会话”作为两个平级产品概念竞争。

项目前台是会话的第二种目标：target_kind=project 的会话没有智能体、没有执行端，服务端读 /api/projects/{id}/team 与 /api/projects/{id}/digest 直接作答。它要回答的是“这个项目现在怎么样、卡在哪、该找谁”，因此工作区里一个智能体都没有时也必须可用；只有“派活”这一类意图才继续走 issue 与调用管道。数字、状态和人名全部来自服务端查询结果，模型只被允许改写一句不含任何事实的开场白；模型不可用、超时或在改写里写出数字时，前台退回关键词分类与确定性文案，答案照常送达。

04 · REMOTE INVOCATION

网页调用、实时接管，也能恢复退出的本地会话

真正的执行始终发生在员工 Mac 或服务器的 PTY 中；云端负责授权、排队、固定动作与瞬时双向终端中继。Web 与 macOS 客户端都能创建首次接入云端机器的一次性接入码，也会为已接入机器生成不含接入码、可长期保存的 multiflow session start 新建与恢复命令；两端都能按项目角色调用在线云端智能体并接管实时终端。项目角色明确绑定执行端，不再按智能体名称猜测本机文件夹。调用不再只有“点名某个智能体”一个入口：向项目前台提出一件要动手的事，服务端会自己选执行端。

本地 PTY 是唯一事实源：浏览器关闭或网络断开不会终止 Claude Code；执行端仅保留 2 MiB 内存回放用于重连，服务端不持久化终端内容。每次调用优先关联用户选择的已有 issue；未选择时自动创建同项目的轻量工作记录，并随调用进入 todo、in_progress、in_review / blocked / cancelled，结果沿同一来源链归档。Web 与 macOS 使用页面内多终端工作台而非阻塞弹窗，同一终端重复点击只切换标签，不同 Agent 可同时保持连接。服务器从受信代理链观察云端执行端 IP，客户端报告 Mac 机器名；两者仅在 owner 的私人会话列表和终端标题中展示。

已运行的 Claude Code 进程不能热插入 MCP channel；先退出旧进程，再通过 --continue 或 --resume=<会话名称或 ID> 恢复保存的上下文。

个人会话默认私有；用户明确开放后，具有该智能体调用权的成员才能查看和接管当前在线终端。目录、密钥、完整历史和离线终端记录仍不对组织公开。

前台不会因为“没有在线执行端”而报错：只有在线的本地会话能立刻开工，其余情况一律落成项目里的 issue，由 issue 指派把工作交给带运行时的智能体队列。派活入口有三个，边界不重叠：项目前台面向人，一句话进来、自动分诊与路由；小队工作流面向系统，版本化、可返工、由工作流独占阶段流转；delegate_work 面向智能体，是智能体之间的一次性求助。前台可以让工作进入 issue 与调用管道，但不参与流程内部调度——小队工作流没有因为前台而改变。

交接和委派是两件事，权限也不同：delegate_work 要跑对方的机器、花对方的额度，所以要对方授权，对方离线就失败；handoff_work 转移的是这件事的归属，只需要同一个工作区，对方离线或没给你调用权时降级成「已记录并指派、对方上线自取」，绝不因此丢掉工作。交接内容始终落在 issue 上而不是走智能体私信——这样同事本人也看得见，重复提交不会送两次，链路超过三跳会被拦下来要求人来接。

路由表只有一份：get_project_team 和项目前台读的都是服务端的 /api/projects/{id}/team，谁可达、谁有调用权、谁在跑几件事由服务端判定，客户端不再各算一遍。

04A · MOBILE COMPANION

手机是智能体的随身调度台，不复制桌面终端

iOS 与 Android 共用一套 Expo / React Native 业务层。管理者可以按项目找到自己有权调用的 Agent 角色，关联 Issue 后下发工作并实时查看队列、阶段和结果；真正的终端、目录与代码执行仍留在员工机器或云端 Runtime。

• 底部主导航只保留对话、需求、项目与我的；复杂配置和批量管理留在 Web / Desktop。
• 智能体目录展示当前用户可调用的统一智能体；“我的执行端”单独管理本机会话，不把会话当作第二种智能体。
• 移动端复用 queued / delivered / running / completed / failed / cancelled 六态、权限模式和幂等键，WebSocket 实时更新并以 30 秒轮询降级。
• 切换 Tab 不重建核心页面；草稿、筛选和滚动状态按工作区隔离。
• 对话文本、附件与 mention 按用户 / 工作区 / 会话持久隔离；停止恢复先排队、成功发送后才消费服务端记录。
• WebSocket 负责实时 patch，前台恢复与重连只做有界补拉，弱网不静默丢消息。
• 双端记录首屏、Tab 切换、会话/需求打开和长帧指标，不采集正文、邮箱或密钥。

05 · ISSUE EXECUTION LOOP

需求、决策、执行和验收留在同一个闭环

智能体一次只租赁一份工作，阶段性回报后继续推进。任务不是一条消失的 prompt，而是拥有上下文、证据、状态与责任人的长期记录。

06 · DATA & LEARNING LOOP

从“做过”走向“知道如何做得更好”

记录不是为了监控员工，而是让组织回答：什么工作正在发生、哪里卡住、成本花在哪里、哪一种智能体与工作方式更可靠。

07 · API-FIRST VERIFICATION

所有产品操作都应可由 API 或 CLI 验证

界面是使用入口，不是唯一入口。每个功能先有可脚本化边界，再通过界面承载体验，调试与回归不依赖截图和人工点击。

• 生产环境默认只读验证；写操作只允许在隔离工作区或隔离数据库中执行。
• 文件、长轮询与实时事件必须通过真实 transport 测试，不能只从 handler 单测推断。
• CI 守卫新路由具备脚本化访问方式；UI 验证是补充，不是替代。
• 每次交付记录准确的 API/CLI 验证命令与结果。

08 · DESKTOP PATCH DELIVERY

高频小修复，也必须经过完整的签名交付链路

Multiflow 不向已签名应用热塞代码。每个补丁仍是完整签名、公证、可追溯的版本，但通过 blockmap 只传输变化部分；更新元数据最后原子切换，发布中断不会影响正在使用的旧版本。

• 更新传输使用 Multiflow 自有域名，不依赖 GitHub API 可用性。
• ZIP blockmap 降低小版本下载量，但应用签名和公证边界保持完整。
• 版本化文件不可变，同版本内容冲突时发布立即失败。
• 下载页与客户端读取同一稳定清单，避免“可下载版本”和“可更新版本”分叉。

09 · TRUST BOUNDARIES

集中管理不等于失去个人环境的控制权

默认最小暴露、显式授权、危险操作升级人工审批。组织获得可调用性与可追踪性，员工保留对机器、会话和权限策略的控制。

10 · LIVING DOCUMENT CONTRACT

这份 HTML 本身也是产品接口

页面正文服务于人，页面末尾的 JSON 服务于系统。两者必须在同一次变更里更新，避免“图里一个世界、代码里另一个世界”。