--- title: "实现复利工程：我是如何通过龙虾构建递归进化的 Agent 闭环" source: wechat url: https://mp.weixin.qq.com/s/FwKQ0QX29pikmIj4IV9pQg ingest_date: 2026-07-04 vxc: 56 stars: 4 sha256: 5ae84221bad36f33b26c178548e8d8a06cfbae522f308395c4a9a6eaf3fd89a3 --- # 实现复利工程：我是如何通过龙虾构建递归进化的 Agent 闭环 **来源**: 高可用架构 **发布日期**: 2026-03-13 **原文链接**: https://mp.weixin.qq.com/s/FwKQ0QX29pikmIj4IV9pQg --- 导读：本文详细描述了 Agent Orchestrator（AO）开源 18 天后的发展历程：一个由 AI agent 构建的 TypeScript 系统，已获 3800+ GitHub Star，通过自改进循环（如 agent 修复 bug 并生成 PR）实现迭代，作者分享了与 OpenClaw 的集成，使 agent 管理从桌面仪表板转向 Telegram 实时交互。 文章焦点在于一夜间 15 个 agent 会话的真实运行：成功合并 6 个 PR，但遭遇认证崩溃、会话死亡和重复任务等故障，这些“信息性失败”暴露了系统弱点，推动了三层升级协议的设计（agent 自愈、协调调解、人类介入），强调可观测性而非完美自治。 作为AI agent 编排领域的实践洞见，该文挑战了“完全自治”叙事，揭示自改进需人类监督以处理 emergent 行为（如跨层依赖），并通过 OpenClaw 辅助撰写文章本身，形成递归反馈循环，启发开发者关注透明度以管理复杂性。 作者：Prateek Karnal (@agent_wrapper)，Composio AI工程师，专注于 AI agent 基础设施。开源 Agent Orchestrator（@aoagents）作者，管理 30+ 并行编码 agent，实现自改进循环与真实世界部署，已获数千 GitHub 星标。热衷分享 agent 编排、反馈对齐与大规模自治系统的工程实践。 18 天前，我们开源了 Agent Orchestrator (AO)。40,000 行 TypeScript 代码，17 个插件，3,288 个测试用例。这是一个用于并行管理 AI 编程智能体集群的系统，而它本身就是由它所编排的智能体在 8 天内构建完成的。 image.png 如果你还没看过那篇文章（小编：参阅文末参考阅读1），简短版总结如下： - 每个智能体都有自己的 git worktree - 自己的终端会话 - 自己的任务 AO 追踪所有动态，监控 CI，处理 PR，并协调这些看似混乱的协作。在开源后的 18 天里，它在 GitHub 上获得了 3,800+ 颗星。 18 天的 AO 战绩： X（原 Twitter）上 98.3 万次曝光，9.49 万次交互，9.6% 的互动率，以及从 0 到 3,800+ 的 GitHub Star。 在发布后的第 3 天左右，我注意到了一些意料之外的事情： 我正在用 AO 开发 AO。 这不是那种常规意义上的“吃自家狗粮（eat our own dog food）”。而是字面意义上的自我开发： - 我会创建一个任务描述 AO 需要的功能。 - AO 就会启动一个code agent，赋予它代码库的上下文，让它开始工作。 - 智能体编写代码、编写测试、开启 PR。 - 另一个智能体进行审查。 - 如果一切通过，代码就会被合并。 - AO 带着新代码重启。下一个任务就在这个改进后的版本上运行。 一步接一步，管理智能体的系统正被它所管理的智能体不断改进。 一个智能体发现了一个竞态条件（race condition），并非因为它在专门找 bug，而是在处理其他任务时撞到了这个 bug。它提交了一个 Issue。另一个智能体修复了它。在那之后，后续的每一次会话都运行得更顺滑。更干净的 PR、更好的审查、更高质量的改进。微小的修复，产生了级联效应。 在另一次会话中，我让编排器分析自己的代码库并提出改进建议。它给出了一些真正深刻的洞察： - 智能体专业化 - 循环失败的模式分析 - 并行化审查瓶颈 这些都是我未曾察觉的。其中三条建议变成了任务。智能体们实现了它们。AO 变得更强大了。 这是自我改进循环的“理想版”：一切正常，每一轮循环都产生比上一轮更好的结果。 但我遇到了一个问题。 AO 有一个完整的 Web 仪表板，带实时终端、看板和会话管理。它确实很强大。但终端在移动端无法正常滚动。 它的界面非常“技术化”：你需要打开浏览器、输入 URL、点击进入终端面板、运行命令。当某个会话在凌晨 2 点崩溃时，你必须起床、打开电脑、拉出仪表板，弄清楚发生了什么。这并不是你在手机上刷 Telegram 时能顺便检查的东西。而我当时已经把大部分时间花在了另一个完全不同的系统上。 ## 为什么要把 OpenClaw 连接到编排器 每个 AI 系统都有一个未解决的“最后一公里”问题： 人机界面 。 工具层出不穷，它们都在构建自己的仪表板、CLI 和 Web 应用。每一个都需要上下文切换。打开浏览器。导航到 URL。学习 UI。记住命令。 AO 也不例外。它有一个很棒的仪表板，包含看板视图、实时终端、会话管理、PR 追踪。它有自己的编排智能体来生成会话、分配任务、监控 CI。AO 是一个完整的系统。它自己处理编排。 但它依然躲在一个 URL 后面。而我并不总是坐在电脑前。 OpenClaw 扭转了这种局面。27.8 万 GitHub Star。但重点在于：市面上有很多集成到 WhatsApp 或 Telegram 的 AI 聊天机器人。你现在就能在聊天软件里和 ChatGPT 对话。这并不是 OpenClaw 的独特之处。 OpenClaw 之所以胜出，是因为它将问题视为“基础设施”，而非“聊天功能”。 聊天机器人是无状态（stateless）的请求-响应模式。你输入，它回答，上下文随即消失。 而 OpenClaw 是你机器上一个 永不停止的进程 ，拥有持久会话、内存文件、工具访问权限、文件系统访问权以及沙盒代码执行能力。网关（Gateway）是会话、路由、工具调用和状态的单一权威。它不是“Telegram 里的 AI”。它是 AI 智能体的操作系统，只不过恰好可以通过 Telegram 访问。 这种工程上的差异至关重要。OpenClaw 负责执行，而不仅仅是生成文本： - 它运行 Shell 命令、读取文件、调用 API、部署代码。 - LLM 变成了操作员，而非回答者。 - 它是事件驱动的，而不仅仅是请求驱动的：它会对定时任务（crons）、Webhooks、邮件到达或心跳信号做出反应。 - 它会主动察觉并采取行动，而无需被动询问。 - 它支持多智能体路由：一个网关，多个拥有不同工作空间和技能的智能体。 - 而且一切都在你的硬件上以本地优先（local-first）的方式运行，拥有完整的系统访问权限。 运行在别人云端的 Telegram 聊天机器人是无法 SSH 进你的服务器或读取你的 codex 认证文件的。我运行它已经好几个月了。它管理我的财务、追踪联系人、写日记、监控我的邮件、部署代码、运行脚本。它是我与数字生活一切交互的单一界面。 对于智能体编排，有四点至关重要： - 常驻无感可用（Ambient availability） ：AO 的仪表板需要刻意访问。OpenClaw 在 Telegram 里，而 Telegram 永远开着。当会话在凌晨 2 点失败时，我不需要去找我的笔记本电脑。 - 自然语言作为通用 API ：AO 的 CLI 有 ao spawn ， ao send ，标志（flags）和参数。OpenClaw 能将“修复终端 Bug”翻译成一系列正确的命令。 - 跨会话的持久上下文 ：OpenClaw 在对话之间保留记忆。它知道 ao-12 昨天在做什么，昨晚什么失败了，本周的优先级是什么。AO 的仪表板显示当前状态。OpenClaw 知道历史和意图。 - 多系统触达 ：OpenClaw 不仅能跟 AO 对话。它还管理我的服务器、我的博客、我的邮件、我的财务。当我说“部署这篇博文然后创建社交媒体草稿”时，这跨越了 AO、Caddy、博客渲染器、静态文件服务器和写作系统。没有哪个单一工具的仪表板能涵盖这一切。 所以这种连接是很自然的。但这里的关键架构决策是：我不是把 OpenClaw 当作一个与 AO 编排器对话的通知层。 我正在构建一个连接器（Connector），让 OpenClaw 直接接管编排器的角色。 AO 一直被设计为带有人类参与（human-in-the-loop）的操作系统。独立的编排器智能体（一个 codex 或 claude-code 会话）一直是人类的替身，做出如果人类在观察时会做出的决定。有了 OpenClaw 连接器，真正的人类正在通过 OpenClaw 进行观察。这个替身变得不再必要了。 带有连接器的 OpenClaw 直接使用 AO 的基础设施：worktrees、tmux 会话、CI 监控、会话管理、仪表板。但是编排决策——构建什么、何时结束卡住的会话、如何拆解问题——来自 OpenClaw 本身，人类就在 Telegram 上随时参与。 没有多余的 LLM 层来翻译意图两次。编排器拥有人类上下文、持久内存和多系统触达能力。上报是瞬间完成的，因为人类已经在对话中了。 独立的 AO 编排器仍然和以前一样工作，它也是带有人类参与的，而不是完全自主的。区别在于哪个智能体处理编排职责。没有连接器，一个专门的 codex 或 claude-code 会话作为编排器。有了连接器，OpenClaw 通过插件接管了这个角色，带来了它的持久内存、多系统触达，以及人类已经在对话中的事实。 然后是递归的想法：让 OpenClaw 使用 Agent Orchestrator 来构建 OpenClaw-AO 连接器，然后在同一次运行中，让 Agent Orchestrator 指向它自己的代码库。人机界面构建了一个更好版本的自己。 ## 连接器实际发布了什么 ao-12 的报告让一件事变得明显：速度来源于拒绝过度设计传输层。 我首先考虑了更深层次的对等协议想法。很有趣，但很慢。实际发布的动作很简单：构建一个 notifier（通知）插件，并路由到 OpenClaw 现有的 hook 入口。 - AO 通知插件 ：@composio/ao-plugin-notifier-openclaw - OpenClaw 入口 ：POST /hooks/agent - 本地传输 ：127.0.0.1 + token 认证 - 会话映射 ：hook:ao: - 交付加固 ：429/5xx 错误时的指数退避 最高杠杆率的测试举措是外部操作员验证，而不仅仅是本地绿灯测试。独立的 OpenClaw 实例，全新检出代码，从源码构建，hook 配置，token 轮换，突发流量，以及实时通道渲染。 - 通过的测试 ：入口，会话隔离，token 轮换，突发处理，以及干净的 deliver: true 渲染 - 差距 ：没有幂等的去重，同一会话的排序可能会因为完成时间而漂移，反向命令路径仍然需要完整的运行时冒烟验证 连接器架构概览 ：AO 插件 → OpenClaw hook 入口 → 操作员通道，具有务实的阶段 0 选择和外部验证。 微型风险地图 ：连接器在类似生产环境的使用中正常工作，但去重、排序保证和反向路径运行时验证是定义下一个加固冲刺的三个差距。 ## 让这一切实际奏效的“烧脑”反馈循环 我们实际运行的循环：OpenClaw 使用 AO 构建插件，另一个 OpenClaw 像客户一样测试它，反馈回到同一个智能体会话中。 ### 15 个并行会话，一个通宵 我想明确一下这里的“自我改进”到底是什么意思，因为很容易夸大其词。智能体自主编写代码。它们运行测试，在 CI 失败时迭代，推送提交。这一部分确实是自动的。 但编排层——决定构建什么、生成哪些会话、注入什么上下文、何时杀掉卡住的会话并重新开始——那是我做的。我整晚都在 Telegram 上，指挥 OpenClaw，OpenClaw 指挥 AO，AO 指挥智能体。三层智能，但战略决策仍然是人类。 这个通宵的运行不是“设定好就不用管”。它更像是在凌晨 2 点通过聊天管理一个由非常快但初级的工程师组成的团队。 下面是那个晚上的实际情况。 头一晚运行的每个会话。绿色的已合并，红色的已死亡，紫色的有一个开启的 PR，琥珀色的还在工作。虚线是会话在重生前死亡的间隙。 ### 第一波：一切正常 会话 ao-3 到 ao-6 很干净。我在使用 AO 时会注意到一个 bug，在 Telegram 上向 OpenClaw 描述它，并告诉它生成一个会话。OpenClaw 会运行 ao spawn ，然后 ao send 注入任务描述。每个会话都有自己的基于 main 分支的 git worktree，在 tmux 内部运行的 codex 实例，以及我描述的任务。 - ao-3 修复了 codex 抑制更新提示的问题。PR #338 ，已合并。 - ao-4 修复了一个被忽略的权限标志。PR #337 ，已合并。 - ao-5 将版本升级到 0.1.1。PR #339 ，已合并。 - ao-6 修复了 PATH 排序以确保 gh CLI 包装器正确解析。PR #343 ，已合并。 四个会话，四个 PR，四个合并。干净利落。教科书般的自我改进循环。系统在自我构建，每一次合并都让下一个会话更顺滑一点。 ao-7 是第一个出问题的迹象。它和 ao-6 在处理同一个问题，但采用了不同的方法。两个智能体，同一个 bug，两个 PR。我杀掉了 ao-7 并合并了 ao-6 的 PR。不是一场灾难，而是一个协调失败。编排器应该检测到重复项。它没有，因为重复检测还没有被构建。 所以我做了一个心理记录：构建重复检测。这个记录变成了一个任务。这个任务最终会变成另一个智能体会话。系统已经在暴露自己的差距了。 ### 崩溃 然后是 ao-9。这是夜晚变得有趣的地方。 ao-9 本应该修复终端组件的 WebSocket URL 路由。一个 15 行的更改。简单到我甚至都懒得为它生成一个智能体。我自己做了编辑，提交，推送，并开启了 PR #346 。 这是一个错误。不是因为代码错了。代码很好。错误在于 ao-9 存在于 AO 的会话列表中，但其背后没有 tmux 会话。其他每一个会话都有一个在 tmux 中运行的实时 codex 进程。ao-9 啥也没有。当你在仪表板上打开 ao-9 时，终端组件试图连接到一个不存在的 tmux 窗格。它无休止地闪烁。重连，失败，重连，失败。 我试图通过在 ao-9 的槽位中生成一个真正的智能体来修复这个问题。但 worktree 已经检出在另一个分支上了。所以我杀掉了 ao-9，创建了 ao-8 来接管，意识到这更糟了，因为现在我为了一个 PR 弄了两个会话。于是我又杀掉了 ao-8，为 ao-9 重新创建了 worktree，并试图手动启动 codex。 codex 立即崩溃了。 只有一行。没有堆栈报错（stack trace）。没有解释。只有“permission denied”。 我运行 strace 想找出它试图读取哪个文件。 auth.json 文件属于 lifeos-secrets:lifeos-secrets 所有，权限为 600。codex 进程作为 lifeos 运行。它无法读取自己的认证文件。 这是怎么发生的？当天早些时候，我在加固 gh CLI 以防止 AI 访问未经授权的 GitHub 仓库。那项工作的一部分涉及将凭据移动到一个名为 lifeos-secrets 的独立系统用户。 auth.json 文件在那次清理中被波及。系统一部分的安全改进默默地破坏了完全不同的另一部分。 对 gh CLI 权限的安全加固更改意外导致 ~/.codex/auth.json 无法读取。每一个新的 codex 会话在启动时都崩溃了。已经运行的会话没问题，因为它们在更改之前加载了 auth。 一旦我找到原因，修复就很简单。删除该文件（目录属于 lifeos ，所以即使文件不属于也可以 unlink），创建一个新的空文件，让 codex 回退到 OPENAI_API_KEY 环境变量。但找到原因花了我 20 分钟进行 strace 和疑惑。 这就是那种不会出现在关于自我改进系统的理论论文中的失败。一个子系统中的安全改进默默地破坏了另一个系统中的身份验证路径。没有测试捕获它，因为测试不是作为不同的用户运行的。直到有人试图启动新会话时，破坏范围才是可见的。 ### 集体死亡 当我在调试 auth 崩溃时，我遇到了一个更大的问题。会话 ao-10 到 ao-14 全部死了。 这五个会话是使用错误的方法生成的。OpenClaw 使用了它的 exec 工具（一个后台 shell 进程）而不是 ao spawn 。直到它们都死了我才发现这个错误。差异很重要。 - ao spawn 创建一个独立存活的解耦 tmux 会话。 - exec 创建 OpenClaw 的 shell 会话的一个子进程。当那个 shell 会话在 600 秒后超时，子进程就会被 SIGTERM 杀掉。codex 进程也就死了。 五个会话，五个任务，全部灰飞烟灭。没有保存任何工作，也没有部分进度。worktrees 虽然存在，但除了基础分支外没有任何提交（zero commits）。这是一个操作员错误。我本应该从一开始就告诉 OpenClaw 使用 ao spawn 。我没有，我丢失了几个小时的智能体工作。 这次我告诉 OpenClaw 通过 ao spawn 重新生成它们，但 AO 是按顺序重用会话 ID 的。所以当我生成替换会话时，它们获得了 ID ao-10 到 ao-14，但具有与原始会话不同的任务。 ao-11 原本是“修复移动终端滚动”。重新生成的 ao-11 变成了“带有重试升级的 CI 自动注入”。完全混乱了到底哪个会话在做什么。 这是一个会话身份问题。会话由顺序数字标识，而不是由它们的任务或目的标识。当 ao-11 死亡并被重新生成时，它仍然应该是“移动终端滚动会话”。相反，它变成了一个碰巧拥有相同数字的完全不同的会话。 ### 递归变得更深 真正诡异的地方就在这里。 重新生成的一个会话，ao-12，得到了一个我已经思考了一段时间的任务：设计 OpenClaw 和 AO 之间的集成。管理我的生活的系统 (OpenClaw) 使用管理编程智能体的系统 (AO) 来构建它们之间的桥梁。 让我再说一遍，因为这很重要。我在 Telegram 上与 AI 助手交谈。助手正在使用智能体编排器生成编程智能体。其中一个智能体正在设计助手应该如何与编排器集成。智能体正在为最终将取代手动创建过程的系统编写设计文档。 三层递归： - 人类与 OpenClaw 交谈 - OpenClaw 使用 AO 生成智能体 - 智能体设计 OpenClaw-AO 集成 而使它有趣的是这点。我整晚都在遭遇失败，感到沮丧，手动修复问题。在某个时候，我告诉 OpenClaw：“把今晚所有出了什么错的上下文都给 ao-12，这样它就可以围绕这些问题进行设计。” OpenClaw 将我遭遇的每一个失败打包：会话默默死亡、消息未提交、ID 被重用、没有健康监控、没有自动重生，并将其作为设计需求注入到智能体中。 智能体并没有发现这些需求。是我发现的，通过糟糕地操作这个系统并注意到什么坏掉了。然后我将这些观察结果输入给能够将其转化为设计的智能体。洞察力是人类的。执行是自动的。 元结构：我与 OpenClaw 交谈，它使用 AO 生成智能体，其中一个正在设计 OpenClaw 应该如何与 AO 集成。今晚的失败成为该设计的需求。 这就是自我改进循环，但它不是我在第一篇文章中描述的那个干净的版本。它很混乱。改进来自于崩溃和困惑，而不是来自于优雅的元分析会话。系统在崩溃中学习。 ## 三层“自愈与上报”机制 那天晚上的失败结晶成了一种架构。我称之为 三层上报协议 (three-tier escalation protocol) 。 第 1 层：智能体自愈。 当 PR 上的 CI 失败时，失败输出会自动注入回智能体会话中。智能体读取错误，修复代码，再次推送。最多尝试 5 次后放弃。没有人类参与。会话 ao-11 构建了这个并提交了 PR #354 。这是目前唯一实际实现的一层。 第 2 层：编排器调解。 如果智能体尝试 5 次后仍无法修复，上报给编排器会话。编排器本身也是一个 codex 实例，拥有关于所有活动会话的上下文。它可以查看失败智能体的代码，理解更宏大的画面，并提出修复建议或重新思考方法。这一层已设计但尚未构建。 上报架构。每个边界的消息格式相同。OpenClaw 完全取代了独立的编排器。保留了三层：OpenClaw，连接器插件，以及各个编程智能体。 第 3 层：通过 OpenClaw 上报给人类介入。 如果编排器处理不了，发送一条消息到我的 Telegram。比如：“ao-14 在 activity state 修复上的 CI 失败了 5 次。错误是 codex 插件中的类型不匹配。”我在聊天中回复，响应路由回智能体。这正是 ao-12 正在设计的。也尚未构建。 关键设计决策：协议是统一的。消息格式是相同的，无论是从智能体到 OpenClaw 还是从 OpenClaw 到我。OpenClaw 完全取代了独立的编排器。保留了三层：顶层的 OpenClaw（人类就在对话中），桥接到 AO 基础设施的连接器插件，以及各个编程智能体。OpenClaw 不是一个通知侧边栏。它是上报协议中的一个对等方，有能力进行自主解决和人类移交。 ## 战绩板 到早上 6 点，通宵的会话产出了： - 6 个合并的 PR ( #337 , #338 , #339 , #343 , #346 ，以及之前的一个) - 2 个开启的 PR ( #353 用于仪表板丰富化， #354 用于 CI 自动注入) - 4 个积极工作的会话 (OpenClaw 集成设计，终端修复，活动状态修复，导航栏修复) - 6 个死亡并重生的会话 - 1 个阻断所有新会话 20 分钟的身份验证崩溃 - 1 起重复工作事件 (ao-6 和 ao-7 修复同一个 bug) - 0 个引入主分支的回归错误 (regressions) 早上 6 点运行的系统比晚上 6 点时好得多。不是因为任何单个改变，而是因为所有改变加在一起。codex 插件正确处理了权限。PATH 解析工作正常。版本升级了。终端 WebSocket 通过反向代理连接。仪表板显示实时 PR 数据。 并且还有三个会话在运行。它们是会产生有用的东西还是默默崩溃，直到我早上检查时才会知道。 ## 自我改进到底是什么样子的 第一篇文章（小编：参考阅读文章1）详细走了一遍循环。8 个步骤，文件锁定示例，会话 ao-52 的自我分析。真实代码，真实会话，真实改进。所有那些都是真的，并且现在依然如此。 但是大规模地在一个通宵并行运行 15 个会话的循环呢？这完全是另一回事（that's a different animal）。 会话死亡是因为我告诉 OpenClaw 使用了错误的生成方法。我做的一个安全更改破坏了另一个工具的身份验证。消息被粘贴到 codex 的输入缓冲区，但 Enter 键从未触发，我必须注意到智能体卡住了并在服务器上手动按下 Enter。会话 ID 被重用，我失去了对哪个智能体在做什么的跟踪。 自我改进仍然在发生。但它不是自动的。我注意到失败。我理解出了什么错。我告诉 OpenClaw 把那个失败作为需求反馈回去。 - auth 崩溃？我告诉 ao-12 在设计中包含“崩溃取证”。 - exec 超时？我告诉它添加“会话健康监控”。 - ID 重用？“会话身份绑定到任务，而不是顺序数字。” 系统通过犯下“具有启发性”的错误来实现改进。但是这所谓的“启发性”，前提是得有个大活人在凌晨 2 点盯着它。 ## 在大规模下发生了什么变化 在第一篇文章中，我描述了三个阶段：智能体作为工具，智能体作为工人，智能体作为自我改进系统。我走查了每一个的具体例子。我说阶段 3 是“质的不同”。 我是对的，但质的不同并不是我预期的那样。它不是系统变好得更快。它是系统生成了自己的改进待办事项（backlog）。 当你将智能体作为工人（阶段 2）使用时，你告诉它们构建什么。你维护待办事项。你排优先级。你决定什么重要。智能体是熟练劳动力，但方向完全是人类的。 在阶段 3，系统产生失败，暴露需求，生成任务，智能体实施任务。我并没有计划去构建会话健康监控。五个会话在凌晨 2 点默默死亡，这个需求变得显而易见。但坦白说：需求并没有“自己写自己”。我注意到了问题，理解了它，并将它变成了一个任务。系统暴露了失败。我做了诠释。智能体做了执行。 也许这仍然是阶段 2.5。完全自主的版本——系统检测到自身的失败，并生成智能体在没有人类于凌晨 2 点注意到的情况下修复它们——正是上报协议旨在启用的。我还没到那一步。但基础设施正在由需要它的相同智能体构建，这至少是有诗意的。 ## 让我感到害怕的部分 我得坦诚一件事。在凌晨 3 点，当我看着 ao-12 为最终将监督所有其他智能体（包括自身未来版本）的系统编写设计文档时，我有一刻想过：我不确定我完全理解我正在构建什么。 不是终结者那种。是在工程复杂性方面。系统有三层 AI（OpenClaw，AO 编排器，个体智能体），每一层都有不同的模型、上下文和失败模式。这些层之间的交互产生了我也没预测到的涌现行为（emergent behaviors）。auth 崩溃是一个涌现行为。exec 超时是一个涌现行为。消息传递失败是一个涌现行为。 随着这些层整合得更加紧密，可能的涌现行为空间呈组合式增长。我可以测试单个组件。我可以测试成对的交互。但是测试完整的系统需要运行完整的系统，而完整的系统就是生产环境。 这就是为什么我在构建上报协议。不是因为我认为系统会失控。因为我认为系统会以我无法预测的方式失败，我需要一条从“什么东西坏了”到“人类知道了”的可靠路径，并且这条路径本身不会以新奇的方式坏掉。 自我改进系统的安全机制不是阻止改变。它是确保可见性（visibility）。如果我能看到系统对自己做的每一次修改，我就能在问题复合之前抓住它们。如果我失去可见性，我就失去控制。而在这么复杂的系统里，失去可见性比听起来更容易。 ## 这篇文章是循环的一部分 我应该提一下这篇博文是怎么写出来的。 我在 Telegram 上告诉 OpenClaw：“写一篇博客，关于我是如何通过让 OpenClaw 使用 Orchestrator 来构建它从而构建 OpenClaw-AO 集成的。” 它阅读了第一篇文章以供风格参考，写了一份草稿，保存到服务器，发给我一个链接。我读了。它有些地方写错了。它夸大了系统的自主性。我让它修改。它改了。我告诉它图表需要做得更好。它重做了。我告诉它包含 star 历史图片。它加了，在过程中破坏了 YAML 配置，它把这也修好了，并给我发了一个新链接。 你现在读到的这一段是在我告诉 OpenClaw 之后写的：“文章让系统看起来比实际上自主得多。真实一点。” AI 写了一个更诚实的版本。我正在审查它的同一个服务器也托管着 AO 仪表板，该仪表板监视着正在构建我正在撰写的特性的智能体们。 它是递归的，是的。但在每一个层级，都有一个人类在阅读、判断、重定向。自动化处理打字。人类处理思考。 ## 循环继续 现在是周日早上了。会话仍在运行。 - ao-12 正在编写 OpenClaw 集成设计。 - ao-13 正在修复移动终端。 - ao-14 正在修补活动状态错误。 - ao-15 正在修复导航栏链接。 当写完这篇博客时，其中一些 PR 就会被合并。系统会变得更好。新的 bug 也会出现。将会生成新的会话来修复它们。 循环没有停止。它没有一个干净的终点。没有一切完美运行的 2.0 版本发布。只有持续的、渐进的、混乱的改进。编码是自动化的。方向依然是我，在 Telegram 上，在凌晨 3 点，告诉 AI 助手下一步修什么。 我在第一篇文章里写过，率先掌握自我改进智能体系统的公司将拥有巨大的优势。我详细说明了原因：应用于工程能力的复利。我仍然坚信每一个字。 但我会加上以前没有意识到的事情：优势不在于拥有一个干净的自我改进循环。而在于拥有一个你可以观察、调试和引导的混乱循环。 不断自我构建的系统不需要完美。它需要透明。 Agent Orchestrator 开源于 github.com/ComposioHQ/agent-orchestrator。仪表板、会话管理和上报协议都在仓库中。我在 Composio 开发 AI 智能体。如果你正在构建编排系统或思考自我改进循环，请在 Twitter 或 GitHub 上找到我。 原文 https://x.com/agent_wrapper/status/2031057214002311560 ## 参考阅读 - 8天，4万行代码：一个递归进化的agent编排器是如何“手搓”出自己的? - 理解 Prompt Cache 与 Agent 的“上下文税”：AI时代架构纪律 - 如何手搓一个 CLI：只需 80 行代码，彻底看清 AI 的底层逻辑 - 从任务到系统：深度拆解2027年百万年薪的6项AI核心技能