飞书审批联动机器人实现业务自动化

用户在审批中心正常填单，走到某一个节点时，希望由我们的服务去调外部接口，再决定过还是驳。飞书审批做不到在流程里挂代码，设计时也选不了应用机器人当审批人；单子交上去之后，同样没有接口能改这个节点上的人。

客服给的办法能用。这个节点挂一个通讯录里的专用账号——他们口头上叫「虚拟机器人」，其实就是带员工身份的账号，不是开发者后台那个应用。任务落到这个人身上以后，我们收事件、调外部系统，再替他点同意或拒绝。飞书收到同意，单子自己往下走。

选定做法

应用机器人当审批人，只适用于接口创建实例：节点先设成「提交人自选」，创建时把机器人的 open_id 写进 node_approver_open_id_list。员工自己在审批中心点提交，选人器里一般选不到这个机器人，所以这条路不适合现在的场景。

转交、加签也解决不了。转交只能动已经生成的任务，文档里写的是转给真人；加签是加人，不是改节点审批人。node_approver_open_id_list 只在创建实例时生效，事后 PATCH 节点 open_id 没有对应接口。

所以手工提单这边，审批人在设计阶段就定死为专用账号。系统不改节点，只在任务到达时代为处理。

配置

审批管理后台里，把目标节点的审批人设成专用账号。后台地址后面加上 ?devMode=on，给这个节点起一个自定义 ID，后面事件里用 custom_key 对得上。控件也尽量写上 custom_id，不要只靠系统自动生成的 id 去解析表单。

自建应用要订两处：开发者后台订「审批任务状态变更」（实例状态变更建议一起订），再调一次「订阅审批事件」，把这条审批定义的 approval_code 订上。少一步，事件都收不到。手工提交和接口提单都会推，身份不限。

应用权限至少覆盖事件订阅和原生审批任务操作。同意、拒绝用 tenant_access_token 即可，专用账号不用登录客户端；请求体里的 user_id 必须是这个账号，并带上 instance_code、task_id。对不上会报 no operation permission 或 task not found。