关注 霍格沃兹软件测试开发 公众号回复「资料」, 领取人工智能测试开发技术合集很多人已经开始感觉到AI Agent 的风向变了。前两年大家讨论最多的是 Prompt 怎么写、模型怎么选、知识库怎么接。只要能让大模型调用一个工具、生成一段代码、完成一次页面操作就足以做出演示效果。现在企业真正关心的问题变成了Agent 能不能连续执行十几个步骤中途失败后能不能从断点继续调用了哪些系统修改了哪些数据能不能完整追溯模型换了、工具升级了、业务规则变化了原来的 Agent 会不会直接失控对于软件测试从业者来说这种变化尤其明显。过去测试一个 AI 应用可能只需要检查回答是否准确、格式是否符合要求。现在面对企业级 Agent还要测试任务规划、工具调用、状态流转、上下文管理、权限边界、失败恢复和多智能体协作。这已经不是一个“模型效果问题”。它正在变成一个完整的软件工程问题。Prompt 依然重要但 Prompt 只能告诉模型应该做什么。真正决定 Agent 能不能进入生产环境的是围绕模型建立起来的那套运行环境。这套运行环境正在被越来越多团队称为 Harness。目录一、Agent 演示很惊艳上线后却开始失控二、企业要的不是“会回答”而是“可靠执行”三、Prompt、Context、Harness 到底分别解决什么四、一个测试用例 Agent为什么会越跑越不稳定五、企业落地 Agent需要补齐哪些工程能力六、Agent 的下一轮竞争可能发生在模型之外一、Agent 演示很惊艳上线后却开始失控能完成一次任务不代表能稳定完成一类任务一个典型的 Agent Demo 通常并不复杂。用户输入一句需求模型识别意图调用几个工具最后生成一个结果。例如读取需求文档→ 提取功能点→ 生成测试用例→ 导出 Excel整个流程只有三四步输入数据也不大。在这种条件下即使系统没有复杂的状态管理、上下文压缩和异常恢复也可能顺利跑通。但企业场景不会一直这么简单。真实任务可能是读取需求文档→ 检索历史需求→ 查询业务规则→ 提取功能点→ 识别接口变化→ 分析影响范围→ 生成测试点→ 生成接口用例→ 生成 UI 用例→ 检查覆盖率→ 去除重复用例→ 调用测试平台→ 创建测试计划→ 通知相关负责人当任务从 4 步增长到 15 步问题不会线性增加。它会成倍放大。模型需要记住更多数据处理更多工具结果维护更多中间状态还要保证前后步骤使用的是同一组业务口径。任何一个环节发生偏差都会影响后续链路。第 3 步拿错了接口版本第 8 步生成的测试用例可能全部基于过期字段第 10 步没有识别这个错误第 12 步仍然可能成功创建测试计划。从系统角度看任务执行成功了。从业务角度看整个结果却是错的。Agent 越跑越不稳定往往不是模型变笨了很多团队会遇到一个很相似的现象同一个 Agent执行三五步时表现很好执行十几步之后工具参数开始出错前面发现的信息开始遗忘最终结果逐渐偏离任务目标。最直接的判断通常是模型能力不够。于是团队开始换更大的模型、购买更长的上下文窗口或者在 Prompt 中加入更多规则。但模型升级以后问题往往只被推迟并没有真正消失。原因在于Agent 每执行一步都会向上下文中加入新的内容模型推理结果工具调用参数工具返回数据错误信息重试记录中间分析结论一个接口返回几十 KB 的 JSON 并不罕见。如果系统把这些结果完整塞进上下文几轮工具调用之后真正与当前任务有关的信息可能只占很小一部分。模型看到的内容越来越多但有效信息的比例越来越低。它不是没有信息而是找不到重点。上下文窗口越大不代表 Agent 的有效记忆越强。没有信息治理的长上下文只会形成更大的噪声场。当模型因为噪声调用错工具系统又会产生新的报错和重试信息。上下文继续膨胀模型下一轮判断进一步下降。于是形成一个自我恶化的循环这类问题不是继续优化某一句 Prompt 就能解决的。测试人员会最早碰到 Agent 的工程边界研发看到的是 Agent 能不能完成任务。测试更容易看到另外一面相同输入多次执行结果是否一致某个工具超时后任务是否还能继续用户关闭页面后后台任务是否丢失调用失败时Agent 会不会无限重试上一步返回 20 条数据下一步是否真的处理了全部数据Agent 是否调用了未授权工具业务规则变化后旧知识是否仍在生效任务成功状态是否等于业务结果正确传统接口测试关注输入、处理和输出。Agent 测试还需要关注过程。因为 Agent 的结果不是由一段确定性代码直接计算出来的而是由模型推理、工具调用、上下文数据和运行时状态共同决定的。同一个最终结果可能经过完全不同的执行路径。其中一条路径安全、稳定、成本可控另一条路径可能调用了十几次无效工具只是碰巧得到了正确答案。如果只验证最终输出很多风险根本不会被发现。企业级 Agent 的质量对象不只是最终答案还包括整个决策与执行链路。二、企业要的不是“会回答”而是“可靠执行”AI 应用正在从内容生成转向任务执行普通聊天机器人主要生成内容。它可以回答问题、总结文档、改写文章。即使回答不够理想用户通常还可以修改、重试或者直接放弃。Agent 不一样。Agent 会对外部系统产生真实影响。它可能创建测试任务修改数据库记录提交代码操作浏览器调用生产接口发送通知调整业务配置触发自动化流水线一旦系统开始执行动作质量标准就发生了变化。内容生成允许概率性。生产执行必须受到确定性约束。模型可以不确定但系统不能把这种不确定性原封不动地传递给生产环境。企业真正需要的不是一个“更会思考”的聊天机器人而是一个能够被控制、被恢复、被审计的任务执行系统。Agent 的核心矛盾是概率推理与确定执行之间的冲突大模型适合处理模糊问题。例如用户真正想解决什么问题一份需求文档有哪些潜在风险当前异常可能与哪些因素有关下一步应该调用哪个工具但大模型并不擅长精确搬运数据。例如上一步工具返回{“executionId”: “9f82c48e-7b31-4d47-a62f-719c0d2d3821”,“caseCount”: 128,“status”: “READY”}下一步需要用 executionId 查询执行详情。最脆弱的做法是让模型从历史消息中找到这个 ID再复制到新的工具参数里。长链路中模型可能漏掉部分字符混淆两个相似 ID使用上一次执行的 ID在压缩上下文后重新生成一个不存在的 ID这类操作不需要推理能力却消耗了大量模型注意力。更合理的设计是步骤 A 的 executionId↓系统变量表↓参数绑定↓步骤 B 的 executionId 参数数据由系统精确传递。模型只负责决定是否需要调用步骤 B。这背后是一条很重要的工程边界让模型负责理解、规划与判断让系统负责状态、数据与约束。当职责没有分开时团队就会不断增加 Prompt希望模型不要犯错。当职责分开后很多错误会从设计上直接消失。从 Prompt 到 Harness本质是控制权逐渐回到系统Agent 的工程演进大致可以分为三个阶段。图片Prompt 工程解决的是指令问题。Context 工程解决的是信息问题。Harness 工程解决的是运行问题。它们不是互相替代而是逐层叠加。Prompt 写得再好也不能完成断点恢复。Context 管理得再精细也不能自动提供权限控制和执行审计。Harness 的作用就是把模型放进一套完整的工程环境中让模型的能力能够稳定转化为业务结果。三、Prompt、Context、Harness 到底分别解决什么Prompt 工程解决“模型应该怎么做”Prompt 是 Agent 最早的一层控制面。一个结构化 Prompt 通常会包含角色与目标任务边界工具说明输出格式行为规则示例数据异常处理要求在简单场景中Prompt 非常有效。例如要求模型你是一名资深测试工程师。请根据需求文档提取功能点并按照以下字段生成测试用例用例标题、前置条件、执行步骤、预期结果、优先级。禁止生成需求中不存在的功能。这已经能明显提升生成质量。随着业务规则增加System Prompt 可能从几百字增长到几千字甚至发展成项目级说明文件。里面可能包含代码路径、接口规范、发布规则、工具约束和业务术语。这种做法的问题在于无论当前任务是否需要所有内容都会被注入上下文。规则越多Prompt 越长。Prompt 越长模型越难判断当前最重要的约束是什么。工程师往往会继续加入IMPORTANTMUSTDO NOTCRITICAL这些强调在短任务中有效在长链路中却会逐渐被新的信息淹没。真正的企业规则不能只停留在“提醒模型遵守”。权限限制、字段校验、数据格式、审批条件和工具白名单都应该由系统强制执行。Prompt 可以表达规则。系统必须落实规则。Context 工程解决“模型当前应该看到什么”很多人理解 Context Engineering只是把更多业务资料塞给模型。实际上Context 工程的核心不是增加信息而是控制信息。一个成熟的上下文系统需要回答四个问题哪些信息必须进入当前上下文哪些信息只需要保留摘要哪些原始数据应该放在外部存储中后续需要细节时如何准确取回可以把 Agent 的上下文管理设计成四层。第一层大结果外置当工具返回大量 JSON、日志或文档时不直接全部放进 Prompt。系统把原始结果存入数据库或对象存储只在上下文中保留{“refId”: “artifact_1024”,“type”: “api_result”,“count”: 238,“summary”: “共返回238条接口变更记录其中17条影响核心交易链路”}模型需要查看细节时再按引用读取。第二层语义压缩对于当前任务需要理解、但不需要完整保留的数据可以压缩为高密度信息。压缩的重点不是“把文字变短”而是保留后续步骤需要的关键事实ID数量状态时间风险项未解决问题已失败方案第三层对话整理当历史消息持续增长时不能简单删除最早内容。更合理的做法是生成一份结构化交接记录原始目标为支付系统版本 V3.8 生成回归测试计划。已经完成已解析需求文档已识别 12 个接口变化已定位 3 个高风险交易链路关键数据requirementIdREQ-2381executionIdEXE-8832已经失败的方案旧版 Swagger 文档字段不完整停止使用待处理生成支付失败补偿场景检查幂等性测试覆盖这样的内容比自由文本摘要更适合继续执行。第四层按需恢复上下文压缩后原始数据仍然不能丢失。系统需要提供查询能力查看结构outline(refId)搜索字段search(refId, query)读取局部context(refId, anchor)读取完整数据get(refId)模型每次只获取当前步骤真正需要的信息。Context Engineering 不是让模型记住所有内容。它是让模型在正确的时间只看到正确的信息。Harness 工程解决“任务如何可靠地完成”Harness 直译有“驾驭装置”“安全带”“控制系统”的含义。放在 Agent 工程中它不是某一个框架或工具而是一整套围绕模型运行的基础设施。一个企业级 Agent Harness通常需要包含以下能力。有状态执行系统要知道当前执行到了哪一步哪些步骤已经完成中间结果存在哪里哪些工具调用失败了当前是否正在等待人工审批状态不能只存在模型的对话历史中。它需要被持久化。断点恢复一个 20 步任务在第 17 步失败不应该重新执行前面的 16 步。系统需要在关键节点保存检查点LLM 推理完成→ 保存状态工具调用完成→ 保存状态步骤完成→ 保存状态服务重启、网络中断或者外部系统超时后可以从最近检查点继续。事件溯源每一次状态变化都应该记录为事件TASK_STARTEDPLAN_CREATEDSTEP_STARTEDTOOL_CALLEDTOOL_SUCCEEDEDSTEP_COMPLETEDTASK_PAUSEDTASK_RESUMEDTASK_FINISHED前端展示、故障恢复、日志审计和成本分析都可以基于同一条事件流构建。参数绑定步骤之间的数据关系需要显式声明。step: query_execution_detailparameterBindings:executionId:sourceStep: create_executionsourcePath: output.executionId模型不再负责复制 ID。运行时直接从上一步结果中读取并注入。动作空间治理工具越多不代表 Agent 越强。假设一个 Agent 同时暴露 80 个工具每次规划时模型都需要判断应该选择哪一个。工具名称相似、能力重叠或说明不清晰时误调用概率会明显增加。更好的方式是根据任务阶段动态暴露工具。需求分析阶段只提供文档解析与知识检索工具。测试设计阶段再提供用例生成、覆盖率分析工具。执行阶段才开放测试平台、浏览器和接口调用能力。安全与权限生产级 Harness 至少要具备工具白名单参数 Schema 校验高风险操作审批最大执行步数最大递归深度重复调用检测敏感信息脱敏用户主动取消资源与 Token 预算控制这些能力不是为了让模型变得更保守。它们的作用是把模型可能产生的不确定性限制在可控范围内。Harness 的核心不是给模型增加更多限制早期 Agent 系统容易进入一种“防御式开发”。模型经常传错参数于是增加参数修复。模型可能丢失字段于是增加字段恢复。模型可能重复调用于是加入更多 Prompt 提醒。最后工具执行器的大量代码都在猜测模型哪里可能出错。这类兜底机制在早期有价值但不能无限扩张。更好的方向不是持续修复错误而是重新设计流程让错误没有发生的必要。例如防御式设计Harness 设计提醒模型不要写错 ID系统自动绑定 ID提醒模型不要无限重试运行时限制最大次数猜测模型是否完成任务提供明确的步骤状态协议把所有工具都交给模型根据阶段动态开放工具出错后从头执行检查点与断点恢复依赖模型记住历史经验把经验写入结构化记忆好的 Harness 不是不断告诉模型“不要犯错”而是让正确路径比错误路径更短。企业级 Agent 已经接近一种新的运行时架构当状态管理、上下文管理、工具系统、事件流、权限、记忆和评测被整合在一起时Agent 系统就不再只是一个模型调用服务。它更像一个轻量级操作系统。模型只是其中的推理内核。真正决定系统可靠性的是外围架构。四、一个测试用例 Agent为什么会越跑越不稳定看起来简单的任务内部可能有十几个状态节点假设团队要开发一个“需求到测试用例”的 Agent。用户上传 PRD 后系统需要完成识别需求版本。提取业务模块。检索历史需求与缺陷。查询测试规范。提取功能点。识别异常流程。生成测试场景。生成详细用例。检查需求覆盖率。删除重复用例。评估风险等级。导出测试平台格式。创建测试任务。最初的实现可能是一个大 Prompt请阅读需求文档结合历史缺陷和测试规范生成完整测试用例并导入测试平台。模型可以完成一部分工作。但只要数据量和流程复杂度增加问题就会出现。纯 Prompt 方案的问题不止是生成质量历史数据把上下文塞满历史需求、缺陷记录、接口文档和业务规范可能达到几十万字。全部注入模型无法聚焦。只注入一部分又可能漏掉关键规则。中间数据被模型改写需求解析阶段识别出 36 个功能点。到了用例生成阶段模型可能只处理其中 20 多个因为它在长上下文中自动做了信息压缩。最终生成的用例格式完整但覆盖率不足。任务失败后无法恢复系统已经完成需求解析、知识检索和测试点生成。创建测试任务时测试平台接口超时。如果没有状态持久化只能重新执行整个流程。结果正确但过程不可接受Agent 最终生成了测试用例但中间可能检索了错误版本的业务规范调用了不必要的生产接口重复请求测试平台泄露了敏感字段消耗了远超预算的 Token只检查最终 Excel无法发现这些问题。Harness 方案会怎样改造这条链路把任务拆成可检查的步骤每个步骤都定义输入输出使用工具验收标准失败策略是否需要人工确认用系统传递确定性数据需求 ID、文档版本、功能点列表、接口 ID 通过 State 和参数绑定传递。模型不负责复制。用引用管理大数据完整需求和历史缺陷存储在外部。上下文中只保留摘要、索引和当前步骤需要的局部内容。每一步都可以评测例如“功能点提取”步骤的验收条件可以是需求章节覆盖率 95%功能点必须保留原始需求引用不得生成需求中不存在的业务能力未达到条件时只重试当前步骤。用检查点保存执行状态测试平台接口失败后从创建任务步骤继续执行。前面的需求分析和用例生成结果不需要重新计算。两种方案的差距会随着任务复杂度扩大对比维度纯 Prompt AgentHarness Agent任务规划模型临时生成结构化计划与动态调整数据传递依赖上下文记忆State 与参数绑定大数据处理全量注入或简单截断外置存储、摘要、按需读取异常恢复通常从头重试步骤级检查点恢复工具权限主要依赖 Prompt 提醒运行时白名单与审批过程验证关注最终结果每一步均可验证执行审计对话日志为主结构化事件链路成本控制执行后统计调用前预算与运行时限额经验积累新会话重新开始结构化记忆与知识更新适合场景演示、短任务长任务、生产业务小任务中两种方案看起来差距不大。任务越长、工具越多、业务风险越高差距越明显。五、企业落地 Agent需要补齐哪些工程能力不要从“做一个万能 Agent”开始很多 Agent 项目一开始就希望接入几十个工具覆盖多个业务系统让模型自己规划一切。这种方式很容易做出 Demo却很难形成稳定产品。更合适的起点是一个边界清晰、结果可验证的业务闭环。例如需求文档→ 测试点生成→ 人工评审→ 导入测试平台或者失败日志→ 异常分类→ 相似缺陷检索→ 定位建议→ 人工确认先把一个流程做到输入明确工具可控结果可验失败可恢复成本可计算再逐渐增加能力。把成功标准从“能跑通”改成“可重复”Agent 第一次成功执行证明的是可能性。连续执行 100 次才开始证明稳定性。团队至少需要观察任务成功率步骤成功率工具调用正确率平均重试次数平均执行时长Token 消耗人工接管率结果验收通过率断点恢复成功率高风险操作拦截率对测试团队来说Agent 的测试对象也需要从单轮问答扩展到完整运行链路。测试策略要从“输入输出”升级为“分层验证”Agent 系统可以按照五层进行测试。模型层关注模型在特定任务中的基础能力意图识别结构化输出规划质量事实准确性幻觉率Prompt 与 Context 层关注输入信息是否正确是否召回正确知识是否遗漏关键规则是否存在冲突上下文压缩后是否丢失关键 ID是否出现上下文污染Tool 层关注模型与外部系统之间的交互工具选择是否正确参数是否符合 Schema返回异常是否正确处理幂等性是否得到保障超时和限流是否有效Runtime 层关注长任务运行质量状态是否正确持久化检查点是否可恢复重试是否会重复产生副作用并行任务是否存在数据竞争多 Agent 状态是否一致业务层关注结果是否真正创造价值测试用例覆盖率是否提升缺陷定位时间是否下降人工审核成本是否减少错误操作风险是否可接受Agent 是否遵守真实业务规则只做模型评测无法证明 Agent 可以上线。只做功能测试也无法解释 Agent 为什么失败。可观测性必须早于自进化很多团队很早就开始讨论 Agent 自学习、自反思和自动优化。但系统连基本执行数据都没有记录时自进化没有可靠基础。在增加自动学习之前至少要能够回答哪个步骤失败最多哪个工具最容易被误调用哪种输入最容易导致计划偏离哪个 Prompt 版本表现更好哪种上下文压缩造成了信息丢失人工为什么拒绝 Agent 的建议没有这些数据所谓自我优化只是让模型根据不完整信息继续生成新的规则。更稳妥的顺序是可观测→ 可评测→ 可归因→ 可修正→ 灰度验证→ 逐步生效5. 不同阶段的从业者需要建立不同的能力重点在校生先看懂完整链路不需要一开始就研究复杂多 Agent 框架。先理解 Agent 的基本组成模型 Prompt Context Tool Memory Runtime Evaluation能够解释每个组件解决什么问题比背诵十几个框架名称更重要。初级工程师从一个闭环场景开始重点掌握Prompt 结构化设计工具调用RAG 与知识检索状态管理基础 Agent 评测一个真实业务流程的完整实现不要只做聊天机器人。至少做一个能够读取数据、调用工具、输出结果并处理异常的 Agent。中级工程师能力重点会转向 Harness需要继续补齐Agent Runtime工作流与 ReAct 的组合Context 生命周期管理事件驱动与状态机断点续传权限与安全边界多 Agent 协作评测与反馈闭环成本和稳定性治理到了这个阶段模型调用代码反而只是很小的一部分。真正的难点是如何把概率性的模型放进确定性的企业系统。六、Agent 的下一轮竞争可能发生在模型之外模型差距会缩小工程差距会扩大模型能力还会继续提升。工具调用会更准确长上下文会更稳定推理成本也可能继续下降。但这些变化不会自动让企业 Agent 变得可靠。模型越强企业反而越愿意把更复杂、更高风险的任务交给它。任务复杂度增长之后对运行时的要求也会同步提高。过去一个 Agent 只生成测试用例。未来它可能读取需求、分析代码变化、选择回归范围、生成脚本、执行测试、分析失败、提交缺陷并推动修复。模型能力提升的结果不是 Harness 变得不重要。而是 Harness 需要承载更大的执行责任。Agent 测试会成为新的质量工程方向传统测试解决的是确定性系统中的缺陷。Agent 测试需要面对概率性决策、动态路径和外部工具副作用。测试方法会逐渐从固定用例扩展到轨迹评测工具调用评测多轮任务评测长上下文退化测试对抗性指令测试记忆污染测试权限越界测试断点恢复测试多 Agent 协同测试线上反馈回放测试人员不会因为 Agent 出现而失去价值。相反系统越自主越需要独立的质量保障机制。只不过测试对象正在从一个接口、一个页面变成一条包含推理和行动的动态执行链。企业 Agent 最终会走向认知与执行分离未来复杂 Agent 系统可能逐渐分成两部分。一部分负责认知理解目标检索知识生成计划分析结果做出建议另一部分负责执行操作浏览器调用接口执行脚本修改数据收集证据认知层可以使用更强的推理模型。执行层强调确定性、隔离性和可恢复性。两者通过结构化任务协议连接任务目标执行约束可使用能力验收标准风险等级这种分离可以避免推理模型直接控制所有生产资源也让模型和执行环境能够独立升级。“会写 Prompt”会逐渐变成基础能力Prompt 不会消失。但它会像 SQL、接口设计或单元测试一样成为完整工程体系中的一个组成部分。未来更有价值的能力是能否把业务流程拆成可执行步骤能否设计高质量的 Agent 工具能否管理长链路上下文能否建立确定性的数据传递机制能否设计状态机和失败恢复能否构建 Agent 评测体系能否建立权限、审计和治理闭环未来真正稀缺的不是会调用大模型的人而是能把 Agent 纳入架构、测试与治理体系的人。当一个团队仍然依赖更长的 Prompt、更多的警告词和更大的模型来维持 Agent 稳定时它可能还停留在 Demo 阶段。当任务状态、上下文、工具、权限、评测和失败恢复都被显式设计时Agent 才真正开始接近企业级系统。回到你现在正在开发或测试的 Agent它只是能够把任务跑完还是已经具备失败可恢复、过程可追溯、结果可验证的反馈闭环本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。