循环边上加明确计数器作为业务级熔断

核心思想

        在 State 里显式放一个计数器字段(如 revision_countretry_countattempts),每绕一圈循环加 1,在路由函数中判断“超过阈值就走 END 或降级”,而不是让框架的 recursion_limit 兜底。

这不是“调大 limit 硬扛”,而是“业务逻辑主动叫停”。

from typing import Annotated, Literal
from typing_extensions import TypedDict
from langgraph.graph import StateGraph, START, END
from langgraph.managed import RemainingSteps
from langgraph.types import Command

# ===== 1. 状态定义:显式计数器 =====
class State(TypedDict):
    query: str
    result: str
    revision_count: int          # ← 业务计数器:绕了多少圈
    remaining_steps: RemainingSteps  # ← 系统级步数(兜底,非必须)

# ===== 2. 节点定义 =====
def agent(state: State) -> dict:
    """模拟模型决策:可能建议重写,也可能结束"""
    # 模拟逻辑:前两次都说“需要重写”,第三次说“完成”
    if state["revision_count"] < 2:
        return {"result": "需要进一步完善"}
    else:
        return {"result": "最终答案"}

def rewrite(state: State) -> dict:
    """重写节点:计数器 +1"""
    return {
        "revision_count": state["revision_count"] + 1,
        # 可以在这里清空其他字段(如用 Overwrite)
    }

# ===== 3. 路由函数:业务熔断 =====
def should_continue(state: State) -> Literal["rewrite", END]:
    """业务级熔断:超过2次就结束"""
    print(f"当前重写次数:{state['revision_count']},剩余步数:{state['remaining_steps']}")
    
    # 方法② 的核心:业务计数器
    if state["revision_count"] >= 2:
        # 超过阈值 → 结束(即使模型还想重写)
        print("⚠️ 达到业务重写上限,强制结束")
        return END
    
    # 如果模型认为需要重写,且还没超限
    if "需要完善" in state["result"]:
        return "rewrite"
    
    return END

# ===== 4. 建图 =====
builder = StateGraph(State)

builder.add_node("agent", agent)
builder.add_node("rewrite", rewrite)

builder.add_edge(START, "agent")

# 条件边:agent 决定是否继续
builder.add_conditional_edges(
    "agent",
    should_continue,
    {"rewrite": "rewrite", END: END}
)

# 循环边:rewrite 回到 agent(形成环)
builder.add_edge("rewrite", "agent")

# 编译
graph = builder.compile()

# ===== 5. 运行测试 =====
result = graph.invoke({
    "query": "帮我写一篇文章",
    "revision_count": 0,        # 初始化计数器
})
print(f"\n最终结果:{result['result']}")
print(f"总重写次数:{result['revision_count']}")

运行过程与输出

当前重写次数:0,剩余步数:25
当前重写次数:1,剩余步数:24
当前重写次数:2,剩余步数:23
⚠️ 达到业务重写上限,强制结束

最终结果:最终答案
总重写次数:2
  • 第 1 次:revision_count=0,模型说“需要完善” → 去 rewrite → 计数器变 1
  • 第 2 次:revision_count=1,模型说“需要完善” → 去 rewrite → 计数器变 2
  • 第 3 次:revision_count=2路由函数直接返回 END,不管模型说什么

生产环境模板

把这段代码当成“计数器循环”的标准模板:

class MyState(TypedDict):
    # ... 其他字段
    max_retries: int = 2          # 业务阈值(可配置)
    retry_count: int = 0          # 计数器

def core_node(state: MyState) -> dict:
    """核心业务节点"""
    # ... 执行逻辑
    return {"result": ...}

def retry_node(state: MyState) -> dict:
    """重试节点:只加计数,不做其他"""
    return {"retry_count": state["retry_count"] + 1}

def route(state: MyState) -> Literal["retry", END]:
    """路由:业务熔断"""
    if state["retry_count"] >= state["max_retries"]:
        return END      # 超过阈值 → 结束
    if state["result"] == "需要重试":
        return "retry"
    return END

总结

方法② 的本质:把“循环多少次”的决定权从框架的 recursion_limit 里拿出来,变成你业务代码里一个显式、可控、可测试的字段

  • 它让你能精确控制“最多重写 2 次”,而不是“最多跑 25 个 super-step”
  • 它让路由函数能做出业务语义明确的判断(“重写超限了,转人工”)
  • 它和 RemainingSteps 形成双重保险,一个管业务,一个管系统
内容概要:本文档为鹏鼎EES项目第二阶段关于设备闲置与富余识别的需求设计方案,旨在通过自动化方式识别低利用率设备,减少资产浪费。系统基于OEE系统提供的设备近6个月时间稼动率数据,设定“闲置”(连续6个月稼动率为0%)和“富余”(6个月平均稼动率≤30%)的判断标准,每周一自动执行识别任务并生成记录。支持在系统中查看识别结果列表、筛选导出数据、发起闲置申请及删除记录(管理员权限)。同时,系统通过鼎机器人按设备闲置/富余持续时长(7天、30天、90天、180天)逐向上推送预警消息至维护人员、厂长、处长、经管等层,推动问题处理。此外,若设备被判定为闲置但未提交闲置申请,系统将向维护人员和设备课长发送D+提醒。; 适合人群:系统设计人员、开发人员、测试人员、设备管理人员及项目实施相关人员;尤其适用于熟悉OEE系统、设备管理流程及企业信息化系统的专业人员;; 使用场景及目标:① 实现设备利用率的动态监控与闲置风险预警;② 支持企业优化设备资源配置,降低资产闲置成本;③ 推动设备闲置处理流程自动化与责任到人机制建立;④ 为后续设备处置、调配、报废等决策提供数据支撑;; 阅读建议:本文档为研发与实施阶段的核心指导文件,涉及系统逻辑、数据来源、权限控制与集成接口等关键内容,建议结合OEE数据对接情况、企业组织架构与设备管理流程协同研读,并关注阈值配置、提醒机制与状态联动等可配置项的实际业务适配性。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值