PentAGI 本地化部署实战Ollama 上 Qwen3 32B fp16 推理模型的 Agent 功能测试报告解读【免费下载链接】pentagiFully autonomous AI Agents system capable of performing complex penetration testing tasks项目地址: https://gitcode.com/GitHub_Trending/pe/pentagi本篇技术指南以 examples/tests/ollama-qwen332b-fp16-tc-report.md 这份真实测试报告为主体深入讲解 PentAGI 如何通过内置的 Provider 配置测试工具ctester对本地 Ollama 部署的qwen3:32b-fp16-tc推理模型进行全量 Agent 功能验证。读者读完后将掌握 PentAGI 的 LLM 测试体系结构、13 类 Agent 角色的测试覆盖范围、测试报告的生成与解读方法以及如何在本地复现这套验证流程。一、报告背景为什么要对本地 LLM 做 Agent 功能测试PentAGI 是一套能够自主执行复杂渗透测试任务的 AI Agent 系统。系统内部分工为 13 类不同的 Agent 角色——从简单的问答助手simple、JSON 输出助手simple_json到负责渗透测试流程编排的 primary_agent、负责报告生成的 generator/refiner、负责搜索的 searcher/enricher、负责编写与安装工具的 coder/installer、以及最终执行攻击动作的 pentester 等。在生产环境接入任意一个 LLM Provider 之前必须回答一个关键问题这套模型的推理能力、工具调用能力、上下文记忆能力、JSON 结构化输出能力能否支撑上述所有 Agent 角色的真实工作负载这也是仓库中ctesterProvider Configuration Tester工具存在的意义。qwen3:32b-fp16-tc是部署在本地 Ollama 服务器上的 Qwen3 32B 模型fp16 精度。这份报告就是对其运行 281 个测试用例后的完整结果记录生成于 2025-07-19最终成绩为279/28199.29%成功整体平均延迟 6.925s。二、总体结果13 类 Agent 的成功率与延迟概览报告第一部分给出了所有 Agent 类型的总体成绩。每个 Agent 均使用同一模型qwen3:32b-fp16-tcReasoning列统一为true表示该模型在测试中呈现了推理/思考输出测试框架会依据模型是否产出思考过程进行判定。AgentModelReasoningSuccess RateAverage Latencysimpleqwen3:32b-fp16-tctrue23/23 (100.00%)7.029ssimple_jsonqwen3:32b-fp16-tctrue5/5 (100.00%)6.073sprimary_agentqwen3:32b-fp16-tctrue22/23 (95.65%)6.596sassistantqwen3:32b-fp16-tctrue23/23 (100.00%)7.374sgeneratorqwen3:32b-fp16-tctrue23/23 (100.00%)6.395srefinerqwen3:32b-fp16-tctrue23/23 (100.00%)7.367sadviserqwen3:32b-fp16-tctrue23/23 (100.00%)7.065sreflectorqwen3:32b-fp16-tctrue23/23 (100.00%)6.974ssearcherqwen3:32b-fp16-tctrue23/23 (100.00%)6.736senricherqwen3:32b-fp16-tctrue22/23 (95.65%)6.578scoderqwen3:32b-fp16-tctrue23/23 (100.00%)7.086sinstallerqwen3:32b-fp16-tctrue23/23 (100.00%)6.952spentesterqwen3:32b-fp16-tctrue23/23 (100.00%)7.140sTotal: 279/281 (99.29%) successful testsOverall average latency: 6.925s从数据可以得出几个直接结论11/13 的 Agent 角色取得 100% 通过率说明该模型在基础指令遵循、工具调用、上下文记忆等通用能力上表现稳定simple_json 仅运行 5 个用例而非 23 个这是测试框架的刻意设计simple_jsonAgent 只负责 JSON 类测试其余类型测试对它不适用详见下文测试与 Agent 的匹配规则两个失败用例全部集中在同一个测试项——Penetration Testing Memory with Tool Call带工具调用的渗透测试记忆测试发生在primary_agent与enricher上将在第五节专门分析。三、这套测试是怎么跑起来的ctester 工具与测试框架3.1 ctesterProvider 配置测试命令行工具报告由仓库中的ctester工具生成入口位于 backend/cmd/ctester/main.go。它支持在本地直接对任意已接入的 Provider 类型运行测试cd backend go run ./cmd/ctester \ -type ollama \ -config ../examples/configs/ollama-qwen332b-fp16-tc.provider.yml \ -report ../examples/tests/ollama-qwen332b-fp16-tc-report.md \ -workers 4主要命令行参数如下对应 main.go 中的 flag 定义参数默认值说明-env.env环境文件路径用于加载 Provider 相关密钥与配置-typecustomProvider 类型支持custom、openai、anthropic、gemini、bedrock、ollama、deepseek、glm、kimi、qwen、minimax-name空Provider 名称会覆盖LLMServerProvider配置-config空Provider 配置文件路径即各 Agent 的模型与采样参数同时写入LLMServerConfig与OllamaServerConfig-tests空自定义测试用例 YAML 文件路径不传则使用内置测试集-report空报告输出路径Markdown 格式不传则只打印终端摘要-agentsall逗号分隔的 Agent 类型如simple,pentester-groupsall逗号分隔的测试组可选basic、advanced、json、knowledge-workers4并行执行测试的 worker 数-verbosefalse输出每个用例的详细执行日志当-type ollama时createProvider 会检查cfg.OllamaServerURL是否为空为空则直接报错退出随后调用ollama.DefaultProviderConfig(cfg)构建 Provider 实例。这提醒我们运行 Ollama 测试前必须确保本地 Ollama 服务已启动且地址配置正确。3.2 测试执行内核TestProvider 与并行 Workerctester本身只负责参数解析与 Provider 构建真正的测试执行位于 backend/pkg/providers/tester/runner.go 的TestProvider函数。其核心流程为收集测试请求collectTestRequests根据配置的 Agent 类型与测试组从测试注册表生成agentType × testCase的所有组合并过滤掉与 Agent 不兼容或模型不支持能力的用例并行执行executeTestsParallel使用带缓冲 channel 的 worker 池并发运行worker 数量由WithParallelWorkers控制默认 4结果聚合groupResults按 13 类 Agent 类型把结果整理成ProviderTestResults结构见 backend/pkg/providers/tester/result.go。测试配置通过函数式选项TestOption注入定义在 backend/pkg/providers/tester/config.go// 默认配置全部 Agent 类型 × basic/advanced/knowledge 三组开启流式测试4 个并行 worker func defaultConfig() *testConfig { return testConfig{ agentTypes: pconfig.AllAgentTypes, groups: []testdata.TestGroup{testdata.TestGroupBasic, testdata.TestGroupAdvanced, testdata.TestGroupKnowledge}, streamingMode: true, verbose: false, parallelWorkers: 4, } }3.3 报告生成链路报告的 Markdown 格式由 backend/cmd/ctester/report.go 的WriteReportToFile生成。观察该函数即可理解报告的结构逻辑Overall Results 表格遍历所有 Agent 汇总成功数、成功率与平均延迟并累计出 Total 行Detailed Results每个 Agent 一节按 Basic Tests / Advanced Tests 分组输出失败用例附带截断至 150 字符的错误信息EscapeMarkdown转义后写入Capability Tests当测试结果中存在能力门控用例adaptive thinking / reasoning off / structured output时单独成表。本次报告中未出现该章节说明这套配置未触发能力类用例详见第六节的能力门控机制。四、测试套件全景281 个用例从哪来4.1 内置测试注册表所有内置测试用例定义在 backend/pkg/providers/tester/testdata/tests.yml通过go:embed编译进二进制见 backend/pkg/providers/tester/testdata/registry.go 的LoadBuiltinRegistry。每个用例包含id、name、typecompletion / json / tool、groupbasic / advanced / json / knowledge、streaming开关、prompt 或多轮 messages、工具定义与期望输出。按测试类型划分枚举定义见 backend/pkg/providers/tester/testdata/models.go类型验证能力代表用例completion基础指令遵循、知识问答、上下文记忆Simple Math、Count from 1 to 5、Pentesting Methodologyjson结构化 JSON 输出字段类型严格校验Person Information JSON、User Profile JSONtool工具/函数调用选对工具、参数正确Basic Echo Function、Search Query Function、nmap 工具选择4.2 测试组与 23 项标准用例默认每个标准 Agent 运行 23 个用例8 项 Basic 15 项 Advanced即报告每个 Agent 小节中看到的清单Basic Tests8 项——通用能力基线测试验证点Simple Math精确数字回答224Text Transform Uppercase精确文本转换Count from 1 to 5系统提示词约束下的精确输出Math Calculation多步数学计算Basic Echo Function最基本的工具调用Streaming Simple Math / Count / Echo流式模式下同类能力的稳定性Advanced Tests15 项——面向真实业务负载高级工具调用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 Toolsnmap 用途、SQL Injection Attack Type、Penetration Testing FrameworkMetasploit、Web Application Security ScannerBurp Suite、Penetration Testing Tool Selection根据需要网络扫描调用 nmap 工具并传参 target192.168.1.1、scan_typeTCP端到端业务场景Penetration Testing Memory with Tool Call——完整模拟资产发现 → 端口扫描 → Web 漏洞扫描 → 生成报告的多轮渗透测试流程要求模型在最后调用generate_report工具汇总目标 IP 与发现复杂安全工作流记忆Cybersecurity Workflow Memory Test——长链条多轮交互后回答与 10.0.0.50 关联的域名是什么。JSON 组5 项仅simple_jsonAgent 运行包含 Person Information JSON、Project Information JSON、User Profile JSON 及流式 JSON 输出等重点校验 JSON 字段的类型正确性如 age 必须是数字而非字符串。4.3 测试与 Agent 的匹配规则为什么simple_json只有 5 个用例规则在 runner.go 的isTestCompatibleWithAgent中switch agentType { case pconfig.OptionsTypeSimpleJSON: // simpleJSON agent only handles JSON tests return testType testdata.TestTypeJSON default: // all other agents handle everything except JSON tests return testType ! testdata.TestTypeJSON }即simple_json只跑 JSON 类用例其余 Agent 跑除 JSON 外的全部用例——这解释了报告中两类 Agent 的用例数量差异5 vs 23。五、逐 Agent 结果解读与失败用例分析5.1 各 Agent 成绩汇总由于除simple_json外其余 12 个 Agent 运行的是同一套 23 项用例报告对各 Agent 的明细可汇总为Agent通过/总数平均延迟失败用例simple23/237.029s无simple_json5/56.073s无primary_agent22/236.596sPenetration Testing Memory with Tool Callassistant23/237.374s无generator23/236.395s无refiner23/237.367s无adviser23/237.065s无reflector23/236.974s无searcher23/236.736s无enricher22/236.578sPenetration Testing Memory with Tool Callcoder23/237.086s无installer23/236.952s无pentester23/237.140s无延迟层面的观察单用例延迟大致呈两档分布——简单用例 2.58s而涉及长多轮上下文的用例Function Response Memory Test、Penetration Testing Memory with Tool Call、复杂框架问答普遍落在 1024s其中 pentester 的 Function Response Memory Test 达到 22.963ssearcher 的 Vulnerability Assessment Tools 达到 24.191s。这符合本地 fp16 推理模型在处理超长上下文时的典型表现。5.2 两个失败用例的完整明细primary_agent22/2395.65%TestResultLatencyErrorPenetration Testing Memory with Tool Call❌ Fail11.379sexpected function generate_report not found in tool calls: expected function generate_report not found in tool callsenricher22/2395.65%TestResultLatencyErrorPenetration Testing Memory with Tool Call❌ Fail12.571sexpected function generate_report not found in tool calls: expected function generate_report not found in tool calls5.3 失败根因分析该用例定义于 tests.yml是一个 9 轮 messages 的长对话系统提示要求必须使用工具帮助用户并记住所做之事对话依次是对 192.168.1.100 做安全评估 → 扫描开放端口nmap→ 检查 80 端口 Web 应用web_scan发现 SQL 注入→ 通过工具调用生成汇总报告。测试框架随后断言模型必须发起generate_report工具调用且参数 target192.168.1.100、findings 包含端口与 SQL 注入发现。两个 Agent 的失败信息均为expected function generate_report not found in tool calls即模型在最后一轮没有发起generate_report调用。结合模型行为可以推断在超长工具调用链末尾qwen3:32b-fp16-tc在这两个角色的采样配置下更倾向于输出自然语言总结而非再次发起工具调用该结论属于基于失败模式的推断报告中未给出模型具体输出内容。值得注意的是其余 11 个 Agent 在完全相同的用例上均通过说明问题并非模型能力缺失而是与特定 Agent 角色组合下的偶发行为有关——这也正是逐 Agent 全量测试这一设计的意义所在它能暴露单一模型在不同角色配置下的差异表现。六、配置层面的对照为什么这套配置能跑出这个成绩6.1 被测 Provider 配置文件本次测试使用的配置为 examples/configs/ollama-qwen332b-fp16-tc.provider.yml13 个 Agent 统一指向同一模型simple: model: qwen3:32b-fp16-tc n: 1 max_tokens: 40000 # ...其余 12 个 Agent 块与此完全一致 pentester: model: qwen3:32b-fp16-tc n: 1 max_tokens: 40000配置中未显式设置temperature、top_p等采样参数此时 Provider 会回落到各 Provider 自身的默认配置。以 backend/pkg/providers/ollama/config.yml 为例Ollama 的默认配置为所有 Agent 设置了temperature: 1.0、top_p: 0.9~0.95、n: 1并按角色分配不同max_tokens如 primary_agent/assistant 为 16384generator/coder 为 20480simple/adviser/searcher/reflector/enricher/pentester 为 4096~8192。这些默认值对应的参数名与取值范围在 backend/pkg/providers/pconfig/config.go 的AgentConfig.Validate中有明确校验temperature ∈ [0,2]、top_p ∈ [0,1]、repetition_penalty ∈ [0,2]、frequency/presence_penalty ∈ [-2,2]、reasoning.max_tokens ∈ [0,32768]。由于被测配置文件把max_tokens统一放大到 40000可以推断测试意图是让模型在长工具调用链与生成型任务上获得充分的输出空间避免因输出截断导致失败。6.2 能力门控机制为什么报告中没有 Capability Tests 章节测试框架支持三类能力门控用例定义见 models.goadaptive_thinking验证显式reasoning: {mode: adaptive}或仅支持自适应推理的模型reasoning_off验证显式reasoning: {mode: off}关闭思考structured_output验证 schema 约束的结构化输出当前仅对simple_json调度。这些用例只有当 Agent 的实际加载配置在真实 PentAGI 流程中会触发对应 wire 行为时才运行capabilitySupported与pconfig.AgentConfig.BuildOptions严格镜像。本次被测配置没有设置任何reasoning块也未声明结构化输出能力因此这些用例被静默跳过报告相应章节自然缺失——在解读报告时没有能力测试章节不等于未测试而是该配置下不适用。七、如何复现与扩展这套测试7.1 复现步骤准备本地 Ollama 环境启动 Ollama 服务拉取模型ollama pull qwen3:32b-fp16-tcfp16 精度需确认宿主机显存/内存充足配置 Provider 地址确保cfg.OllamaServerURL对应的环境变量已设置否则 ctester 会以 Ollama server URL is not set 退出运行测试cd backend go run ./cmd/ctester \ -type ollama \ -config ../examples/configs/ollama-qwen332b-fp16-tc.provider.yml \ -report ../examples/tests/ollama-qwen332b-fp16-tc-report.md \ -workers 4 -verbose查看报告-report指定的路径会生成与本文解读格式完全一致的 Markdown 报告不加-report时则仅打印终端汇总表格式对应 report.go 的PrintSummaryReport。7.2 常用变体只测某类 Agent-agents pentester,primary_agent只跑某个测试组-groups basic,knowledge自定义用例编写符合 tests.yml 格式的 YAML 文件用-tests传入自定义注册表通过testdata.LoadRegistryFromYAML解析见 registry.go可用WithCustomRegistry选项注入控制并发-workers 8可加速但需注意本地推理服务的吞吐上限Web 界面方式PentAGI 前端也暴露了 Provider 测试能力GraphQL MutationTestProvider见 backend/pkg/graph/schema.resolvers.go可在界面中针对单个 Agent 类型即时验证配置。7.3 报告数据的可复现性提示报告中的所有延迟数据6.925s 整体均值、各用例 2.5~24s 区间均依赖具体的硬件算力、并发度workers4、Ollama 服务负载与模型量化状态不同机器上的绝对值会存在差异。在评估该模型是否适合投入生产时应更关注成功率与失败模式的稳定性而非绝对延迟。八、结论与实战建议综合报告数据与框架设计可以给出以下可操作的结论qwen3:32b-fp16-tc具备支撑 PentAGI 全角色流水线的能力99.29% 整体成功率279/28113 个角色中 11 个 100% 通过覆盖了工具调用、多轮记忆、渗透测试领域知识与 JSON 输出等全部关键能力长工具调用链是本地模型的薄弱环节唯一的失败点集中在多轮渗透测试后要求再次发起工具调用生成报告这一场景且仅在 primary_agent 与 enricher 两个角色上出现。若这两类角色是生产核心建议通过 Prompt 强化必须用工具汇报结果的约束或更换/微调模型后重新跑同一份报告对比测试框架本身就是质量基建任何新的 Provider、模型或配置组合上线前都可通过 backend/cmd/ctester/main.go 一键产出同规格报告仓库examples/tests/下已积累 20 余份各 Provider 的测试报告可供横向对比将模型适不适合从主观感受变为可量化的数据。仓库内其他可继续深入的材料测试用例全集 backend/pkg/providers/tester/testdata/tests.yml、并行执行内核 backend/pkg/providers/tester/runner.go、Agent 类型与采样参数定义 backend/pkg/providers/pconfig/config.go以及同目录下其他 Provider 的测试报告如 examples/tests/openai-report.md、examples/tests/gemini-report.md。【免费下载链接】pentagiFully autonomous AI Agents system capable of performing complex penetration testing tasks项目地址: https://gitcode.com/GitHub_Trending/pe/pentagi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考