题1：请用”业务痛点→初版方案→踩坑迭代→量化收益”介绍项目#

参考回答（面试口语化——四步公式，决定性题目）：

这道题是面试中的”第一印象题”，决定了面试官对你这整个人的判断基调。

推荐用 四步公式 来讲：

第一步：业务痛点（说清楚”为什么要做”）

“我们的场景是批量学科竞赛赛题的自动解答——大概 100 道题，每道题包含题目文本和可能配图，需要 Agent 去搜索资料、理解题目、推理给出答案。传统做法让研究生助教每人领十几道题手动搜资料、整理答案，100 道题下来要 3-4 个同学轮一周，质量因人而异、格式参差不齐，后期还要人工对齐。所以我们就想——能不能用 Agent 自动化这个流程，把人从重复的搜索-整理劳动里解放出来。”

第二步：初版方案（怎么做的，但不要只讲”用了什么”）

“第一版我们搭建了一个 Research Agent 基座——定义了 Web 搜索、网页解析、PDF 解析三个核心工具，用 ReAct 范式驱动，LLM 用当时最稳定的 GPT-4o。工作流是：收到题目→拆解搜索关键词→多路搜索→解析返回结果→综合推理给出答案。一开始拿 10 道简单题跑 POC 效果还行，答案质量跟人工差不多。但一放大到 100 道全量题跑，问题全暴露了——跑着跑着就卡死、挂了、或者搜偏了不回头。”

第三步：踩坑迭代（关键！展示你遇到过真实问题）

“全量跑第一次上线就翻车了——跑了大概 3 小时，Agent 在某道题上陷入无限搜索循环，上下文直接撑爆。我们排查后发现核心问题有四个：

① 长时运行崩溃：每道题 10 分钟预算，100 道题就是 1000 分钟连续跑。Agent 要跑十几个小时，期间随便一个网络抖动、API 限流、进程 OOM，整个任务就全废了——前面跑了 90 多道全白费，得从头再来。

② 搜偏了不会回头：Agent 连续 3-4 次搜索找不到正确信息，但它不会停下来，会一直搜一直搜，浪费时间和 token，而且越搜越偏。

③ 结果格式不稳定：明明答对了知识点，但因为输出多了个编号前缀或者少了 Markdown 符号，判分程序直接判错。

④ 出了问题没法排查：跑崩了只看得到一行 ‘TimeoutError’，根本不知道是在哪道题、第几步、因为什么崩的。

针对这些问题我们做了四轮迭代：

• 第一轮：逐题落盘 + 断点续跑——每道题做完立即 append + flush + fsync 写入文件，不攒批写。同时维护进度文件，崩了用 --resume 直接从断点继续跑，不重头再来。这是最关键的优化——它把’要么全有要么全无’变成了’做一题是一题’。
• 第二轮：超时控制 + 有限重试 + 退避策略——单题硬限制 10 分钟，超时直接中断进下一题。网络错误（429/5xx）最多重试 2 次（Max Retries=2），两次之间指数退避。连续 3 次搜索无效时自动停止搜索，转用已有证据作答。
• 第三轮：答案格式清洗 + 验证——Agent 原始输出先过清洗层（去掉 ‘Answer:’ 前缀、多余 Markdown 符号、无关叙述），然后用 verify_answer() 做格式校验，不合规的直接要求重新生成。
• 第四轮：日志复盘体系——每道题跑完记录状态（ok/empty/timeout/error），写入 batch_run.log。跑完后一键统计，哪些题正常、哪些超时、哪些出错，一目了然。错题可以马上复盘翻日志。”

第四步：量化收益（必须有数据！）

“最终 100 道题全量跑完，完成率从最初的 52% 提升到 89%——29 道完全正确、46 道有内容但部分扣分、15 道部分完成、4 道超时、6 道出错。效率对比：之前 3-4 人干一周的活，现在 1 个 Agent 跑一晚上（12-16 小时）就出来了。每道题都有完整的搜索-推理-答案链路日志，结果可审计、可复现。每一次稳定性提升都是针对真实线上问题做的——断点续跑解决了’跑崩全废’，重试和退避解决了’网络波动中断’，搜索纠偏解决了’搜偏不回头’，日志复盘解决了’出问题无法排查’。”

