企业级 AI Agent 生产落地参考架构：从 DoorDash、Shippy 拆出的 5 条可复制工程模式

TL;DR（先给答案）：企业级 agent 怎么上生产环境?难点不在选哪个模型,而在模型外围的 5 件工程事——① 用确定性工具包住不确定的模型;② 编排与业务解耦的 MCP 层;③ 分层记忆;④ 评估 agent 而非评估模型;⑤ 领域团队 × 平台团队的 FDE 式分工。下面用 DoorDash「Ask DoorDash」与 Allen Institute 的 Shippy 两个一手生产案例,把这 5 条逐一拆开。

把一个 agent 在 demo 里跑通,和把它送进每天服务真实用户、真实交易的生产环境,是两件难度差一个数量级的事。过去一年我们已经写过不少「为什么 AI agent 会在生产环境失败」这类文章;这一篇不谈「为什么难」,只谈「照着做的蓝图」——把本周两个刚公开、都自带公司名与硬数字的生产案例,拆成可复制的工程模式。

两个案例互不相干,却指向同一个结论:决定 agent 能不能上生产的,不是模型本身,而是模型外围那一圈确定性的工程。 DoorDash 用转化率数字证明这些投入直接变现;Shippy 则把「为什么这么做」讲得极其干净。

生产环境的 AI agent 架构长什么样?(demo 级 vs 生产级)

一句话定义:生产级 agent 架构,是把一个不确定的语言模型,包在一圈确定的、可测试、可审计的工程组件里——工具、编排层、记忆、评估、隔离,一样都不能少。 demo 之所以是 demo,恰恰因为它省掉了这一圈。

下面这张表把差距量化落地。每一行的「生产级」列,都由 DoorDash 或 Shippy 的真实做法支撑:

维度	Demo 级 agent	生产级 agent
工具调用	让模型直接拼 API 调用	专建确定性 CLI/工具(处理鉴权/翻页/结构化输出)
架构	提示词里塞业务逻辑	编排与业务解耦,业务能力走共享 MCP 层
记忆	单轮上下文 / 无记忆	分层记忆(长期/会话/代理)+ 语义检索注入
评估	人工抽查、跑一次看感觉	自动化评估框架,评「被测确切版本 + 真实数据」
隔离/安全	共享上下文	按用户临时沙箱隔离、护栏写进系统提示(可审计)
组织	一个人 / 一个模型搞定	领域团队建 agent × 平台团队维护编排/工具/记忆/评估

DoorDash 的「Ask DoorDash」正是这张表右列的样板:它把一个对话式购物助手做到了生鲜杂货结账转化率 +约 24%、购物车规模 +17%、对话轮次 −7%,餐厅搜索的开放式查询转化率 +15%(据 InfoQ 报道)。这些数字不是模型换了个更大的版本换来的,而是右列那一整套工程堆出来的。

怎么让不确定的 agent 变得可靠?——给它确定性的工具

生产级 agent 的第一条范式,Shippy(Allen Institute 与 Skylight 合作的海事监测 agent)讲得最直白。Hugging Face 上的这篇工程博客有一句话值得贴在每个团队的墙上:

"Agents are nondeterministic. You can't control what the model decides to do, but you can make the tools it reaches for predictable." (agent 是非确定性的。你控制不了模型决定做什么,但你可以让它伸手去够的那些工具变得可预测。)

Shippy 早期让模型直接去拼原始 API 调用,结果是「a steady stream of subtle bugs」——翻页错误静默丢数据、几何编码出错、看起来正确却返回了错误数据。这类 bug 最危险的地方在于它们不报错、不崩溃,只是悄悄给出错的答案。团队的解法是:不让模型碰原始 API,而是给它一个专门构建的 CLI,由这个 CLI 统一处理鉴权、翻页、结构化输出。模型的不确定性还在,但它能触到的每一个动作都变确定了。Shippy 把这套分层架构总结为一句「Each layer narrows what the next layer can get wrong.」(每一层都收窄下一层可能出错的空间。)

DoorDash 走的是同一条路的另一种形态:编排与业务功能彻底分离。助手运行时只负责编排各个专用 agent,而商品搜索、推荐、购物车、结账、订单历史、用户记忆这些业务能力,统一由一个共享 MCP 层提供——业务逻辑不写进提示词,而是做成可复用的工具被调用。连版本化的资源更新,DoorDash 都用**确定性操作(无需调用 LLM)**来完成。能用确定性代码解决的,就不交给模型去猜。

agent 怎么记住上下文而不失控?——分层记忆 + 确定性操作

有状态是生产级 agent 和一次性 demo 的分水岭,但「记住一切」不等于「把所有历史一股脑塞进提示词」。DoorDash 的做法是三层记忆:长期离线记忆、会话记忆、代理记忆,三者经语义向量检索排序后,只把相关的部分注入当前提示。

