当你的“AI数字员工”开始各说各话：一个架构真相与修复实录

想象一下这个场景：你花了半年时间，精心打造了一支由27个数字员工组成的“超级团队”——有的负责采购，有的管理库存，有的分析报表。你对外宣称“12大核心员工”，对内实际跑了27个，听起来很厉害对不对？

但问题来了：这些员工，各有各的“方言”。有的直接找老板汇报（直连数据库），有的绕过程序员（跳过规则引擎），还有的甚至不知道公司有统一的通讯系统（LLM调度器）。更可怕的是，当你想统计一下“今天哪个员工干了什么活”时，发现系统里居然有两套独立的数据库，数据对不上。

这不是科幻电影，这是今天很多企业在落地AI Agent（智能体）时，真实遇到的“架构分裂”困境。我们最近对BossAgents（左帮右臂）智能体平台进行了一次彻底的“代码级体检”——不是靠PPT推断，而是逐行grep源码、实锤验证。结果发现了一些有趣又扎心的事实，以及一条清晰到可怕的修复路径。

一、我们发现了什么？7个“必须面对”的架构真相

1. 数字员工的数量：对外12个，对内27个，中间差了15个

计划书里写的是“12大数字员工”，听起来很聚焦、很好记。但打开配置文件一看，实际注册了30个ID（包含3个LLM平台占位符），真正在跑的正式业务员工有27个。其中只有3个被标记为“禁用”，其余24个都在默默运行。

这本身不是问题——产品迭代中，内部版本比对外宣传多，很正常。但问题在于：这27个员工，有12种完全不同的实现方式。有的走标准流程（CapabilityRuntime），有的自己写死逻辑，还有的直接绕过所有中间层，裸连数据库。这意味着，你没法用一个统一的“员工手册”去管理它们。

2. LLM调度：一个“不存在”的系统，其实已经写好了

我们之前一度认为“SmartLLMRouter”（智能LLM路由器）这个模块不存在——因为它没有被主流程调用。但深入代码后发现，这个模块不仅存在，而且足足有1043行代码，包含了从MTCLAW到Ollama到DeepSeek再到规则引擎的多级降级链路。

它就像一个已经建好的中央调度台，但所有员工还在用对讲机各自呼叫老板。 主流程里散落着9处直接调用LLM的地方，还有更多藏在各个模块里。SmartLLMRouter有了，没人用。

3. 创建流程：前端和后端，联手绕过了规则引擎

这是最让人揪心的发现。当用户在界面上点击“创建”某个对象时，前端代码直接调用了底层API，跳过了规则引擎；后端同样如此，直接操作数据库。规则引擎就像一个被架空的“质检员”——它被部署了，但所有产品都从它身边绕过去了。

更关键的是，规则引擎本来应该记录每一次操作，生成审计日志。现在好了，创建流程完全不可审计——你没法回答“这个订单是谁创建的？经过了哪些规则校验？”

4. “五维”这个词，在代码和计划书里是两码事

计划书里说的“五维”，指的是“五维对象交易市场”——数据、模型、规则、技能、工作流。但代码里搜索“五维”，跳出来的全是“五维健康评分”——完整性、准确性、时效性、可用性、安全性。

同一个词，两个意思。投资人做尽职调查时，随便问一句“你们的五维是什么”，就会陷入混乱。

5. 19个Worker，只有7个走标准化流程

Worker是数字员工的具体执行单元。我们检查了19个Worker的调用路径，发现只有7个走了标准化的CapabilityRuntime（能力运行时），其余12个各有各的实现方式。有的自己写文件（auto-loop-worker），有的自己写业务逻辑（content、data-caretaker等），还有的直接操作数据库。

计划书里写的“无需前端开发工程师、复制即部署”，在工程上变成了“12种实现风格、12个维护成本”。

6. 两套数据库，一个系统

代码仓库里有两个SQLite数据库：data/bossagents.db（1.7MB，89张表）和server/data/bossagents.db（20KB，2张表）。两套库并存，行为不一致的风险极高。你可能会问：为什么会有两套？答案很简单：开发过程中，不同的功能模块各自建了自己的存储，没人统一。

7. 自进化系统：一个漂亮的设计，但从未上线

规则自进化模块（rule-evolution.js）确实存在，写得也很漂亮。但它只被一个旁路cron定时任务触发，从未接入到规则引擎的执行后钩子。这意味着，系统永远不会根据用户的实际操作来优化规则。计划书里说的“越用越准”，目前只能停留在设计文档里。

二、解决方案：一条唯一主链

