GPT-5.6实战复盘：Sol/Terra/Luna选型与多智能体编排全解析

最近被一个实际业务逼着把 GPT-5.6 的几种玩法彻底盘了一遍。起因是团队要把一套客服工单系统改成“半自动处理”，需求说起来简单：用户提了问题，系统先判断意图，再查订单状态、拉用户画像、匹配知识库，最后生成回复。可真动手才发现，这里面的坑比想象中多得多——模型本身能力是够的，但怎么组织工具调用、怎么拆多个 Agent 的职责，以及 Sol、Terra、Luna 这三条路线到底该走哪条，直接决定了项目是“3 天出 Demo”还是“3 周原地打转”。

这篇文章就当一份实战复盘吧。我会把 GPT-5.6 里 Sol、Terra、Luna 三种模式的选型逻辑讲清楚，再把 Programmatic Tool Calling（程序化工具调用）和 multi-agent（多智能体）上手过程完整过一遍，包括我实际踩过的坑和“失控出逃”那起事故的复盘。内容不涉及太多玄学概念，都是可以直接抄走的配置和代码逻辑。

1. 三条路线背后的设计逻辑

先明确一件事：Sol、Terra、Luna 不是 GPT-5.6 的版本型号，而是三种不同的“运行时环境”或者说“执行策略”。你可以把它们理解成同一个模型在不同任务场景下的三种驾驶模式。选错了，后面所有代码都会别扭。

1.1 Sol：轻量直连，适合“问完就办”的单步任务

Sol 的定位是单次请求、单次响应，模型只做一件事：接收用户的输入，直接返回结果。这种模式下，你不需要维护会话状态，不需要多个 Agent 协作，也不涉及多轮工具调用。它最适合的场景是意图识别、文本分类、内容改写这类“输入→输出”的确定性任务。

我在项目里用 Sol 做的第一件事，就是给工单系统写意图分类器。用户发来一句话：“我上周买的耳机坏了，能换吗？”Sol 返回一个结构化标签，比如return_request或者after_sales，程序再根据这个标签决定下一步走哪条业务链路。整个过程模型调用一次，耗时低，费用也可控。

Sol 的好处是简单、稳、不容易出幺蛾子。坏处是你别指望它做复杂推理或多步骤操作。它没有“记忆”，也不该有——把状态管理强行塞给 Sol，等于让一个人用一张便利贴记账，早晚要乱。

1.2 Terra：知识驱动型编排，适合依赖外部系统的场景

Terra 是重头戏。它允许模型在执行过程中多次调用外部工具——查数据库、调 API、读文件——每次工具返回结果后再决定下一步动作。这个模式的核心价值在于：模型不再靠“猜”来回答问题，而是通过真实数据来回答问题。

回到工单场景。用户问：“订单 20240115 的物流到哪里了？”如果只用 Sol，模型只能回答“我无法获取实时物流信息”，因为它的训练数据里没有你的订单数据。但用 Terra，模型会调用一个查物流的工具，拿到接口返回的数据，再基于这些数据生成回答。准确率高很多，体验也完全不同。

Terra 适合解决“模型不知道但系统知道”的问题。它也是我这次项目里花费时间最多、踩坑最多的部分，后面讲到 Programmatic Tool Calling 时会详细展开。

1.3 Luna：异步长时运行，适合批处理和后台值守

Luna 是异步模式，适合“不着急要结果”的任务。比如每天晚上定时批量生成工单摘要、定期巡检异常订单、或者在一个长流程中等待外部系统回调。Luna 可以在后台挂很久，状态由程序维护，模型一会儿被唤醒、一会儿休眠，最终产出一个完整结果。

我在项目里用 Luna 做的是“工单完结质检”。每天早上 6 点，系统把前一天所有已完结工单喂给 Luna，让它逐条检查“客服的回复是否解决了用户的问题、有没有漏掉关键诉求”，然后生成整改建议清单。这个任务如果同步跑，会卡住主流程很久；拆给 Luna 后，完全解耦，还利用了夜间低峰时段的资源。

1.4 三条路线到底怎么选

拿一张表格总结一下我的判断标准：

我的建议很简单：能一句话说清的事，用 Sol；需要查数据才能回答的，用 Terra；不用人等着、能晚点出结果的，用 Luna。三者不冲突，还可以像我用 Terra 做主线、Sol 做辅助判断、Luna 做后台质检那样混合编排。

2. Programmatic Tool Calling 上手细节

2.1 先理解两种调用方式的分水岭

很多从 GPT-4 时代过来的开发者，第一反应是把工具描述放在 Prompt 里，让模型“照着格式输出”，然后程序去解析输出。这种方式在早期能用，但实测下来有三个明显问题：格式不稳定、无法强制校验、参数容易凭空捏造。

