赛潍：如何用 AgentCore Harness 快速构建 AIOps 智能体

摘要：文章讲述生鲜电商赛潍使用 AgentCore 构建 DevOps Agent 的挑战和实践

01一、大型生鲜电商的运维需求

02二、为运维场景优化 Harness

03三、自建 Agent 的常见问题

04四、三个运维场景的落地

05五、总结

一、大型生鲜电商的运维需求

赛潍是北美最大的多元族裔生鲜电商，过去几年一直在高速增长。赛潍的业务覆盖美国主要都会区，需要同时支撑生鲜商品的短保质期特性、区域仓配调度和线上高并发流量。

生鲜电商和普通电商在技术上有一个明显区别：容错窗口极短。一个仓配调度服务异常，会影响当天必须送出的生鲜订单，无法像标准品那样延后处理。这就要求基础设施的问题必须被尽早发现、尽快定位。

在这样的业务节奏下，赛潍的运维团队长期面对三类高频、重复且依赖经验的工作。

第一类是日常巡检。每天需要确认基础设施的运行状态：资源使用是否异常、安全配置是否发生漂移、成本是否有意外波动。

传统做法是靠监控仪表盘加定时脚本。仪表盘的问题在于需要人主动去看，而且看到的是分散的曲线，需要工程师在脑子里做关联；脚本的问题在于只能覆盖预先想到的检查项，一旦出现没写进脚本的异常模式，就会漏掉。此外还有各种告警噪声，当每天收到几十条告警时，真正重要的那条反而容易被忽略。

第二类是问题的根因分析。当某个服务出现响应变慢、错误率上升这类现象时，定位过程通常是这样的：先看监控指标确认现象，再查日志找异常堆栈，然后找到开发，回溯最近的代码部署和配置变更，如果涉及数据库还要找 DBA 来看慢查询。

这个链路要跨好几个系统和团队，每个系统的查询语法和数据组织方式都不一样。即便是资深的运维和开发工程师，也需要多方协同，安排排查，浪费大量时间精力。

第三类是新服务的上线配置。

随着 AI 编程越来越成熟，大部分组织都在「FDE 化」，赛潍也不例外。FDE 全称「Forward Deployed Engineer」，指的是技术人员直接安插到业务部门甚至直接汇报给业务线，使用 AI 编程来快速实现业务诉求。

和以往的业务发需求给技术，技术开发完再反馈给业务不同，FDE 意味着技术不再有自己的规划、日程和考核，完全和业务融为一体。甚至很多业务部门具备初级编程知识的人，已经可以拿手上的 AI 工具进行研发。

这带来了部署节奏的剧变，从原来每年上线几个系统，到现在每天可能都有新的系统要上线、下线，每个都需要申请内部域名，数据访问权限等等。但即便要频繁上线，安全和数据基线扫描之类的流程也不能少。如果还按照之前的方式，那肯定会占用大量运维的人力物力。

如果我们有一个办法，能让系统自己完成日常巡检并主动把值得关注的问题讲清楚，能在工程师提问时自动串联多个数据源给出分析线索，能把新服务上线这类标准流程自动跑完，那么运维团队就可以把精力集中在真正需要判断力的事情上。

二、为运维场景优化 Harness

在 AI 已经很成熟的今天，大家第一个反应，肯定是把上面三类活儿交给 Agent。确实，现在要出一个原型很快，但要让它在生产环境里天天跑，还能让人放心，还需要考虑下面这些具体问题。

Agent 要跑起来需要哪些东西，业界已经有共识。记忆、上下文注入、知识库检索、MCP 和工具调用、执行沙箱等，都已是标配。但之所以大家对这些东西习以为常，毫无感觉，是因为现成的 Harness，比如 Kiro、Claude Code、Codex 等，大部分都已经把这些做好了。

问题是，现成的 Harness 大多是围绕某个具体场景（比如编程）优化的。它们的记忆策略针对代码库的结构特点，上下文注入优先塞相关文件和符号定义，工具集是读写文件、跑测试、执行构建。这套组合用在写代码上很顺，但不一定能推到别的场景。

比如运维巡检，上下文更关注这次适用的安全基线版本、被检查资源的归属团队、历史上这类告警的处理惯例；常用工具是监控查询、配置读取、变更记录检索；需要记住的则包括团队对告警分级的偏好。而做根因分析时，业务系统的业务流程和文档也可能是定位问题的关键线索。在不同任务下，对上下文、工具和记忆的选择各有侧重。

