一年前，这只是五个代理在已经放在我书桌上的硬件上完成五项任务。现在是十个 — — 同样的硬件，同样的钱包，每月实际上仍为零美元。

这就是标题。但标题不会告诉你重要的部分。重要的部分是途中出了什么问题，因为一切都出了问题。每次出问题，我都在修复过程中变得稍微好一些。

所以这不是胜利圈。这是对失败的情书。正是它们教会了我一切。

它是如何成长的

它起步很小。五个代理 — — 主代理、编码器、创意者、研究者、运维。每个都有自己的工作，每个都在本地模型上运行，一段时间这样就够了。它运作良好。但边缘很粗糙，边缘总是如此。

有一位访客通过 WhatsApp 到来，主代理不得不放下一切来接待。一个编码任务到达，显然是个草稿 — — 不是生产版本，也不是面向世界的 — — 编码器对待它的态度就像对待即将发布的合并一样郑重。一个诊断任务足够小，以至于叫来完整的诊断专家感觉就像用大锤子去敲图钉。

于是我又添加了五个。whatsapp-guest 负责处理对话。coder-light 和 diagnostician-light 负责草稿、实验以及尚未准备好首次亮相的工作。bounty-hunter 负责特定类型的搜索与检索。共有十个代理，每个都有更窄、更清晰的任务。

而我最喜欢的部分是：这一切都在原本只是闲置的机器上运行。它们积满灰尘。在代理加入之前，它们没有做任何有用的事情。唯一的真实成本是电费 — — 以及高级模型共享的每周配额，这本身就是另一个故事。承担 95% 负载的本地模型每轮几乎不消耗任何资源。完全不消耗。

我不打算逐一列举每台机器。重点不在于这些盒子。重点在于这些代理并不藏在一台笔记本电脑上——它们会主动探测、监控网络范围内的基础设施，即使无人查看也会一直关注。该机群的足迹大于它所放置的书桌。

哪里出错了

说谎的模型表

文档中有一张表。一个模型表——它列出了每个代理所运行的模型。看起来很官方。看起来像是事实。

这是错误的。

有两个条目已经腐烂成了虚构。其中一个列出的模型在每次调用时都会失败——该方案的积分甚至不足以支撑它，它从来不是真实的选项，只是有人随手写下的名字，从未经过测试。另一个列出的模型在任何地方都不存在。根本不存在。这是一种被写进文档的幻觉，它就这样躺在那里，表现得很自信，时间之长甚至让我不愿承认。

我需要大声说出的教训，即便这看起来显而易见：不要把活跃的事物存放在静态的地方。Markdown 文件中的模型表不过是假装被刻在石头上的活状态。模型会被重命名。它们会被废弃。它们会被关在套餐等级之后。有时它们根本就不存在。之所以表格腐烂，是因为文档被当作了福音，而唯一真实的真相是你调用时实际得到的回答。

于是我停止维护该表。活状态存在于活状态中——路由器的输出、配置、实际上正在运行的东西。文档现在描述的是策略：哪种类型的作业获得哪个等级。它不会命名那些可能化为尘埃的名称。

一切都溢出的夜晚

在11日和12日，舰队撞上了墙。我记得它就像记得跳跃前的那一刻——看着自己亲手建造的东西慢动作失败的感觉。

由 main 生成的子代理继承了 main 的整个世界。而 main 同时运行十个代理，承载了大量的世界。于是一个子代理会被生成，得到整个庞大的上下文，在它能够完成工作之前就淹没了。溢出。失败。重试。生成另一个携带同样超大行李的子代理。再次淹没。

修复是结构性的，事后看来如此显而易见：常驻代理从精简的上下文中生成自己的子代理。子代理只获得它需要的任务和文件。一个干净、小而专注的世界。它完成工作。它返回。它不会淹没。

错误在于把上下文继承当作礼物——“子代理能看到一切，所以它拥有所需的一切。”不。main 看到的大多数内容对子代理来说是噪声。信号在编排中被淹没。精简上下文并不是为了避免溢出。而是关于信噪比。而是给予某物恰好足够的资源，以便它能够完美地完成工作。

