Binance 一面 | AI大模型实习 | Binance Accelerator Program

面试时间： 5.13

技术栈： Python、Agent、Multi-Agent、RAG、Claude Code

岗位链接： Binance Accelerator Program - Institutional Business Development

面试流程

自我介绍 → 手撕算法 → 项目问答（拷打Agent技术）

面试题目

1.自我介绍

2.手撕算法：最小覆盖子串（Hard，LeetCode 76）

滑动窗口经典题。维护一个窗口 [left, right]，用哈希表记录 t 中字符频次需求，当窗口满足所有需求时尝试收缩左边界。时间 O(n)，空间 O(字符集大小)。核心思路：right 扩张找可行解，left 收缩找最优解。注意用一个 formed 计数器追踪已满足的字符种类数，避免每次都遍历哈希表判断是否满足。

3.介绍项目开发过程，是如何和 Claude Code 配合完成的项目起步

核心回答思路： 讲清楚 Vibe Coding 的工作流。起步阶段：先写 CLAUDE.md 定义项目规则和技术栈约束 → 用自然语言描述目标（What/Why/How）→ Claude Code 生成初始架构和代码骨架 → 人工审查关键设计决策 → 迭代修正。配合方式：把"脑中隐性知识"外化为项目文件（CLAUDE.md + Memory + Plan），让 Agent 每次启动都能接上上下文。关键是人定方向、Agent 执行细节，人负责架构审查和边界判断。

4.是否有 PRD 文档可以展示

有。用 CLAUDE.md + 项目 Memory 文件作为"活 PRD"——不是传统的 Word 文档，而是随代码一起版本管理的规则文件。里面定义了：技术栈选型、目录结构规范、代码风格约束、禁止事项、模块职责划分。优势是 Agent 每次启动自动加载，保证开发一致性。

5.是否使用 harness 约束

是的。用 Claude Code 的 hooks 机制（settings.json 中配置的自动化行为）约束 Agent 的行为边界。例如：禁止 git push 到远程、提交前自动运行引号修复脚本、工具调用权限白名单等。Harness 的本质是把"人的审查规则"编码成系统级约束，让 Agent 在安全边界内自由发挥而不失控。

6.共享屏幕介绍项目构思迭代过程

展示 git log 的提交历史 + CLAUDE.md 的演进过程。重点讲：从最初的 MVP → 遇到什么问题 → 怎么迭代架构 → 每次迭代的 commit message 记录了什么决策。用 git diff 展示关键迭代节点的变化量。核心是让面试官看到"渐进式交付"的过程，而不是一次性生成。

7.新闻交易 Agent 项目管线如何搭建？agent 响应延迟是多久？新闻到交易完成需要的时间？

管线架构：

新闻源（RSS/API）→ 新闻抓取 Agent → 情感/事件分析 Agent → 交易信号生成 Agent → 风控校验 → 交易执行 Agent

延迟拆解：

• 新闻抓取：RSS 轮询间隔 5-30s，WebSocket 实时推送 <1s
• 情感分析（LLM 推理）：500ms-2s（取决于模型和 prompt 长度）
• 信号生成 + 风控校验：100-300ms（规则引擎，非 LLM）
• 交易执行（API 调用）：50-200ms

端到端： 从新闻发布到交易完成，最快 2-5s（WebSocket + 轻量模型），典型场景 10-30s（含 LLM 深度分析）。关键优化：用小模型做快速初筛，只有高置信度信号才走大模型深度分析，避免所有新闻都走重链路。

8.分析为何大家都在用 multi-agent？原因是什么？从一开始到现在原因是否有变化？使用多 agent 的意义是啥？

早期原因（2023）： 单 Agent 能力有限——上下文窗口小（4K-8K）、工具调用不稳定、推理能力弱。拆成多个 Agent 是"能力不足的变通方案"——每个 Agent 负责更小的子任务，降低单次推理的复杂度。

现在的原因（2025）： 模型能力大幅提升（200K 窗口、稳定工具调用），但 multi-agent 依然流行，原因变了：

1. 上下文隔离：不同子任务的中间状态互相干扰是实际痛点，隔离后每个 Agent 的推理质量更高
2. 专业化分工：每个 Agent 的 System Prompt 和工具集针对性更强，比"一个全能 Agent"更稳定
3. 并行提速：独立子任务并行执行，总延迟 = 最慢的那个 Agent
4. 可观测性：每个 Agent 的行为可独立追踪和调试，出了问题能精准定位

本质变化： 从"能力不足的补丁"变成了"工程最佳实践"。就像微服务不是因为单体"不能跑"，而是因为分开更好管。

9.Multi-agent 如何通信？在不同的项目中分别使用了哪些通信方法？Claude Code、Codex、OpenClaw、Hermes Agent 以及大厂自己开发的 multi-agent 是如何协作完成任务的？

通信方式分类：

协议层次区分（MCP vs A2A）：