所以，尽管我们可以基于现有的 Harness 做很多事情，但在 AGI 到来之前，要做到真正丝滑、顺畅而省心的使用体验，还是得构建领域专属 Agent。

要解决这个问题，AgentCore Harness 的思路是把这些领域属性都拆成配置项。

instructions 放固定的角色定义和流程规范。
memory 管长期信息的存取，提供 SEMANTIC 语义检索、SUMMARIZATION 摘要、USER_PREFERENCE 用户偏好、EPISODIC 情景记忆四种策略，可以按需组合启用，也支持自定义策略和元数据过滤。我们可以把稳定和提纯的信息放进去（告警分级偏好、处理惯例），会变的信息则让 Agent 通过工具去取（资源配置、当前容量水位）。
tools 声明能调什么，可以挂 Gateway、远程 MCP Server、内联函数，也能用 Browser 和 Code Interpreter。
skills 是一组可复用的指令集合，支持从本地路径、S3 或 Git 加载，也能用 AWS 官方整理的 skills 目录。比如，巡检的操作规范可以放这里，改规范不用改 Agent 配置。

这些部件，其实最终都会变成模型的上下文，这就是所谓的「提示语组装」。使用 AgentCore Harness，组装顺序和格式由托管循环负责，不用自己维护，这样我们就能更关注业务需求。

[图 1：AgentCore Harness 组件总览]

三、自建 Agent 的常见问题

接下来我们来看一些自建 Agent 过程中常见的问题，以及 AgentCore 是如何来应对。

3.1 如何给 Agent 流程排错

巡检 Agent 的提示语里写清楚了 7 个步骤：先拉资源清单，再逐项对安全基线，发现异常就下钻确认，最后汇总成报告。结果某天的报告里，第 3 步的下钻确认根本没做，直接跳到了汇总。

这时候问题来了：是提示语写得不够明确，模型没理解到那一步是必须的？是前一步某个工具返回了一坨异常数据，把模型带偏了？还是这次巡检的资源清单特别长，上下文被压缩的时候把流程要求给挤掉了？

这三种原因的修法完全不同。提示语不明确就改提示语，工具错误修工具返回格式，上下文问题调整上下文策略。要定位问题，我们必须看那次执行的完整交互流：每一轮模型收到的输入是什么、输出了什么、调了哪个工具、工具返回了什么、模型看到返回之后的下一步推理是什么。这就意味着我们不止要保留人能看到的对话，还要能保存底层调用信息。

自己手搓 Agent 的团队在这件事上通常要走一段弯路：先只记工具调用的入参和结果，出问题时发现不够，再补记模型的输入输出，然后发现推理过程也得留，最后还要处理存哪、存多久、怎么按会话检索、敏感字段怎么脱敏。

AgentCore Harness 每次调用自动产生 Trace、日志和指标进 CloudWatch，模型调用、工具调用、记忆读写、命令执行每一步都带时间戳和载荷细节，不需要额外埋点。

开发阶段，我们也可以使用 agentcore dev 起一个本地开发服务器和 Agent Inspector，在浏览器里对话、看 Trace、浏览项目资源，Harness Settings 面板还能临时覆盖当前会话的配置，调提示语的时候更快速便捷。

3.2 Agent 怎么安全使用外部系统和工具

运维 Agent 要碰基础设施，权限是三个场景里风险最高的一环。

这件事有两个方向要分开看：谁能调用这个 Agent，以及 Agent 能调用什么。先说后者，因为它更容易出事。

我们的直觉做法可能是把约束写在提示语里：「你只能读取配置，不允许执行任何修改操作。」这句话在正常情况下有效，但它不可靠。原因在于提示语和工具返回的数据一起进入模型输入，而运维 Agent 读的数据源是半可控的。资源标签、日志内容、主机 banner 里都可能被写入诱导性文本，真发生这种情况，靠提示语划的线就形同虚设。

所以约束得落在代码和配置层面。具体要解决三件事。

第一件是每个后端系统的认证方式都不一样。巡检要读云上的配置，根因分析要查日志平台，新服务上线要调 GitHub 和内部 DNS 服务。这些系统有的用 API Key，有的用 OAuth，有的走 AWS 签名。凭证得有地方存、有地方轮换，而且绝对不能进模型上下文，因为 Agent 的推理内容会写进 Trace，凭证一旦出现在上下文里就等于写进了日志。

