解密Palantir系列三：6.AIP · 别再把 AIP 当成一个聊天框：四个入口，四种工作

解密Palantir系列三：6.AIP · 别再把 AIP 当成一个聊天框：四个入口，四种工作

别再把 AIP 当成一个聊天框：四个入口，四种工作

AIP Logic、Chatbot Studio、Analyst、Assist 分别服务什么工作，怎样按任务形态与交互方式选择入口

供应链团队的 Agent 上线后，其他部门很快找上门来：

• 采购主管：“我们也要一个 AIP 聊天机器人，帮忙分类供应商邮件。”
• 供应链分析师：“我要一个聊天机器人，做月度中断复盘。”
• 新入职的工程师：“我要一个聊天机器人，教我怎么在平台里建数据管道。”

三个需求都叫“聊天机器人”。如果照单全收，全部用对话应用去实现，团队会得到三个难以维护的 Chatbot：一个本该是后台函数的邮件分类器被套上了没人使用的对话界面，一个即席分析工具被写死成几十条预设问答，一个产品使用问题被重复建设成了官方文档的劣化版。

问题不在需求，而在入口。截至 2026 年 7 月，AIP 中至少有四个入口经常被“聊天机器人”这个模糊需求混在一起。Chatbot Studio、Analyst 和 Assist 都提供对话式体验，AIP Logic 则是输入—Block—输出式的函数构建环境。它们都围绕自然语言和 LLM 展开，承担的工作却完全不同。

本文不是完整的 AIP 产品目录，而是只比较四个最容易在需求阶段被混淆，AI的产品形态不停的迭代，对话/报告/编码/决策。AIP Threads、AI FDE、AIP Document Intelligence、AIP Evals 和 Model Catalog 等产品不在本篇讨论范围内。

先给结论：

AIP Logic 编排可测试的 LLM 函数，Chatbot Studio 构建面向业务用户的受控对话应用，AIP Analyst 让用户对 Ontology 做即席分析，默认的 AIP Assist 回答平台本身怎么用。选择入口先看三个问题：是不是平台使用求助，是即席分析还是复用能力，是否需要持续对话。写回风险不是分流条件，而是选定入口后仍要单独检查的治理问题。

一、为什么四个产品这么容易选错

第一个原因是能力可以组合。Logic Function 可以成为 Chatbot 的工具，Chatbot 可以发布为 Function，Analyst 可以嵌入应用，Assist 中也可以承载自定义 AIP Chatbot。产品不是四座互不相干的孤岛，但它们仍有不同的主要工作单位。

第二个原因是名字在变。AIP Chatbot Studio 原名 AIP Agent Studio，官方主文档已经采用新名称；旧文章、旧培训材料和搜索结果里两个名字仍会长期并存。读到“Agent Studio”时，它通常指的就是今天的 Chatbot Studio，不是另一个产品。

第三个原因是需求表达的习惯。业务方描述需求时说的“我要一个聊天机器人”，其实是在描述交互方式，而不是工作形态。把交互方式当成产品选型依据，就像因为都有方向盘而把卡车、叉车和卡丁车当成同一种车。

二、四种工作形态，逐个拆开

AIP Logic：构建者编排可测试的 LLM 函数

AIP Logic 是无代码的 LLM 工作流开发环境，把 Prompt、模型、Ontology 查询、工具和输出组装成函数。它的产出不是一个聊天界面，而是一个可发布、可版本化、可进入 Evals 回归的 Function，供应用、Chatbot、Automation 调用。

采购邮件自动分类就适合落在这里：它是一段后台逻辑，没有人需要和它“对话”。Logic Function 是 AIP Evals 的主要评测目标之一；Chatbot 发布为 Function 后，也可以进入回归评测。

AIP Chatbot Studio：构建者配置、业务用户使用的对话应用

Chatbot Studio 用于构建正式的企业 Chatbot：配置检索上下文、六类受控工具、引用来源和会话日志，再发布给业务用户使用，或嵌入 Workshop 应用。

它的主要定位是交付一个可复用的对话应用；必要时，Chatbot 也可以发布为 Function，进入评测、自动化、代码或外部应用工作流。也正因为它可以挂载 Action 等写回工具，第 3 篇的执行闸门在这里全部适用：一线计划员问库存、触发调拨提案的场景属于这里，而配置它的责任在构建者。