高分关键：踩坑迭代环节要有真实感——不要说”遇到了一些问题”，要说”遇到了 XX 具体问题，我们走了 XX 弯路，最终用 XX 方式解决”。

题2：你这个项目到底在解决什么问题？#

参考回答（面试口语化——区分”toy project”和”真实工程”的关键）：

这个问题比题1更聚焦——它要求你用一句话说清楚项目的核心价值。

好的回答是这样的：

“这个项目解决的是长时稳定运行的 Agent 系统在批量评测场景下的工程可靠性问题——怎么让一个 Agent 在连续跑十几个小时、处理 100 道不同类型的题目的过程中，不崩、不跑偏、出了问题能恢复、恢复后能继续。”

为什么这个回答好？因为它点出了本质矛盾，而不是描述功能：

• ❌ 错误示范：“我做了个 Research Agent，它能自动搜题答题”
• ✅ 正确示范：“我做的 Research Agent 解决的是 Agent 从’能回答一个问题’到’能稳定完成一整批任务’的关键跃迁——关键在于工程护栏，而不只是调 Prompt”

面试官想听到的三层：

1. 这个场景有什么痛点？（长时运行会崩 / 搜偏不回头 / 崩了全白跑 / 结果格式不一致）
2. 痛点背后的本质矛盾？（AI 的单次准确率 vs 批量场景下的系统可靠性——一个 Agent 答对一道题不难，难的是 100 道题全流程不出问题）
3. 你的方案怎么解了这个矛盾？（用逐题落盘、断点续跑、有限重试、搜索纠偏、格式校验、日志复盘——把 Agent 运行从”黑盒实验”变成”可观测、可恢复、可诊断的工程系统”）

加分技巧：说出来后补一个”如果没有这个方案会怎样”的反例——“如果没有这些工程护栏，我们第一次全量跑的 100 道题，跑到第 43 道时 Agent 就陷入死循环了——前面 42 道的结果全丢，要从头再来。你想想一晚上白跑的感觉。”

题3：为什么这里要做成 Agent？不是直接用现成方案？#

参考回答（面试口语化——校招生最怕的追问，答案要有深度）：

这个问题是面试官在判断：你是为了用 Agent 而用 Agent，还是真的需要 Agent。

回答核心思路：区分”Agent 能做的”和”非 Agent 不可的”

“其实我们第一版想过用轻量方案——最简单的方式就是直接拿 GPT-4o 问答，或者用 Bing 搜索 API 搜到结果后人工拼答案。但跑了几道题后就发现这几种方式都不行：

为什么直接问 LLM 不够？ 竞赛赛题往往涉及最新技术、专有概念或冷门知识点，LLM 的训练数据里没有。直接问 GPT-4o，它会自信地给你一个看起来合理但全是幻觉的答案。我们测试过——纯 LLM 回答正确率不到 30%。必须结合实时搜索。

为什么用 Bing API + 脚本不行？ 因为搜索—解析—推理这个链路里有太多不确定性：搜出来的页面有些是广告、有些是论坛、有些是 PDF。你需要判断哪个页面可信、从页面里提取哪段信息、如果第一个搜索结果不相关要不要换关键词重搜——这些东西写脚本写死，遇到 100 道题 10 种不同题型就会疯狂 if-else 膨胀，根本维护不了。

为什么 Workflow 编排也搞不定？ Workflow 能处理固定路径——比如”搜索→取第一个结果→解析→输出”。但真实的 Research 流程天然带分支：第一个搜索结果质量低，需要退回重选关键词再搜；搜到了 PDF 需要调用 PDF 解析器而不是普通网页解析器；多源信息矛盾时需要交叉验证决定信谁。Workflow 没有这种动态回退和分支决策能力。

那为什么是 Agent 不是人？ 因为 100 道题让研究生助教来干，3-4 个人轮一周，每道题都要人工搜索、阅读、整理、格式化。而且人也有疲劳——搜到第 50 题的时候搜索质量明显下降。Agent 可以保持一致的搜索策略、每步都打日志、结果完全可审计。做完 100 题还能告诉你哪几题搜得吃力、哪几题搜索路径最优。”

