字节跳动 抖音 AI Agent开发 二面

1、自我介绍

2、讲一个你做过的最有代表性的 Agent 项目

3、如果让你设计一个通用 Agent 框架，你会怎么设计

我会把它拆成六层。最上面是接入层，处理用户请求、鉴权、限流和会话管理。下面一层是理解层，负责意图识别、槽位抽取、风险识别和任务分类。再往下是规划层，根据任务复杂度决定是直接回答、走工作流，还是做多步规划。中间一层是记忆和上下文层，统一管理短期记忆、长期记忆、任务状态和检索到的证据。再下面是工具层，把所有外部能力封装成标准化 skill，包括描述、参数 schema、执行逻辑和异常处理。最底层是执行与评测层，负责模型调用、工具执行、结果回填、日志埋点和效果评估。

如果要做成工程上可维护的框架，我会特别强调几件事：一是工具协议标准化，不然 skill 越多越难管；二是上下文构造标准化，不同任务不能随便拼接；三是监控指标要拆开看，至少要区分模型问题、检索问题、工具问题和工作流问题；四是要有失败兜底机制，比如工具调用失败时降级成普通问答或者触发重试。

4、你怎么理解 Agent 和 Workflow 的边界

Workflow 更偏确定性，它适合流程相对固定的任务，比如先查一个接口，再根据结果决定下一步，再做格式化输出。好处是稳定、可控、便于排查，尤其适合线上核心链路。Agent 更偏自主决策，它更像一个能自己判断下一步做什么的执行体，适合复杂、开放、多步的不确定任务。

实际项目里，我一般不会纯做自由 Agent，而是让 Workflow 控制主干流程，把需要理解、规划和选择的局部步骤交给 Agent。这样既能保留灵活性，也能保证线上稳定性。很多所谓的 Agent 系统，本质上都是“Workflow + LLM 决策节点”。

5、你们项目里工具很多的话，怎么做 tool routing

工具多的时候不能直接把所有工具描述都丢给模型，这样 token 开销大，而且模型容易选错。我一般会做分层路由。先做一级粗分类，比如检索类、查询类、生成类、执行类，再在二级做具体工具选择。粗分类可以用规则、小模型分类器或者轻量 LLM 来完成，二级路由再用更详细的 tool description 让模型选。

另外会做工具候选裁剪，比如结合当前意图、用户角色、会话历史和参数完整性，先过滤掉明显不可能用的工具。再往后是参数校验和执行反馈，如果模型选了工具但参数不完整，就不直接执行，而是先补槽或者纠错。这样比“选错了再失败”稳定很多。

6、项目里做过记忆吗，怎么避免记忆把上下文污染掉

做过。记忆最容易出问题的地方就是“记了很多，但真正该用的时候用错了”。所以我一般会把记忆分成三类。

第一类是短期会话记忆，只保留当前任务强相关的最近几轮内容，适合直接拼接进上下文。第二类是长期用户记忆，比如用户偏好、常用配置、角色信息，这类记忆通常结构化存储，不会整段塞给模型，而是在需要时按字段召回。第三类是任务状态记忆，比如当前做到第几步、有哪些待办、已经拿到了哪些中间结果，这类更像 workflow state。

为了避免污染，上下文拼接时会做相关性筛选和优先级排序，不是所有记忆都放。很多时候少而准，比多而乱效果更好。

7、你怎么做上下文压缩

上下文压缩一般有三种思路。第一种是截断，但这个最粗暴，只适合优先级特别明确的场景。第二种是摘要，把长历史对话或者长文档提炼成较短的事实和结论。第三种是结构化压缩，把原始自然语言转换成更适合模型消费的中间表示，比如任务状态、实体槽位、待办列表、工具结果表。

实际用得比较多的是“摘要 + 结构化”。比如多轮会话里，闲聊和冗余表达可以摘要掉，但用户目标、约束条件、已确认参数、未完成步骤这些，会单独抽出来做结构化状态。这样模型接收到的是压缩后的高信息密度上下文，而不是大段聊天记录。

8、为什么有些 Agent 一到多轮就变差

多轮变差通常不是因为模型突然不会了，而是上下文和状态管理出了问题。比较常见的原因，一是历史太长导致注意力稀释，模型抓不住重点；二是任务状态没有显式维护，模型只能靠自然语言自己“记”；三是前一轮工具结果或者中间结论被错误继承，后续在错误基础上继续推理；四是用户补充信息后，系统没有正确融合进原任务。

所以多轮的关键不是“保留更多历史”，而是“保留有效历史，并把任务状态显式化”。很多时候引入 task state、slot memory、todo list 之后，多轮效果会明显稳定。

9、RAG 放在 Agent 里，和普通问答里的 RAG 有什么区别

普通问答里的 RAG 更像是“拿资料来回答”，重点是检索质量和生成忠实性。Agent 里的 RAG 不只是给答案，它更多承担的是给决策过程提供外部知识。比如模型在选工具前，可能要先检索工具说明；在执行任务中，可能要检索用户历史、业务规则、知识库文档；在多步任务里，每一步都可能依赖不同的召回结果。

所以 Agent 场景下的 RAG 更强调动态检索、多源召回和和任务阶段绑定。也就是说，不是一次检索贯穿到底，而是根据当前 step 的目标去检索当前最需要的信息。

10、如果线上发现 Agent 延迟明显变高，你怎么排查

我一般会先拆链路，不会一上来就归因到模型慢。先看是不是请求量变化导致排队，再看链路里各阶段耗时：意图识别、检索、工具调用、模型推理、结果后处理，分别是不是变慢。对于 Agent 系统，还要额外看平均调用步数是不是上升了，因为有时延迟变高不是单步变慢，而是系统开始“思考太多步”。

接着看近期有没有配置变更，比如 prompt 变长、上下文召回数量增加、tool description 变多、模型版本切换、温度和 max_tokens 调整。还要看工具调用失败率，因为失败重试也会拉高整体时延。最后会结合 trace 和日志定位