为什么 Anthropic 的 “Agent Teams” 缺少最重要的部分:治理

发布: (2026年3月5日 GMT+8 13:52)
3 分钟阅读
原文: Dev.to

Source: Dev.to

多代理系统中的信任挑战

大多数多代理系统依赖共享记忆库。如果代理 A 幻想出一个 API 调用,而代理 B 读取了该记忆,这个错误就会成为“制度性知识”。没有适当的检查,单个错误就可能在整个团队中传播。

如果你给代理相同的编码和审查上下文,它会继承自己的偏见。在这种情况下,你会失去可追溯性:

  • 哪个代理做出了决定?
  • 何时发生的?
  • 是否通过了必要的质量检查?

没有这种可追溯性,你就没有团队——而是一个合规噩梦。

Rigovo 的治理方法

在构建 Rigovo Teams——37 K 行代码、八个专用代理和一个主代理——之后,我们意识到难点不在于编排,而在于信任。

使用 pgvector 的平面语义记忆

我们使用由 pgvector 提供动力的平面语义记忆存储。这使得相似度搜索快速,同时保持记忆结构的简洁。

确定性质量门

每条记忆条目必须通过 24+ 个确定性门,才能影响团队。这些门会检查:

  • 幻影 API 调用
  • 密钥泄露
  • 结构违规

只有在通过这些检查后,条目才会成为共享知识库的一部分。

我们的开源治理层 Rigour 执行结构分析,而不是仅依赖基于 LLM 的启发式方法。如果你无法将决策追溯到具体的代理、时间戳和门的结果,系统就无法满足生产级标准。

开源治理层 – Rigour

Rigour 在 MIT 许可证下发布,已被阿里巴巴的 iFlow 等团队 fork,表明生产级 AI 需要强大的治理层。

  • 代码仓库:
  • 治理服务:

我们对大厂进入这一领域感到兴奋,但我们的重点仍然是为需要在生产环境中交付可用代码的工程师构建工具——而不仅仅是演示视频。

0 浏览
Back to Blog

相关文章

阅读更多 »