我的开源项目：python依赖安全修复助手
项目地址，dep-safe-agent。
项目介绍
dep-safe-agent，是一个python依赖安全修复助手，输入一个本地git仓库，即可完成依赖解析、cve检测、可达性分析、changelog读取、最小化修复、测试验证、最终提pr并生成报告。
项目优势
相比dependabot，我们的agent有以下优势：
- 分析漏洞函数的可达性从而在无真实调用的情况下不做多余升级；
- 读取版本变更changelog，分析是否存在破坏性变更，辅以运行项目自带测试套件，避免盲目升级导致项目崩溃；
- 选用最低修复版本进行升级，避免引入多余变更。
作为agent，它有以下亮点：
- 每一个失败路径都有降级策略，比如可达性分析在ast失效后会采用subagent探索代码文件，changelog从github获取失败后会采用subagent联网搜索获取信息，修复过程任何失败都会降级为提github issue。
- 特别的人工审核方式，项目不是human-in-the-loop，而是after，启动agent之后只需在github页面审批pr或issue或阅览安全修复报告即可。
- 评估完整，按行为类别分类设计包括breaking upgrade、simple bump、multi vulns等，双层指标，一层评估pipeline是否健康，比如完成率、预算耗尽率，另一层评估决策是否正确，比如修复版本是否正确、pr卫生如何、回归测试是否通过等，覆盖所有路径。
项目关键决策
bash降级
项目借鉴了swe-agent的模式但之将其作为降级路径，标准工作流只需调用自定义工具比如check cve、get changelog等，但是允许使用bash应对意外情况，提升容错率，比如使用bash寻找依赖文件等。
批间上下文重置
上下文管理，消息列表在多轮扫描之间就行重置，因为漏洞之间的修复上下文相对独立，重置影响较小且极大降低上下文管理的复杂度。另外，设置了0.85阈值，达到后会对工具结果进行裁剪，并进行结构化摘要，包括当前漏洞元信息、changelog、可达性等信息。
评估流程？
首先介绍一下项目的评估部分，整体上行为分类、两层指标。
以一个失败案例为例介绍流程，multi_vuln类里的flask-pyyaml，系统输入就是扫描漏洞这个指令，预期输出是flask与pyyaml各提一个pr，但是实际输出是只有flask提了一个，分析发现是扫描器一轮扫描5个，多轮扫描并没有生效，原来是提示词写成了单轮扫描的标准工作流，要求agent扫描后直接提交终止，修复方式为更改提示词为单轮扫描后要求继续调用scan扫描直至返回空列表，回归测试后发现仍出现偶发的只扫描单轮，于是将轮转逻辑写成代码，由代码循环负责多轮扫描，回归测试始终成功。