会调 API 不叫 FDE，会搭 Agent 也不叫 FDE：深度聊聊FDE 在 AI 落地中的真正含义

▍摘要

如果把本文里的 FDE 固定解释为 Forward Deployed Engineering，那么它并不只是“会调模型 API 的全栈工程师”，而是一种面向生产落地的交付与工程 operating model：工程师直接嵌入业务团队，围绕真实流程做问题定义、技术选型、系统集成、上线、采用和反馈闭环，并把现场经验再抽象成可复用的平台能力。OpenAI 对 FDE 的官方描述非常明确：其职责是把前沿模型做成生产系统，负责 discovery、技术范围界定、系统设计、构建、生产 rollout，并以采用率、可衡量的工作流影响和 eval 驱动反馈来衡量成功；OpenAI 在 2026 年进一步把这种模式组织化为 Deployment Company。Anthropic 也在与 DXC 的合作中，把“面向客户部署的 forward deployed engineers”扩大到更大规模的企业转型场景。

这也是为什么今天讨论 FDE，不能只谈“Agent 调度”或“RAG 接知识库”。真正的 AI/ML 生产系统同时承受 代码、数据、模型 三条变化轴；Martin Fowler 的 CD4ML 明确指出，机器学习应用必须把 code、data、models 作为可重复发布的工件一起管理，而 Google 经典论文《Hidden Technical Debt in Machine Learning Systems》则提醒我们：ML 系统的大头难度不在模型本身，而在耦合、依赖、反馈回路和不可见技术债。FDE 的核心价值，就是把这些分散的问题收束成一个可交付、可观测、可治理、可扩展的系统。

对技术实践者和工程领导者来说，最稳妥的 FDE 参考栈不是“追最新 Demo”，而是把 状态化 agents、确定性工作流、模型注册与评估、特征/数据层、GitOps、观测、数据契约与安全控制 组合起来：用 LangGraph 或 OpenAI Agents SDK 管理长任务和人工介入；用 Airflow、Prefect 或 Dagster 管理确定性流水线；用 MLflow 管理实验、评估和模型生命周期；用 Feast 管理训练/推理特征一致性；用 KServe 或 BentoML 承担推理服务；用 GitHub Actions + Argo CD 做 CI/CD 与 GitOps；用 OpenTelemetry 统一 traces、metrics、logs；用 dbt contracts 与数据质量检查控制上游漂移。

我的总判断很直接：FDE 不是 AI 团队里的一个“高配职位名称”，而是 AI 组织把模型能力变成长期业务产出的最后一公里系统工程。 在 2026 年，这个岗位的上限已经不是“做个聊天机器人”，而是 重写工作流、重构数据路径、嵌入控制面、量化 ROI，并把现场打法平台化。

▍FDE 的定义与边界

在本文语境下，FDE 关注的是 AI/ML 生产部署，不是传统意义上的 full-stack web 开发，也不是只做数仓与 ETL 的 data engineering。OpenAI 的官方角色描述把 FDE 放在“客户交付”和“核心平台开发”的交叉点：既要跟客户和领域团队贴身协作，又要把现场打法抽象成工具、playbook 和 building blocks；政府场景的 FDE 描述则进一步强调，可观测系统必须覆盖从基础设施到应用的整条链路。

这一定义与 Palantir 的 forward deployed/AI deployment 叙事高度一致。Palantir 在 Baseline 页面中强调，其 AIP 可跨多云、on-prem 和政府网络部署；而 Palantir 的 AI FDE 文档则把权限继承、最小上下文暴露和对现有授权体系的遵守放在核心位置。这意味着 FDE 的“边界”天然穿过应用层，延伸到网络、身份、权限、审计、数据路径与环境隔离。换句话说，只会写 prompt，不会设计权限边界和部署拓扑，不是生产型 FDE；只会做 Kubernetes，不理解业务流程与用户 adoption，也不是完整 FDE。

因此，FDE 更像一个 责任组合，而不是单一技术标签。它至少同时承担五类职责：

