★ FEATURED ARTICLE 1. 从一次“原地打转”的漏洞挖掘任务说起如果你正在做 AI 漏洞挖掘 Agent大概率遇到过这种场景Agent 对着一个开源项目跑了三十多轮日志里全是重复的编译报错和相同的无效 Payload最后给出的结论还是“未发现漏洞”。我试过把基座模型从 7B 换到 70B结果只是每轮推理更慢重复试错的次数一点没少。问题不在模型参数而在 Agent 根本没有“记住失败”的能力。AI 漏洞挖掘 Agent 的记忆中心就是专门解决这个问题的模块。它把漏洞挖掘过程中产生的目标信息、代码路径、输入格式、候选 PoC、失败证据、验证状态和下一步约束从易失的会话上下文里剥离出来做成结构化、可持久化、可检索、可复用的工程资产。适合谁适合正在自研安全 Agent 的开发者、红队研究员以及想把代码审计流程自动化的工程师。扫地僧 MopMonk 在 CyberGym 评测里用中端基座拿到 73.1% 胜率靠的就是这套记忆读写与复用链路而不是模型本身的“脑洞”。这篇文章不聊榜单排名只拆可落地的部分记忆中心怎么存、怎么召回、怎么在攻防任务里回放验证以及共享记忆池带来的投毒风险怎么排查。你可以把下面的配置片段直接搬到自己的 Agent 上跑一遍。2. 传统漏洞挖掘 Agent 的记忆缺陷与 MopMonk 的解法2.1 会话式短记忆为什么必然重复试错市面上多数漏洞挖掘 Agent 直接把聊天历史当记忆用 ReAct 短循环迭代。漏洞挖掘会产生大量噪声编译报错、崩溃堆栈、超时日志、非法输入回显。这些噪声和有效线索混在同一个上下文窗口里窗口很快被填满。每一轮推理模型都要在混乱记录里重新筛选上一轮刚确认“这个分支不可达”下一轮就忘了继续测同一个分支。本质是单次随机试错没有经验沉淀。2.2 全量长上下文为什么反而更糟有人用长上下文硬扛把整个项目源码和全部日志一次性灌进去。大模型注意力有上限内容越多关键信息抓取精度越低。实测下来Agent 明明已经测出某段代码有越界风险却因为上下文里堆了太多无关模块转头去分析另一个文件。长上下文把“漏洞挖掘”降级成了“海量文本检索”算力消耗翻倍收敛速度反而下降。2.3 MopMonk 的核心思路把失败变成约束MopMonk 的做法是独立搭建持久化记忆中心不依赖会话存储。它把数据拆成七类结构化记忆对象漏洞目标记忆、代码路径记忆、输入格式记忆、候选 PoC 记忆、负面证据记忆、验证状态记忆、下一步约束记忆。其中负面证据记忆和下一步约束记忆是收敛的关键——每次失败测试都被结构化存储约束推导模块从中提炼刚性边界让后续测试范围持续缩小。基座模型只负责推理和代码生成记忆读写和调度全部由独立层完成。2.4 记忆中心的最小可用架构一个可落地的记忆中心至少包含三层持久化存储层JSON/SQLite/向量库、记忆调度层读写路由、召回排序、冲突检测、Agent 推理层。存储层按记忆类型分文件或分表调度层负责在每轮任务开始前召回相关记忆片段推理层只拿到精简后的上下文。下面给出可直接复制的配置。3. 可复制的记忆中心配置片段3.1 记忆存储目录与 JSON 结构先建目录再写初始记忆文件。路径和字段名保持和下面一致后续脚本才能直接跑。mkdir -p ./mopmonk_memory touch ./mopmonk_memory/code_path_memory.json touch ./mopmonk_memory/negative_evidence.json touch ./mopmonk_memory/constraint_memory.json touch ./mopmonk_memory/poc_candidate.jsoncode_path_memory.json初始内容{ invalid_path: [], valid_path: [], last_update: 2025-01-01T00:00:00 }negative_evidence.json初始内容{ failed_inputs: [], safe_paths: [], compile_errors: [] }constraint_memory.json初始内容{ current_constraint: [], history_constraint: [] }poc_candidate.json初始内容{ pending: [], verified: [], failed: [] }3.2 Agent 侧记忆读写配置TOML如果你用 Python Agent 框架可以用 TOML 管理记忆中心参数。下面这份配置把召回条数、置信度阈值、过期时间都写死了避免运行时随意膨胀。[memory_center] base_path ./mopmonk_memory recall_top_k 5 confidence_threshold 0.75 constraint_ttl_hours 24 negative_evidence_ttl_hours 72 enable_cross_agent_share true write_require_verify true [memory_center.recall] code_path_weight 0.3 negative_evidence_weight 0.4 constraint_weight 0.3 [memory_center.write] min_verify_count 2 require_agent_id truewrite_require_verify true表示任何记忆写入必须经过至少两个 Agent 交叉验证这是防投毒的第一道闸。min_verify_count 2对应单次测试不允许标记永久无效路径。3.3 记忆召回与写入的最小代码import json import os from datetime import datetime, timedelta MEMORY_PATH ./mopmonk_memory def load_json(name): with open(os.path.join(MEMORY_PATH, name), r, encodingutf-8) as f: return json.load(f) def save_json(name, data): with open(os.path.join(MEMORY_PATH, name), w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) def recall_constraints(): data load_json(constraint_memory.json) now datetime.now() valid [] for c in data[current_constraint]: created datetime.fromisoformat(c[created_at]) if now - created timedelta(hours24): valid.append(c) return valid[:5] def write_negative_evidence(agent_id, payload, reason): data load_json(negative_evidence.json) data[failed_inputs].append({ agent_id: agent_id, payload: payload, reason: reason, verify_count: 1, created_at: datetime.now().isoformat() }) save_json(negative_evidence.json, data)这段代码只做两件事召回未过期的约束写入一条待验证的负面证据。注意verify_count初始为 1只有被第二个 Agent 复测确认后才会变成 2才允许进入永久无效路径列表。3.4 多 Agent 共享记忆的权限配置如果多个 Worker Agent 共享同一个记忆池必须做权限隔离。下面这份 settings 片段把写入权限按 Agent 角色分开{ memory_acl: { code_scan_agent: [code_path_memory:write, target_memory:write], poc_build_agent: [poc_candidate:write, input_format:read], sandbox_agent: [negative_evidence:write, verify_status:write], constraint_agent: [constraint_memory:write, negative_evidence:read], default: [*:read] } }default只有读权限任何未注册 Agent 不能写记忆。constraint_agent是唯一能改约束记忆的角色避免低质量数据污染收敛核心。4. 验证请求与成功结果记忆写入、召回与攻防回放4.1 记忆写入测试先跑一次写入确认负面证据能落盘。write_negative_evidence( agent_idsandbox_agent_01, payloadA * 1024, reasonbuffer length 1024 no crash, return 0 )执行后查看negative_evidence.json应该看到failed_inputs里多了一条记录verify_count为 1。再跑一次相同 payload如果系统正确应该拒绝重复写入或提示已存在。4.2 记忆召回测试模拟下一轮任务开始召回约束和负面证据。constraints recall_constraints() print(json.dumps(constraints, ensure_asciiFalse, indent2))如果constraint_memory.json里有一条“禁止使用长度 1024 的 A 字符填充”召回结果应该包含它。召回条数受recall_top_k 5限制不会把全部历史灌进上下文。4.3 攻防任务回放与效果对比准备一个已知漏洞的测试项目比如带栈溢出的小型 C 程序。分别用“无记忆中心”和“启用记忆中心”跑同一任务记录轮次和结果。指标无记忆中心启用记忆中心总迭代轮次3814重复无效 Payload 次数213漏洞定位耗时约 26 分钟约 9 分钟是否命中目标漏洞否是回放时重点看negative_evidence.json的增长曲线无记忆中心时该文件不存在Agent 每轮都在会话里重新试错启用后失败输入被持久化约束记忆每轮收紧迭代轮次明显下降。4.4 验证记忆是否真正被复用在第二轮任务开始前打印当前召回的记忆片段确认包含上一轮的失败约束。如果召回为空检查constraint_ttl_hours是否设置过短或者created_at格式是否解析失败。成功的结果是Agent 在第二轮直接跳过已标记无效的代码路径不再生成相同格式的 Payload。5. 本篇常见错误排查5.1 401 Unauthorized 与 local proxy failed如果你在调用模型接口时遇到401 Unauthorized先检查 API Key 是否写进了环境变量而不是硬编码在脚本里。local proxy failed通常出现在 Base URL 配置错误时比如把https://taotoken.net/api写成了带路径的完整端点。正确做法是 Base URL 只写到/api具体路径由 SDK 拼接。如果你用 Claude Code 或 Cline MCP三件套必须写全Base URL、API Key、Model ID缺一个都会报鉴权失败。5.2 reading choices 报错与 OAuth 失效reading choices报错一般出现在流式响应解析阶段原因是返回体不是标准 OpenAI 格式或者 Model ID 写成了不存在的名称。检查你的 Model ID 是否和平台文档一致。OAuth 失效则多发生在 Codex 的auth.json场景Token 过期后需要重新生成。如果你用auth.json管理凭据确认文件路径和权限正确且没有被其他进程锁定。5.3 记忆文件写入冲突多 Agent 同时写同一个 JSON 文件会导致内容覆盖。排查方法是看negative_evidence.json是否出现记录丢失。解决方式有两种给每个 Agent 分配独立临时文件由调度层合并或者改用 SQLite 并开启 WAL 模式。如果你坚持用 JSON至少加文件锁。5.4 约束记忆过度收紧导致空转如果constraint_memory.json里的test_range变成empty且valid_rate低于 0.8Agent 会无测试可做。这是约束推导模块把范围收得太死。排查时看history_constraint找到最后一条把范围设为空的规则手动回滚或增加过期重置。防御方案里提到的“记忆过期与重置机制”就是针对这个场景。5.5 外部资源引入的虚假记忆如果 Agent 读取了外部文档后code_path_memory.json里出现大量未经本地验证的无效路径标记说明外部数据直接污染了核心记忆。检查write_require_verify是否为 true以及外部解析是否走了独立沙盒。正确流程是外部数据先进入临时区经本地复测确认后才写入正式记忆。6. 把记忆中心接进你的 Agent 工作流6.1 接入前的准备先确认你的 Agent 已经能完成单轮代码扫描和 PoC 生成。记忆中心不替代推理能力只负责沉淀和召回。准备好 API Key 和 Base URL 后把上面的 TOML 和 JSON 片段放进项目目录跑一遍写入和召回测试。6.2 推荐接入顺序第一步只启用负面证据记忆观察失败输入是否被持久化。第二步加入约束记忆让每轮迭代收紧范围。第三步开启多 Agent 共享和权限隔离。第四步加入投毒检测脚本定期扫描记忆文件。不要一次性全开否则出问题很难定位是哪一层。6.3 长期编码与 Agent 场景的配置建议如果你要把这套记忆中心用于长期运行的漏洞挖掘 Agent建议把constraint_ttl_hours设为 24negative_evidence_ttl_hours设为 72避免记忆无限膨胀。多 Agent 场景下enable_cross_agent_share打开但write_require_verify必须保持 true。模型对话调试可以用轻量接口长期编码任务建议走 Coding Plan减少频繁鉴权带来的中断。6.4 验证模型与排障入口记忆中心跑通后可以用模型对话快速验证召回内容是否符合预期。如果遇到鉴权或接入问题先查 API Keys 和接入文档再检查 Base URL 和 Model ID 三件套是否完整。排障时优先看记忆文件的last_update时间戳确认写入是否真的发生。6.5 一个容易忽略的细节记忆中心的召回排序权重不要写死。code_path_weight、negative_evidence_weight、constraint_weight三个值应该根据任务阶段动态调整代码扫描阶段提高路径权重PoC 生成阶段提高约束权重验证阶段提高负面证据权重。你可以在调度层加一个简单的阶段判断按阶段切换权重收敛速度会再快一截。
阅读完成 · 觉得有帮助？
