14个AI Agent怎么协作？一个销售团队的多Agent架构实践

当你决定给每个销售配一个独立的AI Agent时，你马上就面临一个问题：这14个Agent怎么协作？

常规做法是建一个中心化的Agent调度器——一个总控分发任务、收集结果、协调冲突。听起来很合理，但中心化调度器本身就是一个单点故障——它挂了，全系统停摆。而且14个bot的权限隔离在中心化架构里会变得很复杂。

我们选了另一个方向：去中心化——14个独立bot profile共享一个文件系统和SQLite数据库，bot之间不直接通信。

Bot角色矩阵

14个bot按角色分为四类：

• 10个一线销售bot（bot2-6,8,9,11,12,14）：每人配一个企微机器人，有个人推送5时段、gate-check、明道云写入权限。每个bot有自己的wenshu key（只看自己的销售机会）、自己的客户MD、自己的sales_mapping。
• 2个管理者bot（bot1陈显, bot10赵冀楠）：看全量看板。周一07:10接收全部10人待办明细加本周排行。不做gate-check——管理者不做具体操作。
• 1个运维bot（bot7）：管cron调度、客户MD归档审计、gate-check协调。唯一能跨bot读取gateway.log的bot——但不跨bot写入明道云，保护身份安全。
• 1个运营bot（bot13王涛）：日报、周报、天气、提醒。有LLM技能跑日报生成。

共享文件系统即消息总线

这14个bot部署在同一台Linux机器的Ext4文件系统上，共享三个关键路径：

• /root/.hermes/share/memory/tasks/tasks.db——共享SQLite任务库，所有bot通过绝对路径访问。这是bot间唯一的数据交换通道——bot写待办，另一个bot读待办推送给人类。
• /root/.hermes/share/skills/——14个共享技能（gate-check, crm-memory, sales-visit等），所有bot通用。
• /root/.hermes/share/knowleadge/——知识库4个领域加INDEX.md路由。

为什么用文件系统而不是消息队列？三个原因：简单（不需要额外运维一个MQ服务）、可靠（Ext4文件系统比任何MQ都稳定）、易审计（任何人可以随时查看tasks.db知道系统当前状态，查看gateway.log知道历史对话）。对于一个10人团队的内部系统，文件系统的可靠性远高于引入额外中间件带来的复杂度。

数据权限隔离

去中心化的另一个重要考虑是权限隔离：

• wenshu key：每个bot独立持有。蔡红梅的bot2只能查蔡红梅的销售机会，陈显的bot1能看到全量。权限从API key层面就隔离了。
• 企微token：每个bot独立。企微不允许跨bot代发——不能因为bot7是运维就让bot7以蔡红梅的身份发消息。
• 明道云account_id：在sales_mapping.json中独立注册。bot7做归档审计时检查各bot，但不跨bot写入明道云——需要写入的逻辑由各bot自己的明道云审计cron在00:40-01:10错峰执行。

共享文件系统上的私有数据。每个bot的客户MD存放在自己的profile/memory/customers/下——bot2看不到bot3的客户沟通记录，除非通过tasks.db中的公开待办字段间接了解。

技能体系：共享能力与独立能力的平衡

14个共享技能放在share区，所有bot通用——gate-check、crm-memory、sales-visit、task-recall、customer-research、MEDDIC复盘、投标管理、POC对战卡等。

wenshu技能是唯一的per-bot技能——因为API key不同。路径在{bot}/skills/wenshu/scripts/SECRETS.md，共享区无wenshu（已按安全规范清理）。

技能发现顺序是：profile-local优先 → 共享目录 → 全局内置。同名冲突时系统报ambiguous name错误，需要用categorized path解决——例如sales/sales-ops-management。

这个架构的核心洞察：多Agent协作不需要微服务、消息队列、分布式调度。对于10人规模的团队，一个共享文件系统和独立profile就已经足够——简单但不简陋，可靠且易于理解和审计。