上午 8:15恒川工业的计划员在 Object Explorer 找到缺料事件SD-260808-01。他沿 Link 看见物料MAT-0001042、受影响订单、库存和候选方案又打开 Quiver 核对库存趋势。8:40没办完。因为第二天他还得重新搜索、筛选、排序、打开同一组关系再把方案编号抄进审批消息。Ontology 里对象、关系、Function、Action 都有了但“每天怎么工作”还只存在于熟练计划员的脑子里。这就是本篇要解决的问题怎样把一个已经能查、能分析、能执行 Action 的 Ontology交付成运营人员每天用得起来、办得完、出了错接得住的应用上一篇讨论 Automate 如何消除等待。自动化把任务送到人面前之后人仍需要一个明确入口接住任务、理解证据、作出决定并追踪结果。本篇进入第六单元先讲面向人的交付界面。一句话定义运营应用把 Ontology 变成一条可完成的用户任务流Ontology-aware application本体感知应用是在 Foundry 中直接使用 Ontology 的对象、关系、逻辑、Action 和权限为发现、分析或运营任务提供用户界面的应用。其中Object Explorer 让用户自由寻找和调查对象Workshop 让 Builder 把已经稳定的决策路径固化成角色化应用。它们不是 Ontology 本身也不是两个前后串联的技术层而是消费同一 Ontology 的不同应用工具。PalantirOntology-aware applications“本体可以被查询”不等于“运营产品已经交付”。用户还要知道先处理什么、依据什么、执行什么 Action以及失败后谁接手。先把五个工具放回产品架构初学者最容易把 Ontology Manager、Object Explorer、Quiver、Workshop、Contour 当成五个功能相近的页面。其实它们分别面对建设、发现、对象分析、运营应用和表格分析。这张图有三个判断。先看建设端Ontology Manager 是建设和治理工具。建设者在这里创建 Object Type、定义 Link 和 Action、连接数据并调查数据是否更新到了用户应用。计划员不应在 Ontology Manager 里完成日常缺料处置。PalantirOntology Manager再看使用端Object Explorer、Quiver 和 Workshop 是平行的消费工具。Object Explorer 保留探索自由Quiver 深化对象和时间序列分析Workshop 把固定路径交付为应用。最后看表格端Contour 主要站在表格/Dataset 一侧。数据尚未映射 Ontology、只是一次性文件或需要大规模表格操作时Contour 可能更合适但它不是对象运营应用也不是 Workshop 的下一级。PalantirContour overview同样是“看数据”五个工具到底怎样选工具核心对象工作方式恒川工业里的任务主要产出Ontology ManagerOntology 定义、映射与运行状态建设、维护、调查定义Supply Disruption、Links、Actions可被应用消费的 OntologyObject ExplorerObject / Object Set用户自己搜索、过滤、沿 Link 调查找到七日内高风险未处置缺料Exploration、Object Set、调查路径QuiverOntology Object 与 Time Series点击式分析、下钻、参数化比较库存、需求和安全库存趋势Analysis、可嵌入 DashboardWorkshopObject、Object Set、Function、ActionBuilder 预先配置角色化任务流从 Inbox 完成方案、审批和异常处理Workshop Module / 运营应用Contour表格/Dataset表格分析、转换、聚合检查尚未治理入 Ontology 的临时供应商文件Analysis、Dashboard、新 Dataset不知道怎样找先用 Object Explorer要解释风险进入 Quiver要每天按同一路径办完用 Workshop数据还只是临时表格先在 Contour 处理。工具的选择不是成熟度排行榜。判断标准是用户面对未知问题还是稳定任务输入是业务对象还是表格数据结果只需解释还是必须执行 ActionObject Explorer让用户先找到对象和问题Object Explorer 是面向 Ontology 的搜索和分析工具。用户可从关键词或 Object Type 出发用 Property Filter 和 Search Around 逐步形成 Object Set再查看探索视图、结果表格或单个对象的 Object View也可以比较集合、保存 Exploration、执行允许的批量 Action或把结果打开到兼容应用。PalantirObject Explorer overview它的价值不只是“搜索框好用”而是把业务语言变成可操作的调查路径Supply Disruption → status Open → severity High → shortage_date 未来 7 天 → Search AroundMaterial → Search AroundProduction Order / Customer Order → 排除已有开放处置任务的对象恒川计划员由此得到一个 Object Set七日内、高风险、影响确认任务、尚未处置的缺料事件。SD-260808-01位于其中。他保存的 Exploration 记录搜索参数、过滤和布局它不是静态导出因此再次打开时会基于当前对象状态重新求值。新用例早期BA 可以观察计划员从哪个对象出发、反复打开哪些 Link、靠哪些 Property 排序、在哪一步需要 Action。探索行为本身就是应用需求证据。但要守住两个边界。分享 Exploration 不会自动授予底层 Object 或 Action 权限每个用户仍按自己的权限看到结果。全局可发现 Object Type 超过 250 时关键词搜索会限制在前 250 个类型需要指定 Object Type 或类型组继续探索。PalantirObject Explorer getting started所以Object Explorer 是“无需 Builder 先做专用页面即可走上来用”的探索应用却不是无治理的全库搜索。Object View让同一个对象跨工具保持一致上下文当计划员点开SD-260808-01他看到的不是一行表而是 Object View核心 Properties、Linked Objects、相关分析与应用入口围绕同一对象组织。每个 Object Type 默认都有 Standard Object View团队也可用 Workshop 构建 Configured Object View。Full View 适合完整调查Panel View 适合嵌入当前任务上下文。PalantirObject Views恒川把 Panel View 控制在决策所需的最小信息风险、缺料日、物料、工厂、Owner 和当前方案Full View 再展开受影响订单、Action history 与WR-2048-*写回记录。Object View 保持对象上下文一致它回答“对象现在是什么”Workshop 回答“角色接下来怎么做”。Quiver 与 Contour别把两种分析混成一个词Quiver 对 Ontology 中的 Object 和 Time Series 做点击式分析。Links 已经表达对象关系用户无需重新解释主外键分析可以参数化、保存和分享Dashboard 还可以嵌入 Workshop。Quiver 也能通过 Action 把分析决定写回 Ontology但是否允许执行仍由 Action 权限和规则决定。PalantirQuiver overview恒川用 Quiver 复核MAT-0001042的证据账面 800 EA冻结 20 EA、预留 20 EA当时可用量为 760 EA再把需求、到货承诺和安全库存放到同一时间轴解释为什么SD-260808-01进入高风险集合。Contour 则面向表格。假设供应商临时发来一份两万行承诺清单团队还没决定它是否值得治理成长期对象分析人员可先用 Contour 清洗、聚合和检查异常。只有当它需要稳定身份、Link、权限、Action 和持续运营时才把相应数据产品映射进 Ontology。实施边界是不是所有分析都要先造对象但进入稳定决策和行动的核心信息不能永远留在临时表格里。Workshop把反复发生的路径做成运营应用Workshop 让应用 Builder 为运营用户创建交互式应用。它以 Object layer 为主要构件从 Object Data Layer 读取数据使用 Links 组织上下文Functions 提供业务逻辑Actions 执行受控写回。PalantirWorkshop overview在产品里Builder 创建的是 Workshop Module。Module 不是一张漂亮 Dashboard而是一组共同工作的构件构件负责什么恒川示例Layout组织页面、区块和 Overlay待办、详情、方案、写回四个区域Widget展示信息、接收输入、触发操作Object Table、Filter List、Metric、Button GroupVariable保存对象集、当前对象、参数和界面状态v_inbox、v_selected_disruption、v_horizonEvent响应点击、选择和导航选中一行后设置当前对象并打开详情Function计算复杂对象集或业务逻辑计算缺口、候选方案与优先级Action提交受权限和规则控制的业务变化接管、提交方案、批准、转人工复核Module interface定义嵌入或 URL 初始化时可传递的变量从 Material View 传入当前缺料事件Workshop Widget 通过输入和输出 Variables 连接Variable Lineage 可以追踪页面依赖。这里的 Module interface 是模块的输入/输出契约不是第 13 篇讲的 Ontology Interface二者只是英文同名。PalantirWorkshop widgets、PalantirWorkshop module interface恒川工业一条运营任务流怎样真正跑完恒川没有直接把初版搜索条件抄成页面。BA 跟随计划员完成三轮处置确认入队条件、上下文、角色、Action 和退出状态再设计 Module。步骤一进入 Inbox不让用户自己重建范围v_inbox是一个 Object Set定义为High、未解决、七日内、证据新鲜、没有开放处置任务并且当前用户有权处理。计划员打开应用即可看到SD-260808-01同时看到它为何入队而不是从几十个过滤器开始。第二步选择对象让上下文跟着走Object Table 的行选择 Event 把SD-260808-01写入v_selected_disruption。Panel Object View 显示核心状态Links 拉出MAT-0001042、客户订单、生产订单、Plant、Warehouse 和 Owner。嵌入的 Quiver Dashboard 使用同一当前对象显示库存、需求与安全库存趋势。用户无需复制编号到另一个分析文件。第三步形成方案但不把建议伪装成事实计划员调整时间窗口Function 重新计算缺口和候选方案。AP-2048仍是候选 Allocation Proposal而不是已批准事实。页面明确显示证据时间、规则结果和负责审批的供应链经理。第四步通过 Action 改变状态计划员可提交方案经理可批准或拒绝。按钮只负责发起 Action真正的权限、submission criteria、状态编辑和副作用仍定义在 Ontology Action 层。把批准按钮隐藏起来不能构成安全控制。第五步追踪 Writeback 与退出条件批准后应用展示WR-2048-*的 Pending、Applied、Failed 或需要人工复核的状态。只有写回完成并对账或缺料事件被 Closed/Cancelled对象才离开 Inbox。这样“看见成功提示”与“ERP/WMS 已形成业务事实”被明确分开。Workshop 交付的是操作路径不会替团队消除第 21 篇讨论的幂等、补偿和 System of Record 责任。BA 交付物恒川工业运营应用蓝图这张蓝图不是页面线框图而是业务任务、Ontology 构件、权限、异常和 Outcome 的共同契约。设计项恒川工业填写样例验收标准业务事件高风险缺料进入待办能解释入队与退出原因主要用户供应计划员审批人为供应链经理角色与实际职责一致Inbox Object SetHigh unresolved no open task fresh evidence与 Object Explorer 样本逐项核对当前对象SD-260808-01所有页面稳定指向同一对象身份决策上下文Material、Orders、Plant、Warehouse、Owner每条 Link 服务明确判断分析证据Quiver 库存、需求、安全库存趋势数值可复算时间语义可解释方案AP-2048状态 Pending Approval候选与已批准事实清楚分离Actions接管、提交、批准/拒绝、转人工复核权限和 criteria 在 Action 层生效WritebackWR-2048-*状态与外部回执不以页面反馈替代源系统对账退出条件Applied或 Disruption Closed/Cancelled完成条件可机读、可审计异常状态empty、loading、stale、unauthorized、conflict、partial failure每种状态都有责任人和下一步Outcome首响时间、决策周期、人工覆盖率、返工率指标能追到对象与 Action 记录BA 可以用它主持三场对齐先与运营角色确认任务流再与 Ontology/Data 团队确认对象和证据最后与 Security/Integration 团队确认权限、Action 和失败恢复。页面只是这些契约的呈现结果。产品约束应用能打开不代表任务能完成权限是依赖链不是 Module 的一个开关用户能打开 Workshop Module只说明他满足 Module 的 Organization、Marking 和角色要求。Module 里的 Object、Link、Action 和 Function 各自有权限官方提供 Check access 面板检查这些依赖。PalantirWorkshop permissions验收必须用真实角色测试“看见什么、为何看不见、能执行什么”。计划员可建议不可批准经理可批准敏感价格仍按属性策略控制。Event 有顺序但不会等待所有下游计算完成Workshop Events 按配置顺序触发却不会等待前一个 Event 引起的全部下游 Variables 重新计算完成。若“先改时间窗口再基于新窗口提交 Action”不应把两步藏进一次点击并假定传播已经完成应拆成可见步骤或增加明确的重算和确认。PalantirWorkshop eventsVariables 懒加载隐藏页面不是预计算区未显示页面、Tab 或 Overlay 中使用的 Variables 会懒加载。Builder 应通过 Variable Lineage 检查依赖不要假定所有隐藏内容已经计算完毕。PalantirWorkshop variables运营应用必须设计失败态空集合、数据陈旧、Function 超时、Action 冲突、无权限、Writeback 部分失败都应有页面反馈、责任人和恢复动作。只画 Happy Path 的 Workshop 是演示不是生产应用。什么时候应该从 Object Explorer 升级到 Workshop可以观察五个信号同一角色反复打开同一 Exploration总是沿相同 Link 路径补齐上下文同一组排序、阈值和证据已经稳定决策最终落到明确 Action任务需要入队、分派、退出、异常和 Outcome。五项中多数成立就值得固化为 Workshop。若问题仍不断变化先保留 Object Explorer 和 Quiver 的探索自由若输入主要是一次性表格Contour 可能更经济。真正的“升级”不是页面更漂亮而是把个人经验转成了团队可执行、可授权、可观察的任务契约。结论本体只有进入工作才成为运营产品Ontology Manager 负责建设和维护业务世界Object Explorer 让用户找到对象和新问题Quiver 把对象及时间序列变成可解释证据Contour处理仍处于表格世界的分析Workshop 把已经稳定的对象范围、上下文、判断和 Action 固化为运营应用。恒川工业的交付路径因此不再是“做一个缺料看板”而是从SD-260808-01入队开始围绕MAT-0001042汇集证据形成AP-2048经授权 Action 处理再追踪WR-2048-*直到对账或人工接管。现在人已经有了可完成任务的工具面。但下一步会出现一个新问题如果使用界面的不只是计划员而是一个需要读取对象、调用逻辑、提出建议甚至使用 Action 的 AI怎样让它理解同一个业务世界又不越过人的责任边界【声明】恒川工业及其编号、页面、角色、阈值和应用蓝图均为虚构教学设计不代表 Palantir 官方模板或真实客户实施具体功能、权限与限制应在目标 enrollment 发布前重核。