开源生态系统中AI智能体框架与应用的测试实践实证研究：模式、分布与挑战

原创

走向未来

发布于 2025-09-30 15:45:07

600

摘要：

超过70%的测试精力都花在了工具、工作流这些“外围”上，而真正决定AI智能体“灵魂”的提示，测试覆盖率竟然不到1%！别再只盯着代码逻辑了！赶紧把你的Prompts当成一级资产，给它们建立回归测试吧！这是防止你的AI Agent悄悄“变笨”的最关键一步！

正文：

基础模型（Foundation Models, FMs，即大模型）的崛起，正以前所未有的力量推动人工智能进入一个新纪元——“智能体（Agent）”时代。这些基于FM的AI智能体，被赋予了记忆、规划、工具使用乃至协作的能力，不再是简单的任务执行工具，而是能够在复杂环境中自主决策、执行动作以实现高级目标的自治系统。从自动化的客户服务到复杂的科学研究，智能体的应用前景正在迅速扩展，一个全新的“智能体应用（Agentic Application）”生态正在形成。

然而，在这股技术浪潮之下，一个深刻的矛盾也随之浮现。当前，衡量一个智能体“好坏”的主流文化，很大程度上继承自传统AI领域，即依赖标准化的基准测试（Benchmarks）。例如，AgentBench、GAIA等知名基准通过设定一系列预定义任务，来评估智能体在推理、决策和工具使用等方面的表现。这种方式对于模型的横向比较固然有价值，但它在工程实践中暴露了致命的缺陷：它制造了一个“感知性能”与“真实世界可靠性”之间的危险鸿沟。一个在排行榜上名列前茅的智能体，在实际应用中可能因无法处理边界情况而陷入错误循环，可能产生无法预料的“幻觉”，或者在底层FM无声的更新后出现功能衰退。这些都是基准测试难以覆盖的、关乎用户信任和业务成败的质量问题。

为了弥合这一鸿沟，软件工程领域行之有效的测试实践，如单元测试，成为必然的选择。然而，将传统测试方法直接应用于基于FM的智能体系统，又面临着前所未有的挑战。其核心在于FM固有的两大特性：非确定性（Non-determinism）和不可复现性（Non-reproducibility）。传统的测试断言依赖于精确、可预测的输出，但这在智能体的世界里几乎是一种奢望。一个智能体对于同一个指令的两次响应，可能在措辞、结构甚至执行路径上都有细微差别，但两者在语义上都可能是正确的。这种特性从根本上动摇了传统测试的基石。

本文基于对39个开源智能体框架和439个智能体应用进行了大规模的实证调查报告（报告全文可以从“走向未来”（https://t.zsxq.com/xpWzq）知识星球中获取），系统揭示了开发者在面对上述挑战时，究竟是如何在实践中“摸着石头过河”。我们将以此为基础，不仅呈现当前测试实践的全景图，更致力于挖掘其背后的深层逻辑、潜在风险，并为构建一个更加成熟、稳健和可靠的AI智能体生态系统提供前瞻性的思考和 actionable 的建议。

第一部分：构建分析基石——解构智能体生态与典型架构

在深入探讨测试实践之前，我们必须首先建立一个稳定、统一的分析框架。AI智能体领域技术迭代迅猛，新的组件、协议和标准层出不穷。为了使我们的分析能够超越具体实现，触及问题的本质，本章将首先界定智能体生态的核心构成，并引入一个经典的、具有持久生命力的典型智能体架构模型。

欢迎加入“走向未来”知识星球，一起探讨生成式人工智能、大模型和AIGC的产品、技术和应用实践，探讨如何使用各种不同的人工智能大模型和智能体来为工作增效，为生活添彩。点击链接（https://t.zsxq.com/xpWzq）或“走向未来”知识星球，一起走向AGI的未来。

1.1 智能体生态的双重结构：框架与应用

现代AI智能体生态呈现出清晰的层级结构，理解这一结构是剖析其测试实践的前提。

