自从在上海 Summit 上看到了 Agentic Football Cup（下文称 AFC）的多 Agent 足球对战活动，我就一直很想在 User Group 中引入、分享这个活动。我认为 AgentCore 是 AWS 一次很有意思的创新，而这个 Workshop 把娱乐性、参与感和学习结合在一起，能让大家通过实际体验理解 Agent 和多 Agent 协作。于是在北京 UG 进行了几次活动实践，也收获了一些经验，想在这篇文章中与大家分享。
北京这几次活动都依托于 AFC 官方 Workshop 和实验环境，整体形式是先简单讲解，再由大家自行实践，最后进行比赛。与以往的 Meetup 不同，这几次活动以 Workshop 为核心，大家做出来的球队可以直接上场，通过比赛获得即时反馈。
接下来主要分享我们在讲解、参与者自行实践和完成 Workshop 的过程中遇到的一些技术问题，以及相应的处理办法。官方 Workshop 已经提供了完整的操作步骤，其中有些地方也已经写明，但现场依旧容易忽略。
本文结合我们当时的活动经验，并对照了 2026 年 9 月 6 日查阅的 Workshop 内容。后续界面或操作步骤如果有变化，可以再回到 Workshop 对应章节查看。
我们主要使用 Harness 方案
Workshop 给出了多种部署方案和路径。对于首次参与者或非技术背景参与者比较多的活动，我们推荐使用 AgentCore Harness 的方式进行部署。下面的问题也主要是在使用 Harness 方案时遇到的。
Harness 是 AgentCore 提供的托管式 Agent 构建组件，可以让使用者像搭积木一样，快速启动一个 Agent，验证自己的想法。它会负责 Agent 的推理、工具调用等运行过程，具体可以参考 AWS 对 Harness 的介绍。在 AFC 的 Harness 方案中，参与者主要需要选择模型、编写提示词，再选好实验环境提供的权限角色，基本就可以完成创建。Workshop 中也给出了几版我觉得质量很高的提示词示例，可以先复制跑通流程，再按自己的想法修改。
随着后续的需要，还可以配置记忆、通过 Gateway 托管的工具等内容。对首次体验的朋友来说，这种方式能让大家先把精力放在模型选择和提示词上，尝试让自己的球队踢得更好。
创建 Harness 时容易漏选的权限
这里有一个 Workshop 已经提及，但现场依旧有不少人会踩坑的地方：Harness 创建的最后一步，需要选择权限（Permission）。
实验环境已经提前为我们创建了一个名称以 team-SolutionAccessRole- 开头的 Role。按照当前 Workshop 的界面，需要在 Permissions 下选择 Use another role，再从下拉菜单中选择这个已有的 Role。但不少参与者没有修改默认选项 Create default role，也就是创建一个新的 Role，导致 Harness 创建失败。
为什么默认选项在这里不行？Workshop 的部署章节（Harness 标签页） 已经说明：实验环境中的参与者角色没有创建 IAM Role 的权限，所以需要使用提前配置好的角色。这里说的是 Workshop 提供的实验账户；如果使用自己的 AWS 账户，角色的名称和权限配置需要按自己的环境来。
这是我们在 Harness 创建过程中遇到的一个比较集中的问题。如果创建失败，可以先看看是不是这里选错了。
讲解到这里时，可以停下来单独提醒一下。如果活动准备了补充文档或 PPT，也可以放一张截图，把 Role 的选择位置圈出来。
复制到 Player Portal 的 ARN，不同部署方式要分清
上文提到，我们主要推荐大家使用 Harness 的方式部署。创建好后进入详情页，会看到两个 ARN：Harness ARN 和 Runtime ARN。使用这条路径时，需要复制的是 Harness ARN，再到比赛门户进行绑定。当前 Workshop 中把这个门户叫作 Player Portal，下面也统一使用这个名称。
如果是自己在本地开发后部署到远端，或者通过 CloudShell 等方式直接创建 Runtime，这时则需要复制对应的 Runtime ARN。
对应到 Workshop 的部署说明，可以简单记成：
| 使用的部署方式 | 注册到 Player Portal 的 ARN |
|---|---|
| 在 Harness 中配置模型和提示词 | Harness ARN |
| 编写自己的 Agent 代码，再部署到 Runtime | Runtime ARN |
如果之前不太接触 AWS，可以把 ARN 理解成某个云上资源的唯一标识，具体定义可以参考 AWS 的 ARN 说明。Harness 本身和它底下运行的 Runtime 各有一个 ARN，AWS 的 Harness 资源文档 也分别列出了这两个值。所以，虽然都出现在同一个详情页里，复制时还是要看清字段名称。
这两处很容易混淆。我第一次配置时就选错了 ARN，导致连接失败。所以在引导大家复制 ARN 时，需要结合前面使用的部署方式，说明具体复制哪一个。
对于想进一步了解调用方式的技术志愿者，可以参考 AWS 的 InvokeHarness 和 InvokeAgentRuntime 文档，分别查看两个接口使用的资源标识。具体到 AFC 门户该填哪个，按上面的 Workshop 路径选择就可以了。
模型输出的 JSON 不符合要求，导致体能测试不过
我们在 Harness 路径中还遇到过一个问题：Agent 输出的 JSON 格式不符合要求，导致无法通过 Player Portal 的赛前体能测试。当前 Workshop 对应的入口是 Getting Started 清单中的 Test your agents。它会发送一个示例游戏状态，检查 Agent 是否能够正常响应。简单来说，模型虽然回复了内容，但格式不符合程序的要求，程序就无法正常使用这个回复。
在我们使用的 Harness 方案中，Agent 的构建和运行由平台托管，我们没有像自己编写代码那样，在输出交给 Player Portal 前再加一道格式检查和处理。Workshop 的比赛章节 也专门提醒了这一点：这条 Harness 路径依赖提示词来约定 JSON 格式，没有在代码中强制执行格式要求。因此，即使提示词中要求了 JSON 格式，也可能遇到输出不符合要求的情况。
对于这种情况，可以先重试。如果多次重试仍然不行，可以尝试临时切换到输出更稳定的模型，例如换一个更大的模型，再跑一次检查。这也是 Workshop 给出的处理建议，活动中参与者自己就比较容易尝试，但更大的模型也不保证每次都输出正确的 JSON。
如果还是无法通过，就需要请志愿者或 TA 帮忙查看具体原因，也不能把所有体能测试失败都归结为 JSON 问题。同一章节还提醒了另外两个检查点：Agent 是否已经处于 Ready 状态，以及跨账户调用所需的 IAM 信任策略是否配置正确。对参与者来说，可以先看状态；权限相关的部分再请志愿者协助检查。
这里还需要把格式错误和响应超时分开看。当前 Workshop 的动作与属性章节说明，Agent 未能及时响应时，球员会保持上一条指令。这条说明针对的是超时；遇到 JSON 格式错误时，还是需要查看具体响应，不能仅凭球员有没有继续行动来判断输出是否正常。
所以选择模型时，也需要在回复速度和 JSON 输出稳定性之间做一些取舍。回复快，但经常无法被程序使用，同样会影响比赛；换了模型后，也需要再看看它是否能及时响应。
第一次打开比赛，资源加载可能比较慢
我们在活动中观察到，首次在 Player Portal 中开始一场比赛时，页面有较多资源需要加载。如果活动现场网络不稳定，加载时间可能会比较长。
我们处理这类问题时，会尝试切换手机热点，或者使用更稳定的场地网络。
关于现场的技术支持
对于以 Workshop 为主的活动，我仍然觉得，有能够帮忙排查和解决问题的志愿者，是活动顺利推进的重要条件之一。
毕竟，我们使用的是他人编写和提供的实验，有些内容能自己查看、修改，有些则不容易看到内部是怎么运行的。比如这个 Workshop 中的 Player Portal，对我们来说就有一部分是黑盒。遇到问题时，志愿者也需要判断：哪些地方我们能继续检查，哪些涉及平台内部，现场不一定能够解决。
这几条经验并不能覆盖所有情况，但希望能给后续举办活动的朋友、现场志愿者，以及想自行体验这个 Workshop 的参与者一些参考。
补充参考
如果想继续了解完整的实验步骤，可以阅读 Agentic Football Cup 官方 Workshop（中文）。本文涉及的具体操作，也尽量在对应段落里放了链接，方便遇到问题时直接回去查看。
另外推荐 Strands 团队写的 Inside Agentic Football Cup: 10 Strands Agents, 1 Second to Decide。这篇文章介绍了他们如何使用 Strands Agents 和 AgentCore 实现多 Agent 足球对战，也讲到了结构化输出、模型响应速度和多 Agent 协作。对于想知道“这些球员背后是怎么运行的”的朋友，可以作为本文的补充阅读。
阅读时留意，博文与当前 Workshop 对超时时间和超时后球员行为的描述并不完全一致。这里把它作为理解实现思路的参考；实际操作和比赛行为，仍需要结合当前 Workshop 与所用环境确认。