从会话到执行: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/5/18 10:48
查看所有更新日志
43ef3-docs(blog): 新增后端与架构系列技术博客 18 篇,更新原有 7 篇于
