智能体设计遇到的问题及解决方案

智能体开发真不是「调个大模型API」那么简单，从会话管理、上下文设计、权重调优到稳定性保障，每一步都有坑。我这几个问题算是最典型的，如果你也在做智能体相关的开发，希望能帮你少走点弯路。

name_nothing

389人浏览 · 2026-05-05 20:50:29

name_nothing · 2026-05-05 20:50:29 发布

踩坑无数遍，我总结了智能体设计的5个核心问题（附真实代码解决方案）

前言

去年我接了个群面模拟系统的需求，核心是要做一套能模拟不同MBTI人格、不同群面角色的AI智能体。一开始我以为智能体就是「调大模型API+拼提示词」，结果真做起来踩了无数坑：内存泄漏、上下文丢失、智能体垄断发言、会话串台、服务超时……前后调了三个月才稳定下来。

本文完全基于我真实项目的代码复盘，每个问题都对应我实际写过的代码、踩过的雷，希望能帮大家少走弯路。

坑1：HashMap缓存智能体差点搞崩服务，还藏了线程安全隐患

问题现象

系统上线第一周就收到运维报警：服务内存占用90%，重启后过几天又复现。查日志发现，有用户反馈「和智能体对话越来越卡」，甚至出现了两个用户会话内容串在一起的情况。

当时的代码（真实片段）

在backend/src/main/java/com/interview/controller/AgentChatController.java里，我最开始是这样设计会话缓存的：

@RestController
@RequestMapping("/api/agent")
@RequiredArgsConstructor
public class AgentChatController {
    // 致命问题1：用HashMap存智能体，没有过期机制
    // 致命问题2：HashMap非线程安全，并发请求会出问题
    private final Map<String, AbstractAgent> sessionAgents = new HashMap<>();
    
    @PostMapping("/chat")
    public Map<String, Object> chat(@RequestBody Map<String, String> request) {
        String sessionId = request.getOrDefault("sessionId", "default");
        AbstractAgent agent = sessionAgents.get(sessionId);
        if (agent == null) {
            // 并发场景下，多个请求可能同时进这里，创建多个agent互相覆盖
            agent = agentFactory.createAgent(mbtiType, roleType, sessionId, message);
            sessionAgents.put(sessionId, agent);
        }
        // ...
    }
    
    // 只有用户主动调用清除接口才会删，绝大多数用户根本不知道这个接口
    @PostMapping("/clear")
    public Map<String, Object> clearSession(@RequestBody Map<String, String> request) {
        String sessionId = request.getOrDefault("sessionId", "default");
        sessionAgents.remove(sessionId);
        return Map.of("success", true, "message", "会话已清除");
    }
}

问题分析

内存泄漏：用户对话完就关页面，不会主动调用/agent/clear，HashMap里的智能体实例永远删不掉，用户量上来后几万个session占满内存是必然的；
线程安全：Spring的Controller是单例的，HashMap不支持并发读写，多个用户同时发请求时，可能出现sessionAgents.get和put的竞态条件，甚至导致智能体实例被覆盖、会话串台；
无隔离：默认sessionId是default，所有没传sessionId的请求都会共用同一个智能体，完全乱套。

解决方案

直接把HashMap换成Caffeine本地缓存，自带过期机制和线程安全：

// 修改后的代码
@RestController
@RequestMapping("/api/agent")
@RequiredArgsConstructor
public class AgentChatController {
    // 改用Caffeine缓存，30分钟无访问自动清理，线程安全
    private final Cache<String, AbstractAgent> sessionCache = Caffeine.newBuilder()
            .maximumSize(10000) // 最多存1万个会话
            .expireAfterAccess(30, TimeUnit.MINUTES) // 30分钟无访问自动过期
            .build();
    
    @PostMapping("/chat")
    public Map<String, Object> chat(@RequestBody Map<String, String> request) {
        String sessionId = request.getOrDefault("sessionId", UUID.randomUUID().toString());
        AbstractAgent agent = sessionCache.get(sessionId, key -> 
            agentFactory.createAgent(mbtiType, roleType, sessionId, message)
        );
        // ...
    }
}

同时修改前端，每次初始化对话都生成唯一sessionId，避免共用默认default。

优化效果

内存占用从最高90%降到稳定在30%以下，再也没出现过内存报警，会话串台的问题也彻底消失。

坑2：智能体秒变老年痴呆？上下文丢失是元凶

问题现象

用户吐槽最多的是：「智能体像得了健忘症，上一句说我是INTJ的Leader，下一句就问我是什么角色」，或者「我问它之前说过的方案细节，它完全答不上来，像第一次和我说话」。

当时的代码（真实片段）

问题出在AgentChatController里构造智能体上下文的逻辑，我最初为了省事，每次都传空的对话历史：