第二件是很多操作需要以人的身份进行，而不能以 Agent 自己的身份。工程师让 Agent 去查某个服务的日志，Agent 应该只能看到这位工程师本来就有权限看的那部分。如果 Agent 用一个统一的高权限身份去查，那等于给所有人开了后门。

第三件是范围限制。同一个巡检 Agent，这次只该查某个业务线的资源，下次可能是另一批。这种范围约束需要能在调用时表达，不能只依赖固定的身份配置。

AgentCore Gateway 承担的是 Agent 访问工具这一层的统一安全入口：入站认证控制谁能访问 Gateway，出站认证负责 Gateway 如何访问后端工具。至于谁能调用 Agent 本身，则由 Harness 自身的入站 Authorizer 控制，两处入口需要分别配置。

出去的方向由 Credential Provider 负责。API Key 和 OAuth 凭证存在这里，Gateway 调用后端时自行注入，OAuth 流程和 Token 刷新都由它处理。Lambda 和 Smithy 类型的后端用执行角色调用，OpenAPI 和 MCP Server 类型可以挂凭证提供者、配置 SigV4 签名，或者对公开端点不做授权。模型全程看不到任何凭证内容。

以人的身份调用这件事，Gateway 在 MCP target 层面支持三方 OAuth（3LO）。Harness 向下游传播用户身份需要使用 Bearer JWT 入站认证路径，SigV4 入站不支持这条逐用户身份传播路径。完成用户授权后，Gateway 用这位工程师的授权去访问后端，Agent 能拿到的数据由工程师本人的权限和 OAuth 授权范围共同决定。运维场景里这一点很关键：如果企业既有的授权体系规定值班工程师能查生产日志、实习生只能看脱敏后的部分，后端就按这些规则返回数据。3LO 负责使用用户授权访问后端，脱敏仍由后端的数据处理和授权体系实现。

访问 Gateway 的入站请求由它的 Authorizer 处理。可以用 OAuth（JWT）做基于令牌的授权，也可以用 IAM 做基于 SigV4 签名和 AWS 身份的授权。AUTHENTICATE_ONLY 模式只验证 SigV4 签名，不执行 IAM 授权检查，授权判断仍需通过 AgentCore Policy、interceptor 或后端实现。调用 Agent 本身则走 Harness 的入站认证：定时巡检由调度器触发，用 IAM 服务身份比较合适；工程师从内部平台发起的诊断请求，可以走 OAuth（JWT）。

Gateway 还顺手解决了工具定义占 Token 问题。它对 MCP 支持语义化检索；启用工具搜索后，Agent 可以调用 x_amz_bedrock_agentcore_search，按当前任务搜索出合适的工具，不用把所有工具定义都塞进上下文。这让 Agent 既可以使用数千个工具，又保持提示语精简。

除此之外，Gateway 把 Lambda、API Gateway REST API、OpenAPI 规范、Smithy 模型和远程 MCP Server 都聚合成一个统一的虚拟 MCP Server，客户端看到的是一份合并后的工具列表，存量系统不需要为 Agent 做改造。

对 Salesforce、Slack、Jira、Asana、Zendesk 这类常用系统，官方也提供了一键集成。

[图 2：AgentCore Gateway 安全架构]

3.3 如何让 Agent 随起随跑

现在，我们来说怎么跑 Agent。三个场景的 Agent 运行方式完全不同：巡检定时触发，一天几次；根因分析是工程师提问时跑一次，随机；新服务上线的流程中间要等 DNS 生效、等流水线跑完，单次执行时间长。

如果自己维护常驻服务来跑这些，要处理的问题包括：没有任务时资源是否空占、多个任务并发时怎么隔离、单个任务超时了怎么中断、Agent 陷入循环谁来拦。巡检 Agent 如果因为某个工具持续返回异常而反复重试，可能在无人值守的凌晨跑掉大量 Token，或者对被巡检的系统造成不必要的调用压力。

AgentCore Harness 按调用触发，每个会话运行在独立的 microVM 里，按生命周期配置释放，无需自行维护常驻服务。

我们也可以通过几个参数控制运行：

maxIterations 最大迭代次数
timeoutSeconds 总时长
maxTokens Token 预算
idleRuntimeSessionTimeout 空闲超时
maxLifetime 会话最大生命周期

其中，maxIterations、timeoutSeconds 和 maxTokens 可以在 Harness 上设默认值，也能在单次调用时覆盖。idleRuntimeSessionTimeout 和 maxLifetime 则属于 Harness 的环境生命周期配置。

