AI Agent 基础设施：从 Demo 到生产的 6 层检查表

AI Agent 基础设施，是让 AI 智能体（能理解目标、选择工具并执行多步任务的软件系统）在真实用户、真实权限和真实故障面前仍然可控的一组工程能力。演示版（Demo）只证明一条理想路径能走通；生产系统还要保证 Agent 做错时停得住、查得清、救得回来。

这篇文章把生产能力整理成六层检查表：运行时、工具网关、身份权限、记忆、可观测性与评估、恢复。它不是某家云平台的产品清单，也不是行业唯一分层；你可以用它检查现有 Agent，并按真实风险逐步补齐。

要点速览

• 判断 Agent 能否上生产，先问三件事：失败是否有界、责任是否可追、状态是否可恢复。
• 模型负责理解和选择，真正改变数据的动作应交给受控的确定性执行器。
• 普通日志只能证明请求完成；Agent 还需要结果、工具选择与策略遵循的持续评估。
• 小团队可以从单进程或容器起步，但运行标识、权限边界、失败上限和恢复验证不能省。

如果尚无历史数据，可以先给单任务设一个保守起点：10 分钟超时、20 步上限、1 美元费用上限；上线后再按任务成功率、耗时和费用的真实分布调整。它们不是行业标准，也不是所有任务的推荐值，只是防止首次公开运行没有边界的可修改门槛。

Demo 能跑，为什么还不能叫生产系统？

因为 Demo 验证的是一次成功，生产系统管理的是长期失败。只要 Agent 会调用工具、保存状态或代表用户行动，模型之外的隔离、权限、审计和恢复就会决定它是否可靠。

AWS 的生产迁移实践把会话隔离、跨轮次状态、工具认证、系统补丁和扩缩容列为真实用户到来后必须承担的运维责任。文章还特别说明：运行时只改变 Agent 在哪里运行，不会自动改变它怎样推理。

一个请求返回成功，不代表任务真的成功。比如内容 Agent 调用了发布接口，接口也返回正常，但它选择了错误文章、重复发布了一次，或者引用了过期资料。传统后端看到的是「没有报错」，用户看到的却是事故。Microsoft 的 AI 可观测性指南因此明确指出，在线率和错误率不足以代表 AI 系统的质量与可靠性；还要检查任务结果和行为是否符合预期。

春洋AI用下面三问区分演示版和生产：

1. 失败是否有界？ 一次任务有没有时间、步骤、并发、费用和权限上限？
2. 责任是否可追？ 能不能还原谁发起、哪个版本执行、调用了什么工具、改变了什么？
3. 状态是否可恢复？ 进程退出、工具超时或版本回滚后，能不能从可信位置继续？

💡 通俗讲：模型像数字同事的大脑；生产基础设施是它的办公室、工具柜、门禁卡、工作笔记、质检记录和应急预案。模型再聪明，缺少这些条件也不能稳定经营一项业务。

对话范例：把「接口成功」改成「业务成功」

用户说：「把审核通过的文章发布到网站。」

不安全的 Agent 只要收到发布接口的成功响应，就宣布完成。生产化做法会先核对文章唯一标识、审核状态和发布授权；执行时附带幂等键；完成后读取线上页面，核对标题、标签、图片和结构化数据；任何一项不一致都进入修复或人工接管，而不是继续乐观汇报。

六层 AI Agent 基础设施，一张表先看全局

六层 AI Agent 基础设施是一套故障检查模型：先判断哪类事故无法被当前系统控制，再补对应能力。能力是必答题，具体产品和复杂度可以按阶段选择。

这张表有一个重要顺序：先写通过条件，再选技术。先问「怎样证明这一层有效」，再问「用什么实现」。否则即使装了一堆组件，任务失败后仍可能答不出谁来停、怎样查、从哪里恢复。

四类团队应该从哪一层开始？

第一层：运行时怎样让每次执行有边界？

运行时（Runtime，承载 Agent 进程、资源、会话和生命周期的环境）要把每次任务装进一个可识别、可限制、可重启的边界。最低目标不是无限扩容，而是一个任务失控时不会拖垮其他任务。

