BizPro 是一个多组织（多租户）的低代码业务操作系统。组织用它来定义自己的业务记录结构、用 BPMN 2.0 为流程建模、安装并调整打包好的应用模块，并在网页端和移动端运行由此形成的系统。它的关键特征是：系统的结构 —— 数据定义、流程图、权限 —— 不会被编译掉，而是在运行时保持可见、可改。正是这一点，使人工审阅和 AI 参与在实践中成为可能。

• 数据可以改 — 字段、表单和记录类型属于配置，不是一次发版。上午加的字段，下午就能用。
• 流程看得见 — 工作用 BPMN 2.0 图来描述，管理者和引擎读的是同一张图。这张图就是流程本身，不是流程的示意图。
• 不是从空白页开始 — 库存、服务作业、申请审批、档案、配送等等，已经以应用模块的形式存在。装上再调整，而不是从零开始。
• 一条记录，处处可用 — 办公室的界面、手机、公开链接和报表读的都是同一条记录。系统之间不做复制，也就没有过期的数据。
• 边界是开放的 — 外部系统作为工作流中的一个步骤接入。其他组织则通过商务市场和跨组织流程接入。
• 为“人 + AI”而建 — AI 可以在几分钟内草拟出一个人要花几天才能拼起来的东西 —— 而它产出的是一张图、一份表单和一组权限，人可以读、可以试、可以改。

核心目标

• 让组织不经过开发周期就能定义和修改自己的业务数据结构。
• 直接由 BPMN 2.0 模型执行业务流程，而不是由“看起来像它”的代码来执行。
• 把重复出现的业务能力打包成可安装、可调整的应用模块。
• 通过跨组织流程与商务市场，把工作延伸到单个组织之外。
• 让系统足够可读，使人 —— 或 AI —— 能看清它在做什么并安全地改动它。

服务对象

• 需要贴合自身实际做法的运营系统的组织。
• 为工作建模、并且要求“建成什么样就执行成什么样”的业务分析师与流程负责人。
• 在平台之上而非从零开始构建模块与集成的开发者。
• 通过结构化、可审阅的产物来生成和修改业务应用的 AI 代理。

六个部分，只有放在一起才成立。数据给工作以形状，流程给它以顺序，模块把它打包，商务市场把企业彼此连接起来，而人和 AI 完成工作。整件事的要点很简单：企业靠改进流程而成长 —— 所以这个平台把流程做成了真正可以被改进的东西。

• 动态业务数据 — 记录类型、字段、表单和列表在平台里定义，而不是编译进代码。一个定义可以是全平台通用的、共享的，或者只属于某一家组织 —— 而同一个定义会同时驱动网页表单、移动表单、列表、搜索索引和报表。
• BPMN 2.0 流程引擎 — BPMN 2.0 就是国际标准 ISO/IEC 19510。流程用它建模，引擎完全照着画出来的样子运行。因为这是公开标准，一张图就能充当协议：两家公司 —— 或两套系统 —— 在图上达成一致，就等于约定了工作如何在彼此之间流转。人工任务、系统调用、定时器、网关、异常都属于同一个模型，且每一步都留下记录。
• 应用模块 — 一个应用模块就是一整块业务 —— 它的数据定义、流程、权限、界面、报表和移动端一起打包。组织把它打开即可。模块可以按组织调整，而不需要分叉出一个副本。
• 商务市场 — 企业发布自己能提供什么，其他企业找到它、询问、下单。与信息列表网站的区别在于：商务市场不只是介绍两家公司认识，而是给了它们一条共同工作的流程 —— 通常横在两套系统、两个收件箱之间的摩擦由此消失。
• 网页 + 移动 — 网页端用来搭建系统和管理运营。移动端承担离开办公桌的那部分工作 —— 审批、任务收件箱、表单、扫码、拍照、定位 —— 并且在没有信号的时候照样能用。
• 人 + AI — AI 能力是长在平台里的，不是外挂上去的：它用的是和人一样的定义、图和模块。因此它产出的东西可以当成一张图和一份表单来审阅，而不是当成代码差异来读。

