手写一个最小 ReAct 循环：退出条件和死循环兜底怎么设计？

ReAct = Reason（模型想下一步做什么）+ Act（执行工具）+ Observation（结果回灌），循环直到出结果。骨架：

messages = [system_prompt, user_input]
for step in range(max_steps):
    resp = llm.chat(messages, tools=tools)   # 一步 = 一次模型请求
    messages.append(resp.message)            # 别忘了把带 tool_call 的这条也放回去
    if not resp.tool_calls:                  # 正常出口
        return resp.text
    for call in resp.tool_calls:
        result = execute(call)               # 执行在我这边
        messages.append(tool_result(call.id, result))
return "达到步数上限"                          # 兜底出口

两个退出条件：模型返回不带工具调用的最终答案（正常）；达到 max_steps（兜底）。死循环最常见的形态是模型反复用相同参数调同一个工具，可以对"工具名 + 参数"做指纹计数，重复超过阈值就中断。

在骨架上补四件生产必需品：预算、指纹、异常吞掉、降级出口。

def run(user_input, tools, max_steps=8, budget=Budget(tokens=60_000, seconds=60, cny=0.5)):
    messages = [system_prompt(), user(user_input)]
    seen = Counter()                                  # 动作指纹计数
    for step in range(max_steps):
        if budget.exhausted():                        # 出口 2：预算/超时
            return degrade(messages, reason="budget")

        resp = llm.chat(messages, tools=tools)
        budget.charge(resp.usage)
        messages.append(resp.message)

        if not resp.tool_calls:                       # 出口 1：正常终止
            return finalize(resp.text, messages)

        for call in resp.tool_calls:
            fp = fingerprint(call.name, call.args)    # 参数排序+归一化后哈希
            seen[fp] += 1
            if seen[fp] >= 3:                         # 出口 3：死循环干预
                messages.append(tool_result(call.id,
                    "你已用相同参数调用该工具 3 次，结果不会变。"
                    "请改换参数、改用其他工具，或基于现有信息作答。"))
                continue
            ok, result = safe_execute(call)           # 异常绝不抛出循环
            messages.append(tool_result(call.id, clip(result)))

    return degrade(messages, reason="max_steps")      # 出口 4：步数上限

要讲清的四个设计点：

1. 退出条件有四类，不是一类。 正常终止（无 tool_call）／资源终止（步数、时间、token、费用）／异常终止（工具连续失败熔断、护栏拦截、用户中断）／无进展终止（连续几步没有新增信息）。前两类大家都会写，后两类是分水岭。

2. 兜底不是抛异常，是 degrade()。 触顶时返回三段：已经拿到的信息、还没完成的事、建议的下一步（换个问法／转人工）。直接抛"达到步数上限"在产品上等于白跑一次还惹恼用户。

3. 异常必须在 safe_execute 里被吞掉，并翻译成可操作的话。 堆栈回灌有三个问题：占 token、模型看不懂所以不会改、可能泄漏表名路径等内部信息。正确做法是区分可重试（超时、限流——在代码里退避重试，不打扰模型）和不可重试（参数非法、无权限——翻译成"参数 date 需 YYYY-MM-DD"回灌让模型自己改），连续失败则熔断降级。

4. 每一步都要留痕。 至少记录：步号、工具名、参数摘要、结果长度、耗时、token、终止原因。终止原因的分布是最便宜的健康度指标——正常终止占比掉、max_steps 触发率涨，说明任务变难或提示词退化了，比看用户投诉早很多。截至 2026-08，OTel GenAI 语义约定 v1.41 给了 invoke_agent → chat → execute_tool 的嵌套 span 结构和 token 指标口径，可以直接对齐（多数属性仍是实验性，内容捕获默认关闭，合规上反而合适）。

5. 一句时效判断。 早期 ReAct 是文本协议——让模型输出 Thought/Action/Action Input，代码用字符串解析。截至 2026-08 这套只在不支持原生工具调用的模型上才用，主流一律走原生 function calling，省掉脆弱的解析层。面试时说得出这个演进，比只会背论文结构强。

三段式看 ReAct 本身：解决的是"下一步依赖上一步观察"的任务；代价是每步一次模型请求，时延与成本随步数线性增长、错误按乘法累积、轨迹不可复现；不该用在路径固定（写 workflow）和需要长程规划的场景（考虑 Plan-and-Execute，见 Q3-07）。