前言：在不确定的商业技术价值下的做决策

从22年末 Langchain 框架与Agent 概念的兴起，至今也将近有2年的时间了。但是真正在商业和技术上跑通价值闭环的产品方向上少之又少，有的也只是局限在某些领域的特定场景；

但我依然觉得 Agent 平台将会是未来AI应用落地中最核心的部分，即使大部分场景下的技术路径和商业模式尚处于探索阶段，而规模化的商业成功却往往源于不确定的技术与商业环境之下。

可随之而来的问题是：在不确定的技术与商业环境下，如何做决策？即：我应该做什么才能一个商业型组织如何更大概率的接近规模化的成功？这里谈谈我的思考。

首先，成本的控制最核心的关键。因为当技术和商业不确定的时候，一个初创的产品在思考的初期就穷尽所有维度，预测产品、技术走向，乃至商业与用户模型，是一件几乎不可能的事；即使方向预测对了，那爆发的时间点位和时间线也没人能够准确预测。

为了让自己不会倒在黎明前，最重要的是能够让你的试错成本要足够低，低到你在做一个产品中所获得认知远大于产品失败带来的损失。

紧接着再提一个非共识，但是我觉得是重要的一个隐形的低成本模式，其实是认知成本的复用；通俗来说就是尽可能做自己领域已经成功，甚至失败经验的产品，这些产品带来的认知能够帮助你收敛新产品中不确定性的维度，同时你的认知可以被复用。

写到这里我想起 Albert老师在《42章经》播客中说的一句话：“找PMF就是要做没壁垒的事” ；对此我表示赞同，因为产品本身并不应该是最大的壁垒，因为没人做过的事大概率是跑不通的。

我觉得最大的壁垒并不是产品本身，认知才是。

其次，我的第2个观点是：如果没有发现成熟的应用场景和技术；那就下探一层，尽可能抽象一个维度，找到不变的业务路径与框架。

这也就是我为什么要做 Agent 平台的原因，如果将 AI 简单分为三层：即应用层、平台层与模型层；模型层是我们当前组织所不具备的组织能力（这个后面聊业务背景的时候还会再说到），因此在应用层不太明朗的情况下，下探一层做Agent平台则是一个相对较优的解法。

因为从 Agent 框架上看，规划（Plan）、工具（tool）、执行（action）、记忆（memory）的架构会在很长一段时间不会有大的变化，只是随着技术的革新，模型的推理、记忆等能力会变得更强，产品也会更有应用价值。

此外，用户将会在Agent平台上创造更多可能的场景和应用效果。如果假定技术奇点未知的情况下将应用的创造更低成本、低门槛的开放给用户，会让平台型产品更加平滑的接近奇点，更早一步获得技术带来的红利。

规划阶段：选择更适合产品的细分定位

先介绍一下公司的背景情况：

核心领域：一家头部的 CRM SaaS厂商，服务于中大型企业。

业务现状：拥有大量中大型企业资源，移动端 SaaS 日活接近百万。

产品范围：产品线较广，营销、销售、服务均涉猎。

组织形态：产研组织分工细致，自上而下分为 行业侧、领域侧（SaaS）、平台侧

针对以上的业务及组织形态，分享在Agent建设初期选取产品定位的思路。

最早打算做 Agent 平台的想法其实很明确，类比一下我所在的PaaS平台：

PaaS平台的定位就是为业务层提供可定制的产品能力，而从宏观的业务上看，由于本土化SaaS的特色：企业定制多、产品线铺的范围较广；就意味着行业之间，领域之间的业务场景差异较大，需要通过 PaaS 能力；如基础的表单引擎（对象）、流程引擎、权限；低成本驱动上层业务定制。

但仔细一想，又发现很多问题待探讨：

1. 是否一定要做 Agent 平台，PaaS平台研发的本身就意味着高成本，成本是否划算？

2. 当时大量的开源产品（类似Dify、FastGPT、Bisheng）已经出现，是否要重复建设一个新的产品，以及用户为什么要使用你的产品？

关于Agent平台设计的初衷

目前在业内形成共识的是，Agent 在CRM的3个核心垂直领域（营销Marketing、销售Sales、服务Service）已经被证明是有价值的产品方向。可以通过 Agent 的推理与执行能力，简化SaaS的操作步骤，处理复杂业务流程。只是部分场景当前的模型能力还不够。

