AI是匹脱缰野马：调用外溢，App如何重构底层归因？

“楼天城:AI是匹脱缰野马”这条热点，表面上是在谈自动驾驶、世界模型和 AI 自我进化，真正刺中开发者和增长团队的地方，却是另一个更现实的问题：当 AI 开始学会调用工具、调用 skills、调用人类，很多业务链路里真正发起动作的主体，已经不再只是“人”。这就是为什么今天讨论自动驾驶，也会落回到 任务流量 ——谁在发起任务、任务从哪来、经过哪些系统、最后又由谁完成。

新闻与环境拆解

楼天城这次谈的，不只是自动驾驶，而是人和 AI 的关系变了

量子位这次专访里，楼天城给出了一个非常强的比喻：现在的 AI 越来越像一匹脱缰野马，而 Harness，也就是“驯马”或“马具”式的驾驭能力，会成为这个时代最关键的能力之一。这个判断之所以引发广泛讨论，不只是因为他说得形象，而是因为它直接对应了当下 AI 的真实变化——AI 不再只是被动回答问题，而是开始会调用工具、调用 skills、调用外部系统，甚至未来连人类都可能成为被调用的一环。

在这个语境下，楼天城谈的早就不是单点模型能力，而是一种新的系统关系：AI 不只是模型，不只是功能，不只是自动驾驶里的一个模块，它开始成为“主导研发”“识别问题”“派发任务”的主动者。对于行业来说，这种变化比单纯的“模型更强了”更重要，因为它意味着开发范式、组织范式和业务链路范式都开始变化。

PonyWorld 2.0 的核心，不是让车更会开，而是让 AI 来教 AI

从材料看，PonyWorld 世界模型 2.0 最核心的突破，不只是世界模型本身，而是人类在研发闭环中的位置发生了变化。早年的模仿学习阶段，整个行业都在收集海量人类驾驶数据，希望系统通过模仿人类来学会开车；但问题很快暴露出来：模仿学习的天花板就是人类本身，而 L4 自动驾驶需要的是远高于“像人一样开”的能力。

小马智行从 2020 年开始转向世界模型，核心思路就是给机器一个比人类经验更大的训练空间。到了世界模型 2.0，这种变化更进一步：不再只是用虚拟环境训练模型，而是让 AI 自己识别问题、自己判断哪里开得不够好、自己提出需要补采什么数据。也就是说，AI 不只是学生，也开始变成医生、裁判和总教练。

这件事之所以关键，在于它彻底改写了开发闭环。原来是人类工程师定义问题、挑选数据、判断模型是否提升；现在则是 AI 主动在闭环中发现精度缺口、发起定向任务，再由人类去执行。这种变化对自动驾驶是革命性的，对整个 AI 工程世界同样如此。

从世界模型 1.0 到 2.0，最大的变化是“谁在驱动组织”

在楼天城的描述里，世界模型 1.0 更像是一个非常高精度的虚拟训练场，它负责还原环境、模拟交互、训练车端模型；但世界模型 2.0 多出来的，是自我诊断和定向进化能力。它不仅能发现问题，还能生成采集任务，让研发、测试和运营围绕它认为重要的精度短板去补数据。

这看起来只是研发效率提升，实际上却意味着“谁在驱动组织”变了。以前是工程师开会决定优先级、靠经验筛选问题、安排采集和优化节奏；而现在的趋势是，AI 根据自己的判断生成需求，人类去完成这些需求。材料里那句“完成 AI 交给你的任务”，看似玩笑，实际上已经非常接近一种新的组织现实。

这也是“AI 是匹脱缰野马”这个说法最值得开发者警惕的地方。问题不只是 AI 越来越强，而是它开始在系统里形成主动性。它不是一个被动能力层，而是开始能发起工作、分配动作、影响节奏。对任何一个做 App、做平台、做工作流的人来说，这都意味着很多旧有的链路假设会失效。

意图层、定向进化和千万公里数据，说明这不是纸上概念

如果只是抽象讨论“AI 主导 AI”，这件事很容易流于概念。真正让楼天城这次观点站得住脚的，是材料里给出了非常多工程层面的支撑。

首先是 Intention，也就是意图层。小马智行没有走“先用语言解释再输出动作”的 VLA 路线，而是试图跳过语言，把传感器数据直接映射为驾驶动作，同时保留一个更接近驾驶本能的中间层——意图。这个意图层不是事后解释，而是训练阶段就和驾驶动作联合学习的原生能力。它的价值在于，可以反向生成大量虚拟意图组合，让系统在更多“现实中收集不到”的高维组合里接受训练。

其次是定向进化。过去车队规模扩大以后，数据会迅速变成“昂贵但低价值”的海量堆积；而世界模型 2.0 的做法是，AI 先发现某个场景下模型置信度下降，再定向生成采集任务，要求团队去指定时间、指定地点采指定类型的数据。这让研发和运营第一次围绕“AI 的精度需求”而运转。

