打开 Open WebUI 之前，早晨的测试报告就能准备好

周一早上 8 点半，开发者打开夜间测试结果，有三个作业标红。第一个断开了测试数据库连接，第二个偶发超时，第三个在周五改过的代码中断言失败。分清这些结果，比看一眼红色标记花的时间长。定时运行的编程智能体可以把简短报告留在聊天里，把失败断言和相关日志片段放到开头。

Open WebUI 是可自托管的 AI 模型与工具聊天界面，v0.13.3 为定时自动化增加了对编程智能体的支持。GitHub 上的发布时间为 2026 年 11 月 8 日 23:48 UTC。自动化可以保存终端、工作目录和该终端可用的编程智能体，再把结果发送到聊天。定时任务能够在指定执行环境中开始，这让晨间报告变得实用。Open WebUI v0.13.3 发布说明

最值得先安排的是人能在几分钟内核对的报告。让自动化收集证据，把下一步判断交给项目负责人。可重复生成的报告证明有用之后，就有了衡量是否要再开放权限的基线。

自动化会记住智能体在哪里工作

Open WebUI 的自动化原本就支持定期运行提示词。一次执行会通过常规响应流程启动聊天，因此模型设置、工具、过滤器和适用的记忆配置都会影响结果。v0.13.3 可以选择终端中发现的编程智能体。选中终端后，模型选择器以「智能体/模型」的形式显示可用组合。切换终端或目录，组合也可能变化。Open WebUI 会在开始前检查保存的终端与智能体。任一项已不存在，任务都会失败，所有者可以查看执行日志。Open WebUI 自动化文档

调度器使用保存的执行设置启动聊天。Telli.sh 根据 Open WebUI v0.13.3 发布说明原创绘制。

工作目录回答的是一个看似普通、弄错却代价不小的问题。两个项目的文件名相似，或同一项目的功能分支与发布分支都在磁盘上时，智能体应该读哪个检出目录？明确路径可让任务从预期位置开始，也给审核者一个核对参照。它仍然只是起始目录。任务最终能访问什么，由读写权限、可访问文件、环境变量、网络和智能体行为共同决定。

结果也有明确的目的地。编程智能体自动化会把输出发到聊天。发布说明将它与普通模型自动化分开，后者可以选择频道。个人审查晨间报告，用执行历史和聊天就够了。团队需要共享提醒时，还要另外决定共享什么、发到哪里、谁可以看原始日志。定时任务失败后，也要有知道去哪里查的负责人。Open WebUI v0.13.3 发布说明

第一项任务使用小而可检查的输入

以周一的测试报告为例。先准备最近一次夜间测试的摘要副本、机器生成的提交 ID，以及少量失败日志。可以用现有的 CI 产物导出器，也可以手动复制到用完即弃的目录，为智能体提供稳定输入。每个文件应带有足够上下文，能把失败归到具体作业和提交。明显的秘密信息和无关日志要在放进目录前删掉。文件名有约定，时间戳可核对，智能体就不用猜哪个最新。

要求在一条聊天回复里分三项输出。第一是值得关注的失败简表，第二是环境类或尚未确定原因的失败，第三是每项的来源链接或路径。让报告保持简短，好与原始 CI 界面对照。一个测试在矩阵中跑了六次就创建六张重复工单，会把小小的阅读问题变成更大的审核工作。

有用的提示词会说明输出必须保留哪些内容。下面是带提交记录与导出作业摘要的测试样例，目录和文件仅为示意。

读取指定项目目录中的测试摘要和相关失败片段。先列出输入中的运行 ID、提交和时间戳。将矩阵中重复的失败归在一起。每个不同的失败写明测试名、最短的有效日志片段和来源路径。区分明确失败与可能原因。如果摘要缺失、过时或不完整，说明缺哪项输入并停止。保持文件原样。

这些指令能减少歧义，终端权限仍须与任务匹配。只读文件的任务应使用只读视图，或使用不带仓库凭据的临时副本。失败测试可能输出来自源码、第三方依赖或夹具的任意文字。这些文字属于证据，无须变成智能体的新指令。任务在所有者起床之前就执行时，这一点更重要。

同样的安排也能用于另一项定期工作。技术负责人可以提供带日期的依赖清单和另行获取的安全公告，要求智能体标记可能匹配的版本并引用相关记录。实用产出是一张含确切包名、版本与来源的审查清单。可信扫描器仍可做确定性匹配，审核者再判断应用是否会运行到这项依赖。固定文件也让解释随运行改变时，报告更容易复现。

