八到十二个月压缩成数周：AI FDE 如何用「章鱼大脑」重写数据迁移

摘要

数据迁移是 AI 时代最不性感、却最关键的工程——从旧系统（legacy system）迁往新平台时，数据、代码、业务流程与「部落知识」的交织让大型企业常年困在数月乃至数年的周期里。Palantir 架构师 Chad Wallquist 与 Craig Roberts 展示了 AI FDE（AI 驱动的开发工具）如何把这条河上的渡河时间从以周月计压缩到以分钟计。

核心机制是「章鱼大脑」（octopus brain）架构：一个中央上下文大脑统管全局目标，各「触手」智能体并行执行探查数据、编写 PySpark 转换、映射字段、嵌入 LLM 做语言翻译与合规校验等任务，并在执行中互相共享上下文。实测中，系统六分钟内产出迁移方案、几分钟生成带注释的代码、约一小时内由多智能体协作完成整套迁移工件，成本仅约 86 美元。

Palantir 的论点是「既要也要」：迁移不必等数据修好才开始，新老系统可以并行运转、双向同步。当把一次概念验证（PoC）从五个月压到五天，企业真正解锁的不是更快的上线，而是把人力从十万行电子表格中解放出来，让人回到战略决策的位置——这正是通往自主企业（autonomous enterprise）的捷径。

正文

一、最不性感的难题：数据迁移为何卡住整个 AI 时代

许多人把 AI 想象成炫酷的新模型，但 Palantir 架构师 Chad Wallquist 在开场就点破：谈到 AI 时人们最先想到的往往是最不性感的事——数据迁移。Craig Roberts 直言，包括管理这些数据的代码在内，数据迁移是大型企业最挣扎的挑战之一。要从旧系统走向新能力、新运营，必须移动数据、整合数据，并确保作用于数据的代码被正确翻译。

「我还没修好数据，所以做不了 AI」是 Palantir 听到最多的话。但 Roberts 认为这二者可以同时进行：加速迁移，恰恰是为了打开通往「有趣新事物」的大门。他反复强调一个原则——目标永远不该是「我要用 X 系统或 Y 系统」，而应该是「我要把交付效率提升 90%」「让 OTIF（按时足额交付率）上升」或「每周多造几艘船」。所有能力都应服务于这些业务结果。

Chad 用「渡河」比喻这个困境：你在旧系统这一岸，想到达新能力那一岸，中间的垫脚石异常难走。首先，遗留数据大多按 2005 年前后写定的标准存储，从未更新；其次，有一套复杂的旧代码库统治着数据之间的交互关系。更麻烦的是，很多企业的目标不是照搬旧数据，而是借迁移之机把业务标准化——过去二十多年里流程、方法、组织层级、业务角色与职能都已改变，企业希望把所有旧系统拉齐到新的全球战略上。这还没到真正上传数据的阶段，企业就已经开始挣扎：上传时数据看起来不对，究竟是旧系统缺少标准、缺少全球标准、还是旧代码被解读错了、翻译到新系统时出了错？

Chad 补上了最关键的一层：迁移不是「我有代码加一些 SQL」那么简单，还有非结构化数据——电子表格、PDF、图表、业务流程文档，以及存储在人们头脑里、从未被整合成可复用报告的「部落知识」（tribal knowledge）。把非结构化信息与遗留的结构化数据合并，理解现状与目标，这本质上是一个多模态（multimodal）问题，而非单纯的数据库转换问题。因此整个过程必须有人类介入（human in the loop）。

二、章鱼大脑：把一切信息汇入一个上下文

Palantir 认为自己的做法独特之处在于：模型现在既能出色地解读结构化信息，也能解读非结构化信息。一段一小时的系统讲解录音，对 LLM 而言就是极其丰富的信息源——「文档写的是什么、数据里有什么，与业务实际想怎么运作、人们实际怎么用系统，是两回事」。把这些全部汇入同一个上下文，就是「从接触到落地」的最快路径。

