迁移前的幻觉以为只是换个模型名我第一次把 Agent 工作流里的gpt-5.5改成gpt-5.6-luna时心里想的很简单Luna 降价 80%GPT-5.5 的能力基线它也能达到那不就是免费升级跑起来的第一分钟就被打脸了。一个原本在 GPT-5.5 上稳定运行的多步骤数据分析 Agent在 Luna 手里变成了话痨但健忘的实习生——它能快速响应但执行到第三步就开始丢失第一步的上下文约束工具调用参数也开始出现低级错误。这不是模型质量问题是我对 Luna 的能力边界认知不足。这次迁移让我意识到从 GPT-5.5 到 Luna不是降级替换而是需要重新设计任务拆分粒度的架构重构。对奇点智能大会2026的完整技术议题感兴趣可前往奇点大会官方渠道免费获取PPT详细资料。Luna 的真实能力画像快在哪里短在哪里工具调用支持但别指望它自己看着办Luna 确实支持 Programmatic Tool Calling这是 GPT-5.6 全系的新特性。但支持程度和 Sol 有本质区别。在 Sol 上你可以给一个模糊目标——“分析这个仓库的安全漏洞生成修复建议”——它会自己编写轻量级程序来协调多个工具调用处理中间结果甚至根据进展动态调整下一步。Luna 也能走通同样的 API 流程但实际表现更像严格执行指令的脚本工人你给什么参数它执行什么遇到需要推断这里应该调用哪个工具的模糊地带出错率明显上升。具体到我自己的观察同样的三工具链代码检索 → 静态分析 → 报告生成在 GPT-5.5 上的端到端成功率约 85%在 Luna 上掉到 60% 左右。问题不是工具调用本身失败而是跨工具的结果关联和错误恢复——Luna 容易在第二步拿到异常输出后无法正确判断是重试、跳过还是换工具。多步骤推理第三步是道坎GPT-5.5 的长处之一是相对稳定的 5-7 步推理链。Luna 的架构明显为速度优化上下文窗口和推理深度都做了裁剪。实测下来三步以内的线性推理基本可靠超过三步且步骤间存在条件分支时状态丢失概率陡增。一个典型场景我的 Agent 需要先做意图分类再根据分类结果选择不同的处理分支最后汇总输出。在 GPT-5.5 上这个流程用一个 4-5 步的 prompt 就能稳定跑通。换到 Luna 后第三步根据分类结果选择分支经常变成忽略分类结果直接走默认分支。这不是 prompt 工程能完全解决的问题是模型本身的规划深度限制。长上下文保持轻量化有代价Luna 的上下文窗口没有官方公布具体数字但从实际表现推断有效上下文明显小于 GPT-5.5 的 128K。一个具体现象当我把 50 页左右的文档一次性塞进去做摘要时Luna 的速度优势非常明显但当我要求它在摘要中保留第 23 页提到的关键约束条件时它经常遗漏或张冠李戴。这说明 Luna 的长文本压缩能力强于细粒度检索能力——适合读完给结论不适合读完再精准定位。任务分级什么可以下放什么必须保留经过几轮踩坑我把 Agent 里的子任务按 Luna 的适配性做了重新分级。可以安全下放给 Luna 的任务任务类型具体场景关键控制点意图分类用户查询路由到不同处理模块分类标签必须穷举禁止开放式推断信息抽取从结构化/半结构化文本中提取字段抽取规则模板化减少理解自由度简单总结单文档摘要、会议纪要生成明确输出格式避免自由发挥轻量校验格式检查、必填项完整性验证校验规则原子化单条规则独立执行这些任务的共同特点是输入输出边界清晰判断标准客观不需要跨步骤的状态维护。Luna 的速度优势在这里能充分发挥成本降到 GPT-5.5 的五分之一甚至更低。必须保留在 Terra 或 Sol 的任务复杂决策涉及多条件判断、权重权衡、冲突消解的场景。比如根据代码变更影响面决定是否需要全量回归测试Luna 会过度简化判断条件。跨工具协调需要动态选择工具组合、处理工具间依赖关系的场景。Luna 的工具调用更像按脚本执行而非按需编排。长链依赖任务后续步骤的输出是前序步骤的输入且需要前序步骤的完整语义理解。比如根据第一步的需求分析在第三步生成测试用例时确保覆盖所有功能点。一个经验法则如果某个子任务的 prompt 里需要写如果…那么…否则…超过两层嵌套或者需要引用三步之前的输出内容Luna 大概率 hold 不住。迁移后的架构重构从单一大脑到分层路由改造前的架构GPT-5.5 时代我的 Agent 是典型的大一统模式用户输入 → [GPT-5.5] → 意图理解 → 工具选择 → 分步执行 → 结果汇总 → 输出所有认知负载都压在 GPT-5.5 上好处是架构简单坏处是成本高、延迟大。改造后的架构迁移到 Luna 为主力后变成了分层路由模式用户输入 → [Luna] 快速意图分类 → 任务复杂度评估 ├── 简单任务分类/抽取/摘要→ [Luna] 直接处理 → 输出 ├── 中等复杂度标准流程执行→ [Terra] 处理 → 输出 └── 高复杂度跨工具协调、长链推理→ [Sol] 处理 → 输出关键变化在于前置了一个轻量决策层。Luna 在这里的角色不是执行者而是分流器——用它的速度优势快速完成初筛把复杂任务交给更合适的模型。这个决策层本身也需要注意我最初尝试让 Luna 做复杂度评分结果它的评分标准飘忽不定。后来改成基于规则轻量分类的混合模式先用 Luna 做关键词和模式匹配的分类只在边界模糊时才调用 Terra 做二次确认稳定性大幅提升。Programmatic Tool Calling 在 Luna 上的实际体验GPT-5.6 的 Programmatic Tool Calling 是个好东西但在 Luna 上有几个具体注意事项。第一显式声明工具依赖关系。在 Sol 上你可以让模型自己推断先调用 A 再调用 B在 Luna 上最好在tool_choice或自定义 schema 里把执行顺序写死减少它的决策负担。第二中间结果的体积控制。Luna 处理大段中间结果的能力弱于 Sol如果某个工具返回大量数据最好在调用 Luna 之前做一层预过滤只保留关键字段。第三错误重试机制必须外置。Sol 遇到工具调用失败时有一定概率自主重试或换方案Luna 基本会原样返回错误需要你在应用层包装重试逻辑。一个实用的配置模式# Luna 的 tool calling 配置建议responseclient.responses.create(modelgpt-5.6-luna,tools[...],# 工具列表精简避免过多选择tool_choicerequired,# 减少是否调用的推断自由度reasoning{effort:low},# Luna 不需要高推理强度# 关键在应用层包装重试和超时控制)迁移不是目的成本结构优化才是回头看这次迁移最大的收获不是用上了更便宜的模型而是被迫重新审视了 Agent 工作流中每个子任务的实际复杂度。很多在 GPT-5.5 上顺手写在一起的步骤拆开后发现大量任务根本不需要旗舰模型的能力。Luna 的 80% 降价本质上是把能力溢价从那些不需要它的环节里挤了出来。现在的成本结构大致是Luna 处理 70% 的请求量Terra 处理 25%Sol 只留给那 5% 真正复杂的场景。整体 Token 成本降到 GPT-5.5 时代的三分之一左右而端到端成功率通过分层路由反而略有提升——因为每个子任务都落在了能力匹配的模型上。当然这套架构也有代价维护复杂度上升需要维护多模型的 prompt 版本路由规则的迭代也需要额外投入。但对于调用量稳定的 Agent 系统这笔账算下来是赚的。如果你也在考虑类似的迁移建议从任务分级审计开始而不是直接改模型名。Luna 能做的事比想象中多但前提是你得知道它的边界在哪里。推荐阅读最后说一件事2026 奇点智能大会终于要和大家见面了。11 月 20-21 日·北京奇点智能研究院联合 CSDN把两场技术大会放在了同一个时空里奇点智能技术大会始于 2016——聊大模型、AI Native、企业级 AI 落地、多模态与世界模型C 及系统软件技术大会始于 2005——聊现代 C 演进、AI 算力与推理优化、高性能低时延系统。为什么要放在一起因为我们越来越相信——上层 AI 应用的爆发离不开底层系统软件的支撑而底层技术的演进方向也正在被 AI 重新定义。这次大会汇聚 70 位技术专家、18 个主题、1000 同行到场。如果你也在这些方向上做研究、做产品、做工程别错过。 从 GPT-5.5 迁到 Luna，我的 Agent 工作流哪里断了
迁移前的幻觉以为只是换个模型名我第一次把 Agent 工作流里的gpt-5.5改成gpt-5.6-luna时心里想的很简单Luna 降价 80%GPT-5.5 的能力基线它也能达到那不就是免费升级跑起来的第一分钟就被打脸了。一个原本在 GPT-5.5 上稳定运行的多步骤数据分析 Agent在 Luna 手里变成了话痨但健忘的实习生——它能快速响应但执行到第三步就开始丢失第一步的上下文约束工具调用参数也开始出现低级错误。这不是模型质量问题是我对 Luna 的能力边界认知不足。这次迁移让我意识到从 GPT-5.5 到 Luna不是降级替换而是需要重新设计任务拆分粒度的架构重构。对奇点智能大会2026的完整技术议题感兴趣可前往奇点大会官方渠道免费获取PPT详细资料。Luna 的真实能力画像快在哪里短在哪里工具调用支持但别指望它自己看着办Luna 确实支持 Programmatic Tool Calling这是 GPT-5.6 全系的新特性。但支持程度和 Sol 有本质区别。在 Sol 上你可以给一个模糊目标——“分析这个仓库的安全漏洞生成修复建议”——它会自己编写轻量级程序来协调多个工具调用处理中间结果甚至根据进展动态调整下一步。Luna 也能走通同样的 API 流程但实际表现更像严格执行指令的脚本工人你给什么参数它执行什么遇到需要推断这里应该调用哪个工具的模糊地带出错率明显上升。具体到我自己的观察同样的三工具链代码检索 → 静态分析 → 报告生成在 GPT-5.5 上的端到端成功率约 85%在 Luna 上掉到 60% 左右。问题不是工具调用本身失败而是跨工具的结果关联和错误恢复——Luna 容易在第二步拿到异常输出后无法正确判断是重试、跳过还是换工具。多步骤推理第三步是道坎GPT-5.5 的长处之一是相对稳定的 5-7 步推理链。Luna 的架构明显为速度优化上下文窗口和推理深度都做了裁剪。实测下来三步以内的线性推理基本可靠超过三步且步骤间存在条件分支时状态丢失概率陡增。一个典型场景我的 Agent 需要先做意图分类再根据分类结果选择不同的处理分支最后汇总输出。在 GPT-5.5 上这个流程用一个 4-5 步的 prompt 就能稳定跑通。换到 Luna 后第三步根据分类结果选择分支经常变成忽略分类结果直接走默认分支。这不是 prompt 工程能完全解决的问题是模型本身的规划深度限制。长上下文保持轻量化有代价Luna 的上下文窗口没有官方公布具体数字但从实际表现推断有效上下文明显小于 GPT-5.5 的 128K。一个具体现象当我把 50 页左右的文档一次性塞进去做摘要时Luna 的速度优势非常明显但当我要求它在摘要中保留第 23 页提到的关键约束条件时它经常遗漏或张冠李戴。这说明 Luna 的长文本压缩能力强于细粒度检索能力——适合读完给结论不适合读完再精准定位。任务分级什么可以下放什么必须保留经过几轮踩坑我把 Agent 里的子任务按 Luna 的适配性做了重新分级。可以安全下放给 Luna 的任务任务类型具体场景关键控制点意图分类用户查询路由到不同处理模块分类标签必须穷举禁止开放式推断信息抽取从结构化/半结构化文本中提取字段抽取规则模板化减少理解自由度简单总结单文档摘要、会议纪要生成明确输出格式避免自由发挥轻量校验格式检查、必填项完整性验证校验规则原子化单条规则独立执行这些任务的共同特点是输入输出边界清晰判断标准客观不需要跨步骤的状态维护。Luna 的速度优势在这里能充分发挥成本降到 GPT-5.5 的五分之一甚至更低。必须保留在 Terra 或 Sol 的任务复杂决策涉及多条件判断、权重权衡、冲突消解的场景。比如根据代码变更影响面决定是否需要全量回归测试Luna 会过度简化判断条件。跨工具协调需要动态选择工具组合、处理工具间依赖关系的场景。Luna 的工具调用更像按脚本执行而非按需编排。长链依赖任务后续步骤的输出是前序步骤的输入且需要前序步骤的完整语义理解。比如根据第一步的需求分析在第三步生成测试用例时确保覆盖所有功能点。一个经验法则如果某个子任务的 prompt 里需要写如果…那么…否则…超过两层嵌套或者需要引用三步之前的输出内容Luna 大概率 hold 不住。迁移后的架构重构从单一大脑到分层路由改造前的架构GPT-5.5 时代我的 Agent 是典型的大一统模式用户输入 → [GPT-5.5] → 意图理解 → 工具选择 → 分步执行 → 结果汇总 → 输出所有认知负载都压在 GPT-5.5 上好处是架构简单坏处是成本高、延迟大。改造后的架构迁移到 Luna 为主力后变成了分层路由模式用户输入 → [Luna] 快速意图分类 → 任务复杂度评估 ├── 简单任务分类/抽取/摘要→ [Luna] 直接处理 → 输出 ├── 中等复杂度标准流程执行→ [Terra] 处理 → 输出 └── 高复杂度跨工具协调、长链推理→ [Sol] 处理 → 输出关键变化在于前置了一个轻量决策层。Luna 在这里的角色不是执行者而是分流器——用它的速度优势快速完成初筛把复杂任务交给更合适的模型。这个决策层本身也需要注意我最初尝试让 Luna 做复杂度评分结果它的评分标准飘忽不定。后来改成基于规则轻量分类的混合模式先用 Luna 做关键词和模式匹配的分类只在边界模糊时才调用 Terra 做二次确认稳定性大幅提升。Programmatic Tool Calling 在 Luna 上的实际体验GPT-5.6 的 Programmatic Tool Calling 是个好东西但在 Luna 上有几个具体注意事项。第一显式声明工具依赖关系。在 Sol 上你可以让模型自己推断先调用 A 再调用 B在 Luna 上最好在tool_choice或自定义 schema 里把执行顺序写死减少它的决策负担。第二中间结果的体积控制。Luna 处理大段中间结果的能力弱于 Sol如果某个工具返回大量数据最好在调用 Luna 之前做一层预过滤只保留关键字段。第三错误重试机制必须外置。Sol 遇到工具调用失败时有一定概率自主重试或换方案Luna 基本会原样返回错误需要你在应用层包装重试逻辑。一个实用的配置模式# Luna 的 tool calling 配置建议responseclient.responses.create(modelgpt-5.6-luna,tools[...],# 工具列表精简避免过多选择tool_choicerequired,# 减少是否调用的推断自由度reasoning{effort:low},# Luna 不需要高推理强度# 关键在应用层包装重试和超时控制)迁移不是目的成本结构优化才是回头看这次迁移最大的收获不是用上了更便宜的模型而是被迫重新审视了 Agent 工作流中每个子任务的实际复杂度。很多在 GPT-5.5 上顺手写在一起的步骤拆开后发现大量任务根本不需要旗舰模型的能力。Luna 的 80% 降价本质上是把能力溢价从那些不需要它的环节里挤了出来。现在的成本结构大致是Luna 处理 70% 的请求量Terra 处理 25%Sol 只留给那 5% 真正复杂的场景。整体 Token 成本降到 GPT-5.5 时代的三分之一左右而端到端成功率通过分层路由反而略有提升——因为每个子任务都落在了能力匹配的模型上。当然这套架构也有代价维护复杂度上升需要维护多模型的 prompt 版本路由规则的迭代也需要额外投入。但对于调用量稳定的 Agent 系统这笔账算下来是赚的。如果你也在考虑类似的迁移建议从任务分级审计开始而不是直接改模型名。Luna 能做的事比想象中多但前提是你得知道它的边界在哪里。推荐阅读最后说一件事2026 奇点智能大会终于要和大家见面了。11 月 20-21 日·北京奇点智能研究院联合 CSDN把两场技术大会放在了同一个时空里奇点智能技术大会始于 2016——聊大模型、AI Native、企业级 AI 落地、多模态与世界模型C 及系统软件技术大会始于 2005——聊现代 C 演进、AI 算力与推理优化、高性能低时延系统。为什么要放在一起因为我们越来越相信——上层 AI 应用的爆发离不开底层系统软件的支撑而底层技术的演进方向也正在被 AI 重新定义。这次大会汇聚 70 位技术专家、18 个主题、1000 同行到场。如果你也在这些方向上做研究、做产品、做工程别错过。