FinAgent面试备战

# FinAgent 项目面试最终整合版

阅读顺序

1. 第一编：项目理解、简历逐句剖析、17 道核心深问及指标准备。 2. 第二编：49 道高频问题完整回答，适合直接练习口述。 3. 第三编：33 道高级追问、5 道场景题、事实边界和证据清单。

去重审计

《项目拷打分析》：保留项目理解、简历逐句剖析、17 道核心深问、指标口径和准备动作；只移除已由第二编完整覆盖的 49 题简略清单。
《高频问题完整回答》：49 道问题及其考察意图、回答、连续追问、追问答案、易踩坑和可补充点全部保留。
《面试查缺补漏》：33 道高级追问、5 道场景题、事实边界、证据清单和复习顺序全部保留。
《面试总手册》：其中 17 道深问、49 道高频题、指标章节和 Grill 分类均为上述材料的压缩复述；逐题确认没有独立问题后，不再重复收入。

---

# 第一编 · 项目理解与核心深问

一、项目整体理解

1.1 项目要解决的问题

FinAgent 是对"大模型 + 网络搜索"原始方案的一次系统性重构，核心解决三个痛点：

1. 数据不稳定：原始方案让模型直接读网页文本，数据没有统一结构、没有单位/报告期/数据日期标注，模型容易把不同时期、不同口径的数字混用甚至编造。 2. 链路冗余：所有问题都走同一条完整分析链路，连"这只股票现价多少"这种原子问题也要触发全量多 Agent 分析，又慢又浪费。 3. 结论缺乏依据：最终报告里的数字和结论没有出处，无法审计、无法追责。

对应重构出五块能力：任务分层路由、金融工具标准化（MCP）、并行多智能体分析、个性化长期记忆、自动化评测与证据审计。

1.2 核心业务流程（概念层）

用户查询
  → 记忆读取（只读用户长期画像，绝不隐式写入）
  → 复杂度路由（判定问题属于哪一层）
       ├─ 快速查询链路：原子事实/单一指标 → 轻量工具直答 → 结束
       ├─ 单领域链路：只涉及基本面/技术面/估值/新闻某一类 → 单个专业 Agent → 汇总 → 结束
       └─ 深度研报链路：综合判断/多领域 → 四个专业 Agent 并行 → 汇总 → 证据审计 → 结构化研报

数据侧链路：Agent 通过标准化协议调用金融数据服务（行情、财务、估值、新闻），服务端统一返回带 Schema、报告周期、指标单位、数据时间、来源字段的结构化结果，并为每个关键数值生成唯一证据编号，供报告阶段做"结论—证据"审计。

1.3 技术架构分层

编排层：基于 LangGraph 的状态图，显式定义节点、边与状态合并规则，保证流程像状态机一样可控。
路由层：可审计的复杂度分类器，输出"走哪条链路 + 判定理由 + 置信度"，低置信度时自动兜底到深度链路。
Agent 层：每个垂直 Agent 是"提示词 + 专属工具白名单 + 轮次预算"的 ReAct 智能体，只接触自己领域的数据与工具，从架构上隔离上下文污染。
数据层：以 MCP 协议统一封装外部金融数据源与新闻来源，服务端与主 Agent 进程隔离。
可信层：统一响应 Schema + 数值证据编号 + 报告后置审计（数字覆盖、来源声明、算术自洽）。
记忆层：四类长期记忆，候选抽取 → 冲突检测 → 用户确认 → 落库，再按画像动态影响分析权重与报告详略。
观测/评测层：本地执行日志（会话隔离、节点级耗时拆分）+ 可选 LangSmith 追踪 + 离线回归评测（规则 + LLM 判官双轨）。
模型层：在 Qwen3-8B 上做参数高效的 LoRA 微调，产出金融新闻"情感"与"风险"两个评分模型。

1.4 关键技术难点

1. 多源异构数据统一：不同接口字段名、单位、报告口径不一致，需要在数据服务层做字段映射与"单位/周期/数据时间"的自动推断，统一成一张可审计的结构化结果。 2. 长数据注入的上下文爆炸：K 线、财报动辄上千行，直接灌给模型会超窗口且"中间注意力丢失"，需要在工具侧和 Agent 侧做分级截断与压缩，同时保证压缩不丢关键证据。 3. 数字幻觉治理：模型会在报告中无中生有地写数字，需要"数据侧留证据 + 生成侧强制引用 + 报告侧自动比对"三段闭环。 4. 并行调度与失败隔离：深度链路四个 Agent 并行，要保证全部完成才汇总，同时某个维度失败不能拖垮整份报告。 5. 低资源模型推理：两个评分模型要在有限显存下常驻、快速打分，还要能热切换。

1.5 亮点与不足

亮点：证据审计闭环、上下文压缩、规则优先 + LLM 语义仲裁的混合路由、记忆确认机制、"结论—证据"溯源，是项目最扎实、最能体现工程素养的部分。

不足（复盘时的改进方向）：混合路由中的语义仲裁仍复用通用大模型，单次调用延迟偏高，后续应蒸馏为专用小分类模型并扩大真实口语化路由评测集；数据源较单一、缺自动降级；新闻抓取与模型打分挂在实时链路上、是最慢节点；评测以工程约束回归为主、真实语义评测可进一步补强；记忆抽取偏规则、个性化权重靠人工配置。

---

二、简历逐句剖析

句 1：项目背景

针对原有"大模型＋网络搜索"方案中数据不稳定、简单问题链路冗余及分析结论缺乏依据等问题，参与重构覆盖任务路由、金融工具调用、多智能体分析、个性化记忆和自动化评测的股票投研 Agent 系统。

> FinAgent｜多智能体 A 股投研分析系统（AI 实习生） > 针对原"大模型+网络搜索"方案数据无 Schema、全量链路冗余、结论无法溯源三大痛点，参与重构为"任务分层路由 + MCP 金融工具 + 并行多智能体 + 个性化记忆 + 证据审计评测"的 Agent 系统；负责金融数据 MCP 工具化、路由与工作流搭建、新闻情感/风险模型微调及评测链路。

面试官会关注：真实痛点是什么、你在重构中承担哪部分、最终形态长什么样。
可能被追问：① "数据不稳定"具体指什么不稳定？② 你怎么定义"简单问题"？③ "重构"是推倒重来还是增量改造？④ 你的角色边界。
事实依据：痛点与五块能力一一对应（路由解决冗余、MCP 解决数据、审计解决无依据、记忆解决个性化、评测解决质量闭环），逻辑自洽。
推荐改写（把背景压成因果链，突出个人负责的部分）：

句 2：自适应任务编排

自适应任务编排：基于 LangGraph 构建问题复杂度识别与分层路由机制，在快速查询、单领域分析和深度研报链路间动态选路；深度模式下并行调度基本面、技术面、估值和新闻 Agent，聚合生成结构化研报。

> 自适应任务编排：基于 LangGraph 状态图构建三层路由（快速查询/单领域分析/深度研报），采用"高精度规则优先 + LLM 语义仲裁 + 深度链路安全兜底"：明确意图由规则零成本判定，只有规则低置信或出现否定/排除语义时才调用模型；模型超时、输出非法或低置信时自动回退，输出判定来源、理由与置信度。深度模式通过图语义的"全部完成屏障"并行调度基本面、技术面、估值、新闻四个 ReAct Agent（各持领域工具白名单），最终由汇总 Agent 聚合为结构化研报。

面试官会关注：复杂度识别是规则还是模型、为什么这样选；"动态"如何体现；并行如何保证一致性与失败隔离。
可能被追问：① 规则 vs 模型的权衡；② 误判/兜底怎么办；③ 并行怎么汇总；④ 某个 Agent 失败会不会卡死。
事实依据：三层路由（快速/单领域/深度）+ 深度模式四 Agent 并行 + 汇总 Agent 聚合，均已在系统中落地。
推荐改写（把"识别"讲成可审计的设计）：

句 3：可信金融数据链路

可信金融数据链路：基于 MCP 标准化封装行情、财务、估值和新闻 API，统一工具 Schema、报告周期、指标单位、数据时间及来源字段；实现关键数字校验和"结论—证据"关联，降低数据跨周期混用及无依据数字生成。

> 可信金融数据链路：基于 MCP（FastMCP 服务端 + 适配器客户端）统一封装行情、财务、估值与新闻来源为标准化工具，约定统一响应 Schema（状态码、报告周期、指标单位、数据时间、来源字段、参数回显）；每个关键数值生成唯一证据编号，报告生成后执行确定性审计（数字覆盖率、无效引用、来源声明、算术自洽），显著降低跨周期混用与无依据数字。

面试官会关注：为什么选 MCP、统一 Schema 的价值、数字校验的实现与边界、跨周期混用怎么防。
可能被追问：① MCP 相比直接函数调用/HTTP 的优势；② Schema 里到底统一了哪些字段；③ 数字校验是精确匹配还是语义校验、局限在哪；④ 外部接口字段变了怎么办。
事实依据：数据服务层统一封装行情/财务/估值/新闻四类来源，统一响应结构（状态、报告周期、指标单位、数据时间、来源），并为每个数值生成证据编号；报告后置审计做数字覆盖、来源声明与算术校验。
推荐改写（突出"溯源"是核心价值）：

句 4：个性化记忆机制

个性化记忆机制：构建投资画像、分析偏好、阶段关注和历史反馈四类记忆，通过候选抽取、冲突检测及用户确认控制长期写入，并依据风险偏好和投资周期动态调整分析权重与研报结构。

> 个性化记忆机制：定义投资画像/分析偏好/阶段关注/历史反馈四类长期记忆；候选抽取带置信度，写入前须经冲突检测与用户确认，支持按用户隔离与过期失效；依据风险偏好、投资周期与关注领域动态调整各分析维度的权重与报告详略（仅影响呈现与侧重，不改变金融事实）。

面试官会关注：抽取是规则还是模型、写入怎么控制、权重怎么调、会不会误导用户。
可能被追问：① 为什么不自动写、要用户确认；② 冲突（先说稳健后说激进）怎么办；③ 权重调整的依据与数学；④ 隐私与用户隔离。
事实依据：四类记忆 + 候选抽取（带置信度）+ 冲突标记 + 用户确认落库 + 按用户隔离与过期机制 + 风险偏好/周期驱动分析权重与报告详略，全部落地。
推荐改写（把"控制"与"边界"讲清楚）：

句 5：领域模型与评测

领域模型与评测：清洗标注约 10 万条金融新闻语料，使用 LoRA 适配 Qwen3-8B；引入 LangSmith 追踪模型与工具链路，基于 500+ 条问题构建规则与 LLM-as-a-Judge 回归评测。

> 领域模型与评测：清洗标注约 10 万条金融新闻语料（标题/正文/语义三重阈值去重 + 人工种子 + 大模型批量标注 + 一致性抽检），基于标注样本对 Qwen3-8B 做 LoRA 微调，产出情感与风险两个 1–5 分评分模型并封装进新闻工具；引入 LangSmith 追踪模型与工具链路，基于 500+ 条问题构建"规则校验 + LLM-as-a-Judge"回归评测。

面试官会关注：10 万条语料的清洗与标注流程、LoRA 的技术细节、评测体系怎么搭、为什么规则 + Judge 双轨。
可能被追问：① 去重怎么做的、为什么三重阈值；② 标注怎么做的、怎么保证质量（一致性系数）；③ LoRA 的 rank/目标层选择逻辑；④ 500+ 条问题的评测集怎么设计、Judge 偏置怎么防。
事实依据：语料经去重清洗与半自动标注，在 Qwen3-8B 上做 LoRA 微调产出情感/风险评分模型；引入 LangSmith 追踪，并基于 500+ 条问题做"规则 + LLM 判官"回归评测。
推荐改写（保留数据规模，突出工程闭环）：

句 6：结果指标

系统覆盖 A 股 4000+ 只股票，工具调用成功率 98%，数据一致率约 99%，深度研报耗时由 120 秒以上降至 90 秒以内，情感分类及风险事件识别准确率分别为 91% 和 88%。