其一，业务翻译，把模糊需求收敛成可以部署、可以度量的工作流；

其二，系统设计，决定单 agent、多 agent、RAG、批流混合、在线/离线分工等架构；

其三，平台整合，把模型接到数据、工具、IAM、审批与监控上；

其四，生产运营，做 eval、金丝雀、回滚、告警、容量和成本治理；

其五，能力沉淀，把一次性交付变成组织级模板、SDK、组件和最佳实践。OpenAI 的角色描述、Deployment Company 文章与 FDSWE 页面，实际上都在强调这种“现场信号 → 平台抽象”的正反馈。

如果必须给 engineering leaders 一个最实用的判断标准，我会这样下定义：FDE 是对“高价值 AI 工作流”负最终工程责任的人。 他/她负责的产物不是 demo，而是上线后的稳定系统、可审计的流程、可扩展的运维和持续可提升的指标。

▍架构模式与关键组件

FDE 在 AI/ML 生产里的正确架构观，不是“所有需求都做成 agent”，而是先把系统拆成 控制面 与 执行面。控制面负责计划、路由、策略、评估、版本和人工介入；执行面负责检索、特征读取、模型推理、工具调用和事务落地。LangGraph 把 agent 工作流建模为 graph，并强调长时运行、持久化、故障恢复和 human-in-the-loop；OpenAI Agents SDK 也把 state、results、guardrails、human review 与 tracing 作为运行时一等公民。对生产系统来说，这说明 agent 不再只是“对话循环”，而是一个需要状态机、审计轨迹和审批门控的应用运行时。

与此同时，不能把 agent 层误当成整个平台。确定性数据和模型流程依然需要专门编排器：Airflow 官方把自己定义为面向 batch-oriented workflows 的开发、调度和监控平台；Prefect 强调把 Python 函数直接变成生产数据管道；Dagster 则把“software-defined assets”和 asset checks 放在中心，适合把数据产品和质量检查建模为资产而不是脚本。对 FDE 来说，最常见的混合模式是：用 agent 处理不确定性交互，用 pipeline 处理确定性加工与回填。

数据层也必须分层。Feast 的官方文档明确其目标是为训练和推理提供生产级 feature serving，并通过 online store 支撑低延迟读取；dbt 的 model contracts 则要求输出数据集 shape、字段名和类型与 YAML 定义严格一致，否则构建失败；Great Expectations 与 Dagster asset checks 分别把验证和资产属性测试显式化。对 FDE 而言，这组能力共同解决一个最常见却常被低估的问题：业务团队看到的是“模型答错了”，工程团队真正要查的往往是 schema 变更、特征缺失、freshness 失控或训练/推理不一致。

服务层同样不能只盯模型本体。KServe 把自己定位为统一的 Kubernetes AI 推理平台，并强调云无关、Generative + Predictive AI 同栈、canary deployments、按 token throughput/queue depth/GPU utilization 自动扩缩，以及 Open Inference Protocol；BentoML 则更偏应用开发与 API 暴露，一方面支持 vLLM/OpenAI-compatible endpoints，另一方面也提供 LangGraph、函数调用、多模型组合等示例。一个成熟 FDE 团队通常会在这里做明确分工：KServe 更适合平台团队统一提供推理基座，BentoML 更适合应用团队快速打包 compound AI service。

下面这张图可以把 FDE 生产架构的“最小可用全栈”讲清楚：

这张图反映的不是某一家厂商的产品图，而是 FDE 在生产里反复遇到的关键依赖：代码、数据、模型、工具、权限与观测。它与 CD4ML 对 code/data/model 三轴变化的强调、LangGraph/OpenAI 对状态化 agent 的要求、以及 KServe/Feast/dbt/OTel 对 serving、特征、契约和观测的定义是一致的。

