ZGI Workflow 并发控制：保护下游接口

工作流里有多个节点同时就绪时，若全部立即调用模型、HTTP 接口或数据库，下游系统容易出现限流、连接耗尽和超时。处理时可以给执行链设置并发额度：节点启动前先取得执行许可，额度用完就等待，节点完成后再释放。这样能够压住同时运行的节点数量。

ZGI Workflow 的图调度链路采用了这套思路。调度器发现就绪节点后，先申请执行许可；拿到许可的节点进入执行，完成后归还许可。并发控制因此发生在节点启动之前，不必等到下游接口已经承受过量请求后再处理错误。

图示说明：就绪节点先领取执行许可，超过额度的任务等待，执行结束后释放名额。

并行节点为什么会形成瞬时压力

一个节点完成后，多个后续节点可能同时满足依赖条件。比如材料处理流程拿到解析结果后，同时查询客户信息、检索制度、调用模型整理摘要，并向风控接口请求校验。流程图上只是四条分支，下游看到的却是同一时刻到来的四组请求。

压力还会继续放大。若一次任务触发四个并行节点，十次任务同时进入，就可能出现四十个调用。模型服务有并发配额，数据库有连接池，第三方接口也有每秒请求限制。任何一处变慢，等待中的连接和重试请求都会继续堆积。

并发额度可以限制同一时刻处于执行状态的节点。它适合约束瞬时运行数量，但无法单独处理所有流量问题。生产环境还要区分下面几种机制：

额度需要靠近真正受限的资源。若整个工作区共用同一个模型账号，可以对模型调用设置共享额度；若某个内部接口只能承受少量并行请求，可以围绕这类节点单独收紧。所有节点共用一个很小的额度会拖慢轻量任务，额度按资源边界划分更容易兼顾速度和稳定性。

队列中的优先级也要提前约定。面向用户的短任务、后台批处理和定时任务同时到来时，可以给交互任务保留容量，防止长批次占满全部名额。高风险写入还应经过审批或业务校验，不能仅凭获得执行许可就直接落库。

ZGI 当前公开代码可以确认节点调度前的许可申请与执行后的释放机制。具体额度、资源分组和速率策略仍需按部署环境配置，不能从这段调度逻辑推导出统一的默认值。并发许可负责控制启动数量，下游系统自身的限流和保护仍要保留。

可以准备一个响应时间可控的测试接口，让十到二十个任务同时进入同一条工作流。记录峰值执行数量、接口错误率、平均等待时间和整条流程耗时，再逐步调整并发额度。若峰值仍超过预期，检查是否存在绕过调度器的直接调用；若等待时间过长，则按模型、数据库和普通计算节点拆分资源边界。

测试还要加入超时和重复提交。让一个下游接口故意延迟，确认执行名额最终能够释放；让同一业务请求重复进入，确认外部写入有可查询的业务标识。并发额度通过这两类测试后，才适合承接真实业务流量。