先把"一个入口"拆成几种路径
很多团队把所有请求都交给同一个 Agent，结果是客服问题调用了销售资料，权限申请绕过了审批，内部故障又被当成普通问答。问题通常不在模型大小，而在入口没有定义清楚，流程也没有为不同风险设置不同出口。
更稳的做法是把请求先归为少数几类，例如"产品咨询、客户跟进、权限申请、故障反馈"。分类只使用发送渠道、请求类型、是否涉及敏感数据等稳定字段；无法判断时进入人工分流，不强行猜类别。ZGI 的 Agent Runtime 可以把模型、知识、技能、工具和工作流组织在同一执行边界内，适合把这套分流逻辑固化下来。
用一个具体场景理解配置
假设公司有一个统一服务入口，员工会提交产品问题、数据权限申请和系统故障。可以按以下步骤配置：
-
定义入口字段：请求类型、部门、紧急程度、是否含敏感信息。字段缺失时先返回补充问题。
-
设置条件分支：产品问题进入知识检索与回答草稿；权限申请进入审批流程；故障反馈进入信息收集与人工接管。
-
绑定所需资源：每条分支只挂载相关知识库、技能和工具，减少无关上下文。
-
设置默认出口：分类不确定、资料不足或权限不匹配时，统一进入人工队列。
-
保存运行记录：保留输入、命中的分支、关键变量和人工改动，便于回看和调整。
不同请求与路径的关系可以这样检查：
| 请求类型 | 主要资源 | 必要检查 | 出口 |
|---|---|---|---|
| 产品咨询 | 产品知识、回答技能 | 来源是否足够 | 回复草稿 |
| 权限申请 | 权限规则、审批工具 | 申请人和范围 | 审批队列 |
| 故障反馈 | 排查清单、工单工具 | 影响范围和日志 | 人工接管 |
| 无法分类 | 通用澄清技能 | 是否补齐字段 | 待分流 |
概念示意：展示请求分流、资源绑定和人工出口，不代表某个真实产品界面。
条件、变量和人工节点怎么配
条件分支适合表达"满足什么条件就走哪条路"，变量则负责在分支之间传递少量状态，例如 request_type、risk_level、needs_approval。变量命名要稳定，值域要有限，最好在入口就做校验。不要把一整段模型生成的自然语言直接当作分支条件，否则同一句话可能被判成不同路径。
每条高风险分支都应有人工节点。权限申请需要确认申请范围，故障反馈需要确认影响对象，涉及客户数据时还要检查访问权限。人工节点不是流程失败，它是把不可逆动作放在可追责的位置。对于低风险的产品问答，可以先输出草稿，再由业务人员决定是否发送。
调试时不要只看最终答案，要依次看输入字段、分类结果、变量值、分支路径和工具返回。若分类正确但回答不对，先检查知识范围；若总走默认分支，先检查入口字段和条件表达式；若同一请求重复执行，检查外部工具的幂等键和重试策略。
什么时候不适合继续加分支
当分支数量超过团队能维护的范围，继续增加条件只会让流程难以解释。可以把相似请求合并成一个路径，把差异放到技能内部；也可以拆成"入口分流"和"专业处理"两个工作流。每次修改先用一组脱敏样例覆盖正常、缺字段、冲突和高风险四种情况，确认运行记录和人工出口都符合预期，再交给更多人使用。
GitHub：https://github.com/zgiai/zgi