一句话总结：

“用 Agent 是因为 Research 本质上是一个多步搜索→动态推理→反复验证的非确定性流程——脚本写死不可行、Workflow 编不出来、纯 LLM 幻觉严重、人做太慢且不可审计。Agent 是唯一能在动态决策和自动化之间取得平衡的方案。”

加分关键：不要说”用 Agent 更酷”——要具体说”为什么直接问 GPT 不行、为什么脚本控制不了、为什么 Workflow 编不出”——让面试官感受到你是真的被痛点逼到用 Agent 的，不是跟风。

题4：自己做 Research Agent 的动机？和 Perplexity / GPT-4o with Search 比差异？#

参考回答（面试口语化——字节高频题）：

动机：现有的 AI 搜索和研究工具（Perplexity、GPT-4o with Search、Gemini with Search）是通用方案，它们的设计目标是”快速回答通用问题”。但竞赛赛题这个场景有特殊性——每道题 10 分钟预算、需要多轮搜索交叉验证、需要处理 PDF 配图、结果格式要严格对齐评分标准。通用工具做不到这些，所以我们要自己做一个面向长时批量评测场景的专用 Research Agent。

和通用方案的核心差异：

1. 批量运行能力不同：Perplexity 是一次性对话，做完一道题就结束了。我们的 Agent 要连跑 100 道题、1000 分钟不间断，支持断点续跑、超时跳过、失败重试——这是 Perplexity 绝对做不到的，因为它没被设计成”批处理系统”。

2. 搜索策略深度不同：GPT-4o with Search 做一锤子搜索——搜一次，取结果，回答。我们的 Agent 遇到信息不充分时会自动换关键词重搜，连续无效搜索 3 次会停止搜索改用已有证据作答。这种搜索偏航纠偏机制让 Agent 知道”什么时候该放弃搜索，而不是死循环搜下去”。

3. 多源信息处理不同：通用方案主要处理网页文本。我们的 Agent 有 PDF 解析补盲——当搜索结果指向 PDF 而不是 HTML 页面时，自动切换 PDF 解析器提取内容。这个看起来小但在竞赛场景里极其重要——很多赛题参考文档就是 PDF。

4. 结果工程约束不同：通用方案输出自然语言回答。我们的 Agent 输出要过格式清洗（去前缀、去多余 Markdown）和 verify_answer 格式校验——因为评分程序不认”答对了但格式错了”的答案。这一点在工程落地上比通用方案苛刻得多。

5. 成本与 Token 预算不同：通用方案不限制对话轮次和 token 消耗。我们的 Agent 每道题有硬性的 10 分钟时间预算和隐性的 token 预算——超了就中断进下一题。这个预算控制机制是批量场景的刚需。

面试加分关键：不是要踩 Perplexity 不好，而是要说”Perplexity 很好，但它解决的是’用户问一个问题’的场景，我解决的是’批量处理 100 个问题、跑一晚不出事’的场景”——体现你对不同场景下系统设计取舍的理解。

题5：你怎么看待 AI 工具？如何把握自己的能力和边界？#

参考回答（面试口语化——滴滴/多家中小厂常问）：

我的视角分两个层面：

正面：AI 极大地提升了开发效率——开发 Research Agent 那段时间，LLM 帮我快速生成了很多爬虫代码、网页解析器、结果格式清洗函数。原来手写一个 Trafilatura 调优要半天，现在 Prompt 一轮就能拿到能用的脚手架。这不是”替代开发者”，而是”让开发者从重复的 boilerplate 中解放出来”。

但我要说清楚自己的边界：

1. AI 生成的核心护栏逻辑我必 review，不盲信——比如 Research Agent 的断点续跑机制、逐题落盘策略、搜索偏航纠偏逻辑，这些代码我都逐行读、逐路径测试。AI 生成的”看起来对的代码”在边界场景可能遗漏——比如 append+flush+fsync 的落盘顺序错了会导致结果丢失
2. 架构设计我做，AI 是辅助建议——比如”是用单线程串行跑还是异步并行""重试策略用指数退避还是固定间隔""日志用 text 还是 json 格式”，这些依赖工程经验和对场景的理解，AI 给的建议我会参考但需要自己验证
3. 我了解 AI 的幻觉边界——让 AI 生成搜索关键词策略时，它经常推荐”看起来专业但是搜不到结果”的关键词。所以我们后来加了关键词验证环节——搜索返回 0 结果就自动换关键词

