Palantir 哪些功能已经被标注为 Sunset（退场）和当前主推的功能是什么？

一、已明确标注为 Sunset 的功能

Palantir 当前的核心战略高度聚焦：以 Ontology 统一语义，用 Pipeline Builder 管控数据，让 AIP Agent 直接介入决策与执行。这一方向在产品功能迭代上体现得尤为直接。查阅 Foundry 文档，你会发现多个应用已被标记为 [Sunset]。这并非意味着它们会立即停用，而是官方已明确：这些功能不再是未来的发展重点。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

目前被划入 Sunset 阶段的功能，主要集中于以下几类：

1. Preparation
这是初代的数据清洗与预处理 UI 工具。当前立场非常明确：不再推荐使用。所有数据准备工作，正被统一整合到 Pipeline Builder 这条主线上。

2. Forms
用于构建交互式表单的工具，早期在业务录入、审批等场景中应用广泛。但随着“Ontology + Actions / Functions”这套组合能力的成熟，Forms 已非首选方案。

3. Recipes
一套侧重于“规则+触发+通知”的工具集。如今，其核心能力已被拆解并融入 Automations、Foundry Rules 及监控视图中，Recipes 本身不再进行功能更新。

4. Reports
旧版的报表与仪表盘工具。官方给出的迁移路径很清晰：转向 Contour / Quiver 与 Notepad 的组合，而非继续在 Reports 上投入。

5. Logic Flows
早期的自动化与工作流执行引擎。进入 AIP 时代后，其功能基本被 AIP Logic + Actions 取代，新项目已不建议采用。

6. Object Monitors
Foundry 原生的对象监控机制。能力本身并未消失，而是整体并入 Automate 体系，不再独立演进。

7. Use Cases
用于组织 Workspace 和项目的旧有工具。现在主要通过 Portfolios 等方式进行管理，Use Cases 正逐步淡出。

8. Foundry Rules 中的 Time Series Rules
时间序列规则这条子能力已被弱化，最新推荐直接使用 time series alerting automations。

9. Monitoring Views 里的 Check Groups
作为监控分组机制，已不再建议新建，监控视图成为新的承载方式。

二、Sunset 背后的战略信号

将这些被“退场”的功能并列审视，Palantir 在 Foundry 平台上的战略取舍便清晰可见。这不仅是功能迭代，更反映了产品哲学的几个根本转向。

第一，平台主动“收敛”，而非横向堆砌功能。
Pipeline Builder、Automations、Monitoring Views、Contour 等核心组件被持续强化；而一批曾“各自为政”的独立 UI 工具正逐步退出。平台正变得更具主心骨。

第二，能自动化的，便不再依赖手动配置。
Logic Flows 被 AIP Logic 取代，是一个标志性信号：从需要人工绘制流程图，转向由语义驱动、Agent 自动执行。这是 Foundry 明确的技术演进方向。

第三，减少中间层，强化统一语义与治理。
Reports、Recipes、Check Groups 这类“中间工具”，本质上承担了观察、通知或控制的部分工作。如今，这些能力被统一收归平台主干，碎片化问题显著降低，治理效率得以提升。

第四，Sunset ≠ 立刻下线，但等于不再押注。
这些功能大多仍可运行、可维护，但已不再承载未来的产品设计。对于新项目，最关键的一点是：避免基于它们做出长期的技术架构决策。

如果说审视 Sunset 列表是在看 Palantir 放弃了什么，那么分析其主推功能，便是在解读其未来数年的路线图。从近一两年 Foundry 和 AIP 的文档与产品演进来看，Palantir 的重心已高度聚焦，核心赌注都压在了几条明确的能力主线上。

三、Pipeline Builder：数据层的“唯一入口”

如今，所有与数据相关的能力，几乎都在向 Pipeline Builder 收敛。它集成了数据清洗、转换、调度、依赖管理，并能统一处理结构化与非结构化数据，同时保障处理过程的可观测、可回溯与可治理。

Preparation 被 Sunset，本质上并非相关能力消失，而是宣告数据工程必须走向工程化、版本化的道路。Pipeline Builder 已成为 Foundry 中确定性最高、最底层、也最不可能被替代的核心模块之一。

四、Ontology：一切智能与应用的地基

如果只能选择一个最能代表 Palantir 差异化的能力，那无疑是 Ontology。它负责将数据抽象为“业务对象”和“关系”，统一权限、血缘与语义解释，并直接服务于应用、分析、Agent 乃至最终决策。

这也解释了为何 Forms、Use Cases 这类偏重 UI 和组织层的工具逐步退场——Palantir 现在更在意“语义是否统一”，而非“界面是否华丽”。地基的稳固远比表面的装修更重要。

五、Automations + Actions：流程自动化，人力聚焦决策

当前 Palantir 推崇的自动化思路非常清晰：Automations 负责事件驱动、规则触发与调度执行；而 Actions / Functions 则负责对真实系统施加影响，例如更改状态、下达指令或调用接口。

Recipes、Logic Flows 被替代，并非自动化不再重要，而是老一代“图形化配置流程”的方式已跟不上需求。新的方向是：语义理解 + 事件驱动 + Agent 执行，直接推动业务动作发生。

六、AIP Logic / AIP Agents：推向市场的核心增长引擎

从商业视角看，AIP 是 Palantir 当前最核心的增长引擎。这些 Agent 能直接基于 Ontology 理解业务对象，在预设的权限边界内调用 Actions，并能解释决策逻辑、回溯原因，而非提供一个“黑盒”答案。

Logic Flows 退场，AIP Logic 上位，这清楚地表明 Palantir 已不满足于简单的“自动化”，而是致力于让 AI 成为业务执行中的一等公民。

七、Monitoring Views + Contour：统一“观察”与“洞察”

过去，Reports、Check Groups、Object Monitors 等功能各自为战。如今，它们全部向两条主线合并：Monitoring Views 专注于系统、数据、流程的运行态健康监控；Contour / Quiver 则侧重于分析、决策与业务视角的信息展示。

一个回答“系统运行是否健康”，一个回答“业务上发生了什么”，从而避免了零散报表工具的堆砌，实现了监控与洞察的统一治理。

八、Notepad + 应用层：人与系统的交互界面

Notepad 远不止一个笔记工具。它扮演着更关键的角色：将分析过程、图表、解释与结论置于同一上下文中，成为人与 Ontology、Agent 对话的界面，并支撑起协作、审计与决策留痕等关键需求。

这也是 Palantir 很少单纯强调“BI工具”的原因——它更关心整个决策过程的闭环与知识沉淀，而非仅仅是最终图表的呈现。

九、核心总结

归根结底，Palantir 当前全力押注的能力可以总结为：用 Ontology 统一语义，用 Pipeline Builder 管住数据，用 AIP Agent 直接参与决策和执行。

那些进入 Sunset 列表的功能，大多是特定发展阶段的“过渡形态”；而如今被重点推广的组件，才是 Palantir 真正打算长期投入、对外构建叙事、对内打磨精进的平台主干。这背后，是一条从工具集合迈向智能操作系统的清晰演进路径。