一个提示词在演示里表现惊艳，不代表它已经成为产品能力。演示只需要证明“某一次能答对”；生产系统必须证明：输入异常时不会越权，外部依赖失败时能够收敛，模型或提示词变化后质量可比较，结果不完整时界面有明确状态，出事后还能还原一次决策经过。
这篇文章面向已经能调用模型 API、准备把功能接入真实业务的开发者。你需要熟悉 HTTP、异步任务、JSON Schema 和基本的鉴权概念。重点不是某段神奇提示词，而是如何把概率性模型放进确定性软件边界。OpenAI 的从概念到生产路线也把核心逻辑与评测并列为生产 AI 应用的基础，并把结构化输出和工具调用视为连接模型与应用的关键机制。
先改掉一个错误的系统边界
原型通常长这样：接收用户文本，拼接 developer prompt，请求模型，把 output_text 直接回给页面。这个边界把身份、策略、数据、推理、执行和呈现压进了一次调用。只要加入文件检索、退款、写数据库或多轮状态，问题就会同时出现：
- 谁决定用户能调用哪个工具？
- 模型给出的参数合法，是否就等于用户有权限？
- 网络超时后重试，会不会把同一副作用执行两次？
- 答案语言自然但事实错误，哪一层负责发现？
- 模型拒绝、输出截断和工具失败，在 UI 中是不是同一种“报错”？
正确的边界是：模型产生候选决策，应用拥有最终控制权。 模型可以分类、抽取、规划或建议调用；身份认证、权限校验、事务提交、预算上限与审计记录仍由普通程序承担。这个原则既不是对模型能力的否定，也不是额外仪式，而是把非确定性限制在可观察、可撤销的区域。
图 1（1600 × 900）：WEB/SUN 原创 SVG。六层不是六个必须独立部署的服务，而是六种必须能单独推理和测试的职责；证据从执行与体验反向流回评测。
图 2（1600 × 900）：生产架构的编辑式视觉隐喻，不作为技术证据。OpenAI Image Gen × WEB/SUN，2026-07-16；项目内原创生成资产。
第一层：入口不是字符串，而是契约
入口层先完成认证、限流、数据分级和输入归一化，再把一个明确的任务对象交给编排层。不要让“整段请求对象”无选择地进入 prompt。一次客服查询至少应区分：用户原话、可信账户标识、由服务端计算的权限范围、允许使用的数据源，以及本次请求的追踪 ID。
不可信内容只能作为数据存在。OpenAI 的代理安全指南明确提醒，不要把不可信变量插入优先级更高的 developer message；它们应通过 user message 或受约束字段传递。原因很直接：如果外部网页、文档或用户输入被提升为开发者指令，攻击者就获得了本不属于他的控制层级。
入口契约还需要三种限制：字符与文件尺寸上限；内容类型白名单；敏感字段的删除或标记。这里的“删除”要发生在发给模型之前，而不只是日志展示时打码。对无法识别的文件、缺少租户信息的请求或超出业务范围的任务，尽早拒绝比让模型“尽力理解”更便宜，也更容易解释。
第二层：把一次请求写成有终点的状态机
编排层负责状态，而 prompt 只负责当前一步。最小状态机可以包含 received → classified → awaiting_tool → synthesizing → completed，并为每一步设计 failed、cancelled 与 needs_approval 分支。每个状态都要回答四个问题：允许进入的条件是什么，允许调用哪些能力，最多循环几次，失败后保存什么证据。
这一步最容易遗漏的是退出条件。一个“继续调用工具直到完成”的循环没有生产意义；必须同时设置总轮次、单工具次数、总耗时、令牌或费用预算，以及重复调用检测。当模型连续两次提出语义等价的调用，编排器应停止并返回受控失败，而不是期待第三次出现奇迹。
状态也不等于把完整聊天记录无限追加。需要长期保存的是业务事实、用户已确认的决定、工具结果摘要和可恢复的游标；临时措辞可以压缩或丢弃。状态存储策略必须与隐私要求一致，明确哪些内容由应用保存、保存多久、谁能删除。模型供应商的会话能力可以降低传参复杂度，但不能替代你的业务事实库。
第三层：按问题选择能力，不按潮流堆组件
能力层通常包含提示词、检索、结构化输出、模型路由和工具。判断顺序可以很朴素：
- 任务能否用确定性代码完成？能，就不要交给模型。
- 模型只缺输出格式，使用结构化输出，而不是追加十条格式警告。
- 模型缺少最新或私有事实，使用检索；不要指望微调灌入会变化的知识。
- 任务需要读写外部系统，才开放最小工具集。
- 输出风格或稳定行为难以通过提示和示例解决，再评估微调。
OpenAI 的应用开发路线区分了 RAG 与微调：RAG 用于把知识带入上下文，微调更适合调整处理方式和输出行为。这个区分能避免一种昂贵误区——把数据新鲜度问题错误地做成训练问题。
能力选择还应有显式版本。模型标识、developer prompt、工具 Schema、检索索引和后处理规则共同决定行为；只记录“用了哪个模型”不足以复现结果。每次请求的 trace 应引用一份不可变配置快照，但日志不要存储密钥或未经处理的敏感正文。
配置快照还应把“允许变化”和“必须审批的变化”分开。文案示例、温度或路由阈值可以走普通实验；新增写工具、扩大数据范围、取消人工确认则属于能力边界变化，需要安全评审。灰度时按稳定的用户或租户键分桶，保证同一工作流不会在中途切换两套工具契约。出现异常后，回滚的是完整配置组合，而不是只把模型名称改回去。
依赖也要有能力矩阵。检索、模型和某个工具分别不可用时，哪些路径仍然成立？如果没有检索证据，系统可以只回答通用规则；如果写工具离线，可以生成预览但不承诺提交；如果模型不可用，确定性查询仍可返回业务状态。把这些降级写成编排分支，故障时就不必临时让 prompt 猜测该怎么办。
第四层：工具执行必须穿过确定性闸门
工具调用返回的不是命令，而是一份待审核意图。执行器至少依次完成：JSON Schema 校验、领域规则校验、主体对资源的授权、风险等级判断、幂等控制、超时与重试策略，最后才产生副作用。
例如模型提出 refund_order({ orderId, amount })，Schema 只能证明 orderId 与 amount 的形状正确。应用仍要从认证上下文取得操作者身份，重新读取订单归属与可退款余额，判断是否需要人工确认，并用业务幂等键保证重复请求不会二次退款。绝不能让模型提供 userId 或 isAdmin 后就把它当成可信授权事实。
高风险读写默认需要确认。官方代理安全建议强调工具审批和结构化节点之间的数据流；即便做了约束，文档仍明确指出代理可能犯错或受骗。生产设计因此要允许“拒绝执行但继续对话”，而不是把审批拒绝视为系统崩溃。
工具输出也要最小化。模型只需要“退款已创建，状态 pending”，就不应拿到整份支付记录。返回给模型的错误应稳定、可分类，例如 NOT_FOUND、FORBIDDEN、RETRYABLE，同时把堆栈与内部标识留在受保护日志中。
第五层：可观察性回答发生了什么，评测回答这样好不好
普通监控关心延迟、错误率和资源；AI 系统还必须记录输入类型、配置版本、输出状态、工具选择、审批决定、令牌用量，以及用户是否采纳。追踪数据应该通过请求 ID 串起入口、模型响应与每次工具调用，同时遵守最小化采集和保留周期。
但 trace 多并不等于质量可知。评测集要把“好”翻译成可执行判断：分类是否正确，引用是否支持论断，工具与参数是否合适，拒绝是否准确，最终答案是否满足任务。OpenAI 的评测最佳实践建议先定义目标，再收集数据、定义指标、运行比较并持续扩展评测；也提醒避免只凭感觉和过度通用的指标。
评测应沿系统边界分层。结构化抽取可以精确比对字段；工具路由可以检查允许集合和参数；开放式回答更适合明确 rubric、成对比较并用人工样本校准。将所有问题压成一个总分会掩盖回归：总分上涨，可能同时发生“语气更好但越权更多”。发布门禁应分别约束关键维度。
不要等上线才建数据集。先从产品规格写出典型、边界和对抗样本；灰度后再从已获许可、完成脱敏的真实失败中补充。每次改模型、prompt、Schema、检索或工具策略，都跑同一基线并保存差异，而不是只看新版本的几个漂亮例子。
评测结果也需要可操作的归因。为每个失败标记发生层：输入理解、检索召回、工具选择、参数、授权、工具结果解释或最终呈现。若只保留最终答案分数，团队会不断修改 prompt，却无法发现真正问题是索引过期或工具返回字段含糊。分层标签让修复落在正确组件，也能避免用更长提示词遮盖确定性代码缺陷。
第六层：产品体验必须承认结果有多种状态
用户看到的不是 API，而是等待、进度、确认、成功和恢复。流式输出可以降低等待感，却不能把未审查的半句话当成最终事实。涉及结构化数据时，界面应等完整对象通过验证后再提交；涉及工具时，要把“模型正在建议”“等待授权”“外部系统处理中”分开显示。
回退也要按故障类型设计：模型超时时可以重试或切到简化流程；检索为空时明确说明证据不足；工具不可用时保留用户输入并提供稍后重试；安全拒绝则给出可接受的替代路径。不要统一显示“AI 出错了”，那既帮不了用户，也帮不了运维。
生产容量还包括项目与密钥隔离。OpenAI 的生产最佳实践建议安全保存 API key，并按环境隔离项目、规划速率限制、缓存和负载策略。应用侧同样应将开发、预发布、生产的配置与数据分开，防止一次测试误操作真实资源。
一条可执行的上线顺序
不要一次搭完所有“AI 平台”组件。更稳妥的顺序是：
- 固定一个窄任务和明确的非目标，写出输入、输出与拒绝契约。
- 用单次模型调用完成只读闭环，同时建立首批评测样本。
- 为响应、配置和用户反馈增加最小 trace，确保能复现失败类别。
- 引入结构化输出，把解析失败变成显式状态。
- 需要外部数据时先加只读工具，再加最小权限与输出裁剪。
- 只有在审批、幂等、审计与回滚齐备后，开放写操作。
- 在预发布环境跑正常、边界、对抗和依赖故障测试，再小流量灰度。
每一步都有退出条件：质量门禁不过就停，安全边界不清就不开放工具，无法观察就不扩大流量。这种顺序看起来比“先做万能 Agent”保守，但它让每次复杂度增长都对应一个真实需求和一份验证证据。
上线清单还要能由机器和人工共同复核：固定请求夹具证明输入契约，故障注入证明依赖中断能够收敛，审计样本证明一次工具决定可以还原，回滚演练证明配置组合能够整体撤回。把证据链接到同一发布 revision，评审者才能判断这次变化究竟通过了哪些边界，而不是只看到一句“测试完成”。若某项只能人工判断，也应记录评审对象、版本和拒绝理由，避免口头批准成为无法追踪的例外。
失败模式与取舍
最常见的失败不是模型完全不可用，而是系统把概率结果伪装成确定事实：自由文本被直接写库；检索片段没有来源仍被回答；工具参数通过 Schema 后跳过授权；超时重试重复副作用；评测只覆盖正常样本；日志足够详细却泄露隐私。
六层架构也有成本。更多状态与契约会拉长早期开发，人工审批降低自动化程度，严格输出限制表达空间，分层评测需要持续维护。取舍方法不是删除边界，而是按风险决定实现强度：创意草稿可以接受自由文本与轻量抽查；财务、身份、删除和外部发布必须走强授权、确认和审计。
结论
生产 AI 系统的核心并不是让 prompt 变得无限复杂，而是让模型只承担它擅长的判断与生成，让确定性软件掌管身份、权限、状态、副作用和证据。入口契约限制不可信数据，编排状态机保证任务收敛，能力层按问题选择模型与工具，执行层阻断越权，评测层持续比较变化，体验层为失败与确认提供路径。
当这六层都能独立回答“输入是什么、谁做决定、失败怎么办、证据在哪里”，一次模型调用才真正变成可以维护的产品能力。
Sources
- AI app development — Concept to production — OpenAI，访问于 2026-07-16。
- Evaluation best practices — OpenAI，访问于 2026-07-16。
- Safety in building agents — OpenAI，访问于 2026-07-16。
- Production best practices — OpenAI，访问于 2026-07-16。