一、引言

世界杯这阵子，我朋友圈被各种战术分析、半夜看球的吐槽刷屏，我没怎么熬夜看球赛，但脑子里冒出一个想法：既然大家在聊足球，要不我也拿 AI 写个踢球的？

说干就干。我手上本来就有一个 3V3 机器人足球仿真赛的项目，是个完整的 Python 工程，里面有四十多个文件，包括行为树、Playbook 调度、角色分配、传球评分一堆东西。我把火山方舟刚上线没几天的 Doubao-Seed-Evolving 接进了 Claude Code，让它从零开始改造这个项目。

二、Doubao-Seed-Evolving 模型介绍

这次真正的主角是 Doubao-Seed-Evolving——火山引擎推出的一款持续进化（Evolving）的动态升级模型，聚焦 Coding 与 Agent 能力。

它最特别的地方在于统一 Model ID、一次接入、自动升级、零迁移成本：传统模型每次升级都要换 ID、重测、改代码，而你只需固定接入 doubao-seed-evolving，底层能力以周级别高频节奏持续迭代，代码一行不改就能一直用上最新版本，就像「一张永远’最新’的模型卡片」。

本次升级三个关键点，恰好都踩在这次 3V3 足球项目的痛点上：

• 1M 超长上下文：整个四十多个 Python 文件的项目，能一次性塞进上下文喂给模型，无需分段、无需向量检索
• 长程任务能力增强：多步骤、强依赖任务更稳定，“读懂项目 → 给建议 → 改代码 → 跑仿真 → 看录像诊断 → 再迭代” 这种五六步的链条能从头跑到尾不掉链
• Tokens 效率提升：同样任务消耗更少 tokens、工具调用轮次更简洁，响应更快、成本更省

三、Doubao-Seed 家族三大热门模型

豆包 Seed 家族目前主推三款模型，都面向 Coding 与 Agent 场景，可在火山方舟中直接接入，覆盖从"持续进化"到"规模化生产"的不同定位：

模型	⭐ Doubao-Seed-Evolving	Doubao-Seed-2.1-pro	Doubao-Seed-2.1-turbo
定位	动态持续进化（本项目主角）	高复杂度任务旗舰	规模化生产
核心特点	统一 Model ID、周级更新、1M 超长上下文，一次接入自动升级、零迁移成本	面向高难度探索，Coding / Agent / VLM 三大能力全面跃升，擅长复杂推理与多步长任务	面向高频调用场景，价格约为 Pro 的一半，性价比更高，适合大规模线上部署

三款模型能力同源、接入方式一致。而本次项目的主角，是 Doubao-Seed-Evolving——相比另外两款"发版即定型"的模型，它以周级节奏持续进化，统一 Model ID 一次接入便自动升级。

我看中的正是它"超长上下文 + 持续进化"这套独门组合：既能一次吃下整个机器人足球项目的代码库，又能随迭代不断变强，是这类"需要长上下文、又想长期免维护升级"的工程项目的最佳选择。

四、环境搭建：Claude Code 接入 Seed API

上一节已经聊过 Doubao-Seed-Evolving 的能力与定位，这一节把它真正接入到我的Claude Code里试试

步骤一：开通服务并获取 API KEY

首先我们点击登录火山引擎控制台，并进入 Agent Plan 页面订一个套餐，或者直接在方舟控制台创建一个推理接入点（手动选 doubao-seed-evolving 模型）

然后点击创建专属的Agent Plan API Key。

步骤二：CC Switch 中配置 Doubao-Seed-Evolving

创建好后，可以直接使用cc-switch接入，选择火山AgentPlan

然后编写ANTHROPIC_AUTH_TOKEN、ANTHROPIC_BASE_URL，以及选择模型为doubao-seed-evolving，完整的配置如下：