最小运行时的六个动作

1. 为每次任务生成唯一运行标识，并贯穿后续模型、工具和日志。
2. 按用户、租户或会话划分隔离边界，禁止共享可变上下文。
3. 设置最长执行时间、最大步骤数、并发数和资源预算。
4. 把必要状态存到进程外，并为关键阶段写检查点（Checkpoint，失败后继续任务的中间存档）。
5. 暴露健康检查，让系统知道进程是可服务、卡住还是需要重启。
6. 为代码、提示词、工具映射和配置记录版本，保留已验证回滚路径。

完成标志不是「容器启动了」，而是你能主动终止一次运行、重启承载进程，再明确得到三种结果之一：从检查点继续、以可解释错误结束、转交人工。若重启后只看到任务消失，这一层就没有通过。

⚠️ 常见踩坑：把生产化等同于 Kubernetes，会先增加部署复杂度，却没有补齐运行标识、状态与失败上限。Microsoft 的大规模 Agent 架构明确列出不适用场景：Agent 很少或流程本来确定时，动态编排的复杂度可能大于收益。

🎯 实战提示词：审查最小运行时

请把我的 Agent 当作一个会卡住、会重试、会被重复提交的生产服务审查。逐项检查运行标识、会话隔离、超时、最大步骤、并发、状态持久化、健康检查和版本回滚。对每项输出当前证据、缺口、最低修复和可验证的通过条件；不要默认推荐 Kubernetes。

第二层：工具网关怎样防止 Agent 乱调用？

工具网关（Gateway，集中发现、身份校验、权限判断、参数校验、限流和记录工具调用的边界）要把「模型想做什么」与「系统允许做什么」分开。即使只有一个工具，也需要这条逻辑边界；它可以先由一段受测代码承担，不等于必须购买独立网关产品。

OWASP 的 Agentic Applications 安全指南建议让网关仲裁工具调用，在入口执行认证、授权、细粒度限流和审计。真正改变状态的动作还要由确定性执行器（deterministic executor，用经过测试的普通代码完成写操作）负责。

Intuit 的容灾 Agent 案例把边界写得很清楚：模型做解释、选择和协调；执行器完成资产解析、准备检查、策略门、变更记录与真实故障切换。模型不持凭据，也没有直连底层执行系统的网络路径。

一次受控工具调用应该经过什么

⚠️ 常见踩坑：只在提示词里写「请谨慎操作」不是权限控制。提示词可以影响模型选择，却不能替代下游的参数校验、授权、幂等和审计。

🎯 实战提示词：建立工具边界

请列出这个 Agent 的全部工具，并按只读、可撤销写入、不可逆写入分级。为每个工具补充允许的调用者、目标资源、参数规则、频率上限、幂等方式、审批条件和执行后核验。任何缺少下游授权或无法核验结果的写操作都标为禁止上线。

第三层：身份与权限怎样做到最小授权？

身份层要让每次行动回答「谁要求、谁执行、以谁的权限访问什么」。身份校验回答「你是谁」，授权回答「你能做什么」。最小权限（least privilege，只给完成任务所需的最少资源、数据和动作权限）不是给 Agent 建一个账号就结束，而是要贯穿到下游系统。

Microsoft 的 Agent 最小权限指南建议把 Agent 当作独立主体，明确所有者、用途、数据和工具范围，并验证权限吊销与停止开关。Google 的 Agent 安全原则也强调明确的人类控制者、受限的 Agent 权力和可观测的行动。

模型不应直接持有数据库或云服务的长期密钥。更稳妥的方式是：执行器按当前请求取得短期凭据，只把必要工具结果返回模型；日志保存凭据标识和权限判断，不保存密钥本身。

高风险动作还要有清晰的停止路径。一个合格的停止开关不仅禁用 Agent 入口，还要让未完成的令牌失效、阻止队列继续消费，并保留正在执行任务的状态，供人工判断回滚或继续。

🎯 实战提示词：做一次权限瘦身

