AI 定时任务接 ERP：账号切换后的权限校验与异常状态设计

把调度器返回 200、连接器调用成功和 ERP 业务完成混为一谈，排障时就找不到真正失败的环节。本文从公开更新出发，用一个只读查询与一个需确认的写入样本，列出身份、权限和回执的联调点。

这次更新到底说明什么

10 月 9 日的千问办公客户端 1.2.5 更新日志提到系统唤醒恢复、账号切换、二次确认等情况下定时任务触发的稳定性，也提到连接器状态同步与异常恢复。WorkBuddy 的 5.4.0 更新日志（8 月 20 日）涉及自动化执行日期和长耗时工具，自动化说明还写到本地任务按当前登录身份发起。这些信息来自各自官方资料，指向的是不同产品的具体机制，不能合并成"定时任务已经可以替企业自动办完 ERP 业务"。截至 10 月 11 日的官网原文核验，没有发现需另行报道的重大更新；本文因此聚焦企业自己应验收的身份、权限与业务结果。

触发时先确认身份，而不是沿用创建时的假设

假设采购员甲在周五设置"每周一读取待补货清单"，周一电脑由员工乙登录。若业务工具仅沿用创建计划时缓存的身份，就可能把甲的权限带进乙的会话；若仅使用当前桌面登录状态，又可能失去"这项计划归谁负责"的记录。这是用于设计测试的风险场景，不代表某款产品已出现该问题。

合理的企业实施方式是把计划所有者、触发时登录身份、实际业务调用身份分别记录。每次调用前判断计划是否仍有效、员工是否仍在岗、连接器能力是否仍获授权，再由 ERP 按当前映射的员工账号判断功能和数据范围。账号不一致或授权无法确认时，先暂停业务调用并交给负责人处理。连接器授权与目标系统数据权限承担两道不同的判断。

运行记录要说明"计划触发"和"业务执行"是否一致

一个绿色"任务完成"标记可能只代表工作台生成了摘要，未必代表 ERP 已成功查询或写入。建议把每次运行拆成计划触发、身份校验、连接器调用、目标系统回执、人工确认五个可核对的节点。审计记录至少能关联员工、任务运行标识、工具、目标系统、时间和结果；失败时保留不含敏感明文的原因摘要。

若设备在预定时间休眠，恢复后是否补跑、补跑几次、如何避免重复写入，需要按业务动作单独约定。已经提交的写入应以目标系统回执为准；没有回执时先查状态，再决定是否重试。关于重复写单的接口设计，可参看MCP 工具重复写单的验收方法。这些是实施建议，不是对任何工作台默认行为的描述。

无人值守不意味着跳过确认

先区分读取与写入：获权的只读查询可以按计划尝试，采购单提交、审批或删除则会改变业务事实。进入写入前应展示对象、变更内容、调用身份和影响，由有责任的员工确认。若运行时没人能确认，"等待确认"或"本次未执行"也是正确状态，不能为了让计划显示完成而代替员工点击。星云 PLUS AI 系统连接器的公开白皮书确认身份映射、能力授权、原系统权限判断、关键操作人工确认与调用审计；具体工作台怎样传递触发身份和接力确认，仍须在项目中验证。页面预填 ≠ 提交成功。

用五个样本验收

可以从一次只读查询开始，准备五个受控样本：正常触发时看所有者与调用员工是否留痕；触发前换账号时看是否暂停或重新授权；休眠或断网恢复时看补跑规则及重复动作；员工撤权后看服务端是否拒绝；需要写入确认而无人值守时看是否保持待确认并在确认后取得目标系统回执。每个样本都要对照原系统结果，记录预期、实际与异常状态。这里是方法示例，并非客户案例，也不承诺某款工作台默认执行这些策略。

示例状态机与接口契约

方法示例可把运行状态分为 scheduled、identity_checked、authorized、called、waiting_confirmation、confirmed、succeeded、failed。每一次状态变化都关联同一运行标识与员工身份，写入时另记录人工确认和目标系统回执。它不是产品内置状态枚举。测试时用两个权限不同的员工切换登录，分别触发只读查询；再模拟撤权、断网恢复与待确认写入。预期结果应写在测试表中，拒绝也要有可核对的返回，页面预填 ≠ 提交成功。

若身份校验通过而 ERP 权限拒绝，应保存两个不同环节的结果，不要把拒绝统一写成"系统故障"。若目标系统调用成功但结果缺少时间戳，应提醒使用者核对数据时点。若计划触发成功却没有连接器调用记录，要把它记为流程未进入业务层。这三个反例能帮助开发和运维定位责任边界。

资料来源：千问办公客户端更新日志 1.2.5（2026-10-09）；WorkBuddy 5.4.0 更新日志（2026-08-20）及其自动化说明（页面未标注发布日期）。官网原文于 2026-10-11 核验。