Druid AI联合创始人Pleșea：企业智能体互不理解的根源是本体论

一个卖家把砖描述为某种规格，另一个买家搜索的是另一种说法，两边用的词不同但指的是同一批砖——两个程序要达成交易，首先得同意砖是什么。Druid AI联合创始人Andreea Pleșea在2011年的博士论文里研究的就是这个问题：让买卖软件代理就同一批砖找到共同语言。她当时发现，难点不在于代理能不能执行动作，而在于它们对同一个词的理解根本不同——一方用同义词描述报价，另一方用特定请求表达需求。

十五年后，她认为企业正在把同一个迷宫重新搭建一遍。今天每一个ERP、每一个CRM工具都自带了内置的智能体。员工要查Salesforce里的信息，得找Salesforce的智能体；要查另一个CRM，得找另一个CRM的智能体。Pleșea指出，这让大家回到了2011年甚至更早的状态——每个系统都在，但没人知道信息从哪来，也没有一个统一的真相来源。她认为真正需要的不是更多智能体，而是一个安全、可治理的框架，把所有智能体编排在一个地方，并且能审计每个代理在做什么。

Druid AI的CEO Joe Kim给出了另一个切面。他把传统集成描述为按设计工作——你事先画好流程图，告诉系统第一步做什么、第二步做什么。而智能体做的是按意图工作——一个销售员的真正目标是签单、完成指标、拿到奖金，他可能走流程，也可能不走，但优化方向是结果本身。Kim认为智能体也会这样优化，所以它们必须从一开始就被设计为可信任、可监控的，而不是逐步映射的。

但LLM的介入并没有让这个问题消失，只是让它变得更容易处理。Kim说，早期对话平台需要把用户说的话匹配到预定义的意图上，再填槽位；LLM让理解意图这件事变得容易得多。然而他划了一条明确的线：当智能体需要往业务系统里写入数据时，这个动作必须走企业已有的确定性系统。他的理由是，你可以用LLM做推理，但提交到ERP或CRM的那一步需要日志、需要控制、需要逐段微调，不能交给模型自己搞定。

Kim进一步指出，当前行业最流行的模式是用确定性系统做路由而非编排——前端一个路由器判断这个问题走确定性工作流还是走非确定性路径。他认为这带来两个问题：第一，你无法在两条路径之上创建同时利用两者的东西，业务价值变成二选一而非兼得；第二，即使你把任务路由到新模型，如果不对那一侧的智能体施加控制，它们会因为无法被有效约束而失控。Pleșea补充说，桌面端运行的智能体让这个问题成倍放大——在企业规模上，你很难控制每个代理在做什么，也很难度量和审计它的活动。

这套论证的实际含义是：多智能体集成的瓶颈不是连接能力，而是语义对齐。LLM降低了理解意图的门槛，但业务写入仍然需要确定性通道。对正在评估各家智能体平台的读者来说，关键问题不是这个智能体能不能做某件事，而是它和另一个智能体能不能对同一件事用同一个词。

需要指出的是，Druid AI自身就是做智能体编排的公司，其论述天然倾向于将本体论编排定位为核心瓶颈。其他可能的解释——比如API标准化不足、组织流程问题、或模型能力本身的局限——在这篇文章中未被充分讨论。Pleșea和Kim的论证是一个从业者的具体判断，而非经过对照实验验证的结论。