请以用户、Agent、工具、目标资源四段身份链审计当前权限。列出每项权限支持的具体任务，标记共享凭据、长期凭据、通配资源、越权动作和无法快速吊销的环节。给出最小范围替代方案，并设计一个能在演练中验证的停止开关。

第四层：记忆为什么必须有生命周期？

因为记忆既可能丢失，也可能积累成风险。记忆（Memory，Agent 跨步骤或跨会话保存并取回的信息）必须说明属于谁、来自哪里、留多久、何时更新、怎样删除，不能只回答「存在哪个数据库」。数据库解决的是保存位置，生命周期解决的是内容是否还应该存在和被使用。

AWS 的记忆生命周期实践指出，无界累积会让旧上下文继续影响当前回答，降低质量并带来合规风险。资料给出的治理方向包括生存时间（TTL，数据到期失效或删除的规则）、相关性衰减和内容合并，并要求清理后做质量回归。

先把三类东西分开：

• 任务状态：当前做到哪一步、产生了什么、能从哪里继续。
• 会话历史：这次对话中对完成任务有用的上下文。
• 长期记忆：跨会话保留的偏好、事实或工作方法。

只有任务状态几乎是所有多步 Agent 都需要的。长期记忆则要按业务价值决定。

完成标志包括：不同用户的记忆不会互相检索；能删除一个用户的相关记录；过期规则实际运行；清理前后用固定样本验证质量没有越过门槛。

第五层：可观测性为什么还要加持续评估？

可观测性告诉你 Agent 做了什么，持续评估告诉你这些动作是否正确。Agent 可能在没有程序异常的情况下给出貌似合理的错误答案、选择错误工具或陷入循环，所以两者缺一不可。

AWS 的生产调试资料将 Agent 的生产失败分为质量、可靠性和效率问题，并用指标、链路和结构化日志追查每一步。Microsoft 的指南进一步要求把身份、运行标识、检索来源、工具参数、权限和输出纳入记录，同时建立行为基线和质量、安全评估。

跨系统最好使用 OpenTelemetry（统一日志、指标和链路字段的开放标准）。它的生成式 AI 语义约定已经为 Agent 链路、事件、指标与 MCP（让 Agent 统一连接工具和数据的协议）提供分类入口。规范仍在演进，所以生产字段要记录采用的规范版本。

记录也有边界。用户原文、检索文档和工具参数可能含个人信息或密钥；需要先定义允许记录的字段、脱敏、保留期和访问权限，不能把「全量记录」当作默认安全选项。排障价值和泄露风险必须同时计算。

🔍 深入一步：错误率为零而调用步数、token 或执行时长突然升高，可能表示 Agent 正在循环，而不是运行良好。技术告警要与行为基线结合，才能识别这种「没崩溃但没完成」的静默失败。

🎯 实战提示词：设计 Agent 仪表盘

请根据我的 Agent 任务定义最小可观测性方案。分别列出身份、版本、运行链路、工具行为、资源消耗、质量、安全和人工接管字段；为每类字段说明采集位置、脱敏方式、保留期、正常基线、告警条件和事故调查时的关联键。不要只给延迟和错误率。

第六层：怎样让失败可重试、可回滚、可恢复？

恢复要从一次任务内部开始，再扩展到版本、依赖和数据。备份只回答「有没有副本」；恢复还要回答「能否在目标时间内恢复到可接受的数据点」。没有幂等、断点、接管和恢复演练，Agent 仍然会在故障时重复写入或从头制造新问题。

可以按下面的恢复阶梯设计：

1. 有限重试：只重试明确的暂时性错误，并设置次数和时间上限。
2. 幂等（Idempotency，重复请求只产生一次期望效果）：写操作带唯一键，防止超时后的再次提交重复生效。
3. 断点继续：每个阶段保存输入摘要、产物、结果和检查点，恢复时先验证再继续。
4. 降级与熔断：外部依赖异常时暂停调用或切换为只读、草稿、人工处理。
5. 版本回滚：代码、提示词、模型、工具映射和策略都能退到已验证组合。
6. 人工接管：显示当前状态、已发生变化、建议下一步，让人能安全继续或撤销。
7. 异地备份与灾难恢复：数据和配置保存在独立故障域，并实际恢复到新环境验证。