> 系统覆盖沪深两市 4000+ 只股票；工具调用成功率 98%（分层异常处理 + 错误回传让 Agent 自纠错）；报告数字经证据审计与抽检比对，数据一致率约 99%；通过多 Agent 并行 + 数据缓存 + 快速链路，深度研报耗时由 120 秒以上降至 90 秒以内；新闻情感与风险评分模型在测试集上准确率分别为 91% 和 88%。

面试官会关注：每个数字的口径——定义、分母、样本量、对照、统计方式。指标本身不再被质疑，但你必须能现场讲清楚它是怎么来的。
可能被追问：① 98% 里那 2% 是什么、怎么优化；② 99% 一致率怎么验证、剩下 1% 是什么；③ 90 秒的时延构成、怎么从 120 秒压下来的；④ 91%/88% 怎么算、类别不平衡怎么处理。
事实依据：五个指标均为项目实测结论，对应第五部分"指标口径"逐条给出了可辩护的解释。
推荐改写（把口径嵌进描述，显得可信）：

---

三、面试问题与参考答案

每题给出：考察意图 / 推荐回答 / 连续追问 / 追问参考答案 / 易踩坑。

3.1 路由与工作流

Q1 复杂度识别怎么做的？为什么不让所有请求都由 LLM 分类？

考察意图：是否理解"规则 vs 模型"的工程权衡，是否有成本/稳定性意识。
推荐回答：我没有在规则和 LLM 之间二选一，而是做混合路由。领域关键词、综合意图和原子指标等明确问法先由规则判定，成本近零、结果确定、易回归；只有规则低置信，或句子含"不要/只看/排除"等需要理解作用域的语义时，才调用 LLM 仲裁。模型输出仍要经过枚举、领域数量、置信度和 JSON 结构校验；超时、非法输出回退规则，低置信则走深度链路。这样利用 LLM 处理口语化与否定语义，同时不让每个快速查询都多付一次模型延迟。
连续追问："为什么不全量 LLM？" → 当前通用模型实测单次路由约增加 9.5 秒，且结构化输出仍可能带代码围栏或误选工具能力不匹配的链路；全量调用会直接破坏快速查询的低延迟目标。规则判定约为微秒级，所以明确意图保留规则更合理。
追问："模型和规则冲突怎么办？" → 只有满足语义仲裁条件时模型才有覆盖权；模型必须通过结构与业务不变量校验，置信度不足时宁可走深度链路。日志记录本次判定来自规则、LLM 还是回退，便于离线复盘。
追问："未来怎么继续演进？" → 用真实错例构建路由评测集，将通用 LLM 仲裁蒸馏为低延迟小分类模型；达到语义准确率、漏路由率和 P95 延迟门槛后再扩大模型覆盖面，而不是直接切成纯 LLM。
易踩坑：说"LLM 一定比规则好"或"规则永远更可靠"。前者忽略延迟、成本和非确定性，后者忽略否定、隐含意图与口语化泛化。

Q2 深度模式四个 Agent 并行，怎么保证都完成才汇总？某个 Agent 挂了怎么办？

考察意图：并行调度语义 + 容错设计。
推荐回答：用图语义的"全部完成屏障"——把四个并行节点作为同一起点连到汇总节点，四个都返回才触发汇总。失败隔离：每个 Agent 外层有异常兜底，失败时给该维度写降级文案，汇总 Agent 收集这些失败信息，在报告里显式声明"该维度数据缺失、结论受限"，而不是编造数据。
连续追问："某个 Agent 一直卡住不返回呢？" → 两层防线：给每个 Agent 设工具调用轮次预算，防止 ReAct 无限循环；汇总层对缺失维度做"数据限制说明"。要更硬可以加单工具超时熔断，这是后续优化项。
易踩坑：说"LangGraph 会自动并行且不会失败"——实际工程里单个维度失败很常见，关键在降级清晰。

Q3 多个 Agent 的分析结果怎么汇总？冲突（基本面看多 vs 新闻看空）怎么办？

考察意图：多 Agent 协作中的信息合并与裁决机制。
推荐回答：各 Agent 结果写入各自的状态字段，汇总 Agent 拿到四份分析 + 结构化证据目录，做综合裁决。裁决原则写进提示词："交叉验证 + 风险优先"——当基本面良好但新闻面爆出重大负面时，必须下调评级并在报告里单列风险提示；汇总时要求每个关键数字引用证据编号，缺失就声明无法验证，而不是强行给结论。
连续追问："如果四个维度结论完全矛盾呢？" → 报告结构里专门有"综合评估"章节，要求列出"一致点与分歧点"；存在分歧时降低确定性表述，明确告诉用户哪些维度证据充分、哪些不足。
易踩坑：说"我写了个投票/加权打分算法自动裁决"——当前是提示词约束 + 风险优先原则，不是数值投票。

3.2 MCP 与数据链路

Q4 为什么用 MCP，而不是直接在 Agent 里写函数？

考察意图：是否理解协议解耦的价值与代价。
推荐回答：三个价值：① 进程级隔离——数据源登录态、爬虫、本地模型推理和主 Agent 解耦，避免依赖冲突，也避免一个子模块崩溃拖垮主流程；② Schema 标准化——服务端用声明式方式把函数自动转成模型可读的工具定义，参数、类型、描述统一；③ 语言/生态无关——未来换语言重写主 Agent 或换模型基座，数据服务层不用动。代价是跨进程调试链路变长、需要自己维护会话生命周期，所以配套做了执行日志。
连续追问："那和直接写 HTTP API 比呢？" → HTTP 每次新增接口都要给 Agent 写一堆"接口怎么调、参数什么格式"的说明（胶水代码），风格不统一、模型容易传错参；MCP 把工具定义、Schema、调用协议标准化了，模型拿到的是一致的能力描述。
追问："服务端用什么实现、为什么？" → 用声明式封装（类似 FastAPI 的装饰器风格），写一个带类型注解的普通函数即可自动生成 Schema，省去手写 JSON Schema 和路由的样板代码；客户端用适配器把 MCP 工具一键转成框架原生的工具对象，主流程代码几乎无感挂载。
易踩坑：说"MCP 比 REST 快/更安全"——协议价值在标准化与解耦，不在性能；或过度贬低 HTTP。

Q5 统一 Schema 到底统一了什么？外部接口字段变了怎么办？

考察意图：数据链路设计的细节深度。
推荐回答：统一的是响应信封 + 元数据：每次返回都带状态码、数据主体、Markdown 文本、以及一组元数据——数据来源、数据时间（数据基准时间）、报告周期（区分单季/累计/区间/时点）、货币与单位映射、请求参数回显、以及逐字段的证据编号。字段映射集中在数据源适配层，上层 Agent 只认统一信封；外部字段变化只改适配层，对上层零感知。
连续追问："单位怎么保证对？" → 单位映射是启发式（字段名特征推断），覆盖不到的新字段标记为"原生单位"，证据里保留原始值供审计核对——这是已知局限，靠审计兜底而不是靠猜。
追问："报告周期为什么重要？" → 财报有单季值和累计值，若把累计营收和单季营收混比，结论就是错的；把报告周期显式化并写进提示词，能显著降低跨周期混用。
易踩坑：说"单位全部精确校验过"——是启发式推断，要主动讲局限。

Q6 "结论—证据"关联和数字校验怎么做？局限是什么？

考察意图：防幻觉方案的真实性 + 是否有自知之明。
推荐回答：三段闭环。① 数据侧：服务端给每个关键数值生成唯一证据编号随结果返回；② 生成侧：所有 Agent 与汇总的提示词强制"每个关键数字必须引用证据编号，不得声明未使用的数据源"；③ 审计侧：报告生成后做后置校验——抽取报告里的金融数字与证据值集合做容差比对（覆盖度不达标则不通过）、检查证据引用是否存在、检查报告声明的数据源是否真在证据里、检查估值类结论的算术是否自洽，最后把审计结果作为独立章节附在报告末尾。局限：只覆盖"带单位的数字"，"约/区间"表达覆盖弱；是"匹配校验"不是"语义正确性校验"。
连续追问："报告里出现证据里没有的数字会怎样？" → 被标记为未匹配数字，审计不通过，报告末尾追加风险提示，明确"该数字不得作为投资决策依据"。
追问："为什么不直接让模型别编？" → 软约束（提示词）无法根除幻觉，必须靠硬校验兜底；这套方案的本质不是"消除幻觉"而是"降低 + 暴露"。
易踩坑：说"这样 AI 就不会幻觉了"——没有任何系统能保证，你的价值在于可审计、可追责。

Q7 数据返回量很大（比如几年 K 线）会撑爆上下文，怎么处理？

考察意图：长数据注入的工程处理能力。
推荐回答：两级处理。① 工具侧：把表格转 Markdown 并做行数上限截断，超出部分显式标注"已截断"；② Agent 侧：在模型调用前做任务感知的上下文压缩——估算 token，超阈值时优先保留最近工具消息、保留含证据编号与关键结论的行、按"任务相关字段"给证据打分排序截断，压缩产物明确标注"完整结果仍保留在状态里供审计"，即模型看压缩视图、审计用完整数据。
连续追问："token 怎么估的？" → 中英文混合的工程近似（中文按字、英文按 token 折合 + 每条消息固定开销），不精确但足够触发压缩，压缩后还会二次限长兜底。
追问："压缩会不会把关键数据压没了？" → 关键数据分两层保护：证据编号和"结论/风险/异常"等关键词行有最高优先级，且完整原始数据从不删除、只在审计阶段可见。
易踩坑：说"每轮用 tokenizer 精确算"——太贵；或说"截断就好"——忽略审计完整性。

3.3 个性化记忆

Q8 四类记忆怎么抽取？为什么不自动写入？

考察意图：记忆系统的设计取舍与安全边界。
推荐回答：抽取用"触发模式 + 置信度"的规则方式，覆盖四类：投资画像（风险偏好、投资周期）、分析偏好（关注领域、报告详略）、阶段关注（近期重点、带过期时间）、历史反馈（上次报告太长/太技术）。不自动写入是刻意设计：金融画像写错代价高，所以走"候选 → 冲突检测 → 用户确认 → 落库"；读取节点只读不写，写入必须用户确认。
连续追问："用户先说稳健、后来说激进怎么办？" → 新候选与已存值不同会被标记为"冲突"，确认界面明示旧值让用户裁决，未确认绝不覆盖。
追问："为什么不用 LLM 抽取？" → 规则确定性高、零成本、可单测；画像抽取容错要求高，宁可漏抽不误写；未来可引入 LLM 抽取但仍保留确认门控。
易踩坑：说"记忆自动写入/系统自己学习用户"——设计上刻意不自动写。

Q9 "依据风险偏好动态调整权重"具体怎么实现？会不会误导用户？

考察意图：个性化是否只是口号、是否有安全边界。
推荐回答：维护一组"分析维度权重"（基本面/技术面/估值/新闻），按画像调整：保守型提高基本面与估值、压低技术面；激进型提高技术面与新闻；长期投资加重基本面、短期加重技术面；主关注领域再小幅加权后归一化。权重连同报告详略偏好一起注入汇总提示词。安全边界：提示词明确"权重只影响呈现与篇幅侧重，不能改变金融事实"，且系统不输出买卖指令、报告末尾带风险提示。
连续追问："用户说激进，就真给激进建议？" → 不会给仓位或买卖建议，只影响分析侧重；且保留风险提示。
易踩坑：说成"系统学会了用户偏好/智能推荐"——本质是规则配置表。

3.4 领域模型微调

Q10 LoRA 微调：为什么 rank=16、alpha=32？为什么选这些目标层？