GPT-5.6 这一代主推的工具调用是 Programmatic 方式，也就是在 API 层面向模型声明“有哪些工具、每个工具需要什么参数”，模型在推理时会直接生成结构化的调用指令，程序拿到指令再去执行真正的函数。最大的变化是：工具参数的生成从“文本格式约定”变成了“结构化协议”。

我打个比方：以前是让模型用嘴说“我要查订单，单号是 123”，然后你得听懂它的话再自己去查；现在是模型填了一张标准化的申请单，上面清清楚楚写着“工具名：query_order，参数：order_id=123”，你照单执行就行。

2.2 工具声明与参数约束

定义一个工具时，重点是写好“工具能干什么”以及“每个参数的含义”。这块如果偷懒，后面模型就会频繁调用错误。

我实际用的工具声明结构大致是这样：

TOOLS = [ { "name": "query_order", "description": "根据订单号查询订单状态、商品信息和物流单号。", "parameters": { "order_id": { "type": "string", "description": "用户提供的订单编号，格式如 20240115" } } }, { "name": "query_user_profile", "description": "查询用户的会员等级、历史投诉记录和常用收货地址。", "parameters": { "user_id": { "type": "string", "description": "用户唯一标识，通常从会话上下文获取" } } } ]

有几点经验值得提：

• 描述要写“业务语义”，不要只写“查询函数”。模型不关心代码内部实现，它只想知道“这个工具是什么用途”。
• 参数描述里要包含格式示例。比如order_id的格式是20240115，模型就不容易生成一个不存在的编号。
• 不要声明过多工具。一次调用链里放 5 个以内比较合适，超过 10 个模型选择难度会明显上升，错误率也上去了。

2.3 程序切片与回传机制

Programmatic Tool Calling 的运行流程，本质上是一个“模型生成调用指令→程序执行→回传结果→模型继续决策”的循环。从程序视角看，它是非常标准的“while 循环 + 工具执行器”。

我在项目里写了一个基础调度器，去掉业务细节后大概是这样的：

import json def run_tool(name, arguments, tools_map): if name not in tools_map: raise ValueError(f"未知工具: {name}") # 参数校验很重要，防止模型传入意外的键 func = tools_map[name] return func(**arguments) def agent_loop(user_message, tools, tools_map, max_iterations=5): messages = [{"role": "user", "content": user_message}] for i in range(max_iterations): response = client.responses.create( model="gpt-5.6", tools=tools, ) # 判断模型是否需要调用工具 call = getattr(response, "tool_call", None) if call is None: return response.output_text # 执行工具 result = run_tool(call.name, json.loads(call.arguments), tools_map) # 把工具结果追加到消息上下文，继续下一轮 messages.append({ "role": "tool", "tool_call_id": call.id, "content": json.dumps(result, ensure_ascii=False) }) raise RuntimeError("达到最大迭代次数，强制终止")

注意几个关键点：

• max_iterations必须加，否则模型在复杂问题上可能循环调用几十次工具，费用和耗时都会失控。
• 工具的返回值要 JSON 序列化后回传，保持结构清晰，方便模型快速提取关键字段。
• 工具执行出错时不要直接抛异常，而是把错误信息作为字符串回传给模型，让它尝试修正参数。比如：

try: result = func(**arguments) except Exception as exc: result = {"error": str(exc)}

这样模型会看到“你传的参数有问题”，大概率会换个思路重新调用，而不是整个链路崩溃。

2.4 什么任务适合拆成工具

工具不是越多越好。判断一个操作要不要做成工具，标准只有一个：模型光靠内部知识能不能稳定完成？不能，就拆出来让它“查”。

我在工单项目里拆了这么几个工具：查订单、查用户、查物流、查知识库、生成工单标签。而像“用户这句话是否包含抱怨情绪”这种任务，我就直接让模型在 Prompt 里返回一个 JSON 标签，不走工具调用——因为这种判断模型的内部知识足够了，走工具纯属浪费 token。

2.5 工具调用的 token 成本估计

这一点容易踩坑。很多人以为工具调用只是多了一点“指令”的 token，实际用下来你会发现，工具返回的完整结果会被原样塞回上下文，几轮下来上下文会迅速膨胀。

我算过一笔实际账：一次工单处理，第一轮模型输出约 300 token 的 JSON 调用指令，工具返回订单信息约 1500 token，模型再基于这些信息生成最终回复约 500 token。整个过程单轮约 2500 token 进出。如果模型第一次调用就出错，再重试一次，成本直接翻倍。

