ARTEX是一个连接LLM、执行工具、网页界面和数据库的安全研究系统。要安装它，不仅需要源代码，还需要准备好可执行文件、依赖项、配置和数据存储。如果部署路径中断，则必须重新确认可以获取哪些部分。
2026年10月9日重新确认的结果显示，原始Autumn-27/ARTEX的GitHub公共API和现有Docker Hub镜像的latest标签查询均返回404。韩语分支可以打开，但默认的Compose文件仍然引用原始镜像。因此，仅仅将仓库地址更改为分支并运行现有Compose命令并非解决方案。
目前确认的替代方案是韩语分支提供的源代码构建路径。本文解释了检查固定提交的配置、构建顺序和依赖访问的结果。这并非在全新环境中完成编译、数据库连接、管理员登录和模型响应的完整安装成功案例。
AI生成的概念图像。不代表实际的ARTEX界面或完全运行状态。
1. 本次确认范围
重新验证的对象是现有安装篇中提到的原始仓库和镜像，以及可公开访问的jiwoochris/artex-ko的安装资料。韩语分支被区分为由独立维护者管理的仓库，而非原始项目的官方重新发布。
| 检查对象 | 本次观察 | 解释范围 |
| — | — | — |
| 原始GitHub仓库·文件列表·发布公共API | HTTP 404 | 在当前公共路径下无法访问，无需认证 |
| Docker Hub autumn27/artex的latest标签API | HTTP 404 | 该标签的公共查询失败，并非实际镜像拉取成功 |
| 韩语分支README·Compose·Dockerfile·环境变量示例 | 从固定提交成功读取 | 安装设计和指南已确认 |
| norma v0.4.3 Go代理的.info·.mod | HTTP 200 | 版本信息和模块声明访问已确认 |
| 完整依赖下载·编译·服务器运行·模型调用 | 本次重新验证中未执行 | 无法声称安装成功 |
仅凭一个404无法确定仓库是永久删除还是转为私有。但是，对于判断读者无需认证即可遵循的现有公共安装路径目前无法访问，这已是足够的观察。搜索结果中即使保留了旧文件，也无法替代当前的下载可能性。
直接确认路径： 原始仓库API · 原始发布API · 现有镜像标签API。
2. 即使下载了分支，Docker快速启动仍然受阻的原因
审查的韩语分支提交是7333fa47b9bdd89b4973992b2e15d9c393539b8c。此时的README解释说，由于无法获取原始镜像，Docker快速启动无法工作，并且韩语版镜像正在准备发布。源代码编译路径可用的说明是维护者的确认内容，与本文的执行测量结果区分开来。 固定提交README
Compose的核心引用如下：
artex:
image: autumn27/artex:${ARTEX_TAG:-latest}Git仓库地址和容器镜像地址是独立的。即使获取了分支的代码，只要使用此配置，可执行文件仍会在原始镜像仓库中查找。将ARTEX_TAG更改为任意其他名称，也无法证明该标签确实已部署。 固定提交Compose
此外，此提交的Dockerfile并非自动编译整个源代码的形式。它将预先准备好的dist/${TARGETARCH}/artex二进制文件复制到镜像中。不准备文件而仅运行docker build的方法也不是完整的替代安装过程。 Dockerfile
根据分支维护文档和设置重新构建。此图分离了 README和 Dockerfile中的路径，并未将分支表示为原始的官方发布。
3. 源代码构建也需要通过多个阶段
韩语分支指导的顺序是前端静态构建、将结果复制到服务器内置目录、Go二进制编译、启动脚本执行。前端是浏览器中可见的界面，Go二进制是提供该界面并处理API和任务的服务器。
审查的go.mod声明了Go 1.26.3，并将github.com/Autumn-27/norma v0.4.3指定为依赖项。界面构建使用web/package.json中的build:static任务。实际的构建工具必须与此声明以及使用的操作系统和架构相匹配。 go.mod · 前端设置
即使上游依赖仓库关闭，模块代理中仍可能保留特定版本。本次我们从Go公共代理读取了norma v0.4.3的版本信息和模块声明。然而，这两个请求的成功并不意味着源代码压缩文件和所有子依赖项的获取、校验和验证以及实际编译的成功。
这种区别解释了现有开发PC与空白VM之间的差异。即使现有PC由于缓存而能够构建成功，首次安装的用户仍可能在获取依赖项的阶段失败。为了创建可重现的指南，无缓存环境也应作为验证对象。这部分是本次资料确认中得出的操作判断。
4. 安装前先确认源代码和工具
以下是将在独立Linux研究环境中使用的检查命令示例。本文未测量该环境的执行输出。前提是组织已审查并选择了分支的使用条件和代码，并且无需将工作凭据或个人文件连接到研究环境。
git --version
go version
node --version
npm --version
git clone https://github.com/jiwoochris/artex-ko.git artex-ko-lab
cd artex-ko-lab
git checkout --detach 7333fa47b9bdd89b4973992b2e15d9c393539b8c
git rev-parse HEAD
git status --short确认rev-parse结果与所选提交一致，并在更改文件前记录工作目录的状态。固定提交表明选择了哪个源代码，但不能保证软件安全或所有依赖项都已固定。
之后，一起审查go.mod、go.sum、npm锁定文件、Dockerfile和启动脚本。还需要检查安装脚本是否调用了其他部署路径。这是因为在原始镜像不可用的情况下，重复运行旧的自动安装脚本可能会回到相同的失败路径。
5. 审查构建顺序和中断点
以下是为便于阅读而将分支文档顺序分离的可重现候选步骤。它并非作为已验证的安装方法提供给读者的命令。npm安装过程可以执行依赖脚本，因此应在完成源代码审查的专用环境中执行。
cd web
npm ci --include=dev
npm run build:static
cd ..
test -f web/out/index.html
test ! -e server/webui/dist
mkdir -p server/webui/dist
cp -a web/out/. server/webui/dist/
CGO_ENABLED=0 go build -tags embedui -o artex ./cmd/artex每个命令仅在前一个命令成功时才继续到下一行。如果server/webui/dist已存在，则上述检查将停止，并首先查看它是现有结果还是源代码中包含的资料。此条件是为了防止在重复构建时路径重叠或旧界面混淆。它不是一次性运行的安装脚本。
前端依赖项也需要构建包，因此明确指定了–include=dev。即使Go构建完成，其结果也是针对当前构建环境的可执行文件。要将其放入Linux容器镜像中，需要单独准备与操作系统和CPU架构匹配的二进制文件。
如果发生错误，请记录第一个失败阶段和消息。不要仅仅因为看不到原始仓库就关闭校验和验证或切换到任意依赖分支作为默认解决方案。如果需要替代依赖项，则应将该更改本身作为单独的审查项处理。
6. 编译之后是数据库和服务设置
将界面放入单个二进制文件并不意味着也包含了数据库。分支的README指导如何通过config.json或ARTEX_PG_DSN配置PostgreSQL连接。在主机上运行的服务器和在容器中运行的服务器，其到达数据库的地址可能会有所不同。 数据库设置指南
例如，Compose内部的服务名postgres是同一网络中的容器可以使用的地址。不应假定直接在主机上运行的二进制文件可以使用该名称连接到数据库。首先确定数据库将在哪个环境中运行，然后配置该环境中实际可达的地址和认证设置。
README指导使用start.sh而非直接运行二进制文件，并解释说Web/API和日志代理地址分别通过-addr和-proxy接收。本地研究的候选配置如下，前提是数据库和所需设置已准备就绪：
./start.sh -addr 127.0.0.1:8787 -proxy 127.0.0.1:8788此设置旨在限制传入连接的绑定。它不阻止服务器和工具向外部发送通信。模型API和工具的通信目的地必须通过单独的网络策略进行管理。实际打开管理界面，设置新的管理员账户后，并确认服务器重启后设置仍然保留，才能继续进行安装验证。
7. 模型连接和首次响应是独立的测试
管理界面打开后，下一步是模型连接。确认所用提供商的当前模型ID、API格式、工具调用支持和账户权限。此时无需将API密钥放入代码或博客评论中。在连接测试中收到所选模型的响应后，可以通过合成句子摘要等小任务来确认界面和记录流程。
无需从一开始就创建检查外部目标的自主任务。由于这是确认模型和工具接收何种输入以及能执行何种操作的阶段，因此不包含敏感数据和实际服务地址的小输入是合适的。少量不使用工具的提示也不能替代阻止执行权限。
根据分支文档重新构建的安装验证计划。此图根据 安装·数据库·LLM设置指南整理，并非衡量各阶段成功的结果表。
8. 如果有现有安装版本，请先保存
已运行的环境与新安装的处理方式不同。即使公共镜像已消失，本地镜像或二进制文件仍可能存在。在确认正在使用哪些可执行文件之前，删除它们或应用一键更新可能会导致丢失可以重新创建的路径。
要保存的对象包括源代码提交、可执行文件或镜像标识符、实际配置、数据库和文件数据。包含密码和密钥的配置应与一般文档区分开来，并限制访问。不仅要确认备份文件是否存在，还要确认它们是否可以在独立环境中恢复。
将程序文件更改为旧版本与将数据库模式恢复到旧状态是两回事。如果考虑更新或分支切换，最好在保留现有环境的同时，在副本中检查兼容性，这样更容易缩小失败原因。本节是关于操作现有安装版本的一般性建议，并非实际系统更改的记录。
总结：目前确认的替代方案和尚待完成的验证
根据当前的公共路径，基于原始镜像的现有安装指南无法直接使用。韩语分支有源代码构建路径，其配置和核心依赖元数据的访问已得到确认。但是，构建文档的存在与在新环境中成功安装是不同的结果。
下一次验证包括在空白研究环境中构建固定提交，并确认数据库连接、管理员设置、模型响应以及停止和恢复。在获得这些结果之前，本文应作为安装路径检查和重现计划使用，并与具有成功输出的完整实践指南区分开来。
发表回复