ARTEX 將最終版本保留為純原始碼備份

ARTEX’s maintainers are preserving the autonomous penetration-testing system’s final version as a pure-source backup. The former autumn27/artex Docker image is unavailable, so the repository now directs users to the maintained mianhuatang11/artex image or a local source build. Developers evaluating or operating ARTEX should note that these deployment paths have different update behavior, as documented in the project repository.

The project describes ARTEX as the champion entry in Baidu’s “agent+” attack-and-defense competition. That designation is the maintainers’ description and should not be read as independent verification of either the contest result or the system’s effectiveness against real targets. The repository page is the source of the claim.

A planner, workers and two linked graphs

ARTEX combines a Go monolithic backend, a statically exported Next.js frontend embedded in the Go binary, and PostgreSQL storage. Exploration requires an LLM configuration through Anthropic or OpenAI credentials or the application’s interface. Its documented agent roles include goal decomposition, a planner, multiple workers and a human-in-the-loop main agent. The architecture documentation describes these components.

The system separates its data into two linked structures. A shared asset graph stores domains, subdomains, IP addresses, services, applications and endpoints. A task-specific exploration graph stores goals, intents, facts, findings and hints, while anchors associate those records with individual assets. This separation supports both an investigation’s lineage and asset-level coverage views, according to the dual-graph design.

The planner reads the exploration state and dispatches uncovered directions as intents. Workers claim one intent at a time, run tools and write resulting assets, facts or findings back to the graphs; those changes can wake the planner for another cycle. Workers can also search traces from other work items in the same task, excluding their own current trace. The engine documentation specifies this event-driven loop and cross-worker search.

Controls around execution and retesting

ARTEX documents a recording MITM proxy for tool traffic and guard and intercept components that provide approval gates. Its interface exposes activity streams, approval records, traffic recordings, asset coverage and human-in-the-loop conversations. The repository’s subsystem and interface documentation lists those controls and views.

Vulnerability retesting runs in a separate agent session rather than restarting the original scan. A retest can conclude that an issue remains reproducible, has been fixed or cannot be confirmed. A successfully completed retest marked as fixed can update the vulnerability’s status automatically, while the original evidence and report remain available. The retesting documentation defines that workflow.

Deployment has two update layers

The installation script supports either an all-Docker deployment or a locally compiled application, while Docker Compose and a manual source build are also documented. The backup repository does not host precompiled binaries; it instead refers users to releases from the original repository when available. The installation instructions describe these options.

ARTEX’s in-application updater replaces the program but not the Docker image. The documentation warns that tools bundled in the image, including Playwright and nmap, are not updated through that path, and recreating the container restores the application version included in the image. Updating the full environment instead requires pulling and recreating the ARTEX container. The update documentation distinguishes these procedures.

Analysis — ARTEX effectively treats the application binary and its containerized security toolchain as separate release units. The unresolved operational issue is release coordination: an application-only update leaves bundled tools unchanged, while container recreation can replace the application with the image’s bundled version. Teams adopting ARTEX should therefore decide which combination constitutes a tested deployment and track both layers rather than treating the two update paths as interchangeable. This interpretation follows from the project’s documented Docker update behavior.