随着大模型能力不断融入操作系统、云计算和开发运维场景，Agent 正在成为 OpenAtom openEuler（简称“openEuler”或“开源欧拉”）生态中的一种新型软件形态。从内核数据采集、故障诊断，到智能运维、性能分析，openEuler 社区正在形成越来越丰富的 Agent 能力。与普通脚本相比，一个 Agent 通常还包含 Skill、工具、知识、运行依赖和安装配置，需要经过持续开发、构建、验证和发布，才能稳定交付给用户。
当 Agent 从一个变成一组，如何高效地开发和管理这些 Agent，就成为新的工程问题。为解决这一问题，openEuler 社区设计了 witty-agent-factory。它面向本地 Agent 生态，提供统一的可视化入口，帮助开发者和项目管理员完成 Agent 的查看、构建、验证、发布和过程追踪。
目前，Agent 的源码、配置和注册信息统一维护在官方代码仓库 openeuler/witty-agents。witty-agent-factory 基于仓库中的项目和 Agent 注册表，进一步提供可视化的开发与管理能力，让 Agent 从源码到交付形成更加清晰、规范的工程流程。
代码仓地址：
https://atomgit.com/openeuler/witty-agents.git
传统软件的交付对象通常是服务、镜像或二进制程序。Agent 的交付对象则更加复杂：除了代码，还包括提示词、Skill、工具、知识、模型配置和运行时依赖。
一个 Agent 从源码走向可用版本，通常要经历以下过程：
当 Agent 数量较少时，开发者可以通过代码仓库、Jenkins 控制台和服务器目录分别完成这些工作；当 Agent 逐渐形成生态后，只查看某一次构建结果已经不够。团队还需要了解每个 Agent 的版本、构建状态、产物信息、发布记录以及问题发生的位置。
这意味着 Agent 开发正在从“写出一个能运行的程序”，走向“持续构建、持续验证、稳定交付”的工程化阶段。
目前，一个 Agent 的信息通常分散在多个系统中：代码和配置在仓库，构建过程在 Jenkins，产物在服务器目录，发布版本在 npm registry。开发者需要在不同页面之间反复切换，才能还原一个 Agent 的完整状态。
实际工作中，常见问题主要集中在以下几个方面：
1.信息不集中：不知道当前有哪些 Agent、版本是什么、最近一次构建是否成功。
2.问题定位慢：构建失败后，需要在大量 Jenkins 日志中手动查找原因。
3.产物验证不完整：构建通过不代表 online/offline 包、依赖和安装流程都没有问题。
4.发布过程不透明：版本、dist-tag、构建产物和回下载结果之间缺少统一关联。
5.操作难以追溯：构建、下载、发布和回滚由谁发起、何时发生，缺少统一记录。
可以把传统的管理方式简单理解为：
witty-agent-factory 是面向本地 Agent 开发和管理的可视化工作台。它将 openEuler Agent 生态中的代码仓库、Jenkins 构建任务和 npm 产物信息汇聚到一个平台中，让开发者可以在统一入口查看 Agent 状态、触发构建、检查结果和跟踪发布。
witty-agent-factory 并不替换 Jenkins，也不重新实现一套 CI。它与现有工程基础设施的关系是：
代码仓库保存 Agent 的代码、配置和注册信息；
Jenkins执行实际的构建、验证和发布流水线；
witty-agent-factory统一展示项目、Agent、日志、报告和产物状态；
npm registry保存并提供最终发布包及其版本信息。
这种分工可以复用现有的构建能力，同时避免形成第二套彼此不一致的流水线。
witty-agent-factory以工作台作为统一入口，向上连接开发者和项目管理员，向下连接 Agent 源码仓库、Jenkins 构建系统和 npm registry。平台内部按照项目和 Agent 组织信息，提供 Agent 管理、构建状态、报告产物、发布记录和审计等功能。
▲ 工作台总览，集中展示 Agent、构建、发布和近期操作状态
witty-agent-factory 中的一次 Agent 使用流程可以概括为：
开发者首先进入项目，查看 Agent 的名称、版本、目录和当前状态；然后选择需要构建的 Agent 和构建参数，触发 Jenkins 任务。构建完成后，可以在构建详情中查看流水线阶段、日志、结构化报告和产物信息。如果需要发布，再进入发布管理页面进行发布前检查，确认来源构建和产物状态后，由受控流程完成发布并留下审计记录。
▐ 1. 项目概览：先看整体状态
项目概览页用于快速了解项目健康度，包括 Agent 注册数量、构建记录、构建成功率、绑定的 Jenkins Job、最近操作和数据同步状态。
▲项目概览页，展示项目健康度、Agent 状态和数据同步情况
▐ 2. Agent 管理：了解每个 Agent
Agent 管理页以卡片形式展示当前 Agent，包括 Agent 名称、ID、版本、仓库目录、能力描述和可用操作。在当前工作台中，可以看到 Kernel Dataset Agent、openEuler Ops Agent、Shennong Crash Agent、NL2SQL Agent、vLLM Benchmark Agent 和 XLite Perf Optimizer 等 Agent。开发者可以从这里进入详情、下载产物或发起构建。
▲Agent 管理页，以卡片形式展示 Agent 信息和操作入口
▐ 3. 构建流水线：集中查看构建过程
构建流水线页面集中展示构建任务、触发方式、参数、状态和耗时，并支持按 Agent、状态、Job、触发人和日期进行筛选。进入某次构建后，可以继续查看 11 个流水线阶段、构建日志、结构化报告、安装链路和产物校验信息，从而更快定位构建问题。
▲构建流水线页，支持按条件筛选构建记录
▐ 4. 发布管理：让版本发布更清晰
发布管理页面用于查看版本、dist-tag、来源构建和历史发布记录，并在发布前进行必要检查。witty-agent-factory 负责汇聚信息和管理流程，实际构建与发布仍由 Jenkins 执行。
▲发布管理页，展示 dist-tag 状态、来源构建和发布记录
在发布详情页，平台会进一步展示发布内容、完整性信息、发布门禁和发布链路。例如，REL-01 会检查仓库来源、commit 是否属于目标分支、构建产物是否可用、版本是否可发布以及 dist-tag 是否安全。通过检查后，管理员再确认是否进入发布流程。
▲发布详情页，展示发布门禁、发布链路和版本状态
▐ 1. 访问工作台
开始使用前，可以先访问官方代码仓库，了解 Agent 目录、项目说明和注册配置：
https://atomgit.com/openeuler/witty-agents.git
如果 witty-agent-factory 部署在内网或远程服务器上，通常先建立 SSH 隧道，再打开本地浏览器。示例命令如下，具体主机和端口以部署环境为准：
ssh -N -L 18080:127.0.0.1:18080 -p <ssh-port> <user>@<factory-host>保持隧道窗口运行，然后访问 http://127.0.0.1:18080，登录后即可进入工作台。
▐ 2. 基本使用路线
进入平台后，可以按照以下路线快速熟悉 witty-agent-factory：
进入 witty-agents 项目概览，查看项目健康度、Jenkins Job、最近构建和数据同步状态；
打开 Agent 管理页面，查看 Agent 的版本、目录、描述和可用操作；
进入构建流水线页面，按 Agent、状态或触发人筛选构建记录；
打开某次构建详情，查看阶段、日志、结构化报告和产物校验信息；
进入发布管理页面，查看版本、dist-tag、发布记录和发布前检查；
需要复盘时，到审计页面查看登录、构建、下载和发布等操作记录。
对于普通开发者，最常用的是“查看 Agent—查看构建—检查产物”这条路径；具备相应权限的项目管理员，还可以进一步处理构建、发布和版本回溯。
▐ 3. 本地部署
witty-agent-factory 面向伙伴和开发者提供从零开始的本地部署方式。部署前需要准备：
一台能够访问 AtomGit、Jenkins 和 npm registry 的 Linux 服务器或虚拟机；
Git、Docker Engine、Docker Compose v2 和 OpenSSL；
Jenkins 服务地址、服务账号和 API Token；
如果从远程服务器访问，还需要 SSH 客户端。
第一步：获取代码
git clone https://atomgit.com/openeuler/witty-agents.gitcd witty-agentscd ci/factory
第二步：准备配置
witty-agent-factory 的部署配置放在 ci/factory 目录中。复制环境变量模板，并生成平台密钥：
cp .env.example .envopenssl rand -base64 32
将生成的随机值写入 FACTORY_SECRET_KEY，再填写 Jenkins 地址、服务账号、API Token、代码仓库和需要纳管的 Job。.env 只保存在部署主机，不要提交到代码仓库。
第三步：构建并启动容器
witty-agent-factory 由 API 服务和 Web 前端组成，数据保存在独立数据卷中。使用源码部署时，可以直接构建并启动：
docker compose -f docker-compose.yml up -d --build如果发布版本提供了预构建镜像，则先执行 docker compose pull，再执行 docker compose up -d。具体以当前版本提供的 Compose 文件为准。
第四步：初始化管理员和上游连接
docker compose exec api node scripts/seed-admin.js \--user admin \--password '<strong-password>'docker compose exec api node scripts/smoke-jenkins.js
首次登录后，创建或绑定 witty-agents 项目，配置代码仓库和 Jenkins Job，测试连通性，并同步 agents.json。同步完成后，项目中的 Agent 才会出现在witty-agent-factory 页面中。
第五步：打开工作台
如果witty-agent-factory部署在本机，直接访问 http://127.0.0.1:18080。如果部署在远程服务器上，先建立 SSH 隧道：
ssh -N -L 18080:127.0.0.1:18080 -p <ssh-port> <user>@<factory-host>保持隧道窗口运行，再在本地浏览器访问 http://127.0.0.1:18080，即可进入工作台。
Agent 的开发不仅是把代码写出来，还需要让它能够被持续构建、验证和发布。witty-agent-factory 面向 openEuler Agent 生态，尝试把分散在代码仓库、Jenkins 和 npm registry 中的信息集中起来，提供一个简单、清晰的本地管理入口。从“开发一个 Agent”，到“管理一组 Agent”，witty-agent-factory 希望帮助团队把 Agent 开发逐步变成一种可见、可查、可验证、可追踪的工程流程。
Witty 是 openEuler 的智能运维入口，支持用户通过自然语言处理各类运维问题，内置日志检测、知识库、集群管理、性能调优等全套运维能力套件。基于上述运维套件，Witty 进一步构建问答、故障诊断、性能调优多类智能 Agent，覆盖单机、集群、超节点多种部署场景。本专项旨在演示 Witty 智能运维入口的基础能力，并深度拆解各类智能体，剖析其内部工作原理。
-END-
供稿 | 唐舒楠
编辑 | 丘云
校审 | 赵家麒、郑振宇、刘彦飞
关注我们，了解更多
▼