Intuit 的案例值得参考的不是使用了哪个模型，而是原有恢复系统先做准备检查与策略门，再生成执行 ID 和变更记录；Agent 不能绕过这些确定性控制。系统还限制迭代次数，对同一服务的恢复请求排队、去重和熔断。

恢复演练的最小流程

1. 选择一个非生产环境和一种具体故障，例如工具超时、凭据失效或进程中断。
2. 写下期望的停止位置、允许丢失的状态、恢复方式和完成标志。
3. 注入故障，确认任务没有越过权限门、无限重试或重复写入。
4. 按运行档案从检查点继续，或切换人工处理。
5. 从备份恢复关键数据到隔离环境，核对数量、时间、引用资源和可用性。
6. 保存回执，修改失败策略，再用同一场景复测。

⚠️ 常见踩坑：定时生成备份只能证明「有一个对象」，不能证明格式完整、凭据可用、恢复顺序正确。没有恢复验证的备份，应当标记为未经演练。

🎯 实战提示词：生成一次故障演练计划

请为这个 Agent 设计一次无生产副作用的故障演练。选择一个最可能的依赖故障，写出前置隔离、注入方式、预期停止点、幂等检查、人工接管、数据恢复、完成证据和复盘问题。任何会触发真实外发、删除或付款的动作都改为沙箱或只读验证。

小团队应该按什么顺序补齐六层？

小团队应该先补「边界」，再补「平台」。六层问题从第一阶段就要回答，但实现可以从简单文件、容器、数据库约束和少量脚本开始，等真实负载出现再升级。

这条路线避开两个极端：一是把演示版直接公开，把风险交给用户；二是没有用户就先复制大厂架构，把时间耗在尚未出现的问题上。合理标准是：当前风险有控制，升级由证据触发。

15 分钟最小审计卡

拿一个真实任务，写下它的运行 ID、允许调用的工具、最高权限、超时与费用上限、状态保存位置、报警接收人和恢复动作。然后故意让一个工具超时：若系统能停止后续写入、留下可读记录，并从检查点继续或转交人工，这条最小链路才算可验证；只写设计文档不算通过。

实测：这篇文章的 Agent 流水线怎样验收？

这篇文章本身也是一次生产检查。它从春洋AI的 RSS 私人简报中选择第一个候选，建立独立运行标识，先完成关键词与搜索差距判断，再按进阶读者、零基础读者和批评者三种视角检索，关键技术声明回到原始来源核验。

后续每个阶段都有确定输入、版本化产物和完成标志。模型负责选题、综合、写作与评审；关键词取数、文件存在性、图片上传、发布接口、线上探测和备份验证尽量交给脚本或可重复检查。发布授权只覆盖本篇，不自动扩大到 Newsletter 或其他文章。

这里的第一手价值不在于宣称「全自动」，而在于每个阶段都能回答：当前状态是什么、凭什么进入下一步、失败后从哪里继续。最终是否可靠，还要靠后续真实流量、异常与恢复演练持续验证，不能由一次成功发布下结论。

截至 2026 年 9 月 6 日，本次运行从 1 个候选主题开始，复核了 18 个来源网址，其中 16 条关键事实逐项核验；正文再经过 4 类静态检查和多角色动态评审。春洋AI的判断是，可恢复的流水线比一次生成全文更重要，因为真实运营最常见的损失不是少写一段，而是失败后不知道从哪里继续。

常见误区是把脚本成功等同于任务成功，实际运行会发现两者不同。关键区别在于，成功回执只覆盖当前命令；真正的问题在于，文章是否公开可读、标签页是否生成、图片是否能从公网加载、备份是否落到独立存储，都需要下一层读取验证。这也是本文把 QA 和恢复单列成生产能力的原因。

如果你想先了解 Ghost 网站本身如何从本地走向公开环境，可以查看第一篇 Ghost 博客实践；了解春洋AI的内容方向，可访问关于春洋AI和春洋AI首页。

常见问题

AI Agent 基础设施和普通后端基础设施有什么不同？

