首个版本该保留什么

在构建自动化 AI Agent 时，开发者往往希望智能体拥有极高的自主决策能力。但当 Agent 被赋予在长链条下自主选择 Tool Calling 的权限时，系统往往会在特定多模态场景下陷入预期之外的闭环陷阱。一个典型的故障场景是：智能体在处理一张模糊的文本图片时，由于 OCR 提取失败，便不断尝试更换参数重试 API，最终在没有任何阻断的情况下运行数百轮，在几个小时内消耗掉上千美元的 API 额度。Agent 系统的长期演进，决不能依赖每次人工介入调优 Prompt，而是要将每一次线上出现的踩坑经验，通过自动化机制转化为确定性的系统规则。

智能体连续运行 4 小时后，死循环消耗了 80% 的 API 预算

上周线上环境出现了一起典型的 Agent 失控事件。一个负责根据多模态输入（图片+文本）自动生成商品文案的 Agent 任务，在后台连续执行了超过 4 个小时。

看后台抓取到的 Trace 轨迹，根本原因是智能体在面对图片语义模糊时，陷入了“提取特征 -> 校验失败 -> 调整阈值 -> 再次提取”的无解死循环。由于智能体的提示词中写着“如果结果不准确，请调整参数重新尝试”，且没有在状态机中限制最大重试轮次与动作相似度判定，Agent 将“重新尝试”理解为了无限循环。

2026-08-18 03:14:02.102 WARN [agent_executor] Tool 'ocr_extract' returned low confidence (0.12).
2026-08-18 03:14:03.450 INFO [agent_executor] Agent decided to retry tool 'ocr_extract' with contrast=1.2
2026-08-18 03:14:04.890 WARN [agent_executor] Tool 'ocr_extract' returned low confidence (0.12).
... (Repeated 2,400 times over 4 hours) ...

在单纯的 Prompt 层加一句“请不要超过 3 次重试”并不能解决根本问题。大模型在复杂的上下文长窗口中，会随着历史 Conversation 长度增加逐渐丢失对初始 Prompt 的指令遵循能力（即 System Prompt Attenuation 现象）。只有把运行轨迹提取为规则，由外围调度系统硬性接管，才能防止预算雪崩。

经验到规则的反哺： Agent 状态机的死循环识别与记忆抽取

把线上踩坑经验变成规则的过程，本质上是在 Agent 的 System Loop 中建立一层“元认知规则库”（Meta-Rule Store）。这套架构包含 Trace 拦截器、死循环特征识别器、经验总结微引擎以及规则热加载模块。

当 Agent 在状态机轮转中产生动作时，拦截器不仅记录工具名称，还会对工具输入的 Key-Value 参数计算哈希。一旦检测到连续 3 次以上的动作哈希高度相似或者参数处于震荡状态（例如阈值在 0.1 和 0.2 之间反复来回），系统立刻切断 Tool Calling，强制标记该节点为不可达，并引导 Agent 走向 fallback 分支。

在任务结束后，死循环 Trajectory 会被输入给离线分析器，提取出导致循环的触发条件（例如“图像清晰度低于 0.3 且包含公式文本”），并将其转化为一条标准规则注入向量规则库。

多模态输入流的异常拦截与规则匹配拓扑

在处理多模态交互（如图像、音频、PDF 混合输入）时，规则引擎需要工作在 LLM 思考之前。因为多模态 Embedding 或预处理算子耗时极高，如果等到 LLM 看到包含大量噪声的图像后再做决策，已经浪费了一次 Context Window 的 Token 开销。

系统采用前端代理拦截与后置熔断双重控制。在接收到多模态文件时，先经过轻量级边缘规则库评估：

1. 图像分辨率低于临界阈值或图像损坏：直接拦截并返回友好错误，不再触发 agent_executor；
2. 文本 OCR 识别后 Token 数量异常过少：直接走纯文本辅助兜底，关闭视觉 Agent 多轮规划逻辑；
3. 工具调用历史中出现重复 Error Code：立刻激活 Guardrail 规则，强制 Agent 汇报给人工或直接报错。

动态规则注入与死循环防御代理实现

下面提供了一个使用 Python 实现的 Agent 工具调用拦截与死循环防御代理代码。该模块作为 Agent 框架的中间件，能动态计算动作签名并阻止无限重试。

import hashlib
import json
import time
from typing import Dict, Any, List, Optional, Callable

class AgentAction:
    def __init__(self, tool_name: str, tool_args: Dict[str, Any]):
        self.tool_name = tool_name
        self.tool_args = tool_args
        self.timestamp = time.time()

    def get_signature(self) -> str:
        """计算工具调用的规范化哈希签名"""
        # 将参数按 key 排序序列化，防止 dict 无序导致哈希不一致
        serialized = json.dumps({"tool": self.tool_name, "args": self.tool_args}, sort_keys=True)
        return hashlib.md5(serialized.encode('utf-8')).hexdigest()