这套记忆系统的价值不是抽象的「体验更好」,而是可以直接换算成数字:正是这套计算型消费者记忆,带来了前面提到的生鲜杂货结账转化率 +约 24%、购物车规模 +17%、对话轮次 −7%。联合创始人 Andy Fang 的说法很具体:「Ask DoorDash 生成购物车比手动快约 5 倍,一条提示 2 分钟内完成。」

关键原则依旧是那条:能不调 LLM 就不调。记忆的检索、排序、版本化更新尽量走确定性操作,把语言模型的算力留给真正需要推理的环节。这既省成本,也把「模型出错」的暴露面压到最小。

怎么评估一个 AI agent 好不好用?——评估 agent,而非评估模型

这是整篇最该反复读的一节。大多数团队评的是「模型」——跑几个基准、看几条 case,凭感觉判断好坏。生产级团队评的是**「agent」**:被测的那个确切版本、在真实数据上、跑出来的真实行为。

DoorDash 把这件事做成了工业级流水线:规模达到每日 >2000 次自动评估,由此把质量评分提升 8 分、回归测试从 6 小时缩短到 20 分钟;一次模型迁移在质量不变的前提下延迟降低 35%。评估不是上线前的一道关卡,而是能天天跑、快速迭代的基础设施。DoorDash 推荐系统与搜索负责人 Raghav Saboo 的一句话点破了为什么值得投入:

「构建一个有用的 AI 助手很难。而判断它是否真正优秀,则更难。」

Shippy 把方法论补齐了:它明确提出**「评估 agent,而非评估模型」,用 Harbor 框架加上专家设定的加权 rubric,对被测的确切版本、真实数据**执行评估。这套评估揪出来的问题非常真实——agent 越界给出战术建议、把边界简化导致漏检,甚至「发明了一个根本不存在的 CLI 命令」。这些都是纯看模型基准永远发现不了、只有评估「这一个具体 agent」才会暴露的问题。想更系统地把评估与可观测接起来,可参考我们的生产级 agent 可靠性与可观测性与agent 可观测、审计与评估两篇。

团队要怎么组织,才能把 agent 送上生产?——FDE × 平台分工

架构和评估都到位了,还有最后一块常被忽略的拼图:组织怎么分工。 agent 上生产不是一个人、一个模型能扛下来的事。

DoorDash 的分工很清晰:领域团队负责建各自的专用 agent,平台团队维护编排、MCP 工具、记忆、评估与共享组件。 领域团队懂业务、离用户近;平台团队沉淀可复用的地基。两边各司其职,新 agent 才能快速、安全地长出来。

Shippy 从工程侧印证了同一套分层思路。它把一个 agent 拆成三段可独立管理的组成:Soul(系统提示,定义 persona 与行为边界)+ Skills(带 frontmatter 的 markdown,版本化、可审计)+ Config(模型、harness 等运行时设置)。安全上,它按用户临时沙箱隔离——每个用户在独立的 Kubernetes 会话里与 Shippy 交互,用户 JWT 在开通时注入,使 API 调用被死死限定在该用户的数据范围内,因此能同时服务 70 个国家、300+ 合作方而互不串数据。护栏也不是靠 fine-tuning 隐式塞进模型,而是显式写在系统提示里,用 Shippy 自己的话说「…makes them auditable and easy to revise」(可审计、易修订)——例如它会拒绝做法律判定:「that is a determination for people, not an agent.」(那是该由人、而非 agent 来下的结论。)

这套「领域 × 平台」的分工,正是 6AM 一直在做的事:让 FDE(Forward Deployed Engineer)把 AI 真正长进企业的业务流程里——领域侧贴着业务建 agent,平台侧维护那一圈确定性的工程地基。我们不吹这套方法有多神,上面 DoorDash 与 Shippy 的数字就是最好的背书。

生产级 agent 落地清单(可照抄的蓝图)

把上面 5 条模式收敛成一份可勾选的 checklist——照着逐项打钩,就是一份从 demo 到生产的迁移路线图:

• 确定性工具:模型不碰原始 API,统一走专建 CLI/工具,由工具处理鉴权、翻页、结构化输出。
• MCP 解耦:编排与业务分离,业务能力做成共享 MCP 层的可复用工具,业务逻辑不写进提示词。
• 分层记忆:长期 / 会话 / 代理三层记忆,语义检索排序后按需注入;能用确定性操作就不调 LLM。
• 评估闭环:自动化评估被测的确切版本 + 真实数据 + 加权 rubric,做到能天天跑、可回归。
• 按用户隔离:临时沙箱 + 身份令牌注入,把每个会话的数据边界钉死。
• 护栏写进系统提示:行为边界显式声明、可审计、可修订,而非隐式 fine-tune。
• FDE × 平台分工:领域团队建 agent,平台团队维护编排 / 工具 / 记忆 / 评估等共享地基。

七项打完钩,你的 agent 就从「demo 里能跑」跨到了「生产里敢跑」。

---

想知道自己团队离这份清单还差几步? 6AM 的 FDE 就是干这个的——把上面这套参考架构,落到你自己的业务流程和数据边界里。欢迎从落地诊断开始,或到常见问题里找更多答案。