FDE 前沿部署：驻场时长不是分界线，失败恢复的代码边界才是

FDE 在 2026 年成为 AI 交付的焦点，但它同时面临一个尖锐的质疑：如果驻场队伍越来越大、客户离开这批人就无法运行，FDE 只是给传统外包换了一个更昂贵的名字。OpenAI 以超过 40 亿美元成立 Deployment Company 并打包收购 150 名 FDE，联想用 FDE 模式在三个月内交付两个智能体、使客户成品库存降低 70%，这些成绩是真实的，但它们并不自动证明“驻场”本身创造了价值。前沿部署的专业分界线，不在于工程师在客户现场出现了多少天，而在于交付物是否在代码层面强制了幂等、回退和可观测，以及客户团队在 FDE 离场后能否独立诊断闭环的失败。

前沿部署的工程对象：不是“功能”，是一段带失败恢复的生产路径

Palantir 将 FDE 定义为“一个客户，调用多种能力”，成败看对客户目标的实际影响；OpenAI FDE 的北极星则是“必须带着产品离开”。这里的“产品”如果被理解为功能清单，FDE 就会滑向定制开发。General Mills 的供应链系统提供了一个正确的样本：每天检查约 3000 份订单，提供约 400 条调整建议，超过 70% 被工作人员接受，每天节省约 4 万美元。这个系统的工程实质不是“模型能给出建议”，而是建议在什么条件下被允许进入执行、在什么条件下必须退回人工、执行后如何撤销。FDE 在前沿部署中写的生产代码，必须把这三个判断固化为可被机械检查的边界，而不是留给现场的即兴解释。

代码即边界：幂等键绑定业务意图，回退动作预置在响应里

以下 FastAPI 端点将“供应链异常处置建议”封装为可调用的生产服务。它与普通 Demo 的关键区别在于：幂等键由来源系统、对象、异常类型和业务时间窗口共同构成，重复投递不会产生第二张工单；回退动作作为响应字段预先定义，而不是事故发生后临时编写；人工确认字段是契约的一部分，模型无权绕过。

from fastapi import FastAPI, Header, HTTPException
from pydantic import BaseModel
import hashlib, uuid

app = FastAPI()
LEDGER: dict[str, dict] = {}

class Disruption(BaseModel):
    source: str          # 来源系统，如 "wms-shanghai"
    object_id: str       # 物料/批次/订单号
    exception_type: str  # 缺料、运力中断等
    window: str          # 业务时间窗口，如 "2026-10-27-PM"
    severity: float

def idempotency_key(d: Disruption) -> str:
    raw = f"{d.source}|{d.object_id}|{d.exception_type}|{d.window}"
    return hashlib.sha256(raw.encode()).hexdigest()

@app.post("/disposition")
def disposition(d: Disruption, x_request_id: str = Header(...)):
    key = idempotency_key(d)
    if key in LEDGER:
        return {**LEDGER[key], "replayed": True}

    action = _evaluate(d)  # 确定性规则/评分，不在此处调用 LLM
    result = {
        "decision_id": key,
        "recommended_action": action,   # 如 "reroute" / "hold"
        "human_confirm_required": True,
        "rollback": {
            "action": "void_disposition",
            "endpoint": f"/disposition/{key}/void",
            "reason": "操作未生效或业务方否决时使用"
        },
    }
    LEDGER[key] = result
    return result

@app.post("/disposition/{key}/void")
def void_disposition(key: str):
    if key not in LEDGER:
        raise HTTPException(404)
    LEDGER[key]["voided"] = True
    return {"status": "voided", "key": key}

idempotency_key 覆盖了“同一异常在重试中只对应一个决策”这一业务语义，而不是简单地用 request_id 做去重。rollback 字段把撤销路径写进了契约：任何调用方在拿到建议的同时就知道如何回退，不需要在故障发生后才去翻文档。human_confirm_required 不是提示，而是对模型权限的硬约束：建议可以生成，但改变 WMS/ERP 状态的动作必须经过人工闸门。

离场条件：客户能独立跑通“注入异常—定位—回退”

FDE 撤场后闭环失效的典型场景，不是系统崩溃，而是上游字段变了没人知道要同步改，模型漂移了没人重训，一线班组因为三次错误分派就永久绕开了系统。因此前沿部署的验收标准不能是“系统上线”，而必须是客户团队在 FDE 不在场时，独立完成一次完整的失败恢复演练：人为注入一个契约字段的语义变更，观察告警是否触发，定位到具体是数据契约还是工具契约的边界被突破，执行预置的回退动作，并将系统恢复到可用状态。演练记录归档为交付证据。没有通过这一门禁，驻场时间再长，闭环仍然依附于 FDE 的个人在场，而不是客户的运营系统。

FDE 前沿部署的真正门槛，不是谁更愿意待在客户现场，而是谁能在代码中写下可被机械执行的失败恢复边界，并把“客户能独立诊断失败”作为交付完成的条件。当幂等键绑定了业务意图、回退动作预置在响应里、离场演练替代了上线演示，前沿部署才从位置叙事变成一条可验证、可移交的工程能力。