我做了几年大模型应用开发最近半年一头扎进 Agent 项目里手上一个重要输出就是码上面试这个项目。说是项目其实更像一个持续演进的学习样本从需求拆解、架构选型、模块落地到踩坑修复每一步都踩得实实在在。这篇学习记录是第一篇我尽量把思路写透把代码和 Prompt 的关键设计也放出来希望给同样在搞 Agent 开发、尤其是想用 Agent 改造面试场景的朋友一些参考。码上面试这个名字有点双关一层意思是马上试另一层是真的跟码有关——它是一个面向程序员面试场景的 AI Agent做的事情可以概括成三件模拟面试官追问、对候选人代码做多维度评审、面试结束后生成带学习路径的反馈报告。适合谁看如果你正在学习如何从 0 到 1 搭建 Agent或者你厌倦了死记硬背刷八股、想找一个进阶的实战项目可以跟着这篇记录走一遍我的完整思考。我不会只贴结果后面会把很多选择背后的为什么也讲清楚。1. 项目背景与需求拆解1.1 为什么做码上面试这个 Agent我在团队里经常做技术面试官同时自己也在准备新的机会。两种身份叠在一起让我发现一个很别扭的现状程序员准备面试的方式还停留在刷题库 背八股 找朋友模拟的阶段。刷题平台解决的是对不对的问题它告诉你代码能不能通过测试用例但面试官真正关心的往往是为什么这么写、有没有更优解、换一个场景你会不会崩。这些东西没法靠判题机得到反馈只能靠有经验的人点评而现实里很难找到一个人随时陪你模拟并给出高质量复盘。我开始想能不能把面试官的考察逻辑拆解成一个可编程流程用 LLM 和 Agent 把它自动化。于是码上面试这个项目立项了。它不追求做成题库的分发器而是做一个会追问、会评审、会总结的 AI 面试教练。在第一版里它通过 Web 聊天窗口跟候选人交互模拟真实面试的节奏。当时设想的用户有三类准备跳槽的开发人员、想要低成本做模拟面试的培训者、以及我自己这种想体系化梳理知识点的学习者。前两者的需求是要真实感后面那个需求是要结构感。1.2 核心需求与功能边界项目刚启动的时候需求膨胀得很快。我列过一版清单里面有语音识别、简历自动解析、LeetCode 同步、企业题库接入、行为面试模拟、Offer 行情分析甚至还想做移动端。冷静下来之后我把 MVP 砍到了四条面试官模拟支持算法、八股、系统设计三类常见面试场景语言风格可以配置。代码评审候选人把代码粘贴到对话里Agent 判断正确性、算法复杂度、代码质量。反馈报告面试结束后自动生成包含事实记录、能力短板、学习建议的总结报告。动态出题不依赖固定题库由 Agent 根据候选人的目标岗位、技术栈和当前水平现场生成题目。边界划定也很关键。第一版明确不做实时语音不做简历解析不做移动端所有交互都放在聊天窗口里。这样做的好处是能最快验证核心逻辑不被外围体验绑架。说白了Agent 项目最怕的不是功能少而是你永远在准备、永远没上线。1.3 和其他刷题工具的本质差异市面上的刷题平台核心是题库和判题器解决的是一个确定性问题你的代码能不能跑过测试用例。码上面试想解决的是开放性问题你的思路有没有偏差、表达有没有逻辑、知识有没有盲区、面试官下一句会往哪里打。这种差异决定了产品形态。题库平台用检索就够了而码上面试需要的是生成与推理。Agent 的价值就在这里——它不基于固定答案做匹配而是顺着候选人的回答往下走。你说用 Redis 做缓存它就会追问缓存穿透你怎么防你说系统用了消息队列它就会追问重复消费怎么处理。这是序列化的持续考量跟真实面试官的大脑很像。参考了不少 Agent 领域的资料之后我确认了面试场景天然适合 Agent 化的判断它有明确目标考察候选人某种能力、有工具代码执行、检索、有反馈闭环回答、评价、追问。把这三者用 ReAct 模式串起来就能造出一个真正在思维的面试机器人而不是一个搜索框。2. Agent 架构设计与方案选型2.1 整体架构单 Agent 还是多 Agent第一版我非常偷懒想用一个系统提示词包打天下一个 Agent 既当面试官又当评测员还负责记笔记。结果很惨。Prompt 太长之后关键指令被稀释这个 Agent 经常在考八股和点评代码两个角色之间打架。它上一句还在问候选人问题下一句就跳到作为面试官我建议你多学习这种话直接出戏。后来我明白了一个道理面试这种场景必须做角色隔离多 Agent 协作不是炫技而是业务要求。现在的架构里一共有五个角色主控 AgentCoordinator唯一的总导演负责面试流程节点切换和上下文路由。面试官 AgentInterviewer负责提问与追问拥有独立的风格配置模块。评审 AgentReviewer负责代码审查可以调用沙箱执行工具。记录 AgentRecorder负责提取候选人回答中的客观事实生成结构化的面试纪要。导师 AgentMentor负责在面试结束后生成反馈报告与后续学习路径。主控 Agent 根据当前阶段决定把对话交给谁。面试进行中Recorder 在后台同步提取事实候选人提交代码后主控把代码片段转给 Reviewer面试结束时Recorder 的纪要和 Reviewer 的评审结果一起打包传给 Mentor。这个设计的核心逻辑是职责单一、数据流转。每个 Agent 只做一件事Context 里就不会塞满无关信息幻觉自然减少。我在做这版架构的时候参考了主流 Agent 框架里关于多角色编排的思路也看了吴恩达的 Agent 教程但是落到自己项目里还是觉得角色对应状态、状态决定输入这句话最实在。2.2 框架选型为什么不直接套现成模板Agent 框架现在选择非常多LangGraph、AutoGen、CrewAI 各有拥趸。我最终选择了 LangGraph 作为载体但坦白讲核心循环逻辑我并没有完全依赖框架而是自己实现了一遍。理由有三点。第一面试流程的节点是确定的开场、出题、追问、评审、复盘。LangGraph 适合表达这种有向图状态机调度关系一目了然。第二我正处于 Agent 学习期如果直接套用 AutoGen 的自动化对话模板出了问题你根本不知道是哪一步走偏的。第三在并发控制和状态隔离这个维度上LangGraph 基于图的状态快照机制比 AutoGen 更容易让我理解。说句实在话对生产级应用用框架没问题但对学习型项目最好的方式是用框架理解编排思路然后把关键循环自己写一遍。你要知道每一轮 Agent 的思考里发生了什么模型先观察Observe再思考Think决定行动Act然后系统根据行动结果更新状态。等这个循环在脑内变成肌肉记忆再看任何框架都会发现它是这个基本模型的变体。2.3 记忆系统怎么让 Agent 记住候选人面试是多轮对话上下文管理是核心中的核心。我一开始用的是把所有历史消息一次性塞进 Prompt结果 Token 一上去模型就开始说车轱辘话而且答复质量断崖式下跌。后来我把记忆做成了三层工作记忆Working Memory保存当前面试最近的 10 轮对话用于保证追问的连贯性。会话摘要记忆Chat Memory每 5 轮对话由 Recorder 压缩一次把历史总结成摘要存起来。档案记忆Profile Memory面试结束后异步提取候选人的技能向量、薄弱点、擅长方向写入 JSON 档案供下一场面试复用。这个分层设计在 Agent 圈子里已经很常见了但真正让我警觉的是一篇关于 LLM 记忆安全防御框架的论文。它让我意识到记忆不仅要考虑存取机制还要考虑污染问题。候选人完全可能对着 Agent 说我并发编程很强如果 Agent 采样这句话进了能力档案那下一次面试的开始题难度的初始值就会被误导。所以我在记忆写入前加了一道客观性过滤只有候选人回答中可验证的行为事实才允许进入 Profile Memory主观自我评价一律拦截。下面的结构是我 Profile Memory 的核心字段{ candidate_id: uuid, skills: { language: [Python], topics: [缓存, 消息队列] }, strength_evidence: [ {topic: Redis持久化, quote: 候选人能准确描述RDB和AOF区别, source: interview_20250201} ], weakness_evidence: [], last_interview_summary: , updated_at: }3. 核心模块的实操实现3.1 模拟面试官模块追问链路的构建追问是整个项目里最看功力的模块。候选人说我用过 Redis主要是做缓存水平差的面试官听了就结束了水平好的会立刻问缓存穿透怎么防如果 Redis 挂了你的系统会怎样你如何保证缓存和数据库的一致性。为了把这种追问能力交给模型我没有靠Prompt里写一句请深入追问而是设计了一个三级追问策略把它做成结构化配置第一级基础确认型判断候选人是不是真的用过比如你负责的模块里 Redis 最核心的应用场景是什么。第二级细节拆解型考底层原理和边界条件比如Redis 的过期删除策略有哪几种大量 key 同时过期会怎样。第三级拓展应用型把知识点放到业务场景里考比如如果你要设计一个秒杀系统Redis 应该承担哪些环节。代码实现上我让面试官 Agent 每一轮输出都强制包含一个结构化字段用来让主控判断下一步走向。这个设计实际上是对 ReAct 模式的一种改造。模型先观察候选人的回答然后思考这个回答暴露了什么信号再决定下一步的追问类型。下面是一段简化的输出结构{ answer_tag: partial, next_question_type: detail_explore, next_question: 你提到了线程池那线程池的队列满了但任务还在提交会发生什么, confidence: 0.82 }这样做的效果非常明显。候选人在第一版测试里普遍反馈追问比想象中深其实就是这个结构化约束的功劳。模型不需要自己发明追问方向它只需要从几个预设的追问策略里选规范性提高了跑题率下降了。3.2 代码评审模块让 Agent 真的看懂代码代码评审不能光靠模型读文本。模型很有可能会被代码里的假象骗过去尤其是一些自己觉得正确、实际上有隐藏问题的代码。所以我把评审设计成静态检查 动态执行 模型分析三个步骤。第一步是静态检查。我用一个简单的规则引擎提前拦住一些低级问题比如命名不规范、有魔法数字、存在明显重复代码。这些事不需要 LLM 来处理规则更快也更靠谱。第二步是动态执行。候选人提交的代码会被写入临时文件扔进 Docker 容器里沙箱跑一遍拿到真实运行结果。这一招帮我发现了很多模型看文本时发现不了的运行时错误。第三步才是模型分析。我把代码文本、静态检查报告、运行结果三者一起交给 Reviewer Agent让它输出维度化的评审意见。这里贴一段沙箱执行的核心逻辑伪代码风格实际用的 Docker SDK 调用可以照这个思路封装def run_code_in_sandbox(code, languagepython): # 1. 写入临时工作目录 workspace create_temp_workspace(code) # 2. 构造容器限制CPU、内存、网络隔离文件系统 container docker_client.containers.run( imagesandbox-python:3.11, commandftimeout 10 python3 /app/main.py, mounts[f{workspace}:/app], network_disabledTrue, mem_limit256m, cpu_limit1.0, detachTrue, ) # 3. 等待执行结束回收日志与退出码 result container.wait(timeout15) logs container.logs() # 4. 清理容器与临时目录 container.remove(forceTrue) cleanup(workspace) return {exit_code: result[StatusCode], output: logs}我踩过的一个坑是容器执行结果本身也可能是错位的。候选人的代码里写了python main.py还是python3 main.py不同镜像环境差别很大导致同一份代码在本地能跑、沙箱里报错。所以我现在会在沙箱里预置一个环境探测机制先识别代码的语法和入口再决定执行命令。3.3 题目推荐与难度自适应题目的来源我经历了三个阶段。最开始是静态题库把常见面试题做成 JSON 文件命中率尚可但完全没有新意。第二阶段加入了动态生成让 Mentor Agent 根据候选人目标和当前表现现场出题。第三阶段加上了向量检索把历史会话里被用户标记为高质量的题目嵌入向量库每次优先检索相似题再让模型做小幅改写。难度自适应是最有意思的部分。我给候选人维护了一个能力分字段范围 0 到 100。每道题回答完后系统根据三个信号更新能力分答案正确率由模型给出评分、追问响应速度用消耗轮次和响应时长做近似判断、语义置信度来自模型输出的 confidence 字段。能力分直接决定下一题的难度档位。比如正确率超过 80%难度加一档低于 40%降一档。这个思路借鉴了在线教育里的项目反应理论IRT虽然实现简化了但足够验证闭环。这个模块最大的价值是让码上面试不只是一个考试工具它更像一个会陪着候选人升级的教练。当候选人连续答对之后它能自动挑战难度更高的题目而不会像题库那样永远随机出题。3.4 会话编排与并发处理多人同时面试怎么不崩项目上线之后第一件事就是被打到措手不及。AI Agent 怎么扛并发这个问题我体会特别深。第一版是同步请求两个人同时打开模拟面试整个服务基本卡死后面的 API 调用全部排队超时。后来我改成了异步任务队列每场面试被拆成一个独立的任务状态存放在 Redis 里前端通过轮询拿到进度。几个关键做法列出来供参考每场面试创建一个 Session ID对应的上下文快照、题目状态、能力分全部挂在独立命名空间下。Agent 每一步操作都加入任务队列由 Worker 并发消费而不是在请求线程内同步等待大模型返回。对模型 API 的调用统一走了超时与重试策略超过 60 秒直接降级不让用户干等。Token 用量做了成本控制历史记录超过窗口后自动压缩评审时才展开完整上下文。改完这轮之后并发能力提升了大大一截同一时间跑 20 场模拟面试没有压力。我突然意识到Agent 并发的问题跟传统后端并发有本质差别传统后端主要是数据库连接和线程资源Agent 后端最大的瓶颈是上下文状态管理和模型 API 的流控。要把系统做成每场面试是独立世界状态的隔离和流转必须设计得足够干净。4. 踩坑记录与排查实录4.1 Agent 循环不终止模型成了复读机有一段时间模拟面试会被卡死候选人已经答完了Agent 还在继续追问变成复读机。排查了很久才发现停止条件只判断了候选人是否回答这一点但模型内部的终结判定逻辑一直拿不到足够的置信度它就出于谨慎继续问。解决方法是双管齐下第一加了一个硬性的追问轮次上限默认最多 10 轮超过直接强制进入总结阶段第二在面试官 Agent 的系统提示词里加了一句指令明确要求当你已经获得足够信息时必须输出 END 信号。LLM 需要非常明确的行为边界概率性的差不多就行会无限迭代。4.2 上下文窗口溢出与回答退化第一版 30 分钟的面试大概 15 分钟之后就开始出问题模型回答越来越短内容越来越空泛甚至开始重复提示词里的原文。原因是全量历史记录一直堆在 Prompt 里面模型注意力被稀释了。后来我实现了三层记忆长对话被合理压缩。手动跑了几场完整的模拟面试Token 消耗大约降了三成回答质量也没有明显下降。这条经验对所有 Agent 项目都适用上下文是稀缺资源不能一直塞必须分层管理。谁先把存什么、丢什么、什么时候摘要想明白谁才能真正把对话做长。4.3 反馈报告幻觉Agent 编造了候选人没说过的话第二严重的问题是幻觉Mentor Agent 生成反馈报告时会脑补候选人在第二题中展示了很强的并发处理能力候选人明明没提过。排查发现是上下文里信息密度过高模型在合理空间里做了推断延伸。我的修复方法有两步。第一步生成报告之前只传 Recorder Agent 整理的结构化事实纪要而不是原始对话记录第二步在系统提示词里强制要求报告只允许引用对话记录中实际出现的原话或行为任何对候选人能力的推断必须标注为 AI 建议且必须提供支撑证据。效果有很大改进但没法做到百分百消除。为了控制风险我在产品层面把报告分成了两个板块事实记录和 AI 建议用户看到 AI 建议时会知道这不一定完全准确。4.4 高频问题速查表我将这一阶段最常遇到的情况整理成了一张速查表方便自己复盘也给同路人一个参考起点。现象可能原因排查思路与方案Agent 答非所问系统提示词太长关键指令被稀释精简 Prompt把最核心的指令放在开头并增加输出格式约束代码评审漏判只让模型看代码文本没有实际执行接入沙箱执行用真实运行结果辅助判断追问发散、偏题缺少追问类型的结构化约束增加next_question_type字段让模型从预设策略中选择多人并发卡死同步阻塞导致 API 请求排队改异步任务队列每次会话独立状态用 Redis 存快照记忆污染候选人的主观表述被写入长期档案写入前做客观性过滤区分行为事实与自我评价模型输出不稳定温度设置偏高或模型版本更新固定推理参数评审环节温度调低并加输出校验正则5. 第一版复盘与后续规划5.1 第一版效果与我的真实体感第一版做完之后我找了 50 多个真实用户做盲测有准备跳槽的同事也有模拟候选人身份的朋友。整体满意度评分大概在 7 分左右满分 10用户反馈最多的是追问比想象中深其次是报告写得挺像回事但也有人吐槽速度太慢不够真实面试那种自然流利。实际测试里一次模型完整回答需要 2 到 4 秒追问链路复杂时可能要 10 秒以上。Token 成本方面平均每场 30 分钟的面试大概消耗 15 万 Token按当前主流模型 API 的价格来算单场成本还是偏高。这个数据会直接影响产品是否适合免费开放后续必须优化。5.2 下一阶段要做的事接下来我给自己列了四个方向的具体事项不是概念是待办清单语音交互。这个对模拟面试的真实感提升最大但要做语音活动检测和打断控制技术上比纯文本复杂一个量级。Agent 安全加固。要防 Prompt 注入尤其是防止候选人从系统里套取题目答案或者篡改能力评分。这块我计划参考记忆安全防御的思路在关键入口加校验层。引入更细粒度的可观测性。我想给每场面试加上操作轨迹审计方便回放错误和调试。参考企业级 Agent 平台的设计把沙箱隔离、超时熔断、执行日志做成标准能力。从单场面试扩展到跨月陪练。结合档案记忆给候选人制定几周的学习计划每次面试后自动更新进度。这次先记录到这里具体的技术细节比如追问策略的表结构、状态机的完整字段定义、沙箱执行任务队列的代码骨架我会放到第二篇继续展开。给准备做 Agent 项目的同学一句实在话框架和模型是别人的踩坑之后的经验才是自己的这也是我写这份学习记录的初衷。
我做了几年大模型应用开发最近半年一头扎进 Agent 项目里手上一个重要输出就是码上面试这个项目。说是项目其实更像一个持续演进的学习样本从需求拆解、架构选型、模块落地到踩坑修复每一步都踩得实实在在。这篇学习记录是第一篇我尽量把思路写透把代码和 Prompt 的关键设计也放出来希望给同样在搞 Agent 开发、尤其是想用 Agent 改造面试场景的朋友一些参考。码上面试这个名字有点双关一层意思是马上试另一层是真的跟码有关——它是一个面向程序员面试场景的 AI Agent做的事情可以概括成三件模拟面试官追问、对候选人代码做多维度评审、面试结束后生成带学习路径的反馈报告。适合谁看如果你正在学习如何从 0 到 1 搭建 Agent或者你厌倦了死记硬背刷八股、想找一个进阶的实战项目可以跟着这篇记录走一遍我的完整思考。我不会只贴结果后面会把很多选择背后的为什么也讲清楚。1. 项目背景与需求拆解1.1 为什么做码上面试这个 Agent我在团队里经常做技术面试官同时自己也在准备新的机会。两种身份叠在一起让我发现一个很别扭的现状程序员准备面试的方式还停留在刷题库 背八股 找朋友模拟的阶段。刷题平台解决的是对不对的问题它告诉你代码能不能通过测试用例但面试官真正关心的往往是为什么这么写、有没有更优解、换一个场景你会不会崩。这些东西没法靠判题机得到反馈只能靠有经验的人点评而现实里很难找到一个人随时陪你模拟并给出高质量复盘。我开始想能不能把面试官的考察逻辑拆解成一个可编程流程用 LLM 和 Agent 把它自动化。于是码上面试这个项目立项了。它不追求做成题库的分发器而是做一个会追问、会评审、会总结的 AI 面试教练。在第一版里它通过 Web 聊天窗口跟候选人交互模拟真实面试的节奏。当时设想的用户有三类准备跳槽的开发人员、想要低成本做模拟面试的培训者、以及我自己这种想体系化梳理知识点的学习者。前两者的需求是要真实感后面那个需求是要结构感。1.2 核心需求与功能边界项目刚启动的时候需求膨胀得很快。我列过一版清单里面有语音识别、简历自动解析、LeetCode 同步、企业题库接入、行为面试模拟、Offer 行情分析甚至还想做移动端。冷静下来之后我把 MVP 砍到了四条面试官模拟支持算法、八股、系统设计三类常见面试场景语言风格可以配置。代码评审候选人把代码粘贴到对话里Agent 判断正确性、算法复杂度、代码质量。反馈报告面试结束后自动生成包含事实记录、能力短板、学习建议的总结报告。动态出题不依赖固定题库由 Agent 根据候选人的目标岗位、技术栈和当前水平现场生成题目。边界划定也很关键。第一版明确不做实时语音不做简历解析不做移动端所有交互都放在聊天窗口里。这样做的好处是能最快验证核心逻辑不被外围体验绑架。说白了Agent 项目最怕的不是功能少而是你永远在准备、永远没上线。1.3 和其他刷题工具的本质差异市面上的刷题平台核心是题库和判题器解决的是一个确定性问题你的代码能不能跑过测试用例。码上面试想解决的是开放性问题你的思路有没有偏差、表达有没有逻辑、知识有没有盲区、面试官下一句会往哪里打。这种差异决定了产品形态。题库平台用检索就够了而码上面试需要的是生成与推理。Agent 的价值就在这里——它不基于固定答案做匹配而是顺着候选人的回答往下走。你说用 Redis 做缓存它就会追问缓存穿透你怎么防你说系统用了消息队列它就会追问重复消费怎么处理。这是序列化的持续考量跟真实面试官的大脑很像。参考了不少 Agent 领域的资料之后我确认了面试场景天然适合 Agent 化的判断它有明确目标考察候选人某种能力、有工具代码执行、检索、有反馈闭环回答、评价、追问。把这三者用 ReAct 模式串起来就能造出一个真正在思维的面试机器人而不是一个搜索框。2. Agent 架构设计与方案选型2.1 整体架构单 Agent 还是多 Agent第一版我非常偷懒想用一个系统提示词包打天下一个 Agent 既当面试官又当评测员还负责记笔记。结果很惨。Prompt 太长之后关键指令被稀释这个 Agent 经常在考八股和点评代码两个角色之间打架。它上一句还在问候选人问题下一句就跳到作为面试官我建议你多学习这种话直接出戏。后来我明白了一个道理面试这种场景必须做角色隔离多 Agent 协作不是炫技而是业务要求。现在的架构里一共有五个角色主控 AgentCoordinator唯一的总导演负责面试流程节点切换和上下文路由。面试官 AgentInterviewer负责提问与追问拥有独立的风格配置模块。评审 AgentReviewer负责代码审查可以调用沙箱执行工具。记录 AgentRecorder负责提取候选人回答中的客观事实生成结构化的面试纪要。导师 AgentMentor负责在面试结束后生成反馈报告与后续学习路径。主控 Agent 根据当前阶段决定把对话交给谁。面试进行中Recorder 在后台同步提取事实候选人提交代码后主控把代码片段转给 Reviewer面试结束时Recorder 的纪要和 Reviewer 的评审结果一起打包传给 Mentor。这个设计的核心逻辑是职责单一、数据流转。每个 Agent 只做一件事Context 里就不会塞满无关信息幻觉自然减少。我在做这版架构的时候参考了主流 Agent 框架里关于多角色编排的思路也看了吴恩达的 Agent 教程但是落到自己项目里还是觉得角色对应状态、状态决定输入这句话最实在。2.2 框架选型为什么不直接套现成模板Agent 框架现在选择非常多LangGraph、AutoGen、CrewAI 各有拥趸。我最终选择了 LangGraph 作为载体但坦白讲核心循环逻辑我并没有完全依赖框架而是自己实现了一遍。理由有三点。第一面试流程的节点是确定的开场、出题、追问、评审、复盘。LangGraph 适合表达这种有向图状态机调度关系一目了然。第二我正处于 Agent 学习期如果直接套用 AutoGen 的自动化对话模板出了问题你根本不知道是哪一步走偏的。第三在并发控制和状态隔离这个维度上LangGraph 基于图的状态快照机制比 AutoGen 更容易让我理解。说句实在话对生产级应用用框架没问题但对学习型项目最好的方式是用框架理解编排思路然后把关键循环自己写一遍。你要知道每一轮 Agent 的思考里发生了什么模型先观察Observe再思考Think决定行动Act然后系统根据行动结果更新状态。等这个循环在脑内变成肌肉记忆再看任何框架都会发现它是这个基本模型的变体。2.3 记忆系统怎么让 Agent 记住候选人面试是多轮对话上下文管理是核心中的核心。我一开始用的是把所有历史消息一次性塞进 Prompt结果 Token 一上去模型就开始说车轱辘话而且答复质量断崖式下跌。后来我把记忆做成了三层工作记忆Working Memory保存当前面试最近的 10 轮对话用于保证追问的连贯性。会话摘要记忆Chat Memory每 5 轮对话由 Recorder 压缩一次把历史总结成摘要存起来。档案记忆Profile Memory面试结束后异步提取候选人的技能向量、薄弱点、擅长方向写入 JSON 档案供下一场面试复用。这个分层设计在 Agent 圈子里已经很常见了但真正让我警觉的是一篇关于 LLM 记忆安全防御框架的论文。它让我意识到记忆不仅要考虑存取机制还要考虑污染问题。候选人完全可能对着 Agent 说我并发编程很强如果 Agent 采样这句话进了能力档案那下一次面试的开始题难度的初始值就会被误导。所以我在记忆写入前加了一道客观性过滤只有候选人回答中可验证的行为事实才允许进入 Profile Memory主观自我评价一律拦截。下面的结构是我 Profile Memory 的核心字段{ candidate_id: uuid, skills: { language: [Python], topics: [缓存, 消息队列] }, strength_evidence: [ {topic: Redis持久化, quote: 候选人能准确描述RDB和AOF区别, source: interview_20250201} ], weakness_evidence: [], last_interview_summary: , updated_at: }3. 核心模块的实操实现3.1 模拟面试官模块追问链路的构建追问是整个项目里最看功力的模块。候选人说我用过 Redis主要是做缓存水平差的面试官听了就结束了水平好的会立刻问缓存穿透怎么防如果 Redis 挂了你的系统会怎样你如何保证缓存和数据库的一致性。为了把这种追问能力交给模型我没有靠Prompt里写一句请深入追问而是设计了一个三级追问策略把它做成结构化配置第一级基础确认型判断候选人是不是真的用过比如你负责的模块里 Redis 最核心的应用场景是什么。第二级细节拆解型考底层原理和边界条件比如Redis 的过期删除策略有哪几种大量 key 同时过期会怎样。第三级拓展应用型把知识点放到业务场景里考比如如果你要设计一个秒杀系统Redis 应该承担哪些环节。代码实现上我让面试官 Agent 每一轮输出都强制包含一个结构化字段用来让主控判断下一步走向。这个设计实际上是对 ReAct 模式的一种改造。模型先观察候选人的回答然后思考这个回答暴露了什么信号再决定下一步的追问类型。下面是一段简化的输出结构{ answer_tag: partial, next_question_type: detail_explore, next_question: 你提到了线程池那线程池的队列满了但任务还在提交会发生什么, confidence: 0.82 }这样做的效果非常明显。候选人在第一版测试里普遍反馈追问比想象中深其实就是这个结构化约束的功劳。模型不需要自己发明追问方向它只需要从几个预设的追问策略里选规范性提高了跑题率下降了。3.2 代码评审模块让 Agent 真的看懂代码代码评审不能光靠模型读文本。模型很有可能会被代码里的假象骗过去尤其是一些自己觉得正确、实际上有隐藏问题的代码。所以我把评审设计成静态检查 动态执行 模型分析三个步骤。第一步是静态检查。我用一个简单的规则引擎提前拦住一些低级问题比如命名不规范、有魔法数字、存在明显重复代码。这些事不需要 LLM 来处理规则更快也更靠谱。第二步是动态执行。候选人提交的代码会被写入临时文件扔进 Docker 容器里沙箱跑一遍拿到真实运行结果。这一招帮我发现了很多模型看文本时发现不了的运行时错误。第三步才是模型分析。我把代码文本、静态检查报告、运行结果三者一起交给 Reviewer Agent让它输出维度化的评审意见。这里贴一段沙箱执行的核心逻辑伪代码风格实际用的 Docker SDK 调用可以照这个思路封装def run_code_in_sandbox(code, languagepython): # 1. 写入临时工作目录 workspace create_temp_workspace(code) # 2. 构造容器限制CPU、内存、网络隔离文件系统 container docker_client.containers.run( imagesandbox-python:3.11, commandftimeout 10 python3 /app/main.py, mounts[f{workspace}:/app], network_disabledTrue, mem_limit256m, cpu_limit1.0, detachTrue, ) # 3. 等待执行结束回收日志与退出码 result container.wait(timeout15) logs container.logs() # 4. 清理容器与临时目录 container.remove(forceTrue) cleanup(workspace) return {exit_code: result[StatusCode], output: logs}我踩过的一个坑是容器执行结果本身也可能是错位的。候选人的代码里写了python main.py还是python3 main.py不同镜像环境差别很大导致同一份代码在本地能跑、沙箱里报错。所以我现在会在沙箱里预置一个环境探测机制先识别代码的语法和入口再决定执行命令。3.3 题目推荐与难度自适应题目的来源我经历了三个阶段。最开始是静态题库把常见面试题做成 JSON 文件命中率尚可但完全没有新意。第二阶段加入了动态生成让 Mentor Agent 根据候选人目标和当前表现现场出题。第三阶段加上了向量检索把历史会话里被用户标记为高质量的题目嵌入向量库每次优先检索相似题再让模型做小幅改写。难度自适应是最有意思的部分。我给候选人维护了一个能力分字段范围 0 到 100。每道题回答完后系统根据三个信号更新能力分答案正确率由模型给出评分、追问响应速度用消耗轮次和响应时长做近似判断、语义置信度来自模型输出的 confidence 字段。能力分直接决定下一题的难度档位。比如正确率超过 80%难度加一档低于 40%降一档。这个思路借鉴了在线教育里的项目反应理论IRT虽然实现简化了但足够验证闭环。这个模块最大的价值是让码上面试不只是一个考试工具它更像一个会陪着候选人升级的教练。当候选人连续答对之后它能自动挑战难度更高的题目而不会像题库那样永远随机出题。3.4 会话编排与并发处理多人同时面试怎么不崩项目上线之后第一件事就是被打到措手不及。AI Agent 怎么扛并发这个问题我体会特别深。第一版是同步请求两个人同时打开模拟面试整个服务基本卡死后面的 API 调用全部排队超时。后来我改成了异步任务队列每场面试被拆成一个独立的任务状态存放在 Redis 里前端通过轮询拿到进度。几个关键做法列出来供参考每场面试创建一个 Session ID对应的上下文快照、题目状态、能力分全部挂在独立命名空间下。Agent 每一步操作都加入任务队列由 Worker 并发消费而不是在请求线程内同步等待大模型返回。对模型 API 的调用统一走了超时与重试策略超过 60 秒直接降级不让用户干等。Token 用量做了成本控制历史记录超过窗口后自动压缩评审时才展开完整上下文。改完这轮之后并发能力提升了大大一截同一时间跑 20 场模拟面试没有压力。我突然意识到Agent 并发的问题跟传统后端并发有本质差别传统后端主要是数据库连接和线程资源Agent 后端最大的瓶颈是上下文状态管理和模型 API 的流控。要把系统做成每场面试是独立世界状态的隔离和流转必须设计得足够干净。4. 踩坑记录与排查实录4.1 Agent 循环不终止模型成了复读机有一段时间模拟面试会被卡死候选人已经答完了Agent 还在继续追问变成复读机。排查了很久才发现停止条件只判断了候选人是否回答这一点但模型内部的终结判定逻辑一直拿不到足够的置信度它就出于谨慎继续问。解决方法是双管齐下第一加了一个硬性的追问轮次上限默认最多 10 轮超过直接强制进入总结阶段第二在面试官 Agent 的系统提示词里加了一句指令明确要求当你已经获得足够信息时必须输出 END 信号。LLM 需要非常明确的行为边界概率性的差不多就行会无限迭代。4.2 上下文窗口溢出与回答退化第一版 30 分钟的面试大概 15 分钟之后就开始出问题模型回答越来越短内容越来越空泛甚至开始重复提示词里的原文。原因是全量历史记录一直堆在 Prompt 里面模型注意力被稀释了。后来我实现了三层记忆长对话被合理压缩。手动跑了几场完整的模拟面试Token 消耗大约降了三成回答质量也没有明显下降。这条经验对所有 Agent 项目都适用上下文是稀缺资源不能一直塞必须分层管理。谁先把存什么、丢什么、什么时候摘要想明白谁才能真正把对话做长。4.3 反馈报告幻觉Agent 编造了候选人没说过的话第二严重的问题是幻觉Mentor Agent 生成反馈报告时会脑补候选人在第二题中展示了很强的并发处理能力候选人明明没提过。排查发现是上下文里信息密度过高模型在合理空间里做了推断延伸。我的修复方法有两步。第一步生成报告之前只传 Recorder Agent 整理的结构化事实纪要而不是原始对话记录第二步在系统提示词里强制要求报告只允许引用对话记录中实际出现的原话或行为任何对候选人能力的推断必须标注为 AI 建议且必须提供支撑证据。效果有很大改进但没法做到百分百消除。为了控制风险我在产品层面把报告分成了两个板块事实记录和 AI 建议用户看到 AI 建议时会知道这不一定完全准确。4.4 高频问题速查表我将这一阶段最常遇到的情况整理成了一张速查表方便自己复盘也给同路人一个参考起点。现象可能原因排查思路与方案Agent 答非所问系统提示词太长关键指令被稀释精简 Prompt把最核心的指令放在开头并增加输出格式约束代码评审漏判只让模型看代码文本没有实际执行接入沙箱执行用真实运行结果辅助判断追问发散、偏题缺少追问类型的结构化约束增加next_question_type字段让模型从预设策略中选择多人并发卡死同步阻塞导致 API 请求排队改异步任务队列每次会话独立状态用 Redis 存快照记忆污染候选人的主观表述被写入长期档案写入前做客观性过滤区分行为事实与自我评价模型输出不稳定温度设置偏高或模型版本更新固定推理参数评审环节温度调低并加输出校验正则5. 第一版复盘与后续规划5.1 第一版效果与我的真实体感第一版做完之后我找了 50 多个真实用户做盲测有准备跳槽的同事也有模拟候选人身份的朋友。整体满意度评分大概在 7 分左右满分 10用户反馈最多的是追问比想象中深其次是报告写得挺像回事但也有人吐槽速度太慢不够真实面试那种自然流利。实际测试里一次模型完整回答需要 2 到 4 秒追问链路复杂时可能要 10 秒以上。Token 成本方面平均每场 30 分钟的面试大概消耗 15 万 Token按当前主流模型 API 的价格来算单场成本还是偏高。这个数据会直接影响产品是否适合免费开放后续必须优化。5.2 下一阶段要做的事接下来我给自己列了四个方向的具体事项不是概念是待办清单语音交互。这个对模拟面试的真实感提升最大但要做语音活动检测和打断控制技术上比纯文本复杂一个量级。Agent 安全加固。要防 Prompt 注入尤其是防止候选人从系统里套取题目答案或者篡改能力评分。这块我计划参考记忆安全防御的思路在关键入口加校验层。引入更细粒度的可观测性。我想给每场面试加上操作轨迹审计方便回放错误和调试。参考企业级 Agent 平台的设计把沙箱隔离、超时熔断、执行日志做成标准能力。从单场面试扩展到跨月陪练。结合档案记忆给候选人制定几周的学习计划每次面试后自动更新进度。这次先记录到这里具体的技术细节比如追问策略的表结构、状态机的完整字段定义、沙箱执行任务队列的代码骨架我会放到第二篇继续展开。给准备做 Agent 项目的同学一句实在话框架和模型是别人的踩坑之后的经验才是自己的这也是我写这份学习记录的初衷。
