OpenHive面向技术团队与生产团队

01 / 20

开场

把 Agent 从 Demo 带到可治理的生产运行。

OpenHive 是一个开源控制平面，用来创建、运行和治理 Agent 系统：平台级监控、项目级协作、渠道助手、审批、审计、隔离执行和可控演进统一在一个操作模型里。

OpenHive为什么需要控制平面

02 / 20

生产断层

生产系统的问题不是“能不能回答”，而是“能不能安全地持续工作”。

权限边界

Agent 什么时候可以执行工具？什么时候必须停下来等人审批？

证据链路

每次决策、Prompt、工具调用、变更和回滚都要可追踪。

运行隔离

代码、命令、供应商密钥和业务凭据不能混在一个不受控进程里。

持续演进

自我改进必须经过评估、审批、发布和回滚，而不是无约束自改。

OpenHive一句话定位

03 / 20

OpenHive 是什么

OpenHive 是受治理 Agent 系统的开源控制平面。

它不是单一垂直应用，也不是聊天助手框架；它提供统一运行时、可信扩展、审批边界、审计回放、隔离执行和多 Agent 编排。

控制

谁能运行、能运行什么、用什么模型、触达什么资源。

治理

评估、审批、审计、发布和回滚成为一等产品能力。

扩展

业务行为来自模板、插件、技能包和策略，而不是写死在核心运行时。

OpenHive系统总览

04 / 20

平台形态

从平台网关到 Agent 运行时，再到 Dashboard 与扩展层。

Gateway

无 LLM 控制层

认证、准入、路由
凭据代理和密钥边界
调度器和交互卡片
平台 API 与审计入口

HiveAgent

唯一 Agent 运行时

Queen / Keeper / Scout 都是配置实例
工具注册表与能力策略
运行状态、审批恢复、上下文治理
模型供应商抽象

Extensions

业务行为注入

项目模板和蓝图
插件与技能包
技能以子进程执行
本地/市场扩展治理

OpenHive角色地图

05 / 20

Agent 角色

一个运行时，多种职责。

Platform

Queen

平台监控 Agent，负责平台健康、异常窗口、Keeper 静默检测和平台级审计线索。

Project

Keeper

项目经理 Agent，协调项目、分析信号、提出变更、管理 Scout 和工作流。

Channel

Scout

群组或渠道助手，响应用户、执行已安装技能、收集反馈和上下文。

Task

Worker

面向受控任务或沙箱执行的工作角色，承接更强隔离或更专门的执行路径。

Schedule

Pipeline

周期性分析、分类、告警、报告和 Prompt Shadow 的后台执行路径。

OpenHiveQueen Agent

06 / 20

平台操作员

Queen 不是业务助手，而是平台层面的运行监控者。

心跳与健康

管理员可以查看 Queen 心跳、最近运行、连续健康、失败窗口、下次计划运行。

异常与静默

Queen 关注平台异常、静默 Keeper、漏跑任务和需要运维关注的状态。

审计联动

Queen 事件进入平台审计，运行详情可以与具体修复、Diff 和审批记录关联。

对生产团队来说，Queen 是“平台值班视角”；对技术团队来说，Queen 是平台健康、调度和运行时治理的可观测入口。

OpenHiveKeeper Agent

07 / 20

项目经理 Agent

Keeper 把项目运行从“聊天响应”提升为“项目治理”。

协调

创建和管理 Scout，组织项目工作流和协作上下文。

分析

处理反馈队列、运行评估、识别变更候选。

提案

生成可评审的变更、技能演进或工作任务，而不是直接改生产行为。

执行

在审批和能力边界内驱动工具、技能和沙箱工作。

OpenHiveScout 与渠道

08 / 20

一线协作入口

Scout 让 Agent 进入团队协作现场，但能力必须被安装和授权。

渠道内工作

Feishu / Lark 是当前基线集成，未来可扩展到更多消息提供方。

技能约束

Scout 只能执行已安装、已分配、符合凭据声明的技能。

反馈闭环

Scout 收集现场信号，Keeper 分析，生产负责人通过审批和审计确认。

OpenHive运行时原则

09 / 20

单运行时原则

HiveAgent 是唯一运行时；角色差异来自配置，不来自多套 Agent 类。

One runtime, N configs.

降低复杂度

Queen、Keeper、Scout、Worker 共享运行时循环、工具治理、上下文治理和观测模型。

避免场景污染

核心运行时保持业务无关；业务价值由插件、技能、模板、策略注入。

便于验证

安全边界、审批恢复、工具计划和审计链路可以在同一运行时模型上验证。

OpenHive执行隔离

10 / 20

Docker / K8s / 本地隔离

隔离是从预览走向生产的关键分水岭。

preview_local

本地预览

默认可快速启动，但 in-process LocalAgentPool 不是硬进程边界。

local subprocess

本地隔离进程

隔离 Agent 运行时，清理继承环境变量，并通过网关中继访问模型。

Docker

容器执行

将 Agent / Sandbox / Pipeline 任务放入更清晰的运行容器边界。

Kubernetes

集群基线

通过 Pod、NetworkPolicy、健康检查和烟测逐步证明生产拓扑。

表达要精确：当前预览路径是产品评估入口；更强的密钥驻留与网络边界需要显式隔离路径和部署验证。

OpenHive密钥边界

