Skip to main content
当支持工作流需要满足以下要求时,可以使用此方案:
  • 从仪表板预设继承路由和提示默认值
  • 返回严格的结构化输出
  • 暂停高风险案例以供人工审核
  • 将网关失败保留在日志中,而不是隐藏在代理代码里

1. 从预设开始

创建一个名为 support-triage 的预设,用于管理:
  • 默认路由模型或路由器目标
  • 提供商偏好
  • 支持系统提示
  • 稳定的解码参数
这样代理代码就可以专注于工作流控制,而无需重复请求策略。

2. 定义范围明确的分流契约

首次输出结构应尽量精简,便于操作人员快速检查。

3. 创建由预设驱动的代理

SDK 会将 preset: "support-triage" 解析为网关别名形式 @support-triage。

4. 配置网关适配器

对于每次分流都应保持固定的部分,请使用适配器默认值:

5. 以有限次重试运行工作流

如果运行暂停等待审核,请显式恢复:

6. 将网关失败视为运行事件

不要在代理回调链中吞掉失败,从而将其隐藏。 应显式捕获 AgentGatewayError:
然后:
  1. 让运行时持久化 failed 的运行和步骤状态
  2. 在后续恢复流程中,如果原始异常已不在内存中,请检查 loaded.run.errorDetails 或 loaded.steps[n].errorDetails
  3. 检查请求详情中的以下内容:
    • 护栏执行情况
    • 路由详情
    • 插件执行情况
    • 请求 ID 和提供商数据
以下情况尤其需要注意:
  • 护栏拦截了请求
  • 预设允许列表拒绝了所请求的模型
  • 提供商凭证或启用筛选条件移除了可路由候选项
  • response healing 无法恢复符合 schema 的 JSON

7. 验证事项

分别完成一次成功运行和一次故意设置为高风险的运行后,确认:
  • 请求详情视图显示由预设驱动的请求目标
  • 高风险案例会暂停在 waiting_for_human 状态
  • 重试的模型步骤会持久化 modelAttempts
  • 护栏或预设导致的失败会显示在请求详情中,而不会隐藏在代理异常里

相关指南

最后修改于 2026年10月2日