从1个销售到10个：Agent系统怎么从单人用扩展到团队矩阵

大部分AI Agent系统在demo阶段只跑一个bot。一个销售用、一个客户池、一套推送。跑得很顺。

然后老板说："给全团队都配上。"这时候系统开始出问题——不是因为功能不够，而是因为架构没有考虑多租户隔离。一个bot的数据和另一个bot的数据混在一起、推送时间冲突、权限无法区分、管理者看不到全局。

我们的系统从第一天就按多bot设计。下面是真实的扩展路径。

第一步：从1到3——验证架构隔离性

第一个bot跑稳之后（通常需要2-3周调优），扩展到3个bot。这一步的目的不是"覆盖更多人"，而是验证架构的隔离性是否真正成立。

验证清单：

• bot2的wenshu key是否真的看不到bot1的销售机会？
• bot2的企微推送是否真的不会发到bot1的群里？
• tasks.db的待办是否按bot正确隔离（bot2只看到自己的待办）？
• 管理者bot是否能同时看到bot1和bot2的数据？
• gate-check的LLM调用是否因为并发而触发429？

3个bot暴露的问题通常是：错峰间隔不够（需要从1分钟调到3分钟）、tasks.db查询没有按bot_id过滤（导致销售看到别人的待办）、企微webhook配置错误（token配反了）。这些问题在1个bot时发现不了。

第二步：从3到6——管理者看板上线

3个bot跑稳后，扩展到6个bot，同时上线管理者看板。

为什么不在3个bot时就上管理者看板？因为3个bot的数据量不足以验证看板的分层逻辑。6个bot的数据量更接近真实场景——管理者需要同时看6个人的Pipeline、MEDDIC评分、待办完成率。

管理者看板分三层：

• 个人看板：每个销售看自己的客户、待办、Gate进度。这一层每个bot独立，互不可见。
• 团队看板：管理者看全团队的Pipeline总览、MEDDIC评分排行、待办完成率。数据来自tasks.db的聚合查询。
• 运营看板：看系统健康度——82个cron任务的成功率、LLM API调用量、企微消息送达率。这一层只有运维bot有权限。

6个bot阶段的常见挑战是：管理者看板加载慢（因为要聚合6个bot的数据）、MEDDIC评分标准不一致（不同bot对同一标准的理解有偏差）。前者通过给tasks.db加索引解决，后者通过统一gate-check的prompt模板解决。

第三步：从6到10——接近单机上限

6个bot跑稳后，扩展到10个bot。这一步的挑战主要是资源压力。

10个bot意味着：50个推送cron（每人5时段）、10个gate-check、10个明道云审计、8个管理者报告、4个运维监控——共82个定时任务。LLM API的并发调用从6路增加到10路，企微消息发送频率接近限流阈值。

三个关键调整：

第一，错峰间隔从3分钟调到3分钟不变，但增加了退避重试——如果某次LLM调用返回429，等待60秒后重试，最多重试3次。这保证了即使API偶尔抖动，gate-check不会漏跑。

第二，tasks.db增加了WAL模式——10个bot同时读写SQLite时，默认的journal模式会出现锁竞争。WAL（Write-Ahead Logging）模式允许并发读写，大幅减少"database is locked"错误。

第三，管理者看板改为异步生成——不再在管理者打开看板时实时查询，而是每天07:00预生成快照。管理者打开看板时读快照文件，秒开。

新增一个销售只需要5步

当团队有新人加入时，扩展一个新bot的过程是：

1. 创建bot profile目录：复制模板目录，修改bot编号和名称。目录结构包含memory/customers/、memory/daily/、scripts/三个子目录。
2. 配置企微机器人token：在企微管理后台创建新的机器人，拿到webhook URL和token，写入bot的配置文件。
3. 写入wenshu API key：在明道云后台为新销售创建独立的API key，写入bot的环境变量。key的权限只绑定该销售自己的数据。
4. 在sales_mapping.json注册映射：把bot编号、销售姓名、企微user_id、wenshu account_id关联起来。这是系统知道"bot8=张三=企微user_xxx=wenshu_account_yyy"的关键配置。
5. 创建5个时段的推送cron：复制已有bot的cron模板，修改bot编号和目标群ID。5个crontab条目，每个一行。

整个过程约30分钟，不改任何已有代码。新增的bot和已有的bot共享同一套skills、同一个tasks.db、同一套gate-check逻辑——唯一不同的是配置文件里的bot编号和对应的API key。

什么时候该从单机迁移

当前架构跑在一台Linux服务器上，10个bot是单机的合理上限。当以下三个信号出现时，需要考虑迁移：

信号一：WeCom限流成为瓶颈。企微的消息限流约20条/分钟/机器人。10个销售加4分钟推送间隔已接近上限。如果团队扩展到15人以上，推送需要排队，用户体验下降。

信号二：LLM API成本和延迟不可接受。10个bot每天的gate-check需要10次LLM调用，如果扩展到30个bot就是30次。单机串行执行需要90分钟（3分钟×30），可能挤占白天的正常使用时间。

信号三：需要跨地域部署。如果北京和上海各有一个销售团队，单机部署的延迟和可靠性都不理想。

迁移路径是清晰的：tasks.db换成PostgreSQL（支持并发读写和远程访问），文件系统换成对象存储（如S3），cron调度从系统crontab迁移到任务队列（如Celery或Bull）。但在到达这些瓶颈之前，不要提前迁移——单机架构的简单性是10人团队最宝贵的资产。

矩阵不是目的，覆盖才是

从1个bot到10个bot，扩展的不是技术复杂度，而是管理覆盖度。1个bot时管理者靠人盯；3个bot时管理者靠经验判断哪些单子有问题；10个bot时管理者靠系统推送——每天早上系统已经把全团队的健康度、风险项、待办完成率整理好了。

扩展的终极目标不是"让更多人用上AI"，而是让管理者从"救火式管理"变成"预防式管理"——在问题变成丢单之前就看到信号，在销售遗漏关键步骤之前就收到提醒。