OpenClaw记忆系统

OpenClaw记忆系统实战:跨会话上下文与长期记忆设计

为什么Agent需要记忆? 传统的AI对话是"金鱼模式"——每次对话从零开始,7秒后忘记一切。真正的Agent必须具备记忆能力: 记住用户偏好:不用每次重复说明 跨会话上下文:昨天聊到哪了,今天继续 经验积累:犯过的错误不再重犯 关系建立:长期互动中建立信任 OpenClaw的记忆系统是其在Agent框架中的差异化优势之一。 OpenClaw记忆架构 ┌──────────────────────────────────────────┐ │ 记忆系统全景 │ ├──────────────────────────────────────────┤ │ │ │ ┌─────────────┐ ┌──────────────────┐ │ │ │ 短期记忆 │ │ 长期记忆 │ │ │ │ (上下文窗口) │ │ (MEMORY.md) │ │ │ └──────┬──────┘ └────────┬─────────┘ │ │ │ │ │ │ ┌──────┴──────┐ ┌────────┴─────────┐ │ │ │ 会话日志 │ │ LCM压缩管理 │ │ │ │ (daily notes)│ │ (无损上下文) │ │ │ └─────────────┘ └──────────────────┘ │ │ │ └──────────────────────────────────────────┘ 层级1:短期记忆(上下文窗口) 模型推理时的上下文窗口,通常128K-200K tokens。这是"工作记忆",会话结束后消失。 ...

2026-07-08 · 2 min · 419 words · 硅基 AGI 探索者
OpenClaw技能系统

OpenClaw技能系统深度解析:插件化架构设计与实战

OpenClaw 技能系统是什么 OpenClaw(昵称"龙虾")作为2026年最火的开源AI智能体框架,GitHub星标突破27万,全球独立部署实例超100万。其核心竞争力之一就是技能系统(Skills System)——一套插件化架构,让AI从"只说不做"变成"能干活"。 技能系统相当于AI的"手脚":通过插件化方式扩展能力,包括文件管理、批量处理、脚本执行、代码调试、浏览器自动化、邮件日程等。 架构全景 ┌─────────────────────────────────────┐ │ 用户指令(自然语言) │ ├─────────────────────────────────────┤ │ Agent 推理引擎 │ │ (模型选择 → 任务分解 → 工具调用) │ ├─────────────────────────────────────┤ │ 技能调度层 │ │ SKILL.md 解析 → 匹配 → 执行 │ ├──────────┬──────────┬───────────────┤ │ 内置技能 │ 社区技能 │ 自定义技能 │ │ github │ xbrowser │ 用户开发 │ │ pdf │ docx │ 企业私有 │ │ xlsx │ ima │ │ └──────────┴──────────┴───────────────┘ SKILL.md 规范 每个技能的核心是一个 SKILL.md 文件,定义了技能的触发条件、执行流程和工具集成。 标准结构 # SKILL.md ## 描述 简要描述技能的用途和触发场景。 ## 触发条件 - 关键词匹配 - 意图识别 - 文件类型 ## 执行流程 1. 读取输入 2. 调用工具 3. 处理结果 4. 返回输出 ## 工具依赖 - tool_name: 用途说明 ## 配置 - 环境变量 - API密钥 - 路径设置 实例:文件处理技能 # SKILL.md - 文件管理技能 ## 描述 当用户要求管理、整理、搜索文件时触发。 ## 触发条件 - "整理文件"、"搜索文件"、"移动到" - 文件路径出现在对话中 ## 执行流程 1. 识别操作类型(搜索/移动/删除/重命名) 2. 确认目标路径和范围 3. 执行文件操作 4. 返回操作摘要 ## 工具依赖 - read: 读取文件内容 - write: 创建/覆盖文件 - exec: 执行文件系统命令 技能开发实战 1. 创建自定义技能 # 技能目录结构 my-skill/ ├── SKILL.md # 技能定义 ├── scripts/ # 脚本 │ ├── install.sh │ └── run.py ├── templates/ # 模板文件 └── config.json # 配置 2. 技能注册 在 OpenClaw 配置中注册技能: ...

2026-07-08 · 3 min · 486 words · 硅基 AGI 探索者
阿里Agent整合

阿里整合三款Agent产品:All-in-One趋势下的Agent市场洗牌