网页端是搭建、配置和管理系统的地方。移动端承担发生在别处的工作 —— 在现场、在车上、在店面、在客户的楼里。它们用同一个定义渲染同样的表单，所以一次做好的表单在两边都能用；而且在有网络之前，输入的内容会先留在设备上。

• Flutter，一套代码 — 移动端用 Flutter —— Android 与 iOS 出自同一套代码，并共用一个组件包，因此所有 BizPro 应用观感一致。
• 表单原生渲染 — Form.io 渲染器已经做好：平台上定义的表单在应用中以原生控件绘制。它不是套了个壳的网页，也不需要做两遍。
• 该原生的地方就原生 — 当某项作业依赖设备而不是表单 —— RFID 手持机、持续扫描、后台定位 —— 那部分可以做成原生，并且仍然调用同一套服务。
• 离线也能干活 — 没有信号时做的操作会存在设备上，等网络恢复后再发送，并有防止重复发送的保护。
• 发挥手机真正的长处 — 扫码、拍照、记录位置、用手指签名 —— 这些恰恰是在办公桌前很别扭的部分。
• 真正有用的任务收件箱 — 审批和分派到的任务会送到手机上，流程不会为了等某人打开笔记本而卡上三天。
• 易于定制，也能在上面继续开发 — 标签页、主题、品牌以及显示哪些模块都属于配置。再往下就是普通的 Flutter 代码 —— 新增一个页面、一条流程，乃至一个完整的行业应用，都是常规开发。
• 一个应用，覆盖全程 — 找到一家企业、与它沟通、向它下单，再执行这笔订单带来的工作 —— 商务市场、会话、流程和任务收件箱是同一个应用、同一份数据，而不是四个产品拼在一起。

每家企业都在记录：申请、资产、合同、货物、走访、事故。要记录哪些内容从来没有定论 —— 监管方要求再加一个字段，新业务需要另一份表单，某个分支机构的做法和别人不一样。在 BizPro 里，记录的结构本身就是数据，所以改动它是一次配置，而不是一个开发项目。

• 灵活的表单 — 通过选择字段、分区、规则和校验来搭表单。同一个定义会在网页端和移动端各自渲染出来。
• 可调整的结构 — 增加、改名或停用一个字段，不需要数据迁移，也不需要停机。已有记录保留原样。
• 可按组织定制 — 一个全平台通用的定义，仍然可以被某一家组织扩展 —— 额外的字段、自己的表单、自己的规则 —— 而不需要分叉任何东西。
• 立即可用 — 新字段一旦存在，列表、筛选、搜索、工作流、报表和移动端就都能用到它，不必逐处接线。
• 灵活，但不是没有结构 — 灵活不等于无结构。类型、必填规则和关联关系都会被强制执行，数据因此始终是可以用来出报表的。
• 为增长留了余地 — 当某类记录成长为高频大表时，可以把它迁到专用存储上，而使用它的界面和流程不需要改动。

BizPro 用 BPMN 2.0 为工作建模 —— 业务分析师本来就在用的记法，在画布上用开始事件、任务、网关、定时器和结束事件画出来。不同之处在于：这张图不是系统的说明文档，而是引擎实际执行的东西。图上谈定的就是实际发生的；流程要变的时候，变的就是这张图。

• 国际标准 — BPMN 2.0 即 ISO/IEC 19510，是公开标准。在 BizPro 里画出来的东西，任何懂这个标准的人都能读，学过它的 AI 也能读。
• 画一次，然后执行 — 图的背后没有第二套实现，所以图不可能和系统实际做的事情走偏。
• 人、系统与时间 — 一个步骤可以是某个人的任务、对另一个系统的调用、一个等待或升级的定时器，或者一个分支判断。同一个模型全都涵盖。
• 每一步都留痕 — 分派给了谁、谁执行的、提交了什么、什么时候 —— 在流程运行时记录下来，而不是事后追溯拼凑。
• 跨越组织 — 一个流程可以有不止一个参与方，因此供应商或承包商执行的步骤仍然属于同一个流程，而不是发出去就没了下文的消息。
• 运行中也能改 — 流程有版本。新版本可以随时发布，而按旧版本开始的工作会按它开始时的规则走完。

