Cympha
全部文档

AlignerBot——跨 Cympha、OrthoPlus 和 Agent 的 Phase-1 到 Phase-2

本文跟随一个病例走完 AlignerBot AI 隐形矫治设计：从 Phase-1 方案、医生批准或请求修改，到 Phase-2 矫治器设计与最终交付.

适用人群： 提交 AlignerBot 病例的临床医生、对其分诊的技工所经理,以及在技工所中使用 Cympha Agent Manager 调度 OrthoPlus 的 AlignerBot 操作员. 请端到端阅读,这样每个角色都知道其他两方在做什么.

阅读后您将知道： 一个 AlignerBot 病例如何穿越规划（Phase-1）和矫治器设计（Phase-2）阶段、调度交接在哪里发生,以及当临床医生在循环中途请求更改时需要什么.

所需时间： 阅读约 25 分钟. 一个真实病例的 Phase-1 通常在不到一小时的 Agent + OrthoPlus 时间内完成,加上临床医生审阅的时间.

开始之前

您需要：

  • 一位拥有 Cympha 账户且可访问 app.cympha.com/cases/new 的临床医生.
  • 一家 Cympha 上的技工所,其 /team 中至少有一位用户持有 AlignerBot 角色. 如果没有 AlignerBot 角色用户，病例可被分配给普通设计师，但 Agent 不会自动调度 OrthoPlus——它会作为普通设计师任务搁置.
  • 一台 Windows 工作站,已安装并激活 GuideMia OrthoPlus，且 Cympha Agent Manager 已安装并配对到 AlignerBot 角色用户的 Cympha 邮箱.
  • 一组已确认的扫描数据（至少上颌+下颌 STL/PLY）. Agent 没有扫描数据无法调度 OrthoPlus.

技工所侧的设置，请先按 为您的技工所设置 AlignerBot 操作. Agent 侧的设置，请按 安装并配对 Cympha Agent Manager 操作. 如果临床医生对 AlignerBot 全新，提交一个 AlignerBot 病例 是专注的受理文档.

第 1 步——临床医生在 /cases/new 提交 AlignerBot 病例

临床医生打开 app.cympha.com/cases/new. 他们搜索一家提供 AlignerBot 的技工所并选择类别 AlignerBot. 表单显示 AlignBot 参数部分：每颌方案范围、自动拔牙开关、拔牙牙位号、缺失牙、允许的 IPR、前牵/后退、扩弓、伸长/压低、中线对齐、Spee 曲线、矢状/冠状倾角.

他们至少上传上下颌 STL/PLY. 可选：咬合、照片、CBCT.

他们提交. 病例从草稿提升到 Submitted，由技工所经理持有，经理会收到一封来自 Cympha 的邮件. 完整的受理侧详情见 提交一个 AlignerBot 病例.

第 2 步——技工所经理将病例路由到 AlignerBot 席位

技工所经理打开这个新病例——它显示状态为 Submitted，类别为 AlignerBot. 他们确认扫描和参数看起来合理，然后将病例移动到 Designing. 状态控件在确认之前会预览病例将由谁接收；团队中有 AlignerBot 席位用户时，病例会路由到该用户. 完整的分配演练见 将病例分配给设计师.

席位为什么重要：配对到该用户的工作站上的 Cympha Agent Manager 内含一个 AlignerBot Agent. 它只在病例持有者是 AlignerBot 席位用户时激活. 由普通设计师持有时,病例会停留在 Designing,但不会自动调度——设计师必须手动驱动 OrthoPlus.

第 3 步——Agent 认领病例并调度 OrthoPlus

在下一次轮询时（Agent 每 20 秒检查一次新病例），AlignerBot 操作员工作站上的 Cympha Agent Manager 看到一个由其配对用户持有的新分派病例，于是认领一个调度锁. （这个锁可防止配对到同一用户的第二台工作站发生竞争——任何一次设计任务只会被一个 Agent 拾取. ）

