智能体可以消亡，工作得以延续；这在真实生产系统上被验证过；请试着破坏它

TL;DR：我已经把 mishe-tauftauf 开源了——一个用于编码智能体的小型本地协作系统，我已经在真实的生产工作中使用过它。一个早期版本曾帮助我们以三人团队打造并运营一个广告技术 DSP：四个月从零到生产环境，约 5 万 RPS，实时 RTB 竞价，真金白银，真实的 on-call 责任。现在我希望其他人把它植入自己的真实项目中，试着破坏它。给它一个你熟悉的代码库，让智能体在全新的上下文之间工作，看看协作、恢复或证据在哪些环节不再可靠。文档、研究、数据管道、丑陋的遗留系统、硬件——对我来说，更陌生的环境比再一个编码演示有用得多。整个项目采用 CC0 1.0 协议。可以 Fork、改名、砍掉一半、偷走其中一个机制。无需署名。GitHub 地址：genaforvena/mishe-tauftauf 其背后的思想，就是我一直所说的“面向可观测性编程/开发”。通常意义上的可观测性是从软件已经存在之后才开始的：为系统插桩，以便理解它在做什么。我感兴趣的是把同样的原则应用到开发过程本身。如果一个智能体不知道某件事是否成功了，这种不确定性就应该立刻变得可观测。如果证据过时了，就应该看得见。如果一个检查项无法真正确立它所声称的结论，它就应该报告 UNKNOWN。目标是打造一个薄如冰层的反馈循环：某事是未知的 → 暴露缺失的信息 → 观察它 → 行动 → 再次观察 这听起来稀松平常，但大量智能体的出错行为恰恰发生在这些步骤之间的缝隙里。缺失的观察变成了假设。旧结果变成了当下的真相。“命令执行成功”变成了“任务已完成”。一个全新的智能体继承的只是关于“据说发生了什么”的文字描述，而不是它可以亲自检验的东西。Mishe 的构建目标就是试图缩小这些缝隙。它的智能体——“心智（minds）”——是刻意短暂的。它们可以被重启、替换或赋予全新的上下文。我并不太努力去维护智能体本身的连续性。相反，工作的连续性由小型的状态文档（“墙 walls”）的反复重写、共享的文本磁带、检查项、产物以及明确的未完成义务来承载。一个全新的心智应该能够到来、检视世界当前的状态、看到还有哪些未解决的问题，然后继续下去。它不应该需要去重建上一个智能体的思路。 基本循环是刻意保持简短的：观察 → 选择一个有边界的动作 → 行动 → 观察结果 → 重复 检查项会返回 GREEN、RED 或 UNKNOWN。UNKNOWN 很重要。如果 CI 访问权限消失了、某个探针停止更新、证据互相矛盾，或者检查项本身无法确立它所声称的结论，答案就保持未知。证据的缺失不会被悄悄地提升为成功。智能体也可以修复它们所依赖的机器。如果一个检查项在说谎，这个检查项本身就可以成为任务。如果一条指令不断产生糟糕的行为，这条指令就可以被修改。因此，这个系统不仅观察软件，也观察那些被用来对软件做出判断的观测本身的质量。 我开始认真对待这件事，是因为这个早期版本的文化在接触生产环境后存活了下来。我当时是一个三人团队的技术负责人/后端工程师，从零开始构建一个广告技术 DSP。大约四个月后我们上线，处理约每秒 5 万个请求，并参与实时 RTB 竞价。需要精确地说：智能体并没有替我们构建这个 DSP。是工程师构建的。有用的部分在于——当系统快速变化、错误会产生真实后果时——让工作、证据、交接和恢复路径保持可见。随着时间推移，我还移除了数量惊人的协调机制。没有一个宏大的规划器在构建完美的任务 DAG。心智们看到可观测的状态、自己的职责和共享的证据，然后选择有价值的工作。更多的编排机制只会不断制造出新的状态，而这些状态本身又需要被协调、被观察、被修复。因此，我现在想测试的问题，与其说是“智能体能不能写代码？”，不如说是：如果环境足够可观测，有用的工作能否在智能体反复消亡之后幸存下来？ 这就是我在这里发帖的原因。我已经见识过孕育 mishe 的那个环境内部发生的一切。这些证据被熟悉度污染了。我希望有人把它移植到一个充满敌意的地方。如果你尝试了，我尤其感兴趣的是那些失败案例：没有人注意到的过时观测、重复的工作、循环往复的恢复、丢弃了重要信息的墙、永远无法解除的 UNKNOWN、事实证明必不可少的人类干预，或者你在第一天就删掉的抽象。 再说一次：CC0 1.0。如果某个机制有用，就拿去。如果你的 Fork 证明了其中大部分东西都是不必要的，那同样有价值。我真的想知道最先崩掉的是什么。