解密Palantir系列三:9.AIP · 从 Ontology 到 Agent,完整走一遍 AIP 工作流
解密Palantir系列三:9.AIP · 从 Ontology 到 Agent,完整走一遍 AIP 工作流
从语义层到行动层:用两门 Speedrun 拆解 AIP 工作流
两个独立训练场景,一条从数据、对象到 Agent 的能力链
前七篇把概念讲完了,一个合理的质疑随之而来:道理都懂,上手到底长什么样?
本篇选择两门官方 Speedrun 课程:第一门用文献知识库场景,把一堆 PDF 变成可问答的语义层;第二门用临床试验患者招募场景,在现成 Ontology 上装配一个会写回业务状态的 Agent。
需要先划清边界:两门课不共享同一套业务数据和 Ontology,并不构成一条可直接运行的业务链路。官方把第一门课作为第二门课的推荐前置;本文也只把它们并读成一条能力链的上下半程,用来理解“数据怎样成为对象”和“对象怎样进入 Agent”。
界面操作不在本文搬运。按钮位置和页面名称过期得最快,而连接关系更耐久。先给结论:
两门课展示的是能力链的上下半程:数据 → 对象 → Agent → 受控行动。第二门课的运行顺序则是:自动化触发 → 装载业务对象 → LLM Block → 结构化三分支 → 通过 Action 写回,或转人工复核。
一、实操分两段,各管半程
下图表达的是能力分工,不是数据血缘:第一段和第二段属于不同训练场景,Ontology 在图中代表共同的建模与操作范式,而不是同一套被复用的对象。
| 维度 | 第一段:搭语义层 | 第二段:装行动层 |
|---|---|---|
| 训练场景 | 文献知识库(概念案例) | 临床试验患者招募(概念案例) |
| 建什么 | 语义层:数据到对象 | 行动层:对象到受控行动 |
| 主要路径 | 上传 PDF → Pipeline Builder 切块、嵌入、抽实体 → Chunk 与 Entity 对象及关系 → Vertex 关系图 → Logic 问答函数 → Workshop 应用 | 安装基础 Ontology 与应用 → AIP Logic Agent → AIP Evals 评测 → Automate 自动触发 |
| 对应本系列 | 第 1、2 篇:生产线与上下文 | 第 3、4 篇:行动治理与评测 |
第一段值得注意的不是"上传了 PDF",而是它落成的资产结构:文献被切成 Chunk 对象并生成嵌入向量,LLM 从文本里抽出 Entity 对象,再用一张关联表把两者连起来——这是一个最小可用的知识图谱模式。之后的 Logic 问答函数检索的是带来源的 Chunk 对象,Vertex 图展示的是 Entity 之间的关系。第 2 篇说"检索的终点是决策上下文而不是文本",这一段就是把这句话动手搭出来。
学习顺序仍然有讲究:第二段直接使用现成的 Patient 和 Clinical Trial 对象、Action 和应用,并不复用第一段的结核病文献资产;它假设你已经理解语义层是怎么来的。没有第一段的 Ontology 视角,第二段就容易退化成填空练习。
二、行动层的六个工程关节
第二段是本篇重点。它给临床试验招募流程加一个资格评审 Agent,表面是十几组界面操作,骨架是六个工程关节。其中,对象输入、三分支输出、Action 写回和自动化触发构成运行链路;“先人后机”和“发布前评测”是链路启用前的两道护栏。
第一,先人后机。动手造 Agent 之前,先以领域专家身份手动评审患者、手动触发 Action。这不是拖时间:流程没有被理解和编码之前,自动化无从谈起——你在第 7 篇见过这个论点,这里是它的实操版。
第二,输入是对象,不是粘贴的文本。Logic 函数的两个输入是 Patient 对象和 Clinical Trial 对象,试验标准是对象属性,患者的年龄、诊断、用药史逐个字段喂给任务 Prompt。这就是第 2 篇讲的 Ontology 上下文:Agent 读的是业务对象,不是一段复制来的说明文。
第三,三分支输出是内建的人工复核出口。System prompt 明确要求三种结论:Suitable、Not suitable、Manual review required——信息不足时不许猜,转人工。输出被定义成 struct 的两个字段(决定与理由),而不是自由文本。第 3 篇说的 Request Clarification 思想,在这里以 Prompt 设计的形式出现。
第四,写回走的是同一个 Action。LLM 的输出字段被逐个接到一个已存在的 Modify Eligibility Decision Action 的参数上——就是此前在应用里手动点过的那一个。人和 Agent 共用同一个受控入口,这是第 3 篇"读、算、写分离"的实物:Agent 没有获得任何人类没有的通道。
第五,评测在发布之前。暴露 LLM 输出、建评估套件:一个 Exact string match 评估器加三个测试用例,恰好覆盖三个分支;然后换一个模型重跑,对比两次结果。这是第 4 篇"换模型前先考试"的最小版本。
第六,自动化有明确的触发和边界。函数以 user-scoped 模式发布,Automation 的触发条件是"新增 Patient 对象",效果是对新患者运行评审函数。存量患者手动批量执行一次,之后新患者自动处理——而 Manual review required 的患者,留在队列里等人。
三、训练环境刻意简化了什么
训练环境的目标是短时间内跑通,它省略的恰好是前几篇的重点。照单全收会把练习当成生产模板,这张对照表标出差距:
| 练习做法 | 生产要求(对应篇目) |
|---|---|
| 单个 Exact match 评估器、三个手写用例 | 多类评估器组合、历史数据与扰动测试集(第 4 篇) |
| Action 由 Agent 直接执行,无审批 | 按后果分级设计确认、暂存与多角色审批(第 3 篇) |
| 试验对象在 Automation 中写死为静态对象 | 参数校验、对象存在性与业务前置条件检查(第 3 篇) |
| 练习按 user-scoped 模式执行 | 区分 user-scoped、project-scoped 与 automation owner(第 3 篇) |
| 主要查看 Automation 事件和运行状态 | 将 Metrics、Trace、Action Log 与业务结果关联(第 4 篇) |
练习里的资格评审是低风险写回:改的是一个评审状态字段,错了可以重评。把同样的"Agent 直接执行 Action"搬到采购下单或者付款流程,就是另一回事了。
四、环境差异:你的实操可能长得不一样
实操步骤以训练环境为准,而你的 Enrollment 可能不同。卡住时先核对四项:
- 安装权限:基础训练资产可能需要管理员安装;
- 模型清单:可用模型取决于区域和管理员启用状态;
- 项目规范:组织可能要求不同的命名、目录和权限结构;
- 界面版本:按钮位置和名称会随产品更新发生变化。
这些差异通常比步骤本身更容易造成卡点。这也是本文不搬运界面截图的原因:它们过期得最快。
五、动手时的七个自查问题
每走到一个关键节点,都停下来问一次:
| 自查点 | 走到对应步骤时问自己 |
|---|---|
| 输入 | Logic 的输入是对象还是文本?属性怎样进入 Prompt? |
| 分支 | 三种结论在哪里定义?信息不足时 Agent 被要求做什么? |
| 写回 | Action 是谁创建的?人在哪里手动用过它? |
| 评测 | 评估器测到了什么?没测到什么? |
| 对比 | 换模型后,哪个用例的结果变了? |
| 触发 | 自动化由什么触发?范围是新增对象还是全量? |
| 兜底 | Manual review 的患者最终由谁、在哪里处理? |
七个问题都能回答,这次实操的价值就拿满了;答不上的那一个,就是值得回读对应篇目的地方。
结语
实操的终点不是"跑通了",而是"看懂了每一段连接为什么存在"。
一句话记住:动手把链路搭起来只是第一步,前几篇告诉你生产环境里每一环还要再加什么。
会搭链路、会筛用例之后,只剩最后一个问题:从 Bootcamp 的快速冲刺到长期生产运行,中间到底隔着哪些工程与组织工作?下一篇收尾整个第一季。
参考资料与证据说明
| 资料来源 | 本文用途 |
|---|---|
| Palantir Learn:Speedrun: Your First AIP Workflow | 语义层路径:PDF 上传、Pipeline Builder、Chunk 与 Entity 对象、Vertex、Logic 与 Workshop |
| Palantir Learn:Speedrun: Your First Agentic AIP Workflow | 行动层路径:Logic Agent、三分支 Prompt、Action 写回、Evals 与 Automate 配置 |
| 本地归档(palantir_learn,2026-07 证据快照) | 实操步骤与配置细节的本地核对依据 |
