领先一球该换谁？这个实验让模型选人却不敢让它拍板

第70分钟，球队1比0领先，教练要换下右后卫，替补席上有三名球员都能打这个位置。指令只有一句：保住领先。一个喜欢前插助攻，一个站住位置提供防守覆盖，第三个更擅长控球。

Football Decider Lab 就用这个场景来测试 Strands Decider 在选替补时如何遵循教练指令。项目为 Strands Decider Hackathon 而建，应用部分用 Python 编写，解释部分由 Strands Agent 配合 Amazon Bedrock 生成。演示使用合成的比赛快照和球员描述，界面会展示符合条件的候选人、最终选中的球员，以及支撑最终动作的各项检查。

同一套替补席，两种指令

两个主要场景用的是同一批球员：

• bench-17：进攻型边后卫，习惯套边插上并送出传中。
• bench-23：保守型后卫，可以客串右后卫。
• bench-31：中场球员，在该模拟中被允许打右后卫。

三人的准备度评分相同。如果按“主位置匹配就选第一个”的简单逻辑，会优先选中 bench-17，哪怕教练要的是防守覆盖。

在 protect-lead 场景中，球队1比0领先，教练偏好站住位置的防守球员；在 chase-goal 场景中，球队0比1落后，教练要求进攻宽度和传中。这给模型的任务很小也很具体：依据给定的指令和球员描述，在符合条件的球员中做出选择。

规则决定谁有资格被考虑

应用在调用 Decider 之前会先检查快照。工作量数据缺失，或遥测数据超过15秒，会产出 REVIEW_DATA；未达到合成的换人触发条件时，动作为 MONITOR。

触发条件满足后，代码会检查剩余换人名额并筛选替补席。候选人必须在替补席上、准备度评分不低于60，并且被批准打被换下球员的位置。这些数值是模拟的设定值，不是医学阈值，也不是对竞赛规则的完整实现。

没有合格候选人时，应用返回 NO_REPLACEMENT；只有一名候选人时，直接使用策略结果而不调用 Decider；有多名候选人时，才请模型做选择。资格判断始终由应用掌控，模型只拿到通过检查的选项。

应用通过 HTTP 服务调用 Strands Decider 2B。请求包含比赛上下文、教练指令和合格球员描述，预期测试答案不放进请求。响应包含选中选项、概率和置信度，应用在接受前会做校验：未知球员 ID、无效的概率分布或意外的模型身份都会报错。

随后由一道独立的闸门决定最终动作，配置如下：

• 阈值 0.7
• 自动动作 SUBSTITUTE
• 复核动作 REVIEW_MODEL
• 复核原因 low_confidence

低于0.7时，选中的球员仍留在记录里，但动作变为 REVIEW_MODEL，界面可以展示候选人，同时明确标出需要人工复核。该阈值是实验性的，置信度0.74并不意味着换人成功概率为74%。

为已定的决策生成解释

在生成任何文本之前，应用会先创建不可变的 DecisionRecord，保存输入快照、资格结果、提供的选项、模型原始响应和最终动作，同时记录提示词、选项集和闸门配置的哈希。

之后由使用 Amazon Bedrock 的 Strands Agent 依据该记录写一段简短总结。解释必须保持选中的球员和最终动作不变，校验器会检查证据引用、球员 ID 和数字表述；对于 REVIEW_MODEL，总结必须写明需要人工复核。这些检查能抓住特定错误，但无法证明每一句在战术上都正确，生成的文本只是对已记录事实和结果的总结。

如果 Bedrock 调用失败或其响应未通过校验，决策记录仍然可用，解释失败会单独显示。已验证的演示在法兰克福的一台 EC2 实例上，把 Python 应用和基于 CPU 的 Decider 作为两个独立服务运行，Bedrock 负责解释调用。状态分开呈现，便于看出是哪一步失败。

实跑结果说明了什么

保存下来的 EC2 运行记录显示：两个场景都使用了实时 Decider 响应，Bedrock 解释均通过校验。防守场景中，选中的候选人通过了置信度闸门；进攻场景中，Decider 选中了预设的目标球员，但返回的置信度低于阈值，应用保留了该选择并请求人工复核。

这个区别在评估结果时很重要：选中预期球员，和让推荐通过闸门，是两个独立的结果。这两次运行验证的是应用在预设样例上的路径，评估足球层面的质量还需要独立的教练标注和更大的评测集。

命令行工具包含22个合成场景，覆盖空替补席、遥测过期、球员不可用和不同教练指令等情况，最新记录的验证结果为51个自动化测试通过。运行器可以重复请求并改变候选人顺序，用来检查同一批球员以不同顺序出现时选择是否变化。报告保留错误，并区分模型调用与策略决策；离线试运行只构建请求，模型结果标记为 NOT_RUN，不产生模型准确率分数。

应用还把固定样例输出与实时调用分开：固定样例模式使用测试替身，无需 AWS 凭据即可运行，适合检查界面和控制流。回放功能可以读取已登记的捕获并校验哈希，不发起新的模型调用，目前登记的回放目录为空。要在本地打开固定样例界面，运行 make run 并访问 http://127.0.0.1:8080。

下一步想测什么

当前的标签由作者编写，指令也把偏好球员说得相当明确，一个透明的规则基线可能就能处理好其中不少情况。下一步计划让教练标注不那么明显的情形，记录他们意见不一致的地方，并整组留出相关场景，然后把 Decider 与更简单的基线做对比，包括各自需要复核或失败的频率。

选择器已经与足球规则、HTTP 传输和 AWS 分离。仓库里还有一个离线支持专员示例，沿用相同的选择与复核模式，这使得代码可以在另一个领域测试，同时让资格判断和复核策略保持领域专属。