@PostMapping("/chat")
public Map<String, Object> chat(@RequestBody Map<String, String> request) {
    // ...
    // 致命问题：每次都传空的对话历史，智能体根本不知道之前聊了什么
    Agent.AgentContext context = new Agent.AgentContext(
        Phase.DEBATE, 
        "user",
        new ArrayList<>(), // 空的conversationHistory
        message,
        new HashMap<>()
    );
    String response = agent.generateResponse(context);
    // ...
}

虽然我缓存了智能体实例，但generateResponse方法只认传入的AgentContext里的历史，每次传空的，智能体当然啥也不记得。

问题分析

我一开始误解了「会话缓存」的作用：缓存智能体实例不代表智能体自动记住对话，必须显式把历史对话存到智能体的状态里，每次构造上下文的时候把历史传进去。

解决方案

在AbstractAgent里加对话历史字段，每次调用后自动更新：

// backend/src/main/java/com/interview/agent/AbstractAgent.java 修改后
public abstract class AbstractAgent implements Agent {
    // 存对话历史，所有会话共享这个列表
    protected final List<Event> conversationHistory = new ArrayList<>();
    
    @Override
    public String generateResponse(AgentContext context) {
        // 1. 把当前用户消息加入历史
        Event userEvent = new Event("user", context.questionContent(), System.currentTimeMillis());
        conversationHistory.add(userEvent);
        
        // 2. 调用大模型生成回复（这里用Spring AI的ChatClient）
        String response = doGenerateResponse(context);
        
        // 3. 把智能体回复加入历史
        Event agentEvent = new Event(getAgentId(), response, System.currentTimeMillis());
        conversationHistory.add(agentEvent);
        
        // 限制历史长度，最多存20条，避免上下文过长导致大模型超时
        if (conversationHistory.size() > 20) {
            conversationHistory.subList(0, conversationHistory.size() - 20).clear();
        }
        return response;
    }
}

同时修改AgentChatController里的上下文构造，把智能体自己的历史传进去：

Agent.AgentContext context = new Agent.AgentContext(
    Phase.DEBATE, 
    "user",
    agent.getConversationHistory(), // 用智能体存的历史，而不是空的
    message,
    new HashMap<>()
);

优化效果

智能体现在能记住最近10轮以内的对话，用户问「我刚才说的方案是什么」，它能准确引用之前的内容，吐槽率直接降了80%。

坑3：群面模拟变Leader个人脱口秀？发言权重设计太随意

问题现象

做群面模拟功能的时候，测试同学反馈：「5个智能体里Leader永远在说话，其他4个全程闭麦，像看单人脱口秀，完全不像群面」。

当时的代码（真实片段）

问题出在AbstractAgent的发言评分逻辑，我最初拍脑袋定的权重：

// backend/src/main/java/com/interview/agent/AbstractAgent.java 初始版本
public abstract class AbstractAgent implements Agent {
    protected static final double SPEAK_THRESHOLD = 0.65;
    // 拍脑袋定的权重，角色权重占了一半
    protected static final double ROLE_WEIGHT = 0.5; 
    protected static final double RELEVANCE_WEIGHT = 0.2;
    protected static final double EMOTION_WEIGHT = 0.1;
    protected static final double TIMING_WEIGHT = 0.1;
    protected static final double PHASE_WEIGHT = 0.1;
    
    @Override
    public double calculateSpeakScore(SpeakContext context) {
        double score = 0.0;
        score += ROLE_WEIGHT * getRoleImportance(); // Leader的角色重要性是1.0，其他最高0.6
        score += RELEVANCE_WEIGHT * calculateRelevance(context);
        score += EMOTION_WEIGHT * getEmotionActivation();
        score += TIMING_WEIGHT * calculateTimingScore(context);
        score += PHASE_WEIGHT * getPhaseWeight(context.currentPhase());
        return score;
    }
}

Leader的角色重要性是1.0，其他角色最高0.6，再加上0.65的发言阈值，导致Leader的分数永远最高，其他智能体根本拿不到发言权。

问题分析

我一开始只考虑了「角色重要性」，完全没考虑「沉默时长」：一个智能体越久没说话，应该越有发言欲望。而且阈值设得太高，把很多本来可以发言的智能体挡在了外面。

解决方案

重新调整权重，加入沉默时长因子，降低发言阈值：

// 修改后的权重
protected static final double SPEAK_THRESHOLD = 0.5; // 降低阈值，让更多智能体有机会
protected static final double ROLE_WEIGHT = 0.2; // 降低角色权重
protected static final double SILENCE_WEIGHT = 0.3; // 新增沉默时长权重，越久没说话分越高
protected static final double RELEVANCE_WEIGHT = 0.2;
protected static final double EMOTION_WEIGHT = 0.15;
protected static final double TIMING_WEIGHT = 0.1;
protected static final double PHASE_WEIGHT = 0.05;

