内容
<p align="center">
<img width="220" src="https://raw.githubusercontent.com/acornops/docs-website/main/logo/light.svg" alt="AcornOps" />
</p>
<h1 align="center">AcornOps</h1>
<p align="center">
<a href="https://github.com/acornops/acornops/actions/workflows/ci.yml"><img src="https://github.com/acornops/acornops/actions/workflows/ci.yml/badge.svg" alt="CI" /></a>
<a href="LICENSE"><img src="https://img.shields.io/badge/license-MIT-blue.svg" alt="MIT License" /></a>
<img src="https://img.shields.io/badge/contracts-checked-blue.svg" alt="Contracts checked" />
<img src="https://img.shields.io/badge/commits-conventional-green.svg" alt="Conventional commits" />
</p>
<p align="center">
开源、自托管的适用于 Kubernetes 集群和 Linux/systemd 虚拟机的 AI 辅助运维。
</p>
<p align="center">
<a href="https://console.demo.acornops.dev/"><strong>试用在线演示</strong></a>
·
<a href="https://docs.acornops.dev/quickstart">自托管 AcornOps</a>
·
<a href="https://docs.acornops.dev/">阅读文档</a>
·
<a href="https://docs.acornops.dev/integrations">构建集成</a>
</p>
> [!IMPORTANT]
> AcornOps 正在积极实验性开发中。API、部署合约和升级路径可能会在稳定版本发布前发生变化。
AcornOps 通过 outbound target 代理连接中央运维平台到 Kubernetes 集群和 Linux/systemd 虚拟机。运维人员可以检查实时目标上下文、运行有指导的调查、协调受控的补救措施，并从一个管理控制台自动执行可重复的运维工作。
该平台让运维人员保持控制：
- AgentK 和 AgentV 发起到控制平面的 outbound 连接。
- Linux/systemd 内置工具是只读的。
- Kubernetes 写操作需要显式的 RBAC、代理启用、运行权限和工具访问。
- 默认情况下，写确认是必需的，并在特定具有写能力的工具调用之前暂停运行。
- LLM 网关强制执行运行范围的模型和工具访问、运行时限制和预算。
- 远程 MCP 服务器是目标范围的，并且是先发现后启用；发现的工具在被审查和启用之前保持禁用。
从 [公共演示](https://console.demo.acornops.dev/) 开始，遵循 [快速入门](https://docs.acornops.dev/quickstart)，或查看 [系统架构](docs/system-architecture.md)。
## 仓库地图
AcornOps 被分成具有明确合约的独立版本组件。
| 仓库 | 责任 |
| --- | --- |
| [`management-console`](https://github.com/acornops/management-console) | 工作空间、目标、运行、代理、工作流、审批和工具的浏览器体验 |
| [`control-plane`](https://github.com/acornops/control-plane) | 身份验证、工作空间 API、目标注册、运行状态、Webhook 和代理协调 |
| [`execution-engine`](https://github.com/acornops/execution-engine) | 持久运行执行、事件流、重试、取消和工具协调 |
| [`llm-gateway`](https://github.com/acornops/llm-gateway) | 模型提供商路由、MCP 代理、秘密和策略强制执行 |
| [`agentk`](https://github.com/acornops/agentk) | Kubernetes outbound 发现、快照、日志和受控工具执行 |
| [`agentv`](https://github.com/acornops/agentv) | Linux/systemd outbound 快照、日志和只读内置工具 |
| [`acornops-deployment`](https://github.com/acornops/acornops-deployment) | Docker Compose 和 Kubernetes 部署跟踪、兼容性元数据和运行手册 |
| [`charts`](https://github.com/acornops/charts) | 用于包装平台和代理图表的公共 Helm 仓库镜像 |
| [`docs-website`](https://github.com/acornops/docs-website) | 公共运维、部署、集成、架构和 API 文档 |
## 开发 AcornOps
该仓库也是跨独立版本 AcornOps 仓库工作的开发者入口。它拥有工作空间清单、设置助手、共享技能、共享 GitHub 模板和跨仓库文档。产品仓库被检出为忽略的子目录，并保持独立版本。
## 工作空间模型
AcornOps 使用三层：
1. 此仓库中的工作空间核心。
2. 提交到每个独立产品仓库的仓库本地核心。
3. 验证跨仓库合约的平台和集成检查。
从此处开始设置工作空间或检查仓库状态。代理特定操作规则位于 [AGENTS.md](AGENTS.md)；`CLAUDE.md` 导入相同文件，以便代理面对的说明保留在一个位置。
## 代理辅助开发
此工作空间结构适用于人类和代理辅助开发。使用 Codex、Claude Code 或其他编码代理时，从工作空间根目录启动代理以获得最佳结果。根目录包含工作空间清单、共享代理指导、验证助手和跨仓库工作流规则，有助于代理在子仓库之间协调更改。
对于单个仓库工作，代理仍应阅读子仓库的 `AGENTS.md` 然后编辑文件。
## 什么属于这里
- 工作空间设置助手
- 跨 AcornOps 仓库使用的共享代理技能
- 工作空间清单和仓库功能摘要
- 共享技能、GitHub 模板和 Git 钩子的同步工具
- 跨仓库核心和合约检查
- 供应商中立的交接和 Conventional Commit 策略
## 每个产品仓库的内容
- 服务源代码和测试
- 仓库特定的 `AGENTS.md`
- 架构和产品文档
- 仓库拥有的合约清单
- CI 工作流和本地验证入口
- 仓库特定的本地技能位于 `.agents/skills/local`
- 服务特定的运行手册、迁移和滚动笔记
- 仓库特定的标签和 GitHub 工作流秘密
## 仓库布局
```text
acornops/
AGENTS.md
CLAUDE.md
workspace.yaml
.githooks/
.github/
ISSUE_TEMPLATE/
PULL_REQUEST_TEMPLATE/
.agents/skills/shared/
docs/
agent-harness/
scripts/
docs-maintenance/
harness/
sync/
workspace/
*.mjs
lib/
change-sets/
acornops-deployment/ # 忽略的子仓库，用于部署和运维
control-plane/ # 忽略的子仓库，用于控制平面 API
docs-website/ # 忽略的子仓库，用于公共 Mintlify 文档
execution-engine/ # 忽略的子仓库，用于运行执行
agentk/ # 忽略的子仓库，用于工作负载集群代理
agentv/ # 忽略的子仓库，用于 Linux/systemd AgentV 工作
llm-gateway/ # 忽略的子仓库，用于模型和 MCP 代理
management-console/ # 忽略的子仓库，用于浏览器控制台
charts/ # 忽略的子仓库，用于公共 Helm 图表仓库
```
子仓库被故意忽略此父仓库。不要在工作空间仓库中暂存或提交产品仓库内容。
## 入门指南
克隆工作空间：
```bash
git clone https://github.com/acornops/acornops.git
cd acornops
```
设置工作空间：
```bash
task setup
```
`task setup` 从 `workspace.yaml` 克隆缺少的子仓库，通过 HTTPS 规范现有的匹配 GitHub 远程仓库到工作空间清单，然后检查本地工具、子仓库远程仓库、工作空间状态和共享 Git 钩子配置。
了解平台：
- [系统架构](docs/system-architecture.md) 解释了 AcornOps 组件、运行时流程和仓库所有权如何协同工作。
- [`workspace.yaml`](workspace.yaml) 列出了每个子仓库、本地路径、远程仓库、默认分支和验证命令。
在运行设置前预览克隆操作：
```bash
task workspace:bootstrap -- --dry-run
```
如果 Task 未安装，请直接使用底层脚本：
```bash
./scripts/workspace/bootstrap.mjs
./scripts/workspace/doctor.mjs
```
依赖安装和服务启动保持在仓库本地，因为每个产品仓库都拥有自己的运行时。在引导后，阅读受影响的子仓库的 README 和 `workspace.yaml` 中的验证命令。
更多详细信息：[开发者入门指南](docs/developer-getting-started.md)。
## 每日维护
检查父仓库和子仓库状态：
```bash
task workspace:status
```
获取远程引用而不更改本地分支：
```bash
task workspace:fetch
```
仅在默认分支上快速推进干净的仓库：
```bash
task workspace:update
```
`task workspace:update` 跳过具有本地更改的仓库、非默认分支上的仓库、具有未推送提交的分支和不同的历史记录。
为父仓库和子仓库配置工作空间拥有的 Git 钩子：
```bash
task hooks:setup
```
共享钩子运行确定性本地检查，并在失败时打印相关修复。钩子行为记录在 [Sync](docs/agent-harness/sync.md) 中。
## 验证
```bash
task validate
```
`task validate` 运行工作空间核心和跨仓库检查。
提交主题和拉取请求标题遵循 [Conventional Commits](docs/agent-harness/conventional-commits.md)。
## 协调更改
对于影响多个产品仓库的更改：
- 从 `workspace.yaml` 确定受影响的仓库
- 将产品代码更改保留在子仓库中
- 在更改跨仓库时记录协调工作在 `change-sets/`
- 为每个受影响的仓库准备验证证据
- 链接相关的 PR 并在更改相互依赖时包含合并顺序
代理面向的工作流详细信息和助手脚本用法属于 [AGENTS.md](AGENTS.md) 和共享技能工作流，不属于此开发者 README。
更多详细信息：
- [更改集](change-sets/README.md)
- [仓库功能摘要](docs/agent-harness/repository-capability-summary.md)
- [代理交接策略](docs/agent-harness/agent-handoff-policy.md)
- [文档维护](docs/agent-harness/docs-maintenance.md)
- [跨仓库技能工作流](.agents/skills/shared/cross-repo-change/workflow.md)
## 共享技能
共享技能在工作空间中维护，并在共享代理指导更改时同步到子仓库。
预览更改：
```bash
./scripts/sync/shared-skills.sh --dry-run
```
有意应用：
```bash
./scripts/sync/shared-skills.sh
```
同步命令仅更新 `.agents/skills/shared` 和 `.agents/skills/README.md` 到配置的子仓库中。它从不覆盖 `.agents/skills/local`。
父工作空间不保留 `.agents/skills/local` 目录。工作空间技能默认共享；子仓库保留自己的本地技能。
## Claude 设置
共享 `.claude/settings.json` 在工作空间中维护，并在更改时同步到子仓库：
```bash
./scripts/sync/claude-settings.sh --dry-run
./scripts/sync/claude-settings.sh
```
同步仅复制 `.claude/settings.json`。它从不同步机器特定的 `.claude/settings.local.json`，也不删除子仓库拥有的 `.claude` 文件。
## GitHub 模板
工作空间拥有的拉取请求和问题模板位于 `.github/` 下，因此父仓库可以直接使用它们。它们也可以同步到配置的子仓库：
```bash
./scripts/sync/github-templates.sh --dry-run
./scripts/sync/github-templates.sh
```
GitHub 模板同步仅复制允许列出的问题和拉取请求模板文件。它不触及子仓库工作流或删除子仓库拥有的 `.github` 文件。共享问题模板故意不设置默认标签；标签是仓库特定的，应在需要时在每个子仓库中配置。
连接信息
猜你喜欢
暂无推荐服务器