Agent Demo 能跑，为什么离生产上线还很远？
🧑💻 面试官：我们做了个 Agent，输入“查订单并发起退款”，演示时它能完成。下周可以开放给所有用户吗？
🙋♂️ 我：演示成功一次只能证明路径可行。先要知道它在不同订单状态、工具超时、权限不足和重复请求时会怎样。
🧑💻 面试官：加一份系统提示词，要求它谨慎操作，不就好了吗？
🙋♂️ 我：提示词有帮助，但退款权限、金额上限、幂等和人工审批要在执行层实现。模型不能替代业务规则。
🧑💻 面试官：那什么证据能支持灰度上线？
🙋♂️ 我：固定任务集的完成率与风险测试通过，关键动作有 Trace，失败可恢复，成本和时延在预算内，并且能小流量观察、随时关闭或回滚。
Demo 关心“这条路走得通”；生产关心“路走错了谁能拦、断了怎样续、规模变大后还能否守住边界”。
面试速答（60 秒版）
把 Agent 从 Demo 推到生产，我会设四类门槛。第一，目标和安全边界：什么算完成，哪些动作必须禁止或人工确认。第二，执行可靠性：工具超时、重复请求、状态恢复和幂等怎么处理。第三，可观测与评测：保存模型决策和工具结果的 Trace，用固定任务集检查成功率、危险动作、步骤数和成本。第四，发布控制：小流量灰度，监测异常，能停用工具或回滚版本。
例如退款 Agent，模型可以判断用户意图和缺少的信息，但真正执行退款要由后端校验订单归属、可退金额和审批状态。不能因为演示时模型“很听话”，就把退款接口直接交给它。
上线不是把所有风险降为零，而是明确风险在哪里、有谁兜底、出现失败时怎样恢复和止损。
知识点详解：用上线门槛拆开“能跑”和“能用”
第一关：目标与权限边界
Demo 往往只展示一条顺利路径：正确用户、正常订单、工具都可用。生产环境会出现无权订单、超限金额、恶意输入和旧数据。必须把完成条件和禁止动作写成可检查规则。
Agent 决定下一步可以调用什么工具，但工具执行器要根据当前用户重新校验订单归属和操作范围。高风险动作需要确认，敏感工具不应对所有任务开放。
第二关：故障与重复执行
一次退款调用超时，真实结果可能成功也可能失败。若 Agent 直接重试，就可能重复退款。需要操作 ID、幂等机制、状态查询和人工对账路径。长任务还要保存状态，避免刷新页面或进程重启后从头再来。
明确最大执行轮次、时间和费用预算。如果 Agent 一直换工具却没有进展，运行器应终止并交付当前信息，而不是让它无限烧 Token。
第三关：可验证的质量与可观测性
准备覆盖正常、边界和高风险情况的任务集。测“实际完成了什么”，不是只给最后回答打分。Trace 要能还原模型看见了什么、请求了什么工具、工具返回什么、权限为何放行或拒绝。
线上观察任务成功率、危险动作拦截、延迟、成本和人工接管率。若失败只留一句“Agent 出错”，就无法定位，也无法安全迭代。
第四关：灰度、回退与责任归属
先选小范围、低风险任务灰度。每次改模型、提示词或工具接口都跑回归，并保留关闭某个工具或回退旧版本的能力。由谁批准扩大流量、由谁处理异常，也应事先明确。
生产化不是组件堆砌，而是把每一种可预见的失败都放进一个有人负责、能观察、可恢复的流程里。
面试官继续追问
Agent 成功率 95%，可以直接上线吗？
不能只看平均数。如果另外 5% 包含越权退款或重复扣款，就不满足安全门槛。要按风险类型拆开看。
有完整 Trace，就等于系统安全了吗？
不是。Trace 帮助发现和追责；权限校验、审批和幂等必须在执行时生效。
为什么要保留人工接管？
因为有些异常无法由模型可靠判断，比如外部系统状态不明或政策冲突。人工接管是明确的故障处理路径。
面试速记卡
- Demo：证明一条路径能走通。
- 生产：证明多场景、多人和失败情况下仍可控。
- 执行门：权限、审批、幂等和恢复。
- 质量门：固定任务集、Trace、成本与风险指标。
- 发布门：灰度、告警、停用和回滚。
