深入解析Agent与大模型的本质区别：从架构到应用场景

1次阅读

共计 2174 个字符，预计需要花费 6 分钟才能阅读完成。

在开发智能客服系统时，某团队误将纯大模型调用作为对话核心，导致以下问题：
1. 用户连续咨询订单状态时，系统每次都要重新理解上下文，响应延迟达 1.2 秒（基准测试数据来自 AWS Lambda 冷启动日志）
2. 当用户说 ” 取消上一步操作 ” 时，GPT-3.5 版本模型有 47% 概率无法正确关联前序对话（数据来自 2023 年 ACL 会议测评报告）

状态管理机制

Agent：通过 Redis 等持久化层维护会话状态，典型结构包含：

class DialogState:
    def __init__(self):
        self.current_intent = None  # 当前意图标识
        self.entity_stack = []     # 已识别实体栈
        self.context_vars = {}      # 上下文变量字典

大模型：完全无状态，每次请求需携带完整上下文
计算范式对比

Agent：基于规则引擎 +ML 模型的混合决策，典型流程：

graph TD
    A[用户输入] --> B(意图识别)
    B --> C{是否需要实体}
    C -->| 是 | D[实体抽取]
    C -->| 否 | E[动作执行]
    D --> E
    E --> F[状态更新]

大模型：端到端的序列生成，延迟分布示例如下（单位 ms）：
| 操作 | P50 | P90 | P99 |
|——————-|——|——|——|
| 小模型 (6B) | 120 | 210 | 350 |
| 大模型 (175B) | 580 | 1200 | 2500 |
（数据来源于 HuggingFace 基准测试）

class OrderAgent:
    def __init__(self, state_db):
        self.state_db = state_db  # 状态存储接口
        self.nlu = load_bert_model()  # 加载本地 NLU 模型

    def process(self, user_id, utterance):
        # 读取当前会话状态
        state = self.state_db.get(user_id) or DialogState()

        try:
            # 意图识别与实体抽取
            intent = self.nlu.detect_intent(utterance)
            entities = self.nlu.extract_entities(utterance)

            # 业务规则处理
            if intent == 'CANCEL_ORDER':
                return self._handle_cancel(state, entities)
            # 其他意图处理分支...

        except Exception as e:
            logger.error(f"Agent 处理失败: {e}")
            return self._fallback_response()

        finally:
            # 确保状态回写
            self.state_db.set(user_id, state)

def call_llm(prompt_history):
    headers = {"Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json"
    }

    try:
        response = requests.post(
            LLM_ENDPOINT,
            json={"prompt": '\n'.join(prompt_history),
                "max_tokens": 150,
                "temperature": 0.7
            },
            headers=headers,
            timeout=10  # 关键超时设置
        )
        response.raise_for_status()

        # 实现令牌桶限流
        rate_limiter.consume(1) 
        return response.json()['text']

    except requests.exceptions.RequestException as e:
        logger.warning(f"API 调用异常: {e}")
        return "系统繁忙，请稍后再试"

混合部署架构
使用 Kubernetes nodeAffinity 将 Agent 服务与大模型服务物理隔离
Agent 建议分配：2CPU+4GB 内存 / 实例（实测 QPS 可达 120+）
大模型 API 网关需配置：
- 请求队列（Apache Kafka）
- 熔断机制（10 秒内错误率 >5% 触发）
状态管理优化
采用分层缓存策略：
- 高频会话状态存 Redis（TTL 30 分钟）
- 长期上下文存 MySQL+ 向量检索
大模型流量控制

按业务优先级划分令牌桶：

from pyrate_limiter import RateLimiter

limiter = RateLimiter(
    rates=[('urgent', 100),  # 高优先级业务
        ('normal', 30),   # 常规请求
        ('batch', 5)      # 离线任务
    ]
)