智能体框架（Agent Frameworks）：这是生态的基础设施层。框架如AutoGen、CAMEL、MetaGPT等，为开发者提供了构建、编排和部署智能体系统的软件库和结构化环境。它们将状态管理、工具集成、多智能体通信等底层复杂性进行抽象，通过高阶API让开发者可以专注于定义智能体的角色、目标和工作流。框架的质量直接决定了其上构建的所有应用的稳定性和能力上限。
智能体应用（Agentic Applications）：这是生态的价值实现层。这些应用构建于一个或多个框架之上，是直接面向最终用户、解决特定问题的软件系统。例如，一个能够自主搜索信息、预订机票并规划行程的旅行助手，或是一个能与孩子互动、动态生成睡前故事的语音玩具。它们利用框架提供的能力来管理其核心业务逻辑。

这种分层结构意味着测试的责任和焦点也应有所不同。框架的测试应更侧重于通用性、健壮性和可扩展性，而应用的测试则更侧重于特定业务场景的正确性、上下文处理能力和与外部系统的集成稳定性。

1.2 超越基准测试：质量保证的真正内涵

如引言所述，基准测试的局限性在于其“任务导向”而非“质量导向”。一个通过了所有基准任务的智能体，并不能保证它是一个高质量的软件产品。以下是基准测试无法有效覆盖的关键质量维度：

功能衰退（Performance Degradation）：智能体应用严重依赖的底层FM会持续更新。研究已表明，模型的升级可能导致对原有提示（Prompt）的解释发生变化，从而在用户无感知的情况下，悄无声息地降低输出质量。这一现象往往与模型的知识被固化在训练数据的时间点且其生成的内容缺乏事实依据的校验有关。浦东“明珠计划”菁英人才、资深AI技术专家王文广先生在其著作灯塔书《知识增强大模型》中，对此有系统性的剖析。他指出，要从根本上解决这些问题，必须超越模型本身，引入外部的、动态的、可验证的知识源，这正是“知识增强”理念的核心价值所在。该书的第一章便开宗明义，为我们迎接大模型纪元，构建更可靠的AI系统指明了方向。
工具使用失败（Tool Failures）：智能体通过调用工具（如API、代码解释器）与外部世界交互。调用过程可能因为格式错误、参数不匹配、网络问题等多种原因失败。
鲁棒性与边界情况（Robustness & Edge Cases）：真实世界的输入充满了模糊、矛盾甚至恶意的信息。智能体是否能优雅地处理这些非标准输入，而不是崩溃或产生有害输出，是衡量其鲁棒性的关键。
资源管理与安全性（Resource Management & Security）：一个失控的智能体可能会陷入无限循环，耗尽计算资源和API调用预算。同时，如果智能体能够执行代码或访问文件系统，则必须有严格的安全护栏，防止被恶意利用。

这些问题，恰恰是传统软件测试的核心关注点。因此，将软件工程的测试纪律引入智能体开发，是其从“学术演示”走向“工业级应用”的必经之路。

1.3 JaCaMo：一个用于稳定分析的范式架构

为了系统地分析测试实践，我们需要一个统一的“地图”来标注智能体的各个功能区域。考虑到智能体技术仍在快速演进，直接分析具体框架的实现细节（如特定的内存模块、通信协议）会导致分析结果很快过时。

为此，该研究创造性地引入了经典的JaCaMo框架作为范式架构模型。JaCaMo源于多智能体系统研究，它将一个智能体系统解构为三个维度：智能体（Agent）、环境（Environment）和组织（Organization）。其核心组件提供了一个稳定且高度抽象的视角来理解任何智能体系统的构成。研究报告基于JaCaMo，并结合现代FM智能体的特点，提炼出了13个范式组件，它们构成了我们后续分析的“坐标系”。

以下是几个核心组件的释义：

