用 Claude Code 复刻多智能体编排器

开场：我读完公告，却越看越糊涂

2026 年 8 月 4 日，AWS 发布了开源的「多 Agent 编排器」Kiro Crew——它是一个持续运行的单一进程，可以让 AI 编程 Agent 在多轮交互之间始终保持活跃，为其提供记忆、调度器和安全护栏，并允许你通过 CLI、Slack、Telegram 或 Web 仪表盘与它交流。

我读了 README，也读了源代码，可我依然无法在脑海中清晰地描绘出：系统运行时，这些组件究竟是如何组合在一起的。

于是，我采用了自己在「光靠阅读还不够」时一贯的做法：亲手构建一个属于自己的版本。我使用每天都会用到的 Claude Code CLI 作为执行引擎，替代 kiro-cli。这样做不是为了和 Kiro Crew 竞争，也不是要取代它，只是想通过真正让每个组件运转起来，迫使自己理解其中的所有细节。

这篇文章会介绍我构建的 claude-crew，深入研究后看到的 Kiro Crew 完整功能，以及我的版本在哪些方面刻意没有达到原版的能力。我还会讲到几个如果再来一次，我依然会坚持的决定：只在本地运行、使用 Tailscale 而不是云服务、采用操作系统级 sandbox，以及——没错——一个模仿 Windows 1.0 风格的 UI。

源代码已经放在 GitHub 上，整个项目始终将 Kiro Crew 自己的代码仓库作为设计参考。

逐项拆解：Kiro Crew 究竟是什么

去掉营销话术之后，Kiro Crew 本质上是一个持久化、支持多种交互界面的 Agent 编排器。听起来有些拗口，下面逐一解释每个词能为你带来什么。

持久化——关闭终端时，Agent 进程不会随之退出。它会继续运行并保留自己的记忆，你可以稍后接着之前的对话继续，甚至可以换一台设备。

多种交互界面——你可以同时从多个入口访问同一个正在运行的 Agent：CLI、Slack、Telegram，以及 Web 或桌面仪表盘，它们连接的都是同一个底层 session。

编排器——它不会只回答一次 prompt 就停止。它可以安排周期性任务，以类似 cron 的方式运行；可以生成 sub-agent，并行处理任务；还可以持久保存自己在不同 session 中学到的内容。

具体来说，根据 AWS 自己发布的公告和代码仓库，Kiro Crew 提供了以下功能：

• 一个 Gateway 进程，将所有交互界面（CLI、Slack、Telegram 和仪表盘）复用到同一套共享的 Agent runtime 上，并通过 Agent Client Protocol（ACP）驱动 kiro-cli。

• 跨 session 的持久化记忆。

• 用于执行周期性无人值守任务的调度功能。

• 审批工作流——某些操作必须得到人工确认后才能继续执行。

• sandbox 和带签名的审计日志，既能限制 Agent 的操作，也能在事后证明它做过什么。

• Web 和桌面仪表盘，用来观察 Agent 正在执行的操作。

• 开发者工具集成——调查事故、监控 pull request、分流处理工单。

这确实是一个覆盖面很广的系统。读懂它是一回事，理解每个组件为什么存在，以及缺少其中某个组件会导致什么问题，则是另一种层次的理解——而这种理解，往往只有亲手尝试构建它才能获得。

我实际构建的东西：claude-crew

我保留了整体架构的基本形态——一个持久运行的进程、多个交互界面，以及一个不允许被绕过的安全层——然后替换了执行引擎。

工作量最大的部分：安全

这是我在开始之前严重低估的部分。一个能够在你的机器上无人值守地执行 shell 命令、长期运行的 Agent，绝不能只依赖「规则说了不允许」来获得信任。因此，claude-crew 设计了三层防护，而且每一层都假设它上面的防线可能失效：

• PreToolUse gate。在任何 tool call（读取文件、执行 shell 命令、获取 URL）真正执行之前，hook 脚本都会根据一组规则对其进行检查——这个工具是否被允许使用、文件路径是否位于受保护目录中、shell 命令是否匹配 denylist 中的模式。这属于 policy layer，而经过混淆的命令有可能绕过 policy layer。

• 操作系统级 sandbox。由于针对字符串制定的规则可以被绕过，真正的 claude 进程会运行在 sandbox-exec（macOS Seatbelt）或 bubblewrap（Linux）之中。即使规则被绕过，kernel 本身也会拒绝写入。我亲手验证过这一点：在 sandbox 中执行 echo x > ~/some-file，会直接返回 “Operation not permitted”，没有任何商量余地。

• 带签名、防篡改的审计日志。gate 作出的每项决定都会被记录下来。棘手之处在于：gate 运行在 sandbox 内，因此不能信任它自行签署日志条目——遭到入侵的 gate 完全可以重写历史记录。所以，gate 只会把未签名的条目追加到 spool 中，再由另一个运行在 sandbox 外部、持有真正签名密钥的独立进程清空 spool，将条目签名后写入采用 hash chain 的日志。开发过程中，我在这里发现并修复了一个真实的 bug：spool 中只要出现一行格式错误的内容，整个审计链路就可能永久卡死，而且不会产生任何提示。这正是那种只有真正尝试攻击自己的系统时，才会发现的问题。

