工作流分支越来越多，通常说明不同类型的规则被塞进了同一段 Prompt。模型既要理解用户意图，又要记住业务条件、选择工具、判断权限和决定异常处理，任何一条规则变化都可能牵动整段提示词。更稳的做法，是先给规则分类，再放进知识、Skill、Workflow 或人工审批对应的位置。
ZGI 这类可自托管 Agent Runtime 可以把企业知识、Skills、工具、Workflow 和模型放在同一工作区协同运行。团队仍要先划清边界：哪些内容供模型参考，哪些条件由流程判断，哪些动作交给可复用能力，哪些结果必须由人确认。
Prompt 适合处理理解与表达
Prompt 可以说明角色、目标、输出要求和当前任务背景。它擅长处理自然语言中的模糊表达，例如判断用户想查询订单、申请退款，还是补充材料。若把金额门槛、部门权限、接口参数、失败重试和审批人也全部写进去，规则很快会变成长文。
长 Prompt 的问题很实际。同一条件可能在不同位置重复出现；一次小改动会影响其他判断；业务人员难以确认当前生效的版本；测试人员也很难把每一条规则单独覆盖。模型可以读懂这些文字，却无法替代明确的流程控制。
| 规则类型 | 更适合放置的位置 | 常见例子 |
|---|---|---|
| 背景与制度 | 企业知识 | 报销制度、产品说明、服务范围 |
| 可复用动作 | Skill 或工具 | 查订单、生成文件、调用接口 |
| 确定性条件 | Workflow | 金额判断、字段校验、异常分支 |
| 高风险决定 | 人工审批 | 付款、删除、对外发送、正式提交 |
规则拆开后，修改才容易验证
以采购申请为例。员工用自然语言描述需求，模型负责提取品类、数量、预算和用途；知识库提供采购制度与供应商要求；Workflow 检查字段是否齐全，并按照金额进入不同分支；查询预算、创建申请单等动作由工具或 Skill 执行；超过权限范围的申请进入人工审查。
当审批金额发生调整，只需修改对应的流程条件。采购制度更新时，替换知识来源。接口参数变化时，维护执行动作。各类变化落在清楚的位置，测试也可以围绕单个环节展开。
在 ZGI 中搭建这类流程时，可以先画出一张规则归属表，再开始连接节点。条件分支负责可明确计算的判断；用户问答节点补齐缺失信息；人工审查节点留住关键决策；重复出现的查询、转换和文件处理整理成 Skill。模型仍参与理解和生成，确定性业务规则则拥有可查看的执行路径。
分支数量不是唯一信号
分支多并不一定代表设计有问题。复杂业务本来就可能包含多种条件。真正需要警惕的是，同一规则同时出现在 Prompt、代码和流程节点里，修改后又没有统一测试。此时即使画布看起来整齐，运行结果也可能因版本不一致而变化。
上线前可以挑选正常、缺字段、越权、重复提交和接口失败等样本，逐项检查规则落点、执行路径和最终状态。先把规则放对位置，再讨论如何减少节点，工作流会更容易维护，也更适合进入真实业务。
GitHub：https://github.com/zgiai/zgi