为此，会议录音与转录本身也会被当作输入源。Craig 发现，当员工知道自己的输入会被机器利用时，他们非常乐于贡献——「真相其实活在与这些系统朝夕相处的人手里」，让系统基于他们的直接输入变得更好，参与感反而很强。Palantir 以丰富的数据集成能力闻名，几乎能接入任何数据源；现在借助 AI FDE 与 AI 驱动开发，要做的就是把这个循环——解读已有数据、对照新目标推进、再评估——从一周压缩到一分钟。一旦循环变快，「渡河」就快得多。Craig 表示，这让数据迁移的预估周期从「年」变成了「周」。

具体的架构被称为「章鱼大脑」：章鱼有一个中央大脑，每条触手又有自己的局部大脑。中央大脑维持「我从哪里出发、要到哪里去」的全局上下文，然后向各条触手派发任务——「看看数据里有什么值」「把它们映射到我们需要的既有值上」「评估这对业务的影响」。每条触手完成任务后向大脑反馈，经评估再交给下一条触手。多个触手并行、反馈、接力，就能以最快速度逼近最优实现。

一个经典场景是从 SAP ECC 迁往 S4。输入可以是所谓的「业务餐巾纸」（business napkin）——业务专家随手写下的真实需求，比如「必须把物料类型整合成以下几组」；也可以是新合规要求，比如联合国面向全系统财务报告的数据标准——一份 50 页、精确规定报表格式、标准与枚举值的 PDF。把这些目标全部放进大脑，再给出一句提示词：「作为人类，我想看到以下内容，告诉我遗留系统里有哪些可用数据，并确保迁移到 S4 时符合联合国报告要求。」

三、六分钟出方案，几分钟出代码：从勘探到执行

演示中，Craig 把提示词粘贴进 AI FDE，选择 LLM 后即开始。系统先处于勘探模式（exploration mode）——像人类一样浏览每一张可用表、抽样、查看元数据，然后输出一份完整方案：数据应如何流动、应在哪里校验、哪些区域信息不足需要人类介入、以及执行建议。整个过程不到六分钟。在前两分钟内，系统就已列出「这些是你可能需要的表」、识别出自定义系统中的非标准内容、解释受代码约束的字段在变更时会怎样更新、并绘制出表之间的关系。

更进一步的产出是把方案变成真东西：AI 会编写 PySpark 转换（transform）代码，连接被指派的系统，按目标整合数据。每阶段的连接不仅展示实际的行与列，还展示「建了什么、怎么建的、为什么建」的完整上下文。Craig 笑称「我知道这是 AI 写的，因为注释写得特别好」——这有双重价值：人类可以并排核对代码意图与实际实现；后续 AI 也能理解代码的商业意图，基于此做二次判断。通常到第一天或第二天，团队就能获得非常有价值的整合视图。

系统还支持把 LLM 直接嵌入流水线中间。例如企业要进入法国市场，所有物料类型必须翻译成法语——直接在流程中插入一个 LLM，如果翻译后超过目标系统允许的字符数，当场就能发现，而不是六周后才发现，还能即时给出替代译法。若策略临时改成进入德国市场，也无需单独建表、找翻译、改 ETL、再验证——直接在管线内就地完成，几乎即时生效。

映射与评估同样即时。比如企业二十五年来业务变化，采购组需要重新对齐到新的事业部：业务侧可能只有粗略估计，却不清楚某种分配方式下每个采购组会负责多少物料。AI 可以即时生成旭日图（sunburst diagram）展示新旧采购组与物料数量的关系；也可以人工指定新采购组。更重要的是，「应用一个变更时，必须知道它会如何影响其他触手」——你关心采购组的平均物料数量，供应链部门却关心每月可制造件数，改变采购组会冲击他们的策略。这类跨部门评估过去要开两个月的工作组会议，现在大约一分钟内完成，业务专家可以当场确认「这是否解决我的目标、是否支持公司其他部门的目标」，然后立即并入迁移管线。

四、迁移驾驶舱：实时状态、业务模拟与活文档