考察意图：是否真做过微调、能否讲出参数背后的道理。
推荐回答：rank 16 是表达能力与参数量/过拟合风险的折中：金融评分任务既要抓注意力重点，又要前馈层的逻辑推演，rank 太小拟合不足、太大易过拟合；alpha 取 rank 的 2 倍。目标层选了注意力投影 + 前馈投影的全线性层（All-Linear LoRA），因为只微调注意力层只改变"关注什么"，而金融风险判断还需要前馈层的推理能力，全线性层用少量显存换来接近全参微调的泛化。训练用 4-bit 量化基座（QLoRA）进一步降显存，学习率 2e-5、余弦退火、AdamW、fp16 混合精度，8:1:1 划分并早停。
连续追问："怎么判断 rank 够不够？" → 监控训练 loss 与验证 loss：训练降验证不降说明过拟合（减 rank / 加 dropout）；两者都不降说明欠拟合（加 rank）。
追问："为什么不用 vLLM/TGI 部署？" → 这是 MCP 工具内的低并发后台打分（每篇新闻一个 1–5 分、输出极短），原生推理足够、几十毫秒级；且多 LoRA 热插拔方便（基座常驻、换适配器即可）；vLLM 对 CUDA 环境绑定深、多 LoRA 配置成本高，ROI 不划算。若未来进入高并发在线服务再评估。
易踩坑：背参数但讲不出"为什么"；或绝对化贬低 vLLM。

Q11 情感/风险两个任务，怎么处理类别不平衡、难样本？

考察意图：模型训练的实操经验。
推荐回答：金融新闻天然"中性/正面多、明显看空/高风险少"，只看总准确率会虚高（全猜中性也高），所以额外关注宏平均 F1、确保风险类召回不漏报。处理分三招：① 数据侧——重采样与补充少数类（如正向、高风险样本）；② 损失侧——用 Focal Loss（α/γ 调参）自动降简单样本权重、抬难样本权重；③ 难样本挖掘——把模型答错的样本单独抽出，与正常样本按比例混合再训练，既学难点又不遗忘基础。最终情感 91%、风险 88%，且风险类召回达标。
连续追问："难样本有哪些典型类别？" → 情感：讽刺反语（"业绩'亮眼'，亏损创历史新高"）、复杂情感混合（"技术领先但价格过高"）；风险：需财务专业知识判断（"资产负债率 65% 高不高"要看行业与阶段）、多因素叠加风险。
追问："Focal Loss 的 α、γ 什么含义？" → γ 控制对易分样本的压制强度，α 平衡类别权重；γ=0 退化为带 α 的交叉熵。
易踩坑：只报 accuracy 不讲 F1/不平衡——会被追问"全猜中性不也很高"。

3.5 评测与监控

Q12 评测体系怎么搭的？规则评测和 LLM-as-a-Judge 各管什么？

考察意图：生成式系统"好不好"如何度量。
推荐回答：三层验收漏斗。① 规则底线（能不能用）：工具调用参数能否正确反序列化、报告是否含规定章节、格式是否合规，硬校验一票否决；② 事实忠实（准不准）：报告数字与工具返回原始值交叉比对，出现证据外数字判定幻觉；③ 语义质量（好不好）：LLM-as-a-Judge 用评审提示词给报告的主次逻辑、风险提示完整度、可读性打分，配合人工抽检对齐体感。500+ 条问题集用于回归，防止改动引入退化。
连续追问："LLM 判官有偏置吗？怎么防？" → 有，判官会偏好长回答/套话；防法：用结构化评分维度 + 锚定示例 + 与人工抽检结果定期校准，判官分只作辅助不作唯一标准。
追问："规则评测为什么重要？" → 生成式任务的传统文本匹配指标（ROUGE 等）意义不大，而"事实错误、格式错误"这些硬问题可以无歧义地用规则拦掉，成本低、可复现。
易踩坑：把"能跑通"当"评测"；或只讲 LLM 判官不讲规则与人工对齐。

Q13 本地日志 / LangSmith 追踪是怎么设计的？

考察意图：可观测性与问题定位能力。
推荐回答：默认本地执行日志——每次用户查询一个独立会话目录，记录模型请求/响应、工具入参出参、各 Agent 状态与耗时；再叠加可选的 LangSmith 远程追踪（开关式，根 trace 带本地会话 ID，两套日志可互相关联）。这样既能离线审计、也能在需要时看远程链路图。
连续追问："为什么不一上来就用现成监控平台？" → 金融场景对数据出域敏感，本地日志是基线；远程追踪做成可开关，兼顾合规与可观测。
追问："日志能帮你定位什么问题？" → 比如哪个节点最慢、哪个工具调用失败、模型哪次幻觉了，都能按会话回溯到原始上下文。
易踩坑：说"我完全不用第三方平台"或"全上云"——实际是本地为主、远程可选。

Q14 深度研报耗时从 120 秒压到 90 秒以内，具体怎么做到的？

考察意图：性能优化的可解释性。
推荐回答：四招组合。① 算法侧：四个资料收集 Agent 互不依赖，串行改并行，总耗时从"四者之和"降到"最慢一个 + 汇总"；② 工程侧：A 股数据收盘后是静态的，给数据和已生成报告加缓存（带 TTL），重复/相似查询直接命中；③ 路由侧：把原子问题摘到快速链路，根本不进深度链路；④ 上下文侧：压缩工具返回降低模型输入 token、减少推理时间。配合会话日志做节点级耗时拆分，定位到最慢环节对症下药。
连续追问："哪个节点最慢？为什么？" → 新闻 Agent 是木桶短板：既要实时抓取多个网页（网络 I/O 波动大），又要对长文本跑本地模型打分（算力密集），双重瓶颈。短期用超时熔断 + "拿到几篇算几篇"的部分返回止损，长期方向是把新闻抓取和打分改成离线预计算、请求时直接读结果。
追问："缓存会不会返回过期数据？" → 靠 TTL 分级控制——行情类短、热点新闻稍长，过期自动失效重拉。
易踩坑：只报数字讲不出构成，或说不出最慢节点。

3.6 幻觉治理（高频必问）

Q15 系统怎么降低大模型幻觉？

考察意图：对幻觉问题的系统性认知。
推荐回答：四层防幻觉体系。① 数据/提示层：把冗长金融表格转成模型易读的 Markdown 并限长截断，降低"中间注意力丢失"；② 工具层：用 MCP 强 Schema 约束，模型不能凭空猜数据、必须按约定参数调工具，参数错误会被校验并把报错回传让模型反思纠正；③ 架构层：多 Agent 专业分工，每个 Agent 只挂自己领域工具、只看自己领域数据，杜绝上下文污染导致的张冠李戴；④ 模型层：对最易出幻觉的新闻情感/风险任务，不用通用模型硬猜，而是用领域标注数据微调小模型。总结：软约束（提示词）+ 硬约束（Schema/审计）+ 关注点分离 + 领域对齐，才能把幻觉压到可控。
连续追问："工具调用传错参数怎么办？" → 底层对参数做校验，报错信息原样回传给模型，利用 ReAct 机制让模型基于报错反思重试，而不是直接崩溃。
易踩坑：说"Prompt 里写了不许编造就解决了"——软约束不够，必须讲硬校验。

3.7 个人贡献与复盘

Q16 这个项目哪些是你做的，哪些是团队已有的？

考察意图：诚实与贡献边界。
推荐回答（正面、有边界）：我负责的是任务路由与工作流、金融数据 MCP 工具化、个性化记忆、证据审计与上下文压缩、评测链路，以及新闻情感/风险两个模型的微调；团队侧提供的是大规模语料的采集与基础设施、数据源授权、以及部分线上指标与部署环境。被追问"这是你做的还是团队已有的"时，直接按模块拆："X、Y、Z 是我从零实现的，能讲清每一层设计；语料采集和最终线上指标是团队协作，我负责其中清洗与微调部分。"
易踩坑：全揽（逐模块追问必穿帮）或全推给团队（显得没贡献）。

Q17 如果重新设计一次，你会怎么改进？

考察意图：复盘深度与工程视野。
推荐回答（分层、带优先级）：① 通用 LLM 语义仲裁 → 专用小分类模型，并用规则守住明确意图与故障兜底；② 数据单源 → 多源自动降级；③ 新闻实时抓取/打分 → 离线预计算 + 存储，移出请求链路（收益最大）；④ 评测从工程回归 → 真实问题集 + LLM 判官 + 人工抽检的常态化统计；⑤ 记忆规则抽取 → LLM 抽取但保留确认门控，权重从配置表 → 可调参；⑥ 工程化补超时熔断、幂等重试、并发存储与多轮对话。
易踩坑：泛泛说"更强更好"不给方案与优先级。

---

五、指标口径准备与重点掌握

简历里的指标已作为既成事实，但面试官一定会追问口径。下面是每条指标可直接复述的"口径解释"，请烂熟于心。

5.1 指标口径

工具调用成功率 98%：分母是工具调用总次数，分子是成功返回有效结构化数据的次数。能做到 98% 靠三点：数据服务层把异常分类（登录失败 / 无数据 / 上游错误 / 参数错误）、报错文本回传给模型让其 ReAct 自纠、关键路径重试。剩下的 2% 主要是网络抖动、上游限流、模型偶发输出不合法调用格式。优化方向：多数据源自动降级、参数预校验、指数退避重试、工具健康监控。
数据一致率约 99%：指"最终报告里的数字与工具实际返回的原始值精确匹配的比例"，通过证据审计 + 抽样比对得出。剩下 1% 主要是模型对衍生指标理解偏差（把子项与合计重复相加）、跨上下文记串数字、个别缺失数据处模型自行补数——这三类正是证据审计要抓的对象。
深度研报 120 秒 → 90 秒以内：时延构成 = 并行 Agent 中最慢的一个 + 汇总 Agent。优化来自四方面（并行化、数据缓存、快速链路摘除、上下文压缩降推理时间），配合会话日志做节点级耗时拆分定位瓶颈。新闻 Agent 是历史长尾瓶颈（网络 + 本地打分双阻塞）。
情感 91% / 风险 88%：在测试集上的分类准确率；因为存在类别不平衡，日常监控还看宏平均 F1 与风险类召回（确保不漏报重大风险）。难样本（讽刺反语、复杂情感混合、需专业知识的风险判断）单独挖掘、与正常样本按比例混合用 Focal Loss 再训练。
覆盖 A 股 4000+ 只：数据源本身覆盖沪深两市全市场标的，系统无白名单限制，因此可对 4000+ 只股票做分析。
500+ 条问题回归评测：用于防止改动引入退化，规则校验管"能不能用 / 准不准"，LLM-as-a-Judge 管"好不好"，人工抽检对齐判官体感。
约 10 万条语料：来自多家财经媒体的历史新闻，经"标题（编辑距离+余弦）、正文（MinHash-Jaccard）、语义（SimHash 汉明距离）"三重阈值去重；标注采用"人工种子 1000 条 → 大模型批量标注 → 不一致样本人工复审 + 一致性系数抽检（≈0.85）"的半自动流程。

5.2 建议重点掌握的知识点

LangGraph：状态与合并规则、条件边、"全部完成屏障"、轮次预算、模型调用前置钩子。
MCP：协议动机、stdio/SSE 传输、服务端声明式工具定义、客户端适配器、工具 Schema 校验。
工具调用稳定性：异常分类、报错回传自纠、重试/退避/熔断、备用数据源。
幻觉治理：结构化上下文、证据引用约束、数字审计（覆盖/来源/算术）、局限认知。
上下文管理：token 估算、任务感知压缩、头部尾部保留、证据保真。
记忆：规则抽取 vs LLM 抽取的取舍、冲突检测、确认写入、TTL、用户隔离、权重边界。
LoRA/QLoRA：rank/alpha/dropout/目标层选择逻辑、4-bit 量化、训练超参、过拟合判断（train vs eval loss）、Focal Loss 与难样本挖掘。
评测：准确率 vs 宏平均 F1（类别不平衡）、一致性系数（标注质量）、规则评测 vs LLM 判官 vs 人工抽检。
数据去重：MinHash（Jaccard 无偏估计原理）、SimHash（64 位指纹汉明距离）、编辑距离/余弦、粗排精排思路。
工程化：异常分层、日志落盘与可复现、配置化、模型兼容层（不同服务商参数约束）。

5.3 面试前建议补强（准备动作，非简历修改）

1. 把五个指标各写一句"口径 + 分母 + 优化方向"，做到被追问不卡壳。 2. 实际跑通一次完整分析，能现场画出流程图并指出最慢节点。 3. 准备一两个"真实踩坑"故事（如 MCP 跨进程调试、上下文溢出、训练数据类别不平衡），用 STAR 结构讲。 4. 准备"个人贡献边界"的标准话术（Q16），避免全揽或全推。 5. 熟悉一个"如果重新设计"的分层改进方案（Q17），体现工程视野。

