将大型模型用作编排器、小型模型做执行者，反而会增加成本并降低质量。
AI translation, not an official translation. Refer to the original for technical details.
Adapted from @anshuc# 用"笨老板"方式获取更多 Astra/Fable 配额 大多数人认为应该用大型、昂贵的模型作为编排器，将繁琐的工作委派给小型、廉价的工作者。但你应该做的恰恰相反。以下是原因。 # 比较不同方案 ## 方案一：直接使用大型模型 这是大多数人的起点。启动 Codex 或 Claude Code，选择最好的模型，输入提示词，然后开始运行。这种方式效果出色——这也是 AI 公司测试、优化和推广的标准做法。 以下是使用 GPT-6 Astra（轻量版）的几个示例： 提示词： > 构建一个精致的基于浏览器的 3D 房间规划工作室，命名为 ROOM / STUDIO。我需要同时可编辑的 2D 平面图和交互式 3D 房间视图，包含家具目录、指针放置/拖拽、跨两个视图的选择同步、0.25m 捕捉、90 度旋转、尺寸/位置检查器、删除功能，以及清晰的碰撞/越界反馈。使用真实的 3D 几何体搭配轨道控制、连贯的家具轮廓和灯光。从一个有品味的、已摆放家具的 6x5m 客厅开始。所有可见控件都应可用。保持在桌面 1440x900 和笔记本 1100x760 下可用。适配器的导出功能必须现在就能工作，以便我保留布局供未来更改。使用静态服务器从 index.html 提供应用。在声称完成之前通过浏览器进行验证。 结果： 提示词： > 创建一个全视口实时 3D 铰接机器人场景。将精力集中在具有吸引力的机械一致几何体上：螺栓固定的底座、圆柱形肩部/肘部外壳、锥形连杆、腕部套环、夹持器、内嵌接缝、分层材质、柔和灯光和地面阴影。真实的关节层次结构遵循提供的运动学参数。轨道/缩放、带高亮的 3D 拾取、相机预设和四个关节控件，放置在一个小型可折叠覆盖层中。无应用外壳、面板、编辑器、菜单或文件工作流。 这就是 Astra 开箱即用的能力。这是一个优秀的模型！ 然而，它也是一个昂贵的模型。以下是上述运行的费用： 我们将所有内容换算为等效 API 成本进行比较，因为 OpenAI 和 Anthropic 没有提供配额计算方式的详细信息。API 成本与配额消耗成正比。 ## 方案二：天才老板，笨工人 这是大多数人认为应该采用的方式。Astra 很贵，所以不要让它做繁琐的工作。让它负责规划，把繁重的工作委派给更小的模型。 以下是使用 GPT-6 Astra（轻量版）的相同示例。每个案例中，我们使用与之前相同的提示词，并添加了以下附加指令： > 规划并审查工作，但使用带有 xhigh 推理级别的 Luna 将大部分实现委派给子智能体。你负责编排、执行并交付良好的最终结果。仅在委派显得大材小用的情况下自行处理小型 bug 修复。 质量明显下降。2D 和 3D 房间视图变得简单得多，侧边栏也更加简单和不美观。机械臂场景变得更加方块化，细节更少。 好吧，但至少我们节省了配额，对吧？然而…… 什么？！竟然更贵了？Web 应用花了 5 倍的时间？？ 这让我感到震惊，于是我让 Astra 分析了差异。以下是这种方案出了什么问题： - 外层 Astra 线程变得很长，充满了子智能体工具调用和验证工作。尽管有前缀缓存，冗长的输入仍然积累了大量费用。 - Astra必须花费大量tokens来撰写子智能体提示，清楚地阐明它们各自的任务。 - Astra随后还必须花费更多tokens来审查工作、测试代码并修复漏洞。 除了消耗更多tokens之外，结果也更差，因为所有代码都由能力较弱的智能体编写，而Astra能做的善后工作也十分有限。 ## 蠢老板，天才员工 让我们来看看，当我们互换Luna和Astra的角色时会发生什么。没错，这听起来很奇怪，但我们要让Luna来指挥Astra。请先耐心听我说。 同样是基准测试中的那个提示，加上了额外的指令： > 使用一个Astra子智能体，以轻度工作量在一个连续的对话线程中完成所有实现工作。你负责协调、浏览器测试，并将发现的问题及最新的产品截图反馈给Astra。指示Astra不要测试或审查工作，只需在实现完成后停止。你发给Astra的每个提示都应精简，附上上述产品简介和截图，不要带有技术意见或细节。告诉它朝着目标努力，修复它发现的问题，然后极简地汇报。完成3轮后停止，或者如果Astra表示产品已完成则提前停止。 与让Astra独立完成所有工作相比，结果相当接近。机械臂看起来很棒，但房间预览的细节稍少一些。不过，请看成本对比： 我们将成本削减了一半以上，速度还提升了30%！ # 为什么这行得通？ 四个字：说易行难。 假设你想用AI构建一个精美的落地页。在"天才老板"的情况下，大模型需要将其审美能力压缩成指令，传递给一个能力较弱的模型。这个过程是有损耗的。 > 天才老板：嘿，帮我为一家葡萄牙海岸的精品酒店做一个精美的落地页。我的构想是旅行杂志风格：超大号衬线字体标题、温暖的奶油色背景、深蓝色点缀。大幅阳光照耀的照片，留足呼吸空间，加入一些偏心构图的细节以增加视觉趣味，你懂我的意思吗？主视觉要突出，不要太过俗气。文案要写得自然、有针对性。动画一定要加上漂亮、细腻的缓动曲线！哦，还要确保在手机上看起来也很棒。不要用粗糙的渐变——不过你早就知道这一点，对吧？ 蠢员工：呃，好的，明白了老板。 在"蠢老板"的情况下，我们只需要小模型从宏观层面描述目标，它不需要了解或关心细节。大模型会在极少指引下出色地完成工作。 > 蠢老板：嘿，帮我为一家葡萄牙海岸的精品酒店做一个精美的落地页。我也说不好，尽力而为吧。别搞砸了？ 天才员工：当然，先生，我将为用户呈现一份令人心旷神怡的顶级旅行杂志体验…… 如果你曾经管理过真实的团队，这不会让你感到意外。人们总是想象那种有着强烈愿景、掌握所有答案的大老板：发号施令，给每个人分配明确的任务，完成一个又一个里程碑。但成功的团队并非如此运作。你希望你的团队比你更聪明，你要做的是消除他们的阻碍，为他们指明方向，然后放手让他们去跑。 # 那这就是解决我所有问题的方案？用 GPT-5.6 Luna 来处理一切？ 对。GPT-5.6 Luna 修复了我的婚姻。但只有在 xhigh 推理模式下才行。 不，我当然不认为我在这里描述的是解决所有工程问题的通用方案。如果你试图一次性生成一个完整的复杂多服务应用，你大概不应该让Luna来主导。 问问自己这些问题，来决定如何最好地构建你的智能体： **我是否把质量/正确性放在首位？** 如果是，就对所有事情都用大模型。 **我的任务是否非常复杂，涉及多个步骤？** 如果是，就不要让小模型来做决策。用大模型将任务拆解成计划，让小模型只负责逐步执行计划，并在需要实现时调用大模型。 **计划本身是否复杂，或者产品难以测试？** 你不必把最小的模型当作编排者。往上一两档（在 Codex 中是 Terra 或 Sol）会在执行计划和测试应用方面表现好得多，同时仍能节省 token。 --- 还要牢记以下几点： - **你不希望小智能体有技术主见。** 它的工作应该是粘合剂和轻量级 QA——读取计划、取出下一项任务、交给工作者、扫一眼输出、测试一下、截图，然后给你汇报状态。这些都是你不想花大模型 token 去做的事情。 - **如果结果很差，去看看小模型实际发送给大模型的提示词。** 它是在描述解决方案而不是问题本身吗？你要确保获得的是大模型的判断，而不是让小模型把错误信息喂给它。 - **在漫长复杂的运行中，你可能需要创建额外的层级，并偶尔清除大子智能体的上下文。** 而在规模较小的运行中，保持一条连续的子智能体线程可能更有益——这样它的前缀可以被缓存，无需重新发现已知内容。花 10 分钟好好想想你的架构，能省下数小时的痛苦和数百万的 token。 - **提供清晰的目标截图、计划或提示词，让编排者有所约束、让执行者有所指引，往往能带来最好的结果。** 多智能体架构会放大你提示词中的模糊性。 --- 我自己也还没把这套方式推到极限，可能有很多使用场景并不适合它。如果你尝试了，无论好坏，我都很想听听你的经验。