在模式选择上，一个特别容易踩坑的点是“过早多 agent 化”。OpenAI 在讲 Klarna 的公开技术分享里提到，Klarna 的客服系统一个重要经验是：先用单 agent + 强检索/强路由把大量 routines 选准，而不是一开始就搭层层 agent hierarchy；只有当问题天然可分解、工具上下文过宽、或多并行子任务明显增益时，multi-agent 才值得引入。这个经验和 LangGraph 的“低层编排框架”定位很契合：先把图画清楚，再决定要不要增加 agent 数。

▍工程实现、开源栈与工具选择

在工程落地上，我建议把 FDE 的技术决策压缩成三个问题：部署在哪里、状态握在谁手里、发布由谁控制。 如果数据敏感、主权要求高、团队已有 Kubernetes/SRE 能力，那么最稳妥的路径通常是自建 Kubernetes 基座，以 Deployment/HPA 承担无状态服务弹性，用 KServe 暴露统一推理接口，用 Argo CD 做声明式 GitOps 发布。Kubernetes 官方中文文档明确，Deployment 负责声明式更新，HPA 则根据 CPU、内存或自定义指标动态调整副本数；Argo CD 则把自己定义为声明式 GitOps CD 工具，并提供多团队常用的 multi-tenant 安装模式。

如果团队更关注速度而非平台自控，托管式平台通常更快：Amazon SageMaker AI 把训练、定制、推理、治理、观测和 managed MLflow 放到一体化服务中；Azure Machine Learning 提供端到端 ML 生命周期管理、注册表与 MLOps；Google Cloud 在 2026 年把 Vertex AI 演进为 Gemini Enterprise Agent Platform，强调 build、scale、govern、optimize enterprise-grade agents。这里真正的取舍不是“哪个功能最多”，而是 你的团队愿不愿意把 runtime、网络、身份边界和调度控制权交给云平台换更短交付周期。

一个更贴近 FDE 现场现实的第三种路径，是 混合式控制面/数据面：模型或 agent 编排可以在托管或统一控制面上运行，但数据和事务执行留在专网、私有 VPC、on-prem 或政府环境中。Palantir Baseline 关于多云、on-prem、政府网络部署的表述，以及 OpenAI 政府场景 FDE 对 secure, compliant deployments 的强调，都说明了这种组合在现实世界里的必要性。

下面给两个足够“像生产”的最小片段。它们不是照抄官方文档，而是按官方能力边界做的简化改写。

一个用于 KServe 推理发布 的最小 YAML：

yamlapiVersion: serving.kserve.io/v1beta1 kind: InferenceService metadata: name: risk-agent-model spec: predictor: model: modelFormat: name: sklearn storageUri: s3://ml-models/risk-agent/v1/

这个方向来自 KServe 的 InferenceService 与“minutes to production / canary / autoscaling / enterprise-scale ready”设计。真正上生产时，你通常还会补充 traffic split、资源限制、探针、镜像签名与 network policy。

一个用于 dbt 数据契约 的最小 YAML：

yamlmodels:

• name: feature_customer_health_v1 config: contract: enforced: true columns:
  • name: customer_id data_type: string
  • name: churn_risk_score data_type: float

dbt 官方文档明确写到，enforced contract 会强制模型返回的数据集与 YAML 中定义的字段和类型精确匹配；如果不匹配，构建不会通过。这类契约非常适合做 FDE 团队的上线闸门，因为它把“数据结构变化”从隐性线上事故变成显式构建失败。

如果你的应用更像“一个 API 化的 compound AI service”，BentoML 会比上来就铺 KServe 更轻：其官方示例展示了基于 vLLM 的 OpenAI-compatible LLM API，也给出 LangGraph agent、function calling 与 GitHub Actions CI/CD 到 BentoCloud 的模板。这种做法尤其适合 FDE 团队在客户一线快速把模型、工具与业务 API 扎成一个可部署服务。

下面这张表，是我给工程领导者的一个务实选择框架：