{
  "effortLevel": "xhigh",
  "env": {
    "ANTHROPIC_AUTH_TOKEN": "ark-31eb8d88-e114-49b9-9e6b-3d1ab366634e-6de72",
    "ANTHROPIC_BASE_URL": "https://ark.cn-beijing.volces.com/api/plan",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "doubao-seed-evolving",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "doubao-seed-evolving",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "doubao-seed-evolving",
    "ANTHROPIC_MODEL": "doubao-seed-evolving",
    "API_TIMEOUT_MS": "3000000",
    "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1",
    "CLAUDE_CODE_EFFORT_LEVEL": "max",
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1",
    "CLAUDE_CODE_SUBAGENT_MODEL": "doubao-seed-evolving",
    "ENABLE_TOOL_SEARCH": "true"
  },

步骤三：验证模型配置

保存配置文件后，关掉所有已经打开的终端窗口，新开一个（环境变量要在进程启动时就加载）。然后进入项目目录输入 claude 启动，启动后输入 /status 验证模型是否连接成功。如果一切顺利，Claude Code 里显示的模型名会变成 doubao-seed-evolving。配置完成后，就可以在 Claude Code 里调用这个底座的 Doubao-Seed-Evolving 来改造项目了！

五、基于 Claude Code + Doubao-Seed-Evolving 改造 3V3 机器人足球策略

5.1 项目背景与需求

简单交代一下背景，这个项目是每队三个 Booster K1 机器人在 14×9 米的虚拟场地上踢 10 分钟。三个机器人分别对应三个角色槽位：CENTER（前腰）、SIDE（边路）、KEEPER（守门员）。

策略代码的核心架构是 Playbook → Role → Command 三层模型：

• Playbook 是教练，每 30Hz（每秒 30 次）重新判断场上局势，决定谁当 Chaser（追球）、谁当 Supporter（接应）、谁当 Goalkeeper（守门）
• Role 是球员的思考模式，每个角色挂着一棵行为树，比如 Chaser 的子树是"Selector → 踢球分支 | 移动分支"
• Command 是具体 指令，MoveIntent / KickIntent / StopIntent 三种意图，最后下发到机器人

整个项目的目录结构长这样：

机器人足球赛/workspace/messi/
├── src/
│   ├── main.py                # 进程入口 + Agent 生命周期
│   ├── runtime.py             # 控制循环装配层（30Hz）
│   ├── behavior_tree/         # 行为树框架（py_trees）
│   ├── play/                  # 策略层（Playbook / Role / Command）
│   ├── soccer_framework/      # 环境适配层（ROS / 数据类型 / 配置）
│   └── tactics/               # 战术工具（避障 / 移动 / 踢球 / 站位）
├── agent.toml                 # 依赖声明
├── build/                     # 构建产物（.agent 文件）
└── entries/                   # 比赛入口配置

里面有四十多个 Python 文件，分散在 behavior_tree/、play/、soccer_framework/、tactics/ 四个主要目录里。作为一个完整的 Python 工程，它的复杂度一点都不低——读起来跟写一个分布式系统差不多：决策系统每 33 毫秒重新跑一遍"感知 → 决策 → 执行"循环，三个机器人之间还要互相配合，AI 能不能基于现有项目，做出一个比默认版本明显胜率更高的"闪电三角 v3.0"策略？

5.2 我手上有什么：两个 baseline

我把项目拉出来看了一下，发现工作区里其实躺着两个能用的 baseline：

• 一个是官方的示例策略（DefaultPlaybook），也就是 30Hz 默认调度、三个角色按默认参数跑的那一套。这是比赛的"出厂设置"，人人都有，参数保守，胜率平庸。
• 另一个是我之前手写的 版本，那是几周前我自己试着调过参数的版本，速度、守门员出击这些都动过一点，但整体偏保守、没啥章法，胜率一直上不去。

这两个 baseline 给我一种很典型的处境：有一个能跑但平庸的官方版本，有一个我自己试过但没调好的半成品。AI 能不能基于这两个，做出比它们都好的"闪电三角 v3.0"？这是我当时心里真正想验证的事。

5.3 第一轮：让 AI 自己"看"懂整个仓库

第一件事，我不是直接让 Seed-Evolving 改代码，而是让它先把整个工程读一遍。在 Claude Code 里我敲的是：

请把 src/ 目录下的所有文件读一遍，给我讲讲这个项目是怎么工作的。
重点关注 play/、behavior_tree/、tactics/、soccer_framework/ 这四个目录之间的关系。

这一步的关键观察是 Seed-Evolving 的工具调用行为。它没有像一般模型那样直接开始"我猜这个项目是 XXX"——它真的开始读文件了。我能看到终端里它依次调用了：

>>> Read src/main.py
>>> Read src/runtime.py
>>> Read src/play/playbook.py
>>> Read src/play/role.py
>>> Read src/play/default_roles.py
>>> Read src/behavior_tree/tree.py
>>> Read src/behavior_tree/nodes/data.py
>>> Read src/behavior_tree/nodes/conditions.py
>>> Read src/behavior_tree/nodes/actions.py
>>> Read src/soccer_framework/config.py
>>> Read src/soccer_framework/types.py
>>> Read src/tactics/motion.py
>>> Read src/tactics/kick_hysteresis.py
... (还在继续读)

整个读文件的过程持续了大约 90 秒，它调用了 30 多次 Read 工具，把几乎所有相关文件都看了一遍。这里有一个细节我想专门点出来：它没有读死代码——它是真的"理解"了。比如它在读完 playbook.py 之后接着读了 default_roles.py，因为它识别到前者依赖后者。这就是 1M 上下文窗口的真正价值——不是塞得下更多内容，而是对已有代码库的整体理解能力。

读完之后，它给了我一段 800 多字的项目总结，让我意识到它真的把代码读进去了，而不是扫一眼文件名就开始编。

5.4 第二轮：让 AI 在理解之上给出战术修改

读懂整个项目之后，我紧接着抛给它一个开放性的问题——也是我真正想验证的事：它到底是能"看懂"代码，还是只会"看过"代码。

基于上面的理解，请告诉我：在 3V3 小场地上，这套默认策略有哪些可以优化的点？
哪些参数保守了？哪些行为不合理？帮我修改完成代码

我原本的预期是它给我一份调参建议清单——速度调快点、踢力调大点、守门员靠前一点，之类的。毕竟这是最"安全"的回答方式。但它的输出有点出乎我意料。第一件让我意外的事，是它先从代码里挖出了 3 个 Bug，而不是急着调参数。

• tactics/motion.py 里 approach_target() 函数计算追球逼近点时，永远沿 −x 方向（向自家球门）后退固定距离——注释写的是"沿踢球反方向退"，代码却写死了水平后退，这意味着只要踢球方向不是正对球门（斜传、侧方解围），追球手就会跑错位置，得多转半个身位才能踢正。
• tactics/targeting/support.py 里接应球员的位置被 own_half_x() 硬钳在 x ≤ −0.35，哪怕球已经压到对方禁区前，接应点还缩在中圈后面五六米远——3v3 小场这点距离，球传不到一半就被截了。
• tactics/motion.py 的路径绕行逻辑在 PLAY 阶段也会绕开对方球员，追球手正面冲向球时，如果对方后卫站在球和自己之间，就会自动在侧后方画一个绕行点——等于跑着弧线送球权。

这三个问题都不是"参数偏保守"，而是代码本身的行为写错了。如果它真的只是扫了一遍文件名就开始编，不可能发现这些——它们藏在几何计算和条件分支里，需要真的顺着每帧 tick 的执行链路在脑子里跑一遍才能看出来。

第二件让我意外的事，是它排了优先级，不是一股脑全改。 它把所有问题按严重度排了序：先修 3 个 bug，再调战术逻辑，最后才动 ~20 个参数。同时在层次上自底向上推进——先改 motion/geometry 里的几何计算，再改 tactics/ 的目标选择和路径逻辑，最后才动 play/ 里的角色决策。每处改动都在代码里留了英文注释，写清楚"原来是什么值、为什么要改、改成了什么"，方便我后续回滚或继续微调。改完之后，它还自己跑了一遍 python -m compileall src，确认没有语法和 import 错误。

最后它把整套修改打包命名为"闪电三角 v3.0"——这名字是它自己起的。下面是它调整的核心参数：

参数	当前值	建议值	理由
max_linear_speed	0.85	0.95	小场需要冲刺覆盖，Modric 节拍器风格偏慢
max_angular_speed	1.1	1.6	1.1 rad/s ≈ 63°/s，原地转 180° 要 2.8s，太慢。提到 1.6 ≈ 92°/s
_TURN_THRESHOLD	0.5 rad	0.35 rad	29° 就原地转太保守；降到 20° 让机器人边转边走更快到
_ANGULAR_SPEED_FLOOR	0.25	0.20	配合 floor 降低减小超调
_LINEAR_SPEED_FLOOR	0.3	0.2	近距离时不要猛冲
soccer_kick_enter_distance	2.5	1.8	2.5m 开外就进入 kick 模式太早，远射不靠谱
soccer_kick_power	1.5	2.0	小场要能从中场射正球门，1.5 可能踢不到
soccer_kick_exit_delay_sec	1.2	0.6	踢空后退出 kick 状态更快，别僵在那里
soccer_kick_min_active_sec	1.0	0.4	踢一下不用占底盘整整 1 秒
dribble_advance_m	1.0	1.5	盘带推进距离太短，小场应该快速向前
dribble_center_pull	0.7	0.5	不要把球强行拉到中线，保持当前位置更自然

我盯着这张表看的时候，第一反应是：它真的在做工程判断。它不是笼统地说"速度调快一点"，而是给出具体数字、说清楚这个数字在场上对应的物理含义（“1.1 rad/s 约 63°/s，转 180° 要 2.8 秒”），然后告诉你改成 1.6 之后能快到什么程度。这背后是它真的读了运动控制代码，理解了那些常量是怎么被用的——而不是对着参数名瞎猜。还有一个细节让我确认它不是在瞎改：在守门员出击区的调整上，它把阈值从 −2.5m 缩到 −4.2m，注释里写的是"3v3 场总共 14m，−2.5m 离自己球门 4.5m，差不多在中圈，守门员跑到这个位置离门太远"。这个判断需要它真的理解坐标系，并且能把抽象的数字映射到场地上的实际位置。

到这一步我开始觉得，这次可能不只是"调几个参数"那么简单了。它不是在帮我写代码，而是在帮我做一连串工程决策——发现 Bug、排优先级、判断改什么不改什么、给每个数字找物理依据、最后自己跑校验。下一步，就是把这些改动打包放进仿真环境里跑，看看真正踢起来是什么效果。

六、效果展示

6.1 闪电三角 v3.0 策略运行效果

把闪电三角 v3.0 + 动态比分切换打包之后，我在仿真环境里跑了 10 场完整的 10 分钟比赛，整体数据是这样的：

指标	默认策略（baseline）	闪电三角 v3.0	变化
场均进球	0.8	2.4	+200%
场均丢球	1.5	1.1	−27%
场均射门	2.1	5.6	+167%
场均传球成功	3.2	8.7	+172%
场均犯规/违例	0.6	0.4	−33%

场均进球从 0.8 涨到 2.4，这个数字在我意料之中——射门阈值放宽、追球手不绕对方、接应位压上来，进攻变猛是必然的。但丢球反而从 1.5 降到 1.1，这是我没想到的。

我回看了几场录像才想明白原因：机器人不会累。真人足球里"全队压上 = 身后留空当"是常识，但在仿真里三个机器人能连续跑 10 分钟不掉速，对方守门员开门球的瞬间，我的追球手已经压到他面前逼抢，接应球员也整体压过中线——对手根本组织不起有效的反击。这是一个"反直觉"的结论：在机器人足球里，激进的高位压迫反而比保守防守更安全，这个判断如果靠我自己手动调参，大概永远也不敢试。

光看数字有点干，我挑了三场比赛里的典型片段，你能直观感受到Doubao-Seed-Evolving研究出来的策略的效果：

6.2 工具调用轮次对比

数字会说话，我把 Seed-Evolving 这次改造全过程的工具调用统计拉了出来，和我之前用普通对话模型（同样接 Claude Code、同样做足球策略）的记录做了对比：

阶段	Seed-Evolving	普通模型（参考）
读懂项目（5.3）	Read × 30+，按依赖顺序读，90 秒内读完	Read × 5-10，读了几个主要文件就开始编
给战术建议（5.4）	1 轮长回复 + 主动改代码 + 跑 compileall 校验	3-5 轮来回后还会忘记前面讨论过什么
改代码 + 构建	Edit × 11、Bash × 1（compileall）	多轮反复、改完 A 文件又忘了 B 文件的联动
仿真后诊断（后续迭代）	Grep × 8、Read × 若干，能准确引用第二轮给过的参数	第四轮开始记忆模糊，需要重新贴代码
总计有效工具调用	~60 次，连贯决策	~30 次，但中间有大量无效重复

真正的差别不在调用次数，而在连贯性。这种"五六步长链条不掉链"的能力，在这方面给我的感觉是——它像一个真的坐在你旁边和你一起 debug 的同事，而不是一个每轮都要重新 brief 的外包

七、总结

回头看这次改造，我其实只做了三件事：把项目交给 Seed-Evolving，问了它三个问题（“读一遍告诉我怎么工作”、“找问题改代码”、“再写一个新 Playbook”），然后把它的产出放进仿真里跑。从晚上八点打开终端，到十一点看到第一场 4:1 的比分出来——三小时，一个完整的"闪电三角 v3.0"。

真正让我觉得不一样的，不是它改出了多厉害的战术，而是整个过程里我几乎没有"教"它任何东西，把整个流程复盘一遍， 落到模型能力上的点有三个：

它能一次吃下整个项目。 四十多个文件一次读完，它能自己发现那些散落在不同文件里、互相牵连的问题。这种"牵一发动全身"的修改，要是读一段忘一段，肯定会改一半漏一半。

五六步的长链条它不掉链子。 从读代码、找 bug、排优先级、改代码、到自己跑语法检查，中间它没有一次"失忆"。等后面我让它写一套新战术的时候，它还记得很久之前我提到的东西。

它调工具是有目的的，不是走流程。 读完教练逻辑它会立刻去读球员角色定义，因为它看出前者依赖后者；改完运动控制它会顺手去改上层调用，因为加了新参数得传下去；改完所有文件它自己跑了一遍语法检查——这一步我没让它做，是它自己觉得"改了这么多应该验证一下"。

晚上盯着仿真画面，看着三个机器人在场上逼抢、跑位、传球、射门，最后 4:1 拿下的时候，我有点理解球迷那种激动了——90 分钟的职业比赛离我很远，但三小时里我和一个模型一起，把一堆出厂时平庸的默认参数，调成了一支真正能踢球的小球队。这件事本身是浪漫的。世界杯会结束，模型还会继续进化。Seed-Evolving 这种"接入一次、之后每周自动变强"的模式意味着，几个月后底层模型升级了，就能设计出更好的配合策略。

不是模型取代人，而是人和模型一起，一个晚上能做完以前一个人做一周的事，还做得更好。这就够了。