在这之上还有一套审批工作流——这是 Kiro Crew 自己的 README 中列出的功能，也是我最初跳过的部分。等到真正实现它时，我采用了最直接的设计：对于某些工具，gate 会把待处理请求写入磁盘，然后阻塞并持续轮询，直到有人在小型仪表盘（或 CLI）中点击允许或拒绝；如果等待超时，则自动拒绝。Headless 模式下没有可供回退的交互式 prompt，因此「等待人工处理」必须被实现为真正的等待过程。

UI：没错，它采用了 Windows 1.0 风格

仪表盘是一个不依赖任何第三方库的单页 HTML，通过 Server-Sent Events 提供实时数据。做到某个阶段时，我突然意识到，没有任何东西能够阻止我把它设计成自己喜欢的样子。于是，我加入了斜条纹标题栏、带浮雕效果的按钮，以及直接取自 1985 年的等宽字体「MS-DOS Executive」美学。它不承担任何关键功能——当整个 UI 层只是由几百行自己编写的 CSS 组成，而你又决定从中找点乐子时，最终就会变成这样。

我究竟是如何构建它的

我把开发过程拆分成多个阶段，每个阶段的范围都足够小，能够在进入下一阶段之前亲手完成验证：首先实现 session 持久化和 warm process pool，接着是记忆、调度、完整的安全层、daemon 与仪表盘，最后才是审批工作流。每个阶段结束后都会进行两轮彼此独立的审查——一个 Agent 专门寻找过度设计和不必要的复杂性，另一个则专门检查安全漏洞。每一项发现，我都会在真实机器上复现，确认无误后才相信相应的修复。通过这种方式，我们发现了几个真实存在的漏洞，其中包括审批工作流自身决策记录函数里的一个 path traversal bug：任何持有仪表盘 token 的人，都可以利用它覆盖任意配置文件。

对于「验证它确实能够工作」这件事，我没有走任何捷径。为了检查 sandbox 的隔离能力，我真的尝试向允许范围之外的路径写入文件，然后亲眼确认操作失败。为了检查进程能否自动重启，我对 daemon 执行 kill -9，并记录它重新启动所需的时间。为了检查 token 泄露的攻击面，我从未经授权的 origin 打开仪表盘，并确认请求遭到了拒绝。如果我不能亲眼看到它发生，就不会声称这个功能有效。

claude-crew 刻意不如原版的地方

有几项功能是我有意没有构建的：

• 没有集成 Slack 或 Telegram。目前，我并不需要通过聊天界面访问自己的 Agent。仅仅为了「以后可能用得上」而构建它，恰恰属于那种我会劝别人不要添加的推测性功能。如果未来需求发生变化，现有 Gateway 已经支持添加新的交互界面，无须修改 session 层或安全层。

• 没有开发者工具集成，例如 PR review、事故调查和工单分流。理由相同——这些功能目前都没有接入，因为我现在还不需要用它们做任何事。

• 没有桌面应用。只提供基于浏览器的仪表盘，以便将依赖数量维持在零。

• 所有内容都保留在本地运行，没有托管到云端——这是出于安全考虑而刻意作出的决定。我曾研究过使用 Vercel 和 AWS 托管仪表盘，但最后都放弃了：这个系统会在操作系统 sandbox 中生成真实的 subprocess，持有私有签名密钥，并管理一个能够执行 shell 命令的在线 Agent。只要没有必要，这些东西就不应该放在面向公网的服务器上。作为替代，整个系统都运行在我自己的机器上，我通过 Tailscale——一种私有 mesh VPN——从手机或其他电脑访问仪表盘，完全不需要把它暴露到开放的互联网中。tailscale serve 甚至还能免费提供真正的 HTTPS 证书，无须购买域名，也不会产生云服务账单。

（21 秒演示：复古风格的仪表盘、实时 SSE 连接，以及一个 Bash tool call 在获得人工批准之前被阻塞，批准后才获准运行。）

我真正从中得到了什么

按照 AWS 的描述，Kiro Crew 确实是一个范围界定得很好的想法——长期运行的 Agent 需要有一个容身之处，需要记忆，需要安全护栏，也需要不止一个访问入口。尝试从头开始，基于不同的执行引擎重建一个版本，最终让我真正理解了这一切，而这是只读 README 无法做到的。如果你读过某个东西，却依然觉得自己没有完全理解——那么亲手重建它，或许也是你的答案。

源代码：整个项目始终以 Kiro Crew 自己的 GitHub 仓库作为设计参考；claude-crew 的代码也已发布在 GitHub 上（链接见个人资料）。

这是一个独立的个人项目，与 AWS 没有任何关联，未得到 AWS 的认可，也并非由 AWS 构建。

如果需要采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。