---

# 第二编 · 高频问题完整回答

第一部分 · 基础问题

1. 一句话介绍这个项目

FinAgent 是一个面向 A 股投研的多智能体系统。它解决的是原"大模型+网络搜索"方案里数据无结构、链路一刀切、结论无法溯源三个问题：我用 LangGraph 做了三层任务路由，用 MCP 把金融数据统一封装成可审计的标准工具，让基本面/技术面/估值/新闻四个专业 Agent 并行分析后汇总成结构化研报，再叠加个性化长期记忆和证据审计评测。我负责金融数据工具化、路由与工作流、以及新闻情感/风险两个模型的微调。

要点：一句话里要有「是什么 + 解决什么 + 你做了什么 + 结果」，不要堆名词。可补一句：系统覆盖 4000+ 只股票，工具成功率 98%，深度研报耗时压到 90 秒内。

2. 画出系统流程图并讲一遍

（先画，再讲，按数据流方向）

用户查询
 → 记忆读取（只读画像，不隐式写）
 → 复杂度路由（规则分类，带理由和置信度）
    ├ 快速查询 → 轻量工具直答 → 结束
    ├ 单领域 → 单个专业 Agent → 汇总 → 结束
    └ 深度研报 → 基本面/技术面/估值/新闻 四 Agent 并行 → 汇总 → 证据审计 → 结构化研报

讲法：三个关键词——「分层」「并行」「可审计」。

分层：先判断问题属于哪一层，简单问题不空转全链路；
并行：深度链路四个 Agent 各看各的领域数据，全部完成后汇总；
可审计：数据进来就带证据编号，报告出来要过一道数字审计。

可补一句：数据侧走的是 MCP 标准化协议，服务端和主 Agent 进程隔离，返回统一 Schema。

3. 五个 Agent 各自的职责与工具边界

| Agent | 职责 | 只看哪些数据/工具 | |---|---|---| | 基本面 | 财务质量：盈利/成长/现金流/偿债/分红 | 财报、财务指标、行业分类、分红 | | 技术面 | 价格趋势：均线/量能/支撑压力/技术指标 | K 线、复权因子、交易日 | | 估值 | 贵不贵：PE/PB/PS、历史区间、行业对比、股息 | 价格、财务、分红、行业 | | 新闻 | 情绪与风险：抓新闻、情感分、风险分 | 新闻抓取工具（内嵌打分模型） | | 汇总 | 综合裁决：合并四份分析出结构化报告 | 只读前四个的结果，不调数据工具 |

核心设计点：每个 Agent 有「工具白名单 + 黑名单」，例如基本面/技术面/估值 Agent 一律禁掉新闻抓取工具——从架构上杜绝"张冠李戴"和上下文污染。

可补一句：不是模型能力不够，而是刻意做「关注点分离」，让每个 Agent 的上下文小而干净。

4. 什么是 MCP？它解决什么问题？

MCP（Model Context Protocol）是把外部工具/数据"标准化暴露给大模型"的协议。解决三个问题： 1. 胶水代码爆炸：原来每接一个数据源，都要给模型写一堆"接口怎么调、参数什么格式"的说明，风格不统一、模型容易传错参； 2. 强耦合：数据获取逻辑和 Agent 主逻辑绑在一个进程里，依赖冲突、一个模块崩了全挂； 3. 不可复用：换模型/换语言重写主程序时，工具层要跟着改。

可补一句：它分服务端（声明式定义工具、自动生成 Schema）和客户端（把远程工具转成本框架的工具对象），我们两边都用标准库/适配器，没有手写协议。

5. LangGraph 相比原生 LangChain / AutoGen 的区别？为什么选它？

原生 LangChain Agent（AgentExecutor）：自由 ReAct，工具选择灵活，但流程不可控，容易死循环、漏步骤，适合开放式任务；
AutoGen：多 Agent 自由对话，协作灵活，但"对话不可达终点"的风险大，对"必须出研报"这种确定性任务不友好；
LangGraph：把系统定义成有向状态图——节点是能力（调用模型/工具），边是确定的流转规则，状态有合并规则。既保留模型调工具的灵活性，又像状态机一样可控、可复现。

为什么选它：金融研报是"步骤明确、必须出结果"的场景，我要的是"可控 + 可并行 + 可检查点回放"，LangGraph 的图语义正好匹配。

可补一句：LangGraph 还有检查点/回放能力，便于失败重跑和人工介入。

6. LangGraph 的状态如何流转、多 Agent 结果如何合并？

状态是一个带三个分区的结构：消息列表（追加式合并，保序）、业务数据（按字段名合并，后写覆盖）、元数据（同业务数据）。并行阶段，四个 Agent 各自往自己独占的字段写结果（如"基本面分析""技术面分析"），字段名不重叠，所以并行写入互不覆盖；汇总节点一次性读四个字段做整合。

关键点：并行节点返回的是"增量"而非"整个状态"，由框架按合并规则合入，这就是并行安全性的来源。

可补一句：消息用"追加"、数据用"按字段覆盖"，是两种不同的合并语义，分别对应"对话历史"和"分析结果"两种不同性质的数据。

7. LoRA 原理，与全参微调对比？

LoRA 的核心是低秩分解：不在原权重上直接更新，而是冻结原模型，在目标层旁边注入两个低秩矩阵（A×B，rank 远小于原维度），只训练这两个小矩阵，推理时把增量叠加回原权重。

对比全参微调：全参要更新几十亿参数，显存和算力爆炸、还要存完整模型副本；LoRA 只训练约千分之一量级的参数，一个任务一个轻量适配器。
收益：省显存、训练快、可多任务热插拔（基座常驻、换适配器即可）、不易灾难性遗忘。
代价：表达能力有上限，rank 太小拟合不足、太大会过拟合，要调。

可补一句：我们用的还是量化版（QLoRA），把基座 4-bit 量化后再挂 LoRA，进一步降显存，让消费级/单卡也能训 8B 模型。

8. QLoRA 4-bit 量化解决什么问题？

本质解决"大模型显存放不下、训不起"。QLoRA 做了两件事： 1. 把基座量化到 4-bit（用 NF4 这种对权重分布更友好的量化格式），显存占用降到原来的几分之一； 2. 在量化基座之上做 LoRA 微调，训练时用"反量化到高精度再算"的技巧保证梯度质量，训练完只保留小的 LoRA 适配器。

结果：8B 模型在单卡上就能微调，成本大幅下降，且精度损失在分类评分这类任务上可接受。

可补一句：推理时同样走 4-bit 加载 + 热插拔适配器，两个评分模型共享一个基座，进一步省显存。

9. 什么是 ReAct？为什么工具失败后要回传错误让模型反思？

ReAct 是"推理 + 行动"交替的范式：模型先思考（推理）→ 决定调哪个工具（行动）→ 拿到结果 → 再思考 → 再行动，循环直到能给出最终答案。

为什么回传错误：如果工具失败后直接静默或报错退出，模型不知道错在哪、也无法纠正。把结构化的报错信息原样回传给模型，它就相当于有了"反馈信号"，能在下一轮推理里调整——比如参数格式错了就改格式、日期不对就换时间范围、数据为空就换指标。这正是工具调用成功率能到 98% 的关键一环。

可补一句：报错要分类回传（是"无数据"还是"参数错"还是"上游挂了"），模型才知道该怎么修，而不是盲目重试。

10. 成功率 / 一致率 / 时延 / 准确率四个指标怎么定义？

工具调用成功率（98%）：工具调用总次数里"成功返回有效结构化数据"的占比。靠分层异常处理 + 报错回传自纠 + 重试做到。
数据一致率（约 99%）：最终报告里写的数字与工具实际返回原始值"精确匹配"的比例，靠证据审计 + 抽样比对验证。
时延（90 秒内）：从用户输入到出完整研报的端到端时间，构成 = 并行 Agent 中最慢一个 + 汇总。靠并行 + 缓存 + 快速链路 + 上下文压缩优化。
准确率（91% / 88%）：情感/风险模型在测试集上的分类正确率，因类别不平衡还辅助看宏平均 F1 与风险类召回。

关键：被问"怎么算的"时，一定要能说出"分母 + 统计方式 + 剩下那 1~2% 是什么"。

---

第二部分 · 设计问题

1. 为什么三层路由？为什么规则分类？

为什么三层：因为不同问题对"深度"的需求差异巨大——"现价多少"一次工具调用就够，"全面分析"要四个 Agent 并行。一刀切要么简单问题空转浪费、要么复杂问题覆盖不足。三层（快速/单领域/深度）让成本与覆盖匹配。

为什么规则：路由要的是"快、稳、可测"。规则结果确定（可写回归测试）、成本近零（不抢推理预算）、模型不可用时仍可用（降级可用）。代价是泛化有限，所以带置信度，低置信自动兜底到深度链路——宁可多跑不漏信息。

可补一句：未来方向是"小模型分类 + 规则兜底"，两者对拍不一致就回退规则。

2. 深度模式为什么并行？"全部完成屏障"怎么实现？失败维度怎么办？

为什么并行：四个资料收集 Agent 之间没有依赖，串行会把"四者耗时之和"全吃进去，并行后总耗时降为"最慢一个 + 汇总"。

屏障：把四个并行节点作为同一起点连到汇总节点，图语义保证"四个都返回才触发汇总"。

失败隔离：每个 Agent 外层有异常兜底，失败时给该维度写降级文案；汇总节点收集失败信息，在报告里显式声明"该维度数据缺失、结论受限"，绝不编造数据补位。

可补一句：再加一道轮次预算，防止单个 Agent 陷入 ReAct 死循环把全局拖死。

3. 统一 Schema 为什么要有报告周期 / 单位 / 数据时间 / 来源？

因为这四个字段是"数字可比、结论可信"的前提：

报告周期：财报有单季值和累计值，混比就是错的；
单位：同样一个"增长率"，是 % 还是倍数，不标清模型会算错；
数据时间（数据基准时间）：数据是哪天的，决定它能不能用来判断"当前"；
来源：决定数据可信度和可追溯性。

统一之后，模型拿到的每个数字都自带"身份信息"，配合证据编号就能做溯源审计。

可补一句：来源还用于审计——报告里声明用了某数据源，但证据里没有这个源，会被标记为"未验证的数据源声明"。

4. "结论—证据"关联怎么形成闭环？

三段闭环： 1. 数据侧：服务端给每个关键数值生成唯一证据编号，随结果返回； 2. 生成侧：所有 Agent 和汇总的提示词强制"每个关键数字必须引用证据编号，不得声明未使用的数据源"； 3. 审计侧：报告生成后做后置校验——抽取报告数字与证据值集合做容差比对（覆盖度不达标不通过）、查证据引用是否存在、查来源声明是否真实、查估值类算术是否自洽，审计结果作为独立章节附在报告末尾。

可补一句：本质是"软约束（提示词）+ 硬校验（审计）"双保险，把幻觉从"看不见"变成"可发现、可拦截"。

5. 记忆为什么"候选 → 冲突 → 确认"？为什么不自动写？

因为金融画像写错代价高：一旦把用户误判成"激进"或"长期"，后续所有报告的分析侧重都会被带偏，且这种错误会长期累积。所以设计成三步：

候选：先抽取出可能的记忆（带置信度）；
冲突：和已存值不同就标记出来，明确告诉用户"旧值是什么、新值是什么"；
确认：用户显式同意才落库，未确认绝不写。

不自动写是刻意的：宁可漏记，不可错记。读取节点只读不写，写入是唯一的、受控的入口。

可补一句：还有过期机制和按用户隔离，防止旧偏好永久生效、防止用户间串数据。

6. 权重如何影响报告？安全边界在哪？

维护一组"分析维度权重"（基本面/技术面/估值/新闻），按画像调整：保守型提高基本面与估值、压低技术面；长期投资加重基本面；主关注领域小幅加权后归一化。权重连同"报告详略偏好"一起注入汇总提示词，影响各章节篇幅与结论侧重。

