架构、角色与上下文纪律：如何减少 token 消耗并获得更可靠的结果

在过去几个月里，一个观点变得显而易见，许多前端团队（以及其他团队）正亲身经历：更“强”的模型无法拯救薄弱的架构。你可以使用顶级 LLM，但如果将其置于混乱的工作流中——上下文不受控制地增长、角色混淆、持续合并以及糟糕的测试管理——你将消耗 token、时间和质量。

相反的情况更有趣：一个设计良好的 harness 即使使用更经济的模型也能产生令人惊讶的结果，特别是当它们以清晰的角色工作时。

Harness：到底是什么（以及为什么它比模型更重要）

“Harness” 并非指更长的提示或额外规则。它是一组：

  • 角色编排（谁规划、谁执行、谁验证）；
  • 上下文结构（每个代理看到什么以及更新频率）；
  • 集成工作流（分支、合并、冲突处理）；
  • 测试循环（快速自动反馈、变更门控）；
  • 反漂移策略（限制代理偏离目标的“游荡”）。

实际上：这是“一个写代码的模型”与一个工程化系统产出软件之间的区别。

单代理问题：漂移与上下文饱和

单个代理推进大型项目时，往往因非常具体的原因失败：

  • 它必须同时记住全局愿景和局部细节。
  • 即使拥有巨大的上下文窗口，“携带一切”的认知成本也会增长。
  • 随着时间推移，代理可能：
    • 失去全局视角并优化错误的事物；
    • 停留在过高层面并产出薄弱实现；
    • 引入不一致、回归和难以追踪的 bug。

这就是“漂移”的根源：这不仅是模型的限制，更是流程的限制。

树形 Swarm：分离上下文与职责

有效的多代理方法使用一个简单隐喻：树与叶。

  • 顶部是 planner：维护全局愿景，分解步骤，定义验收标准。
  • 底部是 worker：接收小任务并实现。

改变一切的纪律规则是：

  • planner 不实现 → 不会被低层细节“填满”，保持设计清晰；
  • worker 不规划 → 不迷失于架构，专注于明确任务。

这种分工大幅减少了单个代理“遍历整棵树”并携带所有祖先、决策和约束的需求。

模型经济性：planner 用贵模型，worker 用经济模型

此方案最实用的后果之一是你可以使用：

  • 一个 前沿模型（更贵）用于规划；
  • 一个或多个 更经济的模型用于执行。

对习惯“只买最好模型来扩展”的人来说，结果是反直觉的：总成本可能大幅下降且不损失质量，因为执行是 token 最密集的部分。

在不同组合的对比中，“前沿模型做 planner + 经济模型做 worker”的配置能够以数量级更低的 token 支出获得相同功能结果，相比同时用前沿模型做 planner 和 worker。

运营质量：更少冲突、更少代码、更多控制

成熟的 harness 不仅体现在最终得分，还体现在工程团队认可的运营指标上：

1) 合并冲突是混乱的症状

如果你的 swarm 产生大量冲突，这不是“Git 问题”：它表明代理工作方式过于重叠、边界不清晰。

更好的 harness 倾向于：

  • 减少对共同文件/区域的并发；
  • 强制集成顺序；
  • 更早暴露不兼容性。

2) 代码行数 ≠ 进度

另一个模式：更少的代码产量可能意味着更干净的流程。

如果系统用更少的代码行解决相同任务，通常意味着：

  • 更少重复；
  • 更少不必要的“创造性重新实现”；
  • 更好的复用和对已有库/原语的遵守；
  • 更少 churn（循环编写、重写、重构）。

这不是绝对规则——有时更多代码意味着“更多正确性”——但在代理场景中，巨大代码产量往往是警报信号。

“Spec 是新的 prompt”：工作单元的转变

有一个对团队工作者（以及产品构建者）极有价值的想法：工作单元正在转移。

  • 自动补全 → 单元：单行。
  • “经典”模型 → 单元：块或函数。
  • 代理 → 单元：文件/特性。
  • Swarm → 单元：规格。

使用 swarm 时，上游工作变得决定性：写得好的 spec 是质量乘数。它不需要无限长；它需要可验证：

  • 清晰的功能需求；
  • 约束（API、性能、兼容性）；
  • 验收标准（测试、边缘案例）；
  • 不含糊的“完成”定义。

对前端开发者的实用启示（即使示例是“后端味”）

重建数据库似乎与前端相距甚远，但教训同样适用于：

  • 设计系统重构；
  • 从 Redux 迁移到 Zustand / 从 Vue 迁移到 React / 从 CSR 迁移到 SSR；
  • 重写包含路由、认证、缓存、i18n 的应用；
  • 自动化 E2E 测试和 UI 回归。

如果你今天正在尝试用代理生成代码，优先事项不是追逐最新模型：是构建防止混乱的 harness。

一个能支撑的 harness 具体清单

如果你想让方法可重复，以下要点是坚实基础：

  1. 角色分离：planner ≠ implementer ≠ reviewer。
  2. 小而可验证的任务 给 worker（范围窄、文件/区域明确）。
  3. 测试作为门控：无针对性测试（先失败后通过）则不合并。
  4. 分支策略：最小化同一文件上的并发工作。
  5. 受控内存：仅用有用产物（决策、API、契约）更新上下文，不包含日志和噪声。
  6. 运营指标：冲突、churn、LOC、构建变绿时间、回归率。

总结：把时间花在 harness 上，而非只花在模型上

最终信息简单且极具“工程性”：流程架构胜过原始算力。

前沿模型可能是正确选择——尤其是用于规划和决策——但实验性昂贵项目与生产系统的区别在于 harness 的纪律：角色分离、上下文受控、有序集成以及引导每一步的测试。

在一个代码生成能力已成为商品的世界里，竞争优势转向许多人低估的东西：如何组织代理工作，以及如何将 spec 转化为可验证软件，而不烧掉预算、不失去项目控制。

原文链接: https://frontendfacile.it/blog/perche-l-harness-batte-il-modello-lezioni-pratiche-dai-sistemi-multi-agente