开发者把演示链接发给客户，合上笔记本去开会。客户打开页面，按钮按下后一直转圈，不知道还要等多久。网页仍然在线，真正负责运行模型的那台机器却已经休眠；两个状态被界面画成了同一件事。
只需要展示效果就用静态页面，动态服务能托管也优先托管。只有处理必须留在特定环境，例如现成模型或设备旁，才需要连接那台提供方。EasyNet 不会自动把个人笔记本变成有可用性保证的服务器。
页面与执行应分开维护。网站提交一个明确的演示请求，提供方函数接受约定输入并返回真实结果；展示样本则标为样本。网站开发者需要接好请求状态和结果交付，不能用固定动画假装收到 Runtime 的进度。
状态提示要区分没有权限、找不到提供方和处理失败。等待窗口由业务决定，客户端超时只说明停止等待，不等于服务端已取消。对可能产生副作用的任务，恢复后先查原请求，而不是自动再提交一次。
维护者通知也需要具体：哪个入口在什么时候失败，有没有仍运行的任务。健康探测使用小型无副作用输入，不把客户材料带进公开告警。探测、告警和恢复入口属于要补齐的网站运行工作，一次探测成功也不担保之后所有请求。
把提供方断开，检查页面仍能打开并清楚结束等待；再用无权限身份确认不会误报离线。客户暂时用不了时能知道下一步，开发者能收到可处理的信息，才比留着一个永远转动的按钮更像可交付的演示。
- 01
访客打开页面
静态内容仍可阅读
- 02
核对执行结果
离线、拒绝与失败分开
- 03
结束等待
提示下一步，不冒充成功
不要把拒绝权限翻译成离线
本地展示映射示例，输入为合成状态，不是探测命令或真实 Runtime 错误码约定。
本地示例 · python
messages = {
"denied": "Request access from the owner.",
"offline": "The provider is unavailable. Check later.",
"unknown": "Check the original request before retrying.",
}
observed = "denied"
assert "access" in messages[observed]
print(messages[observed])预期结果：提示申请权限，而不是声称机器离线。
接入时的检查项
- 提供方离线后页面是否仍可访问并解释问题。
- 拒绝访问是否不会被误显示为设备离线。
- 恢复服务后是否能核对原请求状态而不制造重复执行。