整体架构

从部署和技术栈看，ARTEX 是一个相当「常规」的现代 Web 应用，真正特别的是它内部跑着自主智能体。理解它的外壳，有助于理解它在一台服务器上会呈现什么样子——这对事后溯源很有用。

技术栈

层	选择
后端	Go，单体（monolith）
前端	Next.js，被打包进 Go 二进制，随后端一起分发
数据库	自备的 PostgreSQL，保存任务、发现、资产与流量记录
智能体能力	norma SDK（同作者的另一个库）
许可证	AGPL-3.0

把前端内嵌进单个 Go 二进制，意味着它分发和部署都很简单：一个二进制加一个数据库就能跑。这种「低摩擦」也是它容易被滥用的现实因素之一。

自托管与可观测性

ARTEX 只提供自托管，没有官方托管服务（曾提供在线 demo）。它的 Web 界面默认监听 8787 端口，首次启动有一个 /setup 引导页。

值得注意的是它对「可观测」下了不少功夫。按公开介绍，界面提供：

• 展示 token 用量的仪表盘和活动流；
• 每个任务独立的会话，带工具调用轨迹（tool-call trace）；
• 探索图（exploration graph）、发现列表、资产列表，以及力导向的资产覆盖图；
• 流量记录。

这些可观测设计本意是让使用者看清智能体「每一步做了什么」。但它也有副作用：一旦这些界面和数据目录被暴露在公网（正是韩国事件里发生的事），对溯源的研究者来说，就等于一份详尽的操作记录。

审批与人在环

ARTEX 支持「拦截并审批」（intercept-and-approve）的流程：智能体的动作可以先经过审批，聊天界面里有可展开查看完整调用细节的审批卡片，还有一份全局审批日志。配合「人在环」（human-in-the-loop）的对话，使用者可以在运行途中介入。

从设计意图看，这是一种安全阀——让「自主」不至于完全脱缰。但审批是否开启、以什么粒度开启，取决于使用者。在被滥用的场景里，攻击者自然不会用它来约束自己。

对防守方的意义

理解这套外壳，有两个直接用处：

1. 它在主机上有明确的「形态」——8787 端口、/setup 页、PostgreSQL、以 Go 二进制形式运行、挂载 ./skills 与 ./data 目录。这些可以成为主机侧检测的线索。
2. 它的可观测数据（会话、工具调用轨迹、流量记录）如果落在可被访问的位置，就是溯源的金矿——CrowdStrike 正是通过攻击者服务器上暴露的开放目录，拿到了大量操作细节。