我的原则：AI 是加速器，不是方向盘。让 AI 加速工程实现，但关键的系统设计决策和安全边界必须自己把控。面试官问这个问题，其实是在看候选人有没有 AI 依赖症——你能不能区分”AI 帮你省时间”和”AI 替你做决定”。

加分回答：加一个自己的实践——“在 Research Agent 项目里我有两套代码从来不交给 AI 写：一套是落盘逻辑，一套是重试策略。因为这两块出问题就是无声的、跑一晚上才发现——等发现的时候已经全白干了。这种’无声的错误’比代码写不出来更可怕。“

题6：AI 工具出现后，对传统研发工作流造成了什么冲击？#

参考回答（面试口语化——考察深度思考）：

冲击是全方位的，我概括成四个层面：

① 开发效率的提升：以前做一个自动化的 Research Agent，从设计→编码→调试→上线，每个环节都是串行的。现在有了 LLM，编码和调试可以大幅度提速——原来需要花几天写的网页解析器、搜索关键词生成器、结果清洗函数，现在半天就能迭代出原型。流程的瓶颈从”写代码太慢”变成了”系统设计的周全性不够”。

② 工程稳定性的定义在变化：以前软件质量主要看功能正确性、性能、可维护性。现在基于 LLM 的系统的质量不只看这些——还看”它在长时运行中会不会崩""它搜偏了能不能自行纠正""它出错了日志够不够复盘”。Research Agent 从 52% 完成率优化到 89% 的过程让我深刻体会到：LLM 系统的”质量”很大程度取决于工程护栏的设计，而不只是模型本身的能力。

③ 开发者的角色在进化：开发者不再只是”写代码的人”，更是”为 AI 设计工作流和安全边界的人”。你做 Agent 不是写一个程序，而是写一个能让 Agent 稳定运行的框架——逐题落盘、断点续跑、超时控制、重试策略、搜索纠偏……这些东西都是开发者为 Agent 搭建的”赛后跑道”，保证 Agent 跑偏了还能拉回来。这其实提高了对开发者”系统设计能力”的要求。

④ 可观测性变复杂了：传统软件出问题有明确的 stack trace。LLM 系统出问题——是模型问题？工具调用问题？搜索质量问题？还是 Prompt 问题？没有好日志根本查不出来。我们在 Research Agent 里加的 batch_run.log 和每题的 ok/empty/timeout/error 状态统计，就是为了让”出问题能定位到具体是哪道题、哪一步、因为什么”。

我的核心观点：AI 工具不是在”取代”开发者，而是在”筛选”开发者——能驾驭 AI 做系统性工程的人越来越强，只能写简单 CRUD 的人慢慢被边缘化。

加分回答关键：不要只说宏观变化，加一个自己工作中的实际体会——“我的 Research Agent 跑崩后复盘日志显示，90% 的失败不是因为 LLM 答不对，而是因为网络超时和搜索不收敛——这让我意识到 LLM 工程的瓶颈往往不在模型，在外围的工程可靠性。“

题7：你知道这个方向上已经有什么成熟方案吗？差在哪？#

参考回答（面试口语化——技术敏感度+判断力）：

在 Research Agent / AI 搜索研究这个方向上，我调研过的主流方案有几个：

① Perplexity Pro / Deep Research 目前最成熟的 AI 搜索产品。优点：多源搜索结果聚合、引用可溯源、体验流畅。不足：单轮对话模式，不适合批量跑 100 道题；无法定制搜索策略（比如调网页解析深度、指定 Fallback 解析器）；没有批量运行监控和审计日志；API 成本在大规模场景下偏高。

