artex-ko - 把自主渗透测试多智能体系统本地化为韩语的分支

artex-ko 是一个由 LLM 多智能体驱动的自主渗透测试系统的韩语本地化分支。据项目自述，它让多个由大模型指挥的智能体自行拆分目标、调用真实工具、把发现的资产与漏洞累积进图结构，从而把渗透测试流程自主推进下去；后端是 Go 单二进制，内嵌 Next.js 前端，数据存放在 PostgreSQL 中。它面向的是需要阅读韩语产出的安全团队与研究人员，尤其是希望理解自主 AI 攻击如何运作、以便构建检测与加固能力的防守方。项目在 README 中反复强调：只能在自有或获得书面明确授权的目标上使用，建议在本地隔离的靶场环境中验证。

维护者与状态

仓库由 jiwoochris 维护，地址为 jiwoochris/artex-ko。仓库创建于 2026-10-03，最后一次提交在 2026-10-07。截至 2026-10-07，星标数为 217，尚无正式 release。许可证为 AGPL-3.0。

据项目自述，这个仓库是 Autumn-27/ARTEX（AGPL-3.0）的韩语本地化版本，目标是让韩语用户和团队可以直接使用。为了保留智能体的判断性能，内部推理提示保持原文，只把面向用户的产出（探测结果、摘要、报告、对话回复）强制为韩语。

主要能力

以下能力均来自项目自述，未经本站实测。

• 多智能体自主渗透流程。据项目说明，系统由 goals、planner、worker、mainagent 四类角色组成，planner 是唯一的意图生成者，worker 负责执行，mainagent 处理人的介入。每个任务会启动一个 plannerLoop 和 N 个 worker goroutine，并处理意图分配、超时、暂停与排空。
• 双图结构。项目自述把「目标是什么」和「测到哪里了」拆成两张相互独立、通过锚点连接的图：资产图（assets / companies / task_scope）与探索图（exploration_nodes / anchors / activity）。
• 过程级信息交换与共享 todolist。据 README，系统围绕双图设置了两项自主性装置：worker 之间的过程级信息交换，以及 planner 的多轮共享 todolist。
• 流量记录代理。项目自述包含一个 MITM 记录代理，worker 的 Bash 与 HTTP 全过程会被记录，并配有 guard / intercept 工具审批闸门。
• 韩语产出。据项目说明，本地化通过 agent/prompt.go 中的 langDirective() 以提示指令方式诱导，而非硬编码上限；命令、载荷、代码、URL、日志原文保持原样以便分析。
• 韩国法律提示。README 中写明，本地化版本补充了《信息通信网法》与《个人信息保护法》的韩语提示，以及「仅在授权范围内使用」的警告。
• 可替换 LLM 供应商。据项目说明，除前沿模型外，也可以通过 OpenAI 兼容端点接入其他模型，相关环境变量包括 ARTEX_LLM_PROVIDER、ARTEX_LLM_MODEL、ARTEX_LLM_BASE_URL、ARTEX_LLM_PROXY。
• 界面模块。据项目自述，前端包含仪表盘、任务、资产、覆盖图、流量、工作区与系统设置等页面，漏洞结果可按严重度、状态、资产、所属任务聚合并导出 CSV。

使用入口

仓库地址：jiwoochris/artex-ko。

据项目说明，Docker Compose 路径的当前状态需要特别注意：docker-compose.yml 中的 artex 服务拉取的是上游作者发布在 Docker Hub 上的镜像，该镜像仍是中文界面与中文输出，并不包含本仓库新增的韩语本地化。项目自述韩语版 Docker 镜像的发布仍在准备中，因此目前要查看韩语界面与输出，需要走源码编译单二进制的路径。

项目自述的源码编译流程大致为：先构建前端静态产物，再同步进内嵌目录，最后带 embedui 标签编译。README 提醒，若 shell 中设置了 NODE_ENV=production，npm ci 会跳过 devDependencies 导致构建失败，此时应改用 npm ci --include=dev。运行时应使用 start.sh（Windows 为 start.bat）而不是直接执行二进制，因为该脚本承担了按退出码重启的守护职责，界面上的「一键更新」也由它处理。

配置方面，据项目说明，数据库可通过 config.json 或环境变量 ARTEX_PG_DSN 指定；LLM 可通过 ANTHROPIC_API_KEY 或 OPENAI_API_KEY 设置，也可在界面中填写。常用启动参数为 ./start.sh -addr :8787 -proxy :8788，前者是前端与 API 端口，后者是流量记录代理端口。

许可与限制

许可证为 AGPL-3.0。

项目自述中列出的已知限制与边界包括：

• 使用范围。只能用于自己拥有或获得书面明确授权的目标；未经授权对他人网络进行扫描、探测或利用可能构成违法。项目建议只在学习、研究以及本地隔离的靶场环境中验证。
• 输出语言依赖模型能力。据项目说明，韩语化由提示指令诱导，因此保持程度取决于模型能力与角色、上下文。README 称在本地隔离靶场的短验证中，默认模型与 gpt-4o 能保持韩语输出，而低价小模型（如 gpt-4o-mini）的报告会退回原文；worker 的短句摘要、report_finding 的结构化字段也可能偏向英语。
• 推理型模型的 token 预算。项目提醒，使用带独立思考通道的推理型模型时，若响应 token 上限过小，预算可能被内部推理耗尽，导致最终答复为空，应把对应 LLM 配置的 max_tokens 设得足够大。
• OpenAI 兼容路径的上限陷阱。据 README，OpenAI 兼容请求默认携带较大的输出上限（32,768），而部分模型（如 gpt-4o）的响应上限为 16,384，若不调整会以 400 (max_tokens is too large) 失败，需在 LLM 设置中把该配置的 max_tokens 降到 16,384 或以下。
• 反向代理部署。项目自述前端与 API/SSE 共用同一后端端口，实时活动流默认同源连接，因此无需单独设置 NEXT_PUBLIC_SSE_BASE；但反向代理必须关闭缓冲，否则浏览器能连上却收不到事件。
• 并发。每个任务的 worker 智能体数量可在系统设置中调整，项目自述默认值为 3。

需要说明的是，上述能力、配置与限制均来自项目自述，本站未运行过该项目，也未对其效果做任何验证。