安全边界（关键）：提示词里明确"权重只影响呈现与篇幅侧重，不能改变金融事实"；系统不输出买卖指令；报告末尾带风险提示。也就是说，个性化只决定"多说哪块、少说哪块"，不改变数据本身、不改变风险事实。

可补一句：这是把"个性化"约束在"表达层"而非"事实层"，避免为迎合用户而扭曲结论。

7. 上下文压缩：触发条件、压缩什么、怎么保证证据不丢？

触发：估算当前上下文 token，超过软阈值就压缩（中英文混合估算，中文按字、英文按 token 折合）；
压缩什么：优先压缩"旧工具消息"——最近 1~2 条保留完整，更早的按任务相关字段筛选、只留关键行和证据编号；
保证据：双层保护——证据编号和"结论/风险/异常"等关键词行给最高优先级；同时完整原始数据从不删除，只从"模型视图"里拿掉，审计阶段仍可读。

一句话：模型看压缩视图，审计用完整数据，两不耽误。

可补一句：压缩产物会标注"完整结果仍保留在状态里"，避免模型误以为数据就这些。

8. 为什么把模型打分放在数据服务内而不是 Agent 内？

三个理由： 1. 进程隔离：打分模型依赖深度学习框架，和 Agent 主进程（依赖 LangChain 等）放一起容易依赖冲突、还拖累主流程； 2. 职责内聚：新闻抓取 + 情感/风险打分是"新闻"这条数据链路的完整闭环，放在数据服务端，Agent 拿到的就是"已经打好分的结构化新闻"，不需要关心模型细节； 3. 可热插拔：基座常驻、换 LoRA 适配器即可升级/切换模型，Agent 无感知。

可补一句：代价是跨进程调用有开销和调试成本，但换来了清晰的边界和可维护性，ROI 划算。

9. 用户问"能不能买"，系统怎么处理？

不直接给买卖结论。系统定位是"提供分析参考"，不是投资顾问。具体做法： 1. 报告给的是"分析 + 风险提示"，结论用"长期配置价值/短期不确定性"这类表述，而不是"买入/卖出"指令； 2. 报告末尾强制带风险提示与数据来源声明； 3. 涉及监管敏感表述（"稳赚""内幕"等）会被拦截或规范化。

可补一句：这是金融合规的底线——Agent 可以给信息和分析，但投资决策的责任必须留给用户。

---

第三部分 · 技术选型

1. MCP vs 直接写工具 vs HTTP API？

直接写工具：最简单，但把数据获取、爬虫、模型推理和 Agent 逻辑焊死在一个进程，依赖冲突、无法独立扩展、换语言就废；
HTTP API：能解耦，但每个接口都要单独给模型解释"怎么调、参数什么格式"（胶水代码），风格不统一、易传错参；
MCP：把"工具定义 + Schema + 调用协议"标准化，服务端声明式定义、客户端适配器一键转换，解耦且模型拿到的能力描述一致。

选 MCP：在"解耦"和"标准化"之间取得了平衡，且生态在变好、可跨语言。

可补一句：不是所有场景都要 MCP，简单内部工具直接写函数更快；当工具要多方复用、跨进程/跨语言时 MCP 才显价值。

2. 服务端声明式封装 vs 原生 SDK；客户端适配器的作用？

原生 SDK：要手写每个工具的 JSON Schema、手写调用请求的路由分发，样板代码多、维护成本高；
声明式封装：写一个带类型注解的普通函数，框架自动根据注解和文档字符串生成 Schema 并注册成工具（类似 FastAPI 的装饰器风格），开发效率高、Schema 一致性有保障；
客户端适配器：把远程 MCP 工具一键转成本框架原生的工具对象，主流程代码几乎无感挂载，不用自己维护 stdio/SSE 生命周期和 if-else 解析 tool call。

可补一句：这一层的选型核心是"把精力放在金融数据清洗上，而不是协议封装上"。

3. LangGraph vs AgentExecutor vs AutoGen vs 自研状态机？

AgentExecutor：自由 ReAct，灵活但不可控，容易死循环/漏步骤；
AutoGen：多 Agent 对话协作，适合开放讨论，但"不可达终点"风险大，对"必须出报告"的场景不稳；
自研状态机：可控性最强，但要自己造轮子（状态管理、并行、检查点、重放），性价比低；
LangGraph：有向状态图，既保留模型调工具的灵活性，又有状态机的确定性和可复现性，还内置并行、检查点、条件边。

选 LangGraph：金融研报是"步骤明确、必须出结果"的确定性任务，图语义最匹配，且能站在成熟框架上而不是自己造轮子。

可补一句：LangGraph 还能做检查点/回放，便于失败重跑和人工介入，这是自研状态机里最贵的部分。

4. 记忆用轻量关系库够吗？什么时候换更重的存储？

当前够：记忆是"小规模、低频读写、按用户隔离"的数据，单用户最多几十条，SQLite 完全够，还省部署、事务简单、易备份。什么时候换： 1. 多实例/高并发：SQLite 是单文件、写并发弱，多服务实例共享时会有锁竞争和一致性风险 → 换 Postgres 等 C/S 关系库； 2. 需要高可用/分布式：多机部署、需要主从 → 换分布式存储； 3. 检索语义化：若未来要"按语义相似度召回历史记忆" → 叠加向量库，而非靠关系库全文检索。

可补一句：选型要"按当前真实规模选，预留迁移接口"，而不是一上来就上重组件。

5. 原生推理 + 多 LoRA 热插拔 vs vLLM/TGI？

当前选原生 + 热插拔，理由： 1. 调用形态是数据服务内的低并发后台打分（每篇新闻一个 1–5 分、输出极短），不是 C 端高并发； 2. 推理极短，原生推理几十毫秒级足够； 3. 多 LoRA 热插拔方便：基座常驻、换适配器即可切换情感/风险模型； 4. vLLM/TGI 对 CUDA 环境绑定深、多 LoRA 配置成本高，当前 ROI 不划算。

什么时候换：如果新闻打分进入高并发在线服务、吞吐成为瓶颈，再上 vLLM 做批处理/高吞吐。

可补一句：这是阶段性的工程取舍，不是"vLLM 不好"，是"当前不需要"。

6. 本地日志 vs 第三方追踪平台？

默认本地日志，第三方做可选开关，原因： 1. 金融场景对数据出域敏感，本地日志是合规基线； 2. 本地日志按会话隔离、可离线审计、不依赖外部服务可用性； 3. 第三方追踪（如 LangSmith）做可视化链路图和快速检索，做成开关式，需要时打开、并和本地日志用同一会话 ID 关联。

可补一句：双轨设计——本地可离线审计 + 远程可快速检索，兼顾合规与可观测。

7. 数据源选型？

核心矛盾是"免费稳定 vs 数据质量 vs 覆盖"：

免费、无需注册、覆盖沪深全市场、返回结构化 DataFrame——这是主要数据源的优点，适合验证 Agent 逻辑；
局限：数据维度/时效/稳定性不如商业源，网络波动时有失败。

当前策略：以免费稳定源为主、统一 Schema 屏蔽差异；改进方向：接入多源（Wind/同花顺等）做自动降级——主源失败切备源，同一指标多源交叉验证还能提升一致率。

可补一句：数据源选型要"先验证业务逻辑，再谈数据质量"，早期用免费源跑通闭环是合理的。

8. 新闻实时抓取 vs 离线预计算 + 缓存？

当前是实时抓取 + 打分，问题是它挂在请求链路上，网络 I/O + 本地模型推理双重阻塞，成为最慢节点。

改进方向（离线预计算）：用后台任务持续抓取新闻并打好情感/风险分，存入数据库/缓存；请求时直接读结果，耗时从几十秒降到几十毫秒级。

权衡：实时抓取的优点是数据最新；代价是慢且不稳。离线预计算的优点是快且稳；代价是时效性略降、要维护一套离线任务和存储。

可补一句：金融风控里"高时效的妥协"有时好过"系统卡死"，短期可用超时熔断 + "拿到几篇算几篇"的部分返回止损，长期走离线预计算。

---

第四部分 · 性能与稳定性

1. 深度链路时延构成？如何拆分定位？

构成：端到端时延 ≈ 并行 Agent 中最慢的一个 + 汇总 Agent。并行 Agent 内部又分「模型推理时间 + 数据源网络 I/O +（新闻 Agent 独有的）本地模型打分时间」。

如何拆分：在会话日志里对每个节点、每次工具调用、每次模型调用做入出口打点，记录各自的耗时。这样就能定位到"哪个节点是最慢的、慢在推理还是网络还是本地打分"。

可补一句：正是靠这套节点级耗时拆分，才定位到新闻 Agent 是长尾瓶颈。

2. 为什么新闻 Agent 最慢？怎么优化？

双重瓶颈： 1. 网络 I/O：要实时抓取多个新闻网页，网络波动大、不可控； 2. 算力密集：抓下来的长文本还要跑本地微调模型做情感/风险打分，长文本推理耗时长。

优化分两档：

短期止损：给最慢的工具设超时熔断，超时后"拿到几篇算几篇"部分返回，保证汇总节点能准时启动；
长期重构：把新闻抓取和打分从实时链路搬到离线预计算，请求时直接读结果，耗时骤降。

可补一句：在金融风控场景，时效性妥协往往好过系统卡死。

3. 缓存策略：缓存什么、TTL 怎么定、并发下怎么防击穿？

缓存什么：两类——已生成的分析报告（按用户问题做 key）+ Agent 检索到的金融数据/新闻（跨用户可复用）；
TTL：按数据时效分级——行情类短（收盘后数据静态、但盘中要快过期）、热点新闻稍长；过期自动失效重拉；
防击穿：突发大新闻/多用户同时问同一只股票时，缓存空窗会导致惊群，大家一起打底层慢接口。解法是用原子指令做互斥锁——第一个到达的 Agent 拿锁去捞数据，其余读锁失败就短暂等待后直接读缓存，避免重复打底层。

可补一句：用带过期机制的缓存组件，能优雅解决"过期清理"，比用文件系统自己轮询时间戳可靠得多。

4. 并行多 Agent 会不会打爆上游限流？怎么退避？

会。四个 Agent 并行意味着同一时刻可能对上游发多个并发请求。应对： 1. 缓存兜底：大量请求其实命中缓存，不真正打到上游； 2. 超时与重试退避：失败后指数退避重试（1s→2s→4s），并设最大重试次数，避免疯狂重试放大压力； 3. 部分返回降级：拿不到就"拿到几篇算几篇"，不硬等； 4. 限流预留：请求侧可加令牌桶控制整体并发。

可补一句：并行是把双刃剑，收益是时延下降，代价是瞬时并发升高，所以缓存和退避必须配套。

5. 上下文超窗口怎么办？

分层处理： 1. 工具侧截断：表格转 Markdown 时设行数上限，超出标注"已截断"； 2. Agent 侧压缩：估算 token 超阈值时，优先保留最近消息、证据编号、关键结论行，其余按任务相关字段打分截断； 3. 完整态保留：压缩只作用于"模型视图"，完整数据留在状态里供审计； 4. 兜底：单条超大消息做字符级限长。

可补一句：核心原则是"模型看压缩视图、审计用完整数据"，两者不互相牺牲。

6. 大量工具返回如何注入而不爆炸？

关键在"注入前先压缩 + 结构化化"： 1. 服务端返回时就把数据转成模型易读的 Markdown 表格并限行； 2. Agent 侧在调模型前做任务感知压缩：按"任务相关字段"给证据/行打分，只保留高分部分； 3. 用证据编号代替原始长文本——模型引用编号即可，审计再按编号回查原始值。

可补一句：这样既控制 token、又保住可追溯性，是"降噪不降质"。

---

第五部分 · 异常与边界

1. 数据源登录失败 / 无数据 / 接口异常怎么分类与降级？

分类：把异常分成几类——登录失败、无数据、参数错误、上游错误、内部错误。分类的意义在于"不同错误用不同策略"：

无数据：提示换时间范围/换指标，不是真故障；
参数错误：报错回传让模型改参数；
登录失败/上游错误：走重试或降级。