然后 Agent：

  1. 将病例文件（扫描+任何其他输入）下载到工作区文件夹中该病例自己的文件夹里.
  2. 以规划模式（Phase-1）在该病例上启动 OrthoPlus.

调度支持并行——Agent 可以同时运行多个 OrthoPlus 工作进程，在其 Configure AlignerBot 对话框中配置.

第 4 步——OrthoPlus 运行 Phase-1（规划）

OrthoPlus 加载扫描，应用 AlignBot 参数，运行规划级联. 这会生成一个治疗方案：N 个步骤上的分阶段牙齿位置、IPR 图、附件放置、中线对齐.

OrthoPlus 将成果保存到病例文件夹中，其中包括 .gvw（Studio 可查看的治疗方案）. Agent 自动上传 .gvw，而且——因为经由 Agent 到达的审阅文件会自行发起审批——病例变为 Awaiting Approval，带 Plan Approval Pending 标签，全程无需技工所点击. （OrthoPlus 使用的 .gos 项目文件留在工作站本地；它不会被上传. ）临床医生收到一封来自 Cympha 的邮件.

第 5 步——临床医生在 /cases/<id>/approve 审阅

临床医生点击邮件链接，进入 /cases/<id>/approve. 标题显示患者姓名、Awaiting Approval 徽章和步骤标签 "Approval needed — Treatment Plan".

文件面板列出 .gvw 以及原始扫描. 临床医生点击 .gvw 链接在新标签页中打开 Studio，并旋转查看方案——分阶段牙齿位置、附件放置、治疗结束时的模拟咬合.

底部有三个操作：

  • Approve design——接受方案.
  • Request changes——退回给 AlignerBot Agent.
  • Escalate to lab manager——转给技工所经理.

完整的批准页演练见 批准或拒绝设计.

第 6a 步——临床医生批准方案 → Phase-2 自动调度

如果临床医生批准方案，状态会经由 Approved 中转，并且——因为还剩一个审批周期——直接回落到 Designing，仍由同一个 AlignerBot 席位持有. Agent 下次轮询时认领一个新的调度锁.

这次 Agent 以矫治器模式（Phase-2）启动 OrthoPlus，OrthoPlus 运行矫治器设计级联——生成病例的 Design kind 所要求的内容：Aligner models、Arch model、Bracket bonding guide 或 Treatment plan only.

OrthoPlus 以一个设计结果 zip 和一个 .gos.gpk 传输包收尾. Agent 自动上传它们，而经由 Agent 到达的 .gos.gpk 会自行触发第二次审批：状态再次变为 Awaiting Approval，带系统标签 Appliance Approval Pending.

临床医生再次收到来自 Cympha 的邮件，并返回 /cases/<id>/approve. 他们审阅矫治器文件并批准. 状态经由 Approved 中转，并且——这是数字类别的最后一个周期——直接推进到 Delivered，没有生产制造环节（完整生命周期见 病例状态术语表）.

往返结束. 病例已交付.

第 6b 步——临床医生请求更改 → 需要结构化物件

如果临床医生改为点击 Request changes，对话框要求他们确认. 对于 AlignerBot，对话框强制执行结构化的修订物件:确认按钮在扩展名为 .xml 或 .gpk 的文件被附加到病例之前保持禁用.

对话框本身显示一个琥珀色横幅,内容为 "Upload one of the following first:"，并列出两条路径：

  • **从 Cympha Studio 的 3D 审阅导出的 XML 牙位文件. ** 临床医生在 Studio 中打开病例的 .gvw，在 3D 审阅界面进行牙位编辑，导出 .xml，并在重新确认拒绝之前将其上传回病例.
  • **从 GuideMia OrthoPlus Planner 保存的 .gos.gpk 传输包. ** 如果临床医生本人有 OrthoPlus，他们可以编辑方案并保存为 .gos.gpk，然后上传.

对话框中的 Get the planner → 链接指向 /downloads，方便临床医生在没有的情况下获取 OrthoPlus.

