前置部署架构师谈本体、仪表盘之死,以及将 token 成本削减 60% 的 Evolve 工具——Chad Wahlquist(Palantir)

Chad Wahlquist · TBPN

Agent 工程 AI 产品

原文约 2.4 万字预计阅读 21 分钟来源视频 ↗ 中英对照全文

TL;DR · 三句话

一Palantir 前置部署架构师 Chad Wahlquist 的底层主张是「人和 AI 协同」：LLM 没有你业务的世界模型，得靠本体来补——而本体不是 1996 年 Kimball 维度建模那种行和列，是能把 CAD 文件、图片、表格装进同一个「工厂」对象的多模态语义对象；同一个本体同时喂运营应用、KPI 和 agent，每接一个用例都在叠加复利。→ 详细
二他全场最锋利的一句是「我想把仪表盘全干掉」：KPI 应该是人在里面做决策的运营应用的副产品，奔着建仪表盘去就是「建好了没人来」；而把数据往上汇总成 KPI，会把成本像花生酱一样抹平，以至于从一亿到 500 亿美元的公司都常常「赚钱纯属意外」，连自己最赚钱的产品是哪个都不知道。→ 详细
三落到 agent 成本上，新工具 Evolve 读生产日志，找出哪些环节能换别家模型、换不开思考模式的老模型、用缓存，或干脆把那块数据放进本体省掉推理——有客户两天内靠重做架构 + 换模型 + prompt 调优砍掉 60% 的 token 成本；同时把用户的显式和隐式反馈存进本体、跑 OODA 循环，让 agent 越用越懂业务。→ 详细

「前置部署架构师」的活儿：没有哪份活在我之下，核心是帮客户换个方式拆解问题

Chad 自我介绍：严格来说他是一名 forward deployed architect（前置部署架构师：驻到客户一线、把技术落进真实业务的架构师），信条是 Palantir 式的「doing the needful（做该做的事）」——「没有哪份活儿是我不屑干的」：可能在一线陪客户、在跟高管讲解本体（Ontology），也可能在录 YouTube 视频。（开场玩笑：Karp（Palantir CEO）爱讲「操纵时间」，这类节目他们按季度来一次。）→ 详细
他给自己工作的一句话定义：「目标就是怎么帮大家换个方式去拆解（decomp）问题，用新的方式去应用技术。」 decomp 是 decomposition 的简写，指把一团乱麻的业务问题拆成能建模、能落地的小块。→ 详细
主持人把「拆解」当成 Palantir 的秘方追问，并给了一段很到位的描述：很多人看 AI 工具，想的是「定义清楚的工作流、有输入有输出，只不过除了 Python 能算的数学，现在还能处理文本」；但真正的拆解从来不是去翻 HR 系统里的岗位描述，而是发现「其实 Steve 干的这件事完全在那个系统之外」「市场部为这件事用着两个平台」「工程部光管 CAD 文件就有三套系统」，以及那些积累了几十年、有的组织甚至上百年的线索——这正是 FDE（forward deployed engineer，前置部署工程师）模式特别的地方（FDE 模式本身见 ep106）。→ 详细

AI 能做拆解吗：本体给 LLM 补上「你公司的世界模型」，再让多个 agent 互相挑刺

