适合读者 ：AI 产品经理、技术决策者、准备接触火山引擎体系的开发者
写作视角 ：以产品经理视角梳理架构逻辑，重点讲清楚"每层是干什么的、怎么选、怎么配合"
说明：本文基于火山引擎公开资料与个人项目调研整理，具体能力与计费以官方最新文档为准
一、背景：为什么需要"AI 云原生架构"
过去一年，大模型应用的落地方式发生了明显变化：
- 第一阶段：直接调一个大模型 API，做个对话 Demo（开发快，但难上生产）
- 第二阶段：加上 RAG、Prompt、知识库，做成"能用的应用"（开始涉及工程化）
- 第三阶段：企业要同时运行成百上千个 Agent，对接 ERP/OA/数据库等内部系统，还要管权限、评测、观测、安全（这才是"生产级"）
火山引擎把这套面向第三阶段的需求，抽象成了 AI 云原生架构 ，核心思路是------围绕 Agent 的开发与运营重构整条技术链路。
对我们产品经理来说，理解这套架构的价值在于：
- 做技术选型时知道该选哪个产品（而不是被一堆名词绕晕）
- 和研发沟通时能对齐"这一层该谁来做"
- 提前识别项目里的风险点（权限、数据、评测、私有化等）
二、一张图看懂三层架构
火山引擎在 2025 年 FORCE 原动力大会上明确了这套以模型为中心的三层架构：
┌─────────────────────────────────────────────────────┐
│ Agent 运营层 │
│ HiAgent "1+N+X" │
│ 智能体低代码搭建 / 统一调度 / 治理 / 全生命周期运营 │
├─────────────────────────────────────────────────────┤
│ Agent 开发层 │
│ AgentKit │
│ SDK / 运行时 / 沙箱 / 记忆 / 网关 / 观测 / 评测 │
├─────────────────────────────────────────────────────┤
│ 模型服务层 (MaaS) │
│ 火山方舟 │
│ 模型广场 / 推理 / 精调(SFT/RLHF) / 评测 / 安全 │
└─────────────────────────────────────────────────────┘一句话概括三层职责：
火山方舟"产智能" → AgentKit"造 Agent" → HiAgent"管 Agent"
三、逐层拆解
3.1 火山方舟（MaaS 层）------ 模型能力的"批发商"
定位：一站式大模型服务平台，即 Model-as-a-Service。
核心能力：
| 能力 | 说明 |
|---|---|
| 模型广场 | 豆包全系（Doubao-Seed 文本、Seedream 图像、Seedance 视频、SeedAudio 语音）、DeepSeek 系列等 |
| 推理部署 | 模型以 API 形式对外提供，按 Token 调用 |
| 模型精调 | 支持 SFT / RLHF 等定制化训练 |
| 评测 & 安全 | 模型效果评估、安全互信计算 |
产品经理视角 ：这一层可以理解成 "模型商店 + 模型加工厂" 。如果团队只是想调个模型 API 做个应用，只买火山方舟就够了，不需要往下看。
3.2 AgentKit（Agent 开发层）------ Agent 的"生产车间"
定位 ：企业级 AI Agent 开发平台，解决的核心问题是------Agent 做出来之后，怎么长期稳定地跑在生产系统里。
它不教你写 Agent 逻辑，而是提供一整套"让 Agent 能安全可控规模化运行"的中间件模块，覆盖 Agent 全生命周期：
- Identity 身份认证
- Runtime 运行时
- Sandbox 云沙箱
- Gateway 网关 / 系统接入
- Memory 记忆
- Observability 可观测
- Evaluation 评测
- Guardrails 安全围栏
开发者用 Python / Golang 基于这些模块开发 Agent。官方数据称 开发代码量可减少约 96%，首次部署 2-3 分钟完成。
产品经理视角 ：这一层是给开发者用的底层基础设施 。如果你的项目需要深度定制 Agent 逻辑、对接复杂内部系统、对运行稳定性要求高，就需要研发基于 AgentKit 开发。它是把"模型能力 + 企业系统 + 业务逻辑"组装成生产级 Agent 的地方。
3.3 HiAgent（Agent 运营层）------ Agent 的"运营总部"
定位：面向中大型政企的"1+N+X"一站式智能体工作站。
核心能力：
- "1+N+X"体系：1 个 AgentSphere 调度中枢 + N 个通用智能体 + X 个业务定制智能体
- 低代码搭建：业务人员也能组装智能体
- 统一纳管：可接入和纳管基于 HiAgent、火山引擎、第三方搭建的智能体
- MCP Gateway：打通 ERP / OA / 数据库等 300+ 企业内部系统
- 全生命周期运营：评测、观测、数据工程
- 统一入口：不论 Agent 来自 Coze、自研系统还是 AgentKit，员工通过一个入口即可调用与岗位、权限匹配的 Agent
产品经理视角 ：这一层是给企业管理者和业务人员用的 。当企业里有成百上千个 Agent 时，就需要 HiAgent 来做统一调度、权限治理、协同运营------否则就是一堆碎片化孤岛。
四、三者的配合关系
完整的业务链路是这样的：
火山方舟 ──(API 推理)──> AgentKit ──(开发部署 Agent)──> HiAgent ──(纳管/调度)──> 员工入口(飞书/钉钉等)
│ │ │
│ │ └─ 统一权限、评测、观测
│ └─ 运行时/沙箱/记忆/网关等底座
└─ 豆包、DeepSeek 等模型能力关键协同点：
- HiAgent 基于 AgentKit 的底层技术模块（身份认证、运行时、云沙箱等）构建
- AgentKit 开发完成的 Agent 可无缝接入 HiAgent 进行统一纳管
- HiAgent 的模型推理默认走火山方舟；私有化/混合部署场景下，可敏感数据走本地、非敏感数据走云端
五、容易混淆的几个产品
火山引擎产品矩阵里和 AI Agent 相关的容易搞混，这里对比一下：
| 产品 | 主要使用者 | 定位 | 一句话比喻 |
|---|---|---|---|
| AgentKit | 开发者 | 底层开发平台，写代码、深度定制 | Agent 的"生产车间" |
| HiAgent | 企业业务/管理者 | "1+N+X"智能体工作站，低代码 + 运营 | Agent 的"运营总部" |
| 扣子 (Coze) | 个人/轻量团队 | 快速搭建职场 AI 工作流 | Agent 的"快速搭建工具" |
| 火山方舟 | 开发者/算法 | MaaS 模型服务 | 模型"批发商" |
核心区别：
- AgentKit vs HiAgent：前者偏"造 Agent"（开发），后者偏"管 Agent"（运营），服务对象不同
- 扣子 vs HiAgent：扣子更轻量、面向快速搭建；HiAgent 面向企业级大规模治理
- 三者都跑在火山方舟 MaaS 之上
六、产品经理视角的选型建议
结合项目（计划）使用火山引擎体系的场景，给出几个实用判断：
6.1 什么情况选什么
| 你的项目现状 | 推荐方案 |
|---|---|
| 只想调模型 API 做个应用 / Demo | ✅ 只用火山方舟 |
| 需要深度定制 Agent、对接复杂系统、要稳定生产 | ✅ 火山方舟 + AgentKit |
| 企业内有大量 Agent 需统一治理、权限、协同 | ✅ 火山方舟 + AgentKit + HiAgent |
| 想快速搭建、低代码、团队规模不大 | ✅ 可考虑扣子，或火山方舟 + HiAgent |
6.2 三个容易被忽略的风险点
- 数据合规：涉及敏感数据时，优先确认是否支持私有化/混合部署（MaaS on AICC 机密计算能力）
- 系统集成成本：对接 ERP/OA/数据库等内部系统的工程量往往被低估，建议提前盘点
- Agent 治理：一旦 Agent 数量上来，权限、版本、评测、观测必须前置设计，否则后期难维护
6.3 与研发沟通时的关键问题清单
- 模型层用火山方舟哪个模型？是否需要精调？
- Agent 开发基于 AgentKit 还是自研框架？
- 是否需要 HiAgent 做统一纳管？Agent 数量预估多少？
- 私有化部署需求？数据合规要求？
- 内部系统（ERP/OA/数据库）对接清单？
七、总结
一句话概括三者关系：
火山方舟是"智能供应商"、AgentKit 是"Agent 生产车间"、HiAgent 是"Agent 运营总部"。
对 AI 产品经理而言，理解这套分层的价值在于：
- 不重复造轮子：知道哪一层该用现成产品、哪一层需要自研
- 对齐技术语言：和研发沟通时能快速定位问题在哪一层
- 提前规划治理：Agent 规模化运营的能力要前置设计，而非事后补救
参考资料
- 火山引擎官方文档 & FORCE 原动力大会（2025）相关发布
- 火山方舟、AgentKit、HiAgent 官方产品页
⚠️ 免责声明：本文为个人学习整理，能力描述与计费政策请以火山引擎官方最新文档为准。如有错误欢迎指正。