一家公司需要的东西，大部分早就有人做过了。应用模块就是那些成果的打包形式 —— 一个下午装好再调整，而不是先写需求再从头开发。

模块是起点，不是笼子。组织可以加自己的字段、改一份表单、调一条工作流、换一张报表，同时仍然继续收到模块的更新 —— 因为这些改动是作为这家组织的覆盖配置记录下来的，而不是分叉出去的一份副本。

在 BizPro 商务市场上，组织可以发布自己提供的东西 —— 商品、服务、可预约的产能 —— 其他组织则可以找到它、询问它、下单。它与信息列表网站的区别在于下单之后：订单会变成一条同时运行在两家公司系统里的流程，双方各有自己的任务、状态和历史。在两家企业之间，一张达成一致的 BPMN 图起到的正是两套系统之间协议的作用 —— 哪一步归谁一清二楚，谁也不必把对方已经做过的事再录一遍。

• 跨语言的检索 — 无论客户输入的是蒙古文、英文还是中文，搜索都能找到相应的供给，并且除了关键词之外还能按地理位置收窄。
• 先沟通，再承诺 — 买卖双方在平台内对话，而这段对话可以转成一份双方签署的约定文件。
• 订单会变成工作 — 被接受的订单会启动卖方自己的流程 —— 因此它像其他工作一样被排期、被分派、被跟踪。
• 不只是商品，还有能力 — 商务市场承载的也包括业务能力：可预约的服务、服务方的产能，以及扩展一家公司自有 BizPro 的模块。

BizPro 是运行在 PostgreSQL 之上的 ASP.NET Core 应用，分层设计使客户改动的部分与我们交付的部分彼此分离。定义、流程和权限是平台层里的数据；其下的引擎与服务对每个租户都是同一套。正是这种分离，让一次部署可以服务许多组织，而每家仍保有自己的形状。

• 技术栈 — PostgreSQL 之上的 ASP.NET Core（ABP / ASP.NET Zero）；MVC 网页前端；Flutter 移动客户端；专用 OpenID Connect 认证服务器；向 AI 代理开放平台能力的 MCP 服务。
• 配置与代码 — 定义、流程、权限与模块覆盖是数据行，不是类。改动它们是一次写入，而不是一次部署 —— 整个平台正是围绕这一性质组织起来的。
• 存储策略 — 灵活的记录类型以 JSONB 文档存放并配表达式索引；高频类型会被提升为专属关系表，但仍在同一套资源 API 之后，调用方无需改动。
• 扩展模型 — 应用模块打包一个业务领域。按租户的定制以覆盖配置的形式存储在共享定义之上，因此客户调整之后，模块仍能继续接收上游更新。

分层为什么对你重要。加一个字段、改一条流程、装一个模块，只触及平台层 —— 不构建、不发版、不停机。下层引擎的升级到来时，不会打扰你在上层配置好的东西。

BizPro 天生是多租户的：一次部署、多家组织，租户边界在数据层强制执行，而不是靠每个功能自己记得。以下就是这条边界所依赖的控制项。