主持人很意外：拆解「感觉就是终极大 Boss」，AI 居然能做？Chad 先亮底牌：「这就要说到 Palantir 真正的核心主张了：人和 AI 协同工作。」→ 详细
为什么需要本体：「LLM 不一定具备关于你的业务、你的运营的世界观或者说世界模型，本体提供的正是这个。」 所以他们的思路是把业务流程建模进本体（Ontology：用一套统一语义把公司里的对象、关系、动作描述出来的业务模型）。这和库里 ep98（Frank Coyle：agent 为何需要本体）的论点同源。→ 详细
拆解在 AI 时代多了一层意思：用 LLM 让更多数据变得可计算。LLM 不只是拿来跟 agent 对话的交互层，也被当成数据加工层——先把原来算不了的信息变成能算的，再把「事情真实的运作方式」建模进本体。→ 详细
具体作业顺序值得原样记下：先把这套世界观搭起来 → 再让多个 agent 在上面跑，「而且让它们彼此对抗，互相唱反调、互相挑刺」→ 做完这一步，让人在回路（human in the loop：人在关键节点审核、给反馈）里给反馈 → 不断迭代。Chad 的结论是：「我们发现，这其实是一种规模化机制。」 注意顺序——对抗式多 agent 是跑在「已经建好的世界观」之上的，不是让 agent 在真空里互辩。→ 详细
对「AI 抢饭碗」的回应是电动工具比喻：「当年给木匠配上电动工具，木匠并没有变少，反而变多了，有了它我能干更多活。」 这是赋能，不是替代。→ 详细

从成果倒推，别盖「梦幻之地」数据仓库：企业软件逼你进框，Palantir 想让你「更与众不同」

主持人点出张力：一边是「理解并把整个业务都跑在 Palantir 上」的宏大推销，一边是低垂果实——比如「居然有人的工作就是把表单内容敲进电子表格」，图像识别早就有了。怎么既盯住大目标，又一件件把活干完？→ 详细
Chad 回到 forward deployed 的本分：交付的是成果，从成果倒推。反面教材是「嘿，我有这些数据，我要建个数据仓库，然后再做报表，因为我所有数据都集中到一处了」——「那就是《梦幻之地》式的幻想，建好了，却根本没人来。」（典出电影《梦幻之地》「建好了就会有人来」的信念。）→ 详细
他批评的主流路数：企业软件会逼你钻进它们的框框里。代价是你得自问「我是不是把自家公司的独门秘方给弄丢了？」——原来大家做事有各种混搭方式，「比如，下个采购单（PO，purchase order）就有 40 种做法」。→ 详细
他给的中间地带：「也许有 40 种做法本身没问题，问题是我的软件应付不了，而且是碎片化的。」 很长一段时间里「定制化」差不多是个脏字（原话 four-letter word），没人愿意碰；Palantir 由此思考 malleable software（可塑软件：随业务形状变形、而不是让业务迁就它的软件）——「怎么帮你变得更与众不同，而不是越来越同质化？」→ 详细
所以拆解问题时不光看定量的部分，也看定性的部分，以及围绕它的人和流程：「怎么让这些人继续去做那些让他们与众不同的事？」→ 详细

AI 一口气生成百万行代码，软件还可塑吗：缺的是一层「可塑的企业级脚手架」

主持人的追问：AI agent 写代码快得惊人（一天的活几分钟搞定），可满屏都是「我实现了这个功能」、GitHub 上代码 +100 万行的截图，context window（上下文窗口：模型一次能「装进脑子」的文本量）涨得跟代码量一样快。他信奉「对付烂 slop（AI 垃圾产出）的答案是好 slop，也许还得是更多 slop」，但担心过去那种最可塑的软件——高手把问题浓缩成一个 2000 行的 repo、能整个塞进上下文当积木用——正在消失。→ 详细
Chad 的回答：「我觉得缺的是那层可塑的企业级脚手架（scaffolding）。」 这正是 Palantir 打造本体、Foundry（Palantir 的数据平台）、整个平台，以及 Apollo（让他们能把这些变更部署出去的系统）的思路——「它给了我们恰到好处的结构，也给了恰到好处的自由。」 要找的是「中间那层可塑性」：既能让人用不一样的方式做事，又依然是企业级、稳健、安全、可扩展的软件。→ 详细
落到人身上：一直在做这件事的工程师，现在写代码快多了，可以腾出手去统筹把关（oversee）；中间那层企业级脚手架负责设好护栏（guardrails），「为他们打造一个安全的工作体系，让他们在里面放手开发」。所以他的答案不是让代码变少变好读，而是让平台层把结构和边界兜住。→ 详细

反馈回路要存进本体：用户一句「这个错了」、一次「我选了这个」，都是 agent 学习的原料

