AgentGroup 为什么不是普通分组：AI 中台如何支持不同业务

约 2594 字大约 9 分钟

2026-05-17

很多团队在做 AI 中台时，最容易低估的一件事，是“同一个 AI 平台其实会服务很多不同业务”。客服想要一类助手，营销想要一类助手，技术支持、运营分析、设备助手、用户侧悬浮聊天入口，又会要求完全不同的提示词、工具、权限边界和运行策略。如果系统里只有一张 Agent 表，把所有智能体平铺管理，短期看当然够用，长期却很容易失去组织能力。

联犀为了解决这个问题，引入了 AgentGroup。它表面上看像是“给 Agent 加了个分组”，但真正作用并不是界面上更好管理，而是让 AI 中台能够稳定支持不同业务。换句话说，AgentGroup 不是普通分组，而是一种 AI 业务组织模型。

普通分组只能解决管理问题，解决不了业务问题

如果只是从后台管理视角出发，给 Agent 加分组似乎已经够了：列表更清晰，查询更方便，用户可以按名称和标签筛选。但 AI 中台的难点并不只是“怎么找到某个 Agent”，而是“怎么让一组 Agent 对应一类稳定的业务用途”。这两件事看起来接近，实则差别很大。

普通分组关注的是归类。它回答的问题是：这些对象属于哪一堆。
而 AI 业务组织关注的是用途。它回答的问题是：这组智能体服务哪个场景，默认继承哪些能力，谁可以使用，和其他业务域之间如何隔离。

如果系统里没有这个层次，后面就会出现很典型的问题。客服和营销助手可能只是名称不同，但底层依然共用同一套配置语义；用户侧悬浮对话和平台运营助手混在一起，既不利于权限控制，也不利于默认能力装配；更麻烦的是，一旦想对某一类业务做统一调优，系统里没有天然挂载点。

AgentGroup 的真正作用，是把“用途”显式化

联犀在 AgentGroup 设计里最关键的一个字段不是名称，而是 useBy / purpose 这类用途语义。这个字段的价值，在于它明确告诉系统：这不是一组随便归类的 Agent，而是一组服务于特定业务场景的 Agent。

这看起来像一个小字段，但它背后决定了很多事情。
一旦用途被显式化，平台就可以自然地区分：

面向普通租户用户的对话助手
面向平台管理者的运营或配置助手
面向设备和 AIoT 场景的智能体
面向不同垂直业务的专属 Agent 集合

也就是说，AgentGroup 不是在管理“对象属于哪个文件夹”，而是在管理“业务场景应该默认拿到哪一组 AI 能力”。这才是它与普通分组的本质差异。

为什么一组 Agent 需要形成一个业务边界

AI 中台和传统对象管理系统不一样。普通对象被分组之后，往往彼此只是列表上的组织关系；而 Agent 被放进一组之后，通常还会共享很多运行语义。例如组级系统提示词、默认 LLM 配置、默认技能集合、默认 MCP 服务集合等。

这意味着 AgentGroup 自带一种“业务边界容器”的属性。它让团队可以把稳定、可复用、且属于同一业务场景的默认能力先放在组级，再由单个 Agent 做局部差异化。这样一来，平台获得的不只是更好的管理界面，而是一种更合理的配置继承模型。

如果没有组级边界，很多默认配置都会被迫下沉到每个 Agent 上重复维护。短期看只是多填几个字段，长期则会导致两个问题。第一，配置漂移。原本应该共享的一组业务助手，会因为手工维护而慢慢出现不一致。第二，治理困难。平台想整体升级一类业务助手的默认能力时，必须逐个 Agent 扫描和修正，成本很高。

AgentGroup 通过组级边界把这种问题拦在了更早的位置上。它让“这是哪一类业务助手”先成立，之后才是“这一类助手内部有哪些具体变体”。

为什么要支持树形分组和全局唯一约束

联犀当前的 AgentGroup 不是只有平铺列表，还参考了物联网平台里设备分组的成熟思路，支持层级关系与成员约束。这一设计说明，AgentGroup 不是为了做一个轻量标签系统，而是希望它具备足够稳定的组织能力。

树形结构的价值在于，很多业务用途并不是单层分类。例如“用户助手”下面可能继续细分成售前、售后、陪伴、教育；“企业侧助手”也可能再拆成运营、知识管理、流程辅助。平铺分组只能解决第一层组织，而树形结构让 AI 中台在业务扩展后仍然保有层次感。

全局唯一约束则体现了另一种取舍。联犀并没有把 Agent 设计成可以同时漂浮在多个分组里，而是默认一个 Agent 只属于一个主要业务归属。这样做看似限制了灵活性，实际上是在防止语义混乱。因为对 AI 系统来说，一个 Agent 最怕的不是能力少，而是用途不清。如果它同时被定义为客服助手、营销助手和技术助手，最终系统很难回答“它到底该按哪套规则被默认使用、被谁调用、在什么地方被自动分配”。

所以，树形结构解决的是“业务层次如何表达”，全局唯一约束解决的是“业务归属如何保持清晰”。这两点组合起来，AgentGroup 才真正具备平台级组织能力。

AgentGroup 如何支撑“不同业务”的 AI 中台

这也是 AgentGroup 最值得对外总结的地方。很多人在谈 AI 中台时，容易把重点放在模型、提示词和工具链上，忽略了“业务组织层”其实同样重要。没有 AgentGroup 这种中间层，系统很容易只有两级结构：平台和 Agent。这样一来，所有差异都只能落在单个 Agent 上，平台很难形成按业务场景组织和治理能力。

联犀引入 AgentGroup 后，AI 中台实际上变成了四层结构的一部分：AgentGroup → Agent → Clone → Session。
其中 Group 这一层回答的是：这个 AI 能力服务哪个业务场景。Agent 回答的是：这组场景下的具体智能体是什么。Clone 回答的是：某个用户、设备或业务对象是否拥有自己的专属分身。Session 则负责一次次实际对话。

从这个角度看，AgentGroup 不再只是管理工具，而是 AI 中台多业务支持的入口。平台可以基于不同业务创建不同用途的 Group，给每类 Group 配置不同的默认技能、权限和系统提示词，再让上层产品能力按用途选择或自动匹配对应 Agent。这比单纯让业务方手动从所有 Agent 中挑一个，要稳定得多。

用户侧入口为什么尤其依赖 AgentGroup

联犀在“用户 AI 交互”能力上就很好地体现了这一点。普通租户用户并不会理解 AI 配置细节，也不会在几十个 Agent 里自己挑一个对话入口。平台更现实的做法，是先定义一个 purpose=user 的 AgentGroup，然后当用户第一次发起对话时，系统自动从该组中选取可用 Agent，为其分配专属 Clone。

这套流程如果没有 AgentGroup，会非常别扭。系统要么硬编码一个默认 Agent，要么在多个 Agent 中做不透明选择。两者都不够好。
而有了 Group 之后，平台终于拥有了一个自然的“默认业务入口层”：只要业务属于用户对话场景，就从 purpose=user 的组里找能力。这使得用户入口和后台 AI 配置之间形成了稳定映射，而不是靠散乱约定连接。

这也是为什么 AgentGroup 对不同业务支持如此关键。它不只是给后台管理员多一个组织维度，而是让产品层可以把“业务类型”和“AI 能力集合”对应起来。

7e927-文档站全面重构：目录重排、首页重写、案例独立成站、应用市场下线于 2026/8/4
3a4f0-新增第19篇博客文章，重构全部博客为目录+README结构于 2026/5/28
43ef3-docs(blog): 新增后端与架构系列技术博客 18 篇，更新原有 7 篇于 2026/5/18