平台或组合更适合什么关键能力主要优点主要约束成本信号Amazon SageMaker AI想要尽快拿到“一体化云上 AI 平台”的团队训练、定制、推理、治理、观测、managed MLflow 都在统一服务中。托管程度高，适合快速把 experiment 走到 prod。云绑定更强，复杂网络与跨环境治理要按 AWS 方式组织。官方为按用量计费，并提供 Savings Plans 这类降本选项。Azure Machine Learning已经深度使用 Azure、需要 Registry/MLOps/企业治理的团队端到端 ML 生命周期、模型注册、环境版本化、跨开发/测试/生产注册表。与 Microsoft 企业栈粘合度高，对传统 ML + GenAI 运维都比较顺手。体系较重，平台抽象较多，新团队学习曲线不低。官方说明 Azure ML 本身无额外服务费，但会产生计算、存储、Key Vault、Container Registry、Application Insights 等相关成本。Gemini Enterprise Agent Platform重点是 enterprise agents、Google 生态数据与全球规模部署build、scale、govern、optimize enterprise-grade agents，支持访问大量 foundation models。对 agent 场景叙事最完整，模型/平台/治理一体化明确。2026 年平台命名与产品边界仍在演进，采购前要核清具体能力归属。官方提供 pricing calculator、custom quote，并给新客户试用 credits；整体是典型云上 usage-based 信号。开源自建组合 Kubeflow + KServe + MLflow + Feast + Argo CD + OTel + dbt对可控性、专网、主权、跨云 portability 要求高的团队Kubeflow 做 AI platform foundation；KServe 做推理；MLflow 做实验/注册；Feast 做 features；Argo CD 做 GitOps；OTel 做观测；dbt 做契约。可控性最高，最适合沉淀组织级 FDE 模板。平台工程要求最高，SRE/安全/升级/成本治理必须自己扛。软件许可成本低，但从其部署前提可推知，真实成本主要是 Kubernetes、对象存储、GPU/CPU、日志与团队运维人力。

如果只给一个非常现实的建议：第一阶段别追求“大而全平台统一”，先做一条高价值工作流的最短闭环；第二阶段再把被证明有效的控制面抽象成平台。 这恰恰是 FDE 的工作方式，而不是传统平台团队先造“大一统中台”再去找业务落点。

▍案例与经验教训

• Morgan Stanley

Morgan Stanley 与 OpenAI 的公开案例是理解 FDE 的一个很好的金融业样本。OpenAI 官方页面提到，Morgan Stanley 在部署前对每个 AI use case 都走评估框架，并让专家反馈持续进入改进环；其 AI @ Morgan Stanley Assistant 已被超过 98% 的顾问团队使用，用于内部知识获取与响应支持。更早的 OpenAI 官方案例摘要还提到，其顾问访问知识的覆盖度从 20% 提升到 80%。对金融、医疗、政府这类场景，这个案例最重要的启发不是“用了 GPT‑4”，而是 先有 eval 和 controls，后有大规模 adoption。

• Klarna

Klarna 是 FDE 生产落地里最常被引用、也最容易被误读的案例。OpenAI 官方客户案例写到，Klarna 的 AI assistant 在上线第一个月就完成 230 万次对话，承担了 三分之二 的客服聊天量，约等于 700 名全职坐席 的工作量；客户问题平均解决时长从 11 分钟降到不到 2 分钟，重复咨询下降 25%，并保持与人工相当的满意度。更有价值的是 OpenAI 技术分享里透露的架构经验：Klarna 并不是靠一大堆复杂 agent hierarchy 获胜，而是通过 单 agent + 非常强的 routine retrieval/intent routing，在大量 routines 中把“该走哪条流程”尽量早、尽量准地选出来。这个案例给 FDE 的结论非常清楚：复杂性优先放在路由与流程建模，不要优先放在 agent 数量上。

• Uber

