我们花了几个月构建AI智能体，然后删除了它们

在过去几个月里，Runnit团队投入了大量精力将AI智能体整合到其平台中。他们构建了多个智能体，每个都有特定的职责：一个负责规划，一个负责研究，一个负责调度，另一个负责写作。这些智能体都配备了精心设计的提示词、独特的行为和各自的专业领域。当时，这似乎是正确的架构——原始LLM的上下文窗口较小（64k-128k），将工作分解为专业智能体不仅是更清晰的做法，而且是产生哪怕半精确结果的必要条件。每个智能体只需理解一个问题，从而更有效地利用其可用上下文。

然而，随着模型不断改进，团队逐渐意识到他们仍在围绕过去的限制进行设计。在测试具有更大上下文窗口的新模型时，他们发现这些模型能够在同一对话中自然切换不同任务，而无需变成完全不同的助手——只要在正确的时间获得正确的信息，它们就可以同时进行规划、写作、研究和推理。这迫使他们思考一个简单的问题：这些真的需要是独立的智能体吗？

最终，答案是否定的。于是他们删除了所有智能体。团队围绕一个单一智能体（名为Ru）重构了架构，该智能体在需要时加载能力。研究不是智能体，调度不是智能体，写作不是智能体——它们是能力和指令，是可以在任务加载、完成后卸载的专业知识。这一改变看似微小，却极大地简化了几乎所有方面：现在有一个一致的业务理解、一个对话、一个记忆、一个组织知识存储的地方。

当速度至关重要时，同一智能体可以简单地创建自身的并行实例，每个实例加载所需指令完成各自工作，然后汇总结果。从外部看，它仍然并行工作，但底层是同一个智能体解决不同部分的问题。团队还删除了大量复杂性：不再需要维护几十个单独的提示词，协调不同智能体之间的交接，或担心不同智能体在演进中逐渐偏离。

当然，这并不意味着专业智能体已过时——在某些情况下，隔离工作、使用不同模型或分离权限仍有充分理由。但作者认为，许多开发者仍在沿用为早已不存在的模型而做出的架构决策。如果今天重新开始构建Runnit，他们不会首先问“我们应该构建哪些智能体？”，而是会问“单一智能体需要哪些能力？”有时，进步不是增加另一个层次，而是意识到你不再需要它了。