除了脚手架，Chad 说他们用本体和平台做的另一件事，是收集用户在使用过程中给出的隐式和显式反馈，由此搭出 OODA 循环（observe 观察、orient 调整、decide 决策、act 行动——主持人当场补全的四步，一种边做边修正的决策循环）：客户在跑工作流的同时，就在给 agent 反馈。→ 详细
反馈长什么样：有直接说出口的「嘿，这个错了」「这个太烂了」，也有「我选了这个选项」这种——选择本身就是反馈。「反馈攒得够多，agent 就能开始从中学习。所以我们其实把这些反馈存进本体里，好让它能规模化。」 关键在后半句：反馈被存进本体、成为业务模型的一部分，而不是散落在某次对话里用完即丢，才谈得上规模化。→ 详细
他把整套东西收成一句价值观：「说到底，这就是一套围绕 AI、以人为中心的流程。我们不该为了 AI 而搞 AI，AI 是为了让人能做更多事。」——「这就是整个思路框架。」→ 详细

给前沿模型实验室的意见：不绑数据、不绑模型，因为「换平台」最推不动成果

主持人问：给你 30 分钟向前沿 AI 实验室（做领先模型的公司）提反馈，讲什么？还调侃第一条肯定是「别跟我们抢生意」。Chad 否认：「我觉得有选择权是好事」——数据存哪、选什么模型、用什么算力都不设限，「因为真正能推动成果的事情里，最排不上号的就是换平台」。→ 详细
这种不绑定刻在公司 DNA 里：本地部署（on-prem）、安全云、ITAR（美国《国际武器贸易条例》）合规。所以要在客户现有基础上赋能，而不是「全迁到 Palantir 上就都好了」——「你很可能这些年一直在换平台。我们能不能让你现有的东西去做这些新的事？」 对模型公司的诉求他只点到「工具调用（tool usage）方面的反馈回路」；主持人想追问各家模型哪里能力忽高忽低（spiky）、有什么短板，话题转到 Evolve。→ 详细

Evolve：读生产日志找出钱烧在哪，换模型 + 改架构 + 调提示词，两天砍掉 60% token 成本

来历：Chad 上周刚发了个 YouTube 视频讲这个叫 Evolve 的新工具，他们在 halftime show（中场秀环节）上也聊过——客户其实在用 AI 帮自己搞清楚「该用哪个模型」。出发点是那个梗：「先做出来，再做好」（make it exist first, then make it good）。→ 详细
痛点的来龙去脉：「我看到大多数人用 agent 搭东西时，用的都是最新的前沿模型。」 好不容易「我终于把它跑通了」，紧接着 token maxing（狂烧 token）就来了——「天哪，我整个预算一下子全烧光了。」 也就是「先做出来」阶段为了跑通默认上最强模型，到了「再做好」阶段，没人回头算这笔账。→ 详细
Evolve 怎么干：去分析生产环境里的日志，看三件事——这些模型实际怎么运行、大家拿它们在干什么、上面搭的是什么架构；然后给出可执行的替换方案：①换成不同供应商的其他模型；②「这个工作流的大部分环节，你都可以用这个更老的模型，而且不用开思考模式，也不用 test-time compute」（test-time compute：推理时让模型多花算力「多想一会儿」换准确率），换来的是确定性更高。→ 详细
另外两条更狠的路：③甚至直接用缓存模型（cached models）；④「嘿，其实你只要把这块数据放进本体里，这些就全都省掉了，成本还能砍掉 50%」——也就是有些环节根本不该让模型去推理，该是一条现成的数据。→ 详细
实战数字：有些客户——McCarthy 在他们的 halftime show 上讲过——两天之内就把 token 成本砍掉了 60%，靠的是三件套组合：重做架构（rearchitecting）+ 换一个模型 + prompt 调优。Chad 强调难点恰恰在组合：「排列组合会变得非常难，尤其是在这种概率性模型上；在确定性的世界里，我们是有工具来做这件事的。」 概率性系统里缺的正是这种搜组合的工具，所以才要做 Evolve。→ 详细
对谈里顺带讲了 prompt 调优的一个反直觉写法：别再写「不许犯错」，而是写「犯点错没关系，要是这个错只花一点点钱，我能接受」——因为「不许犯错」这一句，会让我花掉一大笔钱。 把「哪些错可以容忍」写进提示词，本身就是降本手段。→ 详细
主持人接着提到前一天网上的讨论：某个模型为了更高效，用一种很蹩脚的腔调说话——即 caveman prompting（原始人式提示：让模型用原始人般的蹩脚短句说话，以求更省更快）；对谈中的结论是「原始人提示法还真管用」。→ 详细

