下面是一些典型客户服务的例子以及人工解决流程：
产品库存查询
查询：“我想查询一下是否有6号钳子是否在本地的门店有售，以及它的价格？”
数据：库存、产品目录、定价、区域门店、促销、补货时间和需求。
流程：识别产品和门店，检查该门店的产品库存，并参考任何相关促销或优惠的定价信息。
发票查询
查询：“您好，请提供过去6个月内所有与木材采购相关的发票。我认为我被多收费用了。”
数据：发票信息、订单历史、定价数据和历史定价数据、账户信息及信用/借记信息。
流程：检索客户的账户记录和订单历史，分析相关发票并比较与木材采购相关的费用，确定是否存在多收情况，如有必要则发起退款。
订单跟踪
查询：“您好，请问我的订单预计什么时候到达？”
数据：订单信息、账户/客户信息和跟踪信息（第三方）。
流程：检索客户的账户信息和订单信息以识别相关订单，检查订单的当前状态并确认是否在配送途中，交叉核对与第三方配送公司的跟踪号码来了解订单状态。基于与第三方供应商的历史记录，使用模型预测预计的送达时间，并提供此预估；若配送发生问题，则识别根本原因。
以上例子显示了构建客户服务解决方案所需的基础要素：数据、逻辑/流程、和 操作(action)。
现在，我们的目标是构架AI客服。自动化大部分流程，大幅度提高客户服务的效率。我们采用，模块化的多智能体系统构架( multi-agent )。多智能体AI系统才可以在实际业务运营中解决规模和速度方面的挑战。
规模挑战：因为需要处理各种情况，会导致输入给单智能体的提示词太长。多智能体系统通过将任务分配给各专门智能体来应对这一问题，每个智能体负责交互的特定方面，而不受单一上下文窗口的制约。
速度挑战：单智能体查询的平均响应时间约为三分钟，因为复杂的查询增加了平均响应时间。借助多智能体架构 ，智能体可以专门处理不同的查询类型和解决组件，从而显著缩短解决时间。
可扩展性：多智能体系统天然具有可扩展性；可以在无需大量重新配置的情况下加入新智能体。
任务分解：复杂任务可以被分解为更小、易管理的部分，由不同智能体分别处理。这种模块化方法不仅简化了任务管理，还通过并行处理提高了系统的整体性能。
标准化的agent通信协议：采用标准化通信协议确保智能体之间信息交换的高效性，减少误解。
错误处理：多智能体架构允许集成复杂的错误检测和恢复机制，确保即使单个智能体出现问题，系统整体仍能保持正常运行。
调试问题：在传统大语言模型架构中，由于响应生成过程缺乏透明度，调试过程较为复杂。相比之下，多智能体系统通过模块化设计和清晰的智能体通信协议，提升了监控和调试能力。该结构有助于故障的快速识别与有效恢复，从而提高系统的可靠性。
因而，在本例子中，我们创建了一种多智能体分层架构，涵盖管理、执行和支持角色。这种方法使我们能够适应不同类型的查询并有效应对前述挑战。
分类智能体 Categorization Agent：自动对客户的查询进行分类。
响应智能体 Response Agents:：专门处理特定类型的查询，例如，定价或发票信息。
操作建议智能体 Action Suggestion Agent：生成正确的解决操作顺序并自动回复。
集成智能体 Integration Agent:：将多个响应整合为连贯的客户沟通。
模态转换器：将回复内容转换为客户偏好的沟通形式。
每个Agent是独立的，与其他Agent隔离。
三、 Data
从SAP（管理数据）、Salesforce（销售订单数据）、UPS（快递数据）和各种ERP系统中整合数据，构建“数据对象”。这些对象代表了诸如客户、订单、产品、查询等概念。其次，确定这些实体之间的关系（例如，“产品”由多个“部件”组成；“维修计划”适用于特定“设备”）。指定关系的属性，包括类型（层级、关联）、基数（一对一、一对多）。
以上是把data集成到Palantir的“本体”平台。
3.1 Agent的数据环境
每个Agent是为特定目的而构建，只能访问本体（Ontology）的特定数据和权限。
企业数据是私有的，基于权限的，并且具有深刻的上下文依赖性。所以，Agent不仅需要理解内容，还要理解组织结构、用户角色和访问权限。系统需要理解用户身份，并只返回他们有权限访问的信息。这就是“本体”的治理层，这一层负责理解跨越上百个不同系统的权限规则。系统还需要理解提问者是谁。比如，新员工可能会询问「入职指南」，但究竟该返回哪一份入职指南？这取决于员工是在市场部还是工程部。因此，理解员工、知识以及它们之间的关系。 正是因为PLTR在“本体”层积累了十年的时间，所以在此处相对于其他对手拥有竞争优势。
在具体实现上， 每个Agent有 “记忆模块”。短期记忆（STM）在AI智能体中相当于一个临时工作区，短时间内存储信息以便进行即时处理和决策。它类似于智能体在回答单个问题或处理某一任务时的“思路”。这种记忆是易失性的，通常在任务完成后清除，以便智能体在下一次交互时不被无关数据所累。长期记忆（LTM）存储着过去交互中可能在较长时间内仍然相关的信息，例如对话历史、用户偏好或学习到的知识。该记忆在不同会话之间保持，从而帮助智能体建立更具个性化和信息量的用户关系。
四、 逻辑/流程
将企业所有的决策流程、操作逻辑集成到Palantir的本体 (这件事也是公司做了十年的事情，核心竞争力之一)。例如，
与客户交互相关的业务逻辑（通常存在于 CRM 和 ERP 系统中）。例如，通过解析标准操作流程（SOPs）文档来理解复杂客户支持请求的解决流程。例如，PLC逻辑、工程图纸和焊接程序规范。例如，理解客户特定的采购订单（POs）来接入供应商业务流程。
传统机器学习的建模逻辑（分布在数据科学SaaS 系统）。例如，预测机器故障的概率的模型；
以及与特定领域工具紧密结合的规划、优化和仿真算法。
然后，本体对企业所有绑定之后的“逻辑”范式提供了一致的接口，这些工作流能够无缝整合并组合不同来源的逻辑资产，并且可以构建新的工作流。
4.1 Agent的流程/逻辑工具
例如，之前的产品库存查询
查询：“我想查询一下是否有6号钳子是否在本地的门店有售，以及它的价格？”
数据：库存、产品目录、定价、区域门店、促销、补货时间和需求。
流程：识别产品和门店，→ 检查该门店的产品库存 → 定价 → 促销价格。这些流程存在企业SAP系统中，客服人员操作流程手册里面。现在都集成到Palantir的本体。
下面我们再把LLM接入Agent。
4.2 大语言模型接入Agent
为每个智能体和任务选择最适合的大语言模型。Claude 3在文本和内容生成方面表现出色，能够生成更人性化且简洁的邮件建议。而在处理多模态数据方面，GPT-4 Turbo表现尤佳。每个“逻辑模块”可以使用不同的大语言模型，这使我们能够创建在执行过程中调用多个大语言模型的智能体。
例如， 客户查询：“您好，请问我的订单预计什么时候到达？” AI客服系统将做以下的事情：
分类Agent：将这个查询派发给“订单Agent”
订单Agent：查询客户账户信息、确定订单号（如3.1节所示，本体”给Agent配置了相应权限的“data” ）
订单Agent：调用快递公司API跟踪订单状态。
订单Agent：调用机器学习ETA模型，估算送达时间，并将其传递给Action Agent。（如4.1节所示，本体”给Agent配置了相应权限的企业流程和逻辑工具）
Action Agent：调用LLM撰写邮件，回复客户。
将上述Action Agent推荐的操作，经过人类确认后，写入更新本体中相关订单对象以及ERP系统中对应的记录，并通知末端配送合作伙伴更新其交货安排。
例如，下图的“Suggested Actions” 就是Action Agent给出的建议。
在Action Agent给出了各种建议之后，在此处人类客服专员可以编辑并批准智能体建议的行动。所有的修改，都会被记录下来。
为了有效地在大规模下利用反馈，Palantir采用了以下方法：
使用特定领域（产品/客户细分/供应商）的反馈总结自动生成自定义提示词。
利用大语言模型对特定领域的所有反馈进行总结。
这些反馈总结每周更新并复合，以更偏向较新的输入，因为操作员使用系统会产生更多反馈。所有反馈均可编辑，且可删除/更改。
Palntir使用“本体”来创建一个反馈对象，将本次知识存入平台中的“知识库”。该反馈存储在AIP的向量库中，以便智能体通过RAG（检索增强生成）技术检索使用。
提示词工程在大规模时效果会下降，因为单一提示词无法应对数百万输入的所有情况。然而，给予智能体上下文相关且已总结的反馈，允许其自我修正，可以解决这一问题。
例如，反馈界面如下。
任何企业，只要想使用AI （LLM，或者Agent）系统，都需要一个类似“本体”的系统。
提供符合情境的、安全的 Data环境；
提供符合场景的，流程；
把企业所有软件系统接入，才能把执行结果写入；
换句话说，Palantir “本体”是企业的“数字孪生”。有了它，AI才可以在数字世界里发挥无限的作用。本体是AI和企业结合过程中一定要有的一层。即使做一个简单的企业内部知识搜索，都需要某种形式的本体。这也是PLTR为什么这么贵的原因。
Palantir的领先优势，就是“数字孪生”这件事情非常难做（复杂），而且前期无法盈利。
