背景问题

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

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

选定做法

应用机器人当审批人，只适用于接口创建实例：节点先设成「提交人自选」，创建时把机器人的 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。

事件到了之后，用 custom_key 判断是不是目标节点。先拿表单，再调外部接口：成功就同意，失败再看业务要不要整单驳回。飞书侧同意后自动往下走；拒绝会把整张单结束掉。

表单怎么取

approval_instance、approval_task 里只有状态和 ID，没有完整表单。请假、加班那类特殊事件会带一点业务字段，自定义审批还是要另查一次。

用实例详情接口，tenant_access_token 即可：

GET /open-apis/approval/v4/instances/{instance_code}Authorization: Bearer {tenant_access_token}

返回里的 form 是一段 JSON 字符串，解开后是控件数组，能看到 id、custom_id、name、type、value。同一条结果里还有 task_list、发起人、单号和时间线。控件对不上的话，再去查审批定义。

附件、图片链接大概 12 小时失效，要留文件就尽早下。

几个会踩的点

事件必须在 3 秒内应答。审批事件是按顺序推的，创建实例没回成功，后面的任务事件会堵住。先回、先落库，查表单和调外部接口放到后面做。

同一条任务可能推不止一次，用 task_id 做幂等，免得外部接口打两遍，或者同意点两次。

专用账号在飞书里会有待办。有人先在客户端处理了，接口再调就会失败。这个账号不要给人日常用；如果已经有人点过，系统当作处理完即可。

拒绝等于否决整张单。外部接口失败、只是暂时走不通时，不要直接拒绝，记下来转人工。确定要驳的时候再拒绝，意见里写清原因。时间线上记的是这个专用账号的操作。

流程里有条件分支，同意或拒绝时可能要把 form 带上，不然后面会走错枝。节点开了手写签名，接口会返回 1390018，这个节点别开签名。