作者：泽哥｜灏仟亿大前端技术团队
1. 核心结论
企业级 Agent 中台是公司内部 Agent 能力的统一基础平台。平台以统一 Web 工作台为入口，以 Hermes 作为主调度 Agent，以 LiteLLM 作为基础能力网关，统一管理 Agent、MCP、Tools、Skills、权限、审批、审计和执行结果。
MVP 阶段重点验证一套可持续扩展的中台骨架：任务统一接入，Agent 可编排，工具可复用，执行可审批，结果可回写，过程可审计。
2. 建设定位
| 维度 | 结论 |
|---|---|
| 平台定位 | 公司级 Agent 能力基础平台 |
| 统一入口 | Web 工作台 |
| 主调度 | Hermes |
| 基础能力网关 | LiteLLM |
| 核心管理对象 | Agent、MCP、Tools、Skills、权限、审批、审计 |
| MVP 验证对象 | 业务层、开发层、业务-开发混合层 |
| 生产化要求 | 可审批、可回写、可观测、可审计 |
3. 当前问题与目标形态
当前主要问题是入口分散、流程分散、AI 能力分散、工具能力难复用、业务与研发链路割裂、执行过程缺少统一审计。中台目标是把工作从"人找系统、人理解流程、人操作系统"转为"人发起任务、Agent 调度执行、系统回写、全链路审计"。
4. 总体架构
整体架构分为七层：统一入口层、场景验证层、Agent 中台控制平面、Agent 运行时层、能力与引擎层、系统连接层、统一输出层。
5. Web 工作台功能图
Web 工作台是唯一主入口，承担任务创建、场景选择、执行查看、审批处理、结果查看、管理配置和审计查询。
6. 三类场景闭环
MVP 阶段用三类场景验证中台是否成立：业务层、开发层、业务-开发混合层。三类场景必须共用同一套任务模型、调度能力、能力管理、审批审计。
7. 业务场景功能图
业务层验证 Agent 对真实业务任务的理解、工具选择、业务系统调用、审批和回写能力。
8. 开发场景功能图
开发层不以 IDE 能力建设为核心，重点验证 Agent 是否能承接研发任务流，并将人工职责收敛到审核、驳回、合并和发布确认。
9. 业务-开发混合场景图
混合层验证业务问题能否转化为研发任务，PRD 能否转化为开发执行链路，业务规则能否进入审批和系统变更流程。
10. 控制平面能力地图
控制平面负责"谁能用、能做什么、调哪个 Agent、用什么工具、是否审批、如何记录、如何回写、失败如何处理"。
11. Hermes / LiteLLM / Agent 分工
Hermes 负责调度，LiteLLM 负责基础能力治理，Agent 负责具体任务执行。三者职责必须清晰拆分。
12. 能力目录：MCP / Tools / Skills
MCP、Tools、Skills 统一进入能力目录，避免被单个 Agent 私有化。
13. LiteLLM 能力网关
LiteLLM 统一管理模型、MCP、基础 Tools、基础 Skills、Agent Access、Budget、Rate Limit 和调用日志。
14. 审批与风险分级
自动化边界按风险等级控制。低风险可自动执行，中风险需要确认，高风险必须审批，关键变更必须审计。
| 级别 | 动作类型 | 示例 | 控制方式 |
|---|---|---|---|
| L0 | 只读查询 | 查询订单、查询 PR 状态 | 自动执行 |
| L1 | 生成建议 | 处理建议、方案生成 | 自动执行并记录 |
| L2 | 创建任务 | 创建研发任务、创建审批单 | 自动或确认 |
| L3 | 修改非核心数据 | 更新备注、任务状态 | 人工确认 |
| L4 | 修改业务数据 | 回写订单、修改履约信息 | 审批 |
| L5 | 发布或关键变更 | 合并 PR、发布、计价规则变更 | 强审批 |
15. 审计与观测闭环
企业级 Agent 中台进入生产的关键是可追踪、可复盘、可评估。
16. 最小原子化结构
所有场景共用同一套原子结构，保证任务、计划、调用、执行、结果和审计可复用。
17. 核心状态机
18. MVP 范围
| 优先级 | 范围 | 目标 |
|---|---|---|
| P0 | Web 工作台、统一任务模型、Hermes、Agent 编排、LiteLLM、MCP、Tools、Skills、权限、审批、审计、三类场景验证 | 建立中台骨架 |
| P1 | 状态机、过程可视化、工具调用记录、失败重试、审批驳回重跑、系统回写、运行监控、成本统计 | 形成执行闭环 |
| P2 | 知识库、复杂 BI、复杂看板、多端入口、多租户、质量评估、成本优化、多 Agent 优化 | 增强平台能力 |
| 不纳入 MVP | 独立 AI Coding 平台、IDE 插件、移动端入口、全量知识库、全业务无人自动化、复杂低代码平台、全量业务系统改造 | 控制范围 |
19. 研发任务拆分
| Epic | 目标 | 交付物 |
|---|---|---|
| Epic 1：Web 工作台 | 提供统一入口 | 任务创建、任务详情、审批处理、结果查看、审计入口 |
| Epic 2：统一任务模型 | 统一所有场景的任务表达 | WorkItem、AgentTask、Plan、ToolCall、ExecutionRun、Result、AuditLog |
| Epic 3：Hermes 主调度 | 统一任务理解、计划、Agent 选择和结果汇总 | 调度服务、任务路由、Agent 选择、失败重试、结果汇总 |
| Epic 4：LiteLLM 网关 | 统一 Model / MCP / Tools / Skills / Agent Access | Gateway、模型配置、MCP 接入、调用日志 |
| Epic 5：Agent 编排中心 | 支持自定义 Agent 和场景绑定 | Agent 注册、模板、版本、场景绑定、测试运行 |
| Epic 6：能力管理 | 平台化管理 MCP / Tools / Skills | 能力目录、权限配置、调用记录 |
| Epic 7：权限、策略与审批 | 控制 Agent 自动化边界 | 权限模型、风险分级、审批流程、高风险拦截 |
| Epic 8：审计与观测 | 实现全链路可追踪 | 审计日志中心、链路详情、成本统计、错误报表 |
| Epic 9：业务层验证 | 验证业务任务可执行 | 订单异常、物流计价、数据整理链路 |
| Epic 10：开发层验证 | 验证研发任务可执行 | 代码生成、测试修复、PR、人工审核链路 |
| Epic 11：混合层验证 | 验证业务到开发闭环 | PRD 到研发、规则变更、异常到修复任务 |
20. 阶段路线图
21. MVP 验收标准
| 验收维度 | 标准 |
|---|---|
| 平台层 | Web 成为统一入口；WorkItem 统一承载任务；Hermes 可调度不同 Agent；LiteLLM 可管理基础能力；Agent 可自定义编排；MCP / Tools / Skills 可注册复用；权限、审批、审计完整 |
| 场景层 | 业务层至少完成 1-2 个场景闭环；开发层至少完成 1 个场景闭环；混合层至少完成 1 个场景闭环 |
| 执行层 | 任务能创建、能调度、Agent 能执行、工具能调用、失败能重试、高风险能审批、结果能回写、过程能审计 |
| 复用性 | 同一个 Tool 可被多个 Agent 使用；同一个 Skill 可被多个场景复用；同一个 Agent 可被多个流程编排；同一个 WorkItem 模型可承载三类场景 |
22. 风险与控制
| 风险 | 控制方式 |
|---|---|
| 平台定位偏向 Coding 平台 | 业务、开发、混合三类场景一起验证 |
| 平台定位偏向聊天式单点工具 | 输出必须进入任务、审批、回写、PR、报表或审计 |
| Hermes 责任过重 | 业务逻辑下沉到业务引擎、流程引擎和规则引擎 |
| LiteLLM 被误用成业务中台 | 业务流程、审批策略、任务生命周期放在控制平面 |
| 知识库优先导致 MVP 发散 | MVP 重点验证调度、编排、工具调用、审批、回写、审计 |
| 各场景独立建设 Agent 系统 | 所有场景必须走统一任务模型和中台能力 |
| 自动化边界不清 | 建立 L0-L5 风险分级和强审批机制 |
23. 最终结论
本项目 MVP 的目标是建设能够持续接入 Agent、调度 Agent、管理工具、完成场景闭环验证、审计执行结果的企业级 Agent 中台骨架。
当业务层、开发层、业务-开发混合层三类场景均可通过同一套中台能力完成闭环验证，并实现 Agent 可编排、工具可复用、结果可回写、过程可审计时，中台即具备持续扩展为公司级 AI 操作系统的基础。