「迷你 ChatGPT 时刻」为何没人声张：X 不是真实世界，真优势闷在财报里

主持人问：你们多常碰到这种公司——内部经历了一次「迷你 ChatGPT 时刻」（找到一种效果极好、能带来优势的 AI 用法），然后决定「这事咱们谁都别说出去」？→ 详细
对谈中的推演：X 上嗓门大的人会晒「我让一个产品在这件事上连续干了 30 个小时」，但财富 500 强搞明白一件事不会举手宣布——秘密是值钱的；突破也不均匀，你一喊「航空业从此不一样了」，直接竞争对手就抄走了。能公开聊的只剩 token maxing 这种人人争论的梗（CEO 也许会喊停），更多有趣的时刻要等变成标准作业流程、或者在财报和经济账上显出来，外界才会知道。→ 详细
Chad 的补刀：「可惜 X 并不是真实世界」，那上面有大量忽悠和噪音，还有播客、PMing 之类层出不穷；真实世界里已经分出了「有」和「没有」两拨。→ 详细

「有」和「没有」差在哪：AIG 核保几小时出报价，连 SAP 迁移砍掉一半都是大事

Chad 举 AIG（美国国际集团，保险公司）为例：复杂的企业级保险协议，核保（underwriting：评估风险、决定保不保、怎么定价）几小时或几天就出报价，而不是等上几个月——「如果你没有这种能力，你还怎么跟人竞争？」 Palantir 要争取的正是这类 N of 1（独一无二）的公司，也看得到那些不公开的时刻，「这就是竞争优势」。→ 详细
主持人补账：客户会把 AIG 的对手挨个问一遍，AIG 24 小时出报价或保单、别家因为情况复杂要两周，手里一有两份报价，第三、四、五家就先放一放了。→ 详细
Chad 补上第二重回报——效率本身能建立信任：看到别人这种效率，你会想「还能做什么？」哪怕是 SAP 迁移（SAP 是大型企业 ERP 软件；他自嘲这是「你能聊到的最不性感的话题」），几亿美元的一次迁移，他们能帮你砍掉一半——「这可是件大事」。→ 详细

仪表盘之死：「我想把仪表盘全干掉」，KPI 应该是做决策的运营应用的副产品

主持人顺着 OODA 循环的「观察」一环发问：仪表盘的供需是什么情况？是需求太多——人人跑来说「这个要个仪表盘、那个也要个仪表盘」，你们得劝他们收一收，说也许做个临时分析（ad hoc analysis）、或者亲自去看一看就够了？还是机会多到想把仪表盘推到每个角落？他自己的老看法是：「仪表盘太多了，做出来之后根本没人看。」→ 详细
Chad 的回答是全场最锋利的一句：「嗯，我想把仪表盘全干掉。」→ 详细
理由：「KPI 和仪表盘应该是运营应用的副产品，是我在里面做决策的那种应用。」（KPI：关键绩效指标；运营应用：人在里面真正做业务决策、执行动作的应用，区别于只能看、不能动的报表。）他用 OODA 循环讲因果：「我得真正采取行动，事情才能落到利润上、才能产生价值。」 主持人确认「是在实际的应用里？」——Chad：「在应用里。当我需要这些东西、而且它们能帮我做出更好的决策时，那才是我想要这些指标出现的地方。它们应该是副产品。」→ 详细
反面还是那个比喻：「如果我一出发就奔着建仪表盘去，那又会是《梦幻之地》那一套，结果根本没人来。」——和主题三批评「先建数据仓库再做报表」是同一条逻辑：没挂在决策和动作上的指标，建好了也没人用。但他没把话说死：「所以没错，你确实还是得建一些这类东西。」→ 详细

