用户159899的组织用户1453
你的项目很适合走“ Hermes 式 Agent Kernel + OpenClaw 式 Gateway/Control Plane ”的混合改造路线
输入“/”快速插入内容
你的项目很适合走“ Hermes 式 Agent Kernel + OpenClaw 式 Gateway/Control Plane ”的混合改造路线
你的项目很适合走“ Hermes 式 Agent Kernel + OpenClaw 式 Gateway/Control Plane ”的混合改造路线
用户1453用户14535月9日修改
⏰ 保存时间：2026-05-09 10:19:03 (UTC+8)
你的项目很适合走“ Hermes 式 Agent Kernel + OpenClaw 式 Gateway/Control Plane ”的混合改造路线
先说结论： 你现在的项目已经有“可拆”的基础，但还没真正拆出团队边界。
它已经出现了几个很好的雏形：一边是 DeepAgentRuntimeFacade / DeepAgentRuntimeService / DeepAgentsAIProvider 这条“智能体执行内核”链路，另一边是 agent-runtime 、 agent-blueprints 这类“控制平面 API”雏形；同时 TeamRuntimeFacade 也明显在做“旧 runtime → 新 deep-agent path”的迁移过渡。问题在于，这些能力现在大多还被装在 同一个 FastAPI 进程、同一个 DI 容器、同一个启动生命周期 里，所以从组织协作角度看，API/Web 团队和智能体团队还没有真正分家。 项目源码：main.py 项目源码：application_bootstrapper.py 项目源码：deep_agent_runtime_facade.py 项目源码：team_runtime_facade.py
你项目当前最值得肯定的地方
你并不是从零开始。
从代码上看，你已经有了非常接近目标架构的三个“切口”：
第一， 运行时核心已经开始独立出来了 。 DeepAgentRuntimeFacade 负责准备运行时请求、装配 blueprint / tools / skills / context， DeepAgentRuntimeService 负责 build / execute / stream， DeepAgentsAIProvider 又把它包装成更统一的 IAIProvider 实现。这说明你已经在往 Hermes 那种“平台无关 Agent Core” 的方向走。 项目源码：deep_agent_runtime_facade.py 项目源码：deep_agent_runtime_service.py 项目源码：deepagents_ai_provider.py Hermes 架构文档
第二， 控制平面 API 已经出现了 。 /agent-blueprints 和 /agent-runtime 这两组路由，本质上已经在表达“配置/蓝图管理”和“执行调用”是两类不同职责，这非常像 OpenClaw 把 gateway/control plane 从 agent runtime 前面单独拎出来的思路。 项目源码：agent_blueprint_router.py 项目源码：agent_runtime_router.py OpenClaw Gateway OpenClaw 架构文档
第三， 你已经在处理“旧系统兼容 → 新执行内核”的迁移问题 。 TeamRuntimeFacade 明写了 legacy path 和 deep-agent path 的阶段迁移策略，这意味着你不是简单重写，而是在做一条可演进的替换路径。这一点非常重要，因为真正能支持“两支团队并行开发”的架构，往往不是一次性重构出来的，而是靠这种 façade/compatibility seam 慢慢挪出来的。 项目源码：team_runtime_facade.py
但你现在真正的“耦合点”在哪里
最大的问题不是代码写得乱，而是 边界没有被提升成“协议” 。
目前 main.py 的应用生命周期里同时做了数据库初始化、Nacos 初始化、DI 容器初始化、checkpointer warmup、AI provider warmup、agent recover、job scheduler、skills sync，这说明 平台启动 和 智能体运行时启动 还混在一起。只要 API/Web 团队改一次应用启动，智能体团队就会被影响；反过来，智能体运行时的预热、恢复、cron 变更，也会影响 API 服务的发布与稳定性。 项目源码：main.py 项目源码：application_bootstrapper.py
第二个明显耦合点是 router 直接拿容器里的 runtime 实例 。 agent_runtime_router.py 和 agent_blueprint_router.py 都是从 request.app.state.container 里直接取运行时服务；甚至在拿不到 container 时，还会自己 Container() 一次。这个设计在单体阶段很方便，但它意味着你的“上层应用”并不是通过稳定协议调用智能体，而是通过 进程内对象引用 调用智能体。这样一来，未来想让 Web 团队单独发版、甚至换成另一个服务语言，就会很难。 项目源码：agent_runtime_router.py 项目源码：agent_blueprint_router.py 项目源码：container.py
第三个问题是 应用层和基础设施层仍有泄漏 。比如 ConversationService 放在 application/services ，但内部直接跑 SQLAlchemy 查询和数据库连接；这会让未来的平台团队和智能体团队在“会话/消息”边界上反复扯皮：这到底是平台会话，还是智能体上下文？如果不尽快分清，会越做越粘。 项目源码：conversation_service.py
第四个问题是 同一容器里装了太多不同节奏的东西 。Container 同时接管仓储、runtime、tool resolution、skill resolution、orchestrator、team runtime、conversation service、API use cases。这在代码组织上没错，但在组织协作上会变成“谁都能碰谁”。这不利于你说的那种“一个团队做 API/Web，另一个团队维护智能体”。 项目源码：container.py
Hermes 最值得借鉴的不是“功能多”，而是它把 AIAgent 作为平台无关核心 ，所有入口——CLI、Gateway、API、Batch——最终都只是调用同一颗内核。也就是说，Hermes 的思想是： 先有 Agent Kernel，再有各种外部壳子。 Hermes 架构文档 Hermes Messaging
放到你的项目里，最应该做的是把下面这些东西明确划成 agent-core ：
•
blueprint 解析与装配
•
runtime context 构造
•
tool resolution / skill resolution
•
stream event 协议
•
subagent / team coordination 执行核心
•
memory / checkpointer / artifact 访问抽象
你现在的 DeepAgentRuntimeFacade 、 DeepAgentRuntimeService 、 DeepAgentBlueprintProvider 、 SkillRegistry ，其实已经很像这个方向，只是它们还没被提炼成一个 独立于 FastAPI、独立于 Web、独立于 app.state/container 的核心包 。 项目源码：deep_agent_runtime_facade.py 项目源码：deep_agent_runtime_service.py 项目源码：deep_agent_blueprint_provider.py 项目源码：skill_registry.py
Hermes 还特别强调 registry / plugin / provider 这种可插拔结构。你项目里已经有一些这类痕迹，比如 skill registry、tool resolution、MCP adapter、agent registry；所以不是要推翻重来，而是要 把这些抽象从“容器里的服务”升级成“核心 runtime contract” 。 Hermes 架构文档
OpenClaw 最该学的不是 channel 多，而是它把 Gateway/Control Plane 做成稳定边界。
上层的 Web UI、CLI、聊天渠道、节点设备、自动化客户端，都不是直接摸 agent runtime，而是统一走 Gateway；Gateway 负责鉴权、会话、路由、协议、多端接入，runtime 只负责执行。 OpenClaw Gateway OpenClaw 架构文档 OpenClaw Channel Routing
放到你的项目里，这意味着你应该让 API/Web 团队拥有一个独立的 gateway / control-plane 层，它负责：
•
用户、组织、权限、配额
•
会话与消息记录
•
文件上传与 artifact 元数据
•
任务创建、run 查询、取消、重试
•
SSE / WebSocket / webhook / future mobile SDK