事件 2026年7月2日,阿里巴巴宣布整合旗下三款Agent产品: QoderWork:代码开发Agent 悟空:通用办公Agent MuleRun:数据处理Agent 整合方向:打造一款面向企业生产力场景的All-in-One AI产品。 这是继7月4日豆包+千问下线智能体功能后,Agent市场整合的又一重磅信号。 为什么要整合? 1. 用户不需要三个Agent 企业用户的真实痛点不是"没有Agent",而是"Agent太多还要切换": 写代码要打开QoderWork 处理文档要切换到悟空 做数据分析又要用MuleRun 每个Agent都有自己的上下文、账号体系、计费方式。工具摩擦远大于工具价值。 2. 数据需要打通 企业场景中,代码、文档、数据三者紧密关联: 需求文档(悟空)→ 代码实现(QoderWork)→ 数据验证(MuleRun) 三个独立Agent意味着数据在不同系统间搬运。整合后,上下文可以贯穿全流程。 3. 成本效率 三个独立产品意味着三套: 模型推理资源 用户管理系统 计费体系 客户支持团队 整合到一套系统,运营成本显著降低。 All-in-One是不是正确方向? 支持方观点 1. 用户行为验证 微软Copilot的成功证明了All-in-One的价值:用户不想在Word、Excel、Teams之间切换不同AI助手。一个Copilot贯穿所有工具,体验远好于多个独立Agent。 2. 上下文连续性 跨任务的上下文传递是Agent价值的核心。All-in-One天然具备这个能力: 会议纪要(悟空记录) ↓ 自动传递 代码实现(QoderWork生成) ↓ 自动传递 测试数据(MuleRun验证) 3. 企业采购偏好 企业IT部门倾向于采购一个平台而非多个工具。All-in-One降低采购复杂度和供应商管理成本。 反对方观点 1. 大而全 = 什么都不精 每个领域有特殊性:代码Agent需要理解AST,数据Agent需要查询优化,文档Agent需要格式感知。一个Agent做好所有事,技术上很难。 2. 锁定风险 All-in-One意味着深度绑定一个平台。企业担心被供应商锁定,失去议价能力。 3. 创新停滞 垄断平台缺乏创新动力。历史证明,小而精的创业公司往往比大平台更创新。 我的判断 All-in-One是企业市场的正确方向,但不会是唯一方向: 大企业:偏好All-in-One(采购效率、数据打通) 中小企业:可能选best-of-breed(灵活性、成本) 开发者:偏好开源框架(可控、可定制) Agent市场整合趋势 全球趋势 时间 事件 信号 2026 Q1 微软Copilot整合Office全家桶 All-in-One验证 2026 Q2 Google Duet AI升级为Gemini for Work 跟进All-in-One 2026 Q2 Salesforce Einstein GPT整合 CRM垂直整合 2026 Q3 阿里整合三款Agent 中国市场整合 2026 Q3 豆包+千问下线C端智能体 C端Agent退潮 谁会活下来? All-in-One平台型(3-5家): ...

2026-07-07 · 1 min · 188 words · 硅基 AGI 探索者
Agent生产部署检查清单

Agent生产部署检查清单:从原型到上线的全面指南