Uber 的 Michelangelo 平台则展示了另一个维度：当 FDE 式交付在多个业务场景中重复成功后，组织最终会把打法平台化。Uber 公开资料显示，Michelangelo 已覆盖 end-to-end ML lifecycle；到 2024 年公开文章时，约有 400 个活跃项目、每月 2 万+ 训练任务、5000+ 生产模型，峰值实时预测达到 1000 万次/秒；到 2025 年关于模型部署安全的文章里，Uber 又披露峰值已超过 1500 万次实时预测/秒，并引入了贯穿生命周期的 health measurement、rollout gates 与 instant rollback。这个案例告诉 FDE 团队两件事：第一，现场交付必须最终沉淀为平台能力；第二，模型上线安全不是发布前最后一次测试，而是从数据和代码工件开始贯穿整个生命周期的自动化 safeguard。

把这三个案例放在一起看，经验几乎可以总结成一句话：Morgan Stanley 告诉你要先把评估和信任建起来，Klarna 告诉你不要把系统过度 agent 化，Uber 告诉你成功案例一定要平台化，否则交付规模一大就会被技术债吞掉。

▍安全、合规与运营风险

FDE 最容易被低估的部分，不是模型能力，而是风险面扩张的速度。NIST AI RMF 把 AI 风险管理分成 Govern、Map、Measure、Manage 四个函数，并强调这是一个面向设计、开发、部署和使用阶段的自愿性框架；NIST 针对生成式 AI 还发布了 GenAI Profile 作为配套资源。对 FDE 团队来说，这意味着安全与合规不能留给上线前的“审查会”，而应该体现在日常工程工件里：版本、日志、审批、测试、回滚、责任归属，都要在开发时就设计进去。

在威胁模型层面，OWASP LLM Top 10 把 prompt injection、insecure output handling、training data poisoning、model DoS、supply chain vulnerabilities、sensitive information disclosure、excessive agency 等问题集中出来；MITRE ATLAS 则把 AI 系统的对抗性战术与技术系统化。对 FDE 的现实含义是：你交付的不再是一个普通 web app，而是一个可能被用户输入、外部文档、插件/工具、模型供应链和长任务代理共同攻击的复合系统。

因此，生产级 FDE 系统一般至少需要六道缓解层。第一道是 权限最小化：工具调用必须收敛到最小作用域，Palantir AI FDE 的文档就强调遵守现有权限模型与按权限暴露上下文。第二道是 审批与人工复核：OpenAI Agents 文档与安全最佳实践都强调 guardrails、human review、moderation 与 adversarial testing。第三道是 harness-level observability：Anthropic 关于 agent sabotage 和 monitoring 的研究指出，长任务 agent 的关键控制点就在 harness/运行包络层，因为所有动作都会经过它，观测和验证也最适合挂在这里。第四道是 供应链完整性：SLSA 的目标就是提升构建完整性与 provenance，降低制品与构建链路被篡改的风险。第五道是 内容与数据防护：Moderation、PII redaction、输出校验、结构化约束都应内建。第六道是 运行时 kill switch：一旦发现异常工具调用、越权读取、错误路由或成本失控，系统必须可暂停、隔离或回滚。

合规层面，全球团队还要面对法规时间轴。EU AI Act 的正式法规为 Regulation (EU) 2024/1689；公开实施时间线资料显示，其于 2024 年 8 月 1 日生效，大部分条款在 2026 年 8 月 2 日 开始适用，不同类别义务再按风险和范围分阶段落地。对在日本、欧洲或跨境业务团队服务的 FDE 来说，这意味着你现在设计的日志、审计、文档、模型清单与职责分界，很可能决定两年后的合规成本。

真正成熟的 FDE 团队，会把这些要求做成工程默认值，而不是“安全同事来问了再补”。这也是为什么我更看好 policy-as-code、contracts-as-code、evals-as-code、deployment-as-code 的体系，而不看好“靠经验和人工 review 扛住一切”的方式。

▍KPI、监控与团队路线图

FDE 的 KPI 不能只看“调用量”或“模型准确率”。更合理的做法，是分成四层：

业务层 看 adoption、完成率、人工替代率、平均处理时长、利润或成本改善；Morgan Stanley 和 Klarna 的公开案例都说明，企业真正关心的是 adoption、工作流影响和单位产出，而不是模型 benchmark。

