任务记录清理与业务结果撤销属于两件事。一个工作台可以删除会话或运行记录，但这不能推导出目标业务系统已经撤销单据，也不能说明连接服务和目标系统的审计会同步消失。企业需要先画出记录层次、归属和关联方式，再设计保存、删除与例外处理。
接口设计时至少区分请求已发起、目标系统已接受、业务已提交与最终结果可查询。为异常、超时、撤权和重试写测试用例，再将日志关联到真实业务键；不要用一次 HTTP 成功代表业务闭环。
先分清三层记录
第一层是工作台会话、任务状态、生成文件和定时执行结果，主要支持继续工作与个人复盘，也可能含敏感上下文。第二层是客户端自身的安全事件，例如权限拦截、工具启停或策略触发，字段与保存期限要按产品和企业配置确认。第三层是连接服务与目标业务系统的调用证据，回答谁在什么时间通过哪项能力访问了哪个系统、是否经过确认、执行结果对应什么业务对象。三层的用途和责任方不同，不能把一份聊天记录当作完整审计库，也不能因一份会话被删除就断言 ERP 单据消失。
为每类记录写清生命周期
记录清单至少列出产生系统、业务责任人、用途、访问角色、保存期限、删除执行方以及备份和导出副本。工作台任务删除可以是个人内容清理；业务系统的冲正、取消和审批应走目标系统既有流程，并保留前后业务事件的关联。保留期限没有跨企业通用答案，应由企业依据数据类别、制度和适用要求决定。敏感提示词、附件或返回内容不应因为"便于审计"就默认无限期复制。设计删除传播时还应看日志平台、监控告警、备份和人工导出，避免只清理主界面而忽略副本。
用最少字段建立可控关联
一次业务调用可考虑关联员工或主体标识、能力标识、目标系统、业务时间、确认结果、执行状态和业务单据标识。字段名称与可用性以目标环境为准；关键是让有权限的复核人员能沿关联键回到系统证据，同时限制无关人员查看敏感内容。关联键本身需要访问控制与留存规则。若连接服务记录"已发起"，目标系统记录"未提交"，应保留两个不同状态，不把调用成功写成业务成功。页面预填与实际提交也应分开；最终结果以目标系统回执和单据状态核实。
删除、撤销与保全要分流
若员工删除工作台中的测试任务，核验步骤是检查工作台可见性变化，再到目标系统查原始单据和系统审计。若业务本身需要撤销，应通过原系统的取消、冲正或审批动作处理，不能用删聊天记录代替。调查、争议或法务保全可能要求暂停正常清理，应有授权人、对象范围、期限和解除条件。对保全记录也要检查副本和权限，避免为了留证而扩大可见范围。每个分支都应留下谁发起、谁执行、何时完成、哪些记录未处理的说明。
用测试矩阵验收而非猜测
测试至少包括一次只读查询、一次经员工确认的写操作、一次调用失败、一次超时重试、一次员工撤权，以及业务已提交但会话随后清理的情形。分别检查工作台、连接服务和目标系统的记录落点；用两个权限不同的员工确认可见范围；测试关联标识是否能串起调用与单据。不要用生产数据做破坏性删除演练。再模拟到期删除或匿名化，检查备份、副本、导出和例外保全是否按政策处理。验收目标是按政策清理不再需要的工作台内容，同时在授权范围与保留期内仍能解释业务系统发生了什么。
排障时沿责任边界查证
若会话已删除却无法解释一张单据，先确认目标系统是否有业务单号和原始操作日志，再查连接服务的调用状态与员工身份，最后查看是否存在合法保全或已到期删除的限制。若只有协议层通知而没有持久记录，应将其视作运行期信号，不能直接充作集中可检索的业务审计。日志字段、保留期和跨系统关联方式需要在项目中明确，不应把某工作台的删除按钮推断为跨系统同步清理功能。排查结论应写明证据来自哪一层，以及哪一段仍缺数据。
产品能力与项目边界
官网确认的产品边界是：星云 PLUS AI 系统连接器支持按员工、系统、能力、时间和结果查询调用审计，并可配合员工身份映射、能力授权与关键操作人工确认。具体日志字段、保存期限、备份删除和与工作台任务的关联方式仍须在目标环境核实，不能承诺跨工作台自动同步。
结语：先用一个范围明确、权限可核、结果可回源系统验证的业务样本完成验收，再决定是否扩展到更多流程。
阅读原文：官网原文