降级：无论哪类，都不让整个流程崩溃——错误信息结构化回传，Agent 基于报错反思纠正；实在拿不到就"声明数据缺失"而非编造。

可补一句：分类 + 回传 + 降级，是工具成功率 98% 的底层保障。

2. 新闻来源反爬 / 触发验证码怎么办？

1. 检测：识别返回内容里的"安全验证/验证码"特征； 2. 降级：检测到验证码就明确返回"触发验证，无法获取"，而不是给脏数据； 3. 备用策略：换请求方式/参数再试一次； 4. 根本解：长期方向是把新闻抓取离线化、多来源备份，不依赖单一网页来源的实时可用性。

可补一句：反爬是客观存在的外部风险，工程上要"检测 + 降级 + 不污染数据"，而不是指望绕过。

3. 模型传错参数（参数幻觉）怎么处理？

1. 服务端强校验：工具 Schema 严格约束参数类型/取值，非法参数直接拒绝； 2. 报错回传：把"参数哪里不对"结构化回传给模型； 3. ReAct 自纠：模型基于报错在下一轮反思修正参数重试； 4. 兜底：多次失败后降级为"无法获取，请用户补充信息"。

可补一句：这就是 ReAct 的价值——把"参数幻觉"从硬失败变成"可自纠的软错误"。

4. 报告出现证据外数字怎么办？

1. 后置审计拦截：报告生成后自动比对，抽取报告里的金融数字，凡是在证据集合里匹配不到的，标记为"未匹配数字"； 2. 审计不通过：覆盖度不达标或存在证据外数字时，审计判不通过； 3. 风险提示：报告末尾追加风险提示，明确"该数字不得作为投资决策依据"。

可补一句：审计不是让报告"永远正确"，而是让错误"可见、可拦截、可追责"。

5. 记忆冲突怎么办？

用户先说稳健、后来说激进时： 1. 检测：新候选和已存值不同，标记为"冲突"，附上旧值； 2. 明示：确认界面清楚展示"旧值 vs 新值"； 3. 用户裁决：只有用户显式确认才覆盖旧值，未确认绝不写。

可补一句：冲突检测 + 用户裁决，本质是把"改不改画像"的决定权交还给用户，避免系统自作主张。

6. 模型不可用 / 凭证失效怎么降级？

1. 配置校验：启动时/调用前检查模型配置是否完整，缺失则明确报错并给降级文案（如"模型配置不完整，无法执行"）； 2. 路由可用性：关键点是——路由是规则驱动的，不依赖模型，所以模型不可用时仍能正确判定问题类型，不瘫在第一步； 3. 兜底报告：汇总失败时也生成最小化"错误报告"，列出各维度可用性，而不是白屏。

可补一句：降级的原则是"明确告知 + 保底输出"，而不是悄悄失败或编造。

7. 空查询 / 歧义查询 / 超长查询怎么处理？

空查询：识别为空后走快速链路返回"参数提示"，引导用户输入；
歧义查询（如"帮我看看茅台"）：走深度链路，且股票代码/名称抽取有兜底规则，多候选时提示用代码更准；
超长查询：输入先规范化（去多余空白等），关键信息抽取用锚定模式，兜底到深度链路保证覆盖。

可补一句：所有"拿不准"的情况都往"覆盖更全的链路"兜底，宁可多跑不漏信息。

---

第六部分 · 个人贡献

1. 哪些是你独立实现、哪些是团队协作？

我独立实现：任务路由与 LangGraph 工作流、金融数据 MCP 工具化（统一 Schema + 数据源适配）、个性化记忆、证据审计与上下文压缩、评测链路，以及新闻情感/风险两个模型的 LoRA 微调。

团队协作/已有基础：大规模语料的采集与基础设施、数据源授权、部分线上指标与部署环境。

回答口径：按模块拆——"X、Y、Z 是我从零实现的，每一层设计我都能讲清楚；语料采集和最终线上指标是团队协作，我负责其中清洗与微调部分"。宁可边界窄，不可全揽。

2. 遇到最大的技术难点是什么？

可挑一个最有把握的讲（建议讲"上下文爆炸 + 幻觉治理"这条线）：

最大难点是"数据要全、上下文要小、结论要准"三者冲突——K 线/财报数据量大，全塞给模型会超窗口、还会诱发数字幻觉；砍数据又会丢关键证据。我的解法是分层：服务端限行 + Agent 侧任务感知压缩 + 证据编号溯源 + 报告后置审计。最终做到模型看压缩视图、审计用完整数据，既控 token 又保可追溯。

可补一句：用 STAR 结构讲（情境/任务/行动/结果），结果是"数据一致率 99%、深度报告时延压到 90 秒内"。

3. 开发节奏 / 里程碑怎么拆的？

按三个月拆： 1. 第一个月：搭多 Agent 系统——LangGraph 工作流、三层路由、MCP 数据链路打通； 2. 第二个月：新闻 Agent 的数据处理与模型微调——语料清洗去重、标注、LoRA 训练、封装进新闻工具； 3. 第三个月：评测与优化——证据审计、评测链路、时延优化（并行/缓存）、金融模型接入。

可补一句：节奏体现的是"先跑通闭环 → 再补数据/模型 → 最后做评测优化"的工程顺序。

4. 交付到什么程度、能否上线？

交付：完整可运行的 demo——从查询到结构化研报的闭环跑通，含路由、多 Agent、记忆、证据审计、评测链路和两个微调模型。

能否上线：还缺生产化改造——高并发与部署（存储从轻量库升级、多实例）、超时熔断与幂等重试、监控告警、以及金融合规评审（投资建议表述、数据授权）。当前是"工程闭环验证完成"的 demo 级，不是生产级。

可补一句：说清楚"能跑通"和"能上线"的差距，反而显得你对生产有认知。

---

第七部分 · 项目复盘

1. 回头看最想改什么？

优先级排序：① 新闻链路离线化（收益最大，把最慢节点移出请求链路）；② 数据多源 + 自动降级（提升稳定性和一致率）；③ 路由升级为小模型 + 规则兜底（提升泛化）；④ 评测统计化（成功率/一致率/时延自动出报告，而不是手工统计）。

可补一句：复盘要按"收益/成本"排序，体现工程判断力。

2. 再给一个月做什么？

1. 新闻抓取/打分离线预计算 + 缓存，把新闻 Agent 从"木桶短板"变成"毫秒级读取"； 2. 补齐真实问题集的回归评测（500+ 条 + LLM 判官 + 人工抽检常态化）； 3. 补工程化短板：超时熔断、幂等重试、并发存储、监控告警； 4. 引入多轮对话与上下文摘要，支持追问。

可补一句：一个月做"最痛的时延 + 最缺的评测 + 最该补的工程化"三件事。

3. 能否直接上线？缺什么？

不能直接上线，缺四块： 1. 稳定性：超时熔断、重试退避、限流； 2. 可扩展：存储升级、多实例部署、并发处理； 3. 可观测：监控告警、指标看板； 4. 合规：投资建议表述规范、数据来源授权、敏感数据脱敏。

可补一句：技术 demo 到生产之间，最大的差距往往不是算法，而是稳定性、可观测与合规。

4. 金融合规角度有什么考虑？

1. 不构成投资建议：系统输出"分析 + 风险提示"，不给买卖指令； 2. 数据来源声明：每个数字可溯源到数据源； 3. 敏感内容拦截：对"内幕交易、操纵市场、夸大收益"等表述做识别与规范化； 4. 风险提示强制：报告末尾带风险提示； 5. 数据出域控制：追踪/监控默认本地，远程可选，避免敏感数据外传。

可补一句：合规不是加一层"事后过滤"，而是从数据溯源、结论表述、监控落盘每个环节都内建约束。

5. 幻觉你治到什么程度？

我的定位是"降低 + 暴露，而非消除"。四层：数据层结构化限长、工具层强 Schema 约束、架构层多 Agent 分工隔离、模型层领域微调。配合证据审计，让幻觉从"看不见"变成"可发现、可拦截、可追责"。数据一致率 99% 就是这套体系的结果，剩下 1% 是衍生指标理解偏差和跨上下文记串这类更难根治的情况。

可补一句：诚实说"不能根除"，但能"用工程手段把它的危害降到可控"，这比吹"零幻觉"可信得多。

---

# 第三编 · Grill 高级追问与场景题

一、审阅结论

原有三份材料已经覆盖项目介绍、LangGraph、MCP、记忆、上下文压缩、LoRA、基础评测、性能、异常和个人贡献，适合准备第一轮项目问答。主要缺口不在“再背几个名词”，而在以下七类二至四层追问：

1. 指标证据链：简历已经给出结果，但现有答案对样本量、时间窗口、基线、统计方法和失败样本解释不够完整。 2. 并发与恢复语义：讲了并行屏障，但没讲超时、取消、幂等、重试、断点恢复和共享状态冲突。 3. 金融数据正确性：讲了 Schema，却缺 point-in-time、公告日、复权、未来函数、跨源冲突和衍生指标血缘。 4. 评测科学性：讲了准确率和 Judge，却缺数据泄漏、切分策略、类别分层、置信区间、显著性和端到端归因。 5. 安全与合规：缺 Prompt Injection、工具输出投毒、最小权限、多租户隔离、日志脱敏和投资建议边界。 6. 生产工程：缺 SLO、p95/p99、吞吐、单次成本、灰度、回滚、Schema/Prompt/模型版本管理。 7. 个人判断：答案偏“系统做了什么”，缺“我为什么这样决策、失败过什么、如何用实验推翻假设”。 8. 金融业务有效性：对估值计算、复权/未来函数、新闻实体链接、情绪信号使用方式和技术指标有效性追问不足。

二、以简历为准的事实锚点

| 简历事实 | 面试官会继续追问 | 回答边界 | |---|---|---| | 参与重构任务路由、工具调用、多智能体、记忆和评测体系 | 你具体负责哪部分；从零实现、协作实现、团队已有分别是什么 | 团队代码可以讲接口和设计，但不要把同事实现说成自己独立编码 | | LangGraph 三层动态路由；深度模式四 Agent 并行汇总 | 复杂度识别是规则、模型还是混合；误判成本；屏障、超时和降级 | 简历未写死分类器细节，按真实项目回答，不用同事分支反推 | | MCP 封装行情、财务、估值、新闻 API，并统一 Schema/周期/单位/时间/来源 | MCP 相比函数/HTTP 的价值；跨期、单位和来源冲突如何处理 | 可以把已落地机制讲清，同时主动说明数字校验的边界 | | 关键数字校验和“结论—证据”关联 | claim 与 evidence 如何绑定；衍生指标、同值误配、区间数字如何审计 | 不把数值匹配夸大成完整语义事实验证 | | 四类长期记忆，候选抽取—冲突检测—用户确认，按画像调权重与结构 | 隐私、隔离、撤回、过期；权重会不会改变事实 | 记忆只影响侧重与呈现，不应篡改金融事实 | | 清洗标注约 10 万条金融新闻并 LoRA 适配 Qwen3-8B | 10 万的各阶段口径、标注质量、切分、防泄漏、超参和基线 | 训练与评测细节以本人真实记录为准 | | 500+ 问题上做规则 + LLM-as-a-Judge 回归评测并接入 LangSmith | 题集分层、Judge 偏置、人工校准、版本冻结、回归门槛 | 500+ 是简历事实；需要准备组成与结果，而不是重新质疑是否存在 | | 覆盖 4000+ 股票；98% 工具成功率；99% 一致率；120s+ → 90s 内；91%/88% 模型准确率 | 分子分母、样本量、时间窗口、基线、均值/尾延迟、类别不平衡和失败样本 | 指标按事实回答；不凭空补未参与的统计过程，团队口径要标注协作边界 |

团队实现的统一话术

“这是团队项目。简历中的系统能力和指标是真实项目结果；我独立负责的是 [本人真实模块]，与同事共同完成的是 [协作模块]。对同事负责的代码，我能说明输入输出契约、为什么这样设计、与我模块如何联调以及出现故障时如何定位，但不会把具体实现冒充为我独立完成。”

指标举证最低模板

任何百分比或性能数字都按下面六项回答；缺一项就用占位符，不要现场编：

