1. 这条日报为什么值得每个开发者认真读一遍9月23日早上刷到这条日报的时候我正蹲在工位上给一个 Agent 项目调 API 重试逻辑。标题里两个信息点直接把我从椅子上拽了起来GPT-6 Sol 与 Luna 双模型发布以及API 起步价降到每百万输入 Token 0.10 美元。前者意味着模型能力分层策略又变了后者意味着很多原本跑不起的 Agent 场景突然变得经济可行。先把这条日报的核心信息拆开说清楚。OpenAI 这次不是发一个模型而是发了一对Sol和Luna。从命名和公开的能力描述来看Sol 偏向高强度推理、复杂任务编排、长链路 Agent 执行Luna 偏向轻量、低延迟、高并发调用适合做分类、抽取、路由、简单对话这类高频低难度的活。这种一大一小的双模型组合其实在业内已经不算新鲜但 OpenAI 把它做成官方 API 的默认搭配并且把起步价压到 0.10 美元/百万输入 Token这个组合拳的杀伤力就完全不一样了。为什么这么说你可以算一笔账。假设你做一个客服 Agent每天处理 10 万次对话每次对话平均输入 2000 Token、输出 500 Token。用 Luna 做意图识别和路由用 Sol 做复杂问题的深度处理整体输入成本按 0.10 美元/百万 Token 算一天输入侧成本大概是 20 美元出头。这个数字放在两年前连一个中等规模项目的零头都不够。成本结构的改变直接决定了哪些产品形态能活下来——这是我做 Agent 这几年最深的体会。这条日报适合谁来读三类人。第一类是正在做Agent 开发的工程师你需要重新评估你的模型路由策略和成本模型第二类是产品经理和独立开发者你需要知道现在哪些以前想想就算了的场景变得可落地了第三类是刚入门想学API 调用的新手这条日报里的价格和模型分层是你理解整个行业走向的最好切口。下面我按自己的实操经验把这条日报背后的东西一层层扒开。2. GPT-6 Sol 与 Luna 的双模型分层到底怎么理解2.1 为什么是双模型而不是一个更强的模型很多人第一反应是为什么不直接发一个又强又便宜的模型这个问题我当年也问过自己。答案藏在推理成本和任务分布这两个词里。真实业务里的请求从来不是均匀分布的。我做过一个统计一个典型的 Agent 系统里大约 70% 到 80% 的请求是简单任务——判断用户意图、抽取结构化字段、做一次格式转换、回答一个 FAQ。这些任务用大模型跑属于典型的杀鸡用牛刀又慢又贵。剩下 20% 到 30% 才是真正需要深度推理的复杂任务。如果只有一个模型你要么全部用强的贵、慢要么全部用弱的复杂任务做不好。双模型分层的本质是让你按任务难度付费。Sol 负责那 20% 到 30% 的硬骨头Luna 负责剩下 70% 到 80% 的日常活。这不是技术炫技是成本工程。2.2 Sol 和 Luna 的能力边界怎么划根据公开信息和我在类似分层模型上的实测经验这两个模型的定位大致是这样的维度SolLuna定位复杂推理、长链路 Agent高频轻量、低延迟典型任务多步规划、代码生成、深度分析意图识别、字段抽取、路由分发上下文窗口大适合长文档、长对话中等够用即可延迟较高低成本相对高极低起步 0.10 美元/百万输入 Token适用并发中低高这张表不是让你死记而是让你建立**任务-模型映射的直觉**。我踩过的一个坑就是早期做 Agent 的时候所有请求都走同一个模型结果月底账单出来发现 80% 的钱花在了你好帮我查一下这种请求上。后来做了分层路由成本直接砍掉六成多。2.3 分层路由的核心逻辑分层路由听起来高级其实核心就一句话先用便宜模型判断任务难度再决定要不要升级到贵模型。具体怎么做我常用的模式是Luna 前置 Sol 兜底。用户请求进来先给 Luna 一个轻量 prompt让它输出一个难度标签simple / complex和一个置信度。如果标签是 simple 且置信度高直接由 Luna 处理完返回如果标签是 complex 或者置信度低转给 Sol 处理。这个模式的关键在于路由 prompt 要足够短。我见过有人写了一个 800 Token 的路由 prompt结果路由本身的成本就快赶上直接调用了。路由 prompt 控制在 100 Token 以内效果和成本才平衡。下面是一个我实际用过的路由 prompt 结构ROUTER_PROMPT 判断以下用户请求的复杂度只输出一个词 simple - 简单问答、字段抽取、格式转换、意图识别 complex - 多步推理、代码生成、长文档分析、需要规划的任务 用户请求{user_input} 复杂度这个 prompt 短、明确、输出可控。实测下来路由准确率能到 90% 以上剩下 10% 的误判由兜底逻辑接住整体体验不受影响。3. API 起步价 0.10 美元背后的成本账怎么算3.1 Token 计费的基本逻辑先把基础讲清楚因为很多新手对Token的理解是模糊的。Token 不是字也不是词它是模型处理文本的最小单位。英文里大概 1 个 Token 等于 0.75 个单词中文里 1 个汉字大约对应 1 到 2 个 Token取决于分词方式。API 计费分两块输入 Token和输出 Token。输入是你发给模型的prompt、上下文、历史对话输出是模型生成的。这次日报里说的起步价每百万输入 Token 0.10 美元指的是输入侧的最低档价格。输出侧通常更贵因为生成比读取更耗算力。3.2 一个真实的成本测算我拿一个实际项目来算。假设你做一个文档问答 Agent每天 5000 次请求每次请求包含系统 prompt300 Token检索到的文档片段3000 Token用户问题100 Token模型输出400 Token那么单次请求输入是 3400 Token输出 400 Token。按 Luna 的 0.10 美元/百万输入 Token 算单次输入成本3400 / 1,000,000 × 0.10 0.00034 美元5000 次一天输入成本1.7 美元输出侧假设按 0.40 美元/百万 Token 算这是常见比例单次输出成本400 / 1,000,000 × 0.40 0.00016 美元5000 次一天输出成本0.8 美元一天总成本 2.5 美元左右一个月不到 80 美元。这个数字在几年前是不可想象的。成本降下来之后很多原本算不过账的场景就活了比如给每个用户配一个常驻 Agent、做全量对话日志的实时分析、给内部工具加自然语言入口。3.3 成本优化的三个实操技巧第一个技巧上下文裁剪。很多人把整个对话历史一股脑塞进去Token 哗哗地烧。我的做法是只保留最近 N 轮对话更早的用摘要替代。摘要本身也用 Luna 生成成本极低。第二个技巧缓存高频请求。系统 prompt、固定的知识片段、常见的 FAQ 回答这些内容每次请求都一样完全可以做本地缓存或者用 API 的缓存机制。我实测过光是把系统 prompt 做缓存输入 Token 就能省 20% 到 30%。第三个技巧输出长度控制。在 prompt 里明确要求简洁回答不超过 X 字能显著降低输出 Token。输出比输入贵控制输出长度的性价比很高。提示不要为了省钱把 prompt 压得太狠。我见过有人把系统 prompt 砍到只剩一句话结果模型行为不稳定返工成本远高于省下的那点 Token 钱。省钱的边界是不影响效果。4. Agent 开发在 GPT-6 时代的架构变化4.1 Agent 的核心循环Agent这个词被用烂了但它的核心其实很简单感知 - 规划 - 执行 - 观察的循环。用户给一个目标Agent 拆解成步骤调用工具执行观察结果再决定下一步直到目标完成。GPT-6 Sol 这种强推理模型对 Agent 的意义在于规划环节的质量直接决定整个 Agent 的上限。规划错了后面执行再快也是白搭。Sol 在长链路规划上的能力提升让 Agent 能处理更复杂的任务比如帮我分析这份财报找出三个风险点并生成一份给管理层的简报这种多步任务。4.2 双模型在 Agent 架构里的分工在一个完整的 Agent 系统里Sol 和 Luna 的分工可以这样设计Luna 负责意图识别、工具选择的路由、简单工具调用的参数抽取、结果格式化、对话状态管理Sol 负责任务规划、多步推理、复杂工具链的编排、最终结果的深度加工我实际搭过的一个 Agent 架构是这样的用户输入先进 Luna 做意图分类如果是简单查询直接走工具返回如果是复杂任务交给 Sol 做规划规划出的每一步再根据难度决定用哪个模型执行。这个架构的好处是贵模型只用在刀刃上。4.3 工具调用的稳定性问题Agent 开发里最烦的不是模型不够聪明而是工具调用不稳定。模型有时候会编造不存在的工具名有时候参数格式不对有时候该调用工具却直接回答了。这些问题在 GPT-6 时代有没有改善从公开信息看工具调用的可靠性是这代模型的重点优化方向之一但工程侧的防御性设计依然不能省。我的做法是三层防御第一层工具定义用严格的 JSON Schema参数类型、必填项、枚举值都写清楚第二层模型返回的工具调用做校验格式不对就重试第三层设置最大循环次数防止 Agent 陷入死循环烧钱。第三层特别重要我见过一个 Agent 因为工具一直返回错误自己循环调用了上百次账单直接爆了。MAX_ITERATIONS 10 for i in range(MAX_ITERATIONS): response call_model(messages, toolstools) if response.finish_reason stop: break if response.tool_calls: results execute_tools(response.tool_calls) messages.extend(results) else: # 超过最大循环强制终止并返回当前结果 return fallback_response(messages)这段代码看着简单但那个else分支救过我好几次。5. 从零搭建一个双模型 Agent 的实操过程5.1 环境准备与依赖安装先说环境。我用的是 Python依赖主要是官方 SDK 和几个工具库。安装命令很直接pip install openai python-dotenv tenacitytenacity是用来做重试的API 调用难免遇到网络抖动或者限流没有重试机制的系统在生产环境活不过一天。API Key 我习惯放在.env文件里用python-dotenv加载绝对不硬编码在代码里——这是血泪教训我曾经把一个带 Key 的脚本推到公开仓库十分钟内就被扫到并盗用了。import os from dotenv import load_dotenv from openai import OpenAI load_dotenv() client OpenAI(api_keyos.getenv(OPENAI_API_KEY))5.2 双模型路由的实现路由函数是整个系统的核心。我的实现思路是先用 Luna 做一次快速判断根据返回的难度标签决定后续走哪个模型。def route_request(user_input: str) - str: resp client.chat.completions.create( modelgpt-6-luna, messages[ {role: system, content: ROUTER_PROMPT}, {role: user, content: user_input} ], max_tokens10, temperature0 ) label resp.choices[0].message.content.strip().lower() return sol if complex in label else luna这里有几个细节值得说。max_tokens10是因为路由只需要输出一个词给多了浪费temperature0是让输出稳定路由这种判断任务不需要创造性返回结果做一次lower()和包含判断是为了容错模型偶尔会输出 Complex 或者 complex. 这种带标点的。5.3 主处理流程与重试机制主流程根据路由结果调用对应模型外面套一层重试。重试策略我用的是指数退避第一次等 1 秒第二次 2 秒第三次 4 秒最多重试 3 次。from tenacity import retry, stop_after_attempt, wait_exponential retry(stopstop_after_attempt(3), waitwait_exponential(multiplier1, min1, max8)) def call_model(model: str, messages: list) - str: resp client.chat.completions.create( modelmodel, messagesmessages, temperature0.7 ) return resp.choices[0].message.content def handle(user_input: str) - str: target route_request(user_input) model gpt-6-sol if target sol else gpt-6-luna return call_model(model, [{role: user, content: user_input}])这套代码不复杂但覆盖了路由、调用、重试三个关键环节。实测下来在正常负载下稳定性很好。5.4 成本监控的埋点上线之后不看成本等于开车不看油表。我在每次调用后都记录 Token 用量和模型名定期汇总。def log_usage(model: str, usage): record { model: model, prompt_tokens: usage.prompt_tokens, completion_tokens: usage.completion_tokens, timestamp: time.time() } # 写入本地日志或数据库 save_record(record)有了这些数据你才能知道钱花在哪、哪个环节可以优化。我靠这个埋点发现过一个 bug某个工具调用的结果被重复塞进上下文导致输入 Token 翻倍修掉之后成本直接降了四成。6. 常见问题与排查技巧实录6.1 高频问题速查表问题现象可能原因排查方向401 未授权API Key 错误或过期检查 Key 是否有效、环境变量是否加载429 限流请求频率超限加退避重试、降低并发400 上下文超长输入 Token 超过模型上限裁剪上下文、做摘要模型返回空prompt 或参数问题检查 temperature、max_tokens工具调用格式错Schema 不严格收紧 JSON Schema、加校验成本异常高上下文膨胀或循环调用看埋点日志、设最大循环6.2 上下文超长的处理这是 Agent 开发里最常见的坑之一。长对话、大文档、多轮工具调用很容易把上下文撑爆。我的处理策略是分层裁剪最近的对话完整保留较早的对话做摘要工具返回的大结果只保留关键字段。摘要用 Luna 做成本低。我一般每 10 轮对话触发一次摘要把前 10 轮压缩成 200 字以内的要点。这样上下文能一直控制在合理范围内又不会丢失关键信息。6.3 模型偷懒不调用工具有时候模型明明该调用工具却直接编了一个答案。这种情况在复杂任务里尤其危险因为编造的答案看起来很合理。我的应对是在系统 prompt 里明确要求涉及实时数据、计算、外部查询时必须调用工具不得凭记忆回答同时在代码侧做校验如果任务类型标记为需要工具但模型没调用就强制重试一次并加强提示。6.4 踩过的坑路由误判的连锁反应有一次路由 prompt 写得太模糊Luna 把一个需要多步推理的任务判成了 simple结果 Luna 硬着头皮回答答案质量很差用户投诉。后来我加了一个置信度机制路由时让 Luna 同时输出置信度低于阈值的请求一律升级到 Sol。这个改动之后误判导致的差评基本消失了。注意路由的准确率不需要追求 100%但误判的代价要可控。把误判为简单的代价设计成多花点钱升级到 Sol而不是给出错误答案这个系统就是安全的。7. 这套东西后续还能怎么扩展7.1 多模型混合编排Sol 和 Luna 只是两个点实际生产里你可能还会接入其他模型做特定任务。比如代码生成用专门的代码模型图像理解用多模态模型。把路由层做成可配置的新增模型只需要加一条规则不用改主流程。我现在的做法是把模型配置抽成一个字典路由函数根据任务类型查表。7.2 Agent 的可观测性Agent 跑起来之后最难的是它到底在想什么。我建议从第一天就做可观测性记录每一步的输入输出、工具调用、耗时、Token 用量。这些数据不仅能排查问题还能用来优化 prompt 和路由策略。我靠这些日志发现过很多反直觉的问题比如某个工具的平均耗时是其他工具的五倍优化之后整体响应时间降了三成。7.3 从单 Agent 到多 Agent 协作当任务复杂度再上一个台阶单 Agent 就不够用了。多 Agent 协作是自然的演进方向一个规划 Agent 负责拆解任务多个执行 Agent 并行处理子任务一个汇总 Agent 负责整合结果。这种架构里Sol 适合做规划和汇总Luna 适合做执行。成本依然可控因为并行的执行任务大多是简单任务。我个人在实际操作中的体会是不要一上来就搞多 Agent。先把单 Agent 的路由、重试、监控做扎实等真的遇到单 Agent 处理不了的场景再考虑拆分。我见过太多项目架构图画得跟蜘蛛网一样结果连最基本的工具调用稳定性都没解决最后全推倒重来。技术选型要跟着问题走不是跟着概念走。