• 多租户 — 每条归属租户的记录都带着它的租户，查询在数据层按其过滤。跨越边界是明确且被记录的动作 —— 不会因为漏了一次检查而泄露。
• 数据隔离 — 一家组织读不到另一家的记录、定义、流程或文件。共享与全局定义是一种单独且刻意的范围，而不是可见性上的意外。
• 加密 — 流量端到端 TLS 加密。外部系统的凭据保存在密钥库中，绝不出现在流程图里；密码经过哈希，不可逆。
• 身份认证 — 通过专用认证服务器的 OpenID Connect，支持双因素、手机登录、社交身份与会话控制。令牌短期有效且可撤销。
• 授权 — 每个应用服务都声明其所需权限。一个人在界面上看到什么 —— 包括是否看得到金额 —— 取决于他的角色，而不是他打开了哪个页面。
• 审计与历史 — 记录版本、流程回放与任务级归属都会留存，因此谁在何时做了什么是事后可回答的，而不是靠拼凑还原。
• 遵循标准 — 流程按 ISO/IEC 19510（BPMN 2.0）标准执行。平台面向可追溯、合规导向的运营而建 —— 关于认证的说明见下。
• 备份与恢复 — PostgreSQL，定期备份并支持时间点恢复。自托管部署时，这一切都在客户自己的掌控之下。

• 租户强制 — 租户范围在数据层施加，而不是逐条查询处理，因此某个功能忘了过滤也不会变成一次泄露。跨越租户边界需要显式且被审计的调用路径。
• 权限模型 — 每个应用服务上的声明式权限，均在服务端校验。客户端的隐藏只是呈现层，从来不是控制手段 —— 无论界面显示了什么，API 都会拒绝该调用。
• 密钥 — 外部系统凭据存放在密钥库中（支持 HashiCorp Vault），集成步骤按名称引用，因此它们绝不会出现在流程定义或导出文件里。
• 入站回调 — 支付与合作方回调在被采信之前先行校验 —— 当提供方不对负载签名时，平台会对自己的回调 URL 签名。
• 认证状态 — 不持有、也不声称持有 ISO 认证。ISO/IEC 19510 指的是引擎所执行的 BPMN 2.0 记法。独立的漏洞评估与白盒渗透测试（2024 年 1–2 月）未发现问题；报告可应要求提供。

BizPro 声明已针对平台进行过独立的渗透测试，且未发现问题。以下细节予以记录，以便采购方能够核实这一说法，而不是仅凭信任。

说明。BizPro 并不持有、也不声称持有 ISO 认证 —— ISO/IEC 19510 描述的是引擎所执行的 BPMN 记法，而非对本产品的认证。认证应由具备资质的机构认定。

大多数业务软件假设只有一家公司。大型组织不是一家公司 —— 它是一群公司，各有自己的分支、自己的规则和自己的汇报线，却又都需要协同，而不是合并成一个不加区分的数据库。

• 多组织，一次部署 — 每家子公司都是自己的租户，拥有各自的数据、用户、权限与配置 —— 而集团只运行并升级同一套平台。
• 组织内的分支 — 租户之下有一棵组织单元树，承载分支机构、部门与站点。数据、任务和报表可以限定到其中任意层级。
• 该共享的共享，该分开的分开 — 定义与模块可以对整个集团通用、在部分成员间共享，或只属于某一家 —— 于是共用流程只维护一次，却不强求整齐划一。
• 跨公司的工作 — 同一集团的两家成员 —— 或两家毫无关系的企业 —— 可以运行同一条 BPMN 协作，各自处在自己的边界内。集团内部不必再互发表格。
• 汇总报表 — 因为每条记录都带着它的租户和组织单元，同一张报表可以在分支、公司与集团三个层级回答问题，无需另建数据仓库。
• 随数据一起扩展 — 高频大表类型可迁移到带有专属索引的关系表，而使用它们的界面与流程不必改动。

• 租户拓扑 — 一次部署、多个租户；每个租户内有一棵组织单元树承载分支、部门与站点。记录同时携带两者，因此范围限定与汇总报表都不需要另建模型。
• 定义范围 — 一个定义可以对全平台通用、共享给指定租户，或只属于某一个 —— 这正是让集团在不强制所有成员就范的前提下标准化流程的机制。
• 跨租户执行 — 同一条 BPMN 协作的参与方可以分属不同租户，各方只看到自己的泳道与数据。这是引擎的原生行为，而不是一层同步机制。
• 增长路径 — 索引、表提升与后台处理按记录类型分别调优，因此某一处的数据量不会迫使其余部分重新架构。