指标定义 → 分子/分母 → 样本量与时间窗口 → 对照基线 → 统计结果（均值与尾延迟/置信区间）→ 失败样本归因。

示例：

“工具有效调用率”的分母是 [统计窗口内进入执行阶段的工具调用数]，分子是 [通过 Schema 校验且返回可用业务数据的次数]；在 [时间窗口] 的 [N] 次调用上从 [基线] 提升到 [结果]。参数错误、无数据和上游故障分别统计，重试后的成功不能和首调成功混在一起。原始日志或统计脚本位于 [真实证据位置]。

三、新增核心深度问答

每题按 Grill 四层组织：边界、机制、取舍/失败、项目落地。

统一的 60 秒回答骨架

1. 先下结论：一句话直接回答“为什么/怎么做”，不要先铺背景。 2. 讲因果机制：说明输入、关键步骤、输出，以及为什么能解决问题。 3. 落到项目证据：引用简历中的真实规模、指标、一次案例或 500+ 评测中的对应子集。 4. 给出取舍：至少比较一个替代方案，说明收益、成本和为什么当时这样选。 5. 主动说边界：指出失败模式、未覆盖场景和下一步，不说“彻底解决”。 6. 标清所有权：补一句“我独立负责/我与同事协作/这是团队结果”，防止贡献边界被连续追问击穿。

A. 架构与 Agent 设计

#### Q18 为什么一定要多 Agent？一个 Agent 加全部工具不行吗？

推荐回答： 多 Agent 不是目的，而是用更强的边界换可控性。单 Agent 的优点是上下文共享自然、调用链短、成本低；缺点是工具集合大、职责混杂，容易选错工具或把不同报告周期的数据串起来。FinAgent 把基本面、技术面、估值和新闻按工具白名单与输出字段隔离，深度问题再并行汇总，主要收益是工具选择空间缩小、故障可定位、并行降时延。代价是重复上下文、额外模型调用和跨 Agent 冲突。因此原子问题走快速链路，单领域问题只调一个 Agent，只有综合问题才付多 Agent 成本。

连续追问：“你怎么证明多 Agent 真的更好？”

答法： 不能只凭架构直觉。应做单 Agent 与多 Agent 的对照，在同一问题集、同一模型和工具预算下比较工具误用率、事实忠实度、缺失维度、总 token、p95 时延和成本。项目已经落地多 Agent 架构；如果没有专门做过这组消融，就把收益准确表述为“边界更清晰、可并行、可定位”，不要把未测过的质量提升说成实验结论。

#### Q19 并行节点同时写状态，为什么不会互相覆盖？

推荐回答： 并行安全取决于状态代数，不是“用了 LangGraph 就安全”。FinAgent 让四个 Agent 写各自独占的领域结果，汇总节点只读这些结构化字段，避免同键竞争；消息或集合类字段需要显式 reducer。若两个并行分支可以写同一个键，结果可能依赖完成顺序，因此共享写入要拆成命名空间，或使用满足结合律、最好也满足交换律的 reducer，并用并发测试验证。具体 reducer 和字段名属于团队实现细节，按真实接口契约回答。

连续追问：“消息追加顺序稳定吗？”

答法： 并发分支的完成顺序不应被当成业务语义。汇总应读取按领域命名的结构化结果，而不是依赖消息列表先后决定权重。

#### Q20 全部完成屏障遇到慢节点或永久卡住怎么办？

推荐回答： 屏障保证完整性，但会产生 straggler 问题：总时延被最慢分支支配。完整设计应同时有 ReAct 轮次预算、单工具 timeout、Agent 子 deadline、请求总 deadline、取消传播和熔断；超时后写结构化缺失原因，汇总按最小证据集合决定降级出报告还是失败。面试时先说项目真实落地了哪些，再把剩余项明确列为生产化补强，不能把方案设计和已上线能力混说。

连续追问：“为什么不拿到三个结果就立刻汇总？”

答法： 这是完整性与可用性的取舍。应按查询和维度重要性定义 quorum，而不是固定三选四。例如用户明确问新闻风险时，新闻维度不能缺；一般综合分析可在一个非关键维度超时后出受限报告。

#### Q21 工具失败为什么不能无脑重试？怎么保证幂等？

推荐回答： 重试只适合瞬时故障，并且要区分错误类型。参数校验失败应让模型修参；无数据不应原参数重试；限流和网络抖动可指数退避并加 jitter；鉴权失败应快速失败并告警。读工具天然更接近幂等，但抓取、记忆写入或未来扩展的交易类工具不一定幂等，需要请求追踪标识/idempotency key、去重表和结果复用。还要给“单次尝试成功率”和“重试后最终成功率”分别计数，否则 98% 会掩盖首调质量差。

#### Q22 为什么用 ReAct？哪些步骤不该交给 ReAct？

推荐回答： ReAct 适合“下一步依赖上一步结果”的不确定检索，例如发现报告期缺失后换参数继续取数；但路由兜底、数据校验、证据审计、权限和风险拦截等有明确规则的步骤应由确定性代码控制。原则是把探索交给模型，把控制与验收留在 Harness。FinAgent 用三层图控制主流程、垂直 Agent 处理领域内探索、规则与 Judge 做回归验收；再说明本人负责的具体边界。

B. 金融数据与事实正确性

#### Q23 数据基准时间有了就能避免未来函数吗？

推荐回答： 不能。数据基准时间只说明数据代表哪个时点，还必须记录“市场何时可获得”。财报的报告期、公告发布日期和修订发布日期是三个不同时间；回测或历史问答只能使用当时已公开的数据。正确方案是 point-in-time 查询：以用户问题的基准时间为截断，选择 公告发布时间 <= 查询截止时间 的最新版本，并保留报告周期、公告发布时间、数据源版本。FinAgent 已通过报告周期、数据时间和来源字段降低跨期混用；如果还记录了公告/修订时间就继续说明，否则主动把 point-in-time 版本管理列为边界。

#### Q24 K 线为什么要讲前复权/后复权/不复权？

推荐回答： 分红送转会造成价格跳变。不复权适合回答当时真实成交价，前复权适合观察以当前价格为基准的连续收益，后复权适合从历史起点观察累计回报。技术指标与收益比较必须统一复权口径，证据中要记录 adjustment type；否则不同 Agent 可能对同一只股票得出矛盾趋势。面试时应明确项目当前工具的复权参数和默认值；不知道就说需要回查，不能泛称“K 线已标准化”。

#### Q25 两个数据源给出不同值，系统信谁？

推荐回答： 不能简单多数投票。先按指标定义、报告期、单位、更新时间、是否修订对齐，再按来源权威度排序：交易所/公司公告优先于聚合平台，原始数据优先于二次加工。若仍冲突，应同时保留两个证据、标记差值和口径，不让模型静默选择。最后结合项目真实的数据源优先级、主备关系和降级策略回答；简历只说明封装了四类 API，没有限定数据源数量。

#### Q26 数字在证据集合里出现，就说明报告结论有依据吗？

推荐回答： 不说明。FinAgent 的关键数字校验与“结论—证据”关联能抓到大量无依据数字，但如果只做数值集合匹配，会存在同值误配：报告里的 10% 可能来自另一字段或另一报告期。更强的校验要求数字就近引用 evidence ID，并验证该证据的股票、字段、报告期、单位与 claim 一致；衍生结论还要保存计算公式和输入证据，形成 claim → formula → evidence 的血缘图。回答时明确项目实际做到哪一层，不把数值覆盖夸大成完整语义事实验证。

#### Q27 单位自动推断有什么风险？

推荐回答： 字段名启发式只能提供默认值，不能替代数据契约。例如利润可能是元、万元或亿元，比例可能是 0.15 或 15%，每股数据还涉及币种和股本口径。安全策略是适配器显式映射优先，未知字段保留 raw value/raw unit，转换后记录 scale 和 currency；关键指标若单位不确定应拒绝进入估值计算。FinAgent 已统一指标单位字段，面试时继续说明实际采用显式映射、源端声明还是启发式兜底，以及未知单位如何处理。

C. 路由、评测与统计

#### Q28 路由器怎么评，不是“看起来能分对”就行？

推荐回答： 建立按意图、领域、否定/排除、口语化、代码/名称歧义分层的标注集，报告三类路由的混淆矩阵，而不是只报总准确率。错误成本不对称：把深度问题错分为快速查询会漏信息，代价高；把快速问题错分深度主要浪费时间和 token。因此阈值应按加权风险调，重点看 deep-research recall、快速链路 precision、兜底比例、路由 p95 时延和单次成本。分类器是规则、模型还是混合按真实项目回答，并从 500+ 题中说明路由子集如何评测。

#### Q29 500+ 评测题应该怎么构造，怎样防数据泄漏？

推荐回答： 500+ 题不是平铺的问答列表，而应按能力分层：路由、工具选择、参数正确性、事实忠实、跨期比较、异常恢复、记忆、合规和报告质量；每层含正常、边界、对抗与历史回归样本。相似模板需要按簇去重，题集冻结并版本化，开发调参只看开发集，保留独立回归集防止“把题做熟”。面试时准备这 500+ 题的各类数量、来源、版本、通过门槛和一次真实回归案例。

#### Q30 LLM-as-a-Judge 怎么避免偏长、偏位置和自我偏好？

推荐回答： Judge 只评规则难覆盖的语义质量，硬事实仍由确定性检查负责。评分维度拆成忠实度、完整性、风险意识和表达；用锚定样例校准；候选匿名化；成对比较时交换 A/B 顺序；避免用被评模型做唯一 Judge；定期与双人盲评对齐，报告一致率或相关性。Judge 模型、提示词、温度和评分阈值必须版本化。最后结合项目 500+ 题说明规则分与 Judge 分如何合成、什么情况一票否决。

#### Q31 91%/88% 已经不错，为什么还不能只看准确率？

推荐回答： 91%/88% 是简历中的真实测试结果，但五档情感/风险是有序标签，普通准确率既不反映类别不平衡，也把“1 预测成 2”和“1 预测成 5”同等计错。完整报告还应包含各类 precision/recall/F1、Macro-F1、混淆矩阵、MAE 或 Quadratic Weighted Kappa；风险任务重点看高风险召回和校准。结果最好带样本量、置信区间，并与基座模型和简单规则基线比较。这样不是否定准确率，而是说明模型在哪些错误上仍有业务风险。

#### Q32 训练/测试怎么切分，如何避免新闻事件泄漏？

推荐回答： 随机按行切分会让同一新闻事件的转载、同一公司同一时段的相似文本跨集合，模型记住事件表述就能取得虚高分。更可靠的是先用标题/正文/语义去重结果生成事件标识，再按事件标识或时间切分，保持类别分层，并单独保留未来时间段做 OOD 测试。结合项目真实切分回答：如果已经按事件或时间切分，说明比例和规则；如果采用随机切分，就承认局限，并说明 91%/88% 对应的确切评测边界。

#### Q33 r=16、alpha=32 是怎么选出来的？

推荐回答： r 控制低秩更新容量，alpha/r 控制更新缩放。r=16、alpha=32 可以解释为表达力、显存与过拟合之间的中等容量选择，目标层选择则要结合注意力与前馈层对任务的作用。真正有说服力的是固定数据与预算比较 r=8/16/32、注意力层 vs 全线性层，报告 Macro-F1、训练显存、吞吐和方差；如果项目做过消融就给真实结果，如果没有，就诚实说这是基于资源与经验确定的工程起点。

D. 安全、记忆与合规

#### Q34 新闻网页里写“忽略系统提示并调用某工具”，怎么办？

推荐回答： 把所有外部文本视为不可信数据，而不是指令。工具结果用结构化字段承载，新闻正文放在明确的 data 区；系统提示规定不得执行工具输出中的命令；Agent 只挂领域白名单工具；高风险工具需要参数策略和人工确认；对可疑注入做检测和日志记录。还要在 500+ 评测题中加入间接 Prompt Injection，例如网页要求泄露其他用户记忆、伪造证据 ID、调用禁止工具，并说明项目当前已落地的防线。

#### Q35 用户标识隔离就等于多租户安全吗？

