网站漏洞扫描智能体操作演示摘要本文完整记录了一个基于华为云码道 CodeArts 代码智能体开发的 AI 安全审计系统VulnAgent的工程实践。系统采用 Agent 范式让大语言模型LLM自主规划侦察步骤、调用 22 个原子化安全工具、分析响应并生成结构化报告全程无需人工干预。文章从架构设计、安全合规、代码质量、UI/UX、真实 Bug 修复到技术前景系统阐述了 LLM Loop Tools HarnessEngine laya 分级模型的完整技术栈并分享了用 CodeArts 智能体驱动整个开发流程的实践经验。目录一、开发方式华为云码道 CodeArts 代码智能体二、架构设计三、安全合规设计四、代码质量五、UI/UX 设计六、真实 Bug 的修复七、技术前景与当下影响八、写在最后做安全扫描工具链其实早就成熟了。Burp Suite、AWVS、Nessus 这些名字每个安全工程师都烂熟于心。但说实话用起来总有一种「我在操作工具」而不是「有人在帮我审计」的感觉。你得自己判断先扫哪里、后扫哪里得自己看响应判断有没有漏洞得自己写报告。这次参加华为云码道 CodeArts AI 编程挑战赛我想尝试一种不同的做法用 CodeArts 代码智能体来开发一个让大模型自己当安全工程师的系统。它自己规划侦察步骤自己调用工具发请求自己看响应判断漏洞自己写报告。整个过程在一个循环里自动完成人只需要给一个目标 URL。这篇文章记录的是这套系统的完整工程实践——从架构设计到模型分级从桌面化到测试策略以及用 CodeArts 智能体开发过程中踩过的那些坑。所有代码和数据都来自真实项目不是 PPT 架构。开源仓库https://atomgit.com/qq_36034945/vulnerability-scanning-agent技术栈Python 3.12 PySide6 DeepSeek V4 Flash laya torch规模43 源文件 6930 行代码326 测试全绿7 页面桌面应用一、开发方式华为云码道 CodeArts 代码智能体实战这个项目从头到尾是用华为云码道 CodeArts 代码智能体开发的。不是「用 AI 辅助写代码」而是「让 AI 驱动整个开发流程」。概念解释代码智能体Code Agent是一种具备文件读写、终端执行、测试运行等能力的 AI 编程工具它不仅能补全代码还能自主完成规划、编码、验证、调试、重构等完整开发环节。具体来说开发过程是这样的规划阶段给 CodeArts 描述需求——“集成 laya 模型做漏洞分级、开发桌面应用、UI 现代化”——它自动生成规划文档拆分成 P0 到 P5 六个阶段。编码阶段CodeArts 读取项目现有代码理解架构约定然后生成新模块。laya 分级模块的 4 个文件、UI 组件库的 6 个组件、7 个页面——都是它写的。测试阶段要求模拟真人用户测试每个功能点CodeArts 自动生成 FakeLLM 测试替身、326 个测试用例、6 组验收数据。调试阶段扫描运行时出现中文乱码、429 限流、英文思维链——每个 bug 我把终端日志贴给 CodeArts它定位根因并修复。重构阶段harness.py 超过 400 行CodeArts 自动拆分出 harness_types.py提取重复逻辑为 helper 方法保持所有测试通过。以前觉得 AI 编程就是补全代码、生成函数。现在发现当智能体有了文件读写、终端执行、测试运行的能力后它实际上可以驱动整个开发循环——规划、编码、验证、调试、重构。这和 LLM 在安全审计里做的事本质上是一样的给一个目标自主规划调用工具验证结果迭代改进。二、架构设计LLM Loop Tools 的 Agent 范式2.1 核心问题为什么不是「LLM 扫描器」最直觉的做法是让 LLM 调用一个现成的扫描器然后总结结果。但这有三个问题扫描器是黑盒。LLM 看不到扫描过程中的 HTTP 请求和响应没法做中间判断。一个 SQL 注入检测可能发了十几个 payload有些返回 500有些返回 200 但内容不同——这些中间信号对判断漏洞类型至关重要但扫描器只给一个最终结论。扫描器是死的。它按预设规则跑不会根据目标特征调整策略。看到一个 React SPA 和看到一个 PHP 老站应该用完全不同的侦察路径但扫描器不区分。报告是模板。扫描器输出的报告是固定模板填数据不会有「这个漏洞为什么严重」「在当前业务上下文下有什么影响」这种分析。所以选了另一条更难走的路让 LLM 自己当扫描器。给它一组原子化的安全工具HTTP 请求、SQL 注入检测、JS 逆向等让它在一个循环里自主决定调用哪个工具、用什么参数、怎么解读结果。这就是所谓的 Agent 范式。概念解释Agent 范式Agent Paradigm是一种以 LLM 为核心决策者、通过循环调用外部工具来完成复杂任务的架构模式核心三要素是 LLM 做决策、Tools 做执行、Loop 做迭代。2.2 整体架构LLM Loop Tools HarnessEngine laya整个系统的核心是一个叫 HarnessEngine 的循环引擎。名字借鉴了 AI 安全领域的 “harness” 概念——给模型一套工具和一个安全边界让它在里面自主行动。概念解释Harness约束框架在 AI 安全领域指为模型提供工具集合并划定安全边界的运行环境模型在其中自主决策但无法越界。┌────────────────────────────────┐ │ HarnessEngine │ │ 循环调度 / 范围约束 / 报告 │ └──────────────┬─────────────────┘ │ add_finding ┌────────────────┼────────────────┐ │ │ │ ▼ ▼ ▼ ┌──────────────┐ ┌─────────────┐ ┌──────────────┐ │ laya_cls/ │ │ LLM Client │ │ Tool Registry│ │ AI 三档分级 │ │(DeepSeek V4)│ │ (22 个工具) │ └──────────────┘ └──────┬───────┘ └──────┬───────┘ │ │ ┌──────────────┘ │ │ 一轮一轮 Loop │ └────────────────────────────────────┘ │ ▼ ┌──────────────────┐ │ PySide6 桌面UI │ │ 侧边栏 7 页面 │ └──────────────────┘2.3 循环是怎么转的每一轮迭代做五件事把对话历史和工具 schema 发给 LLMLLM 返回思考过程reasoning和工具调用请求tool_calls逐一执行工具把结果回传到对话历史检查终止条件LLM 停止调工具 / 达到最大迭代 / 检测到重复循环如果 LLM 上报了漏洞通过report_finding工具注入分级器做二次复核关键设计工具调用的结果直接回传给 LLM不经过任何中间处理。LLM 能看到完整的 HTTP 响应头、响应体、状态码能自己判断「这个 500 错误暴露了 SQL 语句说明有注入」。这是黑盒扫描器做不到的。2.4 22 个原子工具工具层是整个系统的基础设施。拆成 22 个原子工具让 LLM 像搭积木一样组合使用概念解释原子工具Atomic Tool指功能单一、不可再分的最小工具单元LLM 可以像搭积木一样自由组合它们来完成复杂任务。分类工具作用HTTPhttp_request/tech_detect/check_security_headers请求与指纹识别网络dns_lookup/port_scan/ssl_cert_info/whois_lookup资产梳理侦察dir_bruteforce/discover_files/analyze_js/fetch_js_endpoints/scan_form攻击面发现Web安全sql_injection_check/xss_check/open_redirect_check/directory_listing_check/cve_lookup漏洞验证本地代码list_files/read_file/search_code/run_command代码审计报告report_finding结构化上报每个工具都受授权范围Scope约束越权请求直接拒绝。2.5 一个真实的扫描过程以对内置靶场故意包含多种漏洞的 Flask 应用的扫描为例概念解释靶场Target Range指故意部署了多种已知漏洞的测试应用用于安全工具的功能验证和效果评估。第 1 轮侦察http_request获取首页 →tech_detect识别技术栈 →check_security_headers检查安全头 →discover_files探测敏感文件。5 个工具并行。第 2 轮攻击面dir_bruteforce探测目录 →analyze_js提取 JS →scan_form解析表单 →port_scan扫端口。第 3 轮验证sql_injection_check测登录接口 →xss_check测搜索接口 →open_redirect_check测重定向参数。第 4 轮上报确认的漏洞逐条调用report_finding上报含完整 title/severity/category/target/description/evidence/remediation。第 5 轮收敛输出「### 审计完成」开头的中文总结停止调用工具。整个过程不需要人工干预。LLM 自己决定先做什么后做什么根据每一轮的工具返回结果调整下一轮的策略。三、安全合规设计授权、非破坏性与数据隐私安全审计工具自身的安全性是不能忽视的。这个项目在安全合规方面做了几层防护3.1 授权范围约束所有网络工具在执行前都过 Scope 校验。用户指定--scope 127.0.0.1那任何对非 127.0.0.1 的请求直接拒绝不管 LLM 怎么要求。这是硬编码的安全边界不依赖 LLM 自觉。概念解释授权范围Scope指用户明确指定的允许扫描的目标范围系统通过硬编码校验强制约束防止越权访问。# vulnagent/scope.pyclassScope:defauthorize(self,target:str)-bool:检查目标是否在授权范围内。# 严格匹配不支持通配符扩展3.2 非破坏性探测系统提示词明确约束只做检测与验证绝不进行数据窃取、破坏或大规模攻击。工具层的 payload 都是最小化的检测 payload——比如 SQL 注入只发和 OR 11不发; DROP TABLE--。概念解释Payload攻击载荷指发送给目标系统的恶意输入数据。非破坏性探测使用最小化 payload仅验证漏洞存在性而不造成实际破坏。3.3 laya 决策模型漏洞分级「二审」report_finding工具允许 LLM 在上报时自己定 severity。但 LLM 定级别不太靠谱——经常把信息泄露标成 critical又把真正的 SQL 注入标成 medium。解决方案是加一个独立的分级模型做二次复核。选了 laya——Convai Innovations 开源的决策模型CPU 上单次推理 200-460ms不依赖 GPU。概念解释决策模型Decision Model指专门用于分类或决策任务的轻量级 AI 模型相比通用大模型更小、更快、可本地部署。关键设计用choice 题型做三档分类。不是让模型生成文字然后解析而是给它选项让它做单选题。这比开放生成稳定得多。# vulnagent/laya_cls/questions.pydefbuild_questions(finding:dict)-list[dict]:statebuild_state(finding)return[{question_type:choice,question:根据以上漏洞信息判断严重程度,choices:[high,medium,low],state:state,}]分级器注入点选在HarnessEngine.add_finding()——每条发现被收集时先过分级器再追加到报告。不侵入工具层不改变 LLM 行为只是一个后处理步骤。# vulnagent/harness.pydefadd_finding(self,**kwargs)-Finding:fFinding(**kwargs)ifself.classifierisnotNone:self._classify_finding(f)# laya 或规则分级self.findings.append(f)self.callbacks.on_finding(f)returnf分级策略info 不参与分级纯信息性发现不需要严重程度复核critical 归并进 highlaya 是三档制critical 直接归 high置信度阈值低于 0.4 保留 LLM 原判并标记「待人工复核」规则兜底laya 不可用时自动回退到 RuleClassifier保证系统任何情况下都能工作3.4 数据隐私分级在本地完成扫描结果不上传到第三方。laya 模型本地推理不联网不消耗 API 额度。这对安全审计场景特别重要——漏洞数据不应该外泄。五、UI/UX 设计5.1 为什么是桌面应用安全审计工具做成 Web 服务有个天然矛盾你要扫描的目标可能在内网但你的 Web 服务在云上。桌面应用没有这个问题——本地运行直接访问内网目标。选 PySide6 而不是 Electron因为整个后端是 Python不想引入 Node.js 依赖链。PySide6 是 Qt 的 Python 绑定性能足够组件丰富。5.2 七页面侧边栏架构┌──────────┬──────────────────────────────┐ │ ◆ VulnAgent│ 漏洞扫描 │ │ │ ┌────────────────────────┐ │ │ 扫描 │ │ 目标 URL [________] │ │ │ 代码审计│ │ 扫描模块 [完整审计 ▼] │ │ │ 对话 │ │ 最大迭代 [40] │ │ │ 发现管理│ │ [▶ 开始] [■ 停止] │ │ │ 报告 │ └────────────────────────┘ │ │ ⚙ 设置 │ 思维链 · 工具调用 发现列表│ │ 自检 │ ┌──────────┬──────────┐ │ │ │ │ 分析目标… │ 发现 0 项 │ │ │ v2.0.0 │ │ 调用 5 工具│ │ │ │ 仅授权使用 │ └──────────┴──────────┘ │ └──────────┴──────────────────────────────┘七个页面各有职责扫描页给 URL 跑扫描代码审计页给本地路径跑静态分析对话页自由下达任务发现管理页汇总所有扫描结果并支持重新分级报告页浏览历史报告设置页配置 API Key 和 laya 参数自检页验证工具链完整性。5.3 设计令牌系统UI 的视觉一致性靠一套设计令牌保证。所有颜色、字体、间距都定义在theme.py的Tokens类里QSS 由令牌生成classTokens:BG#0A0D12# 应用底色SURFACE#11151C# 卡片表面ACCENT#6E7BFF# 主强调靛蓝紫SUCCESS#3FB950DANGER#F85149FONTSegoe UI Variable Text, Microsoft YaHei UI, system-ui, sans-serif视觉方向参考 Linear / Vercel / Raycast 的深色质感——不是花哨的渐变和毛玻璃而是克制的颜色、清晰的层次、安静的专注感。安全审计是个严肃的工作UI 不应该分散注意力。5.4 后台线程与信号桥接LLM 调用是长时间 I/O 操作不能阻塞 UI 线程。用QThread把 HarnessEngine 放到后台跑通过 Qt 信号把事件推到 UIclassAgentWorker(QThr reasoning_deltaSignal(int,str)# 思维链增量content_deltaSignal(int,str)# 正文增量tool_callSignal(int,str,str)# 工具调用finding_addedSignal(dict)# 发现上报doneSignal(dict)# 完成failedSignal(str)# 失败 # 失败UI 侧的StreamingReasoningView组件接收信号把思维链逐 token 追加到界面——用户能看到 LLM「正在思考」的实时效果。这个体验是命令行给不了的。六、真实 bug 的修复这部分是实际运行中遇到的问题和修复过程。每个 bug 都有真实的错误日志。6.1 SSE 流编码乱码现象LLM 的回复显示为乱码——æå°å¯¹ www.csdn.net æ§è¡ç³»»å®¡è®¡而不是中文。根因requests库的iter_lines(decode_unicodeTrue)用resp.encoding解码。当 SSE 响应没有 charset 头时requests 默认用 ISO-8859-1。UTF-8 编码的中文被按 Latin-1 解码就乱了。修复一行代码——在iter_lines前显式设置编码resp.encodingutf-8forraw_lineinresp.iter_lines(decode_unicodeTrue):...这种 bug 很隐蔽。工具结果是 Python 字符串不受影响。只有 LLM 的content字段——从 SSE 流直接解码——才会乱码。6.2 API 限流429 rpm exhausted现象迭代到第 6 轮LLM 返回HTTP 429: {error:{message:rpm exhausted}}扫描中止。根因SenseNova API 有每分钟请求数限制。Agent 每轮调一次 LLM工具执行快时一分钟跑十几轮超限。修复三层防御# 第一层请求间最小间隔主动限速classmethoddef_rate_limit_wait(cls)-None:min_interval2.0# 秒elapsedtime.time()-cls._last_call_timeifelapsedmin_interval:time.sleep(min_interval-elapsed)cls._last_call_timetime.time()# 第二层429 专用指数退避 随机抖动staticmethoddef_backoff_429(attempt:int)-float:wait5.0*(2**attempt)random.uniform(0,2.0)returnmin(wait,120.0)# 上限 2 分钟# 第三层429 重试 8 次其他错误只重试 3 次max_429_retries86.3 侧边栏焦点虚线框现象点击侧边栏导航按钮后按钮周围出现矩形虚线框。根因Qt 默认给焦点控件画指示器。深色主题下特别突兀。修复QSS 加outline: none;。6.4 英文思维链现象LLM 的 reasoning 用英文输出虽然回复和报告是中文。根因系统提示词没要求思考过程也用中文。修复在系统提示词开头加强制指令## 语言要求强制 - 所有思考reasoning、分析、回复、总结必须使用简体中文。 - 禁止使用英文思考或回复。6.5 漏洞查找能力不足现象扫描完成后发现漏洞数量少漏报率高。根因系统提示词对扫描流程指导太笼统。修复重写系统提示词加入四阶段工作流和漏洞判断要点。特别是加了「漏洞判断要点」一节把每种漏洞的判断信比如「注入后返回 500/数据库报错」「注入script后响应体原样包含该字符串」。该字符串」。这比泛泛地说「检测 SQL 注入」有效得多。七、技术前景与当下影响7.1 Agent 范式正在成为主流“Agent” 已经从模糊概念变成可工程化的架构模式。核心要素就三个LLM 做决策、Tools 做执行、Loop 做迭代。这套架构不只适用于安全审计——任何需要「自主规划 工具调用 迭代验证」的任务都能用。但 Agent 工程化有几个独特挑战是这个项目踩过的频率控制。LLM API 不是无限流的。一个 Agent 跑 40 轮迭代每轮调一次 LLM很容易触发限流。需要主动限速 被动退避 差异化重试。这个项目用 2 秒最小间隔 指数退避 随机抖动三层防御实测能稳定跑完 40 轮。编码处理。LLM 的输出经过 SSE 流、JSON 解析、UI 渲染多层转码任何一环的编码假设错误都会导致乱码。这个项目的 bug 就出在 requests 库默认用 ISO-8859-1 解码 SSE 流——一个只有非 ASCII 字符才会触发的隐蔽 bug。线程安全。LLM 推理在后台线程UI 在主线程信号跨线程传递。Qt 的信号槽机制本身是线程安全的但需要保证 worker 线程结束时所有排队信号都已投递——否则 UI 上的断言会时序失败。7.2 本地决策模型的崛起laya 的使用代表一个趋势**不是所有 AI 判断都需要调云端大模分级这个任务——给定一条漏洞信息判断 high/medium/low——不需要 70B 参数的通用模型。的通用模型。一个专门的决策模型在 CPU 上 200ms 就能完成不需要联网不需要 API Key不消耗 token 额度。这种「云端 LLM 做复杂推理 本地模型做快速判断」的混合架构在边缘计算和隐私敏感场景下会越来越常见。安全审计尤其适合——扫描结果不应该上传到第三方做分级。7.3 AI 代码智能体改变开发方式用 CodeArts 开发这个项目的过程本身就是 Agent 范式在软件开发领域的应用。CodeArts 读了项目代码、写了新模块、跑了测试、修了 bug、做了重构——和 VulnAgent 扫漏洞的过程本质上一样给一个目标自主规划调用工具验证结果迭代改进。这说明 Agent 范式不限于安全审计。写代码、做运维、数据分析——任何有明确工具链和验证手段的领域都可以用这套架构。2025 年下半年我们正在看到 Agent 从概念走向工程从demo走向产品。7.4 不足与展望漏报率仍然偏高。对于复杂漏洞链SSRF → 内网探测 → Redis 未授权 → RCELLM 很难在 40 轮迭代内完整发现。工具粒度不够细。当前 22 个工具偏粗——sql_injection_check内部固定了几种 payload不能根据目标特征动态调整。多目标并行扫描。当前架构是单线程单目标的对于大型资产清单需要多 Agent 并行能力。未来最值得探索的方向是多 Agent 协作一个 Agent 做侦察一个做漏洞验证一个做代码审计结果汇总到协调 Agent 做去重和分级。这比单 Agent 大循环更可控、更高效。八、写在最后这个项目从最初的「让 LLM 调工具扫漏洞」的想法到最后 43 个源文件 6930 行代码、326 个测试、7 个 UI 页面、laya 分级集成、5 个工程 bug 修复——整个过程用华为云码道 CodeArts 代码智能体驱动开发从规划到交付大HarnessEngine 的循环 工具注册表 信号回调这三层抽象把复杂度控制在了可管理范围内。管理范围内。添加一个新工具只需要写一个Tool子类注册到build_registry()LLM 自动就能用它。添加一个新 UI 页面只需要继承TaskRunnerPage实现build_form和collect_task侧边栏自动就多一个入口。这种扩展性是 Agent 架构相比传统扫描器的根本优势。规则引擎添加一条新规则需要改规则文件、改扫描逻辑、改报告模板。Agent 架构添加一种新漏洞检测能力只需要加一个工具——LLM 自己会学会什么时候用它。这就是 Agent 范式的承诺不是写一个更聪明的扫描器而是造一个会自己变聪明的审计师。开源仓库https://atomgit.com/qq_36034945/vulnerability-scanning-agent技术栈Python 3.12 PySide6 6.11 DeepSeek V4 Flash laya 0.3.5 torch 2.14 transformers 5.17项目规模43 源文件 6930 行 | 326 测试全绿 | 22 工具 | 7 页面 UI开发工具华为云码道 CodeArts 代码智能体