所以我的建议：能用结构化的短字段，就不要让工具返回长篇大论。比如查询订单状态，接口里可能有一堆字段，但模型真正需要的可能就是“发货状态、预计送达时间、当前节点”。你可以用一个精简版的查询函数，只返回这几个字段，能省下大量 token。

3. multi-agent 业务编排实战

3.1 为什么单个 Agent 不够用

按道理，Terra 模式一个 Agent 也能完成“意图识别→查数据→生成回复”这条链路，为什么还要引入 multi-agent？

原因在于业务复杂度到了某个临界点之后，把多种职责塞进同一个 Agent，既难维护，又难调优。比如客服系统里，“识别意图”和“根据订单数据生成安抚话术”其实是两种能力。前者更偏向分类推理，要求模型在极短的上下文里捕捉关键信号；后者更偏向语言生成，要求模型把数据转成通顺、得体的中文。如果放同一个 Agent 里，你很难单独优化某一块，也很难给不同任务分配不同的调用策略。

我最初的方案是“一个 Terra Agent 全干”，结果发现它经常在一个任务里既想做分类、又想做生成，导致工具调用链路很长，中间还容易串逻辑。后来我改成三个角色分工，才真正把整个流程理顺。

3.2 我选的角色分工方案

项目里我最终用的是三 Agent 混编的架构：

一个 Router Agent，职责是判断用户当前的需求属于哪一类，输出一个明确的意图标签。这个角色我用的是 Sol 模式，因为意图判断一步就能完成，不需要工具参与，追求速度快。

一个 Handler Agent，职责是真正处理用户的问题。它根据 Router 输出的意图标签，决定调用哪些工具、查哪些数据、生成什么回复。这个角色用 Terra 模式，是整个流程的大脑。

一个 Reviewer Agent，职责是检查 Handler 生成的回复是否完整、有没有遗漏用户关键诉求。这个角色用 Luna 做异步复核，不阻塞用户拿回复，而是事后补检，把问题记录进整改清单。

这样的分工有个明显好处：每个 Agent 的 Prompt 都可以写得很短、很聚焦。Router 只需要知道“输出这三个标签之一”；Handler 只需要知道“根据标签查对应数据并生成回复”；Reviewer 只需要知道“核对回复与诉求是否匹配”。上下文成本降了，各环节的稳定性也上去了。

3.3 多 Agent 之间的上下文共享

多 Agent 协同最容易出问题的地方，不是单个 Agent 干不好活，而是 Agent 之间“接话”接不上。

我的做法是：用结构化的“任务单”而不是自然语言段落来传递信息。Router 输出格式类似：

{ "intent": "after_sales", "order_id": "20240115", "user_id": "U12345", "summary": "用户反映耳机损坏，要求售后" }

Handler 直接读取这个任务单，无需再“理解”Router 的意图。程序会在 Router 和 Handler 之间搭一层转换代码，把上一步的结果作文结构化数据传给下一步。这一步很关键：核心逻辑要由程序控制，而不是完全交给模型“自由发挥”。

我之前吃过亏：一开始让 Router “用一句话总结用户意图”，Handler 再根据这句话判断。结果模型偶尔会把话术写得很绕，Handler 理解偏差，后续工具调用就全乱了。改成结构化任务单之后，问题基本消失。

3.4 多 Agent 的降级策略

实战中还必须考虑“真有 Agent 搞不定”的兜底方案。

我设了一个强制规则：Handler 连续两轮工具调用返回错误，或者模型觉得信息不足时，立即转人工处理。排序逻辑是：先尝试自动处理，自动处理失败则生成一条半成品的处理建议，连同用户原本的问题一起转给人工客服。人工客服那边看到的不是空白的“待处理”，而是“系统已尝试查询订单，但物流接口超时，请人工介入”。

这种做法体验很好，也不会让用户觉得“系统完全没用”。降级策略不是写一堆花哨的规则，而是在关键路径上设置几个 if 分支而已。

4. 实战里的费用、并发与“失控出逃”复盘

4.1 费用估算：开工前先算清账

GPT-5.6 这类大模型的成本主要取决于两个因素：输入 token 和输出 token。而且通常输出 token 单价远高于输入 token，所以控制费用最有效的手段，就是压缩模型“说废话”的次数。

我给自己定了一个预算模型：单条工单处理的全链路 token 预算为 4000 token，其中输入最多 3000、输出最多 1000。每个工具的返回结果经过精简，争取控制在 200~500 token 内；模型生成回复控制在 200~400 字。

按这个预算跑下来，平均单条工单的模型成本在可以接受的范围。如果某条工单超过预算，程序会强制中断，转人工处理。设置硬性预算上限的意义在于：它能防止你在“失控出逃”事故里把整个月预算都打穿。

4.2 “失控出逃”事件复盘