对不熟悉数据迁移细节、却有重要输入的 SMEs（业务专家），系统提供定制视图。随便问一句「数据迁移目前状态如何」，AI 会同时查看章鱼大脑与各触手的运行情况，给出多角度答案：迁移经理关心「多少比例的数据已通过校验可上传新系统」；业务负责人关心「上线后预估 OTIF 是多少」「制造速率如何」「供应链哪里最薄弱」。仪表盘上呈现迁移评分、关键指标、需要处理的事项、校验压力最大的业务区域，以及可直接执行的改进动作。

系统还能「换帽子」：从数据迁移评估者切换成业务评估者，预演迁移方案对业务的影响。Chad 特别欣赏的一点是「管线建好、把真实数据喂进新世界、在真正落地之前先评估」——比如提前发现哪些零件号需要担忧、新产品的关键零部件供应链能否支撑。AI 还能持续生成优先级报告：当前状态、能否迁入新系统、要立即处理什么。缺什么值，系统会直接指派给对应 SME，形成「完成这次迁移的收件箱」。

文档同样由系统自动维护：每当某个智能体在 AIP 中执行操作，都会生成完整报告——做了什么、链接到实际来源、用到的关键代码。这对迁移管理意味着从开始到结束的实时进度报告；对后续工作意味着丰富上下文——换一个模型或加一道检查时，可以从这里直接问「项目状态如何？这个错误为何发生？」。最终产物是可直接上传新系统的格式：对 SAP 场景，常常是在平台内生成 IDoc，并通过 RFC 调用 API 快速上传到 S4，同时保留完整文档与数据流转的完整可视化，供审计与复盘。

五、从章鱼到章鱼群：智能体编排与五天的奇迹

未来方向是「章鱼生章鱼」：当一条触手复杂到需要成为自己的章鱼时，如何管理这种复杂上下文？Palantir 内部称之为「章鱼群」（octopi / consortium）——把多个章鱼智能体绑在一起。用户可以把架构概览、与客户的对话录音、工作说明书（statement of work）等放入大脑，应用专用 playbook，然后要求「我知道从某些系统做迁移的最佳实践，请启动」。系统判断任务过于复杂，会自动组装多个拥有独立上下文的章鱼智能体协同执行：发现、构建转换管线、在 Ontology（本体）上标准化、编写函数与动作、为用户生成可视化，并把这一切包装成计划，请人类确认后才开始执行。

演示中，约 45 秒内系统就区分出具体任务，五个智能体各自开工；约一小时内，整套流程跑完并产出可用的工件——一个完整的交互式应用，展示映射了什么、如何映射，并允许用户沿途干预。Craig 展示了成本与 token 明细：这套工作约花费 86 美元，相当于顾问工作 15 到 30 分钟的价格。相比系统集成商的报价，这是小数目。这种「智能体与子智能体、任务与工作产物全面透明、彼此共享上下文」的编排，被视为智能体协调（agent orchestration）的未来：提出想法、评估想法的人力成本趋近于零，迁移的整体效率将持续上升。

回到真实世界：Palantir 的人常开玩笑说「第一次约会有点尴尬」，因为他们在概念验证中常常五天之内向客户展示五个月的进展。周一带着奇怪的工具进场，只向 SMEs 要上午两小时、下午一小时做澄清；周二带着追加问题与初始原型回来；周三早上，当客户听到「我们听了你们几天的讨论，做了初步评估，这里有几个想法请过目」时，往往被震撼——他们的输入没有被扔进 PDF 里六个月后再用，而是当场得到反馈。周四快速迭代，周五做总结汇报时，客户会说「我以为五个月才能走到这里，结果五天就到了」，并热情地想要继续。

这正是 Chad 收尾时的论点：从战术走向战略——AI 智能体承担全部战术工作，让人回到业务专家的位置去思考战略，而不是评估十万行的电子表格。迁移的终点从来不只是「迁移完成」，而是更快、更省地抵达新环境，然后去做智能体工作流（agentic workflows）、去构建自主企业——不是三年后，而是一两个月后。