三个场景可以共用一个 Harness，但为每次调用设置不同的迭代次数、总时长和 Token 预算。默认值是按通用场景给的，巡检这类步骤可预期的任务可以收得更紧，避免异常重试跑掉太多 Token。

如果流程的步骤依赖很强、需要更确定的编排，Harness 也可以作为 AWS Step Functions 里的 InvokeHarness 状态嵌进更大的流水线。新服务上线这类场景，用 Step Functions 管流程骨架、用 Harness 处理需要判断的环节，比让 Agent 自己编排全流程更可控。

3.4 如何验证新版 Agent 的效果

Agent 的提示语调整一版、换个模型、加一个检查工具，这些改动都会影响它的判断。

麻烦的是运维 Agent 的输出质量不容易立刻验证。改完之后第二天的巡检报告看起来正常，但这可能只是因为当天确实没有异常。真正的问题在于，如果那天有一个配置漂移，新版本还能不能发现它。这种「漏报」在当天是看不出来的，要等到出事故才暴露。

所以需要的是能灰度、能对比、能回滚：新版本先在一部分资源范围上跑，和旧版本的结果做比较，确认发现能力没有退化再全量。

AgentCore Harness 支持不可变版本和命名端点，把端点指向早先的版本就能立即回滚。可以让新旧两个版本同时跑在不同端点上，用同一批资源做输入，对比两边的输出差异；确认有问题直接把端点指回旧版本。

这一层 AgentCore 还有两个能力可以接进来。AgentCore Evaluations 接 Agent 的 Trace，用 LLM-as-a-Judge 按评估器打分，支持在线（Online）、按需（On-demand）和批量（Batch）三类评估。此外，公开预览的数据集评估（Dataset evaluation）支持基于测试数据集运行 Agent，其中还包括仿真（simulation）能力。对巡检场景最实用的是数据集评估：把历史上出过问题的资源整理成一份数据集，提示语改完先跑一遍，直接看新版本能不能把这些已知问题都发现出来，不用等第二天的报告。

AgentCore Optimization 在这之上再往前一步：拿真实 Trace 分析失败模式，自动生成改进后的系统提示词和工具描述；把提示词、模型、工具描述打成不可变的配置快照，改行为不用重新部署；A/B 测试通过 Gateway 切流量，逐会话打分并报告统计显著性。

跑、打分、拿建议、A/B 验证、上线或回滚，构成了一个完整的迭代闭环。这相当于把软件测试的一套机制也移植到了 Agent 身上，用 Agent 来提升 Agent。

3.5 如何在任意位置运行 Agent

设计、排错、权限、运行都有了，就要说在哪里运行 Agent 的问题。对于专业程序员来说可能很不可思议，但是我们确实看到现在很多 Agent 是跑在工作机器，甚至个人电脑上的。各种 C 端的 Harness，通过各种奇特的手段，变成了一个临时的后端应用，处理了很多真实的任务。虽然够用，但可能有各种安全隐患。

开发环境与生产环境不同，团队也可能选择不同的托管或自建平台，因此 Harness 需要具备可移植性。

AgentCore Harness 的编排循环由 Strands Agents 驱动。AgentCore 运行一个用 Strands 写的 Agent 程序，我们写的 Harness 配置就是这个程序的运行参数。

AgentCore 也有自己的 CLI，只需执行 agentcore export harness，我们就能把配置导出成完整的 Strands Agent 格式。导出内容包括模型配置、工具（Gateway、远程 MCP、内联函数、Browser、Code Interpreter）、Skills、记忆设置、执行限制、上下文截断策略、文件挂载和授权配置。导出后会生成一份 EXPORT_NOTES.md，列出需要人工跟进的项。

导出的项目可以继续用 AgentCore Runtime 托管，也可以选 Container 构建方式生成 Dockerfile 自行部署。对已经有容器平台的团队，这意味着 Agent 可以方便地纳入现有的部署和运维体系。顺带一提，即使不导出，Harness 本身也支持自带容器来引入自定义依赖。

四、三个运维场景的落地

[图 3：三个运维场景的架构]

4.1 日常巡检：从被动查看到主动汇报

这个场景的架构相对直接：EventBridge Scheduler 按计划触发，调用 Harness 执行巡检任务；Agent 依次调用 Gateway 后面的采集工具，获取基础设施各维度的状态数据；汇总分析后，输出一份巡检报告并推送到团队的协作渠道。