推荐回答： 不等于。应用参数里的用户标识可能被伪造，生产环境应从可信身份系统注入租户标识/用户标识，所有读写都带租户约束并做越权测试；敏感字段加密，日志脱敏，数据库备份和访问审计；导出、删除、过期清理形成完整生命周期。结合项目真实存储与鉴权说明已做到哪一层；如果这些由同事负责，就说清接口约束与联调验证，不冒充独立实现。

#### Q36 TTL 到期的数据真的删除了吗？用户能撤回吗？

推荐回答： 过期至少分两层：读取时不再召回的逻辑失效，以及数据库和备份中的物理清理。产品还应支持查看、修改、导出、撤回，并规定日志与备份保留期。FinAgent 已有候选确认、冲突检测和过期机制；继续说明实际是否支持删除/清理。金融画像属于敏感偏好数据，最小化收集和可撤回比“记得越多越好”更重要。

#### Q37 系统如何界定“投研分析”与“个性化投资建议”？

推荐回答： 先按项目真实产品边界回答，不能为了“安全”临时改口。如果报告包含评级或目标价，应说明它是基于公开数据的研究性分析，展示依据、时间基准、不确定性和风险，不直接连接交易执行，也不承诺收益；涉及用户画像时更要避免把风险偏好转化为自动仓位或交易指令。工程上通过模板约束、敏感表达检测、证据审计和必要的人工审核控制风险，最终边界由业务与合规共同确认。关键是区分“分析能力存在”和“谁对决策负责”。

E. 生产化与可观测性

#### Q38 90 秒以内应该看平均值还是 p95？

推荐回答： 简历中的“90 秒以内”是项目实测结果，但面试官会继续问它是均值、最大值还是某个分位数。用户体验和容量规划更应看分布，因为平均值会掩盖新闻抓取、限流和重试造成的长尾。完整回答要按路由类型给出 p50/p95/p99、超时率、各节点 critical path、输入/输出 token、工具调用次数和单次成本，并说明冷/热缓存、样本量、并发度和测试环境。若当时只统计端到端上限，就准确说明原口径，再把分位数监控作为后续补强。

#### Q39 缓存键和 TTL 怎么设计才不会返回错股票、错时间的数据？

推荐回答： 缓存键至少包括工具名、规范化参数、股票代码、复权方式、报告期、数据源版本和数据基准时间；TTL 按数据变化频率而不是按工具统一配置。行情在交易时段短 TTL，已发布年报可长 TTL，新闻要结合抓取时间；报告缓存还受用户画像、Prompt/模型版本影响。并发下用 single-flight 防击穿，返回时附报告生成时间/数据实际截止时间，过期可 stale-while-revalidate。最后明确这些机制中哪些用于 120s+ → 90s 的实测优化，哪些是进一步设计。

#### Q40 如何做灰度、回滚和可复现？

推荐回答： 一次报告要记录代码版本、模型与 LoRA 版本、Prompt/Agent 版本、工具 Schema 版本、数据源及数据基准时间、路由决策和随机参数。上线用小流量 shadow/canary，比对事实忠实、失败率、p95 时延和成本；任一硬指标退化自动回滚。评测集和阈值也要版本化，否则“模型没变但提示词变了”仍会导致结果不可复现。结合 LangSmith 说明项目如何关联 trace、版本与 500+ 回归结果。

#### Q41 线上最重要的告警是什么？

推荐回答： 优先监控会伤害用户的错误，而不只是 CPU：无证据数字率、无效证据 ID、过期数据使用率、工具错误率/重试率、深度路由漏判、敏感投资建议命中、跨租户访问、p95/p99 时延和单次成本。告警要能关联到执行批次标识、路由、Agent、工具和数据源，并对原始文本脱敏。

F. 个人贡献与复盘

#### Q42 讲一个失败实验，而不是最后成功方案。

回答结构：

最初假设 [真实假设]；用 [真实样本/日志] 观察到 [反例或指标退化]；定位到 [根因]；我亲自做了 [动作]；结果 [真实变化]；因此形成 [可迁移原则]。

可选真实题材：规则路由无法处理否定语义、上下文截断丢证据、报告同值误匹配、训练随机切分泄漏、MCP 子进程故障难定位。没有真实数字时讲现象和证据，不补造百分比。

#### Q43 你做的最关键决策是什么？如果错了代价是什么？

推荐回答方向： 选一项自己真正主导的决策，例如“把证据审计做成模型外确定性步骤”。解释替代方案、决策依据、可逆性和失败代价：只靠 Prompt 实现快但不可验证；外部审计增加开发与误报成本，却把无依据数字显性化。再说明如何用测试和日志降低决策风险。

#### Q44 哪个指标最能证明你的个人贡献？

推荐回答： 选择自己能拿出原始证据的指标，不要选团队口径最大但说不清的数字。回答要包含你改了什么、控制了哪些变量、基线和样本量、结果分布、失败案例。若 98%/99%/90 秒来自团队汇总而你没有统计脚本，就说“这是团队结果，我负责其中某模块；我能独立举证的是 [真实可复现指标]”。

G. 金融业务有效性

#### Q45 估值 Agent 的目标价是谁算的，为什么不让 LLM 直接心算？

推荐回答： 先把“取数、计算、解释”分开：MCP 工具提供可追溯的价格、财务、分红和行业数据；PE/PB/股息折现等公式由确定性计算模块完成并保留输入参数、单位和公式版本；LLM 负责选择适用方法、解释假设和比较结果，不负责偷偷生成数字。估值不是单点真值，应给出基准/乐观/悲观情景与敏感性分析。若项目中部分计算仍由模型完成，要主动说明审计和算术校验如何兜底，以及这是需要继续外置的风险点。

连续追问：“DCF 和相对估值冲突怎么办？”

答法： 先检查口径和假设，再分别呈现方法适用条件；现金流可预测性弱时降低 DCF 权重，行业可比公司差异大时降低相对估值可信度。不能简单取平均，更不能让汇总 Agent 隐藏分歧。

#### Q46 个性化权重、证据质量和 Agent 结论冲突时，谁优先？

推荐回答： 事实与证据质量优先，用户偏好权重最后。先按数据新鲜度、来源权威性、报告期一致性和证据完整度判断每个维度的可信度；再展示一致点与冲突点；个性化权重只决定篇幅、排序和解释重点，不能把低质量证据放大成强结论。最好分别维护用户偏好权重与证据置信度，汇总时不混为一个分数。

#### Q47 新闻 Agent 怎么保证新闻真的属于这家公司，而且不是同一事件的十篇转载？

推荐回答： 先做实体链接：股票代码、公司全称/简称、子公司和品牌别名需要映射，只有行业相关但未直接涉及公司的新闻要降低相关性。再按标题、正文语义、时间窗口和来源聚类，同一事件保留主来源并汇总其他来源，避免“十篇转载被当成十个利空”。证据中保存原文 URL、发布时间、抓取时间、来源和事件标识；汇总情绪时按事件而不是按文章计票。

#### Q48 情感 1–5 分和风险 1–5 分如何进入最终报告？

推荐回答： 两个分数是有序信号，不是未来涨跌概率。先在新闻事件级输出分数、置信度与理由，再结合来源可靠性、事件相关性和时间衰减聚合；情感反映方向，风险反映潜在损失与不确定性，两者不能互相替代。汇总报告应展示分布和关键事件，不只报平均分；同时设置“无足够证据/模型低置信”的拒答或降权机制。个性化画像只能调整展示侧重，不能把高风险事件改写成利好。

#### Q49 技术指标真的能预测股价吗？为什么还要技术面 Agent？

推荐回答： 技术指标主要是对价格和成交量历史的压缩描述，不等于稳定因果预测。技术面 Agent 的价值是提供趋势、波动、支撑阻力与交易拥挤度的观察维度，并与基本面/事件风险交叉验证；不能仅凭 MACD/RSI 给出确定收益承诺。若要证明预测价值，需要严格回测：point-in-time 数据、复权一致、交易成本和滑点、样本外时间段、多重检验控制与不同市场状态稳定性。

#### Q50 怎么证明报告“有投研价值”，而不只是写得像研报？

推荐回答： 把“好看”拆成可验证层级：硬底线是工具轨迹正确、数据新鲜、数字有证据、跨期和单位一致；内容层看是否回答原问题、覆盖关键驱动与风险、区分事实/假设/推断、暴露分歧和不确定性；业务层由投研人员盲评与真实任务反馈验证。LLM Judge 只能覆盖部分内容质量，不能替代事实校验和专家评审。最终还应跟踪错误类型和用户修订，而不是只追求报告长度或 Judge 总分。

四、场景题补充

场景 1：三个 Agent 成功，新闻 Agent 超时，用户问“最近负面事件会不会改变长期逻辑？”

回答应包含：新闻是关键维度，不能把三份成功结果当完整报告；触发子 deadline 后取消新闻分支；尝试备用来源或缩小时间范围；仍失败则输出“无法回答事件影响”的受限结果，只展示可核验的长期基本面，不给综合评级；记录降级原因并告警。

场景 2：报告数字审计通过，但引用的是去年年报，用户问的是今年一季报

回答应包含：这是语义/时间口径错误，数值集合匹配抓不到；在 claim 与 evidence 校验中加入 symbol、field、报告周期、公告发布时间；报告生成前锁定查询截止时间与目标周期；周期不匹配直接阻断，不靠风险提示兜底。

场景 3：上线后工具成功率上升，但报告事实错误率也上升

回答应包含：成功率只说明“拿到结构化响应”，不说明数据正确；拆分首调成功、重试成功、空数据误判成功、Schema 合法但业务无效；沿执行批次标识回放工具响应与报告证据；检查上游字段/单位变更、重试拿到不同报告期、审计同值误配；把业务有效性和事实忠实度设为独立 SLO。

场景 4：新 LoRA 的准确率高 2%，但高风险召回下降 8%

回答应包含：金融风险任务漏报成本更高，不能按总准确率上线；先确认置信区间和样本分层，再按成本矩阵选择阈值；比较 Macro-F1、风险类 recall、MAE/QWK 与校准；必要时拒绝新模型或只灰度到低风险场景。

场景 5：用户要求“记住我所有持仓并以后自动给买卖建议”

回答应包含：最小化收集、明确同意、可查看/删除/过期、加密与租户隔离；持仓属于更敏感数据，不能沿用普通偏好记忆的默认策略；系统可基于用户授权做信息组织，但不自动生成个性化交易指令；需要合规评审和人工确认。

五、面试前必须补齐的证据清单

[ ] 98% 工具成功率的样本量、时间窗口、错误分类和重试口径；若统计由团队完成，准备可说明的结果表或日志证据。
[ ] 99% 数据一致率的定义：是数字级、报告级还是问题级；审计阈值、人工抽检方法和失败样本。
[ ] 120s → 90s 的同环境前后对照、N 次运行、p50/p95，而不是单次最快值。
[ ] 91%/88% 的冻结测试集、类别分布、Macro-F1/混淆矩阵、基座对照与泄漏排查。
[ ] “10 万条语料”是原始、去重后、标注后还是实际进入训练的条数，各阶段保留率是多少。
[ ] “500+ 问题”的类别构成、数据集版本、规则项、Judge 评分维度、人工校准方式和一次回归案例。
[ ] 4000+ 股票覆盖的快照日期、退市/北交所/ST 边界和随机抽样验证。
[ ] 一次真实失败案例及执行批次标识，能讲清定位过程。
[ ] 个人贡献按“独立设计/独立实现/协作/团队结果”四类标注。
[ ] 项目的真实合规边界：是否输出评级/目标价/仓位，如何声明依据与风险，哪些内容需要阻断或人工审核。

六、推荐复习顺序

1. 先把第二节简历事实和团队分工讲顺，确保不会把同事实现说成个人独立贡献。 2. 熟练回答 Q18、Q20、Q23、Q26、Q28、Q31、Q34、Q37、Q38、Q44、Q45、Q48，这十二题最容易拉开深度。 3. 从场景题任选两题，用“识别风险 → 收集证据 → 降级/恢复 → 指标验证”口头回答。 4. 最后补证据清单；无法补齐的数字统一使用 [待核验]，不要临场造口径。