谁来值班守护 AI？智能体归属的未解危机
内容提要
文章指出，AI智能体投入生产后，关键问题不是选哪个模型，而是谁负责运维。生产级智能体应具备：明确归属团队与升级渠道、默认拒绝的工具白名单、执行步数与调用次数预算、可观测日志与追踪、区分推荐与执行的审批边界、健康检查端点，以及故障时优雅降级、由人工接管的回退路径。目标是明确智能体职责边界，确保凌晨出故障时值班人员知道发生了什么、该怎么做。
延伸解读
归属先于选型：生产智能体的第一道门槛
文章强调，智能体投入生产后，首要问题不是选哪个模型，而是明确谁负责运维。团队常把精力花在提示词、检索和工具上，却忽略生产归属，这会让智能体从可靠服务变成运维风险源。给智能体定义归属团队、服务等级和升级渠道，等于把它从实验脚本提升为有问责主体的生产服务，后续日志、追踪、告警和部署记录都能挂靠同一套元数据。
默认拒绝与执行预算：把失控关进笼子
智能体不应从推理直接跳到行动。文章建议采用显式工具白名单，默认拒绝未授权能力，新增权限必须是刻意工程决策；破坏性操作如重启或部署还需人工审批。同时，每个工作流应设执行步数、模型调用和工具调用上限，且预算要在整个工作流中持续复用，不能每次调用都重置，否则反复调用会绕过限制。授权失败应阻断，预算耗尽应升级人工，而非继续重试。
可观测与优雅降级：凌晨故障时的操作抓手
文章指出，所有者无法运维看不见的系统。至少应记录请求ID、模型名、延迟和成败，并配合分布式追踪与指标，让工程师能从告警追到智能体请求及底层模型和工具调用。健康检查要区分存活与就绪：存活确认进程响应，就绪检查模型提供方等依赖是否可用，便于编排平台判断重启还是暂不接流量。故障时应优雅降级，由人工按标准手册继续处理，而不是让组织离不开AI。
推荐与执行分离：智能体可推理，但不拥有授权
文章提出，企业智能体最有用的模式之一是分离推荐与执行。智能体可以诊断并建议“增大数据库连接池”，但不能因模型生成建议就直接推生产变更。审批边界应让未获人工批准的操作停留在等待状态，批准后才执行。这样智能体拥有推理能力，却不拥有授权；凌晨出问题时，值班人员能清楚智能体做了什么、边界在哪、下一步该找谁。
Q&A
AI智能体上线生产后，最关键的运维问题是什么？
最关键的问题不是选哪个模型，而是谁负责运维。生产级智能体必须有明确的归属团队和升级渠道，确保凌晨出故障时值班人员知道发生了什么、该怎么做。
生产级AI智能体应该具备哪些关键控制措施？
应具备：明确归属团队与升级渠道、默认拒绝的工具白名单、执行步数与调用次数预算、可观测日志与追踪、区分推荐与执行的审批边界、健康检查端点，以及故障时优雅降级、由人工接管的回退路径。
为什么AI智能体的工具调用要采用默认拒绝的白名单机制？
因为智能体能力越大风险越高，默认拒绝可以确保新增能力是经过深思熟虑的工程决策，而不是因为工具恰好可用就自动获得。对于破坏性操作（如重启生产服务、部署代码），还应要求经过认证的人工审批，而非智能体自行判断。
如何防止AI智能体无限执行或消耗过多资源？
为每个生产工作流设置执行预算，限制执行步数、模型调用次数、工具调用次数，最好还包括token消耗。预算应可配置而非硬编码，并且必须在整个工作流中持续生效——创建一次预算并传递给每次调用，避免每次调用重置计数器而绕过限制。
AI智能体故障时应该如何优雅降级？
故障时不应让整个服务失败，而应触发人工接管。例如事件响应智能体不可用时，事件仍应被创建、遥测数据仍可用、标准运行手册被激活、人工工程师继续调查。同时要区分不同故障类型：授权失败应阻止操作，预算耗尽应升级而非重试，临时模型故障则按既定故障处理策略执行。
为什么要把AI智能体的“推荐”和“执行”分开？
因为模型调用成功不代表推荐应该自动执行。智能体可以拥有推理能力，但不应该拥有授权能力。例如智能体可以建议“增加数据库连接池”，但不应仅因模型生成了该建议就推送到生产环境，而应经过风险检查和人工审批。
生产环境中的AI智能体为什么需要健康检查端点？
健康检查端点让编排平台（如Kubernetes）能区分需要重启的应用和暂时无法服务流量的应用。存活检查确认进程是否响应，就绪检查确认依赖（如模型提供商、向量数据库）是否可用，失败时返回503。两者分离有助于平台做出正确的运维决策。