AIP Analyst：业务用户对 Ontology 的即席分析

AIP Analyst 面向技术与非技术用户的自然语言分析：搜索对象、构造对象集、聚合数据、生成可视化，并用 Graph 视图展示分析路径。它的主要工作单位是“一次分析”，而不是一套预先固化的问答流程；分析资源也可以保存、共享或嵌入其他应用。

供应链分析师的月度中断复盘属于这里。如果把这类需求固化成只会回答预设问题的 Chatbot，构建者会追不上分析问题的变化。需要注意，Analyst 不只读取数据：它也可以执行 Function 和 Action；Action 执行前需要批准，并受权限和可回退能力约束。

AIP Assist：平台自带的使用助手

AIP Assist 是贯穿 Palantir 平台的上下文助手，默认基于平台文档回答“这个平台怎么用”，组织也可以注册自定义文档补充回答范围。默认 Assist 不直接访问企业业务数据。用户也可能在 Assist 中切换到由 Chatbot Studio 发布的 AIP Chatbot；这种 Chatbot 的数据、工具和写回边界需要单独治理。

新工程师问怎么建数据管道，答案已经在这里，不需要任何开发。

四个入口放在一起比较：

三、选入口只需要回答三个问题

把上面的比较压缩成一个决策顺序：

第一问：这是关于平台本身的问题吗？是——AIP Assist，到此结束，不要立项。

第二问：用户需要的是一次分析，还是一个可复用的应用？每次问题都不同、以探索数据为目的——AIP Analyst；流程固定、要交付给一群人反复使用——继续问第三问。

第三问：这个可复用的能力需要人机对话吗？需要面向业务用户的对话界面、检索和工具——Chatbot Studio；只是一段被系统调用的逻辑——AIP Logic。

三个问题问完，开头的三个“聊天机器人”需求就落到了三个不同入口：邮件分类是 Logic 函数，中断复盘是 Analyst 分析，平台教学是 Assist 的既有能力——真正需要立项构建 Chatbot 的一个都没有。这正是产品地图的价值：它砍掉的项目和它启动的项目一样重要。（以上分流为概念示意。）

写回风险不构成第四个分流问题。Logic、Chatbot Studio 和 Analyst 都可能调用业务能力或改变对象状态；选择入口之后，仍要单独设计权限、审批、评测、观测和回退。

四、这张地图的边界

第一，这不是完整的 AIP 产品清单。本文只比较四个容易被自然语言需求混淆的入口；AIP Threads、AI FDE、AIP Document Intelligence、Evals 和 Model Catalog 等承担其他职责。

第二，产品名称和能力必须带日期。Agent Studio 已更名 Chatbot Studio，官方主文档还在持续增加和调整入口。

第三，“四种工作形态”是本文归纳，不是官方分类。官方文档按产品组织，不按工作形态组织；四个产品的能力边界也可能随版本变化，例如 Analyst 与 Chatbot Studio 在检索、Function 和 Action 能力上存在重叠。

第四，入口选择不改变治理要求。无论从哪个入口进入，权限沿用（第 3 篇）与评测观测（第 4 篇）都不会被豁免——Chatbot Studio 和 Analyst 的 Action 要过执行审计，Logic 与发布为 Function 的 Chatbot 可以进入 Evals，这与选哪个入口无关。

第五，可用性因部署而异。具体 Enrollment 能用哪些产品、哪些模型，取决于区域、合同和管理员配置，不能默认四个入口处处可用。

五、接需求时的五个检查项

五个问题过完，再决定打开哪个产品。

结语

“我要一个聊天机器人”是需求的开始，不是需求的答案。

一句话记住：界面决定它长什么样，工作形态决定它是什么；先按任务与交互方式选入口，再按业务后果设计治理。

平台内部的入口理清了，下一个问题在边界之外：当企业已有的外部 Agent——IDE 里的、自建平台上的——想接入 Ontology 的对象和 Action 时，MCP 打开的是一扇门，还是一个缺口？下一篇拆 Ontology MCP 的治理边界。

参考资料与证据说明