1. 这个标题背后我为什么开始做 Agent Harness如果你在技术社区刷到“AI 面试官”这个说法大概率看到的演示都是这样的——把职位描述和几道题丢给一个大模型然后让它“扮演面试官”提问再对候选人的回答打个分。说实话这种东西我见过太多了从 2023 年到现在每隔一段时间就会冒出来一个类似的 Demo但真正能在企业内部跑起来的几乎没有。原因倒不在于大模型会不会提问。市面上主流模型扮演面试官提问的流畅度早就够了真正让这类 Demo 死掉的是另外三件事题库怎么管、代码怎么验、评估怎么让人信服。先说题库。我在这个项目里接手的是一个积累了多年的题库最后落到系统里的是 2.2 万道题覆盖算法、数据结构、系统设计、数据库、网络、操作系统等各个方向。问题在于这些题不是给 AI 准备的——它们原本是给人类面试官看的题干里带着各种隐含前提、上下文依赖、甚至内部约定俗成的简写。你直接把原题喂给大模型然后让它“根据这道题面试候选人”大概率会得到非常离谱的结果要么题目信息本身不足以让模型理解考核点要么模型自己脑补出了一套和原始评分标准完全对不上的判断逻辑。再说代码验证。这是最要命的一环。AI 面试官如果只是让候选人把代码贴在聊天框里然后让模型“看一眼”给出评价——这在算法题上还有一点可行性但对于涉及编译运行、依赖环境、输入输出格式、边界条件的题目纯粹靠视觉检查根本靠不住。模型读代码的能力再强它无法验证这段代码到底能不能跑通更无法获得运行时的真实反馈。你让面试官凭“感觉”判断候选人代码质量而不是基于测试用例的通过情况和执行轨迹这在技术决策上就是灾难。最后是评估可信度。面试官给出的每一个评价都得能追溯——这道题考核什么、候选人代码运行了什么测试用例、在哪里报错、报错信息是什么、候选人是经过多少次尝试才改对的、有没有借助提示才完成的。这些信息如果不完整面试评价就是空中楼阁。更现实的问题是如果 AI 面试官只是调用一次大模型接口基于一段对话记录给个分那用人部门凭什么相信这个分数候选人凭什么接受这个反馈HR 又怎么把这个结果归档进招聘流程所以我在做这个项目的时候从一开始就明确了一个判断绝对不能只靠 Prompt 堆砌出一个“貌似智能”的面试官必须有一个围绕 Agent 构建的执行框架Harness把工具调用、代码运行、证据采集、状态管理全部纳入可控管道。这篇文章我就想把这个判断背后的完整思考、架构设计和落地过程中的坑原原本本讲一遍。2. 纯 Prompt 方案的三个致命伤不只是“效果不好”在深入 Harness 架构之前先把纯 Prompt 方案为什么不行这件事说透。很多人以为 Prompt 面试官效果不好是提示词写得不够好于是不断调措辞、加 few-shot、优化 system message——这条路我走了差不多两个月最终得出结论问题根本不在提示词层面而在系统边界上。2.1 致命伤一题库内容与 Prompt 上下文之间的失配2.2 万道题的题库有一个很现实的特点题目本身的“可执行性”差异极大。有的题是完整的算法题题干、输入输出格式、示例全都有有的题却只是一段描述比如“请设计一个支持高并发的短链服务”——这种题是用来做系统设计讨论的没有标准答案得分点完全依赖面试官的追问方向和候选人应答的深度。当你试图把这些题塞进 Prompt 里让模型充当面试官时会遇到一个所有人都会撞上的墙上下文窗口有限而且很贵。你不可能把 2.2 万道题的完整题库、评分标准、追问策略全部塞进 system prompt——那不仅超出窗口限制还会严重稀释模型对当前这道题的注意力。实际的妥协方案只能是把当前这一道题和它对应的简单评分标准塞进上下文。可问题是题目本身的背景信息经常不足以支撑一场合格的面试。举个例子题库里有这样一道题SQL 题目题干写着“查询每个部门薪资最高的员工”。看起来很简单对吧但如果你了解这道题的历史就会知道它真正的考核点在于“窗口函数 vs 分组聚合两种写法的性能差异”以及“同薪资并列时怎么处理”。这些信息不在题干里而是沉淀在题库的附注和往期面试记录里。纯 Prompt 方案每次调用都只看到题干文本这些关键上下文完全丢失了。2.2 致命伤二模型“自说自话”的代码评估不具备可证伪性让模型直接读候选人代码然后打分表面上看很智能实际隐患巨大。大模型对代码的“感觉”是基于训练数据里的统计规律不是基于真实执行结果。它看过海量正确代码和错误代码所以能给出一个看似专业的判断——但这个判断没有任何运行时证据支撑。具体到面试场景这会造成三个问题模型可能被“看起来对”的代码迷惑。一段代码逻辑正确但语法上有细节错误比如少了一个冒号、变量名拼写不一致模型倾向于基于整体观感给高分而不是指出运行失败。模型无法区分“候选人自己调试通过”和“候选人贴了一段自己都看不懂的代码”。前者体现工程能力后者可能是背题或者抄的。没有运行轨迹这两种情况在文本层面几乎是不可区分的。模型可能产生幻觉编造不存在的错误。我实测过有时候模型面对一段完全正确的代码会“预测”在某些边界输入下可能出问题然后煞有介事地给出扣分理由——这在纯文本评估里是致命的因为候选人无法反驳面试官也无法验证。2.3 致命伤三多轮面试中的状态管理失控一场合格的面试不是单轮问答而是多轮交互出题 → 候选人作答 → 追问 → 候选人修改 → 再次评估。每一次追问都要基于上一轮的代码和回答这意味着你有一个逐步累积的“面试状态”需要维护。在纯 Prompt 方案里这个状态只能靠“把历史对话全部塞进上下文”来实现。但对话一长问题就来了上下文里的早期内容被截断越靠前的内容注意力权重越低模型对候选人一开始的表现记忆模糊追问质量急剧下降更麻烦的是候选人如果修改了代码模型对“第一版代码”和“最终版代码”之间的差异感知就变得很迟钝——它更像是看了一堆连续的文本而不是看到了一个代码文件的版本演化。我当时用纯 Prompt 跑了几十场模拟面试发现最典型的翻车场景是候选人在第五轮时修正了第三轮的 bug但 Prompt 面试官在最后总结时还拿着第三轮的旧问题扣分。这种事发生一次两次还可以解释为模型能力问题频繁出现就是架构问题了。这三个致命伤每一个都指向同一个结论面试官 Agent 需要外部化状态、外部化工具、外部化证据而不是把一切都压在大模型的单次推理上。这正是 Harness 架构的价值所在。3. Harness 的核心理念从“让模型说”到“让模型做看结果”“Harness”这个词在 AI Agent 领域有特定含义——它指的是为 Agent 提供运行环境和工具接口的那层“装置”有点类似于测试领域里的“测试夹具”。在代码生成 Agent比如 Codex、Devin 这类产品里Harness 通常指代码执行沙箱、测试运行器、文件系统接口和反馈回路的总和。我把这个概念引入 AI 面试官项目就是基于一个非常朴素的判断面试官 Agent 不应该只是一个“会说话的大脑”它应该是一个“能动手验证的完整系统”。它要能出题也要能编译运行候选人代码要能基于运行结果追问还要能把整个过程中的关键证据结构化留存。3.1 从“大脑”到“大脑手眼”的架构转变纯 Prompt 方案里大模型干所有事理解题目、生成提问、读代码、给评价。这是一个典型的“大脑”模型不接触任何外部工具。它的信息全部来自文本输入输出也全部是文本。这种架构的好处是简单坏处是评估质量完全依赖模型“脑补”。Harness 方案的思路是把“大脑”之外的部分全部拆出去让模型通过工具调用去操作外部系统再把操作结果作为新的上下文输入。具体到我的设计里拆成了五层会话管理层维护面试状态、当前题目、历史交互记录、候选人画像。模型不直接持有完整历史而是通过检索接口按需读取。题库服务层支撑 2.2 万道题的检索、筛选、题目分组和题面渲染。代码执行层运行候选人提交的代码执行预设的测试用例采集 stdout、stderr、返回值、运行耗时、内存占用等元数据。证据存储层把代码快照、测试结果、执行日志、模型评估中间结果全部落库形成不可篡改的证据链。策略控制层决定面试官 Agent 何时出题、何时追问、何时结束面试、如何计算评分。这是 Prompt 无法简单承载的“流程逻辑”。在这个架构下大模型的角色反而变“小”了——它不再负责所有事而是专注于两件事根据当前状态生成下一步话术以及基于工具返回的证据给出评估判断。这两件事恰恰是语言模型最擅长且最可靠的。3.2 为什么是“证据链”而不是“推理过程”我在项目文档里坚持用“证据链”这个词而不是“推理过程”是因为两者本质不同。模型给出评估结论时内部可能经过复杂的推理attention 计算、概率采样等这个内部推理是不可控、不可解释的。但 Harness 里记录的证据是不同的——它是客观事实候选人写了什么代码、测试通过了几个、失败的那个用例输入是什么、编译报错发生在第几行。证据链的本质是把模型的主观判断锚定到客观事实上。模型可以说“该候选人对边界条件的处理不充分得分为 3/5。”这句评价如果没有证据支撑跟没说一样。但如果模型说的是“该候选人的代码在测试用例[-2, -1, 0, 1, 2]上得到错误输出0说明对负整数前缀的处理存在缺陷得分为 3/5。”——这个评价就完全不一样了它有可追溯的锚点用人部门可以复核候选人也可以理解。要做到这一点Prompt 里就不能只用自然语言提要求必须在 Harness 层面强制工具返回结构化数据并把结构化数据按照可以引用的格式注入模型上下文。这条“工具返回→结构化存储→按需注入上下文→模型引用输出”的链路就是我说的“代码证据链”的实体形态。3.3 Harness 与 Prompt 的边界划分很多同行问我说你做了 Harness那 Prompt 还需要吗当然需要但它的角色变了。在 Harness 架构里Prompt 不再是唯一的智能来源而是负责“调度模型在正确的时间做正确的事”。我的做法是把 Prompt 拆成四种系统提示词System Prompt定义面试官的基本人格、语言风格、行为边界避免模型说出不当言论。工具定义提示词Tool Definition Prompt告诉模型当前有哪些工具可用、每个工具的输入输出 schema、什么情况下该调用哪个工具。上下文注入提示词Context Injection Prompt由 Harness 动态生成包含当前面试状态、候选人信息、当前题目、最新代码快照、测试结果等结构化数据。动作策略提示词Action Policy Prompt定义模型“下一步做什么”的规则比如什么情况下追问、什么情况下切换到系统设计题、什么情况下结束面试。这套拆分看起来很简单但它解决了一个非常实际的问题大模型每轮只接收恰好足够的信息不会因为上下文过长而迷失。模型不需要记住 2.2 万道题它只需要知道“当前这道题是什么、考核点是什么、候选人刚写出来的代码表现如何”。至于题目怎么选、下一题是什么那是 Harness 的策略层决定的不归模型管。4. 2.2 万题库的工程化重建从“给人看”到“给系统用”题库是整个 AI 面试官的核心资产。2.2 万这个数字看着不少但真正用起来的时候会发现题库的质量远比数量重要。在把题库接进系统之前我花了大半个月做数据治理这个过程远比写 Agent 代码痛苦得多。4.1 题目标签体系的重新设计原始题库的标签体系是给人看的有题目类型算法、数据库、系统设计等、难度等级、题目来源等字段。但 AI 面试官需要的信息粒度要细得多。我给每道题增加了下面这层“机器可读”的元数据考核点列表这道题想要验证的具体能力项例如“递归终止条件设置”“索引使用合理性”“并发下的线程安全”。考核点是面试官追问的主要依据。前置知识依赖候选人答这道题之前应该掌握的知识点。用于面试官动态调整追问深度——如果候选人连前置知识都不懂就不必深入太难的方向。代码模板针对编程题提供一个标准化的初始代码框架确保候选人的代码可以被自动编译和测试。没有模板的题自动判题根本无法落地。测试用例集针对算法题设计多组测试用例从基础正确性到边界条件到性能压测全部配好输入输出。禁用提示哪些信息不能由面试官主动透露给候选人。这在纯 Prompt 方案里总是被忽略但在真实面试里是底线问题。这个重新设计的工作量非常大。2.2 万道题里真正能直接接入自动判题的算法题大概只有 4000 道左右剩下的要么缺测试用例要么题目描述不完整要么强依赖人类面试官的主观判断。我的做法是分优先级处理先把 4000 道算法题完整补齐元数据跑通 MVP再逐步扩展到其他题型。4.2 基于难度与知识点的动态抽题策略题库准备好了接下来就是面试官如何选题目。我的 Harness 里实现了一个抽题策略模块核心逻辑是根据候选人的目标职位如“高级后端工程师”确定题型分布权重。根据面试阶段基础筛选、深入考察、综合评估确定难度区间。从题库中随机抽取候选题目但加入“互斥条件”保证同一场面试不出现知识点重叠过多的题。抽出来的题通过 Harness 注入模型上下文同时附上考核点列表和禁用提示。这套策略实现了“既随机又可控”的平衡。如果完全随机可能出现三套全是动态规划的惨剧如果完全不随机题库的利用率又太低。抽题算法本身不难但如果没有 Harness 的支撑抽题逻辑和模型对话就完全是两套系统需要人工拼装效率极低。4.3 题库分类与代码执行引擎的对接细节在实际对接中有一个细节特别值得提算法题不是只有一种语言。题库里同一道题候选人可能用 Python、Java、C、Go 来作答。这意味着代码执行层必须要有多语言运行环境。我在这个项目里用了容器化方案每种语言一个基础镜像候选人代码提交后在容器内编译运行执行完销毁容器。隔离性、资源限制、超时控制全部由容器编排层统一处理。测试用例的执行结果也分了好几个层级编译/解释阶段代码能不能通过语法检查。失败则记录编译器报错。基础用例阶段少数几个公开示例用例用于快速反馈“你的代码是不是完全跑不通”。完整用例阶段覆盖各种边界条件的完整测试集用例对候选人不可见。性能压测阶段大数据量输入下的耗时和内存表现。这种分层设计有一个好处如果候选人在基础用例就失败了系统可以直接提示“请先确保代码能正确运行”并给编译错误信息如果基础用例全过但完整用例挂了系统给出的反馈可以集中在隐藏用例上例如“程序在包含负整数的数组中输出不正确”。这些反馈既是给候选人的提示也是给模型的追问素材。5. 代码证据链的落地实现评估不靠感觉靠事实这一部分是整个项目的核心也是我觉得最值得分享的一段。“代码证据链”不能停留在概念层面必须落到数据结构、存储方案和模型交互协议上。5.1 运行证据如何被收集、结构化和存储我把证据分为三个层次。第一层是原始证据直接来自代码执行的结果stdout 输出、stderr 错误流、退出码、执行耗时、内存峰值、编译器/解释器版本信息。这一层数据是最客观的不经过任何模型加工。第二层是结构化证据由 Harness 根据原始证据加工而成针对每个测试用例标记“通过”还是“失败”如果失败则截取期望输出与实际输出的差异片段针对编译失败的情况标记出错的代码行号和错误类型。这一层是“人可读、模型可用”的关键。第三层是评估证据来自模型的输出模型基于前两层证据给出的评分、扣分理由、追问建议。这一层是主观的但它的锚点全部指向第二层的结构化证据。存储方案上我用了一张主表记录每次代码提交每一条提交关联多张子表测试用例结果表、编译日志表、代码快照表、模型评估表。每个字段都有时间戳确保整个证据链可以被完整回溯。我甚至保留了每一次代码提交的原始内容——这在面试复盘时特别有用可以看到候选人的调试过程是“稳步前进”还是“反复横跳”。5.2 模型上下文中的证据注入与引用格式证据收集好了还得让模型“会用”。这里存在一个很微妙的工程问题模型上下文空间有限不可能把所有测试用例的执行结果全部塞进去。所以 Harness 要做“证据摘要”和“按需注入”两件大事。证据摘要的逻辑是对于通过的测试用例只保留“通过 N/M 组”对于失败的用例完整保留输入、期望输出、实际输出、报错信息最多取前三条失败用例。这样既保证了模型能了解到代码的整体表现又避免细节爆炸。按需注入的逻辑是第一轮评估时只给模型看到基础用例执行结果如果基础用例全过再进入完整用例评估阶段时把隐藏用例的失败信息注入。这种分阶段注入可以让模型先判断“代码的骨架对不对”再深入判断“边界情况有没有处理好”评估颗粒度更清晰。在 Prompt 的上下文注入格式上我设计了一种纯文本但结构化的格式[Test Result] Passed: 5/8 Failed:[ {case: input[-1,2,-3,4], expected: 6, actual: 3, error: null}, {case: input[1,-2,1], expected: 2, actual: 4, error: out of range}, ] Compile: success | failed at line 12: unexpected token ;这种格式的优势在于完全不用 JSON 也能被模型稳定解析而且人类面试官一眼也能看懂。Prompt 不是越花哨越好关键是信息密度和可解析性。5.3 多轮面试中的代码差异追踪前面的证据链都是针对“单次代码提交”的。但真实面试里候选人会根据面试官反馈修改代码这时候 Harness 需要额外记录代码版本差异。我的做法是在每次提交时计算一个 diff并把 diff 的语义摘要不是原始代码文本注入模型上下文。比如Revision 1: initial submission, passed basic cases 3/3 Revision 2: added negative-number handling, passed basic 3/3, hidden 5/8 Revision 2 diff: added if (num 0) return 0; before main loop这样模型不仅能评估“当前代码好不好”还能评估“候选人有没有针对反馈做出有效改进”。这个维度在纯 Prompt 方案里几乎无法实现但在 Harness 里只是几十行代码的事。证据链的最终价值在于面试官给出的每一个结论都可以被回溯到一条具体证据上。这不是为了“追责”而是为了让评估过程可监督、可改进——当面试结果和候选人入职后的实际表现出现偏差时能快速找到是题目、是模型判断、还是证据收集哪个环节出了问题。6. 实际落地中的四个高频坑用踩坑经历换来的经验任何项目做得再细致落地过程中也会遇到各种意想不到的问题。这一部分我整理四个最典型的高频坑都来自我的真实经历希望对正在做 Agent 类项目的同行有帮助。6.1 模型上下文爆炸不是所有历史都要保留这是我遇到的第一个大坑。最初的设计里为了确保模型不“失忆”我把面试中每一轮对话和每一次代码提交都拼进上下文。结果模型到了第五六轮之后明显开始“发呆”——提问质量下降甚至开始重复已经问过的问题。后来我意识到模型不需要记住每一轮细节它对面试的“理解”应该由 Harness 维护而不是靠上下文硬扛。我的改造方案是维护一个“面试摘要”对象每次交互结束后Harness 让模型输出一句话摘要当前候选人表现的核心特征、已覆盖的考核点、待考察的方向作为下一轮的 Context 基础。历史对话全文存数据库但模型看不到只在需要时按需检索。这一改上下文长度从无限膨胀变成了稳定的 4-6K token 左右模型表现立刻稳定下来。6.2 执行环境的不确定性容器镜像版本一致性代码执行环境最大的隐患是镜像更新导致的“意外挂科”。有一次我们把 Python 镜像从 3.10 升级到 3.11结果大量基础用例突然失败——原因是 3.11 里正则表达式模块的一个默认行为改了。这个坑特别隐蔽因为问题不在代码本身而在执行环境版本漂移。解决方案也很朴素每个基础镜像打上固定的版本 tag并且代码执行层启动前校验镜像 hash。测试用例和镜像版本之间建立对应关系保证同一道题的执行环境永远可重复。这件事在面试场景里特别重要——否则会出现“同一个代码昨天能过、今天不能过”的荒唐事。6.3 模型的“脑补式补全”没有数据时硬要回答我承认这是我在 Prompt 和 Harness 设计上的双重锅。早期我让模型直接基于代码文本评估它经常在测试用例结果缺失的情况下自己“脑补”一套测试结果出来——比如“该代码通过所有测试用例”这种话。后来我把“测试结果缺失”作为一个显式状态注入 Prompt并在系统提示里写死规则“如果没有测试执行结果不得对代码正确性做出任何断言。只能描述代码结构与潜在风险。”人类面试官实际上也是这样做的——没有跑过的代码你不确定它就一定对。模型也是一样需要被 Harness“约束”住不能让它被训练时的统计先验带偏。6.4 异步任务与超时不是所有代码都能 3 秒跑完有些系统设计题会要求候选人写模拟代码比如并发压测脚本、一个大文件处理流程。这类代码运行时间可能远超普通算法题。如果执行层统一设定 3 秒超时这些题基本没法跑。我的方案是给测试用例配置不同的执行模式秒级模式普通算法题超时 2 秒。长跑模式偏工程实现的题超时 30 秒。手动模式系统设计讨论中的代码不自动执行只做静态评估。这个配置不但缓解了资源占用问题也避免了“因为题目类型不匹配导致代码被误判”的低级错误。有个小经验执行超时时间宁可宽一点也不要卡太死。面试场景不是比赛场景候选人本来就紧张代码写完后3 秒超时和 10 秒超时的体验差别很大。但超时之后的反馈文案要精心设计不要直接说“您的代码超时了”换成“代码运行时间过长请检查是否有死循环或过度嵌套”对候选人更友好。7. 分布式题库与评估一致性从 2.2 万题到千人千面的挑战当题库量级到了一定的规模另一个深水区就会出现——评估一致性。同一道题候选人 A 和候选人 B 都写对了但代码风格差异巨大模型会不会给不同分同一个候选人在不同时间面试同一道题评估结果会不会漂移这些都是“AI 面试官”能不能被业务部门接受的关键。7.1 评估一致性的两条防线第一条防线是结构化评分标准。每道题关联的考核点列表就是评分的依据。模型输出评分时Harness 强制它按考核点分项打分而不是给一个笼统的总分。比如一道题有四个考核点逻辑正确、边界处理、代码规范、性能考量模型必须针对每个考核点输出分数和理由证据链里的测试结果也要映射到对应的考核点上。这样最多保证模型在同一维度上做判断不会今天说边界处理是问题、明天说边界处理没问题。第二条防线是重复校准。我定期从题库里抽样一批题目用同一套测试数据和代码提交让模型在不同时间跑评估对比评分分布的漂移幅度。如果发现某道题的评分方差过大就检查是不是题目元数据不足或者测试用例有歧义。校准不是一次性的——大模型的行为会随版本迭代变化每次模型升级后都必须重新校准。7.2 千人千面AI 面试官要能“因材施教”面试里面很重要的一点是“因人而异”。同样一道题如果候选人答得很快且完全正确面试官应该加大难度追问如果候选人在基础环节已经卡住了就不应该继续加深难度。这和“千人一面”的考试系统不同Harness 需要动态感知候选人水平并调整面试路径。我的实现思路是在 Harness 里维护一个“候选人能力画像”对象包含技能维度上的分数比如“递归”7 分、“动态规划”5 分、“SQL 索引”8 分。每答完一题画像分数更新一次下一题的抽题策略基于画像调整。这个画像不直接暴露给模型但模型可以通过上下文注入感知“当前候选人擅长什么、不擅长什么”从而调整追问策略。这一步让 AI 面试官从“答题机”变成了“真正的面试官”——它会根据候选人的实时反馈调整方向。也是我觉得这个项目最有价值的部分。7.3 题库的持续进化和闭环优化Harness 架构还有一个额外红利每次面试都会产生新的真实数据反过来可以优化题库和评分标准。我在证据链里记录了大量“模型认为候选人该得的分”和“后续真实面试官复核后的分”两者之间的差异就是题库和模型需要优化的方向。比如有一道系统设计题模型总是给偏高分但人工复核发现候选人遗漏了缓存层设计。原因很快定位到题目元数据里没有把“缓存设计”设为考核点所以模型评估时没把它当作关键项。修正方式是补充考核点、调整测试用例、刷新模型参考评估然后继续跑校准。这就是为什么我说 Harness 不只是一个“执行框架”它是一个可以持续学习和进化的系统。数据在系统里流动反馈进系统里沉淀偏差不断被校正。8. 上线前的最后一公里安全、权限与薪资问题模型的不是人的这一部分讲的“安全”不是系统安全而是面试内容的安全——防止泄漏、防止作弊、防止模型说出不该说的话。8.1 题库的防泄漏设计2.2 万道题这个体量已经属于需要高度重视的知识资产。我做了几层防护题目不在前端一次性加载而是按需从服务端拉取。面试过程生成的题目、测试用例、参考答案全部加密存储。候选人端只能看到“当前题目”无法看到题库列表或下一题内容。同一道题目对同一候选人只出现一次。最让我头疼的是代码执行层的安全。候选人的代码是任意文本理论上可能包含恶意指令试图读取环境变量、反弹 shell 等。容器的隔离在这里只是第一步还需要对代码内容做静态扫描禁用明显的危险函数。这块没有完美的方案只能做到“多层防御”。8.2 模型输出的合规兜底面试官 Agent 在追问过程中偶尔也会说出一些不该说的话。尤其在我们测试当中有一次模型针对候选人的某个回答说了一句“这个思路在实践中很少见到”语气和人类面试官的质疑很像但缺乏解释容易让候选人产生被冒犯的感觉。后来我在系统提示词里加入了情绪管理规则模型在给出负面评价时必须先给证据再给建议最后才能评价。顺序不能乱。比如“一组测试用例显示输入为负数时输出不符合预期证据建议检查一下对负数边界的处理建议目前看下来这里还有提升空间评价。”这个规则写进系统提示词后候选人侧的满意度明显提升。8.3 评估结果的审计与人工复核上线之前我还做了一个纯粹流程上的决定AI 面试官的评估结果不能直接进入招聘决策必须先经过人工复核。系统生成评估报告后会标记出需要人工关注的点例如“候选人曾在第 3 题上多次尝试修正”供人类面试官快速浏览然后决定是否采纳。这个设计看起来“降低了效率”但它实际换来了业务方的信任。招聘决策关系到人的职业发展这个责任不仅是技术问题更是伦理问题。AI 面试官可以是一个高效的“预筛工具”但在最终决策环节人类必须保留判断权。9. 从面试官到技术平台Agent Harness 的更多可能回看这个项目我发现最有价值的并不是“做了一个 AI 面试官”这件事本身而是验证了 Agent Harness 这套方法论在各类垂直场景里的通用性。面试官只是其中一个载体。9.1 Harness 方法的可复制性“让模型做看结果而不是让模型说”这个理念我在其他场景里也反复验证过。比如技术方案评审让 AI 先写方案再用工具解析火柴人的可执行性基于验证结果继续迭代再比如在线编程教育的作业批改同样的证据链模式比纯人工批改效率高出几个量级。Harness 并不神秘它就是一个朴素的工程原则不要让模型在没有工具支持的情况下对事实下结论。这句话放到任何需要“评估真实世界结果”的场景都成立。9.2 与 Codex/Devin 类 Agent 的横向对比最近同行们都在讨论 Codex、Devin 这类编程 Agent 产品。它们在底层用的也是类似的 Harness 框架——代码执行沙箱、测试反馈、迭代循环。不同点在于它们的目标是生成产品级代码所以 Harness 复杂度更高多文件工程、依赖管理、Git 操作等而我们的面试官系统只需要关注单文件级别的代码验证。但两者有一个底层逻辑是完全一致的模型不是一个人它是一颗需要被工具“校准”的大脑。Agent 的进化方向不是让模型越来越“大”而是让模型周围的工具越来越“称手”。9.3 大模型 Agent 开发学习路线的建议如果你对 Agent Harness 感兴趣我的建议是从小的、具体的场景开始不要一上来就想做一个通用 Agent。先选定一个窄场景比如“自动判题”或者“自动代码评估”找一两个能配合你的工具把“模型调用工具→工具返回结果→模型基于结果继续行动”这个闭环跑通。这个闭环的体验和纯 Prompt 完全不同它会让你真正理解 Agent 和 Chatbot 的区别在哪里。然后再逐步加入状态管理、证据存储、记忆机制和策略控制。这些模块单独拆开都不难难的是把它们组合成一个稳定的系统。每一步都踩在真实数据的反馈上你会有一个比任何教程都深刻的体感。10. 最后聊一点个人体会Prompt 没变弱只是回到了它该有的位置在坚持一年多之后我越来越清楚地意识到我并不是在否定 Prompt 的价值——恰恰相反在 Harness 架构里Prompt 依然至关重要。一个糟糕的 Harness 配上一个精心调教的 Prompt效果远好于一个好的 Harness 配上一个随意书写的 Prompt。但与此同时Prompt 的边界也正在变得前所未有的清晰它能塑造模型的行为方式但不能替代系统的信息获取能力。面试官需要看到运行结果才能判断代码——这不是一句好的提示词能变出来的。工具、数据、执行链路、证据链这些才是决定一个 Agent 是“看起来智能”还是“真正可用”的分水岭。如果你也在思考“我的 Agent 应该怎么设计”我最真诚的建议是先把“模型会怎么回答”放一放多花时间想清楚“模型需要哪些客观信息才能做出可靠回答”。从这些信息的收集和注入入手去设计系统——比把希望都押在提示词上要靠谱得多。
AI面试官背后的Agent Harness架构：代码证据链与落地实践
1. 这个标题背后我为什么开始做 Agent Harness如果你在技术社区刷到“AI 面试官”这个说法大概率看到的演示都是这样的——把职位描述和几道题丢给一个大模型然后让它“扮演面试官”提问再对候选人的回答打个分。说实话这种东西我见过太多了从 2023 年到现在每隔一段时间就会冒出来一个类似的 Demo但真正能在企业内部跑起来的几乎没有。原因倒不在于大模型会不会提问。市面上主流模型扮演面试官提问的流畅度早就够了真正让这类 Demo 死掉的是另外三件事题库怎么管、代码怎么验、评估怎么让人信服。先说题库。我在这个项目里接手的是一个积累了多年的题库最后落到系统里的是 2.2 万道题覆盖算法、数据结构、系统设计、数据库、网络、操作系统等各个方向。问题在于这些题不是给 AI 准备的——它们原本是给人类面试官看的题干里带着各种隐含前提、上下文依赖、甚至内部约定俗成的简写。你直接把原题喂给大模型然后让它“根据这道题面试候选人”大概率会得到非常离谱的结果要么题目信息本身不足以让模型理解考核点要么模型自己脑补出了一套和原始评分标准完全对不上的判断逻辑。再说代码验证。这是最要命的一环。AI 面试官如果只是让候选人把代码贴在聊天框里然后让模型“看一眼”给出评价——这在算法题上还有一点可行性但对于涉及编译运行、依赖环境、输入输出格式、边界条件的题目纯粹靠视觉检查根本靠不住。模型读代码的能力再强它无法验证这段代码到底能不能跑通更无法获得运行时的真实反馈。你让面试官凭“感觉”判断候选人代码质量而不是基于测试用例的通过情况和执行轨迹这在技术决策上就是灾难。最后是评估可信度。面试官给出的每一个评价都得能追溯——这道题考核什么、候选人代码运行了什么测试用例、在哪里报错、报错信息是什么、候选人是经过多少次尝试才改对的、有没有借助提示才完成的。这些信息如果不完整面试评价就是空中楼阁。更现实的问题是如果 AI 面试官只是调用一次大模型接口基于一段对话记录给个分那用人部门凭什么相信这个分数候选人凭什么接受这个反馈HR 又怎么把这个结果归档进招聘流程所以我在做这个项目的时候从一开始就明确了一个判断绝对不能只靠 Prompt 堆砌出一个“貌似智能”的面试官必须有一个围绕 Agent 构建的执行框架Harness把工具调用、代码运行、证据采集、状态管理全部纳入可控管道。这篇文章我就想把这个判断背后的完整思考、架构设计和落地过程中的坑原原本本讲一遍。2. 纯 Prompt 方案的三个致命伤不只是“效果不好”在深入 Harness 架构之前先把纯 Prompt 方案为什么不行这件事说透。很多人以为 Prompt 面试官效果不好是提示词写得不够好于是不断调措辞、加 few-shot、优化 system message——这条路我走了差不多两个月最终得出结论问题根本不在提示词层面而在系统边界上。2.1 致命伤一题库内容与 Prompt 上下文之间的失配2.2 万道题的题库有一个很现实的特点题目本身的“可执行性”差异极大。有的题是完整的算法题题干、输入输出格式、示例全都有有的题却只是一段描述比如“请设计一个支持高并发的短链服务”——这种题是用来做系统设计讨论的没有标准答案得分点完全依赖面试官的追问方向和候选人应答的深度。当你试图把这些题塞进 Prompt 里让模型充当面试官时会遇到一个所有人都会撞上的墙上下文窗口有限而且很贵。你不可能把 2.2 万道题的完整题库、评分标准、追问策略全部塞进 system prompt——那不仅超出窗口限制还会严重稀释模型对当前这道题的注意力。实际的妥协方案只能是把当前这一道题和它对应的简单评分标准塞进上下文。可问题是题目本身的背景信息经常不足以支撑一场合格的面试。举个例子题库里有这样一道题SQL 题目题干写着“查询每个部门薪资最高的员工”。看起来很简单对吧但如果你了解这道题的历史就会知道它真正的考核点在于“窗口函数 vs 分组聚合两种写法的性能差异”以及“同薪资并列时怎么处理”。这些信息不在题干里而是沉淀在题库的附注和往期面试记录里。纯 Prompt 方案每次调用都只看到题干文本这些关键上下文完全丢失了。2.2 致命伤二模型“自说自话”的代码评估不具备可证伪性让模型直接读候选人代码然后打分表面上看很智能实际隐患巨大。大模型对代码的“感觉”是基于训练数据里的统计规律不是基于真实执行结果。它看过海量正确代码和错误代码所以能给出一个看似专业的判断——但这个判断没有任何运行时证据支撑。具体到面试场景这会造成三个问题模型可能被“看起来对”的代码迷惑。一段代码逻辑正确但语法上有细节错误比如少了一个冒号、变量名拼写不一致模型倾向于基于整体观感给高分而不是指出运行失败。模型无法区分“候选人自己调试通过”和“候选人贴了一段自己都看不懂的代码”。前者体现工程能力后者可能是背题或者抄的。没有运行轨迹这两种情况在文本层面几乎是不可区分的。模型可能产生幻觉编造不存在的错误。我实测过有时候模型面对一段完全正确的代码会“预测”在某些边界输入下可能出问题然后煞有介事地给出扣分理由——这在纯文本评估里是致命的因为候选人无法反驳面试官也无法验证。2.3 致命伤三多轮面试中的状态管理失控一场合格的面试不是单轮问答而是多轮交互出题 → 候选人作答 → 追问 → 候选人修改 → 再次评估。每一次追问都要基于上一轮的代码和回答这意味着你有一个逐步累积的“面试状态”需要维护。在纯 Prompt 方案里这个状态只能靠“把历史对话全部塞进上下文”来实现。但对话一长问题就来了上下文里的早期内容被截断越靠前的内容注意力权重越低模型对候选人一开始的表现记忆模糊追问质量急剧下降更麻烦的是候选人如果修改了代码模型对“第一版代码”和“最终版代码”之间的差异感知就变得很迟钝——它更像是看了一堆连续的文本而不是看到了一个代码文件的版本演化。我当时用纯 Prompt 跑了几十场模拟面试发现最典型的翻车场景是候选人在第五轮时修正了第三轮的 bug但 Prompt 面试官在最后总结时还拿着第三轮的旧问题扣分。这种事发生一次两次还可以解释为模型能力问题频繁出现就是架构问题了。这三个致命伤每一个都指向同一个结论面试官 Agent 需要外部化状态、外部化工具、外部化证据而不是把一切都压在大模型的单次推理上。这正是 Harness 架构的价值所在。3. Harness 的核心理念从“让模型说”到“让模型做看结果”“Harness”这个词在 AI Agent 领域有特定含义——它指的是为 Agent 提供运行环境和工具接口的那层“装置”有点类似于测试领域里的“测试夹具”。在代码生成 Agent比如 Codex、Devin 这类产品里Harness 通常指代码执行沙箱、测试运行器、文件系统接口和反馈回路的总和。我把这个概念引入 AI 面试官项目就是基于一个非常朴素的判断面试官 Agent 不应该只是一个“会说话的大脑”它应该是一个“能动手验证的完整系统”。它要能出题也要能编译运行候选人代码要能基于运行结果追问还要能把整个过程中的关键证据结构化留存。3.1 从“大脑”到“大脑手眼”的架构转变纯 Prompt 方案里大模型干所有事理解题目、生成提问、读代码、给评价。这是一个典型的“大脑”模型不接触任何外部工具。它的信息全部来自文本输入输出也全部是文本。这种架构的好处是简单坏处是评估质量完全依赖模型“脑补”。Harness 方案的思路是把“大脑”之外的部分全部拆出去让模型通过工具调用去操作外部系统再把操作结果作为新的上下文输入。具体到我的设计里拆成了五层会话管理层维护面试状态、当前题目、历史交互记录、候选人画像。模型不直接持有完整历史而是通过检索接口按需读取。题库服务层支撑 2.2 万道题的检索、筛选、题目分组和题面渲染。代码执行层运行候选人提交的代码执行预设的测试用例采集 stdout、stderr、返回值、运行耗时、内存占用等元数据。证据存储层把代码快照、测试结果、执行日志、模型评估中间结果全部落库形成不可篡改的证据链。策略控制层决定面试官 Agent 何时出题、何时追问、何时结束面试、如何计算评分。这是 Prompt 无法简单承载的“流程逻辑”。在这个架构下大模型的角色反而变“小”了——它不再负责所有事而是专注于两件事根据当前状态生成下一步话术以及基于工具返回的证据给出评估判断。这两件事恰恰是语言模型最擅长且最可靠的。3.2 为什么是“证据链”而不是“推理过程”我在项目文档里坚持用“证据链”这个词而不是“推理过程”是因为两者本质不同。模型给出评估结论时内部可能经过复杂的推理attention 计算、概率采样等这个内部推理是不可控、不可解释的。但 Harness 里记录的证据是不同的——它是客观事实候选人写了什么代码、测试通过了几个、失败的那个用例输入是什么、编译报错发生在第几行。证据链的本质是把模型的主观判断锚定到客观事实上。模型可以说“该候选人对边界条件的处理不充分得分为 3/5。”这句评价如果没有证据支撑跟没说一样。但如果模型说的是“该候选人的代码在测试用例[-2, -1, 0, 1, 2]上得到错误输出0说明对负整数前缀的处理存在缺陷得分为 3/5。”——这个评价就完全不一样了它有可追溯的锚点用人部门可以复核候选人也可以理解。要做到这一点Prompt 里就不能只用自然语言提要求必须在 Harness 层面强制工具返回结构化数据并把结构化数据按照可以引用的格式注入模型上下文。这条“工具返回→结构化存储→按需注入上下文→模型引用输出”的链路就是我说的“代码证据链”的实体形态。3.3 Harness 与 Prompt 的边界划分很多同行问我说你做了 Harness那 Prompt 还需要吗当然需要但它的角色变了。在 Harness 架构里Prompt 不再是唯一的智能来源而是负责“调度模型在正确的时间做正确的事”。我的做法是把 Prompt 拆成四种系统提示词System Prompt定义面试官的基本人格、语言风格、行为边界避免模型说出不当言论。工具定义提示词Tool Definition Prompt告诉模型当前有哪些工具可用、每个工具的输入输出 schema、什么情况下该调用哪个工具。上下文注入提示词Context Injection Prompt由 Harness 动态生成包含当前面试状态、候选人信息、当前题目、最新代码快照、测试结果等结构化数据。动作策略提示词Action Policy Prompt定义模型“下一步做什么”的规则比如什么情况下追问、什么情况下切换到系统设计题、什么情况下结束面试。这套拆分看起来很简单但它解决了一个非常实际的问题大模型每轮只接收恰好足够的信息不会因为上下文过长而迷失。模型不需要记住 2.2 万道题它只需要知道“当前这道题是什么、考核点是什么、候选人刚写出来的代码表现如何”。至于题目怎么选、下一题是什么那是 Harness 的策略层决定的不归模型管。4. 2.2 万题库的工程化重建从“给人看”到“给系统用”题库是整个 AI 面试官的核心资产。2.2 万这个数字看着不少但真正用起来的时候会发现题库的质量远比数量重要。在把题库接进系统之前我花了大半个月做数据治理这个过程远比写 Agent 代码痛苦得多。4.1 题目标签体系的重新设计原始题库的标签体系是给人看的有题目类型算法、数据库、系统设计等、难度等级、题目来源等字段。但 AI 面试官需要的信息粒度要细得多。我给每道题增加了下面这层“机器可读”的元数据考核点列表这道题想要验证的具体能力项例如“递归终止条件设置”“索引使用合理性”“并发下的线程安全”。考核点是面试官追问的主要依据。前置知识依赖候选人答这道题之前应该掌握的知识点。用于面试官动态调整追问深度——如果候选人连前置知识都不懂就不必深入太难的方向。代码模板针对编程题提供一个标准化的初始代码框架确保候选人的代码可以被自动编译和测试。没有模板的题自动判题根本无法落地。测试用例集针对算法题设计多组测试用例从基础正确性到边界条件到性能压测全部配好输入输出。禁用提示哪些信息不能由面试官主动透露给候选人。这在纯 Prompt 方案里总是被忽略但在真实面试里是底线问题。这个重新设计的工作量非常大。2.2 万道题里真正能直接接入自动判题的算法题大概只有 4000 道左右剩下的要么缺测试用例要么题目描述不完整要么强依赖人类面试官的主观判断。我的做法是分优先级处理先把 4000 道算法题完整补齐元数据跑通 MVP再逐步扩展到其他题型。4.2 基于难度与知识点的动态抽题策略题库准备好了接下来就是面试官如何选题目。我的 Harness 里实现了一个抽题策略模块核心逻辑是根据候选人的目标职位如“高级后端工程师”确定题型分布权重。根据面试阶段基础筛选、深入考察、综合评估确定难度区间。从题库中随机抽取候选题目但加入“互斥条件”保证同一场面试不出现知识点重叠过多的题。抽出来的题通过 Harness 注入模型上下文同时附上考核点列表和禁用提示。这套策略实现了“既随机又可控”的平衡。如果完全随机可能出现三套全是动态规划的惨剧如果完全不随机题库的利用率又太低。抽题算法本身不难但如果没有 Harness 的支撑抽题逻辑和模型对话就完全是两套系统需要人工拼装效率极低。4.3 题库分类与代码执行引擎的对接细节在实际对接中有一个细节特别值得提算法题不是只有一种语言。题库里同一道题候选人可能用 Python、Java、C、Go 来作答。这意味着代码执行层必须要有多语言运行环境。我在这个项目里用了容器化方案每种语言一个基础镜像候选人代码提交后在容器内编译运行执行完销毁容器。隔离性、资源限制、超时控制全部由容器编排层统一处理。测试用例的执行结果也分了好几个层级编译/解释阶段代码能不能通过语法检查。失败则记录编译器报错。基础用例阶段少数几个公开示例用例用于快速反馈“你的代码是不是完全跑不通”。完整用例阶段覆盖各种边界条件的完整测试集用例对候选人不可见。性能压测阶段大数据量输入下的耗时和内存表现。这种分层设计有一个好处如果候选人在基础用例就失败了系统可以直接提示“请先确保代码能正确运行”并给编译错误信息如果基础用例全过但完整用例挂了系统给出的反馈可以集中在隐藏用例上例如“程序在包含负整数的数组中输出不正确”。这些反馈既是给候选人的提示也是给模型的追问素材。5. 代码证据链的落地实现评估不靠感觉靠事实这一部分是整个项目的核心也是我觉得最值得分享的一段。“代码证据链”不能停留在概念层面必须落到数据结构、存储方案和模型交互协议上。5.1 运行证据如何被收集、结构化和存储我把证据分为三个层次。第一层是原始证据直接来自代码执行的结果stdout 输出、stderr 错误流、退出码、执行耗时、内存峰值、编译器/解释器版本信息。这一层数据是最客观的不经过任何模型加工。第二层是结构化证据由 Harness 根据原始证据加工而成针对每个测试用例标记“通过”还是“失败”如果失败则截取期望输出与实际输出的差异片段针对编译失败的情况标记出错的代码行号和错误类型。这一层是“人可读、模型可用”的关键。第三层是评估证据来自模型的输出模型基于前两层证据给出的评分、扣分理由、追问建议。这一层是主观的但它的锚点全部指向第二层的结构化证据。存储方案上我用了一张主表记录每次代码提交每一条提交关联多张子表测试用例结果表、编译日志表、代码快照表、模型评估表。每个字段都有时间戳确保整个证据链可以被完整回溯。我甚至保留了每一次代码提交的原始内容——这在面试复盘时特别有用可以看到候选人的调试过程是“稳步前进”还是“反复横跳”。5.2 模型上下文中的证据注入与引用格式证据收集好了还得让模型“会用”。这里存在一个很微妙的工程问题模型上下文空间有限不可能把所有测试用例的执行结果全部塞进去。所以 Harness 要做“证据摘要”和“按需注入”两件大事。证据摘要的逻辑是对于通过的测试用例只保留“通过 N/M 组”对于失败的用例完整保留输入、期望输出、实际输出、报错信息最多取前三条失败用例。这样既保证了模型能了解到代码的整体表现又避免细节爆炸。按需注入的逻辑是第一轮评估时只给模型看到基础用例执行结果如果基础用例全过再进入完整用例评估阶段时把隐藏用例的失败信息注入。这种分阶段注入可以让模型先判断“代码的骨架对不对”再深入判断“边界情况有没有处理好”评估颗粒度更清晰。在 Prompt 的上下文注入格式上我设计了一种纯文本但结构化的格式[Test Result] Passed: 5/8 Failed:[ {case: input[-1,2,-3,4], expected: 6, actual: 3, error: null}, {case: input[1,-2,1], expected: 2, actual: 4, error: out of range}, ] Compile: success | failed at line 12: unexpected token ;这种格式的优势在于完全不用 JSON 也能被模型稳定解析而且人类面试官一眼也能看懂。Prompt 不是越花哨越好关键是信息密度和可解析性。5.3 多轮面试中的代码差异追踪前面的证据链都是针对“单次代码提交”的。但真实面试里候选人会根据面试官反馈修改代码这时候 Harness 需要额外记录代码版本差异。我的做法是在每次提交时计算一个 diff并把 diff 的语义摘要不是原始代码文本注入模型上下文。比如Revision 1: initial submission, passed basic cases 3/3 Revision 2: added negative-number handling, passed basic 3/3, hidden 5/8 Revision 2 diff: added if (num 0) return 0; before main loop这样模型不仅能评估“当前代码好不好”还能评估“候选人有没有针对反馈做出有效改进”。这个维度在纯 Prompt 方案里几乎无法实现但在 Harness 里只是几十行代码的事。证据链的最终价值在于面试官给出的每一个结论都可以被回溯到一条具体证据上。这不是为了“追责”而是为了让评估过程可监督、可改进——当面试结果和候选人入职后的实际表现出现偏差时能快速找到是题目、是模型判断、还是证据收集哪个环节出了问题。6. 实际落地中的四个高频坑用踩坑经历换来的经验任何项目做得再细致落地过程中也会遇到各种意想不到的问题。这一部分我整理四个最典型的高频坑都来自我的真实经历希望对正在做 Agent 类项目的同行有帮助。6.1 模型上下文爆炸不是所有历史都要保留这是我遇到的第一个大坑。最初的设计里为了确保模型不“失忆”我把面试中每一轮对话和每一次代码提交都拼进上下文。结果模型到了第五六轮之后明显开始“发呆”——提问质量下降甚至开始重复已经问过的问题。后来我意识到模型不需要记住每一轮细节它对面试的“理解”应该由 Harness 维护而不是靠上下文硬扛。我的改造方案是维护一个“面试摘要”对象每次交互结束后Harness 让模型输出一句话摘要当前候选人表现的核心特征、已覆盖的考核点、待考察的方向作为下一轮的 Context 基础。历史对话全文存数据库但模型看不到只在需要时按需检索。这一改上下文长度从无限膨胀变成了稳定的 4-6K token 左右模型表现立刻稳定下来。6.2 执行环境的不确定性容器镜像版本一致性代码执行环境最大的隐患是镜像更新导致的“意外挂科”。有一次我们把 Python 镜像从 3.10 升级到 3.11结果大量基础用例突然失败——原因是 3.11 里正则表达式模块的一个默认行为改了。这个坑特别隐蔽因为问题不在代码本身而在执行环境版本漂移。解决方案也很朴素每个基础镜像打上固定的版本 tag并且代码执行层启动前校验镜像 hash。测试用例和镜像版本之间建立对应关系保证同一道题的执行环境永远可重复。这件事在面试场景里特别重要——否则会出现“同一个代码昨天能过、今天不能过”的荒唐事。6.3 模型的“脑补式补全”没有数据时硬要回答我承认这是我在 Prompt 和 Harness 设计上的双重锅。早期我让模型直接基于代码文本评估它经常在测试用例结果缺失的情况下自己“脑补”一套测试结果出来——比如“该代码通过所有测试用例”这种话。后来我把“测试结果缺失”作为一个显式状态注入 Prompt并在系统提示里写死规则“如果没有测试执行结果不得对代码正确性做出任何断言。只能描述代码结构与潜在风险。”人类面试官实际上也是这样做的——没有跑过的代码你不确定它就一定对。模型也是一样需要被 Harness“约束”住不能让它被训练时的统计先验带偏。6.4 异步任务与超时不是所有代码都能 3 秒跑完有些系统设计题会要求候选人写模拟代码比如并发压测脚本、一个大文件处理流程。这类代码运行时间可能远超普通算法题。如果执行层统一设定 3 秒超时这些题基本没法跑。我的方案是给测试用例配置不同的执行模式秒级模式普通算法题超时 2 秒。长跑模式偏工程实现的题超时 30 秒。手动模式系统设计讨论中的代码不自动执行只做静态评估。这个配置不但缓解了资源占用问题也避免了“因为题目类型不匹配导致代码被误判”的低级错误。有个小经验执行超时时间宁可宽一点也不要卡太死。面试场景不是比赛场景候选人本来就紧张代码写完后3 秒超时和 10 秒超时的体验差别很大。但超时之后的反馈文案要精心设计不要直接说“您的代码超时了”换成“代码运行时间过长请检查是否有死循环或过度嵌套”对候选人更友好。7. 分布式题库与评估一致性从 2.2 万题到千人千面的挑战当题库量级到了一定的规模另一个深水区就会出现——评估一致性。同一道题候选人 A 和候选人 B 都写对了但代码风格差异巨大模型会不会给不同分同一个候选人在不同时间面试同一道题评估结果会不会漂移这些都是“AI 面试官”能不能被业务部门接受的关键。7.1 评估一致性的两条防线第一条防线是结构化评分标准。每道题关联的考核点列表就是评分的依据。模型输出评分时Harness 强制它按考核点分项打分而不是给一个笼统的总分。比如一道题有四个考核点逻辑正确、边界处理、代码规范、性能考量模型必须针对每个考核点输出分数和理由证据链里的测试结果也要映射到对应的考核点上。这样最多保证模型在同一维度上做判断不会今天说边界处理是问题、明天说边界处理没问题。第二条防线是重复校准。我定期从题库里抽样一批题目用同一套测试数据和代码提交让模型在不同时间跑评估对比评分分布的漂移幅度。如果发现某道题的评分方差过大就检查是不是题目元数据不足或者测试用例有歧义。校准不是一次性的——大模型的行为会随版本迭代变化每次模型升级后都必须重新校准。7.2 千人千面AI 面试官要能“因材施教”面试里面很重要的一点是“因人而异”。同样一道题如果候选人答得很快且完全正确面试官应该加大难度追问如果候选人在基础环节已经卡住了就不应该继续加深难度。这和“千人一面”的考试系统不同Harness 需要动态感知候选人水平并调整面试路径。我的实现思路是在 Harness 里维护一个“候选人能力画像”对象包含技能维度上的分数比如“递归”7 分、“动态规划”5 分、“SQL 索引”8 分。每答完一题画像分数更新一次下一题的抽题策略基于画像调整。这个画像不直接暴露给模型但模型可以通过上下文注入感知“当前候选人擅长什么、不擅长什么”从而调整追问策略。这一步让 AI 面试官从“答题机”变成了“真正的面试官”——它会根据候选人的实时反馈调整方向。也是我觉得这个项目最有价值的部分。7.3 题库的持续进化和闭环优化Harness 架构还有一个额外红利每次面试都会产生新的真实数据反过来可以优化题库和评分标准。我在证据链里记录了大量“模型认为候选人该得的分”和“后续真实面试官复核后的分”两者之间的差异就是题库和模型需要优化的方向。比如有一道系统设计题模型总是给偏高分但人工复核发现候选人遗漏了缓存层设计。原因很快定位到题目元数据里没有把“缓存设计”设为考核点所以模型评估时没把它当作关键项。修正方式是补充考核点、调整测试用例、刷新模型参考评估然后继续跑校准。这就是为什么我说 Harness 不只是一个“执行框架”它是一个可以持续学习和进化的系统。数据在系统里流动反馈进系统里沉淀偏差不断被校正。8. 上线前的最后一公里安全、权限与薪资问题模型的不是人的这一部分讲的“安全”不是系统安全而是面试内容的安全——防止泄漏、防止作弊、防止模型说出不该说的话。8.1 题库的防泄漏设计2.2 万道题这个体量已经属于需要高度重视的知识资产。我做了几层防护题目不在前端一次性加载而是按需从服务端拉取。面试过程生成的题目、测试用例、参考答案全部加密存储。候选人端只能看到“当前题目”无法看到题库列表或下一题内容。同一道题目对同一候选人只出现一次。最让我头疼的是代码执行层的安全。候选人的代码是任意文本理论上可能包含恶意指令试图读取环境变量、反弹 shell 等。容器的隔离在这里只是第一步还需要对代码内容做静态扫描禁用明显的危险函数。这块没有完美的方案只能做到“多层防御”。8.2 模型输出的合规兜底面试官 Agent 在追问过程中偶尔也会说出一些不该说的话。尤其在我们测试当中有一次模型针对候选人的某个回答说了一句“这个思路在实践中很少见到”语气和人类面试官的质疑很像但缺乏解释容易让候选人产生被冒犯的感觉。后来我在系统提示词里加入了情绪管理规则模型在给出负面评价时必须先给证据再给建议最后才能评价。顺序不能乱。比如“一组测试用例显示输入为负数时输出不符合预期证据建议检查一下对负数边界的处理建议目前看下来这里还有提升空间评价。”这个规则写进系统提示词后候选人侧的满意度明显提升。8.3 评估结果的审计与人工复核上线之前我还做了一个纯粹流程上的决定AI 面试官的评估结果不能直接进入招聘决策必须先经过人工复核。系统生成评估报告后会标记出需要人工关注的点例如“候选人曾在第 3 题上多次尝试修正”供人类面试官快速浏览然后决定是否采纳。这个设计看起来“降低了效率”但它实际换来了业务方的信任。招聘决策关系到人的职业发展这个责任不仅是技术问题更是伦理问题。AI 面试官可以是一个高效的“预筛工具”但在最终决策环节人类必须保留判断权。9. 从面试官到技术平台Agent Harness 的更多可能回看这个项目我发现最有价值的并不是“做了一个 AI 面试官”这件事本身而是验证了 Agent Harness 这套方法论在各类垂直场景里的通用性。面试官只是其中一个载体。9.1 Harness 方法的可复制性“让模型做看结果而不是让模型说”这个理念我在其他场景里也反复验证过。比如技术方案评审让 AI 先写方案再用工具解析火柴人的可执行性基于验证结果继续迭代再比如在线编程教育的作业批改同样的证据链模式比纯人工批改效率高出几个量级。Harness 并不神秘它就是一个朴素的工程原则不要让模型在没有工具支持的情况下对事实下结论。这句话放到任何需要“评估真实世界结果”的场景都成立。9.2 与 Codex/Devin 类 Agent 的横向对比最近同行们都在讨论 Codex、Devin 这类编程 Agent 产品。它们在底层用的也是类似的 Harness 框架——代码执行沙箱、测试反馈、迭代循环。不同点在于它们的目标是生成产品级代码所以 Harness 复杂度更高多文件工程、依赖管理、Git 操作等而我们的面试官系统只需要关注单文件级别的代码验证。但两者有一个底层逻辑是完全一致的模型不是一个人它是一颗需要被工具“校准”的大脑。Agent 的进化方向不是让模型越来越“大”而是让模型周围的工具越来越“称手”。9.3 大模型 Agent 开发学习路线的建议如果你对 Agent Harness 感兴趣我的建议是从小的、具体的场景开始不要一上来就想做一个通用 Agent。先选定一个窄场景比如“自动判题”或者“自动代码评估”找一两个能配合你的工具把“模型调用工具→工具返回结果→模型基于结果继续行动”这个闭环跑通。这个闭环的体验和纯 Prompt 完全不同它会让你真正理解 Agent 和 Chatbot 的区别在哪里。然后再逐步加入状态管理、证据存储、记忆机制和策略控制。这些模块单独拆开都不难难的是把它们组合成一个稳定的系统。每一步都踩在真实数据的反馈上你会有一个比任何教程都深刻的体感。10. 最后聊一点个人体会Prompt 没变弱只是回到了它该有的位置在坚持一年多之后我越来越清楚地意识到我并不是在否定 Prompt 的价值——恰恰相反在 Harness 架构里Prompt 依然至关重要。一个糟糕的 Harness 配上一个精心调教的 Prompt效果远好于一个好的 Harness 配上一个随意书写的 Prompt。但与此同时Prompt 的边界也正在变得前所未有的清晰它能塑造模型的行为方式但不能替代系统的信息获取能力。面试官需要看到运行结果才能判断代码——这不是一句好的提示词能变出来的。工具、数据、执行链路、证据链这些才是决定一个 Agent 是“看起来智能”还是“真正可用”的分水岭。如果你也在思考“我的 Agent 应该怎么设计”我最真诚的建议是先把“模型会怎么回答”放一放多花时间想清楚“模型需要哪些客观信息才能做出可靠回答”。从这些信息的收集和注入入手去设计系统——比把希望都押在提示词上要靠谱得多。