三条路径，取决于你想拥有多少。它们可以组合 —— 多数客户从第一条开始，再逐步走向其他两条。

无论以哪种方式获得，系统与数据放在哪里由你选择。

具体能力，一行一项。以下每一项都在今天的产品里，而不是在路线图上。

在这个平台上构建是什么样子。下面的示例用于展示形状，不是可以照抄的 API 手册 —— 但每一个都对应产品中真实存在的机制。

{
  "key": "srv_request",
  "name": "Service request",
  "fields": [
    { "key": "requester",     "type": "user",      "required": true },
    { "key": "site",          "type": "reference", "to": "srv_site" },
    { "key": "priority",      "type": "select",    "options": ["low", "normal", "high"] },
    { "key": "warrantyUntil", "type": "date" }
  ]
}

<bpmn:process id="order_qpay" isExecutable="true">
  <bpmn:startEvent       id="start" />
  <bpmn:userTask         id="order"     name="Order" />
  <bpmn:serviceTask      id="pay"       name="QPay payment" />
  <bpmn:exclusiveGateway id="paid"      name="Paid?" />
  <bpmn:endEvent         id="received"  name="Order received" />
  <bpmn:endEvent         id="cancelled" name="Order cancelled" />
  <bpmn:sequenceFlow sourceRef="paid" targetRef="received"  name="yes" />
  <bpmn:sequenceFlow sourceRef="paid" targetRef="cancelled" name="no" />
</bpmn:process>

POST /api/services/app/<AppService>/<Method>
Authorization: Bearer <token>

{ "resource": "srv_request",
  "filter":   "priority == 'high'",
  "sorting":  "creationTime DESC" }

因为这三种形状都是显式且标准的，AI 代理能生成它们，人能读懂它们，平台能在任何东西运行之前校验它们。

当 AI 以代码的形式写出一个应用时，审阅它就意味着读代码 —— 既慢，而且真正懂业务的人大多读不了。在 BizPro 里，AI 产出的是一张流程图、一组字段定义、一组权限和一个界面。一位主管看一眼图就能说“少了审批这一步”。这样的审阅，任何人几分钟就能做完。

• 人说明意图 — 「现场工程师要登记到场服务记录，超过两小时的需要主管审批。」
• AI 起草结构 — 记录定义、表单、BPMN 流程、权限和界面 —— 由平台已有的模式拼装而成，而不是凭空发明。
• BizPro 把它落成形 — 草稿变成真正的定义和真正的流程，和手工搭建的东西一样受同样的规则、权限与组织边界约束。
• 人审阅并启用 — 读一遍图，把表单当测试填一次，发现缺口并补上 —— 然后上线。

让 AI 的参与真正产生效益的，是平台的结构本身。在这里工作的 AI 代理组合的是平台已有的基本构件 —— 定义、流程、模块、权限 —— 而不是逐行生成一个应用；并且它产出的每一件东西都具有人类可读的形式。

• 可复用的平台模式 — 模块、定义和流程模式已经存在，因此生成是对已知零件的组合，而不是发明。
• 动态资源 — 数据结构通过平台自身的定义来创建和修改，而不是通过数据库迁移和部署。
• 结构化的工作流 — BPMN 2.0 是对行为的显式、标准、机器可读的建模 —— 预期的流转是被明确声明的，而不是从代码控制流里推断出来的。
• 可视化的图 — 生成的逻辑可以以图的形式呈现，因此非程序员也能审阅它，并在它运行之前否决它。
• 更低的歧义 — 字段、权限和流程路径都是显式声明的，这压缩了“看似合理但其实是错的”输出的空间。
• 更易测试与解释 — 看得见的流转本身就指明了它的测试方法：沿路径走一遍、提交表单、检查留下的历史。
• 更少花在脚手架上的 token — 由于平台提供了结构，代理的努力有更大比例用在业务特有的部分，而不是重新推导样板结构。