质量层 看 eval score、人工复核通过率、任务完成率、路由正确率、重试率、变更回归。

系统层 看 latency、traffic、errors、saturation，以及队列长度、GPU 利用率、超时率和 rollback 频率；Google SRE 的“四个黄金信号”仍然是最有效的骨架。

数据层 看 freshness、schema breakage、特征缺失、训练/推理偏差、契约破坏、质量检查通过率。

在监控实现上，OpenTelemetry 已经给了非常明确的方向：可观测性依赖 traces、metrics、logs，Collector 负责接收、处理并导出遥测；OpenAI Agents SDK 则把 model calls、tool calls、handoffs、guardrails 和 custom spans 作为可追踪运行记录；MLflow 也把 observability、evaluation、prompt management 与 model management 放到统一平台里。对 FDE 团队而言，一个实用标准是：任何一次线上任务失败，你都应该能在一个 trace 里看到输入、检索、路由、工具调用、模型响应、人工介入和最终结果。 如果做不到，系统就还没有真正进入生产可维护状态。

进一步说，KPI 必须与发布控制挂钩。Google SRE 的 error budget 思想非常适合 FDE：当关键 SLO 被持续侵蚀时，团队应暂停高风险变更，优先修复稳定性问题；Uber 的安全部署实践则证明，把 health measurement 转成 rollout gates、alerts 和 instant rollback，才能真正兼顾交付速度与生产安全。

下面这张路线图，是我认为大多数团队都能执行的 FDE 推进方式：

这条路线图的依据很直接：OpenAI 对 FDE 的职责定义强调从 discovery 到 stable production；CD4ML 强调小步、安全、可复现地发布 code/data/model；Uber 的实践表明 rollout gates 与自动回滚必须尽早进入生命周期；Anthropic 和 OpenAI 都把 eval/trace 放在 agent 系统可靠性的核心。

团队能力清单方面，我建议至少覆盖以下七项，并且把它们视为 一个团队的组合能力，而不是要求单个人全包：

• 业务建模：能把模糊流程转成可操作的 system boundary 和 KPI。

• Agent 与工作流编排：会区分单 agent、图编排、多 agent、确定性 pipeline。

• 数据与契约治理：会用 contracts、quality checks、freshness 和 lineage 控制上游变化。

• 模型生命周期与评估：会做 registry、dataset lineage、trace-based eval 和回归比较。

• 平台与发布：懂 Kubernetes、GitHub Actions、GitOps、金丝雀、回滚。

• 可观测与 SRE：能围绕 traces/metrics/logs/SLO 设计仪表盘和告警。

• 安全与合规：能把 prompt injection、权限、供应链和审计做成默认控制。

技术附录

技术附录：最小可用片段1. 状态化 Agent 图编排pythonfrom langgraph.graph import StateGraph graph = StateGraph(State) graph.add_node(“retrieve”, retrieve) graph.add_node(“act”, act) graph.add_edge(“retrieve”, “act”)参考：langchain-ai/langgraph 与官方 overview。 2. KServe 推理发布yamlapiVersion: serving.kserve.io/v1beta1 kind: InferenceService spec.predictor.model.storageUri: s3://…参考：kserve/kserve 与 KServe getting started/genai docs。 3. BentoML 暴露 OpenAI-compatible LLM APIpythonclass LLM: def command(self): return [“vllm”, “serve”, model_id]参考：bentoml/BentoVLLM，以及 BentoML 的 vLLM 与 LangGraph 示例。 4. dbt 数据契约yamlconfig: contract: enforced: true columns:

• name: customer_id data_type: string参考：dbt-labs/dbt-core 与 dbt contracts/model contracts 文档。