② GPT-4o with Search（OpenAI） 最新内建的搜索能力。优点：与 LLM 推理深度集成，支持多模态输入（图片+文字），自然语言交互体验好。不足：一次搜索到底，没有”搜偏了换关键词再搜”的迭代策略；无法处理搜索返回的 PDF 配图场景；没有逐题计时、超时控制、断点续跑等批量工程能力；搜索结果不可审计——你不知道它每一步搜了什么、为什么选这个结果。

③ Google Deep Research（Gemini） 能力最强的研究 Agent 之一。优点：多步搜索、自动生成研究报告、深度推理。不足：用户完全无法控制搜索策略——你没法告诉它”PDF 文档优先于网页""搜索 3 次没结果就停止""每步搜索用中文关键词尝试一下”；输出格式固定，无法与自定义评分程序对接；单次任务时间长，但无法批量提交 100 个任务并监控整体进度。

④ 基于 MCP 协议的自建 Research Agent 开源社区的方案（比如 OpenAI Agents SDK、LangGraph Research Agent）。优点：Flexibility 极高，可定制一切。不足：工程护栏不完整——很多开源 Research Agent 示例在 demo 跑得好，但上 100 道题的长时运行场景就会暴露各类问题（超时、无重试、无断点续跑、无日志审计等）。我们的方案正是在这个”开源框架可以做到但需要自己堆工程护栏”的空白点上做了系统性补齐。

我们的差异：这些方案各有侧重点，在”长时批量运行（100 题 × 10 分钟）+ 工程护栏（断点续跑、超时控制、重试退避）+ 可观测性（每题状态日志、统计聚合）+ 结果工程约束（格式清洗+校验）+ 搜索纠偏（连续无效搜索停止+关键词收缩）“这个组合上，没有一个现成方案能满足。我们的 Research Agent 不追求对话体验或者报告深度，而是聚焦在长时稳定运行 + 结果可审计 + 失败可恢复 + 可迭代优化这个工程视角，把 Agent 从”能回答一个问题”做到了”能稳定完成一整批任务”。

加分关键：不要只说”我知道这些方案”，要说”我知道这些方案的定位和取舍——Perplexity 在意用户体验、GPT-4o Search 在意模型集成、Deep Research 在意推理深度，而我在意的是工程可靠性。这没有谁更好，只是不同场景下不同取舍。“

题8：当数据 Agent 去查数据库时，怎么保证它查出来的数据跟业务口径对得上？（技术视野题）#

参考回答（面试口语化——考察工程思维 + 技术敏感度）：

这道题问的其实不是”Agent 会不会写 SQL”，而是 “Agent 怎么知道业务上说的’营收’是指什么？”

我分三个层面来讲我的理解：

第一层：问题的本质——Agent 查数据不准，不是 SQL 不行，是上下文缺失

我在做 Research Agent 的时候就有这个体会：Agent 单次查东西表现还不错，但一旦涉及到”按业务口径取数”，它就容易翻车。原因很简单——Agent 每次提问都要重新理解数据库：扫描一遍 schema、猜表之间的关联、自己发明指标定义。今天它把”活跃用户”定义为”7 天内登录过的用户”，明天同一个问题它可能定义为”30 天内登录过的用户”，查出来的数据跟业务对不上。

这不是模型能力问题，是知识底座的问题——Agent 缺少一个统一、准确、有来源的业务上下文层。

第二层：理想的解法——给 Agent 建一个”业务知识底座”

我最近研究了一个叫 ktx 的开源项目，它的思路我觉得特别好，分享给面试官：

ktx 定位是”数据 Agent 的上下文层”，核心做了三件事：

① 自动扫描数据库 + 构建语义层 它不要求人手动定义指标，而是自动去扫描 PostgreSQL、Snowflake、BigQuery 等数据库的表结构，检测哪些列可以关联（joinable columns），然后用一个 Join Graph 把原始表和高级指标串起来。Agent 查数据时，不用自己写 JOIN 逻辑，直接在语义层上声明式获取指标——底层复杂的表关联由框架自动处理。

