artex/README.zh-translation.md

ARTEX 韩语版

由 LLM 多智能体自主执行渗透测试的系统（Go 后端 + Next.js 前端）

韩语 · 中文 · English

---

🚨 安全与滥用警告：请务必先阅读

本仓库仅面向获得授权的环境公开，用于培养防御与检测能力。

ARTEX 是一把极其强大的自主攻击工具，它几乎无需人工介入，就能自行完成从侦察到入侵、再到数据外带的整个攻击过程。相应地，滥用所造成的危害也极大。2026 年 10 月，韩国多家媒体报道称，调查当局发现原始 ARTEX 被用于针对韩国金融机构的个人信息泄露攻击的迹象，相关调查正在进行中。公开这个韩语版本的目的并非协助攻击，而是帮助防御方理解这类自主 AI 攻击的运作原理，并具备检测与阻断的能力。

• 未经授权的使用本身就构成犯罪。 除非目标是你自己所有、或已获得书面明确授权的对象，否则不要对任何系统执行扫描、探测或漏洞利用。在韩国，未经授权侵入信息通信网的行为违反《信息通信网法》，若涉及个人信息还会同时适用《个人信息保护法》。
• 不要以真实服务或他人资产为目标。 只在学习、研究以及你自己所有的本地隔离环境（如 OWASP Juice Shop、DVWA 这类故意做成存在漏洞的环境）中验证。
• 请从防御的视角来阅读。 本仓库同时整理自主 AI 攻击的检测特征与加固清单等防御/检测资料。→ 自主 AI 攻击防御与检测指南

如果你不同意本警告以及下面的 使用限制与免责，请不要下载或使用本仓库。

---

本仓库是将中国开源项目 Autumn-27/ARTEX（AGPL-3.0）本地化、以便韩国用户与团队直接使用的版本。 为保留智能体的判断性能，内部推理提示词保持原文不翻译，只强制将面向用户的产出（检测结果、摘要、报告、对话回复）输出为韩语。下方"为什么做韩语版"一节说明了这一方针。

ARTEX 是一个由 LLM 操控的多个智能体自行拆解目标、执行真实工具、并将发现的资产与漏洞不断累积到图中，从而自主推进渗透测试过程的系统。它将 Next.js 前端内嵌到单个 Go 二进制中，数据存储于 PostgreSQL。

---

⚠️ 请先阅读 — 使用范围与韩国法律告知

ARTEX 只能用于你自己所有、或已获得书面明确授权的对象。超出授权范围的扫描、探测、漏洞利用本身就可能违法。

• 在韩国，未经授权侵入他人信息通信网或造成故障的行为，违反**《信息通信网利用促进及信息保护等相关法律》**。
• 渗透测试过程中收集、暴露的个人信息受**《个人信息保护法》**约束。即便有授权，也必须谨慎处理个人信息的查阅、保管与销毁。
• 请用于学习、研究、本地隔离环境验证的目的。在针对线上外部系统之前，必须取得书面授权并就范围与时间窗口达成一致。

详细的许可证、使用限制与免责条款见下方 许可证与免责 一节。仅使用本工具即视为用户已同意其条件。

---

为什么做韩语版

原始 ARTEX 的提示词、UI、文档全部为中文，韩国用户阅读结果并与团队分享颇为麻烦。本韩语版的目标如下。

• 产出韩语化：强制智能体向人输出的检测结果、事实摘要、最终报告、对话回复使用韩语输出。命令、载荷、代码、URL、日志原文因为分析需要，保持原样。
• 性能保留：决定智能体判断的内部推理提示词（行为指令正文）不翻译。保持以原文基准测试过的行为，仅更改输出语言，避免翻译带来的质量下降。
• 韩国法律告知：以韩语明确提供《信息通信网法》《个人信息保护法》告知以及"仅在授权范围内使用"的警告。
• 韩国技术栈适配：LLM 提供方不仅可换用前沿模型，还可换成 OpenAI 兼容端点（国产/开源模型）。参见下方 配置。

本地化的边界与设计方针在本仓库的工作文档中有更详细的说明。为便于对照上游仓库的变更，原始中文文档以 README.zh.md 保留。

---

界面预览

以下三个界面是已完成韩语化的实际 UI。均为从本地隔离沙箱导出的演示数据，目标全部是虚构的 acme.com 与私有网段。

