技能介绍

它解决什么问题

体育内容里最常见的事故不是文笔差，而是把未经核对的数字写成事实。Sports Reporter 把 Agent 的工作流压到“先取数，再成文”这条硬约束上：它可以按自然语言请求生成赛前预览、实时更新、赛后战报、球队分析、球员画像和每日综述，但所有比分、统计、阵容、排名和事件都必须来自一次已确认的 CLI 调用。

这个分工适合需要稳定产出赛事快讯、日更 roundup 或多联盟报告的工程师：Agent 负责路由请求和组织叙事，数据层负责返回真实结果，减少模型凭空补全比分、ID 或 xG 的风险。

它如何工作

先检查参数：如果传入的是 help、--help 或大小写不敏感的 help，只输出使用指南并停止，不触发取数和写作。
识别文章类型：从上下文判断属于 Preview、Live、Match Report、Team Analysis、Player Profile 还是 Daily Roundup。
识别运动与模块：根据球队、球员或赛事名路由到 football、nba、nfl、nhl、mlb、cfb/cbb、tennis、f1、golf 等模块；如果“football”这类表达有歧义，应先问用户。
先解析 ID，再调接口：不猜测 team_id、event_id 或 player_id，必要时用 get_scoreboard、get_daily_schedule、search_player、get_team_roster 等接口解析。
并行取数：互相独立的数据请求应并行发出，成文只使用已确认结果；接口失败时删除相关段落，不做脑补。
按模板成文：长文使用小标题，开头用最相关事实领起，给出积分、赛季阶段、比赛重要性等上下文，并保持新闻式客观。

适用边界与注意点

它不是数据仓库，也不是赔率或历史回放服务：get_odds 等未列出的命令不存在；xG 等 Understat 指标可能有 24–48 小时延迟，拿不到时应省略并改用 ESPN 统计。赛前内容需要接受“阵容尚未确认”的不确定性；实时数据缺失时只能说明状态并回退到 get_scoreboard。写球员或比赛前必须先解析 ID，遇到 event_id not found 应重新按日期查日程。输出语言跟随用户，未指定时默认 PT-BR。