企业的原子单位是工作流，不是知识工作者
Palantir 史上最强财报的电话会上，CTO Sankar 说企业的原子单位是 workflow，不是知识工作者；CEO Karp 在股东信里警告：没有落地的 Agent 是「无限责任」。这套论点对在哪、普通团队怎么照着做——把一条流程落到记录、规则与审批上。
11 月 2 日盘后，Palantir 交出了上市以来最强的一个季度：收入 23.13 亿美元，同比增长 96%；美国商业收入增长 148%，历史上第一次超过美国政府收入；GAAP 净利润 11.28 亿美元；全年收入指引中点一口气上调 9 个百分点。这些数字会被引用一周。但这场电话会真正值得长期引用下去的，不是数字，是论点。
CTO Shyam Sankar 把它说了两遍——一遍在准备好的发言里，一遍在电话会收尾时忍不住又主动补上：
"The atomic unit of the enterprise is not the knowledge worker. It is the workflow."
企业的原子单位不是知识工作者，是工作流。
CEO Alex Karp 在同日晚间发布的股东信里，从另一面写了同一件事：大模型单独拿出来用，最好的情况价值也有限，更可能的结局是变成 "agents of chaos"——混乱的代理人：
"Lacking a grounding in the means of interfacing with the labyrinth of datasets, people, business units, use cases, and critical safeguards scattered across the modern enterprise, the LLM agent is a virtually unlimited liability, possessing a nearly unbounded destructive potential and a blast radius that tends towards infinity."
没有接进企业那套由数据集、人、业务单元、用例与关键防护交织成的迷宫，一个 LLM 智能体就是一份事实上无限的责任——破坏潜能近乎无界，爆炸半径趋于无穷。
先把立场说清楚：Palantir 卖的正是这两句话所论证的那一层产品，论点带着它自己的商业利益。但它不是口号——它是一组可以拿你自己的 AI 项目逐条对表的判断。下面就逐条对表，然后把「照着做」具体长什么样，落到一个普通团队这周就能动手的工作区里。
原文核心思想：五点，其实是一句
一、单位错了。 Sankar 说，模型实验室默认企业的原子是单个知识工作者，于是整个行业的标准产品变成了「给每个员工配一个助手」。但 "You can make any set of workers more productive and generate no actual ROI"——你能让一群人个个效率更高，同时产生零回报。量人均效率，量的是投入：感觉很好，什么也没结算。他自己留了例外：像编程这类工作，知识工作者本人就是工作流，所以助手在那里的契合是真契合；但对企业里绝大多数工作而言，助手是零件，不是单位。
二、模型单独不成事，它是责任不是资产。 Karp 股东信那段说的就是这个：没有接进数据流、业务流程与防护体系的 Agent，不是「装上就能用的生产力工具」，而是无限责任、爆炸半径趋于无穷。风险不在模型弱，而在它无所连接——不连数据、不连流程、也不连任何人的叫停权。
三、token 层不是价值层。 Karp 在电话会上形容市场对一类做法的态度：假部署公司、倒卖 token 的轻量级公司、把转卖 token 计作自己收入的软件公司——"people are just tired of it"，客户已经腻了。卖的是「动静」，不是结果。客户开始分得清了。
四、野心决定谁拿到价值。 这段同样出自 Sankar：从 AI 里真正拿到价值的客户「目标不是降本这种没劲的事（not something lame like OpEx reduction），是市场支配（market domination）」；反过来，最挣扎的客户恰恰是一门心思降本的。把 AI 硬塞去顶替人（shoehorn it to replacing the human），是「完全错过了这一刻」。降本叙事的问题不只是格局小——它瞄错了靶子：优化的是座位，不是工作本身。
五、钱会蒙眼。 D.A. Davidson 的分析师 Gil Luria 问，怎么说服还没想通的 CEO。Karp 转向投资人本身："What happened on Wall Street is everybody invested in these firms early. It's hard to see the reality when you're getting rich on something that's not actually working the way you think it is."——华尔街这帮人早年投了这些公司，在一个根本没像他们以为的那样转起来的东西上发了财，于是看不清现实了。
五点收敛成一句：AI 的价值在流程里结算——看工作本身有没有被改变，看在客户自己的流程里有没有长出抢不走的东西：运营数据、规则、每一次决定与执行的留痕。模型只是这台机器里可替换的零件，流程才是机器。
示意图——两种可以计量的单位，以及各自结算的是什么。
为什么务实的路线，是从一条流程开始
如果原子单位是流程，那真正要紧的问题就不是「选哪个模型」「买多少个助手席位」，而是：一条流程住在哪里，才能让人和 Agent 一起跑它、并且数得出它的结果？ Busabase 建的就是这块地——不是更大的平台，而是让一条流程有个「家」、而不是飘在某个聊天窗口里的最小一组构件。
流程的状态，活在记录里。 只存在于某个 Agent 会话里的流程，没有任何别人能检查的状态。在 Busabase 里，流程搬运的东西——线索、申请、审阅、交付物——都是 Base 里类型化的记录，有负责人、有状态、有关联。Agent 写的和人读的是同一条记录。Sankar 说价值要「对着流程」产生，这就是让这句话可核查的记账方式：流程的状态和结果，都坐在记录上。
先落地，再谈自治。 Karp 那段「无限责任」列了 Agent 必须接进的东西：数据集、人、业务单元、防护。在 Busabase 里，这些都有地址：Doc 是常驻口径——什么样的线索算合格、公司绝不承诺什么；Skill 是 Agent 必须遵守的方法，作为一等节点和记录住在同一个工作区里，动手前先读；Playbooks 把全部 Skill 和各节点的自定义提示词收成一个目录，Agent 开工前先查——「这件事在这儿怎么做」是查出来的，不是临场编的。
责任是治理问题，治理是机制问题。 Busabase 里 Agent 的每一次写入都走 Change Request：一份带字段级 diff、具名作者和决定记录的提案，合并之后历史还在。权限决定一次写入是当场合入、还是进到某个人的收件箱里等决定；被限制在 changeRequest 级别的凭证只能提案，永远不能自己把修改落下去。流程里的审批步骤是同一思想在流程内部的形态：要紧的那一步，等它的负责人点头。这就是爆炸半径在实践中被关小的样子——不是系统提示词里的一句承诺，而是一个真有人要清的队列。
不是给每个白领配助手。 在同一份记录上，分工是看得见的：人做判断、定优先级、拍板；Agent 做执行、起草、回写。于是 ROI 的问法也变了：不问「大家是不是感觉更快了」，而是问这条流程——进来多少、走完多少、卡在哪一步、谁在解卡。这些数字就长在记录本身上。
务实还在于你不必做的事。 不必推翻现有技术栈：记录层架在你已经在跑的数据库和应用之上——Busabase 自己就跑在 Postgres 上。不必把公司押在一个模型上：Agent 通过 Agent Skill、MCP、OpenAPI、CLI 或 ACP 接进来，底下的模型可以换，记录、规则和历史归你。也不必一上来铺四十条流程：先跑通一条，数得出结果，再把这一轮学到的东西——记成经验、评审过、晋升进 Skill——让下一条流程更便宜。这个复利回路，就是 Palantir 的客户在企业级规模上买的那个东西的不炫技版本。它也是我们上一篇对比文章的落点：Supabase 与 Busabase 最大的区别：记忆和规则这一层。
一条流程，端到端走一遍
把论点放到工作尺度上。场景选销售线索跟进——特意选它，因为它在收入侧，正对第四点。以下是 starter 设计（示例结构）：名称和字段按你自己的管道改。
| 节点类型 | 建议名 | 关键内容 | 用途 |
|---|---|---|---|
| 文件夹 | 线索跟进 | 本流程的全部东西放一处 | 流程的记录、规则与定义有一个家 |
| Base | 线索 | 一条线索一条记录：来源、公司、联系人、状态、负责人、下一步、截止时间 | 流程的状态——每条线索走到哪，人与 Agent 都看得见 |
| Doc | ICP 与话术口径 | 谁合格、谁直接出局、公司怎么说话 | Agent 起草前必须对照的常驻口径 |
| Skill | 线索跟进作业 | 补全方法、首封回复结构、跟进节奏、回写纪律、去重规则（一条线索只建一条记录） | 会复利的那套规矩 |
| Workflow | 新线索跟进 | 把流程画成图，放在它搬运的记录旁边 | 换人、换 Agent，流程都还在 |
跑一遍。 新线索落成一条记录——记录的变化就是流程的启动信号；当前在位的第一版运行时，就是手动启动、或由记录变化触发。Agent 读记录，对照 ICP 口径核公司、补全能核实的信息，按公司口径起草首封回复——草稿写在记录上，不直接发送。负责人在草稿所在的位置审阅、修改或批准；批准之后，Agent 才发送、把发送记回同一条记录、并按跟进节奏建好后续任务记录。所有结果——回复、退信、写明原因的拒绝——都回写同一条线索记录。完成条件很硬：没有任何一条线索能以「无状态、无下一步、无负责人」的状态离开这条流程。信息缺失时 Agent 不编造：记录退回负责人，附一条说明缺什么的任务。
人的那一侧，一条指令就能启动（在你的 Agent 对话里改一改就能用）：
在「线索跟进」文件夹里，把所有停在「新线索」超过一小时的记录拿出来。逐条对照 ICP 与话术口径，起草首封回复，把草稿写在各自的记录上。什么都不要发送。把队列列在这里给我看。我在记录上批准哪一封，你就发哪一封，然后建好跟进任务，并把结果回写到同一条记录。
之后已经上线的部分，如实说。 写这篇时还在成形的那批工作流能力已经上线，强化的正是这一跑：只在字段变成指定值时才触发——已合格的线索再被编辑，不会把流程重跑一遍；定时运行，按编辑者自己的时区算；Webhook 带自定义请求头，要鉴权的系统也能调到；审批步骤的审批人从成员名单里选，不用手打地址。这些都不改变上面的形状——同一条流程，触发更精细而已。而这条流程搬运的公司、联系人、交易，将会获得一层属于它们自己的显式语义定义：本体（Ontology）正在开发、尚未上线，它在你已有的 Base 之上定义对象类型。本篇的论点不依赖它；那是记录层的下一步。
示意图——上面这条流程是一个闭环，不是产品界面。
常见问题
那给员工配 AI 助手就是没用的？ 不是——Sankar 自己给的例外正好说明这一点：当知识工作者本人就是工作流时（比如大量编程工作），助手就是正确的单位，契合度极高。这个论点针对的是企业里绝大多数横跨多人、多系统、多道审批的工作：在那里，助手是流程里的零件，不能替代对流程本身的设计。
要 Palantir 那种预算，才能按流程落地吗？ 这场争论争的是计量单位，不是支票大小。一条流程的家就是记录、常驻规则和有人审的写入——开源版 Busabase 一条命令就能自托管起步，我们的个人数据库指南写了全程。企业级平台把这件事按企业级规模卖；这套纪律本身，从一条流程开始。
先动哪条流程？ 选结果已经能数出来的那条：有明确起止、有具名负责人、而衔接目前靠人肉——在聊天线程、表格和某个人的记忆里完成的那条。如果你现在说不出它的状态存在哪儿，那就是该先给它一个家的那条。
先把一条流程跑通
Karp 的股东信和 Sankar 的论点会被当作修辞引用。把它们当成一张检查表更有用——四个问题，问任何一个 AI 项目，包括建在 Busabase 上的：流程的状态存在哪儿？规则写在哪儿、谁能改？哪些写入要等人、在哪儿留决定？上一跑给下一跑留下了什么？四个都能答的项目，是在原子单位上工作；答不上来的，是在量座位。
本周的务实检验只有一条：能不能指着一条流程说出——它的状态在哪、规矩是谁定的、每一步谁批的、结果记在哪。挑那一条流程，给它一个家，先手动跑一遍，再谈自动化。