ARTEX（Artex）是一款连接大型语言模型以协调安全检查计划和工具执行的软件。2026年10月8日，作者宣布停止更新、转为闭源，并停止未来的外部分发和维护支持。此前基于公开仓库和分发镜像将持续可用的前提编写的安装指南，现在需要重新确认其适用条件。
即使已经获取了源代码或公开的存档仓库，也难以立即更改安装路径。必须首先确认所获取的文件是哪个时间点的什么内容，附带了哪些权利和条件，以及谁将负责修改和维护。本文将分享公告的含义和访问验证结果，并整理如何阅读现有安装指南以及审查存档版本的顺序。
确认日期为2026年10月9日。本文是对官方公告和公开仓库信息的审查，并非新存档版本安装成功或实际安全检查性能测量的回顾。
代表图片：AI生成概念图。并非实际仓库界面或执行环境的再现。
1. 作者公告中可确认的范围
作者GitHub个人资料中10月8日的公告以滥用案例为背景进行说明，并告知项目将不再更新，并转为闭源。其中还包括未来将不再向外部分发新版本或提供维护支持。此处关于滥用和开发宗旨的说明应被解读为作者的立场。它并非独立证据，无法证明特定事件的全部经过或法律责任。 作者公告
这一决定改变的是未来通过官方渠道可获得的公开开发和支持。它并不意味着过去收到的所有文件都同时消失，或者现有副本自动变得无法运行。反之，旧副本的存在也不能被视为官方维护将继续的理由。
在实践中，当出现新问题时，谁来确认和修复将成为一个重要问题。要继续审查一个已停止公开维护的项目，用户必须能够以其获取的特定版本为基础，直接管理依赖项、变更历史和运行条件。这并非主张该版本发现了新的漏洞，而是判断未来的审查责任和支持途径已发生变化。
2. 公告与下载错误是不同的证据
公告中写明了未来的运营方针。HTTP响应是在特定条件下访问特定地址的结果。两者结合有助于理解当前情况，但一个并不能解释另一个的所有原因。
10月9日上午9时10分左右（韩国时间）的访问验证显示，原始仓库、目标发布路径和ARM64 ZIP下载返回了HTTP 404。在同一验证中，对官方Docker镜像特定ARM64 manifest的匿名查询和拉取（pull）尝试以HTTP 401告终。下表是已验证路径的结果，并非对所有版本或所有平台的统一判断。
因此，目前可以说明的范围是，尚未确认可以按照现有官方下载路径直接进行安装。遇到错误时，与其立即使用来源不明的ZIP文件或替代镜像，不如先整理所需的发行版本和可验证的依据。
基于官方文档重构。这是根据作者公告和Registry认证流程区分方针和响应观测的概念图。访问观测不保证所有发行版本的状态。
3. 如何解读现有概述文章和安装指南
此前发布的ARTEX概述与引入边界是基于当时公开资料解释系统构成和安全审查项的。本文并非旨在重新确认事件分析或评估工具性能的后续文章，而是讨论公开分发和维护条件已发生变化的情况。结合阅读前一篇文章的确认日期和本次公告日期，可以区分说明的对象和时间点。
以10月5日为基准准备的安装指南是基于当时官方仓库的特定提交（commit）和Compose配置。Compose是一个将多个容器的运行设置集中到一个文件中的工具。该指南中的源代码固定和镜像标识值记录仍然是有效的审查方法，但原始仓库克隆和镜像下载现在仍然可用的前提需要单独验证。
在应用现有安装指南之前，必须重新确认原始下载地址、镜像提供商、将使用的CPU平台以及所需版本。要区分特定时间点设置的对照指南与当前环境下安装成功的记录，如果使用新的存档版本，则应根据该存档版本的条件进行审查。
即使本地保留了源代码文件夹，也并不意味着已准备好执行。容器镜像、语言包、数据库和构建工具可能需要从外部获取。反之，即使镜像仍然存在，如果不知道它是用什么源代码和设置构建的，也难以判断它是否是同一个程序。源代码保存、可构建性、启动成功、功能验证是不同的阶段。
4. 找到公开存档仓库不代表原始版本已恢复
分支（fork）指的是从另一个仓库分出的副本。实际上，有些仓库是通过GitHub的分支功能连接的，也有一些是将历史记录迁移到单独的仓库中进行保存。获取的时间点和后续的更改比名称相同的事实更重要。
10月9日的公开GitHub API查询可访问以下三个位置。这些是调查候选列表，并非经过安全或安装成功验证的推荐列表。仓库页面和默认分支可能会在之后发生变化，因此在审查时也应记录提交（commit）。
[WRIMO_MD_TABLE_1]查询时，两个候选在API中未被标记为正式分支，而archiveproject候选被标记为分支。此标记提供了GitHub仓库连接关系的信息。它不能替代验证代码的原始性或是否存在恶意更改。 [公开API: mhtsec · Hinln · archiveproject
例如，仅README更改的存档版本和自动更新地址更改的存档版本，其审查范围是不同的。后者还需要确认安装后从何处获取新的可执行文件。如果没有可与原始版本比较的基准文件，则应记录已获取的提交（commit）和可比较的文件范围，而不是写“与原始版本相同”。本文不主张已完成对所有三个候选的完整代码审查或安装验证。
在本次确认过程中，还准备了一个以mhtsec存档版本为起点的存档公开分支。这是保留了原始v0.3.15提交e6ec56999175509551a1e43a3ee3b053d0941bd9和标签的资料。历史记录的存在与新安装或功能验证的成功是两回事。安装本身尚未完成。
5. 韩语替代候选artex-ko有何不同
如果需要韩语界面和结果，可以考虑社区本地化项目jiwoochris/artex-ko。如果说存档分支侧重于保留原始历史，那么artex-ko则是增加了界面、文档和面向用户输出的韩语本地化版本。它并非作为原作者的官方后续版本或经过安全验证的替代品进行介绍。
已确认的代码将默认界面语言设置为ko，并分离了韩语和中文消息文件。代理提示中添加了langDirective()指令，要求用户可见的自然语言使用韩语。这并非一种翻译所有内部指南、代码、URL和原始技术资料的方式。在代码中确认了语言指令的事实与所有模型都能始终准确地用韩语回答的保证是不同的。 界面语言设置 · 输出语言指令代码
审查的韩语版提交（commit）是9e1b227d73a6881c1455b0e5ee0595e669474ed2。同时保存的上游变更历史记录中包含0.3.14及后续未发布（Unreleased）的更改。这不作为断定其与原始v0.3.15代码相同的依据。确切的基础应通过比较将使用的提交与上游资料的范围来确认。 上游变更历史存档版本
当前的README指出，默认的Compose由于引用原始镜像，在快速启动方面存在问题，并且韩语版Docker镜像的分发正在准备中。源代码构建路径的运行确认是仓库运营者的说明，并非本文中重现的安装结果。因此，即使选择韩语版，也必须首先确认获取可执行文件的路径。 韩语版README
许可证显示为AGPL-3.0，并提供了变更历史和维护文档。这些资料的存在并不能替代长期支持承诺或独立的安全性验证。韩语化带来的模型响应、权限、外部传输和更新路径，必须在所选版本中单独审查。本文未实际安装或运行artex-ko。 LICENSE · 韩语版变更历史
6. 安装前需固定的内容：提交、文件、镜像、条件
提交（commit）是Git用于识别特定时间点文件状态的值。由于分支名称可能因后续修改而指向不同位置，因此建议将要审查的源代码以仓库地址和完整提交标识符作为一对进行记录。如果从原始版本获取了资料，应核对与基准提交的变更列表，不要用仅文件名相同的副本代替比较。
确认顺序可分为以下几点：
- 来源和范围：记录从哪个仓库、何时获取、是哪个提交（commit）、是包含历史记录的存档还是仅源代码包。
- 变更点：不仅查看README，还要检查与Dockerfile、Compose、依赖项、模型连接、更新路径、工具权限相关的文件。同时阅读文件名和实际变更内容。
- 分发物连接：确认镜像和可执行文件是否由审查的源代码构建，由谁提供，以及是否支持相应的CPU平台。
- 哈希和保存：记录所获取文件的哈希值，以便后续比较是否为同一文件。如果分发者的校验和与文件是从同一个不可信来源获取的，仅凭两者匹配并不能证明来源。
- 使用条件：同时保存该提交的LICENSE、版权声明、README中的单独声明以及所包含的第三方组件的条件。
在容器中，需要验证摘要（digest），即识别镜像内容的哈希值。像latest这样的标签以后可能会指向不同的内容。固定摘要有助于在重新拉取时选择相同的内容，但这并非内容无害的验证。对于多平台镜像，还必须区分识别整个列表的摘要和特定平台镜像的摘要。 Docker镜像摘要文档
确认结果以如下简短记录而非冗长的成功声明形式保存，对后续审查更有用。以下是编写格式，并非实际安装记录。
출처 저장소: 검토 대상 공개 저장소 URL
소스 기준: 확인한 전체 커밋 식별값
비교 범위: 대조한 기준과 파일 목록 / 대조하지 못한 범위
사용 조건: 해당 커밋의 LICENSE와 관련 고지
실행물: 공급자, 플랫폼, 파일 해시 또는 이미지 digest
검증 범위: 정적 검토 / 빌드 / 시작 / 모델 응답 / 도구 권한
유지보수: 담당자, 업데이트 기준, 중단·복원 방법
基于官方文档重构。这是根据GitHub许可指南、Docker摘要文档和Docker安全文档整理的审查顺序。进入下一阶段的事实并不能解决之前未确认的项目。
7. 许可证标识是原文确认的起点
公开可读的事实与允许复制、修改、再分发的条件必须区分开来。虽然查询到的候选API中显示了标记为AGPL-3.0的许可证信息，但仅凭自动分类无法确定所有待分发文件的条件。实际上，必须确认所选提交的LICENSE和版权声明，以及所包含的依赖项和各个文件的条件。
仅凭作者的公开停止公告，并不能统一判定过去所有发行版本的权利，也不能断定所有分支都是非法的或可以无限制使用的。GitHub的指南也区分了仓库的公开/分支关系和许可证条件。本文并非对各存档版本进行法律审查的结果，特别是如果您计划进行外部再分发或提供服务，则需要根据您获取的原始条款进行单独审查。 GitHub许可证指南
即使在存档时，如果只保留代码而省略了通知文件，后续确认的依据就会减少。反之，如果分支运营者添加了新的LICENSE文件，也并不能自动理清所有原始代码的权利。必须确认变更的时间点和适用范围，不确定的文件应标记为超出审查范围。
8. 执行验证应在独立的研发环境中分步进行
即使在确认了来源和条件之后，也无需立即在工作设备上运行。像ARTEX这样处理文件和工具的代理，其访问范围会根据执行账户、共享目录和网络设置而变化。Docker容器具有隔离功能，但如果共享主机目录或控制套接字并赋予过多权限，其边界就会被削弱。 Docker Engine安全文档
在独立的研发虚拟机中开始审查，不要连接业务源代码、浏览器配置文件或认证文件。仅仅在工具中写上“请勿访问外部网络”并不能阻止网络连接。要区分必要的模型目的地和其他外部连接，并确认执行环境中允许的通信范围。
验证也不应捆绑为一次成功。应分别记录是否能读取设置、审查的可执行文件是否能启动进程、界面是否能打开、所选模型是否能对合成输入做出响应，以及工具执行前所需的限制和批准是否正常工作。如果只收到了服务器健康响应，则仅完成了服务器确认。不要将其扩大解释为已验证了模型响应或整个工具批准路径。
如果使用外部模型，即使是本地程序，输入也可能传输到外部。首次确认时，应使用合成文本而非实际客户数据或操作日志，并同时确认存储位置、记录设置、使用量和停止方法。此程序是未来审查的标准，并不意味着本文已实际安装该存档版本或通过了所有这些项目。
9. 当前的选择标准是能否维护，而非能否获取
ARTEX公开分发中止并不意味着过去的所有说明都是错误的。然而，官方下载和维护将持续可用的假设已经改变。阅读现有安装指南时，应确认基准日期，并从原始获取阶段开始重新审查当前的访问可用性。
存档版本的作用是保留特定时间点的数据。它不保证可重现的执行环境和安全运行。只有在确认了来源、提交、条件、变更点和可执行文件，并能在独立环境中记录验证范围时，才能进行下一步判断。
如果依据不足，与其增加下载绕行路径，不如停止审查并比较其他仍在维护的工具，这更为合理。如果继续进行存档版本研究，也必须明确修改责任和更新标准。分别记录是否已获取文件、是否已确认运行、以及未来是否可维护，是本次变化中最必要的检查。
参考资料
确认日期：2026年10月9日。仓库和分发路径的状态可能在之后发生变化。
- ARTEX作者公告 — GitHub个人资料：2026年10月8日公告。
- 现有ARTEX概述与安全引入边界：此前确认时间点的系统说明。
- mhtsec/ARTEX公开API、Hinln/ARTEX公开API、archiveproject/ARTEX公开API：公开存档候选查询。
- 存档公开分支：用于保留原始历史记录，不代表已完成安装或安全验证。
- 韩语社区替代候选artex-ko：本地化范围、基础资料、分发路径、使用条件确认。
- 确认目标发布路径、确认目标ARM64 ZIP：访问观测对象，不代表当前可下载。
- Docker Registry认证流程。
- Docker镜像摘要。
- GitHub仓库许可指南。
- Docker Engine安全。
发表回复