AI Agent 查询 OA 审批：流程结束后，如何确认是否真的通过
OA 流程结束不等于申请通过。区分任务完成、流程终止与业务结论，核对申请轮次、最终决定和权限边界，避免智能体误报审批结果。
员工问智能体“我的 OA 审批通过了吗”，系统却只拿到一条“流程已结束”的通知。结束可能是同意、驳回、撤销，也可能是流程异常终止；某位审批人完成自己的任务，也不等于整张申请已经通过。AI Agent 对接 OA 时，关键不是尽快复述一条状态，而是确认这条状态属于哪次申请、处于哪个层级，以及是否已有可核实的最终决定。
把三种“完成”拆开
第一层是任务：某位审批人完成了自己负责的节点。第二层是流程实例：这次申请的整条流程不再运行。第三层才是业务结论：申请最终同意、驳回、撤回，或仍无法确认。它们不能共用一个“已完成”标签。顺序审批里，第一位审批人点击同意后，后面的节点仍可能待办；流程被取消，也不能被解释成“审批通过”。
Camunda 的流程实例状态定义区分 ACTIVE、COMPLETED 与 TERMINATED；其用户任务生命周期文档还区分任务完成、取消和分配。这里借用这些公开资料说明状态层级，不表示本站固定采用 Camunda，也不能把它的字段名称直接当作目标 OA 的接口契约。
先找到正确的申请实例
同一个业务申请号可能经历撤回、修改和重新提交。若只按标题、申请人或业务单号查一条“最近流程”，就可能把上一轮驳回当成当前结论。集成时应在源 OA 允许的范围内保留业务申请标识、流程实例标识、发起人、发起时间及可核对的修订或轮次信息；回答前先确认用户问的是哪一轮。没有稳定实例标识时，应明确要求进一步定位，而不是猜测。
本站系统集成页面公开了 OA/BPM 的制度查询、表单预填、审批材料准备与流程触发方向，接入方式可按接口条件选择 API 或消息队列。流程触发属于写操作，默认要求人工确认。本文讨论的是触发之后或已有申请的授权只读结果查询，并不宣称本站已经接通任意 OA 产品的实例查询接口。
通知到了，也要核对最终决定
回调、邮件或聊天卡片适合提醒状态变化，却不宜单独作为最终结果的权威来源。通知可能滞后，卡片可能没有随另一入口的操作更新；Microsoft 的审批已知问题文档就记录了卡片显示与审批中心状态不一致的情形。可采用的通用做法是：收到通知后，用授权接口按准确实例标识查询当前状态、最终结果和结果时间；接口不可用时保留“待核实”，不把通知文本改写成确定结论。
还要检查结果字段的含义：流程技术上完成，是否意味着业务上同意？某节点的“同意”是否仍需后续会签？“撤回”和“驳回”是否在该 OA 中分别存在？这些映射必须由业务方和 OA 管理员共同确认，写入接口说明及测试用例；不应让模型靠自然语言推断状态码。
把超时、撤销和重新提交列入回答边界
“等不到结果”不等于“审批被拒”。等待动作超时、通知丢失或适配层重启，可能仅说明读取链路失败。Microsoft 对审批动作的说明明确区分创建请求与等待响应；其已知问题文档也举出等待流程失效但审批项仍存在的情况。这是具体产品的示例，提醒我们不能把集成程序的执行状态替代 OA 的业务结果。
撤回后重新提交的申请，应把旧实例标注为旧轮次，新实例独立查询。如果目标系统只返回“已结束”而不返回结果原因，就应回答“该轮流程已结束，是否同意无法从当前接口确认”，附上可访问的源系统记录入口，而不是补造一个“通过”。源系统记录入口也必须经过当前用户的权限校验。
给读者一个可核对的状态模板
面向申请人的回答可分四项：申请与轮次、目前可确认的结果、结果来源及核对时间、尚不能确认的部分。例如构造场景：一张采购申请的第一轮被撤回，第二轮正在会签。即使第一轮回调显示“流程结束”，回答也应指向第二轮的在办状态；若 OA 回查失败，就说“第二轮当前状态待核实”，而不是沿用第一轮结果。这个例子是说明方法的虚构用例，不是本站客户案例。
结果展示不得超出用户授权范围。申请人能看到自己的结论，不代表能读取所有审批人的意见、附件或其他部门申请。详细节点记录可只在源 OA 中按权限查看；智能体侧保留用于定位的最小字段即可，避免复制敏感审批材料到普通对话日志。
用异常用例验收，而不是只测一张通过单
- 顺序节点：第一人同意、第二人待办时，不回答“整单已通过”。
- 不同终态：同意、驳回、撤回、技术终止分别显示，不把“已结束”统一映射为同意。
- 同号多轮：撤回后重提，按实例和轮次定位，不引用旧轮次结论。
- 通知冲突：卡片或回调与 OA 当前查询不一致时，标注待核实并以授权源记录为准。
- 接口故障：查询超时或字段缺失时，不编造结果；记录关联标识供排查。
- 权限边界：未授权用户不能通过自然语言问到他人的审批细节。
每个用例都应保存源 OA 的脱敏实例状态、适配层读取结果、用户最终看到的回答与时间点。若要设计触发前的人工确认，可另读工具调用人工审批；本文只解决 OA 流程已经存在时，如何向读者准确描述其当前与最终结果。
参考资料与适用边界
- Camunda 8 Docs：ProcessInstanceStateEnum，用于区分流程实例运行、完成和终止。
- Camunda 8 Docs：User task lifecycle，用于说明任务完成不等于整个流程的业务结论。
- Microsoft Learn：Differences between flow approval actions，用于区分创建审批与等待响应。
- Microsoft Learn：Known issues，用于说明通知展示可能不一致、等待链路与审批记录可能分离。
资料查阅日期：2026 年 9 月 28 日。上述文档是不同产品的技术事实和设计参照，不代表本站采用该产品、已有特定状态字段或已完成 OA 对接。实际状态映射、回查能力、授权范围与保留期限，应以项目所用 OA/BPM 的正式接口和业务规则为准。
