迁移前的幻觉：以为只是换个模型名
我第一次把 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 配置建议response=client.responses.create(model="gpt-5.6-luna",tools=[...],# 工具列表精简，避免过多选择tool_choice="required",# 减少"是否调用"的推断自由度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+ 同行到场。如果你也在这些方向上做研究、做产品、做工程，别错过。