再加上小马智行已经累计了千万公里级多城市纯无人驾驶数据，这件事就不再只是“一个 CTO 的理论判断”，而是一套建立在大规模无人运营、模型迭代和组织闭环上的实践结论。也正因为如此，这次访谈对行业的冲击，并不亚于一次新模型发布。

从新闻到用户路径的归因问题

普通读者会把这条新闻理解成自动驾驶公司对未来研发范式的判断，但如果从 App 开发和增长视角看，真正值得紧张的地方在于：系统中的“发起者”开始变了。

过去我们默认，业务链路里的主语是人。人看见入口、人点击按钮、人触发任务、人安装 App、人完成动作，所以归因系统主要围绕“人物流量”设计。哪怕链路再复杂，大家默认最前面的主体是一个人类用户。

可在“AI 是匹脱缰野马”这个语境里，这个前提开始松动。因为越来越多任务不是人直接点出来的，而是由外部 AI 工作流、Agent、Copilot、世界模型或中间系统先判断、先拆解、先调用，再把执行动作交给人或具体 App。这个时候，表面上还是人在点按钮，实际上前面真正的任务发起权已经转移了。

这正是 任务流量 和传统人物流量的根本区别。人物流量强调的是“谁来了”，任务流量强调的是“什么任务被发起了、由谁发起、带着什么上下文、经过哪些系统、在哪一步完成或失败”。如果后台仍然只看人是否登录、点击或安装，就会错过最前面的 AI 发起层。

而像 PonyWorld 2.0 这种系统给行业的最大提醒，就是未来很多关键动作都可能是“AI 驱动、人类执行”。在这种情况下，如果你没有记录 agent_platform、workflow_id、scene、risk_level、callback_source 这类信息，最后看到的只是一个动作结果，根本解释不了它为什么会发生、由谁决定、是否还能复现。

所以这条新闻真正带来的业务冲击，不是自动驾驶会不会先走到 AGI，而是它提前暴露了一种全行业都可能遇到的归因困境：人还在系统里，但任务已经不完全由人发起了。

工程实践：重构安装归因与全链路归因

用 ChannelCode 先识别“谁在发起任务”

问题：很多团队今天做渠道编号，还是围绕广告、媒介、私域、活动页来做。可在 AI 时代，一个任务真正的发起点，可能不是投放入口，而是某个 Agent、某个自动化工作流、某个系统级 AI 助手，甚至是某个由模型生成的内部采集任务。

做法：这时可以用 渠道编号 ChannelCode 的思路，把“渠道”从人类入口扩展为任务入口。例如，将 ai_agent_entry、workflow_trigger、system_copilot、manual_entry、auto_callback 等入口统一编号，并补充 agent_platform、workflow_id、scene、task_type、risk_level 等字段。这样你统计的就不只是“人从哪来”，而是“任务从哪来”。

带来的好处：团队能把人物流量和任务流量拆开看，区分哪些动作是用户主动触发，哪些是 AI 工作流驱动。对今天越来越复杂的业务系统来说，这种区分不是锦上添花，而是决定你还能不能解释业务结果的底层能力。

用智能传参保住 AI 发起时的上下文

问题：AI 场景里最容易丢失的，不是流量本身，而是上下文。一个任务也许在外部 Agent 里已经走了几步，已经有了明确场景、明确目标、明确风险等级，但一旦跳到 App 安装、激活或内部页面，这些信息很容易断掉。最后系统只看到“有个人进来了”，却不知道他背后带着一个已经被 AI 拆解过的任务。

做法：这时就需要把 智能传参 放到更重要的位置。可以在任务跳转、链接中转、安装首启或深链拉起阶段保留 source_channel、agent_platform、workflow_id、scene、task_type、intent_type 等关键参数，并在首启后受控恢复。具体链路设计上，也可以参考 xinstall 在《智能体分发时代 App 安装传参逻辑的底层重构》中提到的那套思路：不仅记录来源，还要尽可能保留任务语境。

带来的好处：产品和数据团队不只是知道用户从哪里来，而是知道这个用户背后是什么任务、由哪个系统发起、为什么被导向这个页面。这样才能在 AI 驱动的新链路里还原真实业务含义。
注：本文讨论的部分跨 Agent 上下文保留、系统级 AI 入口携参、复杂任务流回传等方向，属于对未来分发生态的前瞻性技术延展与思考，例如任务型入口识别、跨平台拉起、工作流级参数保真等应用方向。不同业务系统和终端环境的实现成熟度并不一致，目前仍需结合具体技术架构评估；如有类似高阶场景需求，可进一步与 Xinstall 团队探讨或定向扩展。

用任务事件图，把 AI 发起和人工执行放到一张图里

问题：传统埋点体系更适合解释“用户看到页面—点击按钮—完成转化”。但在 AI 主导的系统里，很多任务是“AI 先判断—AI 先分配—人类再执行—系统再回传”。如果埋点还停留在页面动作层，你看到的只是一串孤立结果，完全无法还原任务全链路。