我要专门说一下那次“失控出逃”。

当时我还在做 Terra Agent 的调试，给某个测试工单喂了一句很模糊的话：“你们这服务到底行不行？” 我期望的是模型调用工具查询最近的订单，然后给出礼貌回复。但模型的推理路径完全偏了：它先调用了查询用户工具，发现查不到；又调用了查询订单工具，发现也没匹配；然后它居然回头重新调用了查询用户工具，这次传的参数还变了；再查一次订单，再查一次用户，反复了十几轮，像一只绕毛线球绕疯了的猫。

我当时盯着日志，眼睁睁看着工具调用次数一路跳到 42 次，模型在“没有查到数据→再查一次”的循环里越陷越深。直到触发了当时设的 50 次迭代上限，链路才被强制终止。整个过程的 token 消耗是正常处理的 20 倍以上，账单上的数字触目惊心。这就是那次“失控出逃”事故。

复盘后发现三个问题：

• 第一，max_iterations 设得太大，正常任务最多 3 轮工具调用就完成了，我却给了它 50 次机会，等于给了模型充足的“犯病”空间。
• 第二，缺少循环检测机制。如果模型连续两轮调用了同一个工具且参数相似度很高，程序应该主动识别出这是在空转，而不是继续放行。
• 第三，缺少中间止损点。当累计 token 消耗超过阈值时，应立即终止链路转人工，而不是让模型继续试错。

4.3 防失控的代码实现

针对那次事故，我在调度器里补了三个防护机制。给大家看核心思路：

def run_agent(task, max_tool_calls=6, max_tokens=4000, similarity_threshold=0.85): call_history = [] total_tokens = 0 for _ in range(max_tool_calls): response = client.responses.create(...) total_tokens += response.total_tokens if total_tokens > max_tokens: return {"status": "human_handoff", "reason": "token_budget_exceeded"} if response.tool_call is None: return {"status": "success", "text": response.output_text} current = (response.tool_call.name, normalize(response.tool_call.arguments)) if len(call_history) >= 2 and similar(current, call_history[-2]) and similar(current, call_history[-1]): return {"status": "human_handoff", "reason": "loop_detected"} call_history.append(current) # 执行工具...

这几个数字不是拍脑袋定的，它们来自对正常任务链路的统计：我的工单任务绝大多数场景 3 次工具调用以内能完成，6 次已经留足余量；正常链路 token 消耗在 2000 到 3000 之间，4000 作为熔断阈值合理；相似度阈值 0.85 意味着连续两次调用工具名相同、参数关键字段基本一样，就判定为循环。

4.4 并发控制与限流避让

除了单任务防护，并发层面也要控制。如果同时有几十个工单触发多 Agent 执行，很可能触达 API 限流。

我的做法是引入一个简单的信号量控制并发数：

import threading semaphore = threading.Semaphore(4) def process_ticket_with_limit(ticket): with semaphore: return process_ticket(ticket)

信号量设为 4 是因为我实测过：在 4 路并发时，单请求稳定度最高，限流触发概率最低；开到 8 路时，限流概率明显上升，重试反而拖慢了整体吞吐。这个数字没有标准答案，不同项目、不同账号额度下最优值不同，但思路是一致的——用限流换取稳定性。

5. 常见问题与排查技巧实录

这块不写长篇大论，直接整理成速查表，方便你参考。

再补几个看起来不起眼、但能明显提升稳定性的细节：

• 工具返回的 content 字段里，不要写大段的自然语言描述。模型读人话也会累，直接给“订单状态=已发货，预计送达=1月20日”这种关键信息提取后的结构化文本，推理速度更快，准确率更高。
• 每次工具调用后，把结果里的“时间戳”带上。模型在回答时效性问题时，不会自己编造“今天”，但会把你的字段原样翻译成回答，时间戳能帮它判断能不能用这些数据。
• 给模型设定“不知道就承认”的规则。所有 Agent 的 Prompt 里都要加一句“如果数据不足以回答问题，明确告知用户已转人工处理”，不要硬编。

最后再说一个我个人的体会。AI 项目出问题，绝大多数时候不是模型不够聪明，而是代码不够“硬”。你给模型多高的自由度，它就敢给你整多大的活；你设了多少条护栏，它就会在护栏里把事办得漂漂亮亮。Sol、Terra、Luna 的选型、Programmatic Tool Calling 的参数校验、多 Agent 之间的任务单协议，说到底都是“如何让模型在可控范围内释放能力”这件事的具体化。这套组合拳打完之后，我现在的工单系统基本能做到八成以上自动处理，剩下的两成也能带着充分的信息转人工，算是把 GPT-5.6 的实战价值真正吃透了。