11 / 20

Credential Proxy / Provider 管理

生产团队关心的不只是“能调用模型”，而是密钥在哪里。

网关持有

供应商密钥和集成凭据应尽量停留在 Gateway 或明确可信的密钥持有角色中。

加密与遮罩

Provider Secret 可由管理员管理，加密存储，读取时只返回遮罩状态，不返回原始值。

中继访问

隔离运行时通过 Gateway Relay 获得受预算、受模型 allowlist 和受作用域限制的访问。

OpenHive审批边界

12 / 20

RunState / ToolExecutionPlan

高影响工具调用先形成计划，再决定是否执行。

模型请求工具

运行时接收工具名、参数和上下文。

生成执行计划

记录能力、参数摘要、幂等键和策略决策。

需要审批则中断

RunState 进入 awaiting_approval，副作用尚未发生。

人工决策

批准、拒绝、过期或要求更多上下文都进入审计。

恢复或终止

批准后只执行一次；拒绝后模型收到安全的工具结果。

OpenHivePrompt Shadow

13 / 20

影子 Prompt 测试

新 Prompt 先并行验证，不直接替换生产 Prompt。

生产路径

Pipeline 正常运行当前生产 Prompt，结果继续服务真实通知和工作流。

影子路径

同一 Pipeline 步骤使用 shadow_prompt 再跑一次，产出候选输出。

评审路径

系统保存生产/影子差异，Dashboard 中待 PM 或生产负责人审批后才推广。

Prompt Shadow 让“调 Prompt”从手工猜测变成可比较、可审计、可回滚的上线流程。

OpenHive受治理自我演进

14 / 20

Self-evolution, but governed

OpenHive 不主张无约束自我进化，而是受治理的持续改进。

信号

反馈、失败、误判、重复需求和运行后复盘候选。

草案

Keeper 或演进插件生成技能、Prompt、内存或策略修改建议。

评估

运行测试、Prompt Shadow、Diff、证据和安全扫描。

审批

人类负责人决定是否推广到本地安装副本或项目配置。

回滚

历史和审计让生产团队可以追责与恢复。

OpenHive技能与扩展

15 / 20

Plugin / Skill / Marketplace

把业务能力放在可安装、可审计、可升级的扩展边界里。

Skills

无状态能力单元，以 JSON stdin/stdout 子进程运行，不直接共享核心状态。

Plugins

接入渠道、策略、卡片动作、演进逻辑等平台能力。

Bundles

把模板、技能包、策略和蓝图组合为可复用工作负载起点。

Governance

安装、升级、编辑、推广和执行都进入权限、审计和本地副本管理。

OpenHiveDashboard

16 / 20

生产可见性

Dashboard 是生产团队与平台团队共享的操作台。

Projects

项目概览、Agent 状态、运行、会话、工作任务、配置和技能治理。

Usage

跨项目用量、趋势、成本线索和运行规模视图。

Audit

平台事件、项目变更、Diff、审批和 Queen 事件的审计入口。

Admin

Queen 监控、用户准入、Provider 管理、平台 AI 治理和运行时维护。

OpenHive工作负载选择

17 / 20

首批试点

选择有重复性、有负责人、有证据链的工作。

Pilot A

安全内部 Agent

编码支持、技术研究、文档流程、内部运营助手；适合技术团队先吃自己的狗粮。

Pilot B

研究与监控工作流

周期性分析、生态跟踪、告警、报告生成；适合生产团队验证持续运行价值。

Pilot C

客户与运营 Agent 队列

支持、产品、区域或流程专属 Agent，在共享策略和发布控制下扩展。

OpenHive部署演进

18 / 20

从 Preview 到 Production-facing

不要把预览拓扑说成生产隔离；要按阶段证明。

preview_local

本地 Docker PostgreSQL、FastAPI、Next.js，验证产品路径与团队协作。

isolated runtime

引入分离进程、环境清理、Relay 模型访问和密钥驻留验证。

Docker sandbox

把受控命令、工作区任务、Patch 审批和日志采集放到容器边界。

Kubernetes baseline

用 Pod、NetworkPolicy、健康检查、烟测和发布验证支撑更强部署模型。

OpenHive团队对齐

19 / 20

试点前必须回答

技术团队和生产团队需要共同定义边界。

技术团队问题

哪些运行时必须进程/容器/Pod 隔离？
哪些密钥绝不能进入 Agent 环境？
哪些工具调用必须先形成 ToolExecutionPlan？
哪些日志、Trace、RunState 和审计必须保留？

生产团队问题

谁拥有审批责任？SLA 是什么？
什么差异可以自动通过，什么必须人工复核？
Prompt Shadow 的成功标准是什么？
什么触发回滚、暂停或升级处理？

OpenHive下一步

20 / 20

本次建议

选一个受治理工作流，端到端跑通“运行、证据、审批、演进”。

最好的第一步不是铺开很多 Agent，而是选择一个重复发生、价值可衡量、审批责任清晰、失败可回滚的生产场景。

1. 定试点

一个业务/平台工作流，一个 Owner，一个衡量指标。

2. 定边界

隔离模式、密钥驻留、工具审批、Prompt Shadow 和回滚规则。

3. 跑闭环

Queen 监控平台，Keeper 管项目，Scout 进渠道，Pipeline 做影子评估。