传音控股测试开发一面：定时任务用例设计与 Agent 记忆测试

《面试题目》

1. 自我介绍。
2. 介绍下实习做的测开工作？
3. 定时任务这个功能，自动化怎么设计测试用例？
4. Agent 记忆功能怎么测试？主动记忆、自动记忆分别怎么测？自动记忆触发条件是什么？
5. 沙Subagent隔离环境怎么测试？工具、Prompt 继承逻辑？
6. Playwright 如何实现 VSCode 插件自动化，CDP 协议在这里起什么作用？
7. 讲一讲 React，解决什么问题？
8. Workflow 工作流和大模型主控模式的区别？
9. Skill 技能模块如何做测试，模型评测怎么做？SW-Bench、LoCoM 评测集了解吗？
10. 成熟框架 vs 自研脚手架怎么权衡？
11. Agent Harness 是什么？
12. 反问。

《参考解析》

定时任务的自动化测试用例怎么设计

定时任务与普通接口的差别在「触发不由你控制」，所以要先把触发方式变成可测的：把调度层与业务逻辑层分开，业务逻辑暴露成可被直接调用的函数，测试只针对它；调度层用假时钟或手动触发接口来验证 cron 表达式与调度策略。用例设计按维度展开：时间维度（正常触发点、跨天跨月跨年、闰年与夏令时、时区、错过触发点后的补跑与幂等）、数据维度（空数据、单条、批量、脏数据、重复数据）、执行维度（首次执行、重跑、执行中被打断后续跑、执行超时、并发多实例抢占同一任务）。断言要落在三处：任务是否按预期次数触发、业务数据是否只被处理一次（幂等）、失败后是否按策略重试并告警。稳定性上还要覆盖「多个实例同时到达触发点」的分布式场景，验证锁或选主机制能保证只跑一次。

Agent 记忆功能怎么测

先把记忆拆成两类分别定判据。主动记忆是用户显式要求「记住这件事」，判据是写入时机、存储内容、召回时机和可见性：测「说了记住」是否真的落库、下一轮是否带进上下文、用户要求遗忘或更正后旧记忆是否失效、跨会话是否生效、有没有把敏感信息存进不该存的地方。自动记忆是模型自行抽取，难在触发条件不确定，所以要用「可观测的中间产物」来测：把抽取决策、候选记忆、写库记录都打进日志，用固定数据集构造正负样本——该记的（稳定偏好、长期事实、任务约束）有没有漏记，不该记的（一次性指令、闲聊、含隐私的信息）有没有误记，并检查记忆冲突时以谁为准、记忆过多时是否污染上下文导致答非所问。评测既要有端到端用例（连续多轮对话后追问旧信息），也要有单元级断言（抽取结果与期望集合比对），再配上回归集防改动打坏。

Subagent 隔离环境与工具、Prompt 继承逻辑

隔离测试的核心是证明「子 Agent 拿不到它不该拿的东西，也丢不掉它必须有的东西」。工具侧要验证继承范围：工具不是全量继承父 Agent，而是按需授权——测越权（父有、子不该有的工具能否调用）、测缺失（子应该有的工具是否可用）、测参数与凭据边界（子进程是否带着父的凭证或工作目录逃逸）。Prompt 侧是 fork 语义：一部分直接复用父的指令与约束，一部分需要针对子任务总结裁剪——测约束是否传递（安全规则、输出格式在子 Agent 里是否仍然生效）、测上下文是否被正确摘要（关键前提没被截掉）、测多级嵌套下是否继续收敛。验证手段就是作者说的那条：打开后台 trace 链路日志，按调用序列核对认证流程、工具调用行为、权限校验与角色切换，最后断言记忆继承与任务切换后的状态一致性（父恢复执行时状态没被污染）。这套测法要有稳定的桩：把模型输出固定，才能把「模型随机性」和「隔离实现错误」区分开。

Playwright 做 VSCode 插件自动化与 CDP 的作用

VSCode 插件跑在 Electron 里，界面不是浏览器页面，常规的选择器驱动不了，所以要借 CDP：先用 --remote-debugging-port 启动 VSCode（或用 Playwright 的 Electron 支持直接拉起），通过 CDP 连上渲染进程，拿到页面目标后再用 Playwright 的 API 操作 DOM、截图、注入脚本。CDP 在这里承担三件事：连接与目标发现（哪个窗口、哪个 WebView 是插件 UI）、底层输入与网络能力（真实鼠标键盘事件、请求拦截与 mock）、以及在原生与 WebView 之间切换上下文。插件测试的难点在于：WebView 的 iframe 层级要正确切进去、插件激活时机要等待（命令面板、状态栏元素的出现），以及测试要覆盖宿主与插件交互（文件保存触发、配置变更、语言服务返回）。工程上把启动参数、工作区 fixture 和扩展安装做成可复用的 fixture，一条命令跑完清理。

Workflow 工作流与大模型主控模式的区别

两者的区别是「流程控制权在谁手里」。工作流把步骤写死在代码或图里：节点、分支、重试、超时都是确定的，模型只在固定位置做填空（抽取、分类、生成），好处是可预测、可测试、token 与延迟可控、出错能定位到节点；代价是覆盖不了没预先枚举的路径。大模型主控（Agent Loop）把控制权交给模型：由它决定下一步调哪个工具、要不要继续循环，能处理开放任务，但行为不稳定、轮次与成本不可预测、失败难复现。选型判据是任务路径能否穷举、错误代价有多高、有没有人工兜底：审批、出单、对账这类确定流程用工作流，探索型、输入千变万化的任务用主控模式，最实用的通常是混合——外层用工作流框住关键节点，把模型自主循环限制在受控子图里，并给它设步数上限、预算上限和终止条件。

Skill 模块测试与模型评测

Skill 本质是给模型的说明文档与资源包，测法与测功能完全不同：先测静态契约（命名与描述是否说清「什么时候该用」、参数与文件引用是否存在、有没有互相冲突或与工具重名），再测触发准确率——用一批该用和不该用的问题，看模型是否正确加载、有没有该触发没触发、不该触发乱触发，以及加载后是否真的按里面的步骤执行。模型评测要建带标准答案的评测集并分层：能力维度（抽取、推理、多轮、工具调用）、难度、业务场景，指标不能只看最终答案对不对，还要看过程（是否选对工具、参数是否正确、有没有多余步骤），打分校准用规则判定加模型评审加人工抽检三方交叉。SWE-bench 一类基准是「用真实仓库的真实 issue 做端到端修复，跑测试用例判对错」，LoCoM 一类基准偏长上下文与记忆，注意它们的场景与业务不同——借用它们的设计思路（客观可执行、可复现），但结论必须用自己的业务评测集验证，并固定住评测集版本与评分口径，否则每次改动的对比都不成立。