做法：数据层需要建立新的任务事件图。建议围绕 trigger、assign、invoke、install、activate、manual_takeover、callback、complete、retry 等节点建模，并纳入 agent_platform、agent_id、workflow_id、channelCode、scene、risk_level、callback_source、completion_mode 等字段。对于多系统流转场景，也可结合《亚马逊 AI 战略升级？多云多 Agent 时代 App 该怎么认清流量真身》和《OpenClaw 引爆智能体分发：AI 个人助理重构 App 参数传参安装范式》中的思路，把任务入口、执行节点和结果回流统一观察。

带来的好处：团队最终看到的不再只是“某个用户完成了动作”，而是“哪个 AI 系统发起了什么任务，这个任务经过了哪些系统，最后是 AI 自主完成还是转交人工完成”。当任务越来越多地由系统发起而非用户直接发起时，这正是 任务流量 的真正价值所在。

这件事和开发 / 增长团队的关系

对开发和架构团队：现在就该给“AI 发起层”留字段

如果你的业务正在接入 Agent、Copilot、自动化工作流或者外部模型系统，那么现在最容易被忽视、以后最难补的，就是“任务发起层”的字段设计。建议优先预留：

• channelCode：统一入口编号
• source_channel：来源渠道
• agent_platform：Agent 平台
• agent_id / workflow_id：任务或工作流标识
• scene：任务场景
• task_type：任务类型
• intent_type：意图类型
• risk_level：风险等级
• callback_source：结果回流来源
• completion_mode：AI完成 / 人工完成 / 混合完成

这些字段短期看像是额外负担，长期看却决定你还能不能解释系统里的复杂动作。

对产品团队：入口定义权不再只属于页面

过去产品经理可以比较自然地把入口理解为 Banner、按钮、搜索、活动页、商店页。但从这条新闻开始，你需要重新接受一个事实：未来很多入口并不长在你的产品页面里，而是长在外部 AI 系统、自动化流程和工作流节点里。

所以产品团队需要先做两件事：

• 重新定义入口，把“页面入口”扩展成“任务入口”。
• 重新设计承接逻辑，让 AI 发起的任务进入 App 后不丢上下文。

对增长团队：别把任务流量误判成普通自然流量

增长负责人最容易掉进的坑，是把 AI 驱动的新链路都归入“自然流量”或“内部流量”。这会让很多真正有价值的来源被埋没，也会让投放、合作和产品迭代方向判断失真。

现在可以做什么：

• 先盘点现在哪些任务已经不是用户手动发起的；
• 再确认这些任务是否带有可识别的来源和上下文；
• 最后单独建立一张任务流量看板，把它和人物流量分开观察。

常见问题（FAQ）

Harness 为什么会被楼天城称为这个时代最关键的能力？

因为 AI 不再只是工具，而是开始具备主动调用、主动拆解任务和一定程度自我演进的能力。楼天城强调 Harness，本质上是在说：未来最稀缺的不是单纯会用 AI 的人，而是能给 AI 建框架、定边界、让它持续发挥并避免失控的人。

PonyWorld 世界模型 2.0 和 1.0 的最大区别是什么？

从这次材料看，1.0 更像一个高精度虚拟训练环境，负责模拟世界、训练车端模型；而 2.0 的关键增量，是自我诊断和定向进化能力。它不只是训练 AI，而是开始判断哪里有问题、该补哪些数据、该如何推动后续优化。

为什么楼天城会说人类驾驶数据的价值正在归零？

因为当 AI 驾驶能力明显超越人类后，人类数据不一定还能提供正向指导，甚至可能把不该学的坏习惯带回来。换句话说，在“AI 比人开得更好”的阶段，人类不再适合继续做最高裁判，系统需要 AI 来驱动进一步进化。

这件事为什么不只是自动驾驶问题？

因为楼天城讲的是一种更普遍的 AI 组织关系：AI 开始从“辅助工具”走向“主动驱动者”。自动驾驶只是最早暴露这种变化的领域之一，但类似问题会出现在 AI coding、企业流程自动化、智能体协作甚至更多业务系统中。

行业动态观察

“楼天城:AI是匹脱缰野马”真正值得行业重视的，不是它提供了一个耸动比喻，而是它揭示了一条已经开始发生的主线：AI 正在从能力层走向组织层、从执行层走向发起层。自动驾驶只是最早把这件事公开讲明白的行业之一，但类似变化一定会逐步扩散到更多软件系统、业务系统和企业工作流里。

对 App 团队和 B 端团队来说，这意味着一个新的窗口期已经打开。过去你关心的是用户从哪来、广告怎么投、安装怎么归因；接下来你必须同时关心任务由谁发起、任务在哪些系统之间流转、AI 在链路中扮演了什么角色。谁能先把人物流量和 任务流量 拆开、看清、还原，谁就更有机会在 AI 主导的新链路里保住入口解释权。而这也正是未来几年最值得尽早补上的底层能力：不是只会接住人，而是能看懂 任务流量 。