上周给团队做模拟面试，我问了一道题："怎么测一个会自己改自己的系统？"现场安静了三秒。这道题不是凭空编的。2026年8月13日晚，DeepSeek 发布了首款开源 Agent 产品 DeepSeek Harness（简称 dsh），MIT 许可证，上线约 42 小时破 10 万星，目前已超 15 万星。更关键的是，它的终极目标是 Self-Evolving Agent Harness——Agent 在运行中自己编写、安装插件。当测试对象开始"自进化"，面试题迟早跟上。我整理了 10 道题，每题附考察点和参考回答思路，可以直接背诵复用。

概念题
Q1：用一分钟介绍一下 DeepSeek Harness？
考察点：技术敏感度，是否跟进行业动态。

参考回答思路：它是 DeepSeek 在 2026 年 8 月 13 日发布的首款开源 Agent 产品，MIT 许可证。设计理念是"一切皆插件"：Model Adapter、Tool Registry、Session Log、Agent Loop 全部可插拔、可替换、可检查，底层由 Cordis 插件治理框架驱动。它标志着 DeepSeek 从"造模型"走向"造 Agent 产品"。加分项：补一句官方明确警告当前是 developer preview，会有破坏性变更——说明你真的读过 README。

Q2：什么是 Agent Loop？
考察点：对 Agent 运行原理的理解，而不是背名词。

参考回答思路：Agent 循环就是"思考—调用工具—观察结果—再思考"的迭代过程，直到满足终止条件。它和聊天机器人最本质的区别在于：模型不只给答案，还会采取行动，并根据反馈修正自己。

简化示意：Agent Loop 的骨架（非 dsh 源码）

while not done and step < MAX_STEPS:
action = llm.decide(context) # 思考：模型决定下一步动作
observation = execute_tool(action) # 行动：执行工具调用
context.append(observation) # 观察：结果写回上下文
done = action.type == "final_answer" # 终止：模型判断任务完成
绝大多数 Agent 异常——打转、跑偏、成本失控——都能追溯到这个循环出了问题，这也是它成为面试高频点的原因。

Q3：怎么理解"一切皆插件"？
考察点：架构理解，以及能否看出设计对测试的意义。

参考回答思路：在 dsh 里，模型适配、工具注册、会话日志、Agent Loop 这些核心部件都被当作可插拔组件，统一由 Cordis 框架治理，对应论文提出"时空可组合性"。对测试的红利有两层：其一，凡是可插拔的，就能单独替换、单独验证，天然适合组件级测试和故障注入；其二，"可检查"意味着内部状态可观测，正好缓解 Agent 测试最头疼的黑盒问题。

Q4：Revertible Effects 为什么重要？
考察点：关键机制的理解，能否和质量挂钩。

参考回答思路：它要求对上下文的每次修改都留下一个"反向方法"，卸载时按相反顺序撤销，媒体称之为给 AGI 自进化发的"后悔药"。重要性在于：当 Agent 开始自己写插件、改自己，犯错是常态，"能回滚"就是最后一道安全兜底。再往前说一步会更出彩：回滚本身也要测——反向方法是否完备、撤销顺序是否正确、连续多次修改后能否干净还原。

实践题
Q5：AI 输出是非确定性的，怎么测？
考察点：AI 测试的核心方法论，近期最高频的新题型。

参考回答思路：放弃"断言精确值"，转向"断言性质"。四个常用手段：一是多次运行看分布，用统计通过率代替单次成败；二是结构断言，只校验格式、必填字段、关键词；三是 golden set 对比，用精选的代表性用例当基线；四是 LLM-as-Judge 辅助打分，但裁判模型本身要先校准。

简化示意：对非确定性输出做统计断言

def test_agent_answer(runagent, judge, runs=10, threshold=0.8):
passed = sum(
1 for in range(runs)
if judge(run_agent("如何对 Python 列表排序？"))
)
assert passed / runs >= threshold, "多次运行通过率不达标"
Q6：AI 生成了一批测试用例，你如何评估它们？
考察点：对 AI 产物的质量验收能力。

参考回答思路：分三层漏斗。第一层"能不能跑"：语法合法、可真实执行；第二层"对不对"：断言是否真的针对业务规则，而不是只调了接口、没做任何校验；第三层"有没有价值"：看覆盖增量、变异测试的杀伤率、能否发现新缺陷。一定要警惕"用例数量多＝质量好"的错觉，AI 特别擅长生成看似正确、实际永远通过的废用例。

Q7：给 dsh 这样的插件系统设计回归测试，你怎么做？
考察点：测试设计能力，能否把概念落地。

参考回答思路：三层。第一层，插件契约测试：每个插件的输入输出格式与约束边界；第二层，组合兼容矩阵：插件版本两两组合后的行为；第三层，装载与卸载后的集成冒烟。特别要提 Reactive Coeffects 机制——组件声明所需能力，能力出现或消失时系统自动重算依赖，"重算"本身就值得专门设计用例：卸载插件 A 后，依赖它的插件 B 是优雅降级还是直接崩溃？

Q8：dsh 已知有稳定性短板，你会怎么测？
考察点：面对真实产品短板的测试策略。

参考回答思路：社区实测的短板是响应偏慢、复杂长任务稳定性不足、偶发循环打转、API 成本随任务长度放大。我的做法：把时间预算和轮次预算纳入测试约束；对"打转"设行为特征检测——连续出现相同或相似的工具调用就告警；建立任务长度与 token 成本的曲线，把成本当回归指标盯。另外官方警告会有破坏性变更，每次升级本身就是一次回归风险，需要锁定版本做基线。

开放题
Q9：Agent 自进化会带来哪些新的质量风险？
考察点：风险意识与辩证思维。

参考回答思路：至少三层。一是行为漂移：Agent 装了自己写的插件后，旧用例上的行为变了，回归基线失效；二是错误传染：一个错误插件被后续任务复用，错误被放大且难以定位源头；三是审计困难：系统状态是运行时历史的中间产物，缺陷复现成本陡增。应对手段是版本快照、行为基线、回滚验证三件套。最后补一句辩证观点会更稳：也有人质疑软件自进化可能是伪命题，只会带来更大混乱——我认为这种谨慎是合理的，越要自进化，越离不开可回滚与可审计。

Q10：如果让你从零搭建 Agent 产品的评估体系，怎么设计？
考察点：体系化设计能力，压轴综合题。

参考回答思路：四步。第一步，建 golden set：收集代表性任务和预期性质，宁精勿滥；第二步，建可复现的执行环境：沙箱隔离、环境快照，保证每次评估条件一致；第三步，多维评分：任务完成率、步骤数、token 成本、安全性（有无越权操作）；第四步，看板与门禁：指标回退即阻断发布。核心观点一句话：对非确定性系统，评估环境的可复现性优先于一切，否则任何结论都不可信。

写在最后
这 10 道题从概念到开放层层递进，参考答案给的是思路而非标准话术，实际作答时建议结合自己的项目经历补充细节。dsh 的爆火释放了一个清晰信号：测试对象正在从静态代码走向会自我演化的系统，面试题只是最先变化的那一环。

本文整理自霍格沃兹测试开发学社的原创分享，更多测试开发与 AI 测试实战内容，我们下一篇见。