class DeadLoopPreventer:
    """
    Agent 运行死循环与异常工具调用防范中间件
    """
    def __init__(self, max_same_action: int = 3, max_total_steps: int = 20):
        self.max_same_action = max_same_action
        self.max_total_steps = max_total_steps
        self.history: List[AgentAction] = []
        self.action_counts: Dict[str, int] = {}
        self.active_rules: List[Callable[[AgentAction, List[AgentAction]], Optional[str]]] = []

    def register_rule(self, rule_func: Callable[[AgentAction, List[AgentAction]], Optional[str]]):
        """注册从经验中提炼出的动态规则"""
        self.active_rules.append(rule_func)

    def validate_action(self, tool_name: str, tool_args: Dict[str, Any]) -> Tuple[bool, str]:
        """
        在执行工具调用前进行确定性安全校验
        """
        action = AgentAction(tool_name, tool_args)
        
        # 1. 硬性总步数限制
        if len(self.history) >= self.max_total_steps:
            return False, f"Rule Violated: Total steps limit ({self.max_total_steps}) reached."

        # 2. 死循环动作签名判定
        sig = action.get_signature()
        current_count = self.action_counts.get(sig, 0) + 1
        if current_count >= self.max_same_action:
            return False, f"Rule Violated: Action '{tool_name}' with identical arguments executed {current_count} times."

        # 3. 执行提炼出来的自定义元规则链
        for rule in self.active_rules:
            violation_msg = rule(action, self.history)
            if violation_msg:
                return False, f"Custom Rule Hit: {violation_msg}"

        # 记录合法动作
        self.history.append(action)
        self.action_counts[sig] = current_count
        return True, "OK"

# 示例：根据过去事故提炼的自定义规则
def ocr_low_quality_rule(action: AgentAction, history: List[AgentAction]) -> Optional[str]:
    """规则：如果连续两次 OCR 工具返回为空，禁止再次调用图像相关工具"""
    if action.tool_name in ["ocr_extract", "image_caption"]:
        recent_ocr_count = sum(
            1 for act in history[-3:] 
            if act.tool_name in ["ocr_extract", "image_caption"]
        )
        if recent_ocr_count >= 2:
            return "Consecutive multi-modal vision operations failed. Image processing blocked."
    return None

这段代码的核心亮点在于把非确定性的自然语言决策转化成了不可篡改的 action_signature 签名计算。即使 LLM 在 Prompt 中表达得再委婉，一旦其生成的 JSON 工具调用发往底层代理，代理就会依据历史特征签名快速阻断。

长链路 Agent 任务的延迟与规则碰撞 trade-offs

引入规则引擎后，必须在“系统的安全性”与“Agent 的灵活性”之间寻找折中点。如果规则过于严苛，往往会导致 Agent 在合法解决复杂任务时被误判熔断。

以长文本检索与分析任务为例，Agent 可能确实需要对多个不同页面执行 search_document 工具。如果将校验规则简单设定为“禁止连续调用同名工具 5 次”，就会产生误伤。因此，规则必须区分“同名工具+相同参数”与“同名工具+不同参数”。

+--------------------------------+--------------------+--------------------+
| 治理手段                       | 优势               | 缺陷与负面效应     |
+--------------------------------+--------------------+--------------------+
| 纯 Prompt 级口头约束           | 无额外延迟，开发快  | 指令衰减严重，无法熔断|
| 工具入参签名哈希比对           | 准确切中绝对死循环  | 无法识别参数微调抖动|
| 基于中间件的状态机规则引擎     | 100% 阻断异常风暴   | 稍微增加规则维护成本|
| 离线元规则抽取与动态注入       | 系统越用越聪明      | 规则过于密集可能降低成功率|
+--------------------------------+--------------------+--------------------+

在工程实践中，推荐采用“渐进式规则沉淀”模式：先在线上部署最基础的硬限制（最大步数限制、完全相同入参拦截），随后开启运行 Trace 日志收集。当发现新的慢速死循环链路时，通过离线复盘提取出最小拦截规则并补充到代理库中。这样既保护了 API 预算不被极端故障吞噬，又维持了 Agent 解决未知复杂难题的能力。

给第一版留下可删减的边界

首个版本不必把所有设想都做成入口。先列出任务真正需要的字段、一次处理允许花的时间，以及结果由谁验收。凡是不能改变这三件事的功能，都可以先放到后面。比如组件、接口或提示词设计时，先选一套稳定的数据结构，让页面能在缺字段、空结果和慢响应时保持可用。原型里出现的临时配置也要集中管理，别把它散在多个页面，等到要调整时才发现没有人说得清哪一处还在生效。

发布前检查真实路径

验收不只看顺利输入的演示数据。准备几类常见边界：字段少一项、文本过长、重复提交、服务超时、用户在处理中刷新页面。把每一类结果记下来，区分为提示用户修正、自动重试或人工接管。第一版的价值在于缩短学习周期，不在于把界面堆满。只要主任务能完成、错误能说明白、数据不会被悄悄写坏，就有条件进入下一轮。

写下当时的判断依据

这类方案在文档里看起来往往很顺，但真正接到已有系统时，会先碰到边界不清的问题。调用方并不会严格按理想顺序工作：有人会中途取消，有人会重复提交，也有人带着旧版本的缓存继续访问。处理这些情况时，先把当前状态、可重试条件和不可逆操作分开。页面可以给出简短提示，日志则需要保存足够的上下文，至少让排查的人知道请求来自哪里、经过了哪些关键步骤、最终在哪个判断处停下。不要为了补齐一条看似完整的流程而替用户猜测数据，也不要把内部异常原样暴露给用户。

实际修改前，我会先选一条能复现的路径做小范围验证。确认输入、异常和回退都能工作后，再考虑是否扩大到其他入口。测试不需要追求覆盖所有想象出来的场景，但要包含最容易造成误解的几个分支：空值、重复、超时、刷新和权限变化。每一次调整都留下版本和原因，等到下一次有人问“为什么这里要多一步”时，可以从记录中找到答案。这样的过程没有捷径，却能避免系统在看不见的地方积累临时假设。

如果某个判断暂时没有足够证据，就把它标注为待验证，而不是写成确定结论。后续有新样本时再修订它，文档才不会变成只适合当时的一次性说明。