PentAGI 实战测试报告解读智谱 GLM 系列模型在多智能体渗透测试框架中的表现分析【免费下载链接】pentagiFully autonomous AI Agents system capable of performing complex penetration testing tasks项目地址: https://gitcode.com/GitHub_Trending/pe/pentagi本篇文章围绕 PentAGI 开源项目中的 GLM 测试报告 展开深入解读智谱 GLM 系列模型glm-4.5-air、glm-5-turbo、glm-5.2在该全自主 AI 渗透测试 Agent 系统中的实测表现并结合仓库内的测试框架源码与 GLM 提供方配置分析成功率、延迟、失败原因与模型选型策略。读完本文你将理解 PentAGI 的 LLM 提供方测试方法论、各 Agent 角色与模型的对应关系以及如何解读与复现这类测试报告。报告背景PentAGI 的 LLM 提供方测试体系PentAGI 是一套能够执行复杂渗透测试任务的自主 AI Agent 系统其质量高度依赖底层 LLM 的能力。为了让接入的每个模型提供方都能被客观验证仓库在 tester 测试框架 中实现了完整的提供方测试工具链并在examples/tests/目录下沉淀了各模型的测试报告本文解读的glm-report.md正是智谱 GLM 系列模型在该框架下的实测结果。从源码结构看该测试体系由三层构成测试执行引擎runner.go 负责并行调度测试用例通过 worker 池并发执行默认parallelWorkers: 4测试用例注册表testdata/tests.yml 以 YAML 定义全部内置用例覆盖 completion文本补全、jsonJSON 输出、tool工具调用三种类型并按 basic / advanced / knowledge / json 四个分组归类报告生成器ctester 的 report.go 将测试结果格式化为 Markdown 报告即glm-report.md的生成来源。总体结果289/295 通过97.97% 成功率报告开头的 Overall Results 汇总了 13 个 Agent 角色在各自模型配置下的表现完整数据如下AgentModelReasoningSuccess RateAverage Latencysimpleglm-4.5-airfalse24/24 (100.00%)2.690ssimple_jsonglm-4.5-airfalse5/7 (71.43%)23.074sprimary_agentglm-5-turbotrue23/24 (95.83%)13.213sassistantglm-5-turbotrue21/24 (87.50%)7.770sgeneratorglm-5.2true24/24 (100.00%)6.324srefinerglm-5.2true24/24 (100.00%)5.923sadviserglm-5.2true24/24 (100.00%)6.481sreflectorglm-4.5-airtrue24/24 (100.00%)0.709ssearcherglm-4.5-airtrue24/24 (100.00%)2.869senricherglm-4.5-airtrue24/24 (100.00%)2.432scoderglm-5.2true24/24 (100.00%)6.389sinstallerglm-4.5-airtrue24/24 (100.00%)5.674spentesterglm-5.2true24/24 (100.00%)6.601s合计289/29597.97%测试成功整体平均延迟6.004s。从中可以清晰看出 PentAGI 的 GLM 模型分层策略glm-5.2 承担 generator报告生成、refiner报告精修、adviser顾问、coder编码、pentester渗透执行等关键推理角色glm-5-turbo 承担 primary_agent 与 assistant 两个编排/助手角色glm-4.5-air 则以低成本承担 simple、reflector、searcher、enricher、installer 等工具型角色。这与 glm/config.yml 头部注释中描述的选型策略完全一致glm-5.2 (newest flagship) for critical reasoning, glm-5-turbo (OpenClaw-native, agent-optimized) for orchestration, glm-4.5-air for cheap utility。测试用例体系从基础补全到渗透知识考核报告中的每个 Agent 均被跑了两组用例部分含 Capability 组其来源即 tests.ymlBasic Tests基础测试覆盖 8 项包括纯文本补全Simple Math、Text Transform Uppercase、Count from 1 to 5、Math Calculation、工具调用Basic Echo Function及三组流式Streaming变体。例如math_simple用例要求模型只输出数字 4不带任何其他文本用于验证指令遵循度。Advanced Tests进阶测试覆盖 16 项左右主要包括带参数的函数调用JSON Response Function、Search Query Function、Ask Advice Function及其流式版本多轮上下文记忆Basic Context Memory Test、Function Argument Memory Test、Function Response Memory Test渗透测试领域知识Penetration Testing Methodology、Vulnerability Assessment Tools、SQL Injection Attack Type、Penetration Testing Framework、Web Application Security Scanner、Penetration Testing Tool Selection复杂多轮工具编排Penetration Testing Memory with Tool Call、Cybersecurity Workflow Memory Test文件编辑往返Read a file, then edit it via unified diff。其中Read a file, then edit it via unified diff用例并非来自 tests.yml而是在 runner.go 中手工构建的fileEditTestCase——由于它是一个真正的动态多轮交互read_file → edit_file无法用固定消息列表表达因此以代码形式注入 Advanced 组。该用例实现了MultiTurnTestCase接口在每次工具调用返回后由 runner 循环驱动下一轮调用见 runner.go 中multiTurn.HandleToolResponse(contentResp)的循环逻辑。Capability Tests能力测试仅针对具备特定能力的配置出现。报告中的 simple_json 角色出现了 Structured Output With JSON Schema 用例属于structured_output能力门控测试通过CallWithExtraOptions路径调用runner.go 中len(extra) 0分支验证模型是否具备 schema 约束输出能力。关键失败案例分析在 6 个失败用例中可以归纳出两类典型问题这在选择与调优 GLM 模型时极具参考价值。1. 流式工具调用中的 JSON 解析失败primary_agent 与 assistantprimary_agent 的 Streaming Basic Echo Function Streaming 失败错误信息为expected function echo not found in tool calls: invalid JSON in tool call echo: invalid character after top-level valueassistant 的 Streaming Basic Echo Function Streaming 与 Streaming Search Query Function Streaming 失败信息完全相同invalid character after top-level value另外 Penetration Testing Memory with Tool Call 失败原因是模型未发起预期的generate_report工具调用。从错误特征看invalid character 表明模型在流式输出工具调用参数时参数内容中混入了类似 HTML/XML 标签的非 JSON 字符导致参数解析失败。这提示在使用 glm-5-turbo 进行流式工具调用时需要关注其流式函数调用参数的格式稳定性。2. 流式 JSON 输出与结构化输出的兼容性问题simple_jsonsimple_json 共有 2 个失败用例Person Information JSON Streaming流式 JSON模型返回了{answer:{age:25,city:Boston,name:Jane Doe}}这种带外层包装的 JSON与期望的扁平结构不符说明模型在流式模式下把字段包进了额外的answer键中Structured Output With JSON Schema失败信息为structured output: response validation failed (provideropenai modelzai/glm-4.5-air choice0 stop_reasonstop): response is not a single JSO...即模型输出未通过 JSON Schema 校验。值得注意的是该用例以provideropenai标识出现结合 glm/config.yml 与仓库中 openaicompat 适配器 的存在可以推断 GLM 提供方经由 OpenAI 兼容协议接入。此外simple_json 组中 JSON Array Response Without Schema 虽然通过但耗时高达 148.756s拉高了该角色的平均延迟23.074s说明无 schema 的数组输出在 glm-4.5-air 上响应极不稳定。在 tests.yml 的注释中仓库明确解释了 structured_output 测试的设计意图它是为 simple_json 角色即将接入的llms.WithStructuredOutput集成做的前置就绪检查——即使该路径尚未在生产接线也要提前验证模型后端是否具备 schema 约束输出能力从而在该集成正式落地时已有 100% 的信心。因此 simple_json 在此项上的失败实际结论是glm-4.5-air 目前尚不适合生产环境中的 schema 约束输出。各角色延迟画像低成本模型的优势区间报告的平均延迟数据揭示了 GLM 模型在 PentAGI 中的典型性能画像reflector 表现最亮眼平均 0.709s多数用例在 0.2s 左右完成这与该角色使用 glm-4.5-air 且任务简单直接相关glm-4.5-air 系列角色simple / searcher / enricher / installer延迟普遍在 2.4s ~ 5.7s 区间符合其低成本工具型角色定位glm-5.2 系列角色generator / refiner / adviser / coder / pentester延迟集中在 5.9s ~ 6.6s属于需要深度推理的核心角色glm-5-turbo 系列primary_agent / assistant延迟较高且波动大primary_agent 的 Count from 1 to 5 耗时 160.978sVulnerability Assessment Tools 耗时 23.513s反映了编排型 Agent 处理长链工具调用时的实际成本。从源码看测试框架的运行机制能力门控只测试生产路径上真实发生的调用capability.go 中的capabilitySupported函数体现了该框架的一个核心设计原则只运行 PentAGI 运行时真实会发出的调用。例如adaptive_thinking自适应思考能力用例只有当UsesAdaptiveThinking判断该角色的实际配置会产生该行为时才执行reasoning_off同理仅当角色配置中推理模式为 off 时才验证推理确实被抑制。这样避免了对生产永远不会发生的调用路径做无意义的假通过/假失败测试。结果聚合与报告生成测试结果通过 result.go 中定义的ProviderTestResults结构按 13 个角色聚合json tag 与报告表格的 Agent 列一一对应并由 report.go 的WriteReportToFile输出为 Markdown。报告中每行失败信息的格式如TruncateString(EscapeMarkdown(test.Error.Error()), 150)将错误截断至 150 字符这也解释了为什么报告中部分错误信息以省略号结尾。测试类型的角色兼容规则runner.go 中的isTestCompatibleWithAgent规定simple_json角色只执行 JSON 类型用例其余角色执行除 JSON 外的全部用例。这解释了为什么 simple_json 的报告只有 Advanced Tests 与 Capability Tests 两个分组而没有 Basic Tests 与 Knowledge 用例。GLM 配置细节思考模式与推理强度控制从 glm/config.yml 可以看到 PentAGI 为 GLM 系列定制了大量细节参数思考模式控制通过extra_body.thinking.typeenabled/disabled切换。simple / simple_json / reflector / searcher / enricher 关闭思考以降低延迟与成本glm-5-turbo 与 glm-5.2 角色开启思考保留思考Preserved Thinkingextra_body.thinking.clear_thinking: false用于在标准 API 端点保留reasoning_contentZ.AI 默认会在轮次间清空思考内容这会损害含工具调用的 Agent 循环该参数需与 openaicompat.go 中的WithPreserveReasoningContent()配合使 langchaingo 能把reasoning_content序列化回 API从而改善推理连续性与缓存命中率推理强度glm-5.2 支持reasoning_efforthigh/maxgenerator / refiner / adviser 三个角色通过reasoning.effort: max开启最大推理强度该参数会被AgentConfig.BuildOptions转换为llms.WithReasoning(ReasoningMax, 0)见 pconfig/config.go温度语义提醒config.yml 注释指出langchaingo 的IsReasoningModel会匹配 glm-4.5/4.6/4.7 前缀并强制将温度设为 1.0因此这些模型在 YAML 中的温度值仅是参考性的而 glm-5/glm-5.1/glm-5.2/glm-5-turbo 不被匹配温度参数会如实生效。模型定价数据价格仅代表配置文件中记录的输入/输出/缓存读取单价也体现了分层glm-4.5-air 为 0.20/1.10 美元每百万 tokencache_read 0.03glm-5-turbo 为 1.20/4.00glm-5.2 为 1.40/4.40cache_read 0.26。models.yml 进一步记录了模型家族规格如 glm-5.2 支持 200K 上下文与 128K 最大输出、glm-4.5-air 为 128K 上下文的 MoE 106B/12B 激活模型。如何复现此类测试若要为其他提供方或 GLM 新模型复现本报告可参考 ctester 入口 与 tester 包配置。config.go 暴露了完整的可编程选项WithAgentTypes限定角色、WithGroups限定测试组、WithStreamingMode开关流式用例、WithVerbose详细日志、WithParallelWorkers并发度与WithCustomRegistry自定义用例注册表默认配置会执行全部角色、全部测试组、开启流式并启用 4 个并行 worker。测试将按角色聚合结果最终产出与glm-report.md同构的 Markdown 报告。结论通过对这份 GLM 测试报告及其源码佐证的分析可以得出以下关键结论GLM 模型族整体表现优秀除 simple_json 外仅 glm-5-turbo 的两个编排角色出现流式工具调用 JSON 解析问题整体 97.97% 通过率模型分层策略有效glm-5.2 承担高推理角色、glm-5-turbo 承担编排角色、glm-4.5-air 承担低成本工具角色的分工与各模型的实测延迟与成功率高度匹配流式场景是当前短板流式工具调用参数与流式 JSON 输出的格式稳定性是 glm-4.5-air / glm-5-turbo 需要重点关注的调优方向能力门控设计严谨PentAGI 只测试生产路径真实发生的调用使得报告结论对实际部署具有直接参考价值。如需验证后续 GLM 新版本的表现可直接对比本报告与仓库examples/tests/目录下的其他提供方报告如 openai-report.md、qwen-report.md、deepseek-report.md 等并结合 glm/config.yml 与 models.yml 了解每个模型的规格与定价为渗透测试 Agent 的模型选型提供数据支撑。【免费下载链接】pentagiFully autonomous AI Agents system capable of performing complex penetration testing tasks项目地址: https://gitcode.com/GitHub_Trending/pe/pentagi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 PentAGI 实战测试报告解读：智谱 GLM 系列模型在多智能体渗透测试框架中的表现分析
PentAGI 实战测试报告解读智谱 GLM 系列模型在多智能体渗透测试框架中的表现分析【免费下载链接】pentagiFully autonomous AI Agents system capable of performing complex penetration testing tasks项目地址: https://gitcode.com/GitHub_Trending/pe/pentagi本篇文章围绕 PentAGI 开源项目中的 GLM 测试报告 展开深入解读智谱 GLM 系列模型glm-4.5-air、glm-5-turbo、glm-5.2在该全自主 AI 渗透测试 Agent 系统中的实测表现并结合仓库内的测试框架源码与 GLM 提供方配置分析成功率、延迟、失败原因与模型选型策略。读完本文你将理解 PentAGI 的 LLM 提供方测试方法论、各 Agent 角色与模型的对应关系以及如何解读与复现这类测试报告。报告背景PentAGI 的 LLM 提供方测试体系PentAGI 是一套能够执行复杂渗透测试任务的自主 AI Agent 系统其质量高度依赖底层 LLM 的能力。为了让接入的每个模型提供方都能被客观验证仓库在 tester 测试框架 中实现了完整的提供方测试工具链并在examples/tests/目录下沉淀了各模型的测试报告本文解读的glm-report.md正是智谱 GLM 系列模型在该框架下的实测结果。从源码结构看该测试体系由三层构成测试执行引擎runner.go 负责并行调度测试用例通过 worker 池并发执行默认parallelWorkers: 4测试用例注册表testdata/tests.yml 以 YAML 定义全部内置用例覆盖 completion文本补全、jsonJSON 输出、tool工具调用三种类型并按 basic / advanced / knowledge / json 四个分组归类报告生成器ctester 的 report.go 将测试结果格式化为 Markdown 报告即glm-report.md的生成来源。总体结果289/295 通过97.97% 成功率报告开头的 Overall Results 汇总了 13 个 Agent 角色在各自模型配置下的表现完整数据如下AgentModelReasoningSuccess RateAverage Latencysimpleglm-4.5-airfalse24/24 (100.00%)2.690ssimple_jsonglm-4.5-airfalse5/7 (71.43%)23.074sprimary_agentglm-5-turbotrue23/24 (95.83%)13.213sassistantglm-5-turbotrue21/24 (87.50%)7.770sgeneratorglm-5.2true24/24 (100.00%)6.324srefinerglm-5.2true24/24 (100.00%)5.923sadviserglm-5.2true24/24 (100.00%)6.481sreflectorglm-4.5-airtrue24/24 (100.00%)0.709ssearcherglm-4.5-airtrue24/24 (100.00%)2.869senricherglm-4.5-airtrue24/24 (100.00%)2.432scoderglm-5.2true24/24 (100.00%)6.389sinstallerglm-4.5-airtrue24/24 (100.00%)5.674spentesterglm-5.2true24/24 (100.00%)6.601s合计289/29597.97%测试成功整体平均延迟6.004s。从中可以清晰看出 PentAGI 的 GLM 模型分层策略glm-5.2 承担 generator报告生成、refiner报告精修、adviser顾问、coder编码、pentester渗透执行等关键推理角色glm-5-turbo 承担 primary_agent 与 assistant 两个编排/助手角色glm-4.5-air 则以低成本承担 simple、reflector、searcher、enricher、installer 等工具型角色。这与 glm/config.yml 头部注释中描述的选型策略完全一致glm-5.2 (newest flagship) for critical reasoning, glm-5-turbo (OpenClaw-native, agent-optimized) for orchestration, glm-4.5-air for cheap utility。测试用例体系从基础补全到渗透知识考核报告中的每个 Agent 均被跑了两组用例部分含 Capability 组其来源即 tests.ymlBasic Tests基础测试覆盖 8 项包括纯文本补全Simple Math、Text Transform Uppercase、Count from 1 to 5、Math Calculation、工具调用Basic Echo Function及三组流式Streaming变体。例如math_simple用例要求模型只输出数字 4不带任何其他文本用于验证指令遵循度。Advanced Tests进阶测试覆盖 16 项左右主要包括带参数的函数调用JSON Response Function、Search Query Function、Ask Advice Function及其流式版本多轮上下文记忆Basic Context Memory Test、Function Argument Memory Test、Function Response Memory Test渗透测试领域知识Penetration Testing Methodology、Vulnerability Assessment Tools、SQL Injection Attack Type、Penetration Testing Framework、Web Application Security Scanner、Penetration Testing Tool Selection复杂多轮工具编排Penetration Testing Memory with Tool Call、Cybersecurity Workflow Memory Test文件编辑往返Read a file, then edit it via unified diff。其中Read a file, then edit it via unified diff用例并非来自 tests.yml而是在 runner.go 中手工构建的fileEditTestCase——由于它是一个真正的动态多轮交互read_file → edit_file无法用固定消息列表表达因此以代码形式注入 Advanced 组。该用例实现了MultiTurnTestCase接口在每次工具调用返回后由 runner 循环驱动下一轮调用见 runner.go 中multiTurn.HandleToolResponse(contentResp)的循环逻辑。Capability Tests能力测试仅针对具备特定能力的配置出现。报告中的 simple_json 角色出现了 Structured Output With JSON Schema 用例属于structured_output能力门控测试通过CallWithExtraOptions路径调用runner.go 中len(extra) 0分支验证模型是否具备 schema 约束输出能力。关键失败案例分析在 6 个失败用例中可以归纳出两类典型问题这在选择与调优 GLM 模型时极具参考价值。1. 流式工具调用中的 JSON 解析失败primary_agent 与 assistantprimary_agent 的 Streaming Basic Echo Function Streaming 失败错误信息为expected function echo not found in tool calls: invalid JSON in tool call echo: invalid character after top-level valueassistant 的 Streaming Basic Echo Function Streaming 与 Streaming Search Query Function Streaming 失败信息完全相同invalid character after top-level value另外 Penetration Testing Memory with Tool Call 失败原因是模型未发起预期的generate_report工具调用。从错误特征看invalid character 表明模型在流式输出工具调用参数时参数内容中混入了类似 HTML/XML 标签的非 JSON 字符导致参数解析失败。这提示在使用 glm-5-turbo 进行流式工具调用时需要关注其流式函数调用参数的格式稳定性。2. 流式 JSON 输出与结构化输出的兼容性问题simple_jsonsimple_json 共有 2 个失败用例Person Information JSON Streaming流式 JSON模型返回了{answer:{age:25,city:Boston,name:Jane Doe}}这种带外层包装的 JSON与期望的扁平结构不符说明模型在流式模式下把字段包进了额外的answer键中Structured Output With JSON Schema失败信息为structured output: response validation failed (provideropenai modelzai/glm-4.5-air choice0 stop_reasonstop): response is not a single JSO...即模型输出未通过 JSON Schema 校验。值得注意的是该用例以provideropenai标识出现结合 glm/config.yml 与仓库中 openaicompat 适配器 的存在可以推断 GLM 提供方经由 OpenAI 兼容协议接入。此外simple_json 组中 JSON Array Response Without Schema 虽然通过但耗时高达 148.756s拉高了该角色的平均延迟23.074s说明无 schema 的数组输出在 glm-4.5-air 上响应极不稳定。在 tests.yml 的注释中仓库明确解释了 structured_output 测试的设计意图它是为 simple_json 角色即将接入的llms.WithStructuredOutput集成做的前置就绪检查——即使该路径尚未在生产接线也要提前验证模型后端是否具备 schema 约束输出能力从而在该集成正式落地时已有 100% 的信心。因此 simple_json 在此项上的失败实际结论是glm-4.5-air 目前尚不适合生产环境中的 schema 约束输出。各角色延迟画像低成本模型的优势区间报告的平均延迟数据揭示了 GLM 模型在 PentAGI 中的典型性能画像reflector 表现最亮眼平均 0.709s多数用例在 0.2s 左右完成这与该角色使用 glm-4.5-air 且任务简单直接相关glm-4.5-air 系列角色simple / searcher / enricher / installer延迟普遍在 2.4s ~ 5.7s 区间符合其低成本工具型角色定位glm-5.2 系列角色generator / refiner / adviser / coder / pentester延迟集中在 5.9s ~ 6.6s属于需要深度推理的核心角色glm-5-turbo 系列primary_agent / assistant延迟较高且波动大primary_agent 的 Count from 1 to 5 耗时 160.978sVulnerability Assessment Tools 耗时 23.513s反映了编排型 Agent 处理长链工具调用时的实际成本。从源码看测试框架的运行机制能力门控只测试生产路径上真实发生的调用capability.go 中的capabilitySupported函数体现了该框架的一个核心设计原则只运行 PentAGI 运行时真实会发出的调用。例如adaptive_thinking自适应思考能力用例只有当UsesAdaptiveThinking判断该角色的实际配置会产生该行为时才执行reasoning_off同理仅当角色配置中推理模式为 off 时才验证推理确实被抑制。这样避免了对生产永远不会发生的调用路径做无意义的假通过/假失败测试。结果聚合与报告生成测试结果通过 result.go 中定义的ProviderTestResults结构按 13 个角色聚合json tag 与报告表格的 Agent 列一一对应并由 report.go 的WriteReportToFile输出为 Markdown。报告中每行失败信息的格式如TruncateString(EscapeMarkdown(test.Error.Error()), 150)将错误截断至 150 字符这也解释了为什么报告中部分错误信息以省略号结尾。测试类型的角色兼容规则runner.go 中的isTestCompatibleWithAgent规定simple_json角色只执行 JSON 类型用例其余角色执行除 JSON 外的全部用例。这解释了为什么 simple_json 的报告只有 Advanced Tests 与 Capability Tests 两个分组而没有 Basic Tests 与 Knowledge 用例。GLM 配置细节思考模式与推理强度控制从 glm/config.yml 可以看到 PentAGI 为 GLM 系列定制了大量细节参数思考模式控制通过extra_body.thinking.typeenabled/disabled切换。simple / simple_json / reflector / searcher / enricher 关闭思考以降低延迟与成本glm-5-turbo 与 glm-5.2 角色开启思考保留思考Preserved Thinkingextra_body.thinking.clear_thinking: false用于在标准 API 端点保留reasoning_contentZ.AI 默认会在轮次间清空思考内容这会损害含工具调用的 Agent 循环该参数需与 openaicompat.go 中的WithPreserveReasoningContent()配合使 langchaingo 能把reasoning_content序列化回 API从而改善推理连续性与缓存命中率推理强度glm-5.2 支持reasoning_efforthigh/maxgenerator / refiner / adviser 三个角色通过reasoning.effort: max开启最大推理强度该参数会被AgentConfig.BuildOptions转换为llms.WithReasoning(ReasoningMax, 0)见 pconfig/config.go温度语义提醒config.yml 注释指出langchaingo 的IsReasoningModel会匹配 glm-4.5/4.6/4.7 前缀并强制将温度设为 1.0因此这些模型在 YAML 中的温度值仅是参考性的而 glm-5/glm-5.1/glm-5.2/glm-5-turbo 不被匹配温度参数会如实生效。模型定价数据价格仅代表配置文件中记录的输入/输出/缓存读取单价也体现了分层glm-4.5-air 为 0.20/1.10 美元每百万 tokencache_read 0.03glm-5-turbo 为 1.20/4.00glm-5.2 为 1.40/4.40cache_read 0.26。models.yml 进一步记录了模型家族规格如 glm-5.2 支持 200K 上下文与 128K 最大输出、glm-4.5-air 为 128K 上下文的 MoE 106B/12B 激活模型。如何复现此类测试若要为其他提供方或 GLM 新模型复现本报告可参考 ctester 入口 与 tester 包配置。config.go 暴露了完整的可编程选项WithAgentTypes限定角色、WithGroups限定测试组、WithStreamingMode开关流式用例、WithVerbose详细日志、WithParallelWorkers并发度与WithCustomRegistry自定义用例注册表默认配置会执行全部角色、全部测试组、开启流式并启用 4 个并行 worker。测试将按角色聚合结果最终产出与glm-report.md同构的 Markdown 报告。结论通过对这份 GLM 测试报告及其源码佐证的分析可以得出以下关键结论GLM 模型族整体表现优秀除 simple_json 外仅 glm-5-turbo 的两个编排角色出现流式工具调用 JSON 解析问题整体 97.97% 通过率模型分层策略有效glm-5.2 承担高推理角色、glm-5-turbo 承担编排角色、glm-4.5-air 承担低成本工具角色的分工与各模型的实测延迟与成功率高度匹配流式场景是当前短板流式工具调用参数与流式 JSON 输出的格式稳定性是 glm-4.5-air / glm-5-turbo 需要重点关注的调优方向能力门控设计严谨PentAGI 只测试生产路径真实发生的调用使得报告结论对实际部署具有直接参考价值。如需验证后续 GLM 新版本的表现可直接对比本报告与仓库examples/tests/目录下的其他提供方报告如 openai-report.md、qwen-report.md、deepseek-report.md 等并结合 glm/config.yml 与 models.yml 了解每个模型的规格与定价为渗透测试 Agent 的模型选型提供数据支撑。【免费下载链接】pentagiFully autonomous AI Agents system capable of performing complex penetration testing tasks项目地址: https://gitcode.com/GitHub_Trending/pe/pentagi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考