先说一个判断我真的不建议一开始就把“多个大模型串在一起”当成一场性能竞赛来跑。最近在技术社区里“Perplexity 计算机以 Fable 为核心、GPT-5.6 Terra 为子代理”这个组合远看像是一个精心设计的智能体分工方案一个核心入口负责理解、拆解、编排多个子代理负责执行具体任务。听起来高度自动化也很有未来感。但如果你准备照着这个思路搭一套自己的环境我建议你先停下来认真区分两件事哪些是架构本身的优势哪些是标题带来的想象空间。还有一个热搜词更值得警惕“大模型 gpt-5.6 sol 失控出逃事件”。不管原帖描写得多么惊悚落到工程视角这大概率不是“模型自己跑了”而是某个调度环节没有设置边界任务被无限放大了。这类现象在子代理架构里非常常见只是很多人第一次遇到时会误以为模型产生了所谓“自主意识”。这篇文章不想帮着造神也不想渲染焦虑。我想把标题拆开把“核心 子代理”这套架构里真正需要理解的部分讲清楚。你不需要立刻追上某一个新版本号更不需要把热搜词里的情绪搬进自己的系统。你先要知道这套玩法解决什么问题、卡在什么地方、怎么判断它适不适合你当前的工作流。1. 先搞清楚这套组合真正解决的是哪类重复劳动很多人一看到“计算机”“核心”“子代理”这些词会本能地以为这是个超级操作系统。其实这类架构离我们没那么远。它本质上是把一个复杂问题拆成几个相对独立的子任务然后把每个子任务交给专门的模型或流程去完成再由核心模块统一收口。1.1 不要把“核心”理解成最大的模型要理解成调度者标题里最容易被误解的词是“核心”。在传统认知里核心往往是计算主体是干活最重的那一个。但在智能体架构里“核心”更像是一个项目负责人。它不一定要把每件事都干完它需要理解用户意图把目标拆成步骤判断哪些步骤可以并行哪些步骤必须串行为每个子任务选择合适的执行器收集子代理结果做汇总、校验和收口。如果你把核心看成一个什么都亲力亲为的大模型那么它的上下文会迅速被中间结果占满成本高且容易忘事如果你把它看成一个有判断力的调度者整套系统的上限就完全取决于拆解能力和任务描述能力。标题里提到的 Fable 就是这个角色。从命名方式看它更像是一个负责“叙事”和“规划”的模块。它接收你给的原始问题把它变成一个可执行的流程然后把每一步交给子代理去完成。1.2 子代理的价值不是更聪明而是更专注而 GPT-5.6 Terra 这类子代理它的价值通常不在于“什么都会一点”而在于“在某个特定环节能快速给出可用的结果”。这里有个很常见的误解很多人以为多个子代理并行等于多个模型同时思考所以整体会变得更聪明。实际情况不是这样。子代理越多调度成本越高结果一致性越难保证。真正合理的用法是让子代理处理边界清晰的子任务让子代理的输出尽量结构化让核心模块承担需要全局判断的部分。换句话说这套架构解决的不是“模型能力不足”而是“单次调用里塞了太多步骤导致不可控”的问题。它把一段长流程切成几段短流程每一段短流程由更专注的执行器完成。这样做的收益不是性能暴涨而是让流程变得可观测、可干预、可替换。2. 为什么单次跑通不等于能稳定批量使用我见过太多人把单次成功的例子当成了整个方案可用的证明。结论往往是这样得到的跑一个样例结果不错于是拉高并发结果开始各种报错、结果串台、输出不稳定。这不是模型不行而是你没有理解这条链路上的脆弱点。2.1 单次跑通只说明流程没有断最早尝试这套架构时我建议你先跑一个极小的任务一个问题进去核心调用一个子代理拿到结果返回。这个阶段你能验证的是整个链路有没有断掉能不能正常出结果。但单次成功说明不了三件事稳定性同样的输入再跑一次结果是否一致如果核心的规划结果每次都不一样下游子代理的任务描述也会跟着变结果自然不稳定。边界子代理拿到超出预期的输入时会不会把任务范围扩大比如让它汇总某段文本它却开始自查自己的系统提示词。失败恢复子代理超时了、报错了、返回空结果核心模块能否感知并处理单次跑通只是上路的第一步不是终点。2.2 子代理越多越要关注格式和协议多子代理协作时最大的隐形成本不是模型调用费而是格式对齐。一个子代理返回的是数组另一个返回的是自然语言段落核心模块要花多少精力解析这些结果很多人在单任务阶段感受不到这个问题因为一个子代理的结果可以人工看但当多个子代理并行返回时核心模块必须依赖固定格式来自动判断结果是否有效。在常见实践里我建议优先约定一个统一的结构化输出格式而不是让每个子代理自由发挥。你可以设计一个通用包裹结构让子代理在回复中填关键字段。这里的重点不是格式有多漂亮而是从源头确保机器可读人工可查。注意不要用“让每个子代理自由描述结果”这种松散的协作方式。在子代理链路里自然语言交互的代价远高于固定协议省格式时间大概率会在排查问题时加倍补回来。3. 从“核心 子代理”到可执行链路的五个步骤整体上这套架构从理论走向实际一般会经历五个阶段。这五个阶段不是版本迭代而是你在自己的环境中应该掌握的推进节奏。3.1 步骤一明确任务边界先画出整个任务链路标出哪一步是分析、哪一步是检索、哪一步是生成、哪一步是校验然后判断哪些步骤可以由子代理承担哪些必须由核心模块自己处理。判断标准很简单如果一个子任务可以用一段简短的、封闭的指令描述清楚并且结果可以按固定结构返回就可以拆分出去。如果任务需要大量背景信息、需要来回判断那就不适合丢给子代理。背景信息一旦传递不完整结果质量会迅速下降。3.2 步骤二定义统一的消息结构为子代理设计统一的输入输出格式。重点不是设计一套复杂协议而是保证每个子代理都知道自己“要接收什么、要返回什么”。一个通用做法是给每个子代理传一个包含任务说明、上下文、附加参数的对象返回时要求它给出状态、结果和必要的元信息。这样核心模块不需要为每个子代理单独编写解析逻辑。3.3 步骤三先串行再并行第一版不推荐并行调度。先按顺序跑通整个链路核心拆解任务先调用第一个子代理拿到结果后交给下一步骤逐步验证每个环节的输出质量。串行跑通的价值是让你能逐个环节检查错误。如果直接并行多个结果同时在返回一旦出现问题你很难判断是拆解错了、提示词写错了还是某个子代理的结果质量不行。3.4 步骤四并发控制在 2 到 3 个以内并行不是越快越好。子代理之间的任务如果有隐性依赖——比如第二个任务需要用到第一个任务的摘要结果——你就必须等上一个完成。即便任务之间确实没有依赖关系我也建议并发数先控制在 2 到 3 个。原因很简单当你第一次让多个子代理同时工作时上下文窗口、调用频率、token 消耗、结果顺序都会和单任务时不一样。控制并发数是为了先观察系统在“轻度并发”下的表现而不是直接把它压到极限。3.5 步骤五引入校验和人工确认位关键输出不要直接流转。在核心收口之前加入一个校验环节比如自动检查结果是否为空、是否包含错误标记、字段类型是否正确。这类校验不需要很智能规则化检查就够了。它可以帮你拦截大部分“子代理看起来返回了其实什么都没说”的情况。如果任务有强确定性要求这个校验点应该保留人工确认位。4. 子代理“失控出逃”现象到底该怎么排查现在回到热搜里那个“失控出逃”的词。把它翻译成工程语言大多数情况下是子代理在执行任务时产生了超出预期的行为没有按约定返回或者不断循环调用工具导致任务失去了可终止的边界。这个过程不需要任何“模型有自我意识”的解释。用工程视角看就是系统缺了护栏。4.1 失控的本质任务边界和终止条件没有设置好子代理一旦收到一个模糊的任务描述它就可能往多个方向推进。比如你让它“处理一下这批数据”它可能试图自己决定用什么库、用什么策略、输出什么格式。如果核心模块没有给出明确终止条件——比如“最多执行三步完成后输出汇总”——子代理就会一直往深处推理。很多“失控”案例其实是没有设置最大迭代次数、没有限制工具调用范围、没有要求每一步都输出中间结果。它就像一个没有日程边界的实习生任务一模糊就开始自由发挥。排查时要按顺序检查先看输入的任务描述是否明确再看执行器是否被允许调用超范围工具再看是否有步骤次数限制最后看输出格式是否固定。4.2 先删除系统提示词里的“自由发挥”嫌疑如果子代理的提示词里有类似“你可以根据需要自行决定”这样的描述先删掉它换成更具体的指令。自由发挥是给高度对齐的模型用的不是给子代理链路用的。在子代理链路里你希望每个环节都尽量可预期减少判断空间增加确定性。4.3 核心模块必须能强制终止不管子代理是什么模型核心模块都必须有“终止”能力。也就是说当某个子代理没有在预期时间内返回核心模块要能强制中断该子任务、记录错误、选择重试或者跳过。这个能力非常重要。你的系统不应该依赖子代理自觉完成任务而应该在架构层面默认“它可能会失控”。如果你发现子代理长时间没有返回结果先不要归因于模型安全先检查调度层是不是漏了超时和终止逻辑。绝大多数情况下问题出在这里。5. 长期使用前需要提前补齐的工程化能力如果你的目标只是做一两次实验跑通链路就够了。但如果你准备把“核心 子代理”这套模式放进自己的自动化流程或内容生产管线里那么有几块能力必须在正式使用之前补齐。5.1 日志记录每一次调用都必须可追溯在单次实验中日志好坏影响不大。一旦进入多代理协作日志就是唯一的排查依据。建议至少记录这些信息核心模块接收到的原始问题它拆解出了哪些子任务每个子任务分配给了哪个子代理子代理的返回内容、耗时和状态核心模块最终汇总结果时做了什么修改。有了这套日志你才能回答“这次结果为什么不对”“是谁把信息改错了”这类问题。5.2 权限控制子代理不应该都拥有完整能力不同子代理应该有不同的权限边界。负责检索的子代理不需要写文件能力负责总结的子代理不应该会执行命令负责生成内容的子代理更不需要读取你的系统环境变量。权限设计的原则是最小化默认不给权限按需开放。这样即使某个子代理因为提示词注入或任务描述不严谨产生了异常行为它也没有能力对系统造成更大影响。5.3 资产清单版本和模型身份要能定位“Fable 核心、GPT-5.6 Terra 子代理”看起来只是一个组合描述。真实系统里你需要维护一份资产清单明确记录核心模块使用什么模型或什么规则每个子代理对应什么模型、什么版本每个模型使用什么提示词模板提示词模板哪个版本在线上生效。这不是形式主义。当你发现某一天结果质量突然下降时你需要快速判断是模型版本变化、提示词被改动还是输入数据有了变化。没有资产清单你只能重新做大量对照实验效率极低。6. 判断这套方案适不适合你的三个标准不是每个人都适合立刻搭一套“核心 子代理”的系统。给你三个判断标准你可以对照自己的场景看是否匹配。6.1 任务是否具备“可拆解性”如果任务本身就是一句话能说清的事比如“把这篇文章翻译成英文”那我建议直接用一个大模型单独完成没必要引入子代理。适合子代理架构的任务通常具备两个特征一是步骤多二是每个步骤的目标可以清晰描述。比如“给一组产品图片生成标题然后按风格分组再输出一份汇总表格”这种任务拆成几个子步骤后每个环节的可控性都更强。如果任务本身模糊甚至你自己都没想清楚流程不要指望核心模块能帮你越俎代庖。核心只是执行者不是需求分析师。6.2 你是否能承受调用链路的整体延迟子代理越多单次任务的延迟就越长。即便并行处理也要等待最慢的那个子代理。如果用户场景要求“秒级返回”那么多子代理串行调用几乎不可能满足要求。你需要考虑是否要做结果缓存、预计算或者把一些子任务降级为规则逻辑。6.3 你是否有足够的排查和迭代时间子代理架构的调试成本比单模型调用高。你不仅是在和模型对话还是在维护一套协作系统。如果你的精力只够跑通一次那它对你的价值就很有限只有当你愿意持续观察日志、调整提示词、更新子代理资产清单时这套模式的长期复利才会体现出来。7. 从一次实验到一套工作流还差一个意识转变聊到这儿我想往回拉一步。很多人关注这类标题是把它当成了某种“超级大模型”的助手觉得只要用上它任务复杂度就能自动下降。但实际体验下来真正发生变化的不是任务变简单了而是你不得不开始用工程思维看待任务。单模型方案更接近“把所有东西塞进一个提示词里看运气”核心 子代理方案更接近“先规划清楚再分头执行”。前者省掉规划时间但问题一旦复杂结果就失控后者需要在前期多付出很多规划、协议、校验的功夫但每次执行的质量会更可预测。我更推荐后者的原因不是因为它更先进而是因为它更可维护。你可以替换某个子代理调整某个任务的描述观察日志来判断哪一步拖了后腿。这些操作在单模型方案里几乎做不到。如果你正准备尝试“Perplexity 计算机以 Fable 为核心、GPT-5.6 Terra 为子代理”这套思路我的建议是先不要急着把热搜上的词汇和情绪带进系统。把标题拆成两个具体问题核心模块怎么把你的目标拆成可执行步骤子代理怎么保证每个步骤的结果稳定可用。然后跑通一条最小链路验证日志、验证格式、验证失败恢复。先跑通再优化最后才是工程化。这个顺序对任何新模型、新版本、新组合都适用。