那么抽象出一个业务维度，所有智能体的规划和执行能力都基本可以归结为CRM的业务系统操作能力，而业务系统操作的背后是PaaS的编排能力。

而从PaaS平台本身的角度看，我们的PaaS平台已经天然具备了基础的业务能力。因此在自研 Agent 平台上，如果我们的大部分调用能力来自CRM自身的场域闭环，那么很多的基础业务能力（流程引擎能力、基础业务对象查询、更新API）甚至低代码能力（自定义函数）都可被复用；只是引入了一个新的PaaS子模块，从成本上看一定是相对可控的。

另外容易被忽略的点是 组织能力模型的问题，建设的初期由于面对的是一个陌生的领域，一个为上一代产品建设的组织体系下，并不一定能够快速适应甚至配比到相应的人才，因此从向内看：产品架构的设计也会高度依赖于组织设计，这一切的目的是希望建立一个高效响应市场业务的组织体系。

而建立这样的组织体系最快速的方法不是去让大家去恶补知识，而是将组织能力做分层，在复杂组织下各司其职；让少数具备 AI 能力产研团队专注平台，用平台能力驱动业务场景建设。

具体的逻辑是，将 AI 的建设分为业务层与平台层。上层业务调用基础 AI 基础业务能力（Agent框架、基础模型切换、函数调用等）；这样上层业务团队只需要对AI有基础了解，并专注于AI场景的挖掘，并与平台共建产品。

那么，用户为什么使用使用你的产品而不是那些开源产品？对此我将行业内的Agent产品大体分为几类：

如果以坐标轴的形式来看，目前大体可按照2个维度，分别是ToC——ToB、开源——闭源；我认为垂直行业领域 Agent 是存在行业机会的，原因有几个：

首先我认为通过上一代的传统互联网沉淀下来的企业用户能够作为我们的第一批种子用户，帮助我们的产品一起找到企业应用落地的价值点。这会是我们的一个小的差异化壁垒。而这些用户的规模足够大，这些企业用户的信息已经大量地沉淀在我们的系统中，如果要接入开源系统，需要有大量的迁移成本。

此外第2个假设是：用户如果希望更便捷的使用 AI Agent 能力，大概率希望配置的能力能够在系统内闭环，而不是需要大量的对接外部接口来实现工具调用能力；

自建的 Agent 可以让用户仅靠点选对象表单信息（Object，例如客户、商机）、自动化Flow就可以快速实现复杂业务的建设，这样无论是编写业务逻辑的工作量，还是 Agent 配置工作量上，都可以大大降低。

所以我们最后决定更倾向于自建垂类 Agent 平台。

Agent平台架构设计的过程

Agent平台首个版本的设计方法：以垂直场景单点突破

我们在做 Agent平台V1.0时，遇到的问题其实和大家类似：如何找到最佳的AI落地场景。当时 Coze 海外版还没有推出，市面上也没有太多成熟的落地场景，因此当时寻找场景的逻辑是：向内看；结合CRM业务场景找到能够快速赋能的细分领域，客服场景就是我们最初想要落地的方向。

由于本期内容仅描述具体选取的场景，不会选取场景的方法论；如果大家对此内容感兴趣，可以先看我之前的《AI产品的落地总结与思考》。

那么在客服场景下，应用到 Agent 的首个方向是基于工单查询、变更能力。大致场景如下：

客服人员会在线与用户进行对话，解答用户的使用问题，如果发现系统或设备有问题，会自动提取客服与用户的对话，并结合AI提炼会话中的关键信息（如故障的位置以及待预约的时间），并辅助客服人员创建并将提炼的信息填入工单，基于工单反馈模块推送工程师进行咨询维修。

这个场景中的核心效率提升点在于，客服人员与用户在沟通过程中，AI 可以直接通过理解上下文语义自动帮助用户进行日常的工单操作（如维修工单提交），如下图所示：

左侧是客服工作区，客服人员可以通过左侧的文本编辑区与用户进行交互；而右侧是客服人员的 Copilot 界面，如果当用户提到某个设备产生了问题故障，且客服人员提到了预约处理时，AI助手能够识别左侧工作区的会话信息自动帮助用户创建，并结合上下文信息将工单所需的字段值映射进去；

