三个臭皮匠，顶个诸葛亮：让便宜模型协同工作

每次思考 AI 架构的时候，我都会想起一句老话：

三个臭皮匠，顶个诸葛亮

诸葛亮是三国时期的传奇军师，后来几乎成了"智慧"的代名词。这句话说的不是皮匠，而是视角的汇聚。三个普通人，只要协调得好，就能跟一个天才抗衡。

当 token 账单开始影响架构决策时，这句话突然变得特别实用。

很长一段时间里，遇到复杂的 AI 工作流，默认答案很简单：用你能负担得起的最强模型。跑 Sonnet，跑 Opus，跑最好的 GPT。如果输出漏东西，就加更多指令。最后 prompt 变成一大坨：需求、示例、边界情况、日志、约束，还有一堆"请小心"全塞进一个请求里。

看起来挺合理。但这也是便宜模型开始撑不住的地方。

巨大 prompt 的陷阱

Haiku 级别的小模型很有用。它们快，便宜到可以反复调用，也擅长窄任务。但它们不是缩小版的 Opus。

跟 Sonnet 比，小模型更容易漏掉长 prompt 里的第二、第三个约束。它可能遵守主指令，却忘掉例外。跟 Opus 比，差距更明显：长线规划、冲突解决、自检能力都弱一些。当它犯下一个看似合理的错误时，它常常会把错误包装得更像回事，而不是发现错误。

这并不意外。问题不在于 Haiku 会漏东西，而在于我们把工作流设计得好像它不该漏。

第一步改进：把任务和规则分开

我学到的第一个修正特别简单：不要把所有东西都塞进 user prompt。

清晰的 system prompt 会改变任务的形状。System prompt 定义角色、优先级、约束、输出规范和评估标准。User prompt 承载具体的任务内容。这个分离很重要，因为模型不必再猜哪些是永久规则，哪些是一次性数据。

对弱模型来说，这个差别很大。聚焦的 system prompt 像护栏一样先限定判断方式。比如："你是需求审计者。只检查缺失的验收标准。以 JSON 返回发现的问题。"这比在一段很长的 prompt 第十二段里写"也请像需求审计者一样工作"更容易执行。

原因很具体：小模型同时处理指令的带宽更小。当规则、示例、数据和期望输出混在一起时，模型必须把注意力摊开。System prompt 先锚定行为，再让任务数据流过它。

这不会让弱模型突然变聪明，但会让任务变窄。

真正的架构：三个皮匠

专业的答案不是"写一个更好的巨大 prompt"，而是"别让一个 session 同时扮演所有角色"。

把工作拆开。

一个 session 检查需求，另一个找边界情况，第三个抽取事实，下一个找矛盾，最后一个重写语气。每个 session 都有自己的 system prompt 和窄任务 prompt。它们不需要都是诸葛亮，只需要在自己负责的小角落足够可靠。

然后用一个最终的 synthesis session 合并结果。

这就是谚语变成架构的地方。三个职责明确的小模型，可以覆盖比一个过载模型更大的表面积。提升不是来自假装弱模型很强，而是减少每个模型可能忘掉的事情数量。

当子任务相互独立时，并行很有用：安全评审、UX 评审、成本评审、事实抽取。当一个输出会变成下一个输入时，链式处理更合适：分类、抽取、验证、总结。不管哪种方式，关键动作都一样：把一个宽泛判断，换成多个狭窄判断。

Hub-and-spoke 模式

还有一个我喜欢的模式：hub-and-spoke。

一个 session 担任 orchestrator。它不直接解决整个问题，而是决定哪个 specialist agent 应该检查哪一部分。它只传递相关 context，收集回复，并在输出冲突时追问。最后再综合答案。

当工作不是干净的 pipeline 时，这个模式很有用。真实任务很乱。Review agent 可能发现缺失需求，缺失需求又需要回到 planning agent。Cost agent 可能反对当前架构。Orchestrator 让状态继续流动，而不要求每个 specialist 理解整个世界。

诀窍是保持 orchestrator 诚实。它应该传结构化摘要，而不是含糊感觉。它应该保留分歧，而不是把分歧掩盖过去。当外围 agent 给出冲突答案时，最终 synthesis 应该说出来，或者升级给更强模型。

便宜模型在这里有用，因为它们变成传感器。每个模型从一个特定角度观察。Orchestrator 不需要它们完美，只需要足够的覆盖面，让重要遗漏更不容易发生。

最后一个旋钮：temperature

Temperature 不能治好弱推理，但它是让 pipeline 少一点混乱的最简单旋钮之一。

对于抽取、验证、分类、synthesis 和评审，我希望 temperature 低。可预测性比新奇更重要。如果相同输入每次产生不同 schema 或不同判断，工作流会很难调试。

对于创意工作，我会调高它。命名、头脑风暴、比喻、初稿文案、视觉想法，这些任务受益于变化。我不希望模型每次都返回最安全的平均答案。

错误在于所有地方都用同一个 temperature。架构任务需要不同模式。检查合规的 specialist 应该无聊；提出博客标题的 specialist 可以松一点；orchestrator 通常应该保守。

这就是我反复学到的课：不要把所有精力放在寻找一次完美模型调用上。设计工作，让不完美的调用仍然有用。

三个皮匠不会神奇地变成诸葛亮。但如果每个人都知道自己该看什么，并且有一个冷静的角色把结果合起来，系统就可以惊人地接近。