1996 年的 Kimball 维度建模 vs 本体：世界不是按行和列运转的，一个本体同时喂应用、KPI、agent 才有复利

仪表盘的另一面是数据仓库。Chad 说不打算在技术话题上扯太深，但点了一个刺眼的时间差：「Kimball 和维度建模是 1996 年为了扩展数据库而诞生的，可到了 2026 年，你还在用同样的方式建模」——为的是喂你的仪表盘、你的 Tableau（常用的 BI 报表可视化工具）。（维度建模：数据仓库的经典建模法，把业务拆成存数字的「事实表」和存属性的「维度表」，方便按维度切片汇总。）→ 详细
核心反驳：「世界实际上并不是按行和列运转的，你需要复杂的东西才能对真实世界的运作方式建模，这就是我们对本体的思考。」 这里正是与 207 老冯「本体 = 数据库建模换皮」的反方论证正面相撞的地方。→ 详细
本体的回报在复用：「我可以把它复用到运营应用、KPI、agent 上，全都建在同一个本体之上，由此形成复利效应」——「我每加进来一样东西，都是在叠加复利，我处理的每一个决策，都会让我在整个业务里接入的下一个用例变得越来越好。」 对照他上一句：维度模型是「为了你的仪表盘」建的；本体里，KPI 只是和应用、agent 并列的一种用法，三者共用同一份业务语义（本体与语义层的分工另见 ep99）。→ 详细

AI 会吃掉技术栈吗？「yes, and」——本体是装得下 CAD、图片和表格的多模态语义对象

主持人拿 NoSQL 热潮类比：当年喊「干嘛还要关系型数据库和 schema（表结构定义）、以后别再做迁移」，结果几乎双赢——Postgres 和 MongoDB 等非关系型数据库都涨了，Redis 也被拿来干各种事，「巨人越来越多」。那 AI 工具是在蚕食技术栈的某些环节，还是在企业里全是「yes, and（在原有基础上叠加）」？→ 详细
Chad：是「yes, and」，而且体现在几个地方——「真实世界不只是行和列，你没法用度量和属性去描述一切。」（度量和属性，就是维度建模里的「数字」和「标签」。）→ 详细
所以本体是多模态的：「你可以有一个语义对象，里面同时装着一份 CAD 文件、一张图片、一个 CB 模型，还有表格数据，全都在『工厂』这一个语义对象里。」 他点出的意义只有一句：「这意味着我开始用自己业务的语言说话了。」——你面对的是「这座工厂」，而不是散在几个库、几个桶里的表和文件。→ 详细
对比别处的做法：「我得有个 MongoDB，这边还得有个 SQL 数据库，那边还得有个 S3 bucket（亚马逊云的对象存储）」，才能把不同类型的东西分门别类地存起来；Palantir 则把这些——包括向量（vectors，AI 检索用的语义数字表示）——全放进本体。目标是按真实世界实际的运作方式建模，并让底层技术对用户透明：比如石油平台上传感器的时序数据该用哪种技术来存——「无所谓，对吧？」→ 详细
平台定位一句话：把「无差异化的繁重工作」（non-differentiated heavy lifting：每家都得做、做好了也不构成优势的底层苦活）真正放进平台里，消除把事情做成过程中的摩擦。→ 详细

「公司赚钱纯属意外」：KPI 把成本像花生酱一样抹平，不下到最细粒度就算不出真实销货成本

