Mike 说差别最能感受到的地方，是对象之间的关联：假如你有五个 MCP，随手丢给 AI 说「把这些东西之间的冲突理清楚、找找规律」，它「每次做出来都会有点不一样」，容易出错、费时间，还「会烧掉大量 token」（token 是大模型计费和上下文长度的基本单位，烧得多就是又贵又慢）。关系提前建模好以后，「离一次就把这些分析做对近了很多」，拿回来的数据也是 AI 能直接处理的形式。换句话说，关系建模这件苦活，要么人提前做一次，要么 AI 每次现场猜一次。（agent 为什么需要本体的一般论证见 ep98。）→ 详细
等 agent 跑时 Chad 感慨：Palantir 的工单系统本身就建在本体和 Foundry 上，这些实时在用的 system of record（记录系统，业务数据以它为准）汇到一处，本体把工单流程映射到各产品模块——「这其实就是 Palantir 如何运转的本体」，随时能对着它发问、做规划、迭代。Mike 第一次用时「真的被震撼到了」，整天在问「这个团队在忙什么？」——「那种对全局的掌握程度，是我以前从来没有过的」。→ 详细
复盘还能直接变成干活起点：网络工程团队的人看到「有些 Terraform 的问题」（Terraform 是用代码管理基础设施配置的工具），粘进 Claude Code 说「去把我所有的配置文件都看一遍，真正帮我把这个问题修好」，接着走平常的写代码流程。→ 详细
Chad 在这里把分工说透：agent 把这些活干完之后，你就能「真正专注在策略上、专注在真正动脑子的那部分——对吧，这部分我们是不会甩给 LLM 的」。→ 详细
他给 AI 的职责划了清楚的边界：「关键在于，它能不能把所有数据汇到一起，拿出一个打底的基础。这样我就能从战略层面去思考，而不是忙着找这个东西在哪儿、那块内容又在哪儿。」AI 管「找齐」，人管「想透」。→ 详细
Mike 补上组织层面的收益：规划讨论里很常见的是大家「凭感觉」说「这些是大家一直在抱怨的、这些是让人很头疼的」，而「有了真正以数据为依据的视角，这类讨论就容易太多了，能直接切入正题」；还能一边推进产品、一边给规划做原型、反复迭代。→ 详细
13
换一个 agent 来审稿：Claude 起草，Codex 挑刺，两边连着同一个本体
Mike 分享一个「一直觉得特别有用」的习惯，不管是 AI 写代码还是写这种书面文档都适用——「换另一个 agent 来检查一遍」。他让 Claude 在后台继续起草网络工程团队那份，自己切到另一个开着 Codex 的窗口（Codex 能访问 Claude 刚写的那些文件），让它看一下这份规划草稿给点反馈：「切不切实际？是不是太激进了？」→ 详细
Chad 追问关键问题：「说到把它固化下来，或者说，我要怎么写回、怎么把这些规划真正建出来？」→ 详细
Mike 在规划工作流的最后一步只说一句「好，这份没问题了，正式发布吧」（他顺带说自己打字出错、手滑都没关系，它能看明白）。agent 随即发起「一大串 OMCP 调用，去调我前面展示过的那些 action」——写回本体靠的正是配置时开放出来的那几个规划动作。画面里能看到它边查边判断：找到一个 T3 规划 → 发现是网络工程团队的 → 推断技术支持团队还没有 T3 规划 → 先起草 → 一度「不太明确」→ 最后决定把 T3 的 Markdown 文件拉出来发布。Mike 很坦白：「看来这里还得我稍微盯着点。嗯，不过它最后能搞定。」→ 详细
结果核对：规划已经进了本体，是为数不多的几份 T3 规划之一（Tech Support），「它在本体里一路都找对了地方，所有目标和关键结果都建对了，全部发布完毕」，「我都不用去一张张点表单」。Mike 的总结：「我在发布规划、整理规划格式上花的时间是零，所有时间都用在了真正做规划上。」→ 详细
发布后，规划会回到那个 Workshop 应用里——「公司里其他人就是在这儿看这些规划的」——别人在自己的 AI 工具里跑工作流时也能引用。两种界面分工很清楚：只想大致翻翻「tech ops 那边在忙什么」，用 Workshop 就够；要更偏战术的信息或做冲突梳理，就回到 AI 工具里。→ 详细
15
规划变成结构化对象之后才能「算」：一句话问出跨团队卡点
Chad 点出发布这一步的真正价值：现在拿到的是一份结构化的规划，能跟其他产品模块、业务里的其他信息打通，「我就有各种办法基于它做计算，想怎么用就怎么用」。他的概括是「有这样一块结构化的组件，让我能去处理非结构化数据」——在结构化和非结构化之间来来回回，「恰恰就是组织真实运作的方式」。→ 详细
Mike 当场演示回报：随手抛一个典型问题「技术支持团队在哪些地方被网络工程团队卡住了？」因为两份规划都已发布进本体，agent 能通读后弄清两队在哪些地方相互依赖、哪些地方要互相提工作项和 issue、哪些已经畅通、哪些被卡住、哪些能往前推，很快就给出一份简短的依赖清单。「这类事平时真的特别繁琐」，现在能直接问开放式问题，再以此为起点去推进工作。→ 详细
16
先在顺手的工具里手动跑通，再固化进平台：从「探索」升级到「固化」
Mike 主动接住一个预期中的质疑：看视频的 AI 工作流老手大概会说「这挺好的，但其中很多步骤完全可以自动化啊」——「我觉得这话说得完全对」。他的顺序是：先用几个不同的 AI 工具手动把流程走一遍、攒下经验；一旦认可了这个工作流，就用另一个 Foundry MCP（更偏向用来搭建东西的那个），或者直接在 Foundry 里用 AI FDE（Palantir 自家的 AI 版 FDE；FDE 即 Forward Deployed Engineer，驻到客户现场把方案落地的工程师，见 ep106），把整个工作流固化下来。「一旦我们摸清了这套流程最有价值的版本，它就应该自动发生。」→ 详细