BizPro 把面向机器的接口做成平台的一等组成部分，而不是外挂：外部 AI agent 通过 Model Context Protocol 服务器接入，按含义读取平台、校验拟议的变更，并把它作为提案交由人确认。它作为独立进程运行，可以单独重启、停用或移除，不影响 Web 应用 —— 而它提供的正是产品内助手所用的同一份目录。

• 传输 — 基于 HTTP 的 Model Context Protocol。以独立主机名单独部署，与 Web 应用共享数据库和任务队列，但进程相互独立。
• 认证 — 只接受 bearer token —— 与 API 主机签发的 JWT 完全相同，签名密钥、issuer 和 audience 一致，因此不会出现第二套凭据体系。没有签名密钥，服务器拒绝启动。
• 身份 — 取自已验证 token 的 claim，并作为每个工具做租户过滤所依据的会话。身份类参数会被直接拒绝：调用方无法指定自己要以哪个租户或用户的身份行事。
• 契约 — 一份带输入输出 schema 的声明式工具目录。dispatcher 拒绝目录之外的任何名称，因此新的 handler 不会被意外暴露；每个工具还声明自己的 toolset、界面，以及是否需要人来确认。
• 可发现性 — 知识工具会检索 BizPro 自己的 skill、其参考文件、agent 角色定义、工具目录以及各模块指南，并返回片段 —— 让 agent 在提出变更之前先查清平台的做法，而不是靠推测。
• 资源 — 除了工具，服务器还把 Concept Contract（本体）、模块指南、已发布的 skill、平台目录和 JSON-LD 导出作为 MCP resource 提供 —— agent 在请求一条记录之前，先读懂这条记录是什么意思。

当前目录 —— 99 个工具，按用途分组：

每个工具都独立声明两件事：它做什么，以及出错的代价有多大。这是两个互不相同的维度，因为两个写入工具的风险等级可能相差很远，而查看审计页面的运维关心的是后者：

• ReadOnly — 没有需要回退的东西。
• SafeWrite — 写入的内容仍需人来批准。
• PrivilegedWrite — 改动真实的平台状态，或跨越单个租户的共享状态。
• Destructive — 删除或覆盖不易恢复的内容。
• HostOnly — 租户会话永远无法触及。
• Confirmation — 与前两者分开声明：一个提案类工具自己什么都不写 —— 变更只在人于浏览器中确认后才发生 —— 而 PrivilegedWrite 及以上却未声明确认的工具会被 dispatcher 拒绝。

除了工具，平台还带着自己成文的知识：17 个 skill，各自指向系统某一领域的参考资料；以及 14 个 agent 角色定义，写明该角色动手之前必须加载哪些 skill。这与一位新工程师要读的是同一批材料。其中两个角色是强制而非建议：凡涉及会计、审计历史或租户隔离，加载合规角色；凡涉及授权或租户边界，加载安全评审角色。

• 结构 — 核心架构、动态实体与资源、BPMN 引擎、AppModule 开发以及按租户定制。
• 边界 — 权限与安全、跨租户协作 —— 在这两个领域答错是安全事故，而不只是缺陷。
• 界面层 — MVC 页面与表格、Flutter 应用、SQL 与 PostgreSQL、测试。
• 成文产出 — 开发文档、用户手册，以及线上租户的问题诊断。

agent 做不到的事 —— 靠结构约束，而不是靠规定：

• 直接写入平台数据行。所有改动都是 change set，或由人确认的提案。
• 批准自己的成果。批准与确认都是浏览器动作 —— 不在 agent 的工具集中，API 上也没有确认端点。
• 读取提问者在页面上打不开的概念。语义读取按概念、按租户授权，并被审计。
• 冒充其他租户或用户。身份来自 token，身份类参数会被拒绝。
• 调用目录之外的工具，或从租户会话调用 host-only 工具。
• 通过通用资源 API 读取平台自有的存储 —— 这些 key 在读和写两条路径上都被拒绝。
• 看到凭据值。连接器的元数据是公开的，密钥不是。

接入一个 agent：