// 新增沉默时长计算逻辑
private double calculateSilenceScore(SpeakContext context) {
    // 智能体自己的最后发言时间，和当前时间的差，差越大分数越高
    long lastSpeakTime = getState().getLastSpeakTime();
    int silenceDuration = (int) ((System.currentTimeMillis() - lastSpeakTime) / 1000);
    return Math.min(silenceDuration / 60.0, 1.0); // 最多1分，沉默1分钟以上拿满分
}

@Override
public double calculateSpeakScore(SpeakContext context) {
    double score = 0.0;
    score += ROLE_WEIGHT * getRoleImportance();
    score += SILENCE_WEIGHT * calculateSilenceScore(context); // 加入沉默分数
    score += RELEVANCE_WEIGHT * calculateRelevance(context);
    score += EMOTION_WEIGHT * getEmotionActivation();
    score += TIMING_WEIGHT * calculateTimingScore(context);
    score += PHASE_WEIGHT * getPhaseWeight(context.currentPhase());
    return score;
}

还加了「连续发言限制」：单个智能体最多连续发言2次，必须换其他人说。

优化效果

现在5个智能体都有发言机会，Leader负责控场，Viewpoint提新观点，Executor补执行细节，群面讨论的真实性直接上了一个台阶。

坑4：同一角色开两个标签页，对话内容串了？会话ID设计太随意

问题现象

测试的时候发现，用同一个MBTI+角色开两个浏览器标签页，在A页面发消息，B页面也能收到回复，甚至出现A页面的问题，B页面收到回复的诡异情况。

当时的代码（真实片段）

问题出在前端AgentChatView.vue的会话ID生成逻辑：

// frontend/src/views/AgentChatView.vue 初始版本
const sendMessage = async () => {
    // 致命问题：同一个MBTI+角色，不管开多少个标签页，sessionId都一样
    const sessionId = `${selectedMbti.value}_${selectedRole.value}`
    
    const result = await chatWithAgent({
        mbti: selectedMbti.value,
        role: selectedRole.value,
        message: userMsg,
        sessionId: sessionId
    });
    // ...
}

问题分析

sessionId的作用是用来标识唯一会话，我最初只用了「MBTI+角色」组合，完全没有唯一性标识，同一个组合开多个标签页，后端会认为是同一个会话，肯定串台。

解决方案

给sessionId加唯一标识，比如时间戳+随机串，或者让后端生成唯一ID返回：

// 修改后的前端代码
let currentSessionId = null; // 当前页面的唯一会话ID

onMounted(async () => {
    // 初始化的时候生成唯一sessionId，每个标签页都不一样
    currentSessionId = `${selectedMbti.value}_${selectedRole.value}_${Date.now()}_${Math.random().toString(36).slice(2)}`;
});

const sendMessage = async () => {
    const result = await chatWithAgent({
        mbti: selectedMbti.value,
        role: selectedRole.value,
        message: userMsg,
        sessionId: currentSessionId // 用当前页面的唯一ID
    });
    // ...
}

优化效果

不同标签页、不同浏览器的会话完全隔离，再也没出现过串台的问题。

坑5：大模型超时拖垮整个服务？稳定性设计不能少

问题现象

高峰期的时候，经常有用户反馈「发消息后转圈半分钟，最后提示对话失败」，甚至会导致整个后端接口的线程池占满，其他正常接口也跟着挂。

当时的代码（真实片段）

前端api.js里的全局超时设置，以及后端没有降级逻辑：

// frontend/src/services/api.js 初始版本
const api = axios.create({
  baseURL: '/api',
  timeout: 70000 // 所有接口统一70秒超时，报告生成这种长任务根本不够
})

后端调用大模型的时候，也没有设置超时和降级，完全依赖DashScope的可用性。

问题分析

70秒超时太死板：普通对话可能够，但报告生成、长文本回复肯定超时；
没有降级策略：如果DashScope接口慢或者挂了，所有请求都卡着，线程池很快被打满，整个服务雪崩；
没有区分接口类型：对话接口和报告生成接口的超时需要分开设置。

解决方案

前端按接口类型设置不同超时：

// 修改后的api.js
export async function chatWithAgent(data) {
  // 对话接口70秒超时
  return await api.post('/agent/chat', data, { timeout: 70000 });
}

export async function generateManusReport(payload) {
  // 报告生成接口300秒超时
  return await api.post('/report/manus/generate', payload, { timeout: 300000 });
}

后端Spring AI设置大模型超时，加降级逻辑：

# application.yml 配置
spring:
  ai:
    dashscope:
      api-key: ${DASHSCOPE_API_KEY}
      timeout: 60000 # DashScope调用超时60秒
    deepseek:
      api-key: ${DEEPSEEK_API_KEY}
      timeout: 60000

// 后端调用大模型的时候加降级：DashScope超时后自动切DeepSeek
public String callLLM(String prompt) {
    try {
        return dashscopeChatClient.call(prompt);
    } catch (TimeoutException e) {
        log.warn("DashScope超时，切换到DeepSeek");
        return deepseekChatClient.call(prompt);
    }
}