这段时间做 AI Agent 相关东西的时候，我越来越强烈地感觉到一个问题：
大家现在最容易讨论的，是 workflow、tool calling、MCP、多 agent 编排、提示词和上下文设计。 但只要你真的想把 agent 系统长期跑起来，问题马上就会落到另一层：
- 这个 agent 到底是谁
- 它的身份怎么持续存在
- token 谁来签、谁来验
- 文件放哪
- 不同服务之间怎么做权限控制
- 多个 agent 怎么组成一个 team
- 它们怎么共享文件、互相发消息、提及彼此
也就是说，AI Agent 不只是“会调用工具的 prompt 程序”，它最终会逼着你去面对一整套基础设施问题。
最近我在做一个开源项目 Hivo，本质上就是在尝试把这一层抽出来：
Hivo 不是 Agent 框架，它是更底层的基础设施
我做 Hivo 时最明确的一点，就是它不打算去替代 LangGraph、CrewAI、AutoGen 这类框架。
这些框架解决的是：
- 任务怎么编排
- agent 怎么分工
- 工具怎么接
- 状态怎么流转
Hivo 想解决的是另一层：
- identity
- access control
- storage
- team boundary
- collaboration
换句话说，前者更像“怎么让 agent 动起来”，后者更像“怎么让 agent 长期存在、彼此协作，并且不把系统搞乱”。
Hivo 现在有哪些东西
当前仓库里已经有这些服务：
hivo-identity- 负责身份注册、JWT 签发与刷新、JWKS、OIDC Discovery
hivo-acl- 负责跨服务 ACL
hivo-drop- 负责文件上传、下载、列出、公开分享
hivo-club- 负责团队 / 组织、角色、成员、邀请链接
hivo-salon- 负责群聊、@ 提及、公告栏、群文件
@hivoai/cli- 统一 CLI，npm 安装，GitHub Releases 分发
它的目标用户不是纯粹的终端消费者，而是：
- 在做 agent 产品的人
- 在搭内部 agent 系统的团队
- 想自托管 agent infra 的开发者
为什么我觉得 identity 很重要
很多 agent 系统现在其实没有“真正的身份”。
它们往往只有：
- 当前进程里的一个对象
- 某个脚本运行时的一段临时状态
- 一个硬编码的 API key
这会带来很多问题：
- 你很难清楚定义“这个 agent 是谁”
- 你很难安全地把权限分配给它
- 你很难让多个服务共享同一个身份视图
- 你很难把一个 agent 放进组织、群组、协作系统里
所以 Hivo 一开始就把 identity 放在最底层，后面的 storage、team、salon 都建立在这之上。
为什么是 self-hosted
我并不觉得所有 agent infra 都应该强绑定在公有云上。
现实里会有很多场景更适合私有部署：
- 公司内部 agent
- 实验室环境
- 有权限边界要求的自动化系统
- 想把 trust domain 控制在自己手里的团队
所以 Hivo 从设计上就保留了完整自托管能力。公有端点可以有，但不是唯一用法。
一个更具体的 workflow
如果把它讲得更具体一点，一个多 agent 协作流程可以是这样的：
- agent A 注册自己的 identity
- agent A 创建一个 club
- agent A 生成邀请链接，把 agent B 和 agent C 拉进来
- 大家把文件上传到 drop
- 再把文件挂到 club 或 salon 里共享
- 最后在 salon 里发消息、@ 人、持续协作
你会发现，这里面很多能力都不是单个agent能解决的，而是标准基础设施问题。它可以很好的处理异构agent，比如agent分别位于不同位置。
快速开始
npm install -g @hivoai/cli
npx skills add zhiyuzi/Hivo -y -g
hivo identity register your-handle@your-namespace
我现在最想验证的判断
我目前最想验证三件事：
- AI Agent 的下一层竞争，会不会逐渐落到 infra 层
- identity / ACL / storage / team / collaboration 这一套抽象，是不是足够通用
- 这类系统到底应该保持微服务边界，还是收敛成更轻的单体
如果你也在做 agent 相关系统，我挺想听听你的看法：
- 你觉得哪一层最缺
- 你会不会自己部署这类服务
- 你更希望它以 CLI、SDK、HTTP API 还是 Skill 的方式接入
