Field AI Engineering

摘要

Field AI Engineering（FAE）不是售前演示，也不是单纯模型调参。它更像一套现场工程方法：在真实业务样本里识别任务边界，定位失败来源，建立评估集，把原型结论翻译成生产系统可以执行的约束。

大模型应用失败时，表面问题常常是“回答不稳定”。但现场看下去，根因可能是输入字段缺失、知识版本冲突、工具权限不清、专家规则不一致，或者任务本身不适合自动化。FAE 的价值是把这些问题拆开，而不是全部归因于模型。

FAE 的技术位置

FAE 处在四个角色之间：

角色	关注点	FAE 的交界
解决方案架构	业务场景和系统边界	把场景变成可测任务
应用工程	代码、接口、运行时	定义工具、状态和日志
数据工程	数据源、质量、权限	做数据地图和知识审计
评估工程	指标、样本、回归	建立失败分类和评估集

因此 FAE 的交付物不是一个“看起来能跑”的 demo，而是一组能支撑上线决策的工程资产。

从愿望到任务

“做一个售前方案 Agent”不是任务。FAE 需要把它拆成可观察步骤：

raw customer material
  -> requirement extraction
  -> missing field detection
  -> product capability lookup
  -> similar case retrieval
  -> proposal section drafting
  -> human confirmation
  -> CRM or workspace writeback

每一步都要标注输入、输出、系统依赖、风险等级和验收方式。模型可以参与需求提取和草稿生成，但价格、交付周期、合同承诺等高风险判断必须进入人工确认。

数据地图

现场项目经常低估数据问题。FAE 应该先做 data map，而不是直接写 prompt。

data map:
  source: CRM / ticket / document / meeting note / spreadsheet
  owner: responsible team
  freshness: update frequency and last update
  access: role, project, tenant, customer scope
  quality: missing fields, duplicate records, conflicting versions
  usage: read-only, evidence, writable target, audit source

这张图能回答一个关键问题：模型需要的事实到底在哪里，谁维护，能否被当前用户访问，是否可以写回。

失败分类

一个好原型不应该只展示成功路径。FAE 要主动收集失败样本，并把失败放回正确责任位置。

失败类型	典型现象	修复方向
输入问题	用户材料缺字段、上下文不足	追问、表单化、字段校验
知识问题	没资料、资料过期、资料冲突	知识治理、版本管理
工具问题	参数错、接口超时、写回失败	schema、重试、幂等
权限问题	查不到或越权召回	ACL、scope、metadata
模型问题	忽略约束、误解术语	prompt、few-shot、模型选择
业务问题	专家判断不一致	先统一规则和责任人

这个 taxonomy 能防止项目陷入“继续调 prompt”。如果失败来自知识缺失，换模型只会让错误表达得更顺。

原型应该测量什么

FAE 原型不是产品雏形，而是风险探针。它至少要测四类指标：

task:
  completion_rate, human_edit_distance, missing_field_rate

retrieval:
  correct_source_recall, stale_source_rate, forbidden_source_recall

tool:
  argument_error_rate, timeout_rate, duplicate_write_rate

operation:
  latency_p95, cost_per_task, handoff_rate

其中 human_edit_distance 很重要。如果业务专家每次都要重写输出，Agent 只是把工作从“从零写”变成“改一篇不可靠草稿”。

生产交接契约

从 demo 到 production，中间缺的往往不是模型，而是系统约束。FAE 需要交接一份工程契约：

契约项	需要明确的问题
task boundary	Agent 处理哪些输入，哪些必须拒绝或转人工
identity	Agent 以谁的身份访问数据和工具
state	任务状态保存在哪里，如何恢复
tool policy	哪些只读，哪些写入，哪些需要确认
evaluation	上线前和升级后跑哪些样本
observability	记录哪些 trace、metric 和失败原因

没有这份契约，原型越成功，风险越容易被掩盖。

什么时候应该停止

FAE 也要负责说“不适合继续自动化”。以下情况应暂停：

• 输入长期缺失，且没有团队愿意维护。
• 专家之间没有稳定判断标准。
• 错误不可逆，但流程无法插入审批。
• 任务频率很低，自动化收益低于集成和评估成本。
• 原型依赖工程师手工整理上下文才能成功。

暂停不是失败，而是避免把 AI 工程资源投入无法验收的任务。

参考材料

• AI Engineering, Chip Huyen。
• NIST AI Risk Management Framework：AI 系统风险识别与治理框架。
• OpenAI Agents SDK：Agent loop、tools、guardrails、tracing 等工程抽象。