从会话到执行：AI 中台为什么要拆控制面、运行时和工具层
约 2734 字大约 9 分钟
2026-05-17
很多团队第一次做 AI 中台时，最自然的想法都是：先做一个聊天接口，把消息传给模型，再把回复流式返回出来。这个起点没问题，但系统只要继续往前走一步，很快就会发现“聊天接口”根本不是 AI 平台的真实边界。用户会话、工具调用、前端工具回传、知识搜索、语音链路、运行时状态、长任务控制，这些能力一旦叠上来，如果还停留在一个“大聊天服务”的思路里，代码结构会迅速失控。
联犀当前的 AI 中台之所以要拆控制面、运行时和工具层，本质上是在回答一个问题：AI 平台到底在管理什么。它管理的并不是单次模型调用，而是一套从会话建立、上下文组织、工具决策、运行时执行到结果回传的完整系统。只有把这几个层次拆开，AI 中台才可能长期演进，而不是在越来越多的特殊链路中变成一个难以维护的大协调器。
会话层回答的是“谁在和谁对话”
AI 系统表面上最显眼的是消息流，但真正稳定系统的往往是会话层。
没有会话层，系统只能处理“这次请求要不要调模型”；有了会话层，平台才能开始回答：
- 当前是谁在对话
- 这轮对话属于哪个 session
- 对应哪个 Agent 或 Clone
- 当前是文本通道、语音通道还是设备通道
- 这轮输入结束后，是否还要继续等待工具结果或语音收尾
联犀在这一层用了 ChatManager、ChatSession、ai_sessions、ai_session_summaries 这组结构，把“会话头”和“轮次记录”区分开来。这样做的意义不只是数据存储更清楚，而是让运行时终于可以稳定映射到一个 session 世界，而不是每次都把请求当成孤立调用。
特别是在语音和工具调用场景里，这一层极其关键。因为一旦进入流式语音、前端 tools、长轮次对话，系统面对的就不再是一个“请求-响应”瞬时动作，而是一个有生命周期的会话状态机。没有会话层，后面的运行时和工具层都无从挂靠。
控制面回答的是“平台如何组织 AI 系统”
很多系统把所有 AI 逻辑都塞进调用链里，最后会出现一个典型问题：模型在执行什么、会话是否还活着、工具结果回来了没有、某个 clone 的运行环境是否就绪，这些状态全都混在一次业务请求里。联犀把 aisvr 保留为控制面，正是为了避免这种混合。
控制面的职责，不是直接代替运行时执行所有动作，而是组织整套 AI 中台的主数据和流程边界，例如：
- Agent / Clone / Session 主数据
- 会话生命周期
- 技能与工具的装配入口
- 知识加载与搜索入口
- HTTP / RPC / app service 等外部入口
换句话说，控制面更像平台的大脑。它知道一场对话应该由哪个 Agent 或 Clone 承接，知道当前会话应该关联哪些上下文，知道工具结果回传后要唤醒哪个 session，也知道什么时候该启动或关闭某个运行时。但它不应该承担所有执行细节，否则控制面最终会退化成又大又重的执行器。
运行时回答的是“模型这一轮到底怎么执行”
这也是为什么联犀必须把运行时单独拉出来看。
真正的一轮 AI 执行，不只是“调用 LLM”，而是一个动态过程：
- 先组织模型输入
- 决定是直接回答还是发起 tool call
- 执行后端工具或等待前端工具回传
- 必要时继续多轮推理
- 最后输出文本、事件流或工具执行结果
这一层如果继续写在通用 API 逻辑里，很快就会出现逻辑打结。因为聊天入口、用户入口、语音入口、设备入口虽然都能触发 AI，但它们共享的不是 HTTP 结构，而是运行时执行规律。联犀通过 AgentRuntime、ChatSession、tool orchestration 相关能力，把这部分抽离出来，让模型的决策循环在一个更稳定的运行时层里完成。
这层拆分的好处很明确。入口层只负责接入语义，运行时层负责执行语义。前者决定“谁调用了平台”，后者决定“平台这一轮如何工作”。这样系统既能同时支持文本、语音和设备链路，也不会因为接入方式不同而复制多套模型执行逻辑。
工具层回答的是“模型能碰哪些外部能力”
AI 中台发展到一定阶段，工具层几乎一定会成为最复杂的部分。因为模型一旦不只会说话，它就需要接触：
- 本地工具
- MCP 工具
- 知识搜索工具
- 前端 tools
- 设备控制工具
这些工具表面上都叫 tool，但实际语义完全不同。有些是后端直接执行，有些要等前端回传结果，有些是受网络隔离约束的外部能力，有些则只是知识检索过程中的辅助步骤。如果平台没有把工具层单独组织出来，很快就会出现“模型工具调用逻辑”和“具体工具实现”缠在一起的问题。
联犀的做法是，工具不是聊天逻辑里的临时分支，而是 AI 运行时里的一级能力对象。
这意味着：
- 工具装配有统一入口
- 不同来源的工具有明确适配层
- 前端 tool 与后端 tool 的差异是被架构承认的，而不是被临时 if/else 处理
这样做尤其重要，因为工具层其实决定了 AI 中台的扩展上限。会不会对接 MCP、会不会支持知识工具化、会不会支持前端工具回传，本质上都不是“加几个接口”那么简单，而是工具层是否已经被当成平台正式组件来设计。
为什么要拆前端工具与后端工具
这是很多 AI 平台在后期才会意识到的问题。
从模型视角看，工具就是工具；但从后端视角看，前端工具和后端工具的执行方式完全不同。后端工具可以直接调用，前端工具则必须通过会话事件流通知客户端执行，再等待 tool-result 回传。它们共享工具语义，却不共享执行链路。
如果平台忽略这一点，把所有工具都当作可以直接同步执行的能力，系统很快就会在“模型决定调用前端动作”这类场景下卡住。联犀在这一层的处理方式，是把前端 tools 注册给模型可见，但不由后端直接执行；后端负责下发 tool_call_execute 事件，并在收到工具结果后继续运行时推理。
这说明 AI 中台里“工具层”的难点从来不只是工具 schema，而是执行契约。只有契约清楚，会话、运行时和工具层之间的分工才会稳定。
控制面、运行时、工具层拆开之后，平台才开始像一个平台
如果从业务视角看，用户可能仍然只感知到一个聊天窗口或一个设备对话入口；但从架构视角看，联犀已经不再是“一个大聊天接口”，而是一套分层的 AI 平台：
- 会话层负责状态与生命周期
- 控制面负责主数据与调度
- 运行时负责模型执行循环
- 工具层负责外部能力装配与回传契约
这套分层最重要的收益，不是“代码更优雅”，而是平台终于能面对复杂度增长。新增一种工具类型，不必重写整个聊天入口；新增一种接入方式，不必复制一套运行时；新增一种安全隔离策略，也不必把主会话逻辑一起改穿。
从开源仓库结构反看这套分层
如果再结合 .gits/ 下面现有的开源仓库去看，会发现这套分层不仅存在于主仓设计里，也开始自然长成独立仓库边界。
.gits/sandbox：更接近执行面，承载安全运行时与任务执行环境.gits/cli：更接近统一工具入口，把平台能力整理成 AI 与人类都能消费的命令和 Skill 生成链路.gits/skills：更接近可分发能力面，把设备、产品、AI、协议脚本等能力组织成 AI Agent 可加载的 Skill 集合
这三个仓库并不等于 AI 中台的全部，但它们很好地说明了一个事实：当控制面、执行面和工具面已经能沿着不同方向独立演进时，这通常意味着边界已经足够稳定，不再只是代码里的临时拆分，而是可以被仓库级组织进一步印证的系统层次。
AI 中台真正难的地方，从来不在于让模型回一句话，而在于当模型开始拥有记忆、工具、知识、设备能力和多通道接入之后，系统还能不能继续维持清晰边界。联犀把控制面、运行时和工具层拆开，正是为了让这种复杂度增长被不同层次分别吸收，而不是一起堆到一个入口函数里。
总结
从会话到执行，AI 中台真正管理的是一整条运行链，而不是单次模型调用。
如果系统只有聊天接口，它迟早会在工具化、多通道、长会话和安全隔离面前变得越来越重；只有当控制面、运行时和工具层各自拥有稳定职责，平台才真正具备持续演进能力。
联犀这套分层给出的经验可以概括成一句话：
AI 平台不是“模型接得越快越好”，而是“每一层复杂度都要有自己的归属”。会话有会话的边界，执行有执行的边界，工具有工具的契约。只有这样，AI 中台才不只是一个能聊天的后端，而是一套真正可扩展、可治理、可继续生长的系统。
更新日志
2026/8/4 07:04
查看所有更新日志
7e927-文档站全面重构：目录重排、首页重写、案例独立成站、应用市场下线于3a4f0-新增第19篇博客文章，重构全部博客为目录+README结构于43ef3-docs(blog): 新增后端与架构系列技术博客 18 篇，更新原有 7 篇于