主持人问：营收过一亿美元、却对自己业务实际怎么运转几乎不了解的公司有多常见（可能只知道「做个产品，卖得比交付成本高」）？50 年前跨时区、跨办公室、没有电子邮件，大公司内部的迷雾放到今天难以想象；如今迷雾少多了，那 Palantir 进场前的公司长什么样？→ 详细
Chad 以一句玩笑开场：「我常开玩笑说，很多时候公司赚钱纯属意外。」 他们其实不知道自己最赚钱的产品是哪个，还经常卖力推销那个其实并不是最赚钱的东西，反倒没去卖真正赚钱的那个。→ 详细
根因在建模方式：他们把数据往上汇总成 KPI 和其他指标；可实际上，「你需要以最细的粒度对业务的运转方式建模，才能算出比如真实的销货成本（COGS），或者真实的服务成本（cost to serve）」。（COGS：卖出去的货本身实际花了多少成本；cost to serve：服务一个客户或一笔订单实际摊到的全部成本，如履约、售后。）这件事非常复杂，所以 Palantir 的思路是「拥抱这种复杂性」，让人能在一线、在战术层面真正搞明白——「怎么多做好的事、少做坏的事。就这么简单。」→ 详细
失真是怎么发生的：「这些东西都被 KPI 和各种指标像抹花生酱一样摊平了，大家其实并不知道自己的业务是怎么运转的。」（抹花生酱：把成本或收益平均摊到所有产品、客户头上，赚钱的和亏钱的混在一起，谁也看不出来。）而且和规模无关：「不管是一亿美元的公司还是 500 亿美元的公司，这种情况我见过多少次都数不清了：他们其实并不在细粒度上清楚自己到底是怎么赚钱的。」 这和主题十「仪表盘之死」是一体两面——汇总指标不只是没人看，还会让人推错产品。→ 详细

Palantir for Builders：免费开发者版 + Shopify 集成，一门快倒闭的生意三个月从 -10% 拉到 +9~10% 利润率

主持人的最后一个问题：将来会不会有一天，一家公司刚在 Stripe Atlas（Stripe 的线上开公司服务）上注册成立，除此之外开通的第一个账号就是 Palantir？Chad：「那我可太乐意了。」→ 详细
他列出现成的入口：有个 Palantir for Builders 计划；「我们这儿就有两个人的初创团队，就在加拿大自家阁楼里干」，「真的是任何规模的公司都行」；有免费的开发者版（dev tier），谁都能来上手搭；Palantir 里还有 Shopify 集成（Shopify：主流的独立站电商建站平台），连上自己的 Shopify 就能把数据拉进 Palantir，「真有人在这么干」。他也自嘲：「我们是不是一直都很会推销、很会讲这个故事？当然——不是。」→ 详细
案例：几个哥们原本是「嘿，我的生意快撑不下去了，我卖的东西利润率是负 10%」，后来看了 Palantir 的 YouTube 视频、自己动手搭出来，三个月就把利润率拉到了正 9% 到 10%——将近 20 个百分点的翻转。→ 详细
Chad 的判断：「我真心觉得总有一天这会变得无处不在」——「大家是真的能自己做到的」，「这就是那种伟大的美国故事」，他们要做的是让这种事成为可能，「可能还得花点时间」。→ 详细

闪电问答 / 收尾

本期无闪电问答。主持人的「最后一个问题」（公司在 Stripe Atlas 注册后开的第一个账号会不会是 Palantir）及 Chad 的回答已并入主题十四；收尾是主持人致谢、预告下一位嘉宾 15 分钟后上线。→ 详细

联系方式

本期未提供嘉宾联系方式。节目中提到、但未给链接的资源：Chad 上周发布的 Evolve 讲解 YouTube 视频、Palantir for Builders 计划、Palantir 免费开发者版（dev tier）、Palantir 的 Shopify 集成。原节目页见文件头「视频」链接。

接着读

NO.208 · Agent 工程 Ontology MCP:本体驱动的内部规划工具——Chad Wahlquist、Mike Barone(Palantir) Chad Wahlquist Palantir内部自用Ontology · 22 分钟 NO.207 · AI 产品 Palantir 的“本体论”骗局 + 一场辩论之后,认真聊聊“本体论”——冯若航(VONNG) 冯若航 · 27 分钟