现在是 2026 年 1 月 25 日，周日下午。
Multi-Agents: 对抗生成翻译
昨天完成了 CZON 轻量级的 OpenCode 翻译集成，实现了一个基础的对抗生成模型。
这个翻译任务引入了翻译任务和审查任务。双方进行对抗生成，翻译模型负责生成翻译结果，审查模型负责审查翻译结果是否合格。如果审查模型认为翻译结果不合格，则要求翻译模型重新生成，直到生成合格的翻译结果为止。（目前最大迭代次数为 10 次，防止无限循环）
这个翻译设计，相比于原始的 one-shot LLM 翻译，牺牲了时间和 Token 效率。但有一个关键的优势：大幅提升了翻译质量，解决了如下问题：
- 翻译遗漏内容的问题：有些翻译模型会漏掉原文中的某些内容，导致翻译结果不完整。审查模型可以检查翻译结果是否包含了所有原文内容，确保翻译的完整性。
- 长文章翻译不连贯的问题：有些翻译模型在处理长文章时，可能会出现前后不一致的情况。审查模型可以检查翻译结果的连贯性，确保翻译结果在整体上是一致的。
- 生硬、不自然的问题：有些翻译模型生成的翻译结果可能显得生硬、不自然。审查模型可以评估翻译结果的流畅性，确保翻译结果符合目标语言的表达习惯。
从结果上来看，翻译的质量的优先级显然高于 Token 效率和时间效率。对于 CZON 这种需要高质量翻译的场景来说，对抗生成模型是一个不错的选择。
Multi-Agents 内存优化
不能为每个 Agent 单独启动一个进程，每个进程少说也有 100MB 的内存占用，多个 Agent 同时运行会导致内存不足。更好的方法是将所有的 Agent 集成在一个进程中运行，节省内存开销。OpenCode 官方是分离了 Server 和 Client 的，它可以使用一个 serve 进程监听端口 (默认是 4096)，然后多个 Client 连接到这个端口进行交互。这样就可以将所有的 Agent 集成在一个 Server 进程中运行，Client 只负责发送请求和接收响应。
如此，我们应该能够支撑同时启动数百个翻译任务，而不会因为内存不足而崩溃。
Multi-Agents 的控制约束
业界有两种方案，一种是令 Agent 控制 Agent，一种是用 Script 控制 Agent。
区别在于，Agent 控制 Agent 是软约束，Agent 可以根据自己的判断来决定是否执行另一个 Agent 的指令；而 Script 控制 Agent 是硬约束，Agent 必须严格按照 Script 的指令来执行。
软约束的优点是灵活，缺点是不可靠；硬约束的优点是可靠，缺点是不灵活。
软约束的问题很常见，在 Agent 中定义了 workflow，但是 Agent 常常并不按照此 workflow 来执行任务，甚至提前退出，导致结果不符合预期。而硬约束的问题则是，Script 可能无法覆盖所有的场景，导致 Agent 无法处理某些特殊情况。
两者看似水火不容，实际上，可以用一个 Orchestrator Agent 来生成 Script，然后让其他 Agent 按照这个 Script 来执行任务。这样就结合了两者的优点，既有灵活性，又有可靠性。在早期，甚至可以人工编写 Script 来控制 Agent 的行为。完全可控才是最大的灵活。
所以，得让 Script call Agent 的摩擦足够小，小到一行代码即可实现调度，进而实现复杂的多 Agent 协同工作。
Anthropic 在 Multi-Agent 的文章中提到，子 Agent 的输出最好是写入文件系统，而不是返回给主协调器。因此，我们可以认为 Script call Agent 不需要返回结果，只需要让 Agent 将结果写入文件系统，然后由其他模块读取文件系统中的结果即可。
至于 Script 又可以集成到常用的语言中，例如 JS 中，利用一个 lib，即可实现让 Orchestrator Agent 先编码 Script，然后由 Script 调用其他 Agent 执行任务。不用 DSL，胜过 DSL。
Multi-Agents 生态: OpenCode vs Claude Code
OpenCode 的生态明显比 Claude 更加开放。OpenCode 允许通过 HTTP API (or SDK) 来调用 Agent，查看 Agent Session 的状态，获取 Agent 的输出结果等。这使得我们可以更方便地集成 OpenCode Agent 到我们的系统中，实现复杂的多 Agent 协同工作。而 Claude 则反其道而行之，想办法封闭生态，只允许通过 Anthropic 提供的接口来调用 Claude Agent，限制了用户的自由度。
