正在统计访客…
浏览全部文档
开始 · 9找到适合你的 Runifold 学习路径45 分钟掌握 Runifold理解完整的 Runifold 平台第一次可信运行选择正确的执行 API选择 Crate 与 Cargo Feature构建常见 Runifold 应用Runifold 常见问题排查 Runifold 应用故障
执行内核 · 7理解 RunContext安全协调外部副作用使用预算与取消限制工作安全地处理错误与重试事件、Journal 与执行证据设计 Capability 安全执行从 Checkpoint 安全恢复
模型与服务商 · 7在避免重复输出的前提下路由模型选择并配置模型服务商使用服务商中立的模型协议基于 Provider Runtime 契约构建使用 OpenAI 控制面与 Realtime API测试与 Benchmark Provider Adapter配置 OpenAI、Anthropic、Gemini 与 Ollama
Agent · 7构建并配置 Agent为 Agent 添加类型化工具加入会话与语义记忆安全地委派给子 Agent返回结构化 Rust 值在不丢失语义的前提下流式输出使用检索为 Agent 提供事实依据
持久工作流 · 7组合确定性工作流让工作流持久化运行持久工作流 Worker协调 Timer、Signal 与持久等待运行多租户工作流基础设施运行并行 Branch 与安全 Race对持久 Workflow 进行版本管理
集成 · 7通过 MCP 连接外部能力选择存储与持久化边界通过 MCP Tasks 暴露持久工作构建并评估检索流水线使用 MCP Resources、Prompts 与 Sampling在不跨越权限的前提下缓存 MCP 响应在 Rust Web Service 中部署 Runifold
质量与运维 · 10在没有网络的情况下测试评估质量并阻止回归观测完整运行树在浏览器与边缘环境安全运行准确理解可靠性声明在 CI 中运行可复现评测使用 SLO 运维 Runifold治理 Task 保留与删除把审计证据归档到 S3-Compatible WORM 存储管理兼容性与可信发布
文档/可信执行
第一次使用?通过 45 分钟核心课程建立完整心智模型
可信执行

安全地处理错误与重试

区分构建错误、执行错误、可安全重试的传输错误和不确定副作用。

实践指南·14 min

错误分层

在最了解错误语义的边界处理它:

层级示例常见处理
构建工具重复、策略无效启动时失败
模型限流、错误响应按分类路由或重试
工具输入无效、能力被拒返回安全的工具结果
运行Deadline、预算、取消终止运行树
工作流Lease 丢失、版本过期从持久状态恢复

不要把所有错误压成一个字符串。保留类型化来源,并给调用方提供安全信息。

检查类型化原因

Agent::prompt_text 返回 AgentError。先匹配错误层,再转换成应用自己的 HTTP、 Queue 或 CLI 错误。公共错误 Enum 是 non-exhaustive,保留通配分支才能兼容未来版本。

use runifold::{Agent, AgentError};
 
async fn answer(agent: &Agent, prompt: &str) -> anyhow::Result<String> {
    match agent.prompt_text(prompt).await {
        Ok(text) => Ok(text),
        Err(AgentError::Model(error)) => {
            eprintln!(
                "model kind={:?} retry_safety={:?} provider={:?}",
                error.kind, error.retry_safety, error.provider
            );
            Err(error.into())
        }
        Err(AgentError::Budget(error)) => {
            eprintln!("budget stopped the run: {error}");
            Err(error.into())
        }
        Err(AgentError::AmbiguousCheckpoint { turn }) => {
            anyhow::bail!("turn {turn} may already have produced an external result")
        }
        Err(error) => Err(error.into()),
    }
}

对外暴露稳定的应用错误码,但在受控诊断中保留类型化 Source 与 Run ID。不要把服务商 Body、Prompt、Tool 参数或凭证作为错误详情返回给调用方。

安全重试

只有适配器明确判断为安全时才重试。请求尚未发出前断网,与服务商可能已经接收并计费 后的超时,语义完全不同。

使用有上限、带抖动的指数退避。重试额度应小于整次请求的 Deadline 与资源预算。

熔断器

runtime() 会在服务商外层组合保守的重试和熔断默认值。通过 route_health() 观察 运行状态,在每个请求都付出完整超时前绕开故障边缘。

熔断器保护容量,但不能证明服务商健康;需要配合健康检查与结果指标。

不确定的副作用

不要盲目重试非幂等外部操作。目标支持时使用幂等 Key,否则用 Runifold 的写前 Effect 边界,在执行前记录意图。

如果无法证明是否完成,应标记为 Ambiguous 并进行对账。对支付、邮件或破坏性工具, “大概失败了”远远不够安全。

重试决策表

观察结果自动重试?处理方式
本地校验或不支持的 Feature修正输入、Feature Policy 或模型选择
已取消或超过 Deadline返回终止状态;调用方可创建新任务
被分类为安全的传输故障策略范围内使用有上限退避和剩余 Deadline
被分类为安全的 Provider 限流策略范围内遵守 Provider 延迟与全局预算
Provider 协议格式错误通常否保存安全诊断并切换路由
Tool 输入被拒绝不重复相同调用让模型在轮次预算内修正参数
已确认 Key 的幂等写入取决于策略通过相同 Effect 边界重放
非幂等或不确定写入先与目标系统对账

运行排查顺序

  1. 找到根 Run ID 和终止错误种类。
  2. 在调查 Provider 前,先检查取消、Deadline 与预算。
  3. 查看 runtime.route_health() 中是否有 Open 或 Half-open 路由。
  4. 用 Journal 和 Telemetry 关联失败 Attempt,但不要暴露正文。
  5. 确认 Effect Intent、Completion 或 Ambiguous 状态是否已经持久化。
  6. 只通过原有策略边界重试,不要在 prompt_text 外面临时套无限循环。