Agent与LLM技术选型指南：从架构差异到生产环境实践

1次阅读

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

在构建智能客服系统时，我们曾遇到一个典型案例：当用户咨询订单状态时，系统需要先后调用订单查询接口、物流接口和支付系统。最初采用纯 LLM 方案时发现：

三次独立 API 调用导致对话上下文丢失，用户需要重复描述问题
每次调用消耗约 3000 tokens，总延迟超过 8 秒
无法记录用户偏好（如物流通知方式）

而在自动化财务审批流程中，另一个团队使用 Agent 架构时遭遇：

过度维持会话状态导致内存占用达到 12GB
工具调用超时未处理引发线程阻塞
多部门审批 Agent 同时修改数据产生竞态条件

维度	LLM	Agent
记忆类型	上下文窗口 (Context Window)	记忆池 (Memory Pool)
存储时长	单次会话	跨会话持久化
典型实现	Transformer 注意力机制	向量数据库 + 元数据管理
成本影响	Token 消耗线性增长	存储 I / O 和检索延迟

graph TD
    A[用户输入] --> B{决策点}
    B -->| 单次任务 | C[LLM 直接响应]
    B -->| 复杂任务 | D[Agent 决策引擎]
    D --> E[工具调用]
    E --> F[状态更新]
    F --> B

from langchain.agents import AgentExecutor, create_react_agent
from langchain_core.prompts import ChatPromptTemplate

# NOTE: 记忆组件使用 Redis 节省内存
def build_agent(llm, tools):
    prompt = ChatPromptTemplate.from_template("""
    当前会话 ID: {session_id}
    历史记录: {memory}
    问题: {input}
    可用工具: {tools}
    """)

    agent = create_react_agent(llm, tools, prompt)
    return AgentExecutor(
        agent=agent, 
        tools=tools,
        handle_parsing_errors=True,  # NOTE: 必须捕获 JSON 解析错误
        max_iterations=5  # 防止死循环
    )

import tiktoken

def optimize_llm_prompt(user_query, history):
    encoder = tiktoken.encoding_for_model("gpt-4")

    # NOTE: 动态裁剪历史记录保持 token 预算
    while len(encoder.encode(history)) > 2000:
        history = history.split('\n')[1:]  

    return f"""
    精简版对话历史 (最近 3 轮):
    {history}

    当前问题 (必须独立回答):
    {user_query}
    """

指标	LLM 方案	Agent 方案
平均延迟	320ms	890ms
峰值内存	2.1GB	5.7GB
API 调用成功率	98%	82%
会话保持成本	无	$0.12/ 千次

from datetime import datetime, timedelta
import jwt

SECRET = "your_256bit_secret"  # NOTE: 必须从环境变量读取

def create_secure_session(agent_id):
    return jwt.encode({
        'agent_id': agent_id,
        'exp': datetime.utcnow() + timedelta(hours=2),
        'scope': ['db_read', 'api_call']  # 最小权限原则
    }, SECRET, algorithm="HS256")

记忆机制混淆
错误表现：将 LLM 的 max_tokens 参数当作记忆容量
修正方案：为 Agent 实现分层记忆（Redis 缓存近期 +DB 持久化重要）
异步超时未处理
错误示例：result = await tool.call() 无 timeout

正确写法：

from asyncio import wait_for, TimeoutError

try:
    result = await wait_for(tool.call(), timeout=3.0)
except TimeoutError:
    logger.warning(f"Tool {tool.name} timeout")

竞争条件忽视
危险场景：多个 Agent 同时修改订单状态

解决方案：采用乐观锁机制

# 在数据库操作中添加版本检查
UPDATE orders 
SET status = 'approved', version = version + 1 
WHERE order_id = 123 AND version = 5

graph TD
    Start{是否需要以下能力?} -->| 跨会话状态保持 | Agent
    Start -->| 实时工具调用 | Agent
    Start -->| 简单问答 | LLM
    Agent --> C{是否接受?}
    C -->| 接受更高延迟 | Agent 方案
    C -->| 需要低成本 | Hybrid(LLM+ 轻量 Agent)

在需要处理实时变化的外部数据（如股票价格、交通路况）时，如何设计 Agent 的以下容错机制：
1. 工具返回数据过期时的重试策略
2. 多个数据源冲突时的验证流程
3. 紧急状态下的降级处理方案

正文完