1、自我介绍

2、介绍一下实习

3、你们的 Agent 项目落地完成后，是直接交付给业务方还是让对方调用 API

这两种方式都常见，区别主要在交付形态。

如果是直接交付给业务方，一般会做成完整应用，比如网页端、内部工作台、客服系统插件或者企业微信机器人。业务方直接使用现成系统，不需要关心底层模型、检索、工具调用这些实现细节。这种方式更适合业务部门直接落地，优点是使用门槛低，缺点是后续定制需求可能会比较多。

如果是提供 API，通常说明 Agent 能力被当成平台能力输出。业务方或者其他系统通过接口调用，比如传入用户问题、上下文信息、用户 ID，再拿回模型结果。这种方式更适合中台化建设，扩展性更强，不同业务系统都能复用同一套能力。

如果是企业内部项目，很多时候会同时做两层：底层提供 API，上层再封装成可用页面或者业务入口。这样既方便集成，也方便后续复用。

4、讲一下你认为你负责的部分比较难的地方

我负责的部分里，相对更难的是意图识别和多轮对话管理。因为 AI Agent 项目里，模型能不能答对，不只是看生成能力，很大程度上看前面的路由有没有做对。用户一句话进来以后，如果意图判断错了，后面整个链路都会错。比如用户本来是查订单，结果被当成知识问答去检索知识库，那最后答案肯定偏掉。

意图识别难主要难在几个地方。一个是用户表达不标准，口语化、歧义、多意图混杂的情况很多。另一个是业务场景里意图边界有时候并不清晰，比如“帮我看下这个产品适不适合老人用”，既像产品咨询，也可能涉及推荐。再一个是线上输入噪声很大，用户不会按训练数据那种标准句式提问。

所以实际做的时候，通常不会只靠单一分类模型，而是会结合规则、关键词、少量人工标注样本以及大模型辅助判断一起做。这样做的目的，不是追求理论上多先进，而是先把线上可用性做稳。

5、项目中意图识别部分你们用户画像是怎么做的

用户画像主要是为了辅助意图判断和后续回答生成，不是单独为了存用户信息。

常见做法是把用户画像拆成显式信息和隐式信息。显式信息一般来自注册信息、角色信息、部门信息、历史业务记录，比如用户属于哪个业务线、是什么身份、有没有购买记录、最近关注过什么内容。隐式信息更多来自行为数据，比如最近连续问了哪些问题、点击过哪些内容、经常在什么时间段使用、偏向哪类问题。

在 Agent 场景里，用户画像最直接的作用有两个。一个是帮助意图识别。比如同样一句“帮我查一下”，管理员和普通用户可能对应完全不同的业务动作。另一个是帮助回答个性化。比如不同角色查同一问题，返回内容权限范围可能不同，展示重点也可能不同。

如果从实现上说，用户画像通常不是一次性全塞进 prompt，而是会做结构化管理。需要的时候只取当前任务相关的信息，避免上下文太长、噪声太大。

user_profile = {
    "user_id": "u1001",
    "role": "运营",
    "department": "风控",
    "recent_intents": ["查报表", "查订单", "知识问答"],
    "product_focus": ["企业安全", "告警平台"],
    "permission_scope": ["report_read", "order_read"]
}

6、你们是怎么管理历史信息或者对话的

对话历史管理的核心不是全存，而是怎么存、什么时候取、取哪些。

如果把所有历史对话无脑拼进上下文，会有几个问题：一是 token 开销大，二是噪声多，三是旧信息可能会干扰当前回答。所以一般会分层管理。

一种常见做法是短期记忆加长期记忆。短期记忆就是当前会话窗口内最近几轮对话，主要保证上下文连续性，比如用户说“这个再详细一点”“那第二个呢”，模型要知道“这个”和“第二个”指的是什么。长期记忆则是把一些稳定信息抽出来单独存，比如用户偏好、历史关注主题、重要事实、业务配置等，不会每轮都原样塞进去，而是在必要时检索出来再补充。

如果是工程上实现，通常会保留最近 N 轮对话，再配合摘要机制。也就是对过长历史先做总结，后续只带摘要和关键轮次，而不是把所有原文带上。

from collections import deque

class ConversationMemory:
    def __init__(self, max_turns=5):
        self.history = deque(maxlen=max_turns)

    def add_message(self, role, content):
        self.hi