DeepSeek Harness来了，测试开发面试该怎么准备？

2026年8月13日晚，DeepSeek正式发布了其首款开源Agent产品——DeepSeek Harness（简称dsh）。这款产品采用MIT许可证开源，上线约42小时便突破10万Star，目前已达15万星以上。更值得关注的是，DeepSeek为Harness设定的终极目标是打造Self-Evolving Agent Harness——即Agent能够在运行过程中自主编写和安装插件。当测试对象开始具备“自进化”能力时，传统的测试方法论正面临前所未有的挑战。作为测试开发从业者，我们需要重新思考：如何为这类新型系统设计测试方案？本文整理了10道针对性面试题，涵盖概念理解、原理分析、架构设计和风险意识等多个维度。

概述

第一道题考察技术敏感度：能否用一分钟介绍DeepSeek Harness？这道题看似简单，实则考验候选人是否真正关注行业动态。DeepSeek Harness的核心设计理念是“一切皆插件”：Model Adapter、Tool Registry、Session Log、Agent Loop等核心部件全部可插拔、可替换、可检查，底层由Cordis插件治理框架驱动。值得注意的是，官方已明确声明当前为developer preview阶段，后续可能会有破坏性变更。如果候选人能补充这一点，说明他确实深入阅读过项目文档，而非泛泛了解。

Agent运行原理与核心机制

理解Agent Loop是掌握Agent系统的关键。Agent Loop本质上是“思考—调用工具—观察结果—再思考”的迭代过程，直到满足终止条件。它与传统聊天机器人的本质区别在于：模型不仅给出答案，还会采取行动，并根据反馈修正自己的策略。绝大多数Agent异常——如循环打转、输出跑偏、成本失控——都可以追溯到Agent Loop的问题，这使得它成为面试中的高频考点。 另一个重要概念是Revertible Effects（可撤销效应）。DeepSeek Harness要求对上下文的每次修改都记录“反向方法”，卸载时按相反顺序撤销。这一机制被业界形象地称为给AGI自进化发的“后悔药”。在Agent开始自己写插件、修改系统的场景下，犯错是常态，“能回滚”就是最后一道安全底线。测试人员需要验证：反向方法是否完备？撤销顺序是否正确？连续多次修改后系统能否干净还原？

非确定性输出的测试策略

AI输出具有天然的不可确定性，这给测试工作带来了根本性挑战。传统测试中的“断言精确值”思路已不再适用，我们需要转向“断言性质”。以下是四种常用策略： 一是多次运行看分布，通过统计通过率代替单次成败；二是结构断言，只校验输出格式、必填字段和关键词是否正确；三是建立Golden Set，用精选的代表性用例作为测试基线；四是采用LLM-as-Judge辅助打分，但需注意裁判模型本身要先进行校准。 当AI生成测试用例时，评估质量需要分三层漏斗：首先验证“能不能跑”——语法是否合法、能否真实执行；其次判断“对不对”——断言是否真正针对业务规则，而非只调用接口却无任何校验；最后评估“有没有价值”——看覆盖增量、变异测试的杀伤率，以及能否发现新的缺陷。必须警惕“用例数量多等于质量好”的误区，AI特别擅长生成看似正确、实际永远通过的无效用例。

插件系统的测试设计

为DeepSeek Harness这类插件系统设计回归测试，需要构建三层测试体系。第一层是插件契约测试，验证每个插件的输入输出格式与约束边界是否正确；第二层是组合兼容矩阵，测试不同版本插件两两组合后的行为是否符合预期；第三层是装载与卸载后的集成冒烟，确保核心功能不受影响。 特别值得关注的是Reactive Coeffects机制——组件声明所需能力后，当能力出现或消失时系统会自动重算依赖关系。这种“重算”行为本身值得专门设计测试用例：卸载插件A后，依赖它的插件B是优雅降级还是直接崩溃？系统能否正确处理依赖关系的变化？ 对于已知的稳定性短板，如响应偏慢、复杂长任务稳定性不足、偶发循环打转、API成本随任务长度增加等问题，测试策略应包括：将时间预算和轮次预算纳入测试约束；对“打转”行为设置特征检测——连续出现相同或相似的工具调用时触发告警；建立任务长度与Token成本的曲线关系，把成本作为回归指标持续监控。

如有侵权，请联系删除。