1. 一个人刷题到 AI 战队竞速ctf-agent 接入 CTFd 到底解决了什么ctf-agent 是一套面向 CTF 场景的自动化解题 Agent它能直接对接 CTFd 平台自动轮询新题、拉起多个模型 Solver、在 Docker 沙箱里跑工具、最后把 flag 提交回平台。适合谁适合打 CTF 的战队、做安全 Agent 研究的人、以及想把「题目下发 → 多模型并行 → 结果回收」这条链路跑通的工程师。它和普通「把题目粘给大模型聊两句」最大的区别是它不是单模型问答而是多模型竞速系统谁先拿到 flag 谁赢下这一局。我最初接触这类工具时最大的痛点不是模型聪不聪明而是模型调用入口太散。Claude 一个 Key、Codex 一个 Key、Gemini 又一个 Key每个 Solver 都要单独配环境变量比赛时题目一多光是管理这些凭据就够呛。更麻烦的是并发一上来某个通道限流整个 Solver 就卡死Coordinator 读不到轨迹调度直接断链。所以这篇的重点不是复述 ctf-agent 有多强而是把「多 Agent 统一模型调用入口」这件事讲透。我会用 TaoToken 作为统一 Key/API 通道让所有 Solver 和 Coordinator 走同一个 Base URL再对接 CTFd跑通从题目下发到 flag 提交的完整闭环。你可以把它理解成ctf-agent 是战队TaoToken 是战队的统一通讯频道CTFd 是比赛场地。实测下来统一入口之后配置从「每个模型一套环境变量」变成「一个 Base URL 一个 Key 按需切 Model ID」并发调度时也不用担心某个通道的凭据写错导致整个 Solver 起不来。下面按步骤来先讲前置准备再给可复制配置最后跑一次完整赛题验证。2. TaoToken 前置准备统一 Key 与 API 通道怎么开在把 ctf-agent 接到 CTFd 之前先把模型调用入口统一掉。这一步做扎实后面多 Solver 并发才不会乱。TaoToken 在这里的角色是「统一 Key/API 通道」你不需要为每个模型单独维护一套凭据而是用一个 Base URL 加一个 Key通过切换 Model ID 来调用不同模型。先注册并拿到 Key。打开官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 完成账号注册后进入控制台。控制台地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 在里面可以创建 API Key。创建完记得立刻复制保存页面刷新后一般不再完整显示。拿到 Key 之后去 API Keys 页面管理你的凭据https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。这里建议按用途分 Key比如「ctf-solver」一个、「ctf-coordinator」一个方便后面按 Agent 角色限流和排查。API 的基础地址是 https://taotoken.net/api 注意这个地址不带 UTM 参数配置里直接写它。模型这块ctf-agent 的 Solver 和 Coordinator 可以分别指定不同模型。你可以在模型对话页面先验证某个 Model ID 是否可用https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 。比如先发一句「返回 pong」确认通道通了再写进 ctf-agent 的配置。这一步别省很多后面的 401 和 reading choices 报错都是因为 Model ID 写错或 Key 没生效。如果你打算长期跑 CTF 训练或 Agent 调度建议直接看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。它更适合高频、多并发的编码与 Agent 场景比按次调用更稳。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 配置细节以文档为准。前置准备的核心就三件事一个 Base URLhttps://taotoken.net/api、一个 Key、一组你要用的 Model ID。把这三件套记牢后面所有配置都围绕它们展开。3. 可复制配置ctf-agent 对接 CTFd 与统一 Key这一节给可直接复制的配置片段。ctf-agent 用.env管理凭据用命令行参数控制调度。我们把模型调用统一指向 TaoToken把 CTFd 的地址和 token 填进去。先看.env的写法。路径是项目根目录下的.env从.env.example复制而来# .env # CTFd 平台 CTFD_URLhttps://ctf.example.com CTFD_TOKENctfd_your_token_here # 统一模型通道TaoToken OPENAI_BASE_URLhttps://taotoken.net/api OPENAI_API_KEYsk-your-taotoken-key # 按角色指定 Model ID SOLVER_MODELgpt-4o-mini COORDINATOR_MODELgpt-4o # 并发与调度 MAX_CHALLENGES10 POLL_INTERVAL5注意OPENAI_BASE_URL指向 TaoToken 的 API 地址OPENAI_API_KEY填你在控制台创建的 Key。ctf-agent 里很多 Solver 走 OpenAI 兼容协议所以用这两个变量就能把通道统一。Model ID 按你实际可用的填先在模型对话页验证过再写进来。如果你用 Claude Code 或 Codex 作为 Coordinator需要额外配置。Claude Code 的接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite Codex 相关配置同样以文档为准。以 Codex 的auth.json为例路径通常在~/.codex/auth.json{ OPENAI_API_KEY: sk-your-taotoken-key, OPENAI_BASE_URL: https://taotoken.net/api }如果你用 Cline 或 MCP 方式接入配置里同样要写全三件套Base URL、Key、Model ID。缺一个都会在启动时报错。Cline 的 MCP 配置片段大致如下{ mcpServers: { taotoken: { command: npx, args: [-y, your-mcp-server], env: { OPENAI_BASE_URL: https://taotoken.net/api, OPENAI_API_KEY: sk-your-taotoken-key, MODEL_ID: gpt-4o-mini } } } }启动 ctf-agent 的命令行参数这样写uv run ctf-solve \ --ctfd-url https://ctf.example.com \ --ctfd-token ctfd_your_token_here \ --challenges-dir challenges \ --max-challenges 10 \ --coordinator claude \ -v--max-challenges控制一次拉起的题目上限第一次跑建议设小一点比如 3 到 5确认链路通了再放大。--coordinator选claude或codex取决于你配了哪个后端。-v打开详细日志方便看 Poller 是否在轮询、Solver 是否起来了。参数对照表参数作用建议值--ctfd-urlCTFd 平台地址你的比赛地址--ctfd-tokenCTFd API Token平台生成--challenges-dir题目工作目录challenges--max-challenges单次最大题目数首次 3–5--coordinator调度后端claude/codex-v详细日志调试期开启注意.env里的 Key 不要提交到 Git。建议把.env加进.gitignore比赛用的 Key 单独创建赛后及时轮换。配置写完先别急着放大并发。下一步先做一次最小验证确认 CTFd 能拉到题、模型通道能返回、Solver 能起容器。4. 验证请求从题目下发到 flag 提交跑通一次配置就绪后做一次完整验证。目标是CTFd 下发一道题 → Poller 发现 → Solver 拉起 → 模型通过 TaoToken 返回结果 → flag 提交回平台。整个过程用日志观察。第一步确认模型通道通。先用 curl 打一次 TaoToken 的 API验证 Key 和 Model IDcurl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-your-taotoken-key \ -H Content-Type: application/json \ -d { model: gpt-4o-mini, messages: [{role: user, content: 返回 pong}] }如果返回里有choices字段和内容说明通道正常。这一步能挡掉大部分后面的 401 和 reading choices 报错。第二步确认 CTFd 能拉到题。用 CTFd 的 API 直接查一次curl https://ctf.example.com/api/v1/challenges \ -H Authorization: Token ctfd_your_token_here返回题目列表就说明 token 有效。如果返回 403 或空列表检查 token 权限和比赛是否开放。第三步启动 ctf-agent观察日志uv run ctf-solve \ --ctfd-url https://ctf.example.com \ --ctfd-token ctfd_your_token_here \ --challenges-dir challenges \ --max-challenges 3 \ --coordinator claude \ -v正常日志会依次出现Poller 轮询到新题、创建 challenge 目录、拉起 Solver 容器、Solver 调用模型、返回尝试结果。如果某道题解出日志里会有 flag 提交记录CTFd 平台上该题状态变为已解。第四步检查沙箱。每个 Solver 在独立容器里跑可以用docker ps看容器是否正常启动。如果容器起不来多半是镜像没构建成功回到docker build -f sandbox/Dockerfile.sandbox -t ctf-sandbox .重新构建。一次成功的验证你会看到类似这样的链路题目下发 → 轮询发现 → Solver 启动 → 模型返回 → flag 提交 → 平台状态更新。跑通这一条后面的并发放大就是改--max-challenges的事。提示第一次验证建议用一道简单题比如 misc 或 web 入门题别一上来就 pwn。简单题能快速确认链路复杂题容易把链路问题和题目难度混在一起。5. 常见报错排查401、local proxy failed、reading choices、OAuth这一节对照真实报错给排查路径。ctf-agent 接 CTFd 加统一 Key最容易在这几个地方翻车。401 Unauthorized。两种可能模型通道的 Key 错或 CTFd 的 token 错。先分清是哪个 401。如果日志里是调用模型时报 401检查.env里的OPENAI_API_KEY和OPENAI_BASE_URL是否配对Base URL 是不是https://taotoken.net/api。如果日志里是拉题目时报 401检查CTFD_TOKEN是否有效、有没有多余空格。三件套Base URL、Key、Model ID缺一个或写错一个都会 401。local proxy failed。这个报错通常出现在 Solver 容器内访问外部通道时。原因是容器网络没配好或者 Base URL 在容器里不可达。排查顺序先在宿主机 curl 一次 TaoToken 的 API确认宿主机通再进容器docker exec -it container sh在容器里 curl 一次。如果宿主机通、容器不通检查 Docker 网络模式。别在容器里配任何网络代理类的东西直接确认 DNS 和出网即可。reading choices 报错。这个多半是模型返回格式不符合预期常见原因是 Model ID 写错或者通道返回了非标准结构。先在模型对话页用同一个 Model ID 发一句测试确认返回里有标准choices。如果对话页正常、ctf-agent 里报错检查 ctf-agent 用的模型名和对话页是否一致。有些 Solver 走 OpenAI 兼容协议Model ID 要和通道支持的名称对齐。OAuth 相关报错。如果你用 Claude Code 或 Codex 作为 Coordinator可能碰到 OAuth 登录态问题。这类情况不要走交互式登录直接用 API Key 方式配置。Claude Code 的接入方式看文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite Codex 的auth.json按第 3 节的写法填全三件套。OAuth 报错的核心是登录态和 API Key 混用统一用 Key 就干净了。容器起不来。检查docker build是否成功镜像名是否和启动参数一致。如果构建时拉依赖失败重试一次或换网络环境。沙箱镜像比较大第一次构建慢是正常的。Poller 不轮询。检查POLL_INTERVAL和 CTFd 地址。如果日志里没有轮询记录多半是 CTFd 地址写错或 token 无效。先用 curl 验证 CTFd API再启动 ctf-agent。排查的核心思路先分层再定位。模型通道一层、CTFd 一层、容器一层每层单独验证别混在一起猜。6. 长期跑 CTF 与 Agent 调度把统一 Key 用稳跑通一次验证之后如果你打算长期用 ctf-agent 做训练或比赛辅助重点就从「能不能跑」转到「跑得稳不稳、成本可不可控」。这一节讲几个实战经验。第一按角色分 Key。Solver 和 Coordinator 用不同的 Key方便在控制台分别看用量。Solver 并发高、调用频繁Coordinator 调用少但单次上下文大。分开之后某个角色异常不会影响另一个。API Keys 页面可以随时创建和吊销https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。第二控制并发上限。--max-challenges是硬上限但每个 challenge 内部可能还有多个 Solver。比赛时先小规模试跑估算 token 消耗和容器资源再逐步放大。多模型竞速意味着多份模型消耗这点要有预期。第三保留人工观察窗口。ctf-agent 支持人工介入比赛中可以给正在跑的 Solver 发提示。别完全无人值守尤其是复杂题人的方向判断往往比模型试错更省成本。第四沙箱隔离要到位。Docker 能隔离大部分执行环境但不要把真实密钥、个人文件和生产网络暴露给比赛题目。建议用一次性虚拟机或专用环境跑赛后清理。第五长期高频场景看 Coding Plan。如果你不只是打比赛还用它做 Agent 调度研究或日常训练Coding Plan 比按次调用更合适https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。接入细节以文档为准https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。最后说个实际感受ctf-agent 把 CTF 解题从「单模型问答」推进到了「多模型竞速系统」而统一 Key 通道是这套系统能稳定跑起来的地基。Base URL、Key、Model ID 这三件套配好剩下的就是调并发和看日志。跑通一次完整闭环之后你会发现真正花时间的不是配置而是理解每道题的调度策略和成本控制。