Agent 项目中的 harness engineering 是什么，如何支撑工具模拟、回放、评测、回归和线上前验证？｜美团后端开发面经解析

60 秒回答模板

Agent 项目里的 harness engineering 可以理解为围绕 Agent 的测试运行器和实验底座。普通服务测试通常输入固定、函数确定，而 Agent 依赖模型、工具、检索、外部 API 和多轮 state，输出有概率性，所以需要一个 harness 把这些不确定因素可控化。它至少要支持五件事：第一是工具模拟，用 mock 或 fake tool 返回稳定结果，区分成功、空结果、超时、权限错误、下游错误和脏数据；第二是轨迹回放，把一次真实会话的用户输入、模型选择、工具调用、工具返回、state diff 和最终回答保存下来，在新版本上复跑；第三是评测，构建任务集和指标，既看最终答案，也看工具选择、参数正确性、步骤数、成本、延迟、停止条件和安全约束；第四是回归，把历史 badcase、关键业务路径和边界场景纳入 CI，防止改 prompt、改工具 schema 或改路由后行为漂移；第五是线上前验证，在灰度前用 shadow traffic、dry-run 工具、沙箱环境和审批门禁检查新 Agent 是否会误调用有副作用工具。好的 harness 还要记录可审计 trace，支持随机种子或模型 stub，隔离真实副作用，并输出可定位的失败原因。它的目标不是让 Agent 永远确定，而是让变化可复现、风险可比较、上线有证据。

考点 可控运行

难度 真实面经题

回答目标让候选人能把 harness engineering 讲成 Agent 的验证基础设施：通过工具模拟、轨迹回放、过程评测、回归门禁和副作用隔离，把 Agent 变更从人工试聊变成可复现、可比较、可上线的工程流程。

深入解析

harness 是 Agent 的可控运行环境

Agent harness 不只是测试脚本，而是能把模型、工具、检索、状态和评估连接起来的运行框架。它负责装载任务样本、注入模型或模型 stub、替换工具实现、捕获 trace、计算指标并输出报告。没有 harness，Agent 的行为只能靠人工聊天验证，无法稳定回归。

工具模拟要覆盖语义而非只返回成功

工具 mock 不能只写一个 happy path。真实工具会有空结果、参数错误、权限不足、超时、限流、网络失败、返回字段缺失和数据冲突。harness 需要能配置这些场景，并检查 Agent 是否会补参、重试、降级、停止或解释错误，避免上线后被外部系统异常打穿。

回放要保存完整轨迹和状态差异

一次 Agent 运行应记录用户消息、系统配置、模型输出、工具调用参数、工具返回、节点路径、state diff、耗时、token、错误和最终回答。回放时可以选择完全冻结模型响应，也可以只冻结工具和输入再让新模型运行。前者适合调状态机，后者适合比较模型或 prompt 漂移。

评测指标要覆盖过程和结果

Agent 评测不能只做文本相似度。应同时看任务成功率、工具选择准确率、参数正确率、无效工具调用率、步骤数、循环次数、停止条件、拒答或追问是否合理、延迟、成本和安全违规。对高风险工具，还要把是否触发确认、是否越权调用作为硬指标。

回归集来自关键路径和 badcase

回归样本应包括高频路径、收益最大的核心能力、历史失败案例、边界输入、工具异常、权限边界、多轮上下文恢复和低置信度场景。每次改 prompt、工具 schema、router、state 或模型版本，都要跑这些样本，并输出和基线的 diff，而不是只看新功能样例。

线上前验证要隔离副作用

Agent 常会调用有副作用的工具，例如写入、提交、发送、更新状态。上线前验证要使用 sandbox、dry-run、只读凭证、影子流量或人工审批，把真实副作用隔离开。harness 应能证明新版本在真实输入分布下不会误触发危险工具，也不会出现成本或延迟失控。

报告要能定位到失败原因

好的 harness 输出不只是 pass/fail，而是告诉开发者失败发生在哪一层：路由错、slot 抽取错、工具参数错、工具返回处理错、模型总结错、停止条件错，还是安全策略错。报告最好能展示 trace diff、state diff 和指标变化，这样才能把评测结果转化成修复行动。

易错点

把 harness 理解成简单 mock 工具，没有覆盖回放、评测、回归和发布前验证。
工具模拟只有成功路径，缺少空结果、超时、权限错误、脏数据和下游异常。
评测只看最终回答是否通顺，不检查工具选择、参数、state、节点路径和停止条件。
回放记录不完整，没有保存模型输出、工具返回和 state diff，导致失败无法复现。
对有副作用工具直接在真实环境测试，没有 sandbox、dry-run、只读凭证或审批门禁。
回归集只放新功能样例，忽略旧能力、高频路径、历史 badcase 和边界输入。
报告只给一个分数，不定位失败层级，开发者不知道该改 prompt、工具还是状态机。

面试官追问

Agent harness 和普通单元测试有什么区别？

普通单测通常验证确定性函数；Agent harness 要控制模型概率性、外部工具、长链路 state 和多轮上下文。它不仅断言输出，还要记录和比较工具调用、节点路径、状态变化、成本、延迟和安全策略。

工具 mock 应该做到多真实？

要真实到能覆盖工具契约和关键失败语义，但不必复制整个下游系统。重点是参数校验、返回结构、错误码、超时、空结果、权限和数据边界。对复杂工具可以用 fake service 或录制回放，而不是只写死一个 JSON。

回放时是否应该冻结模型输出？

取决于目标。冻结模型输出适合验证状态机、工具执行和渲染逻辑；不冻结模型、只固定输入和工具返回，适合评估 prompt 或模型版本变化。成熟 harness 应支持两种模式，并在报告中标明差异。

如何评价 Agent 的任务成功率？

可以用人工标注、规则断言和 LLM judge 组合。确定性部分优先用规则，例如工具名、参数、最终状态；文本质量和解释合理性可用人工或 judge，但要抽样校准，避免 judge 也引入不可见偏差。

线上前验证和灰度有什么关系？

线上前验证是在真实发布前用离线样本、录制流量或影子流量证明风险可控；灰度是小流量真实服务。前者应尽量隔离副作用，后者要有监控、回滚和流量开关，两者都需要 harness 产出的可比较指标。

历史 badcase 怎么进入回归集？

每个 badcase 要沉淀成可复现样本，包括输入、期望行为、工具环境、失败标签和断言。修复后先证明样本变绿，再长期保留在回归集中，防止后续模型或 prompt 更新把问题带回来。