发现问题是好事，因为问题越具体，解决方案就越清晰。我们给出的方案只有一个核心思想：把所有数字员工统一到一条主链上。

这条主链长这样：

用户操作 → SmartLLMRouter（唯一LLM入口）→ CapabilityRuntime（规则引擎优先）→ 六能力（识别/创建/修复/优化/比对/生成）→ 统一SCSAI适配层 → 可审计结果 

这个方案听起来很简单，但要做到，需要三步走：

第一步：立即止血（P0级，今天就能动手）

1. 1. 让创建流程回到规则引擎

：前端代码从直接调底层API，改为调规则引擎接口；后端同样。保留一个“bypass=rule”逃生阀，但默认走规则引擎。验收标准：每一次创建操作，都在规则命中表里留下记录。

1. 2. 让所有LLM调用走同一个入口

：在系统启动时，建立一个全局的SmartLLMRouter实例。然后把所有散落的new LLMBrain()调用，全部替换成global.__smartLLMRouter.call()。验收标准：所有LLM调用都经过统一的度量出口。

1. 3. 给“五维”正名

：代码里保持“五维健康评分”的命名；计划书里将“五维对象交易市场”改为“六类对象交易市场”（数据、模型、规则、技能、工作流、数字员工）。避免尽调时的命名冲突。

第二步：系统内核化（P1级，下一个版本）

1. 4. 让所有Worker强制走CapabilityRuntime

：把12个未接入的Worker逐个改造，保留Worker作为“参数配置器+能力编排器”的角色，但禁止它们直接操作LLM或数据库。

1. 5. 合并双库

：统一使用data/bossagents.db，删除另一套库的所有引用。配置项DB_PATH成为唯一的真相源。

1. 6. 清理历史遗留

：把旧的入口文件标记为“已弃用”，所有路由指向新的调度器。一个版本后彻底删除。

1. 7. 处理“空插座”

：要么把配置里注册但未实现的功能真正实现（复用现有模块即可），要么从配置中删除，避免“配置幻觉”。

1. 8. 让自进化真正跑起来

：把自进化模块接入能力运行时执行后钩子。每次能力执行后，更新命中次数、采集用户修正行为，生成候选规则。

第三步：规模化（P2级，长期规划）

1. 9. 补齐测试

：为核心主链（创建、识别、路由）添加集成测试。

1. 10. 实现多租户隔离

：在调度上下文中注入租户ID，确保数据隔离。

1. 11. 产品层收敛

：配置文件分不同profile（轻量版、企业版），主叙事只聚焦12个标准技能。

三、为什么这很重要？

你可能觉得，这些都是技术细节，跟业务有什么关系？

关系太大了。当你的数字员工开始“各说各话”时，你失去的不仅是技术上的可控性，更是业务上的可审计性、可优化性和可复制性。

想象一下：

• 你的合规官问：“这个采购订单是谁创建的？经过了哪些审批？”——你回答不出来，因为创建流程绕过了规则引擎。 - 你的产品经理问：“我们的系统真的越用越准吗？”——你只能说“理论上是的”，因为自进化从未上线。 - 你的投资人问：“你们到底有多少个数字员工？12个还是27个？”——你陷入两难。

架构的混乱，最终会变成业务的混乱。

四、BossAgents（左帮右臂）能做什么？

我们不是来卖一个“完美无缺”的产品的。我们做的是：直面问题，然后给出可执行的修复路径。

这次“代码级体检”暴露的问题，恰恰证明了BossAgents平台的透明度和可修复性。我们不是那种“PPT上很完美、代码里很混乱”的公司。我们愿意把源码摊开来，逐行检查，找到所有“理想与现实之间的裂缝”，然后用工程化的方式一条条填补。

如果你正在考虑引入AI数字员工，或者你已经有了但发现它们“各说各话”，我们可以帮你做三件事：

1. 1. 架构体检

：像这次一样，逐行审查你的AI Agent系统的源码，找到所有“已实现但未接入”的模块和“已规划但未落地”的功能。

1. 2. 主链收敛

：帮你把所有散落的调用路径，统一到一条可审计、可优化、可扩展的主链上。

1. 3. 工程闭环

：从“PPT上的12个员工”到“代码里的27个员工”，帮你建立从产品定义到工程实现的完整映射，确保对外宣传和对内实现的一致性。

好的架构，不是没有裂缝。而是你知道裂缝在哪里，并且有勇气和工具去修复它们。

这就是BossAgents（左帮右臂）在做的事情。我们不承诺“完美”，我们承诺“可修复”。而在这个AI Agent快速落地的时代，“可修复”比“完美”更重要。