SaaS公司需要为智能体构建新的数据模型

在设计智能体策略时，SaaS公司通常面临两条常见路径：

这就剩下两个糟糕的选择：要么将复杂性转嫁给客户，要么强迫客户采用独立的智能体。

还有第三条路径。产品可以将工作的定义扩展到公司核心数据模型之外，为外部智能体提供一个可运作的空间。这需要一种新型的架构模式，以及一种全新的工作方式。

产品边界向左移动，以捕捉工作上下文，而客户则留在其偏好的环境中：

独立的工作平面

关键在于将代理所需的数据与执行工作的系统分离开来。

SaaS产品为其现有记录周围的工作创建了一个模型。例如，在CRM中，产品超越了账户、联系人、线索和机会。其数据模型扩展至包含代理所需及产生的内容。

传统SaaS模式描述了客户所处理的对象。而代理型模式还描述了围绕这些对象发生的工作。

例如，面向代理的CRM需要在其现有记录周围有一个工作平面：

每个对象都有类型、版本，并与证据相关联，且可供任何授权代理使用。这些对象共同构成了工作平面：一个用于CRM现有记录之间发生的工作的系统。

工作平面保存着客户流程的状态以及代理继续该流程所需的状态。任何授权人员或代理都能理解当前情况并接手工作。这种状态超越了生成它的上下文窗口、模型和运行时。

执行可以来自多个地方。SaaS公司可能为常见任务或在其领域专长重要的工作中提供代理。客户可能使用Claude、Codex、内部系统或某种组合。人员和专业服务也可以参与其中。

产品定义了工作的结构以及接受变更的条件。每个代理决定如何产生其贡献。由于当前状态存在于产品中，新模型可以在无需重建流程的情况下接管工作。

MCP 可展现工作计划

一旦CRM具备此模式，代理便可通过MCP发现它。代理能审视当前策略，追踪其关联关系，并查看有哪些工作可执行。当它贡献新内容时，能识别出产生结果所依据的确切状态。CRM在接受贡献前会进行验证。

这正是ThruWire的MCP接口运作方式。代理能以工件图的形式检查待办工作，查询类型化工作，理解依赖关系，认领可用任务，并发布结果。服务器会根据其模式及其与当前上游状态的关系，对每项结果进行验证。

MCP为SaaS公司提供了通往代理生态系统的开放接口。工作模型界定了代理到达时所见内容，并赋予其贡献持久的意义。

为何这对双方都有利

客户得以保留其偏好的代理，同时获得产品提供的结构。它需要构建和维护的基础设施大大减少。其代理携带的状态更少，使得跨组织的多代理及多人协作更加便捷。

客户也无需再从头教导每个代理了解流程。产品本身已掌握哪些工作存在、它们如何关联，以及何种进展算作有效。围绕一套工具维护不断增长的提示、记忆系统、工作流规则及交接逻辑的需求也随之降低。

SaaS公司则保持工作与其产品的紧密联系。它捕获客户的目标、决策、中间工作及成果。其领域专长成为指导每个参与代理的模式与规则的一部分。

SaaS公司仍可构建自有代理。这些代理提供强大的默认体验，并处理专业化工作。外部代理使用相同模式，因此客户可以切换或组合执行系统，而工作内容保持不变。

职责划分很清晰：SaaS公司负责定义并维护其领域内的工作，而客户则选择执行这些工作所需的智能体。

客户在获得智能体选择自由的同时，无需管理过多架构。SaaS公司对客户成果承担更多责任，同时保持对客户已在使用智能体的开放性。

总而言之，SaaS公司需要：

这一新的数据层正是产品战略的核心。