信念库（Belief Base）：智能体关于自身和环境的信息集合，相当于其“知识”或“记忆”。在现代智能体中，它对应于内存系统、向量数据库等。
计划（Plan）：为实现目标而采取的一系列行动。一个计划由三部分组成：
- 触发器（Trigger）：激活计划的事件。在FM智能体中，用户的初始提示（Prompt）是最核心的触发器。
- 上下文（Context）：用于选择最合适计划的即时信息。这类似于检索增强生成（RAG）中提供的背景文档。
- 计划主体（Plan Body）：构成计划的实际动作或推理步骤序列。在现代智能体中，这通常由FM动态生成，是智能体的“大脑”所在。
资源构件（Resource Artifacts）：环境中可被智能体利用的被动、可复用的实体。这包括工具（Tools）、API封装、解析器、数据库连接等。
协调构件（Coordination Artifacts）：专门用于管理和同步多个智能体交互的实体。这对应于定义好的工作流（Workflows）、消息队列等。
边界构件（Boundary Artifacts）：连接智能体系统与外部世界的桥梁，如用户界面（GUI）或与其他软件系统的外部连接器（External Connectors）。
可观测属性（Observable Property）：智能体感知构件状态的机制，如日志、度量指标和输出（Output）结果。

通过将测试代码中实际被测的单元（Subject Under Test, SUT）映射到这13个范式组件上，研究得以穿透具体实现的迷雾，揭示出测试投入在智能体核心功能上的分布规律和深层模式。

第二部分：剖析现状——智能体测试的十大模式及其应用

在建立了分析框架后，我们现在可以深入智能体测试的核心：开发者究竟采用了哪些具体的测试模式？研究通过对759个抽样测试函数进行系统的卡片分类法分析，识别出了10种主流的测试模式，这些模式可以分为两大类：结构化模式（Structural Patterns）和验证模式（Verification Patterns）。这分别对应了测试用例“Arrange-Act-Assert”（AAA）结构中的“Arrange”（安排）和“Assert”（断言）阶段。

2.1 结构化模式：如何为不确定的测试搭建舞台

结构化模式关注如何组织和设置测试环境，以隔离被测组件、管理依赖并控制输入变量。研究发现了三种主要的结构化模式。

1. 测试替身（Test Double）

模式描述：这是从传统软件工程中继承的最核心的实践之一。它通过使用模拟对象（Mocks）、桩（Stubs）和伪对象（Fakes）来替代真实的、复杂的或不稳定的依赖项（如数据库、外部API、甚至FM本身）。
应用分析：在智能体测试中，测试替身被广泛用于隔离那些难以控制的组件。例如，当测试一个需要调用天气API的工具时，开发者会用一个Mock对象来模拟API的调用，并返回一个预设的、固定的天气数据。这确保了测试的稳定性和可重复性，使开发者能专注于验证工具本身的逻辑是否正确，而不受真实API网络延迟或服务中断的影响。在框架和应用中的使用率均在20%以上，表明它已成为不可或缺的基础实践。

2. 参数化测试（Parameterized Testing）

模式描述：允许用多组不同的输入数据来运行同一个测试逻辑。开发者只需编写一次测试函数，然后提供一个数据列表，测试框架会自动为列表中的每一项数据执行一次测试。
应用分析：该模式在智能体测试中的采纳率惊人地高（框架中占28.7%，应用中占26.1%），远超传统软件工程中约9%的水平。这一现象深刻地反映了智能体开发的内在需求。由于智能体的行为受到输入提示、上下文数据和FM随机性的多重影响，其输入空间极其广阔。参数化测试成为了一种高效验证核心逻辑在不同输入下保持健壮性的关键手段。开发者用它来测试解析器能否处理各种格式的数据，或者一个工作流在面对不同用户意图时能否正确路由。

3. 超参数控制（Hyperparameter Control）