一旦上传了其中一种物件类型，Request changes 确认按钮即可启用. 点击它使状态变为 Changes Requested，病例回到 AlignerBot 席位手中. Agent 下次轮询时认领一个新锁，并以规划模式重新调度 OrthoPlus，同时应用修订物件. Phase-1 在融入临床医生的编辑后再次运行. 循环重复.

为什么没有自由文本拒绝：OrthoPlus 规划级联没有英文解析器. 一个键入的指令如"move tooth 16 buccally"在管道中没有可落地的位置. XML/GPK 物件是 OrthoPlus 实际消费的结构化输入.

第 6c 步——临床医生升级 → 退出 Bot 循环

如果临床医生点击 Escalate to lab manager，状态变为 Escalated，持有者转交给技工所经理. Bot 不会在已升级的病例上重新调度. 技工所经理进行分诊——通常他们在聊天中与临床医生审阅，然后要么让病例重新走 Bot 流程（将其移回 Designing，使其路由到 AlignerBot 席位），要么改为手动处理该病例.

成功的样子

一次干净往返的终态：

  • 病例活动日志中有 两次批准——一次对应 Treatment Plan 步骤，一次对应 Appliance Design 步骤.
  • /cases/<id> 上 状态为 Delivered（数字交付——AlignerBot 病例没有生产制造环节）.
  • Files 面板 包含原始扫描、Phase-1 的 .gvw、Phase-2 的矫治器输出（设计结果 zip 和 .gos.gpk），以及循环中上传的任何修订物件.
  • 临床医生的病例列表 在 Delivered 下显示该病例，可以通过 与患者共享治疗方案 分享给患者.

故障排查

**分配后病例停留在 Designing 但 OrthoPlus 从未打开. ** 病例由一位不持有 AlignerBot 席位的设计师持有. 将病例重新走一遍 Designing，使其路由到 AlignerBot 席位用户——状态控件会预览由谁接收. Bot 只对 AlignerBot 席位持有者激活.

**OrthoPlus 打开但加载病例时立即报错. ** 扫描数据格式错误或缺一颌. 在 /cases/<id> 中打开病例，确认上下颌扫描都存在并已确认（不是卡在上传中）. 如有需要重新上传，然后在病例页点击 Re-run design 触发新的调度.

**Phase-1 完成但 Approve 后从未调度 Phase-2. ** 临床医生批准了,但 Agent 没有拾取病例. 检查操作员工作站上的 Agent 是否已配对. 如果已配对但未调度，病例可能已不在 AlignerBot 用户手中；请在 /cases/<id> 上检查当前由谁持有该病例，等它回到正确持有者后使用 Re-run design.

**临床医生的 Request changes 确认按钮保持灰色. ** 他们尚未上传 .xml 或 .gos.gpk. 对话框中的琥珀色横幅解释了两条合法路径. 要么前往 Studio 的 3D 审阅获取 .xml，要么使用 OrthoPlus Planner 获取 .gos.gpk. 在病例聊天中的自由文本指令不算数.

**临床医生在批准 Phase-1 后想要不同的设计类型. ** 病例页上的 Design options 卡片带有 Design kind 选择器（Aligner models、Arch model、Bracket bonding guide、Treatment plan only），以及步骤范围和附件选项. 保存选项本身不会派发任何任务——更改类型后，点击 Re-run design 以新值重新调度.

**病例在循环中不断重新调度 Phase-1. ** 查看活动日志，弄清每一轮由什么驱动. 如果病例确实卡住了，技工所经理可以在病例页覆盖其状态，待状态正常后使用 Re-run design——或者取消并重新提交.

相关教程：提交一个 AlignerBot 病例 · 为您的技工所设置 AlignerBot · 安装并配对 Cympha Agent Manager · 将病例分配给设计师 · 批准或拒绝设计 · 使用 ClearAligner.AI 直达诊所 · 病例状态术语表 · 文件格式参考 · 角色矩阵

CymphaLMSCymphaStudio