_{仪表盘：在一屏中查看活动任务、已确认漏洞、资产节点、LLM token 消耗与活动流。
此仪表盘截图是在本地化标签之前导出的演示画面，因此"LLM Token 消耗"卡片的数据源名称仍显示为代码标识符 llm_usage。当前构建在此处显示新版本「计量账本」/旧版本「活动统计」。}

_{漏洞：按严重程度、状态、资产、所属任务汇总检测结果，并可导出 CSV。
漏洞标题由模型生成，可能随目标应用与技术术语夹杂英文（参见[模型选择与输出语言](#模型选择与输出语言)）。标题下方的描述以及整个界面均为韩语。}

_{对话：在自主执行过程中人工介入给予提示，智能体以韩语总结攻击链。}

原始（中文 UI）的完整界面可在 README.zh.md 查看。

---

快速开始（Docker Compose）

前置条件： Docker 与 Docker Compose。数据库为 PostgreSQL，由 compose 一并启动。探测需要 LLM（ANTHROPIC_API_KEY 或 OPENAI_API_KEY，也可在 UI 中设置）。

⚠️ 目前此 compose 拉取的镜像是上游（原始）中文构建。 docker-compose.yml 中的 artex 服务拉取的是原作者上传到 Docker Hub 的 autumn27/artex 镜像。该镜像为中文 UI 与中文输出，尚不包含本仓库新增的韩语化（韩语 UI、韩语报告、langDirective）。要查看韩语版界面与输出，目前请使用下方「其他安装方式」中的从源码编译单二进制路径自行构建。韩语版 Docker 镜像的发布正在筹备中。

git clone https://gitea.mygoband.com/carrydela/artex.git
cd artex
cp .env.example .env          # 设置 POSTGRES_PASSWORD，ANTHROPIC_API_KEY 可选
docker compose up -d          # 一并启动 artex 镜像 + postgres
# → 访问 http://localhost:8787（首次进入时在 /setup 设置管理员密码）

上述上游镜像内置了常用工具（ripgrep、curl、vim、npm、nmap 等）。./skills 与 ./data 以 bind mount 方式保留在宿主机上，即使重建容器也会保留。

其他安装方式

原始仓库提供安装脚本（./install.sh）、预编译二进制（Releases）、源码单二进制编译等多种方式。命令与步骤整理在 README.zh.md 的"安装"一节，下面仅摘录要点。

• 安装脚本： 运行 ./install.sh 会检测并安装 Docker，然后让你选择"① 全部 Docker"或"② 本地编译运行"。但默认的"① 全部 Docker"与上述快速开始一样，会拉取上游中文镜像（autumn27/artex），因此要查看韩语版界面与输出，请选择"② 本地编译运行"，或按下述从源码编译单二进制路径构建。脚本在完成"① 全部 Docker"启动后也会输出同样的提示。

• 从源码编译单二进制：

  cd web && npm ci && npm run build:static && cd ..   # 1) 前端静态构建
  rm -rf server/webui/dist && mkdir -p server/webui/dist && cp -a web/out/. server/webui/dist/   # 2) 同步到内嵌目录（防止重建时嵌套）
  CGO_ENABLED=0 go build -tags embedui -o artex ./cmd/artex   # 3) 编译并内嵌前端
  ./start.sh                                          # → http://localhost:8787
  

第 1) 步的 npm ci 会一并安装构建所需的 devDependencies（如 @tailwindcss/postcss）。若 shell 中设置了 NODE_ENV=production，npm ci 会跳过 devDependencies，导致构建以 Error: Cannot find module '@tailwindcss/postcss' 失败，此时请用 npm ci --include=dev 下载。

运行时请不要直接执行 ./artex，而要用 start.sh（Windows 为 start.bat）。该脚本是一个根据退出码重新拉起程序的守护进程，UI 的"一键更新"也由该脚本处理。

---

配置

数据库（config.json，或通过环境变量 ARTEX_PG_DSN 覆盖）：

{
  "database": {
    "host": "127.0.0.1", "port": 5432,
    "user": "artex", "password": "yourpass",
    "dbname": "artex", "sslmode": "disable"
  }
}

LLM： export ANTHROPIC_API_KEY=sk-...（或 OPENAI_API_KEY），或在 UI 的"LLM 设置"页面输入。可选环境变量还有 ARTEX_LLM_PROVIDER / ARTEX_LLM_MODEL / ARTEX_LLM_BASE_URL / ARTEX_LLM_PROXY。若要使用国产/开源模型，请指定 OpenAI 兼容的 ARTEX_LLM_BASE_URL。

并发度： 每个任务运行的 worker 智能体数量在"系统设置"中调整（默认值 3）。

常用参数： ./start.sh -addr :8787 -proxy :8788 中，-addr 开放前端与 API，-proxy 为流量记录代理端口。

模型选择与输出语言

产出的韩语化并非硬编码上限，而是通过提示词指令（agent/prompt.go 中的 langDirective()）诱导。因此输出保持韩语的程度取决于模型的能力、角色与上下文。

• 建议使用能力较强的前沿模型。 在本地隔离沙箱中仅应用生产指令的简短验证运行结果显示，默认模型 claude-opus-4-8 在 planner、worker、reporter 产出以及持有权限的沙箱计划请求这全部四个角色中，都让面向用户的输出保持韩语，且没有被拒绝。gpt-4o 在同一场景下也保持了韩语。相反，廉价/小型模型（如 gpt-4o-mini）的报告回退成了原文（中文）。输出语言质量直接取决于模型能力，因此若环境需要人工阅读报告，请使用能力较强的模型。
• 角色/上下文仍可能导致漂移。 相比语言本身，偏差更常出现在角色与输出格式上。尤其是在 worker 的最终一句话总结这类简短产出中，模型可能直接暴露英文思考过程，或 report_finding 的结构化字段随目标应用与技术术语偏向英文。在过往运行中，gpt-4o 的 planner 情境摘要在部分轮次也曾回退为中文。在任务指令中明确写"用韩语撰写"可提高忠实度。
• 对推理型（reasoning）模型请给足 max_tokens。 单独使用思考通道的推理型模型，若响应 token 上限过小，会把预算耗尽在内部推理上，导致面向用户的最终回答为空。此时丢失的不是语言而是回答本身，因此请把该 LLM profile 的 max_tokens 设置得足够大。

OpenAI 兼容路径的 token 上限陷阱。 像 gpt-4o 这类 OpenAI 系列模型的响应 token 上限为 16,384。但 OpenAI 兼容请求默认会携带更大的输出上限（32,768），若原样保留，所有调用都会以 400 (max_tokens is too large) 失败。此时请在 LLM 设置中把该 profile 的 max_tokens 指定为 16,384 或更小。Anthropic 系列（默认模型 claude-opus-4-8 等）允许 32,768，不会踩到这个陷阱。

反向代理部署（仅开放 HTTPS / 443）

前端与 API/SSE 都由同一后端端口（默认 :8787）提供，实时活动流默认以**同源（same-origin）**方式连接。因此无需单独设置 NEXT_PUBLIC_SSE_BASE，只需对公网仅开放 443、把 8787 留在内网即可。

SSE 作为长连接持续推送事件，因此反向代理中必须关闭缓冲。若不关闭，浏览器虽然能连上，但收不到事件（活动流会一直显示加载中）。Nginx 配置示例见 README.zh.md。

---

系统架构

ARTEX 是一个由 LLM 多智能体驱动的自主渗透系统。使用单个 Go 后端（内嵌 Next.js 前端）加 PostgreSQL，智能体功能由 norma SDK 提供。核心是双图结构，以及围绕它的两种自主性装置（worker 之间的过程级信息交换、planner 的多轮共享 todolist）。

整体分层

flowchart TB
  subgraph FE["前端 Next.js (go:embed 单二进制内嵌)"]
    UI["仪表盘 · 任务 · 资产 · 覆盖图 · 流量 · 工作区 · 系统设置"]
  end
  subgraph SRV["server (Go net/http)"]
    API["REST /api/*　JWT 认证　SSE"]
    ENG["engine 调度循环"]
    MGR["Manager　任务/引擎/store 生命周期"]
  end
  subgraph AG["agent (norma SDK)"]
    GO["goals　目标分解 + 范围提取"]
    PL["planner　规划者（唯一的意图生成者）"]
    WK["worker　执行者 ×N"]
    MA["mainagent　人工介入"]
  end
  subgraph DB["PostgreSQL"]
    AGRAPH["资产图　assets / companies / task_scope"]
    EGRAPH["探索图　exploration_nodes / anchors / activity"]
  end
  subgraph SUB["支持子系统"]
    PROXY["流量记录代理　MITM + CA 记录"]
    GUARD["guard / intercept　工具审批门"]
    ENR["enrich　DNS / HTTP 异步增强"]
    EXT["MCP · skills · memory · report"]
  end

  UI -->|HTTP| API
  API --> MGR --> ENG
  ENG --> PL
  ENG --> WK
  API --> MA
  API --> GO
  PL --> DB
  WK --> DB
  MA --> DB
  GO --> DB
  WK -->|"Bash / HTTP 全过程记录"| PROXY
  WK --> GUARD
  WK --> ENR
  PL -.-> EXT
  WK -.-> EXT
  MA -.-> EXT

• 前端：把 Next.js 静态构建通过 go:embed 内嵌到单二进制中。可视化任务、资产、探索链、覆盖图，并提供人工介入的对话。
• server：负责 net/http 路由、JWT 认证与 SSE，Manager 管理任务、引擎、DB store 的生命周期。
• engine：每个任务运行一个 plannerLoop 与 N 个 worker goroutine，处理意图分配与超时、暂停、排空。
• agent：分为 goals / planner / worker / mainagent，ToolSet 把双图暴露为 LLM 工具。
• db：把双图存储到 PostgreSQL（pgx），通过 go:embed 引入的 schema 在每次启动时幂等地建表。
• 支持：记录型 MITM 代理、审批门、异步增强、MCP·技能·内存·报告。

双图结构：探索图 + 资产图

系统把"目标是什么"与"测试到哪一步"拆分为两个相互独立、又通过锚点（anchor）相连的图。

• 资产图（Asset Graph，全局共享）：跨任务共享的资产真相存储。节点为 root_domain / subdomain / ip / service / app / endpoint，归属于公司。域名→子域名→服务→端点的父子关系与去重键全部由程序计算，智能体只提交原始信息。
• 探索图（Exploration Graph，每个任务独立）：一个任务的"思考与进展"过程。节点为 goal(目标) / intent(意图) / fact(事实) / finding(漏洞) / hint(提示)，通过 spawns / derived_from / yields / proves 等边构成血缘链。
• 两个图通过锚点相连。 exploration_anchors(node_id, asset_id) 把意图、事实、漏洞固定到具体资产上。由此可以从探索方向双向查询：它攻击了哪个资产；反过来，某个资产在本任务中以何种意图被测试、产出了什么事实。

flowchart LR
  subgraph EG["探索图 (每任务独立 · 进展链)"]
    direction TB
    G["goal 目标"]
    I1["intent 意图 A"]
    F1["fact 事实"]
    I2["intent 意图 B"]
    FD["finding 漏洞"]
    G -->|spawns| I1
    I1 -->|yields| F1
    F1 -->|derived_from| I2
    I2 -->|proves| FD
  end
  subgraph AG["资产图 (全局共享 · 真相存储)"]
    direction TB
    RD["root_domain"]
    SD["subdomain"]
    SV["service"]
    EP["endpoint"]
    RD --> SD --> SV --> EP
  end
  I1 -. anchor .-> SD
  F1 -. anchor .-> SV
  I2 -. anchor .-> EP
  FD -. anchor .-> EP

分工：planner 读取探索图的状况判定目标，仅在存在尚未覆盖的新方向时把意图送入 frontier。worker 领取一个意图，用真实工具执行，把新资产、事实、漏洞写入两个图后停止。资产图是共享事实，探索图是每个任务的进展链。

引擎与意图生命周期（一次探索的闭环）

引擎是一个事件驱动的闭环。图发生变化就唤醒 planner，planner 发出意图后 worker 领取该意图执行并写入结果，该写入又触发下一轮。这个循环一直持续到目标被证明（prove_goal）为止。

sequenceDiagram
  autonumber
  participant EV as 图变更 debounce
  participant P as planner
  participant FR as frontier 意图队列
  participant W as worker
  participant PX as 记录代理
  participant DB as 双图 + activity

  EV-->>P: 唤醒
  P->>DB: 读取状况(graph_overview 预取 + coverage/scope)
  P->>FR: 分配意图 0..N 个(含 asset_ids)
  Note over P,FR: 大多数唤醒分配 0 个 — 没有新方向则结束
  W->>FR: 用 claimNext 领取一个意图
  W->>DB: 取意图的 asset_ids 原始资产作为初始信息
  W->>PX: 执行真实工具(Kali / Bash / HTTP)
  PX-->>W: 响应(全过程记录 + CA 验证)
  W->>DB: fact / asset / finding + 各步骤 activity 记录
  DB-->>EV: 图变更
  EV-->>P: 再次唤醒(闭环)

worker 之间的过程级信息交换

在深度探索中，有价值的观察（某个错误、某段响应片段、隐藏参数）往往产生于某个 worker 的执行过程，却未被记录为正式 fact。为避免重复劳动、让后续 worker 能站在先前观察之上，worker 具备检索其他 work 过程的能力。

• search_all_worker_traces(q)：以关键词检索同一任务下其他 work 的执行过程（自动排除自身意图的步骤）。命中项会附带 intent_id。
• list_worker_traces / get_worker_trace(intent_id, step_ids=[…])：先查看有哪些 work 运行过，再拉取某个 work 的特定几步完整内容以交换细节。

这样，即便探索图中尚无对应的 fact，后续 worker 也能复用他人过程中的观察。信息在 worker 之间以"执行过程"为单位流动，但边界保持不变（每个 worker 仍然只执行自己领取的那一个意图）。

flowchart LR
  WA["worker A (意图 #12)"] -->|"逐步 activity"| ACT[("探索图 · activity 过程库")]
  WB["worker B (意图 #34)"] -->|"逐步 activity"| ACT
  WC["worker C (意图 #56)"] ==>|"① search_all_worker_traces(q)"| ACT
  ACT ==>|"② 命中 A/B 的步骤 (排除自身)"| WC
  WC ==>|"③ get_worker_trace(intent_id, step_ids)"| ACT
  ACT ==>|"④ 返回完整过程内容"| WC

planner 的多轮共享 todolist → 稳定的攻击链

真实的攻击链往往是前后依赖的多步骤序列（例如：发现注入点 → 获取凭证 → 横向移动 → 权限提升），若一次性并行下发就会纠缠不清。因此 planner 拥有一个按任务保留、跨唤醒共享的计划待办列表（todolist）。

• planner 是事件驱动的，图每次变化都会唤醒，但每次唤醒都是一个新的会话。共享 todolist 把串行攻击链只记录一次，之后跨多轮按依赖关系一步步分配意图（不会在单轮里把整条链一次性铺开）。
• 每轮只给"前驱步骤已完成、且该步骤所依赖的 fact 已存在"的下一步分配意图，并根据进展更新列表（把已由 fact 满足的步骤标记为完成）。

flowchart TB
  subgraph TODO["共享 todolist (按任务保留 · 跨唤醒常驻)"]
    direction LR
    T1["1 发现注入点　[完成]"]
    T2["2 获取凭证　[进行中]"]
    T3["3 横向移动　[等待前驱]"]
    T4["4 权限提升　[等待前驱]"]
    T1 -. 前驱满足 .-> T2 -.-> T3 -.-> T4
  end
  R1["第 1 轮唤醒　分配意图①"] --> T1
  R2["第 2 轮 (①产出 fact)　分配意图②"] --> T2
  R3["第 3 轮 (②产出 fact)　分配意图③"] --> T3

由此，攻击链在"事件驱动 + 无状态会话"的环境中也能稳定推进，不重复、不乱序。这正是 ARTEX 能自主完整走完多步骤攻击链的关键。

---

防御与检测资料

本仓库的目标是帮助防御方理解自主 AI 攻击的运作原理，培养检测与阻断能力。我们把上文中 ARTEX 的行为从防御者视角反转过来，用韩语整理出应观测什么、应在哪里收紧的指南。

• 自主 AI 攻击防御与检测指南 (docs/defense-ko.md)
  • 自主 AI 攻击与传统扫描器的差异、为何难以检测、以及尽管如此又该如何检测
  • 防御者可观测的指纹（IoC·行为特征）：分为目标视角与取证视角
  • 攻击者瞄准的入口点与加固（辅助认证·本人确认、API 授权、凭证填充、会话·密钥管理）
  • WAF·SIEM·认证日志检测规则（伪规则）、加固清单、事件响应摘要
  • 韩国官方侵害指标·安全建议渠道（KISA·金融安全院·个人信息保护委员会）与韩国法律下的报告义务
• Defense & Detection Guide（英文版 · docs/defense-en.md）：可与海外团队及协作者共享的英文同内容版本。
• 可直接部署的检测规则 (detections/README.ko.md)：把上述指南中的指纹检测转化为可直接使用的规则。主机·日志·SIEM 层使用 Sigma 规则（原子·关联，可用 sigma convert 转换为 Splunk·Elasticsearch 等），网络层使用 Suricata 规则，针对 enrich 探针与 norma SDK WebFetch 的 User-Agent。
  • ATT&CK 覆盖层 (detections/attack/README.ko.md)：把上述规则针对的 MITRE ATT&CK 技术整理为 Navigator 层（JSON），一眼看清哪些攻击行为会被哪些规则命中。技术仅取自规则的 attack.* 标签，没有凭推测加入的条目。
  • 机器可读的侵害指标清单 (detections/indicators/README.ko.md)：把 ARTEX 实际导出的独有指纹汇集成一个 CSV 文件（artex_indicators.csv），并以 MISP 事件（artex_indicators.misp.json）形式提供相同指标。可直接导入 SIEM 查询表或威胁情报平台（接收 MISP 格式的 MISP·C-TAS·FSI 等）的侵害指标（IoC）。所有值都是在本仓库源码中确认过的字符串，每一行都标注了来源文件与检测规则。
  • 主机分类（triage）脚本 (detections/triage/README.ko.md)：面向没有 SIEM 或网络传感器、站在一台可疑主机 shell 前的响应人员的只读脚本 artex_host_triage.py。它检查与上述规则相同的指纹，并额外直接在主机上确认三个无法从日志或网络观测到、故侵害指标 CSV 有意未配 Sigma 规则的主机·DB 指标（服务器监听端口、记录代理端点、PostgreSQL 探索 schema）。无需额外安装，仅用标准库即可运行；每项发现都只是与对应侵害指标行具有相同局限的分类线索，本身不构成定性依据。
  • 上述规则、层、指标以及主机分类脚本的自测，全部通过仓库测试（detections/tests/README.ko.md）重跑验证。遵循"无法运行的检测规则只是主张"的原则。

这些资料会持续补充。要补充的检测规则·加固条目请以 issue 提出；直接提交规则时，请遵循贡献指南的「检测规则·检测测试贡献」一节所整理的契约（贴合可观测事实、说明局限、通过静态校验、附带可复现测试）。

---

开发

本地开发与测试：

./dev.sh    # 后端(:8787) + 流量代理(:8788) + 前端 next dev(:5173) → http://localhost:5173

• 后端：go run ./cmd/artex（不带 -tags embedui 则不内嵌前端）
• 前端：cd web && npm run dev（将 /api 代理到后端，热重载）
• 测试：go test ./...
• Mock 预览（无需后端）：cd web && NEXT_PUBLIC_MOCK=1 npm run dev

其他开发项（手动漏洞复验等）请参考 README.zh.md 的"开发"一节。

本韩语版对上游 ARTEX 所加的变更整理在 变更历史（CHANGELOG.md）。

---

许可证与免责

开源许可证

本项目以 GNU Affero General Public License v3.0（AGPL-3.0） 发布。完整条款见仓库根目录的 LICENSE 文件。

任何人都可自由使用、修改、分发，但衍生作品也必须同样以 AGPL-3.0 公开。 特别是，若你修改本项目并通过网络（例如作为在线服务）提供给用户，则必须向这些用户公开对应的完整源代码。 本韩语版同样保留 AGPL-3.0。

⚠️ 重要： 开源许可证本身并不限制软件的用途。下方的"使用限制"与"免责"是原作者对用户额外要求的约定与严厉告知，请务必遵守。

使用限制

• 本工具请用于阅读源代码、学习与研究的目的，以及在本地隔离环境中验证技术原理的目的。
• 除非目标是你自己所有、或已获得书面明确授权的对象，否则不要对任何网站、在线服务、相连系统执行扫描、探测、漏洞利用、攻击。
• 严禁用于非法入侵、数据窃取、拒绝服务（DoS）以及其他破坏性、犯罪性活动。
• 必须遵守用户所在国家/地区的网络安全、数据保护、计算机犯罪相关法规（韩国如《信息通信网法》《个人信息保护法》等）。

免责

本项目按"原样（AS IS）"提供，不作任何明示或默示的担保。原作者与贡献者对因使用本工具（无论使用方式是否恰当）而产生的任何直接、间接损害、数据丢失、系统损坏、法律纠纷概不负责。下载、安装或使用本项目即视为已阅读、理解并同意上述全部条件。

一切法律责任与后果由用户本人承担。

---

原始项目

• 原始仓库：Autumn-27/ARTEX
• 原始 README（中文）：README.zh.md
• 原始在线演示（中文 UI）：https://artex-demo.vercel.app/
• 智能体 SDK：Autumn-27/norma