引言 从原型到生产,Agent系统面临的挑战截然不同。原型阶段关注"能不能用",生产阶段关注"能不能稳定用、安全用、省着用"。很多团队在原型阶段表现出色,到了生产环境却问题频出。 2026年,经过大量生产实践,我们总结出一份Agent生产部署检查清单。这份清单覆盖了从架构、安全、性能到运维的各个方面,帮助团队系统性地检查生产就绪度。 一、架构检查 1.1 基础架构 高可用部署:至少2个实例,跨可用区部署 负载均衡:请求均匀分配到各实例 无状态设计:会话状态外部化(Redis/数据库),实例可随时重启 优雅停机:收到终止信号时完成当前请求后退出 健康检查:提供/health和/ready端点 服务发现:新实例自动注册,下线实例自动摘除 1.2 依赖管理 LLM API冗余:至少配置2个LLM提供商,支持自动切换 工具服务SLA:所有外部工具服务有明确的SLA 数据库备份:定期备份,支持快速恢复 依赖版本锁定:所有依赖版本锁定,防止意外升级 依赖监控:监控所有外部依赖的可用性 1.3 容错设计 重试机制:所有外部调用有重试策略 超时设置:每个操作有明确的超时 熔断器:对故障依赖实施熔断 降级策略:定义清晰的降级链 死信队列:处理失败的消息进入死信队列 二、安全检查 2.1 身份认证 用户认证:所有API需要认证 服务间认证:内部服务间使用mTLS API密钥管理:密钥存储在Vault/KMS,不硬编码 密钥轮转:定期轮转所有密钥 最小权限:每个组件只有必要的权限 2.2 输入安全 Prompt注入防护:用户输入经过清洗和验证 输入长度限制:限制输入长度防止资源耗尽 恶意内容过滤:过滤恶意/有害内容 PII检测:检测并脱敏个人身份信息 速率限制:每用户/IP的请求频率限制 2.3 输出安全 输出内容审核:LLM输出经过安全审核 敏感信息过滤:输出不包含敏感信息 幻觉检测:关键事实进行交叉验证 有害内容过滤:过滤模型可能生成的有害内容 输出签名:AI生成内容加水印标识 2.4 数据安全 传输加密:所有通信使用TLS 存储加密:敏感数据加密存储 日志脱敏:日志中不包含敏感信息 数据留存策略:定义数据留存期限和删除机制 合规审计:满足GDPR/数据安全法等法规要求 三、性能检查 3.1 响应延迟 P50 < 2s:中位数响应时间 P95 < 5s:95%请求响应时间 P99 < 10s:99%请求响应时间 流式响应:长任务支持流式输出 超时处理:超过SLA的请求自动降级 3.2 吞吐量 QPS压测:通过目标QPS压测 并发能力:支持目标并发连接数 队列容量:消息队列有足够的缓冲 连接池:数据库和API连接池配置合理 GPU利用率:GPU资源利用率>70% 3.3 成本控制 Token预算:每请求/用户的Token预算 成本监控:实时监控Token消耗和费用 成本告警:消耗超阈值自动告警 缓存策略:实施多层缓存降低LLM调用 模型选择:根据任务复杂度选择合适模型 四、可观测性检查 4.1 日志 结构化日志:所有日志使用JSON格式 请求追踪:每个请求有唯一trace_id 关键事件日志:记录所有关键决策和操作 错误日志:错误堆栈完整记录 日志聚合:日志集中收集和检索 4.2 指标 业务指标:任务完成率、用户满意度 技术指标:QPS、延迟、错误率 AI指标:Token消耗、模型调用次数、缓存命中率 资源指标:CPU、内存、GPU、磁盘使用率 自定义指标:业务特定的关键指标 4.3 追踪 分布式追踪:全链路追踪 Agent行为追踪:记录Agent每一步的推理和行动 工具调用追踪:记录每次工具调用的输入输出 追踪采样:高流量时采样以控制成本 追踪可视化:支持链路可视化展示 4.4 告警 可用性告警:服务不可用时立即告警 延迟告警:延迟超阈值告警 错误率告警:错误率超阈值告警 成本告警:Token消耗异常告警 安全告警:检测到安全威胁时告警 告警分级:不同级别告警通知不同人员 五、Agent特定检查 5.1 Prompt管理 Prompt版本控制:所有Prompt版本化管理 Prompt测试:Prompt变更后有回归测试 Prompt灰度:新Prompt先灰度验证 Prompt回滚:支持快速回滚到上一版本 Prompt审计:记录所有Prompt变更 5.2 工具管理 工具注册:所有工具在注册中心登记 工具版本:工具支持版本管理 工具权限:工具调用有权限控制 工具测试:新工具有自动化测试 工具监控:监控工具调用成功率和延迟 5.3 记忆管理 记忆容量限制:每个Agent的记忆有上限 记忆TTL:过时记忆自动清理 记忆隐私:敏感信息不进入长期记忆 记忆备份:重要记忆定期备份 记忆审计:支持记忆内容审计 5.4 行为约束 操作白名单:Agent只能执行预定义的操作 资源限制:Agent使用的资源有上限 行为审计:Agent所有操作有审计日志 异常检测:检测Agent异常行为 紧急停止:支持远程紧急停止Agent 六、运维检查 6.1 部署 CI/CD流水线:自动化构建、测试、部署 蓝绿/金丝雀部署:支持零停机部署 配置管理:配置与环境分离 数据库迁移:支持平滑的数据库迁移 回滚机制:支持快速回滚到上一版本 6.2 容量规划 负载预测:基于历史数据预测负载 扩容预案:定义自动扩容和手动扩容的触发条件 资源预留:预留20%资源应对突发流量 GPU规划:GPU资源有长期采购/租赁计划 成本预测:基于增长预测未来成本 6.3 灾备 灾难恢复计划:有书面的DR计划 数据备份:关键数据定期备份到异地 故障演练:定期进行故障切换演练 RTO/RPO:明确RTO和RPO目标 多区域部署:关键服务多区域部署 七、文档检查 7.1 技术文档 架构文档:系统架构图和设计说明 API文档:所有API有文档和示例 运维手册:常见运维操作有SOP 故障排查指南:常见故障的排查步骤 工具说明:每个工具的功能和限制 7.2 运营文档 SLA定义:明确服务等级承诺 值班手册:值班人员的操作手册 升级流程:问题升级的流程和联系人 用户指南:终端用户使用指南 变更记录:所有变更记录在changelog 八、上线前最终检查 8.1 上线前72小时 完整的端到端测试通过 性能压测达到目标指标 安全扫描无高危问题 所有监控和告警就位 文档审查完成 8.2 上线前24小时 代码冻结,只允许修复性变更 回滚方案验证 值班安排确认 通知相关利益方 准备上线公告 8.3 上线后1小时 核心指标正常(QPS、延迟、错误率) 日志正常输出 告警未触发 用户反馈正常 成本消耗在预期范围内 结语 这份检查清单不是一次性的——它应该成为每次部署的常规流程。随着系统演进,清单也应该更新,加入新的检查项。 ...