模式描述：这是一种针对FM智能体新出现的、领域特定的结构化模式。它通过在测试设置阶段显式控制FM的超参数（最典型的是temperature）来管理模型的随机性。
应用分析：temperature参数控制着FM生成文本的多样性。较高的值会产生更随机、更有创意的输出，而将其设置为0则会使模型倾向于选择最可能的下一个词元，从而产生更具确定性的输出。在测试中，开发者利用这一点来创造一个可复现的测试环境。当一个测试失败时，通过将temperature设为0，他们可以有效地区分失败是源于自身代码的缺陷，还是仅仅是FM的一次随机、非预期的输出。然而，令人惊讶的是，该模式的采纳率极低，在框架和应用中都不足1%。这揭示了一个巨大的认知鸿沟：尽管这是一个应对非确定性的有力工具，但绝大多数开发者可能并不知道或没有采用它。

2.2 验证模式：如何在不确定的结果中寻找确定性

验证模式关注如何在测试执行后，判断被测组件的行为是否符合预期。这是智能体测试中最具挑战性的部分，因为它必须直面FM的非确定性输出。研究发现了七种验证模式，展现了开发者们一种务实而充满智慧的“权变策略”。

1. 基于断言的测试（Assertion Based Testing）

模式描述：这是最传统、最基础的验证方式，通过精确的等值检查（assert result == expected）、类型检查（assert isinstance(result, str)）等来验证输出。
应用分析：尽管面临非确定性的挑战，该模式依然是绝对的主导，在框架和应用中的使用率分别高达81.5%和72.9%。这表明开发者仍然倾向于在可能的情况下寻求最严格、最明确的验证。他们主要将这种模式用于测试系统的确定性部分，例如，验证一个工具函数的计算结果，或者一个配置加载模块是否正确解析了文件。

2. 成员资格测试（Membership Testing）

模式描述：这是一种比严格等值检查更灵活的验证方式。它不要求输出完全匹配，而是检查输出中是否包含（或不包含）特定的子字符串、模式或元素。
应用分析：该模式的使用率显著（框架中15.9%，应用中21.6%），成为应对FM输出变化的首选“软”断言。例如，测试一个生成邮件草稿的智能体时，开发者不会断言整个邮件内容，而是用成员资格测试来验证邮件中是否包含了正确的收件人姓名、会议时间和关键主题词。这种方式在保证核心信息正确的同时，容忍了措辞和格式上的细微变化。

3. 模拟断言（Mock Assertion）

模式描述：当使用Mock对象时，除了控制其行为，开发者还可以验证它是否被以预期的方式调用了。例如，验证某个方法是否被调用了恰好一次，或者是否传入了正确的参数。
应用分析：这种“基于交互”的验证方式在智能体测试中非常普遍（框架中14.5%，应用中10.0%）。它将验证的焦点从不确定的输出结果转移到了确定的内部交互上。当一个工作流的最终产出难以预测时，开发者可以通过模拟断言来确保工作流内部的各个组件（如工具调用、日志记录）之间的协作是正确的。

4. 负面测试（Negative Test）

模式描述：验证系统在接收到无效输入或遇到异常情况时，是否能按预期抛出错误或优雅地失败，而不是崩溃。
应用分析：该模式的使用率相当高（框架中27.4%，应用中22.9%），反映了开发者对系统鲁棒性的高度重视。他们用负面测试来确保当用户提供格式错误的输入、或者外部API返回错误码时，智能体能够正确地捕获异常并给出合理的反馈。

5. 快照测试（Snapshot Testing）

模式描述：在第一次运行测试时，将一个复杂输出（如一个长JSON或HTML片段）的结果保存为一个“快照”文件。在后续的测试中，新的输出会与这个快照进行比较。如果存在差异，测试就会失败，开发者可以选择接受新的结果作为快照，或修复代码。
应用分析：该模式主要用于验证那些结构复杂但内容相对稳定的输出。在智能体框架中，它被用来确保工作流的中间状态表示或最终生成的配置文件结构不被意外破坏。

6. 值范围分析（Value Range Analysis）

