新的一个开源 AI黑盒 Harness驱动的渗透测试终端

马背上的黑子

2026年6月29日 16:12
云南

在小说阅读器读本章

去阅读

编者荐语：

用了下，工业水平拉满

以下文章来源于明夷数字安全
，作者MingyiLab

明夷数字安全
.

面向真实攻击面的数字安全平台，专注资产暴露面识别、持续监测与智能攻防，探索 AI 驱动的自动化安全防护能力。

当大家都在反复聊 Harness Engineering，我们把它做成了一个开源 AI 渗透测试终端

这段时间，大家开始反复聊一个词：Harness Engineering。

怎么给模型组装工具，怎么管理上下文，怎么做记忆，怎么让 Agent 跑长程任务不崩，怎么把“会聊天的模型”变成“能持续完成任务的系统”。这些问题，已经越来越不像 prompt 技巧问题，而更像系统工程问题。

我们开源 Mingyi Atlas，(https://github.com/MingyiSecLab/Mingyi-Atlas)就是想正面回答这些问题。

先说清楚一点：Mingyi Atlas 不是从零重新发明一个 Agent CLI。 它是基于 Mastra 的编程 CLI mastracode 进行二次开发，并结合 pu-tui 的终端交互能力，继续把 Agent 的运行结构往前推进。我们做的，不是再包一层聊天界面，而是沿着现有 harness 体系，把工具调度、上下文管理、记忆、长程任务和授权安全评估工作流，做成一个更完整的终端 Agent 系统。

从这个角度看，Mingyi Atlas 想解决的问题其实很明确：

不是把某个模型塞进终端里，而是把模型装进一个可执行、可恢复、可约束、可扩展的任务系统里。

我们做的不是“聊天 CLI”，而是任务型 Agent Harness

今天很多 AI 产品，本质上还是“对话框 + 几个工具”。

它们在短任务里看起来很聪明，但一旦任务开始变长、变复杂，问题就会迅速暴露出来：工具很多，但模型不会稳定选择；上下文越来越长，但真正有用的信息留不住；任务跑了几轮以后开始重复、偏航、失忆；目标只存在对话里，系统并不知道这件事是否完成、应该继续多久、什么时候该停。

所以在 Mingyi Atlas 里，我们优先搭建的不是“聊天体验”，而是 Agent 真正跑起来所需的基础层：模式切换、动态工具暴露、本地工作区与执行环境、持久化上下文、记忆与召回、Goal 模式、子 Agent 协作，以及安全边界和结构化证据沉淀。

换句话说，我们不是在给模型堆功能，而是在给任务建系统。

支持任意模型接入，但不把系统绑死在模型上

这是 Mingyi Atlas 一个很重要的特点。

我们不希望它变成某一个模型、某一家 provider 的专用外壳，所以从一开始，就尽量把 harness 层和模型层解耦。项目既支持内置 provider，也支持通过自定义 provider 和 OpenAI-compatible 方式接入模型。无论是公开模型、私有部署模型、统一网关后的模型，还是团队内部封装过的模型入口，只要能接入运行时，就可以进入同一个任务系统。

这件事的意义，不只是“模型选择更多”，而是：

模型可以换，但 Agent 的运行结构不需要跟着重写。

也就是说，工具调用、上下文注入、记忆召回、长程任务推进、子 Agent 协作、权限控制和安全边界，这些都不应该依赖某一个固定模型生态。我们更在意的是：先把任务系统搭起来，再让模型插进来，而不是反过来让系统被模型锁死。

工具不是越多越好，关键是模型在什么时候看到什么工具

很多人聊 Agent，第一反应就是 tool use。但真正难的不是“有没有工具”，而是：

模型在当前任务里，到底该看到哪些工具。

如果一个系统把所有工具一股脑暴露给模型，结果通常不是更强，而是更乱。选择成本变高，误用概率变高，推理空间也变得发散。

所以在 Mingyi Atlas 里，工具暴露是动态的、按模式切换的。普通模式下，它更像一个面向软件工程的终端 Agent，围绕本地工作区、代码读写、命令执行和项目理解来工作。切到 pentest mode 后，工具面则会切换到授权安全评估语境。

为了更直观一些，也可以直接看当前工具能力面：

通用工具能力

Pentest 工具能力

这背后的逻辑很简单：工具不是给模型炫技的，而是给任务收敛解空间的。

但另一件同样重要的事是，真实任务很少靠单个工具完成。一个可用的 Agent 系统，不只是“有工具”，还要能把 multi-tools 串成稳定流程。

比如在安全评估场景里，一次完整验证往往不是某一个探针单独完成的，而是多个工具协同：先用 HTTP 请求建立基线，再结合认证识别、前端端点提取、浏览器自动化或容器化辅助工具补证据，最后再把结果沉淀到 finding 和 report 流程里。对于软件工程任务也是一样，项目搜索、文件读取、命令执行、LSP 检查、技能指引，往往需要在同一个 harness 内形成配合，而不是彼此孤立。

所以我们关注的不是“有多少工具”，而是 工具之间能否在同一个任务闭环里协同工作。这也是 Harness Engineering 里非常容易被低估的一层。

上下文管理，不是把所有东西都塞进 Prompt

现在很多人也在聊 Context Engineering，但很多实现最后只是“把更多内容塞进 prompt”。这远远不够。

真正的问题不是“能不能塞进去”，而是：什么信息属于系统级规则，什么属于项目级上下文，什么只属于当前线程，什么应该结构化持久化，什么不应该污染长期记忆。

在 Mingyi Atlas 里，我们尽量把上下文分层处理，而不是揉成一团。模式级上下文决定 build、plan、fast、pentest 的行为规则；项目级上下文来自项目说明、指令文件和技能文件；线程级上下文保存当前会话状态、模式、目标和工作目录；工作流上下文保存 scope、asset、endpoint、finding、retest queue 等结构化信息；工作区上下文则对应文件系统、沙箱、LSP 和命令环境。

这样做的意义在于，上下文不再只是“聊天记录”，而是一套可分层、可恢复、可裁剪的运行时信息。我们理解的 Harness Engineering，也不是拼命拉长上下文窗口，而是先决定什么信息该放在哪一层。

记忆不是聊天归档，而是任务连续性的基础设施

长任务为什么难？因为模型天然不擅长稳定地“记住一件事并持续推进”。如果只靠对话历史，任务一长，信息就会越来越乱，重点越来越模糊。

所以在 Mingyi Atlas 里，我们引入了持续记忆机制，而且不是简单做消息堆积，而是把观察、压缩、反思、召回当成系统能力的一部分。真正重要的不是“记更多”，而是：什么值得留下，什么应该被压缩，什么需要跨轮次复用，什么不应该进入长期记忆。

尤其在有动态项目指令、技能文件和工作流提示的场景里，这一点非常重要。否则很多临时上下文会直接污染后续任务。对我们来说，记忆服务的不是对话连续性，而是任务连续性。

长程任务不崩，靠的是 Goal，不是硬撑多轮对话

“怎么让 Agent 跑长程任务不崩”，是最近最值得认真讨论的问题之一。

我们的判断是：不能只靠多轮对话一直往下续。必须把“目标”从聊天内容里拿出来，变成系统中的正式对象。

所以 Mingyi Atlas 提供了 Goal 模式，用来管理持续目标，而不是只管理一段对话。目标有自己的状态、轮次、判断逻辑和恢复机制，可以暂停、继续、完成，并在线程层持久化。

这背后的工程思想很朴素：任务不能只存在于语言里，还要存在于状态里。

只有这样，系统才真正知道当前为什么继续、已经做到哪一步、是否偏离目标、什么时候该停、什么算完成。这也是 Harness Engineering 和“会多轮聊天的产品”之间最本质的区别之一。

Pentest Mode 的重点，不是多了几个安全工具，而是多了一套安全工作流

Mingyi Atlas 里最有代表性的部分，是 pentest mode。

但它的价值并不只是“支持做安全测试”，而是我们试图把授权安全评估里的工作流、角色分工、边界约束和证据链，做成 Agent 可执行的结构。

所以在 pentest mode 下，系统不是简单地挂上一堆探测工具，而是补上了一整套围绕安全评估展开的运行结构。任务会被拆成攻击面梳理、认证分析、漏洞验证、finding judgment、报告生成等不同阶段。与此同时，系统还提供专门的子 Agent 来负责攻击面、认证、验证和 finding 复核，但最终责任仍然保留在主 Agent：它要负责授权确认、范围控制、工具选择、证据复核、finding 决策和最终汇总。

更重要的是，安全场景里的边界必须更硬。所以我们明确要求：仅限授权测试；不做破坏性动作；不做凭证窃取、暴力破解、持久化、拒绝服务；不越权测试未授权范围；CAPTCHA 只检测，不自动绕过；finding 必须结构化记录，并区分 candidate、validated、false-positive 等状态；结论必须基于证据，而不是基于“模型觉得像”。

换句话说，pentest mode 的核心不是“更 aggressive”，而是更结构化、更可约束、更可复核。

开源

我们把 Mingyi Atlas 开源，不只是为了发一个项目。

更重要的是，我们觉得今天关于 Agent 的讨论，正在从“模型能力竞争”转向“系统工程竞争”。真正决定一个 Agent 能不能从 demo 走向可用系统的，越来越不是模型本身，而是这些工程问题：工具如何按场景暴露，上下文如何分层，记忆如何压缩与召回，长任务如何定义与恢复，子 Agent 如何分工与收束，高风险场景如何做边界治理，finding、证据、报告如何结构化沉淀。

这些问题如果不在 harness 层解决，模型再强，也很容易只做出一个“偶尔看起来很聪明”的演示系统。

而我们更想做的，是一个基于 mastracode 持续演进、支持任意模型接入、能真正进入软件工程和授权安全评估现场的开源终端 Agent。

这个项目本身就适合社区持续参与，而且参与门槛并不高。

如果你只是对方向感兴趣，最直接的参与方式就是提 issue，反馈你在真实任务里遇到的问题、你觉得当前模式覆盖不够的场景，或者你希望 harness 层补齐的能力。对于一个 Agent CLI 来说，很多真正重要的改进，本来就来自具体任务中的摩擦点，而不是来自抽象讨论。

如果你希望进一步参与开发，路径也很清晰。你并不一定需要一上来就改动核心 runtime，很多扩展都可以从相对独立的层开始：

• 扩展 tools，补充新的模型可调用能力
• 扩展 skills，补充新的方法论、任务指引和工作流知识
• 扩展 workflow，把多工具协作沉淀成更稳定的执行流程
• 扩展 mode，为新的任务域定义独立的运行边界、工具集和行为规则

这也是我们想把结构做清楚的原因。只有当工具、技能、工作流和模式边界足够清晰，社区协作才不会变成“大家都在同一坨 prompt 上缝缝补补”。

从路线看，pentest mode 不是终点。后续我们也会继续往更多任务域扩展，比如 redteam mode、逆向分析相关 mode，以及更多围绕安全研究与复杂任务执行的模式化能力。对我们来说，这些 mode 的意义不只是“多几个入口”，而是继续验证一件事：当任务域变化时，harness 该如何重新组织工具、上下文、记忆、工作流和边界。

不是纸面设计，我们已经在实战场景里持续使用

对我们来说，Mingyi Atlas 不是一个停留在概念层的开源项目，也不是为了展示某种 Agent 设计思路而单独做出来的样板。

它之所以会长成现在这样，恰恰是因为我们已经在真实场景里持续使用它，并且不断根据反馈去调整结构。无论是在实战攻防演练、SRC 场景，还是日常渗透测试里，Mingyi Atlas 都已经产出过实际结果。这也是为什么我们会特别在意模式切换、multi-tools 协同、结构化 finding、长程任务管理，以及严格的安全边界。

因为一旦进入真实任务现场，很多问题会立刻变得非常具体：上下文一长就乱，工具一多就散，任务一久就漂，证据链一断结论就不稳。也正是在这些实际使用过程中，我们越来越确认，Harness Engineering 不是一个抽象概念，而是决定 Agent 能不能真正落地的核心工程问题。

某种意义上，Mingyi Atlas 的很多设计，不是先有一套完美理论再来实现，而是在真实攻防、SRC 和日常测试过程中，一点点把“什么东西必须结构化、什么东西必须持久化、什么边界必须前置约束”打磨出来的。

最后

如果要用一句话概括 Mingyi Atlas，我们会说：

它不是把某个模型接进终端，而是把模型装进一个可执行、可恢复、可约束、可扩展的 harness 里。

这也是我们理解的 Harness Engineering。

Agent 从来不是“模型自己跑起来了”。
Agent 是你先把工具、上下文、记忆、目标、状态、边界和协作结构搭好，模型才真正开始具备稳定生产力。

而这，正是 Mingyi Atlas 想回答的问题。

期待更多的朋友一起参与开发社区，提一个iss、提出问题、提出新的需求都是在一起开发，期待你的加入！