1. 从 API 主机获取 JWT —— 与 REST API 接受的是同一个 token。
2. 把 MCP 客户端指向该服务器主机，并以该 token 作为 bearer 凭据。
3. 调用 get_system_version，确认协议版本与工具数量；从 bizpro://ontology 读懂记录的含义。
4. 先调用 get_module_context —— id、key 和模块代码必须来自它，不能靠猜。
5. 先读后写：semantic_resolve，然后 semantic_describe 与 search_bizpro_knowledge。
6. 校验，然后提案 —— 结构用 change set，数据用 semantic_execute 或 start_process —— 再交给人来确认。

设计前提是：agent 有能力，但也会出错。因此平台让有用的东西容易被发现，让危险的东西根本够不着，并在提案变成现实的那唯一一个节点上放一个人。

BizPro 里所有的 AI 功能 —— 设置助手、模块 agent、支持聊天、面向外部 agent 的 MCP 服务器 —— 都跑在同一套栈上。六层，各司一职，谁也不越俎代庖。

• 本体管含义，DynamicEntity 管状态，BPMN 管执行。 — MCP 暴露能力，skill 管流程，模型负责理解与组合。没有哪一层去做另一层的事 —— 正是这一点让一个错误的回答不会变成一次错误的写入。
• 没有 agent 写业务数据。 — 每个改动都是一个由人确认的提案或 change set。确认是一个浏览器动作，背后没有 API，所以 agent 手里的 token 无法确认它自己的成果。
• 身份从来不是参数。 — 租户和用户来自会话。工具无法指定要以哪个租户的身份行事，每次语义读取都限定在提问者的范围内 —— 就是他们在页面上能打开的那些行。
• 第一个客户是我们自己的会计。 — 会计设置助手从 Excel 读入科目表，映射到标准科目表，提出期初余额与记账默认值 —— 每张卡片都由人确认。酒店模块靠一份配方就能把一个租户设置好，引擎里没有一行酒店代码。

上面每一层今天都已在产品里，连同它的测试 —— 不在路线图上。设计按阶段记录在平台的开发计划中。

能力概览

• 可定制的业务数据 —— 定义、字段、表单与校验可在运行时修改。
• 流程自动化 —— 执行 BPMN 2.0 模型，含人工任务、系统调用、定时器、网关与异常处理。
• 跨组织工作流 —— 一条流程中包含来自多家组织的参与方。
• 可审计性 —— 记录版本、流程历史、任务级归属与留存的审批。
• 模块化开发 —— 应用模块可按组织安装与调整，无需分叉。
• 外部集成 —— 对外 API 调用、经校验的对内回调、可复用连接器、设备数据回传。
• 移动支持 —— 平台定义的表单原生渲染，离线采集、扫码、媒体与定位。
• 商务市场扩展 —— 发布、检索、跨组织下单与模块分发。

架构带来的结果

• 变更即配置：大多数业务变更不需要一次部署。
• 一个定义服务多个界面：网页表单、移动表单、列表、筛选、搜索与报表在结构上天然保持一致。
• 模型即实现：BPMN 图不可能与它所描述的行为走偏。
• 无需分叉即可定制：按组织的覆盖配置让共享模块继续接收更新。
• 非程序员也能审阅：产物是图、表单和权限集合。
• 组织隔离是平台的性质，而不是每个功能都必须自己记得去实现的事情。

BizPro 把工作的历史和工作本身一起记录下来。每条记录保留它的历次版本，每个流程实例保留它走过的路径和每一步的经手人，每个界面只显示查看者的权限所允许的内容。这使得系统不只是一个用来录入的地方，而是可以作为凭据来使用。