模式描述：验证一个数值输出是否落在某个合理的、预定义的区间内。
应用分析：这在传统ML测试中很常见，用于检查模型预测的置信度等。在智能体测试中，它被用来验证一些性能指标或资源消耗，例如，一个API调用的延迟是否在可接受范围内。

7. DeepEval

模式描述：这是另一种新出现的、领域特定的验证模式，代表了最前沿的探索。它采用“LLM-as-a-Judge”（大模型作为裁判）的范式，利用另一个强大的语言模型来从语义层面评估被测智能体的输出。
应用分析：DeepEval能够评估传统断言无法捕捉的质量维度，如答案的相关性、忠实度、是否存在幻觉等。例如，测试一个简历检索智能体，DeepEval可以判断其返回的简历摘要是否真的与职位描述高度相关。这为解决非确定性验证问题提供了根本性的新思路。然而，与超参数控制类似，DeepEval的采纳率同样微乎其微，仅在智能体应用中出现了1.1%。

2.3 综合洞察：务实的权变与巨大的认知鸿沟

综合分析这十大模式，我们可以得出两个核心结论：

开发者采取了务实的“权变策略”：面对非确定性，开发者并没有完全放弃传统测试的严谨性。相反，他们形成了一种“混合验证”的策略。研究发现，基于断言的测试经常与成员资格测试、模拟断言和负面测试等更灵活的模式共同出现在一个测试函数中。这表明，他们会对自己能控制的确定性部分使用严格断言，而对FM产生的、难以预测的部分则采用更宽容的“软”断言。这是一种在理想与现实之间寻求平衡的理性选择。
存在巨大的“认知与采纳鸿沟”：像DeepEval和超参数控制这样专门为解决智能体核心挑战而设计的先进模式，几乎无人问津。这反映出当前社区存在严重的知识断层。其原因可能是多方面的：这些新技术缺乏成熟的工具支持、学习曲线陡峭、或者仅仅是因为开发者社区对它们的存在和价值缺乏足够的认知。无论如何，这个鸿沟表明，最强大的“武器”仍被束之高阁，智能体测试的潜力远未被发掘。

第三部分：聚焦被测对象——测试投入的“大反转”与关键“盲点”

理解了“如何测试”（测试模式）之后，下一个关键问题是“测试什么”（被测组件）。通过将每个测试函数中被测的SUT映射到前述的13个范式架构组件上，研究揭示了测试资源在智能体系统内部的分配情况。其结果不仅出人意料，而且深刻地揭示了当前智能体工程实践的核心逻辑和致命缺陷。

3.1 测试投入的“大反转”：从模型到基础设施

研究最令人震惊的发现是，与传统机器学习（ML）应用的测试实践相比，AI智能体的测试投入发生了根本性的反转。

在传统ML项目中，测试的焦点无疑是模型本身，大约24-30%的测试工作都围绕着模型的性能、准确率和鲁棒性展开。然而，在智能体生态中，作为“大脑”的计划主体（Plan Body，即FM）组件，得到的直接测试关注却极少——在框架和应用中均不足5%。

与之形成鲜明对比的是，绝大多数测试资源（超过70%）都涌向了系统的确定性基础设施部分。其中，投入最大的两个组件是：

资源构件（Resource Artifacts）：包括工具、解析器、数据库接口、嵌入生成器等。它在框架测试中占比29.7%，在应用测试中更是高达39.2%，是毫无疑问的测试焦点。
协调构件（Coordination Artifacts）：即定义好的工作流。它在框架和应用测试中分别占据了21.6%和22.1%的投入。

这种“大反转”现象背后，是一种极其理性的工程决策。面对FM这个充满不确定性的“黑箱”，开发者选择将有限的测试资源投入到他们能够完全控制和可靠验证的部分。他们无法轻易断言FM的思维过程，但他们可以百分之百地确保自己编写的工具函数在给定输入下返回正确的结果，可以确保自己设计的工作流在特定条件下正确地流转。这是一种“避难就易”的策略，开发者在不确定性的汪洋大海中，为自己构建了一座由确定性代码组成的“安全岛”。