相应的，如果我们把【工单】看做其中的一个对象实体，那么除【工单】外，【销售订单】【服务记录】等都可以作为系统内标准的操作API 封装到具体的工具中进行调用，并且能够定义每个工具/行动（Action）的入参和出参；而 AI 则作为“大脑”，承担意图分类器（Classify）和规划器（Plan）的作用。

所以从工单这一垂直场景，我们可以梳理出一次Agent调用流程：

从触发的逻辑上，体验最好的效果是：AI可以不间断监听Session某几行会话并实时触发操作询问弹窗；但实测下来无论是调用成本的控制上，效果其实远远未达预期。所以我们采用了PlanB，让用户根据业务实际进行主动唤起AI操作；这里最好的方式是通过Copilot【常用按钮区】进行快捷操作，同时也支持用户通过和AI助手对话，自动识别上下文信息来完成。

另外在控制模型输出的幻觉问题上，也是我们比较头疼的点。我们这里采用的2个主要的方式解决可控性缺陷：

1. 首先是在调用 Fuction call 接口失败的场景下，采用了兜底知识库的逻辑，这样确保系统在未获取外部工具的情况下，能够将自己的回答范围内，这样尽管感觉回答的内容不那么准确，但生成的内容会更符合规范。

2. 其次为了确保输出内容准确性和安全性，我们在最开始并没有采用最激进的Auto-Pilot 产品策略，所有AI生成的内容全部仅对客服人员开放，并提供了确认的流程，确保整个内容不会出现比较大的风险。

根据垂直场景的分析，我们设计输出了初版 Agent 平台架构，总体分为了通道层、Agent应用构建层、引擎层、模型层、基础PaaS业务层；由于内容篇幅关系，就不在这里详细展开，等最后的架构说明中再展开描述。

反思与回顾：以单点垂直场景切入的局限

上文中提到了我们在初版架构设计的一些思考过程中，里面也埋下了一些伏笔，读者朋友有兴趣可以对照前文一起看。

首先，我们初期过于追求单点垂直场景的效果，导致整个系统的泛化效果欠佳；且整个架构的灵活性不足，以表单数据创建为例：

如果是在客服工作台中，客服人员手动激活AI创建工单流程；实际上是由2个具体的工具API完成；

1. 从外部通道（即客户与客服人员的对话窗口）拉取会话上下文并进行AI摘要提炼，而这里的【上下文】非当前AI窗口本身的上下文；

2. 将其作为【AI摘要的内容】变量作为【对象创建】工具调用创建API。

而大家可以发现，步骤1的操作是基于上下文摘要的标准化能力；而步骤2的对象创建工具是标准的API通用能力，仅需要做一些标准的能力（如表单类型，变量）配置即可。

为了确保需求的输出效果，我们将2步封装在了1个工具执行中；最后效果上确实也可以满足；但是整个系统不能支持泛化场景，比如不能够支持其他外部通用场景，且每次调用也只能调用一次工具，不支持通过Agent工具间串行调用，架构的可复用性和灵活性都不够好。

此外，由于具体到了某个垂直场景，而此场景中未涉及到的更多高频场景，如：多轮对话补全信息，信息确认等交互形态没有在首个版本引入；导致高频场景未被满足。

回顾首个版本的Agent平台设计，我认为通过单点垂直场景设计的思路存在一定的局限性，因为这类方式虽然可以帮助我们更好地优化某个case的效果，但是我们忽略了对开放性的、长尾的交互场景case的把握；而我认为这却是 AI应用最值得被建设的部分。

而当一个业务较为复杂，涉及多场景时，为了兼顾开放性和输出的确定性，就必然要在整个领域模型设计中厘清封闭性与开放性的部分，并将可复用性的部分抽离出来，尽早通过流程解决 ＜20% 的高频封闭性问题；

而开放性的问题要尽可能通过大量的case中分析得出；并通过大模型、Agent prompt人设描述来解决 ≥80% 的简单的任务编排、长尾的多轮对话、任务编排等开放性问题。

Agent平台演进后的架构思路

针对 V1.0 版本中遇到的问题，以及参考了市面上的一些行业上的优秀竞品后，整个Agent平台架构也逐渐变得清晰，下图是脱敏后的一个产品架构图，结合这张图也聊聊我对架构的一些思考；以及我对Agent平台未来趋势的判断：