• MCP（Model Context Protocol）：解决 Agent → 工具/资源 的连接，类比 USB 接口接外设
• A2A（Agent-to-Agent Protocol）：解决 Agent → Agent 的跨框架互操作，类比 HTTP 让不同服务互相调用
• 两者协同：A2A 负责水平通信（Agent 间委托任务），MCP 负责垂直连接（Agent 调工具）
• A2A 核心设计：Agent Card（/.well-known/agent.json 声明能力）→ Task 生命周期（submitted→working→completed）→ 支持多轮交互和长时间运行任务

具体项目对比：

• Claude Code：主 Agent 通过 Agent tool 派发子任务（prompt 即通信协议），子 Agent 返回结构化结果。上下文隔离靠独立对话窗口，持久化靠 Memory 文件
• Codex：多 Agent 通过 git worktree 隔离工作空间，通信靠 PR/commit message，适合并行开发
• OpenClaw：分层压缩记忆 + .md 文件作为 human-in-the-loop 审查接口，Agent 间通过事件触发流转
• Hermes：情景记忆（Episodic Memory）+ 双索引（语义+时间），Agent 间通过事件关联度匹配触发
• 大厂方案：通常是中心化 Orchestrator + 结构化消息总线，用状态机管理流转，强调可观测性和审计

10.智能客服长上下文不够用怎么办？agent 压缩机制有哪些？分析优劣。在面向客户使用时如何实现 multi-agent 并且实现用户体验良好？

压缩机制对比：

面向客户的 multi-agent 体验设计：

核心原则：用户感知到的是一个客服，背后是多个 Agent 协作。

1. 统一对话界面：用户始终在一个对话窗口中，Agent 切换对用户透明。用 Orchestrator Agent 管理路由，用户只和 Orchestrator 对话
2. Handoff 时传结论不传过程：Agent A 转给 Agent B 时，传结构化摘要（用户需求 + 已确认信息 + 待处理事项），不传原始对话历史。避免 B 重复问用户已经说过的信息
3. 追问策略：不让用户做填空题，让用户做选择题。"您是想查物流还是申请退款？"而不是"请问您有什么需求？"
4. 状态感知：每个 Agent 接手时，先用一句话确认已知信息——"我看到您要退货的是订单 XXX，对吗？"让用户觉得"它记得我说过的话"
5. 降级兜底：Agent 连续 2 次无法理解用户 → 自动升级到人工，附带完整上下文摘要，让人工客服无缝接续

11.知识库 RAG 和智能客服 agent 系统的成熟方案、标准方案以及优点局限性？

标准方案架构：

用户输入 → 意图识别/路由 → RAG 检索（向量+BM25混合）→ Rerank 精排 → LLM 生成回答 → 答案校验 → 输出

成熟方案对比：

标准方案的核心局限性：

1. 知识库覆盖度：用户问了知识库没有的问题 → 模型要么幻觉要么拒答，体验都不好
2. 多轮上下文管理：标准 RAG 是单轮检索，多轮对话中上下文漂移导致检索偏离
3. 个性化不足：同一个问题对不同用户应该有不同回答（VIP vs 普通用户），标准方案不区分
4. 实时性：知识库更新有延迟，新政策/新产品上线后用户马上来问，知识库还没入库

12.GraphRAG 叶子节点在智能客服中如何触发？

GraphRAG 的图结构：

根节点（全局主题摘要）

├── 社区节点（主题簇摘要）

│ ├── 实体节点（具体实体）

│ │ └── 叶子节点（原始文档 chunk / 三元组细节）

│ └── 实体节点

└── 社区节点

叶子节点触发机制：

GraphRAG 有两种搜索模式：

• Global Search：从社区摘要出发，适合全局性问题（"你们的退货政策整体是什么"）→ 不触达叶子节点
• Local Search：从具体实体出发，沿关系边遍历到叶子节点，适合具体细节问题

智能客服中的触发条件：

当用户问题涉及具体实体的细节信息时触发叶子节点检索：

1. 实体识别：从用户 query 中提取具体实体（产品名、订单号、功能名）
2. 图定位：在知识图谱中定位到该实体节点
3. 关系遍历：沿实体的关系边向下遍历到叶子节点（原始文档片段、具体参数、操作步骤）
4. 上下文聚合：收集叶子节点内容 + 沿途实体关系 + 所属社区摘要，组合成完整上下文

触发 vs 不触发的判断：

"你们有什么售后服务"	Global	否，社区摘要足够
"iPhone 15 能不能 7 天无理由退"	Local	是，需要具体产品的退货规则细节
"我的订单 123456 什么时候到"	Local + API	是，且需要调用外部系统

工程实现要点： 用意图分类器判断问题粒度——粗粒度走 Global（快但粗），细粒度走 Local 到叶子节点（慢但准）。两者可以级联：先 Global 判断主题范围，再 Local 深入到具体细节。

面试感受

• 整体偏考察 Agent 工程实践和多 Agent 系统设计能力
• 对 Vibe Coding / Claude Code 开发流程问得很细，建议提前准备好项目的 git 历史和 CLAUDE.md 演进过程
• Multi-agent 通信和智能客服是重点考察方向，需要对比不同项目的实现差异
• 算法手撕是 Hard 难度，建议刷熟滑动窗口模板