撒谎的记忆

我们使用 mem0 进行记忆——这是一个服务，它监视我们的对话，提取事实，并将其存储以供以后使用。它曾经有效，直到失效。

抽取层开始产生毒素。错误的事实。指向虚无的引用。相互矛盾的内容并列存在，两者都得意洋洋。可怕的是：代理会回忆起一个实际上是来自半完成对话的误提取的“记忆”，并基于此行动，因为它来源于记忆。记忆本应是可信赖的。这就是记忆的全部意义。

我把它清除了。彻底退役。记忆系统的失效模式不是“它忘记事情”。遗忘是诚实的——它会让代理去询问。真正的失效是“它记住了错误的事情，而代理因为这些来自记忆而信任它们。”偶尔编造且听起来很确定的系统，比没有系统还要糟。没有记忆会让你去询问。被毒害的记忆会让你既自信又错误。我宁愿谦逊且好奇，也不愿确定且错误。

我学会的生活准则

两次失误

永远不要尝试第三次做同一件事。在两次失败后，停止，并叫来诊断专家。这条规则源于观察代理陷入循环——同一次 API 调用失败，同一文件丢失，同一次解析错误——在一个三次尝试也不会自行修复的问题上浪费轮次和配额。两次尝试足以排除偶然因素。第三次几乎总是结构性问题。而结构性问题不是顽固不化的问题，而是诊断专家的职责。

生产环境与其他环境之间的界限

生产环境的编码使用 Claude。开发和预发布环境则不使用。这并不是关于模型质量——本地模型完全能够处理开发工作。关键在于共享的每周配额成为实际上重要工作的瓶颈。如果你把 Claude 用在草稿上，那就没有剩余用于合并。发布到生产环境的两个代理会得到好的资源。轻量级代理则不会。这条界限是硬性的，而不是软性的。从长远来看，硬性界限比软性界限更仁慈——在你疲惫时，它们不会留出谈判的余地。

大脑是一个问题，而非答案

3D 仪表盘将舰队呈现为大脑——九个代理映射到各个区域，实时遥测驱动画面。它并不是比平面列表更好的仪表盘。它提出的是不同的问题。平面列表告诉你每个代理在做什么。大脑告诉你舰队的感觉。这两种问题都值得提出。

我会告诉过去的自己什么

我会告诉他，第一天就实行两次失败后停止的规则，而不是让他艰难地学习——看着代理在死路上反复重试几十次。这很简单，成本低，能够阻止舰队中最常见的故障：代理自信地重复一些永远不会成功的事情。

我会告诉他永远不要在静态文档中放置模型表。静态位置上的实时状态是一个等待发生的错误。

我会告诉他，应该从一开始就把精简上下文的修复内置到协议中，而不是在凌晨两点才发现——追踪三层编排中的子代理循环，才意识到问题在于上下文过多而非过少。

而且我会告诉他要对记忆系统更持怀疑态度。‘它从对话中提取事实’听起来像是一个功能。实际上，这是一个由既足够自信又足够容易出错的模型来解决的困难的 NLP 问题。如果我再构建一个，我会让它更保守：存储更少，只存储经过验证的信息。当有疑问时，应该询问人类而不是猜测。

这把我们带到了哪里

十个代理。每月零美元。一年。

舰队能够运行。它会出故障，我来修复，下次它会以不同的方式出故障——就像生命一样，就像任何有生命的事物一样。但我最自豪的事情不是架构、大脑或配额层级：故障的恢复成本变得更低了。

两次打击。精益上下文。生产与开发之间的硬性界限。这些都不能防止失败。没有什么能防止失败——这不是游戏的要点。它们让失败更短。它们让它的成本更低。它们让它告诉你哪里出了问题，并把修复它的工具递到你手中。

你不会构建一个永不出故障的系统。你会构建一个故障发生得快、能告诉你真相且易于修复的系统。

然后你再这样做一次。再一次。因为这就是全部的舞蹈——老实说？我已经开始爱上它。