5. Feast 在线特征读取pythonstore = FeatureStore(repo_path=“.”) features = store.get_online_features(…)参考：feast-dev/feast 与 Feast architecture/online store 文档。
6. OpenTelemetry 统一观测pythonfrom opentelemetry import trace tracer = trace.get_tracer(name) with tracer.start_as_current_span(“agent_run”): …参考：OTel docs 与 Collector 文档；适合把 agent run、tool calls、retrieval、审批一起纳入 trace。
7. GitHub Actions + GitOps 发布yaml# .github/workflows/deploy.yml on: [push] jobs: build-test-deploy参考：GitHub Actions 文档 + Argo CD declarative GitOps。
8. 数据质量门禁python@asset_check(asset=my_table) def no_nulls(…): …参考：dagster-io/dagster 与 Dagster asset checks。

开放问题与说明

FDE 这个词本身仍是一个快速演进中的行业术语，目前最权威的公开来源多来自 OpenAI、Palantir、Anthropic 等官方角色描述、产品文档与客户故事，而不是某个统一学术标准；因此，本文对 FDE 的定义是 基于官方一手资料做的工程综合归纳，重点放在 AI/ML 生产部署，而非所有可能的岗位语义。与此同时，云厂商能力边界与价格页面在 2026 年变化很快，表中的“成本信号”更适合做方向性判断，而不是采购报价依据；Klarna、Morgan Stanley 这类案例也主要来自官方客户故事与公开技术分享，适合提炼架构与治理经验，但不应被当作独立审计报告。

▍主要参考来源

1. https://openai.com/careers/forward-deployed-engineer-%28fde%29-nyc-new-york-city/

2. https://martinfowler.com/articles/cd4ml.html

3. https://docs.langchain.com/oss/python/langgraph/overview?utm_source=chatgpt.com

4. https://openai.com/index/openai-launches-the-deployment-company/

5. https://palantir.com/docs/foundry/ai-fde/overview/

6. https://airflow.apache.org/docs/apache-airflow/stable/index.html

7. https://docs.feast.dev/

8. https://kserve.github.io/website/docs/intro

9. https://forum.openai.com/public/videos/technical-success-office-hours-swam-11-14-2024

10. https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/

11. https://aws.amazon.com/sagemaker/ai/

12. https://openai.com/careers/forward-deployed-engineer-gov-washington-dc/

13. https://docs.getdbt.com/docs/mesh/govern/model-contracts

14. https://docs.bentoml.com/en/latest/examples/vllm.html

15. https://aws.amazon.com/sagemaker/ai/pricing/

16. https://learn.microsoft.com/en-us/azure/machine-learning/overview-what-is-azure-machine-learning?view=azureml-api-2

17. https://azure.microsoft.com/en-us/products/machine-learning

18. https://cloud.google.com/products/gemini-enterprise-agent-platform

19. https://cloud.google.com/blog/products/ai-machine-learning/introducing-gemini-enterprise-agent-platform

20. https://www.kubeflow.org/docs/started/introduction/?utm_source=chatgpt.com

21. https://openai.com/index/morgan-stanley/

22. https://openai.com/index/klarna/

23. https://www.uber.com/us/en/blog/michelangelo-machine-learning-platform/

24. https://www.nist.gov/itl/ai-risk-management-framework

25. https://owasp.org/www-project-top-10-for-large-language-model-applications/

26. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng

27. https://developers.openai.com/cookbook/examples/partners/agentic_governance_guide/agentic_governance_cookbook

28. https://opentelemetry.io/docs/what-is-opentelemetry/?utm_source=chatgpt.com

29. https://sre.google/workbook/error-budget-policy/

30. https://docs.getdbt.com/reference/resource-configs/contract

31. https://mlflow.org/docs/latest/ml/model-registry/

32. https://papers.neurips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems.pdf

33. https://www.uber.com/us/en/blog/from-predictive-to-generative-ai/

34. https://sre.google/sre-book/monitoring-distributed-systems/

35. https://github.com/langchain-ai/langgraph

36. https://github.com/kserve/kserve

37. https://github.com/bentoml/BentoVLLM

38. https://github.com/dbt-labs/dbt-core

39. https://github.com/feast-dev/feast

40. https://docs.github.com/actions/get-started/quickstart

41. https://github.com/dagster-io/dagster