3.2 致命的盲点：被完全忽视的“触发器”（提示）

然而，这种理性的“避难”策略，却造成了一个可能致命的盲点。研究发现，触发器（Trigger）组件——在现代智能体中主要对应于提示（Prompts）——在测试中几乎被完全忽视，其在框架和应用中的测试占比均只有约1%。

这是一个极其危险的信号。提示是人与FM智能体交互的唯一接口，是引导和约束其所有后续行为的源头。提示的质量，包括其清晰度、示例的选择与排序、上下文的丰富性，直接决定了智能体性能的上限。更重要的是，如前所述，提示具有脆弱性（brittleness）。当底层的FM模型更新时，原先表现优异的提示可能会突然失效或效果大打折扣，导致智能体应用发生难以察觉的“功能衰退”。

当前社区几乎完全缺乏对提示的回归测试，这意味着绝大多数智能体应用都暴露在由模型迭代带来的巨大风险之下。开发者们精心测试了智能体手中的“锤子”（工具）和使用锤子的“说明书”（工作流），却唯独忽略了发出“去钉钉子”这个指令本身的有效性和稳定性。这个盲点，是当前智能体工程实践中最薄弱的环节。

3.3 框架与应用的分野：测试哲学的微妙差异

尽管框架和应用开发者都将测试重点放在了相同的基础设施组件上，但研究进一步发现，他们在如何测试这些组件上，展现出了微妙而重要的哲学差异。这种差异体现在对不同测试模式的选择上。

框架测试哲学：追求“通用鲁棒性”
- 框架作为基础设施，其目标是为各种上层应用提供一个稳定可靠的底座。因此，其测试更倾向于使用严格、全面的验证手段来保证其普适性。
- 例如，在测试协调构件（工作流）时，框架开发者更倾向于使用快照测试来确保工作流的中间状态和内部结构在代码迭代中不被破坏。在测试构成性实体（如速率限制、安全护栏）时，他们更多地使用负面测试和参数化测试来系统性地探索各种边界和异常情况。
应用测试哲学：追求“特定场景正确性”
- 应用的目标是在特定的业务场景下完成任务。因此，其测试更关注结果的最终有效性，并对过程中的不确定性有更高的容忍度。
- 例如，在测试协调构件（工作流）的产出时，应用开发者更频繁地使用成员资格测试。他们不关心输出的精确措辞，只关心是否包含了关键信息。在测试边界构件（外部连接器）时，应用开发者虽然也使用测试替身来隔离第三方服务，但相比框架，他们更少使用严格的模拟断言，而是采用更轻量级的检查。

这种测试哲学的分野是合理的，它反映了框架和应用在生态系统中的不同角色。但也揭示了一个潜在的效率问题：双方在相同的四个核心组件上投入了大量资源，可能存在重复测试的情况。一个理想的模式应该是，应用开发者可以充分信任框架已经保证了基础组件的通用鲁棒性，从而将自己的测试资源更多地投入到与自身业务逻辑紧密相关的部分。

第四部分：迈向未来——为构建可靠智能体生态系统的行动指南

基于上述的现状剖析和深度洞察，本研究不仅诊断了问题，更重要的是为智能体生态系统的未来发展指明了方向。以下是为生态系统中不同角色的参与者提炼出的具体、可行的行动建议。

4.1 对智能体框架开发者的建议

1. 将先进的语义验证能力集成到框架中

行动：框架开发者应将DeepEval这类“LLM-as-a-Judge”技术作为内置的、一等公民的测试能力集成到框架中。
理由：当前应用开发者难以采纳DeepEval，很大程度上是因为其使用复杂，需要额外设置。如果框架能提供简单易用的API（例如，assert_semantic_relevance(output, context)），将极大降低应用开发者进行语义验证的门槛。这将把处理非确定性输出的重担从应用层转移到基础设施层，从根本上提升整个生态的可靠性。

2. 建立并推广“测试契约”

