1. DevDay 2025 之后本地工程里最该先跑通的三条线OpenAI DevDay 2025 发布的东西不少但如果你是一个需要在本地工程里快速验证新能力的开发者真正值得先动手的其实就三条线Apps SDK、AgentKit、Codex SDK。Apps SDK 解决的是「怎么把外部能力塞进 ChatGPT 的对话流里」AgentKit 解决的是「怎么让模型自己拆任务、调工具、跑完一整条链路」Codex SDK 解决的是「怎么把代码生成和自动化任务接进现有工程」。这三个东西单独看文档都不难难的是把它们放进同一个本地项目里用同一套 Key 管理方式跑通而不是每接一个 SDK 就换一套鉴权、换一套 base_url、换一套调试习惯。我这边的做法是本地只维护一份统一的服务端 Key 配置三个 SDK 都通过同一个入口去拿模型能力这样验证阶段不用反复改环境变量也不会因为某个 SDK 的默认 endpoint 不同而把请求打到意料之外的地方。下面按「先统一入口再分别跑通三条线」的顺序来写每一步都给可复制的配置骨架和验证动作。你不需要一次全做完可以按 Apps SDK → AgentKit → Codex SDK 的顺序逐个确认。2. 前置用 TaoToken 统一 Key 接管三个 SDK 的模型调用2.1 为什么验证阶段不建议每个 SDK 单独配 KeyApps SDK、AgentKit、Codex SDK 在本地验证时都会发起模型请求但它们默认读取配置的位置不一样有的走环境变量有的走项目内 settings.json有的走 config.toml。如果你每个都单独填一次官方 Key会出现三个问题第一Key 散落在多个文件里改一次要改三处第二不同 SDK 的默认 base_url 不同调试时很难判断请求到底发到了哪里第三一旦某个 SDK 的调用量上来了你没法在一个地方看整体消耗。统一入口的思路是本地所有 SDK 的模型请求都指向同一个兼容端点Key 也只维护一份。TaoToken 在这里的角色就是提供这个统一入口它的 API 地址是https://taotoken.net/api你可以在控制台生成一个 Key然后让三个 SDK 都读同一个环境变量。2.2 拿 Key 和确认端点先到控制台创建 API Key地址是https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite。创建完之后本地只需要记住两个值配置项值API Key控制台生成的 sk- 开头字符串Base URLhttps://taotoken.net/api如果你后面要接 Claude Code 这类编码工具Anthropic 兼容入口的说明在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite但本篇主要走 OpenAI 兼容这条线三个 SDK 都用同一个 base_url 即可。2.3 本地环境变量骨架在项目根目录建一个.env.local只放两个变量# .env.local TAOTOKEN_API_KEYsk-你的Key TAOTOKEN_BASE_URLhttps://taotoken.net/api然后在 shell 里导出或者用 dotenv 加载。后面所有 SDK 的配置都引用这两个变量不写死具体值。这样做的直接好处是你换 Key 或者换端点时只改一个文件三个 SDK 同时生效。3. Apps SDKsettings.json 骨架与本地验证3.1 Apps SDK 在本地工程里的定位Apps SDK 的核心是让你在 ChatGPT 里挂一个可交互的应用它需要一份 App Manifest 来描述你的应用能力还需要一个本地服务来响应调用。验证阶段你不需要真的发布到 ChatGPT只要本地能把 manifest 加载起来、能响应一次工具调用就说明链路通了。3.2 settings.json 可复制骨架在项目里建apps-sdk/settings.json内容如下{ app: { name: local-devday-demo, version: 0.1.0, manifest: ./manifest.json }, model: { provider: openai-compatible, base_url: ${TAOTOKEN_BASE_URL}, api_key: ${TAOTOKEN_API_KEY}, default_model: gpt-5-pro }, server: { host: 127.0.0.1, port: 8787 } }这里的关键点是provider写成openai-compatiblebase_url和api_key都引用环境变量。Apps SDK 在启动时会读取这份配置把模型请求发到统一端点。3.3 manifest.json 最小示例同目录下建manifest.json{ schema_version: v1, name: local-devday-demo, description: DevDay 2025 Apps SDK 本地验证, tools: [ { name: echo, description: 回显输入内容, parameters: { type: object, properties: { text: { type: string } }, required: [text] } } ] }这个 manifest 只声明了一个 echo 工具目的是让 Apps SDK 有东西可加载。你后面可以按同样结构加真实工具。3.4 启动与验证动作启动本地服务cd apps-sdk npx apps-sdk dev --settings ./settings.json预期输出里会出现listening on 127.0.0.1:8787和manifest loaded: local-devday-demo。然后另开一个终端发一次工具调用请求curl -s http://127.0.0.1:8787/tools/echo \ -H Content-Type: application/json \ -d {text:devday-2025}如果返回{echo:devday-2025}说明 Apps SDK 的本地加载和工具响应都通了。这一步不涉及模型请求但它是后面 AgentKit 调用的基础。4. AgentKitconfig.toml 骨架与任务链路验证4.1 AgentKit 验证的重点是什么AgentKit 的重点不是单次模型调用而是「任务拆解 → 工具选择 → 执行 → 汇总」这条链路。本地验证时你不需要接真实业务工具只要让 AgentKit 能读到配置、能选到一个工具、能返回结果就说明链路是通的。4.2 config.toml 可复制骨架在项目里建agentkit/config.toml[model] provider openai-compatible base_url ${TAOTOKEN_BASE_URL} api_key ${TAOTOKEN_API_KEY} model gpt-5-pro [agent] name local-agent max_steps 5 tool_choice auto [[tools]] name echo type http endpoint http://127.0.0.1:8787/tools/echo method POST这里把 AgentKit 的工具直接指向 Apps SDK 本地服务暴露的 echo 接口这样两个 SDK 就串起来了AgentKit 负责决策Apps SDK 负责执行。4.3 运行一次任务cd agentkit npx agentkit run --config ./config.toml \ --task 调用 echo 工具把 devday-agentkit 回显出来预期你会看到类似输出[step 1] selected tool: echo [step 1] tool result: {echo:devday-agentkit} [final] devday-agentkit如果卡在selected tool之后没有结果先检查 Apps SDK 的本地服务是否还在运行再检查 config.toml 里的 endpoint 端口是否一致。AgentKit 本身不报工具连接错误时通常就是 endpoint 写错了。4.4 和 Apps SDK 的联动意义这一步跑通之后你实际上已经有了一个最小可用的「Agent 工具」闭环。后面你要接真实工具只需要把[[tools]]里的 endpoint 换成你自己的服务地址模型侧不用改。这也是 DevDay 2025 里 AgentKit 和 Apps SDK 深度集成的实际含义工具执行层和决策层可以分开部署、分开调试。5. Codex SDK把代码生成接进现有工程5.1 Codex SDK 在本地工程里的接入点Codex SDK 的定位是代码生成和自动化任务。本地验证时你不需要它真的改你的仓库只要它能读到配置、能对一段代码生成补全或解释就说明接入成功。5.2 初始化与配置npm init -y npm install openai/codex-sdk建一个codex-demo.mjsimport { Codex } from openai/codex-sdk; const codex new Codex({ apiKey: process.env.TAOTOKEN_API_KEY, baseURL: process.env.TAOTOKEN_BASE_URL, model: gpt-5-pro, }); const result await codex.complete({ prompt: 用 JavaScript 写一个函数输入数组返回去重后的数组, language: javascript, }); console.log(result.text);5.3 运行与预期结果node codex-demo.mjs预期输出是一段可运行的 JavaScript 去重函数。如果返回的是鉴权错误先确认.env.local已经加载如果返回的是模型不存在检查model字段是否写成了当前可用的模型名。Codex SDK 本身不负责加载 dotenv你需要在运行前手动 export或者在脚本顶部加import dotenv/config。5.4 三个 SDK 的配置对照SDK配置文件关键字段验证动作Apps SDKsettings.jsonbase_url / api_keycurl 本地工具接口AgentKitconfig.tomlbase_url / api_key / tools运行一次带工具的任务Codex SDK代码内初始化baseURL / apiKey生成一段代码并运行三者的共同点是都读同一组环境变量这样你在本地只需要维护一份 Key。6. 本篇常见错排查6.1 请求返回 401 或鉴权失败最常见的原因是环境变量没有真正加载。settings.json和config.toml里的${TAOTOKEN_API_KEY}是占位符需要你的运行环境支持变量替换。如果你直接node跑脚本先确认echo $TAOTOKEN_API_KEY有输出。另一个原因是 Key 复制时带了空格建议重新从控制台复制一次。6.2 请求发到了意料之外的端点如果你没有显式设置 base_url某些 SDK 会走默认官方端点。表现是Key 是对的但请求失败或者计费出现在别处。排查方法是打开 SDK 的 debug 日志确认实际请求的 host 是taotoken.net。Apps SDK 可以在 settings.json 里加debug: trueAgentKit 用--verbose运行。6.3 AgentKit 选不到工具先确认 Apps SDK 的本地服务在运行再用 curl 直接打一次工具接口。如果 curl 通、AgentKit 不通检查 config.toml 里 endpoint 的协议和端口。如果 curl 也不通说明 Apps SDK 服务没起来回到第 3 章重新启动。6.4 Codex SDK 返回空结果空结果通常不是鉴权问题而是 prompt 太短或者模型选择不对。先把 prompt 写具体一点比如加上输入输出示例。如果还是空换一个模型名再试。Codex SDK 对模型名比较敏感写错不会报错只会返回空。6.5 三个 SDK 同时跑时端口冲突Apps SDK 默认 8787如果你本地已经有服务占用这个端口启动会失败。改 settings.json 里的 port同时把 AgentKit config.toml 里的 endpoint 改成同一个新端口。两个文件要同步改否则 AgentKit 会连到旧端口。7. 验证完之后怎么继续往下走三条线都跑通之后你手里其实已经有了一个最小可用的本地验证环境Apps SDK 提供工具执行层AgentKit 提供决策层Codex SDK 提供代码生成能力三者共用一套 Key 和端点。接下来你可以按自己的项目需要把 echo 工具换成真实业务接口或者把 Codex SDK 接进 CI 流程做自动化代码检查。如果你在排障过程中需要确认 Key 和端点的对应关系可以直接到 API Keys 页面核对https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite。接入文档里对 OpenAI 兼容端点的说明在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite遇到配置字段不确定时优先查这份文档。如果你更想先直观感受一下模型对话的效果可以到模型对话页面试一次https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite。而如果你打算把 Codex SDK 和 AgentKit 长期用在日常编码和自动化任务里Coding Plan 的入口在https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite可以先看套餐再决定怎么接。
1. DevDay 2025 之后本地工程里最该先跑通的三条线OpenAI DevDay 2025 发布的东西不少但如果你是一个需要在本地工程里快速验证新能力的开发者真正值得先动手的其实就三条线Apps SDK、AgentKit、Codex SDK。Apps SDK 解决的是「怎么把外部能力塞进 ChatGPT 的对话流里」AgentKit 解决的是「怎么让模型自己拆任务、调工具、跑完一整条链路」Codex SDK 解决的是「怎么把代码生成和自动化任务接进现有工程」。这三个东西单独看文档都不难难的是把它们放进同一个本地项目里用同一套 Key 管理方式跑通而不是每接一个 SDK 就换一套鉴权、换一套 base_url、换一套调试习惯。我这边的做法是本地只维护一份统一的服务端 Key 配置三个 SDK 都通过同一个入口去拿模型能力这样验证阶段不用反复改环境变量也不会因为某个 SDK 的默认 endpoint 不同而把请求打到意料之外的地方。下面按「先统一入口再分别跑通三条线」的顺序来写每一步都给可复制的配置骨架和验证动作。你不需要一次全做完可以按 Apps SDK → AgentKit → Codex SDK 的顺序逐个确认。2. 前置用 TaoToken 统一 Key 接管三个 SDK 的模型调用2.1 为什么验证阶段不建议每个 SDK 单独配 KeyApps SDK、AgentKit、Codex SDK 在本地验证时都会发起模型请求但它们默认读取配置的位置不一样有的走环境变量有的走项目内 settings.json有的走 config.toml。如果你每个都单独填一次官方 Key会出现三个问题第一Key 散落在多个文件里改一次要改三处第二不同 SDK 的默认 base_url 不同调试时很难判断请求到底发到了哪里第三一旦某个 SDK 的调用量上来了你没法在一个地方看整体消耗。统一入口的思路是本地所有 SDK 的模型请求都指向同一个兼容端点Key 也只维护一份。TaoToken 在这里的角色就是提供这个统一入口它的 API 地址是https://taotoken.net/api你可以在控制台生成一个 Key然后让三个 SDK 都读同一个环境变量。2.2 拿 Key 和确认端点先到控制台创建 API Key地址是https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite。创建完之后本地只需要记住两个值配置项值API Key控制台生成的 sk- 开头字符串Base URLhttps://taotoken.net/api如果你后面要接 Claude Code 这类编码工具Anthropic 兼容入口的说明在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite但本篇主要走 OpenAI 兼容这条线三个 SDK 都用同一个 base_url 即可。2.3 本地环境变量骨架在项目根目录建一个.env.local只放两个变量# .env.local TAOTOKEN_API_KEYsk-你的Key TAOTOKEN_BASE_URLhttps://taotoken.net/api然后在 shell 里导出或者用 dotenv 加载。后面所有 SDK 的配置都引用这两个变量不写死具体值。这样做的直接好处是你换 Key 或者换端点时只改一个文件三个 SDK 同时生效。3. Apps SDKsettings.json 骨架与本地验证3.1 Apps SDK 在本地工程里的定位Apps SDK 的核心是让你在 ChatGPT 里挂一个可交互的应用它需要一份 App Manifest 来描述你的应用能力还需要一个本地服务来响应调用。验证阶段你不需要真的发布到 ChatGPT只要本地能把 manifest 加载起来、能响应一次工具调用就说明链路通了。3.2 settings.json 可复制骨架在项目里建apps-sdk/settings.json内容如下{ app: { name: local-devday-demo, version: 0.1.0, manifest: ./manifest.json }, model: { provider: openai-compatible, base_url: ${TAOTOKEN_BASE_URL}, api_key: ${TAOTOKEN_API_KEY}, default_model: gpt-5-pro }, server: { host: 127.0.0.1, port: 8787 } }这里的关键点是provider写成openai-compatiblebase_url和api_key都引用环境变量。Apps SDK 在启动时会读取这份配置把模型请求发到统一端点。3.3 manifest.json 最小示例同目录下建manifest.json{ schema_version: v1, name: local-devday-demo, description: DevDay 2025 Apps SDK 本地验证, tools: [ { name: echo, description: 回显输入内容, parameters: { type: object, properties: { text: { type: string } }, required: [text] } } ] }这个 manifest 只声明了一个 echo 工具目的是让 Apps SDK 有东西可加载。你后面可以按同样结构加真实工具。3.4 启动与验证动作启动本地服务cd apps-sdk npx apps-sdk dev --settings ./settings.json预期输出里会出现listening on 127.0.0.1:8787和manifest loaded: local-devday-demo。然后另开一个终端发一次工具调用请求curl -s http://127.0.0.1:8787/tools/echo \ -H Content-Type: application/json \ -d {text:devday-2025}如果返回{echo:devday-2025}说明 Apps SDK 的本地加载和工具响应都通了。这一步不涉及模型请求但它是后面 AgentKit 调用的基础。4. AgentKitconfig.toml 骨架与任务链路验证4.1 AgentKit 验证的重点是什么AgentKit 的重点不是单次模型调用而是「任务拆解 → 工具选择 → 执行 → 汇总」这条链路。本地验证时你不需要接真实业务工具只要让 AgentKit 能读到配置、能选到一个工具、能返回结果就说明链路是通的。4.2 config.toml 可复制骨架在项目里建agentkit/config.toml[model] provider openai-compatible base_url ${TAOTOKEN_BASE_URL} api_key ${TAOTOKEN_API_KEY} model gpt-5-pro [agent] name local-agent max_steps 5 tool_choice auto [[tools]] name echo type http endpoint http://127.0.0.1:8787/tools/echo method POST这里把 AgentKit 的工具直接指向 Apps SDK 本地服务暴露的 echo 接口这样两个 SDK 就串起来了AgentKit 负责决策Apps SDK 负责执行。4.3 运行一次任务cd agentkit npx agentkit run --config ./config.toml \ --task 调用 echo 工具把 devday-agentkit 回显出来预期你会看到类似输出[step 1] selected tool: echo [step 1] tool result: {echo:devday-agentkit} [final] devday-agentkit如果卡在selected tool之后没有结果先检查 Apps SDK 的本地服务是否还在运行再检查 config.toml 里的 endpoint 端口是否一致。AgentKit 本身不报工具连接错误时通常就是 endpoint 写错了。4.4 和 Apps SDK 的联动意义这一步跑通之后你实际上已经有了一个最小可用的「Agent 工具」闭环。后面你要接真实工具只需要把[[tools]]里的 endpoint 换成你自己的服务地址模型侧不用改。这也是 DevDay 2025 里 AgentKit 和 Apps SDK 深度集成的实际含义工具执行层和决策层可以分开部署、分开调试。5. Codex SDK把代码生成接进现有工程5.1 Codex SDK 在本地工程里的接入点Codex SDK 的定位是代码生成和自动化任务。本地验证时你不需要它真的改你的仓库只要它能读到配置、能对一段代码生成补全或解释就说明接入成功。5.2 初始化与配置npm init -y npm install openai/codex-sdk建一个codex-demo.mjsimport { Codex } from openai/codex-sdk; const codex new Codex({ apiKey: process.env.TAOTOKEN_API_KEY, baseURL: process.env.TAOTOKEN_BASE_URL, model: gpt-5-pro, }); const result await codex.complete({ prompt: 用 JavaScript 写一个函数输入数组返回去重后的数组, language: javascript, }); console.log(result.text);5.3 运行与预期结果node codex-demo.mjs预期输出是一段可运行的 JavaScript 去重函数。如果返回的是鉴权错误先确认.env.local已经加载如果返回的是模型不存在检查model字段是否写成了当前可用的模型名。Codex SDK 本身不负责加载 dotenv你需要在运行前手动 export或者在脚本顶部加import dotenv/config。5.4 三个 SDK 的配置对照SDK配置文件关键字段验证动作Apps SDKsettings.jsonbase_url / api_keycurl 本地工具接口AgentKitconfig.tomlbase_url / api_key / tools运行一次带工具的任务Codex SDK代码内初始化baseURL / apiKey生成一段代码并运行三者的共同点是都读同一组环境变量这样你在本地只需要维护一份 Key。6. 本篇常见错排查6.1 请求返回 401 或鉴权失败最常见的原因是环境变量没有真正加载。settings.json和config.toml里的${TAOTOKEN_API_KEY}是占位符需要你的运行环境支持变量替换。如果你直接node跑脚本先确认echo $TAOTOKEN_API_KEY有输出。另一个原因是 Key 复制时带了空格建议重新从控制台复制一次。6.2 请求发到了意料之外的端点如果你没有显式设置 base_url某些 SDK 会走默认官方端点。表现是Key 是对的但请求失败或者计费出现在别处。排查方法是打开 SDK 的 debug 日志确认实际请求的 host 是taotoken.net。Apps SDK 可以在 settings.json 里加debug: trueAgentKit 用--verbose运行。6.3 AgentKit 选不到工具先确认 Apps SDK 的本地服务在运行再用 curl 直接打一次工具接口。如果 curl 通、AgentKit 不通检查 config.toml 里 endpoint 的协议和端口。如果 curl 也不通说明 Apps SDK 服务没起来回到第 3 章重新启动。6.4 Codex SDK 返回空结果空结果通常不是鉴权问题而是 prompt 太短或者模型选择不对。先把 prompt 写具体一点比如加上输入输出示例。如果还是空换一个模型名再试。Codex SDK 对模型名比较敏感写错不会报错只会返回空。6.5 三个 SDK 同时跑时端口冲突Apps SDK 默认 8787如果你本地已经有服务占用这个端口启动会失败。改 settings.json 里的 port同时把 AgentKit config.toml 里的 endpoint 改成同一个新端口。两个文件要同步改否则 AgentKit 会连到旧端口。7. 验证完之后怎么继续往下走三条线都跑通之后你手里其实已经有了一个最小可用的本地验证环境Apps SDK 提供工具执行层AgentKit 提供决策层Codex SDK 提供代码生成能力三者共用一套 Key 和端点。接下来你可以按自己的项目需要把 echo 工具换成真实业务接口或者把 Codex SDK 接进 CI 流程做自动化代码检查。如果你在排障过程中需要确认 Key 和端点的对应关系可以直接到 API Keys 页面核对https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite。接入文档里对 OpenAI 兼容端点的说明在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite遇到配置字段不确定时优先查这份文档。如果你更想先直观感受一下模型对话的效果可以到模型对话页面试一次https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentchatutm_campaignrewrite。而如果你打算把 Codex SDK 和 AgentKit 长期用在日常编码和自动化任务里Coding Plan 的入口在https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite可以先看套餐再决定怎么接。
与自动换行原理)
