Syntheos-Systems/henosis
GitHub: Syntheos-Systems/henosis
Henosis 是一个源码可用的持久化 agent runtime，通过身份验证、策略审批、沙盒执行和审计链等机制，确保 AI agent 的每一次公开操作都经过严格的多重边界校验。
Stars: 1 | Forks: 0
# Henosis
Henosis 是一个处于公测开发阶段的源码可用持久化 agent runtime。它采用 [Elastic License 2.0](LICENSE) 授权，而非开源许可证。
Henosis 的构建围绕一条核心规则：agent action 并不会仅仅因为模型的请求就视为完成。每一个公开的 action 都会跨越服务器所有的身份验证、策略、审批、凭证、执行和审计边界。本 alpha 版本包含：
- 机器和人类操作员身份验证，并带有实时的租户成员资格检查；
- 请求绑定的、仅限一次的审批记录，持久化存储于 SQLite 中；
- 同步的哈希链审计记录，并带有独立签名的见证选项；
- 类型化的 Wasmtime Component Model host，具备 fuel、内存、时间、输出和网络限制；
- 一个凭证边界，在不返回原始 secret 的情况下暴露指定的 broker 操作；以及
- 单个 `henosis` 可执行文件，用于初始化、诊断、控制和服务。
## 安装公测版
原生发行版压缩包包含一个启动可执行文件：`henosis`。安装程序会检测宿主机
平台，要求与 `SHA256SUMS` 中的 SHA-256 校验和匹配，仅安装到当前用户账户下，
运行 `henosis init --quick`，并在初始化失败时恢复先前的可执行文件。
在 Linux 或 macOS 上，复制并运行以下命令：
```
curl --proto '=https' --tlsv1.2 --fail --silent --show-error --location \
https://raw.githubusercontent.com/Syntheos-Systems/henosis/1a9ff0730f36e9a3af537e09177d36e3be204229/install.sh \
| sh -s -- --version v0.1.0-alpha.3
```
在 Windows 上，打开 PowerShell，复制此命令并按 Enter：
```
$installer = Join-Path ([IO.Path]::GetTempPath()) "henosis-install-$([guid]::NewGuid().ToString('N')).ps1"
try {
irm 'https://raw.githubusercontent.com/Syntheos-Systems/henosis/1a9ff0730f36e9a3af537e09177d36e3be204229/install.ps1' -OutFile $installer
$powerShell = (Get-Process -Id $PID).Path
& $powerShell -NoProfile -ExecutionPolicy Bypass -File $installer -Version 'v0.1.0-alpha.3'
if ($LASTEXITCODE -ne 0) { throw "Henosis installer exited with code $LASTEXITCODE" }
} finally {
Remove-Item -LiteralPath $installer -Force -ErrorAction SilentlyContinue
}
```
这两个命令在单独选择发行版本的同时，将经过审查的安装脚本固定到其完整的 Git commit，因此移动的 tag 无法在验证之前替换代码。在下载
二进制文件之前，安装程序要求 GitHub 将该发行版报告为已发布且不可变。设置
`HENOSIS_VERSION`、`HENOSIS_RELEASE_BASE`、`HENOSIS_RELEASE_API` 或 `HENOSIS_INSTALL_DIR` 可以
覆盖安装程序的默认设置。
这就是本地模式下完整的安装和初始化路径。它不需要检出源码、Rust 工具链、容器 runtime、数据库服务器、账户、密码或 API key。
安装程序在创建本地私有配置时，既不会要求也不会生成用户
密码。启动 loopback 服务并保持终端开启：
```
$HOME/.local/bin/henosis serve
```
在 Windows 上：
```
& "$HOME\.local\bin\henosis.exe" serve
```
当 `http://127.0.0.1:8088/health` 返回 `ok` 时，Henosis 就准备就绪了。使用 `Ctrl+C` 停止它。
打开第二个终端执行剩余的命令。首次启动会在 `HENOSIS_HOME` 下
创建一个私有的本地 owner token。实时的 CLI 命令会自动读取该 token，并且除非需要显示新请求的一次性 token，否则绝不打印它。
为 agent 或集成创建一个带作用域的机器 token，并捕获其一次性凭证：
```
export HENOSIS_AGENT_TOKEN="$($HOME/.local/bin/henosis token create first-agent --token-only)"
```
在 Windows 上：
```
$env:HENOSIS_AGENT_TOKEN = & "$HOME\.local\bin\henosis.exe" token create first-agent --token-only
```
Loopback 兼容授权仅识别稳定的本地房间
`!henosis-local:loopback` 中的 `henosis.probe`。通过 `context.room` 传入该房间。
每次公开的 dispatch 都需要在 `X-Henosis-Idempotency-Key` 中提供一个唯一的重试身份。Key 的作用域
限定为经过身份验证的 tenant 和 principal。使用相同的 key 和完全相同的请求进行重复调用，会返回
之前存储的过滤后结果，而不会再次运行工具。将相同的 key 用于不同的
内容则会返回冲突。
```
curl --fail-with-body http://127.0.0.1:8088/api/v1/dispatch \
-H "Authorization: Bearer $HENOSIS_AGENT_TOKEN" \
-H "Content-Type: application/json" \
-H "X-Henosis-Idempotency-Key: first-agent-probe-1" \
--data '{"tool":"henosis","action":"probe","args":{},"context":{"room":"!henosis-local:loopback"}}'
```
在 Windows 上：
```
$headers = @{
Authorization = "Bearer $env:HENOSIS_AGENT_TOKEN"
"X-Henosis-Idempotency-Key" = "first-agent-probe-1"
}
$body = @{
tool = "henosis"
action = "probe"
args = @{}
context = @{ room = "!henosis-local:loopback" }
} | ConvertTo-Json -Depth 3
Invoke-RestMethod -Method Post -Uri "http://127.0.0.1:8088/api/v1/dispatch" `
-Headers $headers -ContentType "application/json" -Body $body
```
需要审批的操作返回 `202 Accepted` 以及一个审批 ID。使用 `henosis approvals approve ` 批准该 ID，然后使用原始的幂等 key 和 `X-Henosis-Approval-Id` 重复完全相同的 dispatch。
操作员 WebSocket 客户端通过提供 `henosis.v1, henosis.auth.` 子协议进行身份验证，而无需在 URL 中包含凭证。服务器仅协商 `henosis.v1`，在连接期间检查实时的组织成员资格，并在 token 签名的有效期到期时断开连接。
## 本地开发
本地模式默认绑定到 `127.0.0.1:8088` 的 loopback。它面向单个操作员设计，并使用内嵌的本地策略后端。其配额和速率限制计数器会在进程重启时重置。请勿将本地模式直接暴露给网络。
```
docker compose -f containers/compose.local.yml up --build
curl http://127.0.0.1:8088/health
```
Compose 服务运行与原生安装程序相同的幂等 `henosis init --quick` 路径。持久化状态保持在指定的 `henosis-state` volume 中。
## 生产环境前置条件
生产环境需要受管的 PostgreSQL 授权、受保护的持久化存储、TLS 终端、
带有基于来源的登录速率限制的经过身份验证的 ingress、备份、独立的审计
见证，以及专有的 `phylaxd` 凭证 broker。操作员通过
`cred` 管理凭证；`phylaxd` 对其进行代理，Henosis 通过
私有的、经过身份验证的 endpoint 与其独立部署的服务进行通信。
完整的 Pistis 服务是一个私有的、专有的集成，不包含在此
repository 中。Henosis 包含一个狭窄的 fail-closed 兼容性决策核心，用于 loopback 本地
模式。在部署提供来自 Pistis 的受信任
room-state 之前，携带能力的生产环境请求将被持续拒绝。
### 集成边界
Henosis 将模型选择和能力授权保留在接口之后。生产环境部署将这些接口之外的凭证代理保持在外部。
| 边界 | 选择 | 部署契约 |
| --- | --- | --- |
| Model provider | Anthropic, Ollama, OpenAI 兼容的代理, OpenCode Zen, OpenAI Codex, Azure OpenAI, Foundry, 或 Claude Max CLI | 通过 `ProviderConfig` 选择 provider。兼容 OpenAI 的路径支持额外的服务，而无需更改 Henosis 代码。 |
| 能力授权 | 内嵌的 loopback 兼容性策略或受 feature gate 控制的 Henosis room-state 适配器 | 通过 `PistisAuthority` 选择授权。当受信任的状态缺失或无效时，受限工具将 fail closed。 |
| 专有服务 | `phylaxd` 和完整的 Pistis 服务 | 生产环境凭证需要 `phylaxd`。使用受管房间信任的部署需提供来自完整 Pistis 服务的受信任的 room-state 集成。这两个服务均不包含在此 repository 中。 |
`read`、`write`、`edit`、`ls`、`grep` 和 `glob` 工具仅接受
相对于任务根目录的路径。它们拒绝绝对路径、父级遍历和符号链接逃逸。`bash` 是一个独立的、
显式的能力，而不是文件系统沙盒；它使用 Henosis 进程
被授予的操作系统访问权限运行。
仅在完成以下操作后，才能使用 `containers/compose.production.yml`：
1. 将 `containers/production.env.example` 复制到被忽略的 `containers/.env.production` 文件中，并替换每一个占位符。
2. 将 base64 编码的 32 字节审计来源签名 key 和见证公钥放入具有严格权限的被忽略的 `containers/secrets` 目录中。
3. 从发行版的
`container-image.env` 资产中复制 `HENOSIS_IMAGE_REPOSITORY` 和 `HENOSIS_IMAGE_DIGEST`。
4. 在 bootstrap 变量中选择第一个操作员的电子邮件和密码。首次成功启动后，请移除这两个 bootstrap 变量。
使用同一个私有环境文件启动生产环境 Compose 以进行变量插值和服务
配置：
```
docker compose --env-file containers/.env.production -f containers/compose.production.yml up -d
```
镜像引用始终包含 `@sha256:`。Docker 会在启动服务之前拒绝缺失或格式错误的 digest。
生产环境 compose 文件不发布任何主机端口。
## 发行版验证
每次发行版都会发布平台压缩包、`SHA256SUMS`、SPDX SBOMs 和 Sigstore attestation
bundles。在使用前请验证压缩包：
```
grep -F ' henosis-0.1.0-alpha.3-x86_64-unknown-linux-musl.tar.gz' SHA256SUMS \
| sha256sum --check
```
GitHub 还为每个压缩包存储了由 OIDC 支持的来源证明。GitHub CLI 会验证 artifact、
repository 身份和发行版工作流：
```
gh attestation verify henosis-0.1.0-alpha.3-x86_64-unknown-linux-musl.tar.gz \
--repo Syntheos-Systems/henosis \
--signer-workflow Syntheos-Systems/henosis/.github/workflows/ci.yml
```
发行版工作流仅接受由记录在受保护的
`release` 环境的 `RELEASE_ALLOWED_SIGNERS` 变量中的 GhostFrame key 签名的带注释 tag。
`security/release-allowed-signers` 文件是公开的审计副本，而不是工作流的信任来源。
被标记的 commit 必须存在于 `origin/main` 上。在发布之前，必须启用 repository 的不可变性，并且一个处于活动状态的 `v*` tag 规则集必须将 tag 的创建、更新和删除限制为
GhostFrame。工作流会在发布之前和之后立即比较准确的远程 tag 对象。
发行版工作流构建 Linux x86-64 和 arm64、macOS Intel 和 Apple Silicon，以及 Windows x86-64 压缩包。当 GitHub package 发布可用时，它还会发布 Linux amd64/arm64 容器镜像。
## 安全与支持
请私下将漏洞报告发送至 [security@syntheos.dev](mailto:security@syntheos.dev)。将非敏感的支持请求发送至 [support@syntheos.dev](mailto:support@syntheos.dev)。有关范围和处理指南，请参阅 [SECURITY.md](SECURITY.md)。
## 当前限制
公开的限制列表位于 [scripts/known-incomplete.md](scripts/known-incomplete.md)。在任何网络暴露之前，Alpha 部署必须对其进行审查。
## 贡献
在提交 issue 或 pull request 之前，请阅读 [CONTRIBUTING.md](CONTRIBUTING.md)。
标签：AI智能体运行时, Streamlit, Wasm沙箱, 代码分析, 凭证管理, 可视化界面, 审计日志, 测试用例, 版权保护, 访问控制, 身份与策略管理, 通知系统