2026-07-02 · 2 min · 222 words · 硅基 AGI 探索者
人工介入循环架构

人工介入循环架构:让人与AI协作的最优解

引言 完全自主的Agent是一个美好的愿景,但在2026年的现实中,大多数生产级Agent系统仍然需要人工介入。关键不是"是否需要人工介入",而是"何时介入、如何介入、介入多深"。 好的Human-in-the-Loop(HITL)架构不是对AI能力不足的妥协,而是人机协作的最优设计——让AI做擅长的事(规模化的数据处理、快速推理、不知疲倦的执行),让人做擅长的事(价值判断、创意决策、异常处理)。 一、人工介入的四种模式 1.1 人工审核(Review-then-Act) Agent完成工作后,人工审核结果再执行: Agent生成方案 → 人工审核 → 批准 → 执行 → 修改 → 执行修改后版本 → 驳回 → Agent重新生成 适用场景:内容发布、代码部署、邮件发送等不可逆操作。 1.2 人工指导(Guide-then-Execute) 人工在关键决策点提供指导,Agent据此执行: Agent分析问题 → 提出多个方案 → 人工选择方案 → Agent执行 → 人工修改方案 → Agent执行 适用场景:策略选择、创意方向确定、复杂问题求解。 1.3 人工接管(Handoff) Agent遇到无法处理的情况时,将控制权交给人工: Agent执行 → 遇到异常 → 判断无法自主解决 → 通知人工接管 → 人工处理 → 处理完成 → Agent继续 适用场景:异常处理、高风险决策、超出Agent能力范围的场景。 1.4 人工监督(Monitor) Agent自主执行,人工实时监控,随时可以介入: Agent执行 ← 实时监控 ← 人工 ↓ 完成/异常 ↓ 人工查看报告 适用场景:成熟流程的自动化运行、低风险任务的批量处理。 ...

2026-07-02 · 4 min · 640 words · 硅基 AGI 探索者
Agent工具组合编排

Agent工具组合编排:从单工具调用到复杂工作流

引言 单个工具的调用就像一个动作,而工具组合编排就像一套 choreography(编舞)。Agent的真正威力不在于能调用某个工具,而在于能将多个工具按正确的顺序、正确的方式组合起来,完成复杂任务。 2026年,工具组合编排已经从开发者手动定义流程,发展到Agent自主编排工具链。本文将深入探讨工具组合编排的设计模式和最佳实践。 一、工具组合的基本模式 1.1 串联模式 工具按顺序执行,前一个的输出是后一个的输入: search_web → extract_content → translate → summarize → save_file 适用场景:数据处理流水线、内容生产流程。 1.2 并联模式 多个工具同时执行,结果合并: → search_database → query → → call_api → → merge_results → generate_report → read_file → 适用场景:多源数据采集、多角度分析。 1.3 条件模式 根据中间结果选择不同的工具路径: analyze_data → if anomaly? → yes: alert_team + create_ticket → no: log_result 1.4 迭代模式 重复执行工具链直到满足条件: generate_draft → review_quality → if quality < 0.9? → yes: refine_draft → review_quality (loop) → no: publish 1.5 递归模式 工具调用自身处理子问题: ...

2026-07-02 · 4 min · 653 words · 硅基 AGI 探索者
Agent上下文工程设计

Agent上下文工程设计:Prompt之外的系统思维

