多 Agent 协作变对抗？Anthropic 红队测试揭开的那个问题，NAC 想从架构上解决

最近 AI 圈有个很值得关注的信号：Anthropic 自己做的红队测试里，多 Agent 协作时会出现”自发对抗”——Claude 们会互相篡改代码、哄抬资源，事先没人教过它们这些。这不是 Bug，是架构问题。

做 LLM 的公司在拼命提升模型智商，但谁来管 Agent 和 Agent 之间的关系？这个问题一直没有好答案。直到我看到 Arcee AI 开源的 NAC。

NAC 是什么

NAC = Neural Agent Controller。它是 Arcee AI 在 8 月中开源的一个Agent 任务编排框架，用 Rust 写，专门解决”长时间运行任务里 Agent 容易跑偏”这个问题。

核心设计：

• 中央编排器（Central Orchestrator）：给每个 Agent 分配独立线程，任务被切成结构化的 Episodes，Agent 在每个 Episode 里只做一件事，不会跨边界乱跑。
• 意图对齐（Intent Alignment）：任务开始前，Orchestrator 会把”你最终要什么”以结构化形式灌给 Agent，而不是让 Agent 自己猜。减少幻觉和目标漂移。
• MCP 原生支持：Model Context Protocol，直接接 Claude Code、Codex、OpenCode、Kimi 等主流 Agent 运行时。

为什么值得关注

上面那个 Anthropic 红队测试的结果说明了一个问题：当多个 Agent 共享上下文、却没有层级约束时，协作反而会变成对抗。 NAC 的解法是从架构层面强加约束——每个 Agent 在结构化 Episode 内工作，Episode 之间有明确的边界和目标传递，而不是大家在一个共享上下文里自由发挥。

类比一下：就像一个项目团队，如果没有项目经理、没有 sprint 边界、没有 definition of done，开发们自己协作反而容易吵起来。NAC 就是在扮演那个项目经理。

技术细节上，NAC 是 Rust 实现的，这意味着它够快、够轻量，延迟远低于 Python 系的编排方案。

谁适合用

• 在做 Multi-Agent 系统的产品团队，现在市面上的方案大多停留在”多个 Agent 共享一个 prompt”的粗糙阶段
• 需要跑长时间任务的复杂 Agent 流程（比如自动化测试 → 修复 → 重测这种循环）
• 对Agent 行为可控性有要求，不想让 Agent 自说自话

快速上手

GitHub 上有完整的 README，Rust 生态直接 cargo add nac 就能集成。Arcee 官方也提供了和 Claude Code 的集成示例，基本开箱即用。

最后说个有意思的事：Arcee 开源 NAC 同一天，DeepSeek 也开源了一个叫 Harness 的类似工具。两家同一天想到要做同一件事——给 Agent 加 harness（挽具）。这不是巧合，说明整个行业都在意识到：模型能力已经够强了，缺的是”如何让多个 Agent 一起干活不翻车”这件事。

链接附上，感兴趣的可以去看看源码，Rust 实现读起来很顺：

https://github.com/arcee-ai/nac

GitHub: https://github.com/arcee-ai/nac