企业级 Agent 架构演进：ZillizTown 的工程实践与思考
导语
软件世界的流量入口正在发生结构性迁移——从浏览器和原生 App，快速向 Agent 与 Skills 演进。主流 SaaS 厂商纷纷开放 MCP 接口，Skills 正在替代传统 App，开发周期从月级缩短至分钟级。在这个范式切换的节点，“小模型 + 好 Skills” 正在展现出比 “大模型无 Skills” 更强的业务落地能力。
然而，Agent 从个人效率工具走向企业级协作系统，仍面临巨大的工程鸿沟。ZillizTown 基于 Claude Code 构建，通过 Hub+Connector 架构、双层消息收敛机制以及基于 Milvus 的多租户集体记忆，为企业级 Agent 落地提供了一套可执行的完整工程范式。
核心问题与挑战
当我们将视线从单机版的 Coding Agent 投向企业生产环境时，四个核心痛点浮出水面：
- 物理距离未突破：传统 Coding Agent 仅解决了“效率距离”，人依然被困在电脑前、终端里，Agent 无法随时随地触达。
- 协作网络缺失：以 OpenClaw 为代表的单人架构，无法支撑企业内多人、多职能的横向通信与共享空间，Agent 沦为信息孤岛。
- 群聊消息泛滥：多 Agent 协作极易演变成群聊灾难，缺乏有效的消息收敛与治理机制，导致信息轰炸。
- 多租户检索噪声：在百万级用户场景下，传统大图向量检索存在严重的跨租户噪声干扰，图不连通，召回率断崖式下降。
方案与实践
1. 打破物理距离：IM 接入与主动驱动
让 Agent 真正融入企业流转的第一步，是让它住在员工每天高频使用的 IM（如飞书）里。在 ZillizTown 中，Avatar 随时可通过私聊或群聊 @唤起，无需切换应用。
更重要的是，Agent 从被动响应转向了主动驱动。通过 Cron MCP，Avatar 可以自己“设闹钟”创建定时任务，实现自主巡检与有状态执行。它不等你开口，而是观察你、记住你、主动关心你，表现得像一个真正的同事。
2. 从单打独斗到多人协作：Hub+Connector 架构
为了突破单人架构的局限，ZillizTown 设计了 Hub+Connector 架构，将 N 个 Avatar 编织成一张 N × (N-1) 条路径的协作网络：
- Hub（中心路由）：作为能力索引与注册拓扑，负责 Avatar 间的发现与消息路由。
- Connector（连接器）：独立管理 Avatar 进程，支持 A2A（Agent-to-Agent）对等通信与自动 Session 托管。
这种架构使得“Avatar 找 Avatar 帮忙”成为可能，经过 Hub 路由，Agent 间可以互相发消息、派任务，实现企业级协作。
3. 治理与收敛：让多 Avatar 像一个团队
针对多 Agent 群聊吵闹的问题，ZillizTown 引入了双层消息收敛机制：
- 第一层：LLM 自主判断。Avatar 接收到消息后，由 LLM 自主决策是静默（SKIP）、回复（REPLY）还是开话题（THREAD）。
- 第二层：话题硬路由锁定。通过系统级路由规则，将特定话题强制锁定给指定 Avatar，避免多 Agent 交叉抢答。
双管齐下，确保多 Avatar 协作时边界清晰、不吵闹。
4. 企业级能力补齐：MCP 封装与配置即人格
ZillizTown 定义了 4 个核心 MCP 来补齐企业 Agent 缺失的维度（时间、空间、业务、连接）。其中，Feishu MCP 的设计尤为关键：它绝不是对飞书 Open API 的简单透传，而是对业务意图的封装。让 Agent 说业务语言，而非底层接口语言。
在人格定义上，ZillizTown 采用“配置即人格”的三层叠加框架：
- 骨架（CLAUDE.md）：定义 Agent 基础人设与行为边界；
- 能力：定义 Agent 能做什么；
- 规则（MEMORY.md）：定义 Agent 的长期约束与偏好。
配合实时、智能、无感的 Training 机制，用户在飞书对话中即可完成对这三层配置的修改，无需触碰代码文件，实现了 Agent 的在线自我进化。
5. 记忆与检索：集体记忆沉淀与多租户隔离
记忆系统存在明确的分工：短期记忆常驻上下文，长期记忆按需语义检索。传统 RAG、Skills RAG 与 Agentic Search 三种形态并存互补。
在 ZillizTown 中，所有 Avatar 的经验汇入同一份 Milvus 存储，个人记忆自然沉淀为组织共享的集体智慧。针对多租户检索的痛点，系统采用 Milvus Partition Key Isolation 技术，按租户拆分独立子图。这彻底消除了跨租户噪声，使得召回质量与检索性能得到双重提升。
原则/方法论沉淀
在 ZillizTown 的工程实践中，我们沉淀出以下架构原则：
- 架构栈类比：模型 = CPU，Agent = OS，Skills = App。做企业级落地应专注领域知识打包，不要去碰底层 OS。
- MCP 封装原则：MCP 必须封装业务意图而非透传 API，这是降低调用复杂度、减少模型幻觉的关键。
- 记忆与搜索分工：短期常驻，长期检索；不同场景调用不同搜索形态，拒绝一套 RAG 打天下。
- 配置即人格：静态配置定底线，在线训练给弹性，Agent 的人格是三层配置的动态叠加。
总结与行动建议
企业级 Agent 的落地，绝不是套一个开源单机框架然后接上大模型就能跑通的。它需要突破物理距离的束缚，构建多 Agent 协作网络，解决群聊收敛问题，并夯实多租户隔离的记忆底座。
给你的行动建议：
- 立刻将 Agent 接入 IM，让它离业务人员足够近，这是突破物理距离性价比最高的方式；
- 审视你的 MCP 设计，如果里面全是增删改查的 API 透传，请立刻重构为业务意图封装；
- 评估多租户向量检索架构，如果你的业务面临多租户场景，尽早引入 Partition Key Isolation 替代传统大图方案。
开放问题与延伸方向
- 在 Milvus Partition Key Isolation 实现租户物理隔离的前提下，跨租户的「组织级集体记忆」如何在不破坏隔离性的情况下进行合规检索与沉淀？（关联多租户隔离与集体记忆机制）
- Agent Cron 实现的「自主定时巡检」，在 IM 高频沟通场景中，如何避免对人类员工造成信息轰炸或引发「被监控」的隐性心理压迫？（关联主动巡检机制）
- 双层消息收敛机制高度依赖 LLM 自主判断，若 LLM 产生误判导致关键业务指令被 SKIP，系统是否有低延迟的兜底或回溯机制？（关联消息收敛机制）
- Hub 作为中心路由与能力索引，在 Avatar 规模剧增时，是否会产生调度瓶颈与单点故障，其高可用方案是否违背了 A2A 对等通信的设计初衷？（关联 Hub+Connector 架构）
- 「小模型+好 Skills 优于大模型无 Skills」的论断在需要复杂多步推理与容错的开放域任务中是否依然成立，还是仅适用于流程高度确定的工具调用场景？（关联技术选型原则）
- 「MCP 封装业务意图而非透传 API」的设计，除了降低 Agent 调用复杂度，如何实质性地减少大模型的幻觉并提升业务闭环的成功率？（关联 MCP 设计原则）
- 「配置即人格」目前依赖三层静态叠加，是否存在更动态的替代路径，例如基于强化学习与环境反馈的在线人格演化机制？（关联人格定义与训练机制）
- ZillizTown 的 Hub+Connector 协作网络与多 Session 机制，能否脱离飞书等 IM 场景，迁移至物联网多设备协同调度或跨企业供应链对齐的复杂网络中？（关联架构泛化能力）
- 多 Session 机制绕过 1M 上下文限制时，跨 Session 的状态共享与上下文切换的工程开销具体表现如何，是否会引入新的延迟毛刺？（关联 Session 托管机制）
- 从 OpenClaw 到 ZillizTown，企业级 Agent 架构演进的核心瓶颈已从单点能力转向协作治理，当前架构最需优先补齐的权限管控与审计机制是什么？（关联架构演进方向）