② 吸收散落的业务知识 企业里业务知识是散的：dbt 里有模型定义，Metabase 里有看板，Notion 和 wiki 里还有团队沉淀的业务口径。ktx 会把所有这些来源的知识统一吸收进来，去重、归类。更重要的是——同一指标在不同来源的定义如果有冲突，它会主动标记出来，让业务方去确认。比如 dbt 里说”营收=订单金额-退款”，Notion 里说”营收=订单金额×0.95”，ktx 会在构建上下文时报警，而不是闷声让 Agent 用错定义。

③ 通过 MCP 协议暴露给 Agent 它不要求 Agent 换工具链——通过 ktx mcp start 启动一个 MCP 服务，Claude Code、Codex、Cursor 这些 Agent 工具直接通过 MCP 协议查询语义层。Agent 问”上季度营收多少”，不是自己去拼 SQL，而是先查 ktx 的语义层找到”营收”的批准定义和规范 SQL，再去执行。

第三层：这个思路对 Agent 工程的启发——知识底座思维

我做 Research Agent 和看了 ktx 之后，有一个深刻的体会：

Agent 工程的一个关键趋势，正在从”优化模型”转向”优化知识底座”。

传统思路是：Agent 不行 → 换更强的模型 → 调更好的 Prompt。但不管是 Research Agent 的搜索偏航纠偏，还是 ktx 的语义上下文层，它们的共同思路是：与其让 Agent 自己摸索，不如给它搭好一个准确、可维护、有来源的知识基础设施。

• Research Agent 里，我们不希望 Agent 自己瞎编搜索策略，所以给了它搜索纠偏和关键词收缩的护栏
• 数据 Agent 里，我们不希望 Agent 自己发明指标口径，所以需要给它一个语义上下文层，把业务知识固化下来

两者的本质是一样的——把 Agent 从”自由发挥”变成”在框架内执行”，而框架的准确性由工程来保障，不是靠 Agent 自己猜。

面试加分关键：不要只说”有个项目叫 ktx 挺有意思的”——要说”这个项目印证了我在 Research Agent 项目里的一个核心判断：Agent 的瓶颈往往不是模型，而是它依赖的知识底座不够准。不管是搜索还是查数，给 Agent 一个准确、统一、可维护的上下文层，比换更强的模型更有效。” 这样就把技术视野和你自己的项目经验串起来了，面试官会觉得你有深度思考能力。

👑 高阶加分（如果面试官追问）： 如果面试官追问”那你觉得 ktx 有什么局限？“可以说——“ktx 目前主要依赖 LLM 来做知识抽取和冲突检测，但 LLM 本身也可能产生幻觉，所以’自动标记冲突’这个环节还需要人工兜底。另外它当前对实时性要求高的场景（比如秒级查询）还不够成熟，MCP 协议的通信开销在这种场景下可能成为瓶颈。不过它的整体思路——给 Agent 建可维护的知识底座而不是让 Agent 自己探索——我认为是数据 Agent 走向生产环境的必经之路。”

1. 四步公式背熟#

1
业务痛点 → 初版方案 → 踩坑迭代 → 量化收益

每一步都要有具体细节，不要只喊概念。

2. 准备 2-3 个”踩坑故事”#

面试官最想听的就是这个——要准备：

• 一个技术选型的坑（“我们选用了纯 LLM 直接答题的方案但幻觉率超高……”）
• 一个工程落地的坑（“第一次全量跑 100 道题跑到第 43 道就崩了，前面全白干……”）
• 一个边界场景的坑（“有一道题的配图是 PDF 表格，Agent 解析成了乱码……“）

3. 任何一句话都要能被追问#

不要讲”我们做了优化”这种空话——要讲”我们做了 XX 优化，通过 XX 方法，带来了 XX 效果，过程中遇到了 XX 问题”。面试官每个细节都可以往下追问。

4. 量化！量化！量化！#

• ❌ “效果还不错”
• ❌ “感觉好了很多”
• ✅ “完成率从 52% 提升到 89%，29 道完全正确”
• ✅ “100 道题一晚上跑完，之前 3-4 个人要干一周”

5. 准备”反过来”的回答#

面试官可能追问：“那为什么不选 B 方案？“——要准备好备选方案的对比分析，每个技术选型至少 2-3 个理由。

🎯 下一篇预告：算法/CS 基础篇（17 题）— 手撕代码 + Java 八股 + LLM 基础