普通后端主要处理确定性代码的可用性；Agent 基础设施还要约束非确定性的模型判断、工具选择、记忆写入和质量漂移。

一个 Agent 只调用一个工具，也需要独立 Gateway 吗？

不一定需要独立产品，但仍需要一个明确的调用边界，负责参数校验、最小权限、限流、审计和幂等。

小团队必须使用 Kubernetes 才能上生产吗？

不必须。低并发单 Agent 可以先用可重启的容器或托管进程；出现多租户、弹性负载和独立发布需求后再升级编排。

没有长期记忆的 Agent 还需要记忆层吗？

仍需管理任务状态、会话隔离、保留期限和删除能力；只有确有跨会话个性化需求时，才增加长期语义记忆。

为什么不能让模型直接持有数据库或云服务密钥？

模型输入、输出和工具链都可能暴露信息。凭据应由受控执行器按请求注入，并限制资源、数据、动作和有效期。

Agent 可观测性最少要记录哪些字段？

至少记录运行标识、调用者与 Agent 身份、版本、工具和结果状态、耗时、资源消耗、门禁事件及可追溯的来源。

离线评估通过后，生产中为什么还要持续评估？

真实输入、检索内容、工具响应和模型版本都会变化；持续评估用来发现离线样本没有覆盖的质量与安全退化。

备份和容灾有什么区别？

备份只提供数据副本；容灾还包括故障检测、切换、恢复顺序、权限、恢复目标、人工接管和定期演练。

判断 Agent 可以上线的最低标准是什么？

每次运行可识别，危险动作有边界，失败有上限，过程可追查，状态可恢复，而且这些条件已经在非生产环境实际验证。

上线前自检清单

使用方法：每项后面补上「证据链接、负责人、最后验证日期」。没有证据的勾选视为未完成；若某项确实不适用，也要写明原因和重新评估条件。

• [ ] 每次任务都有唯一运行标识，并贯穿模型、工具、日志和产物。
• [ ] 会话或租户隔离已经用两个不同测试身份验证。
• [ ] 时间、步骤、并发、费用和重试都有硬上限。
• [ ] 所有写工具都在白名单中，参数经过类型与业务规则校验。
• [ ] 写操作带幂等键，超时重试不会重复产生副作用。
• [ ] 用户、Agent、工具和资源身份链完整，下游会再次授权。
• [ ] 模型不持有长期管理员密钥，凭据可快速吊销。
• [ ] 状态与记忆按用途分类，具有来源、保留、删除和恢复规则。
• [ ] 日志、指标、链路与结果评估能通过同一运行标识关联。
• [ ] 已建立正常行为基线，并对循环、费用、越权和质量退化告警。
• [ ] 代码、提示词、模型、工具与策略版本可以回滚。
• [ ] 人工接管时能看到已完成步骤、真实变化和安全下一步。
• [ ] 备份位于独立故障域，且已恢复到隔离环境验证。
• [ ] 公开发布、外发、删除、付款和生产变更都有明确门禁。

相关教程

• Agent 记忆为什么必须会忘记？六道生命周期闸门
• 多 Agent 协作：10 个编码 Agent 先崩在哪里？
• 第一篇 Ghost 博客网站：从本地验证到生产发布
• 春洋AI的内容与运营方向
• 春洋AI首页

参考来源

• AWS：Migrate agentic workloads to Amazon Bedrock AgentCore
• AWS：AgentOps operational practices
• AWS：Designing lifecycle policies for AgentCore memory
• AWS：Debugging production agents
• Intuit：Agentic disaster recovery assistant
• Microsoft：Observability for Generative AI and agentic AI systems
• Microsoft：Least privilege for AI agents
• Microsoft：Dynamic AI agents at scale pattern
• Google Cloud：How Google secures AI agents
• OWASP：Securing Agentic Applications Guide
• OpenTelemetry：Generative AI semantic conventions
• NIST：Artificial Intelligence Risk Management Framework—Generative AI Profile

真正的生产化，不是把 Agent 推得更远，而是让每一步自治都落在可验证的边界里。先用这张清单找到最危险的空白，补到能够演练通过，再增加新的工具、权限和用户。