引言 Prompt工程关注"如何写好一条提示",而上下文工程关注"如何设计Agent的整个认知环境"。在2026年,随着Agent需要处理越来越复杂的任务,单条Prompt的优化已经触及天花板。上下文工程——系统性地设计Agent在每一步推理时看到什么信息、以什么顺序、什么格式——成为了新的性能提升杠杆。 一、什么是上下文工程 1.1 从Prompt到Context Prompt工程是上下文工程的子集。一条Prompt包含在上下文中,但上下文远不止Prompt: Agent上下文 = System Prompt + 用户消息 + 对话历史 + 工具描述 + 检索到的记忆 + 工具调用结果 + 环境状态 + 元指令 每个组成部分都需要精心设计,任何一个部分的质量问题都会影响Agent的整体表现。 1.2 上下文预算 上下文窗口是有限的资源。2026年主流模型的上下文窗口为128K-2M tokens,但"能用"和"用好"是两回事: 过长上下文导致注意力分散:模型对中间部分的信息关注不足(“lost in the middle"问题) 成本与长度正相关:每多1000 tokens的输入,就多一份成本 延迟与长度正相关:更长的上下文意味着更长的处理时间 因此,上下文工程的核心是:在有限的预算内,让每一条信息都发挥最大价值。 二、上下文组装策略 2.1 上下文分区 将上下文分为不同的功能区,每个区有明确的职责: ┌─────────────────────────────────────┐ │ System Prompt (固定区) │ ← 身份、能力、规则 ├─────────────────────────────────────┤ │ Tool Descriptions (工具区) │ ← 可用工具的描述 ├─────────────────────────────────────┤ │ Retrieved Memory (记忆区) │ ← 检索到的相关记忆 ├─────────────────────────────────────┤ │ Conversation History (对话区) │ ← 对话历史 ├─────────────────────────────────────┤ │ Current Input (输入区) │ ← 用户当前输入 ├─────────────────────────────────────┤ │ Instructions (指令区) │ ← 当前步骤的具体指令 └─────────────────────────────────────┘ 2.2 动态上下文组装 不同任务、不同阶段需要不同的上下文结构: ...

2026-07-02 · 3 min · 620 words · 硅基 AGI 探索者
Agent并发执行架构

Agent并发执行架构:让智能体学会多线程思考

引言 Agent的很多操作是独立的——搜索三个不同的关键词、查询多个数据源、分析多个文件。如果串行执行,总时间是所有操作时间的总和;如果并发执行,总时间接近最慢操作的时间。 并发执行是Agent性能优化的重要手段。但并发带来了复杂性:资源竞争、状态同步、错误处理、死锁风险。2026年的Agent并发架构需要在性能和复杂性之间找到最佳平衡。 一、Agent并发场景 1.1 工具调用并发 一个请求需要调用多个独立工具时,可以并发执行: 串行: search_web(3s) → query_db(2s) → call_api(1s) = 6s 并发: search_web(3s) ─┐ query_db(2s) ─┼─ 并行 = 3s call_api(1s) ─┘ 1.2 多Agent并发 多个Agent同时处理不同子任务: 用户: "调研三家公司的市场表现" Agent A: 调研公司甲 ─┐ Agent B: 调研公司乙 ─┼─ 并行 Agent C: 调研公司丙 ─┘ 1.3 批量处理并发 对一批数据并行处理: 100个文档需要摘要 → 分成10批,每批10个文档 → 10个Worker并行处理 → 总时间 ≈ 单个文档的10倍(而非100倍) 1.4 竞争执行 同一任务由多个Agent竞争执行,取最优结果: Agent A → 方案A ─┐ Agent B → 方案B ─┼→ 评估器选择最优 Agent C → 方案C ─┘ 二、并发模型 2.1 异步IO模型 Agent的绝大多数操作是IO密集型(LLM API调用、工具调用),适合异步IO模型: ...

2026-07-02 · 4 min · 777 words · 硅基 AGI 探索者
Agent降级链设计

Agent降级链设计:构建弹性的多层防线

引言 在理想世界中,Agent的每个请求都能得到完美处理。但现实是,LLM API会限流、工具会超时、外部服务会宕机。当主路径不可用时,Agent需要有备选方案——这就是降级链(Fallback Chain)。 降级链的设计哲学是"逐步退化"——不是在失败时直接报错,而是尝试一系列替代方案,每一步都比上一步弱一些但仍然能提供价值。就像人类的处理方式:想不起来精确答案时,先给个近似答案;近似答案也没有时,至少给个方向。 一、降级链的核心原则 1.1 逐步退化 完美结果 → 良好结果 → 可用结果 → 基本结果 → 优雅失败 每一步降级都是可控的、有意的,而不是崩溃式的。 1.2 价值保留 每一步降级都应尽可能保留核心价值。用户问"帮我分析这份数据",如果AI分析不可用,至少展示原始数据;如果展示也不行,至少告知用户数据已收到、稍后处理。 1.3 透明告知 降级时应告知用户当前状态,而不是假装一切正常: "由于实时数据服务暂时不可用,以下分析基于最近缓存数据(更新于5分钟前)。" 1.4 可观测 每次降级都应该被记录和监控,用于发现系统性问题。 二、LLM降级链 2.1 模型降级链 GPT-4o / Claude Opus → GPT-4o-mini / Claude Sonnet → GPT-3.5 / Claude Haiku → 规则引擎 第一级:最强模型,提供最佳质量 第二级:中等模型,质量略降但更快更便宜 第三级:轻量模型,保证基本功能 第四级:规则引擎,不依赖LLM 2.2 降级触发条件 class LLMFallbackChain: def __init__(self): self.chain = [ {"model": "gpt-4o", "timeout": 30, "max_retries": 2}, {"model": "gpt-4o-mini", "timeout": 15, "max_retries": 2}, {"model": "gpt-3.5-turbo", "timeout": 10, "max_retries": 1}, {"model": "rule_engine", "timeout": 1, "max_retries": 0}, ] async def call(self, prompt, **kwargs): for i, config in enumerate(self.chain): try: if config["model"] == "rule_engine": return await self.rule_engine_fallback(prompt) result = await self.call_llm( model=config["model"], prompt=prompt, timeout=config["timeout"], retries=config["max_retries"], **kwargs ) # 质量检查:如果结果质量不达标,降级 if i < len(self.chain) - 1 and not self.quality_check(result): logger.warning(f"Quality check failed for {config['model']}, falling back") continue return result except (TimeoutError, RateLimitError, ServiceUnavailableError) as e: logger.warning(f"LLM {config['model']} failed: {e}, falling back") continue # 所有降级都失败 return self.graceful_failure(prompt) 2.3 质量降级 不只是模型级别的降级,还可以在功能级别降级: ...

2026-07-02 · 3 min · 445 words · 硅基 AGI 探索者
Agent重试策略设计

Agent重试策略设计:从盲目重试到智能恢复

引言 在Agent系统中,失败是常态。LLM API超时、工具调用失败、网络波动——这些故障随时会发生。如何处理这些失败,决定了系统的可靠性。 重试是最直接的容错手段,但"盲目重试"——不分析原因、不调整策略地反复重试——不仅浪费资源,还可能加剧问题。2026年的Agent系统需要的是"智能重试"——根据故障类型、上下文和历史数据做出最优的重试决策。 一、何时应该重试 1.1 可重试错误 vs 不可重试错误 可重试错误: 网络超时 服务暂时不可用(503) 速率限制(429) 临时性数据冲突 不可重试错误: 参数错误(400) 认证失败(401/403) 资源不存在(404) 业务逻辑错误(如"余额不足") 1.2 判断框架 def should_retry(error, attempt_count, context): # 不可重试错误直接返回False if error.type in NON_RETRYABLE_ERRORS: return False # 超过最大重试次数 if attempt_count >= context.max_retries: return False # 速率限制:可以重试,但需要等待 if error.type == "rate_limit": wait_time = error.retry_after or calculate_backoff(attempt_count) return True, wait_time # 网络超时:检查是否值得重试 if error.type == "timeout": if context.estimated_remaining_time > context.deadline: return False # 重试也无法在截止时间内完成 return True, calculate_backoff(attempt_count) # 服务不可用:重试 if error.type == "service_unavailable": return True, calculate_backoff(attempt_count) # 未知错误:保守重试 return True, calculate_backoff(attempt_count) 二、退避算法 2.1 固定间隔 每次重试间隔相同时间。简单但可能造成"重试风暴"——所有失败请求同时重试。 2.2 指数退避 每次重试间隔按指数增长: Retry 1: wait 1s Retry 2: wait 2s Retry 3: wait 4s Retry 4: wait 8s Retry 5: wait 16s def exponential_backoff(attempt, base=1, factor=2, max_delay=60): delay = min(base * (factor ** attempt), max_delay) return delay 指数退避是最常用的策略,有效避免重试风暴。 ...

2026-07-02 · 3 min · 516 words · 硅基 AGI 探索者
鲁ICP备2026018361号