行动：框架开发者应明确定义并公布其提供的“测试契约（Testing Contract）”。
理由：为了解决框架和应用之间重复测试的问题，框架需要清晰地告知其使用者：“我们已经保证了所有协调构件的并发安全性和所有资源构件的输入校验”。这份契约可以是文档、最佳实践指南，甚至是某种形式的“框架认证”。它将指导应用开发者将测试精力从已被覆盖的基础设施 robustness 上移开，更专注于他们自己的业务逻辑，从而优化整个生态的资源分配。

4.2 对智能体应用开发者的建议

1. 将提示回归测试套件作为开发的“标配”

行动：应用开发者必须将提示（Prompts）视为与代码同等重要的一流可测试资产，并为其建立系统的回归测试套件。
理由：这是为了填补当前最致命的测试盲点。开发者应维护一个“黄金”提示集，以及这些提示对应的、经过验证的语义输出。每当底层FM更新或应用逻辑变更时，自动运行这个测试套件，以确保智能体的核心行为没有发生非预期的衰退。这是保障应用长期稳定和可靠的生命线。

2. 善用超参数控制作为核心调试技术

行动：在开发和调试阶段，系统性地使用超参数控制（如设置temperature=0）来隔离问题。
理由：当测试失败时，这是区分“代码缺陷”与“模型随机性”最有效的手段。开发者应养成习惯，先在确定性环境下（temperature=0）验证其工作流和工具逻辑的正确性。一旦确认了自身代码的稳健，再将temperature调高，测试系统在真实、非确定性条件下的表现。

3. 将测试焦点上移至业务逻辑和集成点

行动：信任并依赖底层框架的鲁棒性保证，将主要的测试资源投入到应用的差异化价值点上。
理由：应用的核心价值在于其独特的业务逻辑、定制化的工具以及与特定外部系统的集成。应用开发者应该将测试的重点放在这些方面，例如，他们自定义的工具是否能正确处理业务数据，他们的边界构件（外部连接器）是否能稳定地与第三方系统交互，以及他们独有的业务工作流是否能满足用户需求。

4.3 对AI研究人员的建议

1. 深入研究新型测试模式的采纳障碍

行动：通过定性研究方法（如访谈、问卷调查），诊断为何像DeepEval和超参数控制这样的先进模式采纳率如此之低。
理由：技术再先进，如果不能被实践采纳，其价值就为零。研究需要揭示这背后的根本原因：是缺乏认知？是工具不成熟？还是文化上对传统测试范式的路径依赖？这些洞察将为设计更直观的测试工具、开发更有针对性的教育材料提供宝贵输入。

2. 形式化一套全面的智能体测试理论

行动：在本次实证研究的基础上，着手构建一套系统的“智能体测试理论”。

理由：当前开发者们的实践（如“混合验证”、“测试投入反转”）虽然务实，但仍处于自发的、零散的状态。研究人员的责任是将其提炼、升华为一个具有指导性的理论框架。这个框架应明确回答：针对何种范式组件，哪种测试模式组合最为有效？（例如，对边界构件应优先使用测试替身，对构成性实体应优先使用负面测试，对可观测属性应优先使用DeepEval）。要构建这样一套行之有效的理论，离不开对底层技术的深刻洞察与系统性梳理。在这方面，王文广先生的灯塔书《知识增强大模型》一书提供了宝贵的思想资源。该书不仅系统讲解了检索增强生成（RAG）、向量数据库、知识图谱等核心技术，更重要的是，在第八章和第九章中高屋建瓴地提出了“图模互补应用范式”与“知识图谱增强生成（GraphRAG）”等创新理念。这些理念将确定性的知识图谱推理与大模型的概率性生成能力相结合，为解决智能体的可解释性、可靠性与深度推理能力提供了全新的路径。对于期望推动智能体工程化纪律的研究者而言，这本书无疑是一座不容错过的“灯塔”，它为我们从“手工作坊”迈向真正的“工程化”提供了坚实的理论基石和丰富的实践案例。