• 审计轨迹 — 记录的改动连同修改人和时间一起保存，因此之前的状态总是可以直接调出来，而不必去推断。
• 状态可见 — 一件事进行到哪一步，是系统本身持有的事实，而不是由某位协调人在另一张表里维护的东西。
• 任务可追溯 — 每个任务都记录它分派给了谁、由谁完成、提交了什么，以及等待了多久。
• 流程历史 — 已结束的流程可以逐步回放，包括它走过的分支和它没有走的分支。
• 靠权限，而不是靠界面 — 一个人能看到什么、能做什么由权限决定。同一个界面上的两个人可以看到不同的信息 —— 比如价格 —— 而不需要做出第二个版本的界面。
• 组织之间相互隔离 — 每家组织的数据在平台各处都被限定在这家组织范围内，跨越这条边界是一个明确且被记录的动作，而不是某种副作用。

BizPro 在设计上充分考虑了安全性与治理，支持可追溯、面向合规的运营方式 —— 权限、组织隔离、留存的历史和被记录下来的审批。具体的认证资质应由认证机构来认定，我们在此不做此类声明。

• 销售与客户管理 — 线索与客户、报价，以及交接给真正交付所售之物的那条流程。
• 审批与内部申请 — 请假、采购、权限、报销 —— 按规则路由、在手机上审批，并连同理由一起留存。
• 服务与维保 — 从申请到排定作业再到完成的工单，包括由分包方执行的部分。
• 库存与 RFID — 跨门店的库存、用手持机盘点，每一件打了标签的物品都可以单独追溯。
• 配送与物流 — 货物、行程与交接，GPS 跟踪，收件人无需账号即可查看的公开链接。
• 文档与档案 — 文件的登记、分类与保管期限，可在整个馆藏范围内调阅。
• 物业与不动产 — 楼宇、房屋、住户、费用，以及运营一处物业所伴随的各类申请。
• 只有你们才有的那些事 — 因为只有你们这个行业才有、所以没有厂商在卖的流程 —— 而那通常正是表格堆积的地方。

我们从真实项目里学习，并据此持续改进平台。

外部系统可以直接在 BizPro 流程里被调用。接一次，之后的流程都能复用。

• 调用其他系统 — 流程中的一步去调用外部 API —— ERP、财务系统、税务、银行、合作方的系统 —— 凭据集中保管，绝不写在图里。
• 事件与回调 — 其他系统告知 BizPro 发生了某件事，等待中的流程随即继续。回调在被采信之前会先做校验。
• 可复用的连接器 — 常见的集成被打包成连接器，配置即可使用而不必现做，并可被任何需要它的流程复用。
• 设备与数据回传 — GPS 设备、扫描枪和手持读写器直接写入人们正在使用的那些记录，因此状态也可以自己发生变化。

三个正在推进的方向。

• AI Accounting — AI 辅助的会计模块 — 把交易、单据、账簿和报表的工作接到流程与 AI 上。合规和审计痕迹是架构的一部分，而不是事后补的。
• Logistics — 在公司之间延续的物流流程 — 把订单、仓储、运输、配送和单据，在参与的各个组织之间连起来。
• PMS — 以时间为核心的物业管理 — 客房、公寓、场地等资源的可用时段、预订、服务与收款，都按流程来管。

一家组织的业务流程，可以直接延续成下一家组织的流程。

• 一笔订单不会止于一家组织。
• 它流向供应商，再流向物流；付款流向银行，发票流向税务系统。
• 在 BizPro 看来，这些不是彼此独立的应用，而是一条一直延续下去的业务流程。

概念关系

动态业务数据   ->  定义灵活的业务结构
BPMN 2.0 流程  ->  定义这些结构之上的流程行为
应用模块       ->  把数据 + 流程 + 权限 + 界面打包成业务能力
商务市场       ->  分发能力并连接各个组织
网页 + 移动    ->  把同一份定义送达办公桌与现场
人             ->  定义意图、审阅、决策并承担责任
AI             ->  在这套结构之内加速生成与优化

BizPro 是面向“人 + AI”的低代码业务操作系统。动态业务数据让结构可改，BPMN 2.0 让行为显式且可执行，应用模块让能力可复用，商务市场让能力可以在组织之间共享。因为这四者在运行时始终可见，人可以审阅系统在做什么 —— 而 AI 可以在一套已经存在的结构之上做扩展，而不必先发明一套。