短暂的配置试验能看出大部分实际工作

Open WebUI 文档列出全局 Automations 开关和非管理员用户的单独权限。确认实例为 v0.13.3 或后续兼容版，功能已启用，账户有权访问。终端必须已连接，并获准用于自动化场景。终端可能出现在模型编辑器里，却被上下文配置排除在定时任务之外。这能解释为什么普通聊天里可用，定时运行时却失败。Open WebUI Automations · Open Terminal 连接文档

1. 准备测试样例。 在临时工作区放入一次成功执行、一个有代表性的失败，以及记录提交和时间戳的清单。保持输入小，把生产密钥、云配置和个人文件放在工作区之外。
2. 打开 Automations 并创建任务。 填写标题、提示词、模型和时间安排。在编辑器里选终端，明确填写工作目录，再从模型选择器选定编程智能体。稍等环境报告该目录可用的智能体。
3. 从编辑器执行一次。 打开生成的聊天和执行日志。确认提交、来源文件、去重和文件权限。将结果与原产物对照，并检查源码工作树是否仍然干净。
4. 执行一个反例。 从另一套样例移除清单，或故意指向过时输入。报告应当把证据缺失说清楚。确认无法在自动化中使用的终端会在执行历史中显示为失败。
5. 设置定期时间，查看最初几份结果。 将执行计划与 CI 导出完成的时间对照。即使报告读起来像今天的，过早启动而读取昨天结果也是排期问题。输入约定变了，或报告开始偏离时，暂停任务。

把样例与报告提示词成对维护。更改目录名、分支约定或测试所属套件时，一起更新样例，避免任务悄悄丢失用于归组的证据。有人改提示词时，保留之前的样例，用相同输入比较两个结果。两个定时任务需要对哪次执行算最新达成一致时，改进输入清单往往是最便宜的办法。

选定终端时，也要确定权限边界

自托管的聊天界面也可以连接其他提供方的模型或智能体。检查选定智能体关联的提供方、它收到的数据和能用的服务凭据。容器或一次性工作区中的检出目录，给操作人员一个限制任务能力的地方。同一用户若能访问宿主机其余内容，或智能体持有仓库写入凭据，仅设置起始目录作用很小。Open WebUI 终端文档介绍了不同使用场景的设置，包括自动化上下文，管理员可以在运行前收窄终端的暴露范围。Open WebUI 终端连接文档

只读报告把证据、执行权限和审核决定分开。Telli.sh 原创图解。

省下的是从打开结果到知道该查哪里的时间。这些工作有很大一部分可以由可靠命令完成。让命令生成运行 ID 和状态，让智能体解释不同类型的输出里发生的失败。出问题时，先把报告的 ID 与清单对照，就能在更换智能体前发现输入是否有误。

成本也应该一起检查。选定的智能体调用计费模型时，定期运行会消耗用量。长日志增加输入体积，重复的测试失败也会引起重复分析。先以短期排程、长度受限的日志片段测试，看看能得到多少有用的审查信息。如果每次都处理相同的大文件，先用低成本的确定性步骤记录内容是否变化。每次读取的输入有已知上限后，每日排程就容易估算预算。

小团队里，归属与终端一样重要。Open WebUI 文档称，自动化归创建者所有，对该用户私有。个人报告可以留在那里。多人依赖的发布签核要有独立可见的流程，用来共享证据，并在负责人不在时转交责任。自动化历史方便个人排查错误，团队共用的 CI 检查则让交付人员都能看见构建决定。Open WebUI 自动化访问控制

晨间报告有没有价值，要在审核时看

第一周结束后，查看人实际打开过的报告。核对每条紧急项的链接或摘要，统计遗漏失败、重复已知问题和引用错误提交的次数。问审核者，报告有没有帮助他们找出下一个该查的测试。这些观察比自动回复的数量更能说明排程是否有价值。

输出持续有用时，可以一次增加一项新的证据。为终端保留稳定的目标位置，收窄任务凭据，让代码与基础设施修改继续走团队原有审查。进展最清楚的标志，是晨间报告可靠到能据此行动，而且出现异常时很快就能查明。

来源

• Open WebUI v0.13.3 发布说明
• Open WebUI 自动化配置、权限与执行历史
• Open WebUI 终端连接与使用场景

---

想保留可搜索的工作讨论与决策记录，可以创建 Telli.sh 账户。