腾讯 AI Agent开发 一面(暑期)

1. 自我介绍

2. 介绍你这项目，重点讲 LLM 部分是怎么设计的

3. 如果让你从零设计一个对话 Agent 的流程，核心状态有哪些

核心状态至少要有会话状态、任务状态、工具状态和记忆状态。会话状态负责当前轮的输入输出和上下文窗口；任务状态描述目标、槽位、依赖和是否完成；工具状态记录已经调用过哪些外部能力、返回了什么、是否失败和是否可重试；记忆状态保存长期偏好、历史事实和结构化摘要。很多对话系统看上去只是“多轮聊天”，实际真正难的是状态机设计，如果状态边界不清晰，模型很容易把临时信息写成长久事实，或者把上一个任务的中间结果错误继承到当前轮。

4. 如果用户和 AI 对话时生成的问题本身有冲突，系统应该怎么处理

不能让模型直接“二选一猜一个”，而是先进入冲突检测和证据仲裁流程。比较稳的处理方法是先识别冲突类型，是事实冲突、时间冲突、约束冲突还是角色冲突；然后回溯冲突来源，是来自用户多轮表述变化、工具返回不一致还是知识库版本冲突；最后根据冲突级别选择澄清、回退、拒答或者多解并列输出。真正线上可用的系统必须能分清“模型不会”和“输入本身互相矛盾”，否则用户会觉得它在胡说。

5. 如果把一个普通问答项目升级成虚拟对话系统，架构上要改哪些东西

普通问答项目的核心是检索和生成，虚拟对话系统则必须补齐人物设定、长期记忆、情感状态、轮次目标、风格一致性和可恢复状态。也就是说，从“单轮回答机器”升级成“持续扮演和持续行动的系统”。需要新增的关键能力包括 persona 管理、状态压缩、对话目标跟踪、情绪或风格约束、事件回忆和多回合安全控制。如果没有这些，所谓虚拟对话只是在每轮临时拼 prompt，轮数一长角色就会漂。

6. RAG 在这类 Agent 项目里到底用来解决什么问题

RAG 不是为了让模型“知道更多”，而是为了解决时效性、事实约束和可追溯性。模型参数里的知识不可控且难更新，业务上真正需要的是把最新文档、规则、历史记录和用户私有数据接进来，并能指出答案依据在哪里。尤其在流程型 Agent 里，RAG 不只是给答案供料，还经常参与工具前置决策，比如先查规则再决定是否允许调用某接口，或者先查历史工单再决定是否升级异常等级。

7. RAG 的信息一般怎么存，为什么不能只扔进向量库

只用向量库存文本块，通常很快就会遇到版本冲突、权限过滤、结构化事实缺失和引用不可追踪的问题。更合理的做法是分层存储：原文和版本信息进对象存储或文档库，向量索引用于语义召回，倒排索引用于关键词精确匹配，结构化事实进关系库或 KV，权限标签和生效时间作为元数据统一挂载。这样系统在检索时才能做到“先过滤再召回”，而不是把所有东西都召回来之后再指望模型自己判断。

8. embedding 模型在项目中应该怎么选，选错会出现什么现象

embedding 模型要看语言范围、文本长度、领域适配、向量维度、吞吐和成本。选错最直接的现象不是“指标低一点”，而是召回结果出现系统性偏差，比如术语相似但业务语义完全不同的块被排前面，短 query 发散严重，数字、版本号、接口名、时间表达召回很差。很多团队一开始只看通用榜单分数，实际上业务文档里型号、规范、错误码、配置项这类词法强约束内容非常多，这时就必须让 BM25、规则检索和 dense retrieval 一起工作，不能迷信单一 embedding。

9. embedding 切 chunk 应该怎么做，为什么固定长度切分经常不够

固定长度切分容易把一个完整知识单元切断，导致召回命中一半证据。更稳的方案通常是“结构优先、长度兜底”，先按标题、段落、表格、代码块、对话轮次这些天然边界切，再对超长块做二次切分，并保留来源、章节路径、时间、实体标签和父子关系。这样做的目标不是切得均匀，而是让每个 chunk 在语义上尽量自洽，既能被召回，又不会因为上下文缺失而让后面的生成偏掉。

def split_by_structure(paragraphs, max_len=350):
    chunks, cur = [], []
    cur_len = 0
    for p in paragraphs:
        if cur_len + len(p) <= max_len:
            cur.append(p)
            cur_len += len(p)
        else:
            chunks.append("\n".join(cur))
            cur = [p]
            cur_len = len(p)
    if cur:
        chunks.append("\n".join(cur))
    return chunks

10. 硬切分在实际场景里有哪些典型弊端

最常见的问题有四类。第一，标题和正文分离，导致召回到了内容却丢了语义锚点；第二，表格跨页或跨段被切裂，数值关系失真；第三，FAQ 问答对被拆开，query 命中问题但取不到答案；第四，长流程文档的前置条件和执行步骤被拆到不同块里，模型只看到了动作没看到约束。很多看起来像“模型幻觉”的问题，本质上是 chunk 设计把证据先破坏掉了。

11. 在 RAG 里，hard negative 到底该怎么构造，为什么它比随机负样本更有价值

random negative 太容易，训练出来的检索器只会区分“明显不相关”和“明显相关”，上线后遇到真正难的近邻样本就失效。hard negative 更接近真实业务中的干扰项，比如同领域、同实体、同模板、同章节但回答不了当前问题的文本块。构造方式可以来自 BM25 高分但人工判负的结果、cross-encoder 重排后的误召回样本、同文档相邻块、同类任务历史 bad case。hard negative 的价值不在于增加难度本身，而在于逼着模型学会更细粒度的判别边界。

12. ReAct 机制在生产环境里怎么设计，为什么不能只靠 prompt 写几句 Thought/Action

纯 prompt 版 R