和原有的脚本加告警方案相比，变化主要在输出形态上。脚本产出的是结构化的检查结果列表，需要人去逐条判断哪些重要；Agent 产出的是一段说明，指出今天哪些指标正常、哪些出现了值得关注的变化，以及这些变化之间可能存在的关联。因为有基础逻辑能力，Agent 可以根据提示来选择有意义的问题进行推送，而不是一股脑全部扔给用户。

Harness 在这里提供的主要支撑如下。

每次巡检使用独立会话，多个巡检任务并发时上下文互不干扰
limits 确保单次巡检不会因为某个异常分支无限循环下去
所有工具调用都记录在 CloudWatch 的追踪数据里，事后可以确认 Agent 具体检查了哪些项目

4.2 根因分析：把排查经验固化成工具编排

这个场景的输入是工程师的自然语言描述，比如「某个服务今天下午响应变慢了」。

Agent 的处理过程是：先调用监控工具确认现象的时间范围和影响面，再查询日志系统寻找异常模式，然后检查这段时间内的部署记录和配置变更，如果线索指向数据存储层就继续查询相关指标。

每一步的结果决定下一步查什么。最终输出的是一份带证据链的分析，列出发现的异常现象、时间上的关联性，以及可能的原因方向。历史诊断的上下文被保留下来，当类似问题再次出现时，Agent 也可以参考之前的排查路径。

这个场景的关键工程量在于把内部系统的排查能力安全地暴露给 Agent。日志、指标、变更记录各有自己的接口和权限模型，这部分通过 Gateway 统一成工具之后，Agent 就能像资深工程师那样按线索逐层下钻。往后再走一步，是把巡检发现的问题直接接进根因分析，让告警到诊断形成一条链路。

4.3 新服务上线：标准流程的自动化

这个场景和前两个的性质不同，因为它涉及实际的写操作。

流程是：Agent 依次调用 GitHub API 完成仓库配置、调用 DNS 管理接口配置域名解析、调用 CI/CD 系统建立流水线、触发部署并验证结果。步骤之间有严格的依赖关系，前一步的输出是后一步的输入。

因为涉及写操作，权限约束比前两个场景更严格。通过 Gateway 关联的 AgentCore Policy、interceptor 或后端授权，限定 Agent 只能操作预先授权范围内的资源；涉及生产环境的部署动作需要人工审批环节，Agent 只负责把准备工作做到位。

这个场景展示的是 Agent 从「查询和分析」到「执行流程」的延伸。等待 DNS 生效、按固定策略重试，传统流水线或 Step Functions 本来就能处理。Agent 更适合参与需要结合现场信息判断的环节，比如根据 DNS 查询结果、配置内容和工具返回的错误，判断是继续等待，还是转去检查配置，并给出相应证据。确定性的步骤依赖和重试策略仍可交给流水线。

五、总结

大语言模型已经发展数年。前沿模型驱动的 Agent 能力强大，处理巡检数据关联、日志异常识别、多源信息串联这类任务已经足够。真正决定 Agent 能否进入生产的是另一组问题：状态由谁管理，权限如何约束，失败时表现如何，事后能否追溯。这些问题属于运行系统的范畴。

AgentCore Harness 的价值就在这一层。它把 Agent 运行所需的隔离、记忆、工具接入、身份鉴权、可观测性和执行边界做成了配置项，让团队可以把精力放在业务场景的设计上。而由 Strands Agents 驱动、可导出为代码这两个特性，则给了用户充分的选择自由，使用户既可以配置够用时享受托管的便利，又可以在不够用时拿到源码继续演进。

AgentCore 将 Agent 运行的相关技术挑战都进行了托管和处理，让赛潍这样的大型企业得以快速测试、验证并上线深度贴合业务的 Agent。我们也期待更多企业基于 AgentCore 构建出属于自己的独特 Agent 体验。

➡️ 下一步行动：

相关产品：

Amazon Step Functions — 分布式应用程序的可视工作流
Amazon IAM — 身份管理和访问权限
AWS Lambda — 无需服务器即可运行代码
Amazon CloudWatch — 可观测性工具
Amazon S3 — 适用于 AI、分析和存档的几乎无限的安全对象存储

相关文章：

立即咨询 → 从 AI 规划到落地实施，我们的专家团队为你全程护航。

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者

探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用

亚马逊AWS官方博客