📄 本文提炼并改写自 Archestra 团队 Joey Orlando 的文章《We Fix Small Bugs by Dropping a 🦀 in Slack》，原文链接见文末。

一个工程师在用自家产品的聊天界面时，发现了个小毛病：一旦上下文开始压缩，他就没法继续输入，只能干等。按老规矩，这事会变成一张 ticket，一次上下文切换，然后被丢进 backlog，和另外六十个 bug 一起排队，等一个「有空再修」。

Archestra 团队现在有另一种做法。工程师在 Slack 线程里贴一行描述、附一张截图，末尾加一个 🦀 表情。三分钟后，一个机器人回复了 SSH 命令、应用地址和操作说明。再等几分钟，一个修好的 PR 已经躺在仓库里，等着人点 “Ship it”。

那只 🦀 就是他们内部的 Crab Bot。这篇文章想聊的不是「AI 帮你写代码」，而是一个更完整的思路：让编码 agent 包下 bug 的整个生命周期。

从表情到 PR 的完整链路#

当 🦀 出现在线程里，事情是这样发生的。集群里的一个控制器收到请求，立刻在 GCP 上拉起一台虚拟机，机器上预先配好了一整套开发环境：仓库已经 checkout、一个本地 Kubernetes 集群、跑完整技术栈的 Tilt、无头 Chromium，再加上两个关键组件，OpenAPPA 负责数据边界，nitpicker 负责自审。最后，它启动一个 Claude Code 会话，让 agent 先读那条 Slack 线程，搞清楚要做什么。全程没有人在旁边盯着。

三个值得借鉴的设计#

第一，你可以随时插嘴。 agent 会轮询自己的 Slack 线程，你在原线程里随手补一句，它就把这条信息并进正在进行的任务里。以前「补充一个想法」意味着打断、切上下文、重新同步，现在只是在线程里多打一行字。

第二，它读的是原始现场，不是二手转述。 会话收到的不是消息文本，而是一个指向线程的指针，然后它自己去读原始内容。这一点对截图尤其关键。很多 bug 报告就是一张图，与其依赖别人对图片的文字转述，不如让 agent 自己打开原图看，人肉转述的误差在这里被绕开了。

第三，它先自审，再交差。 PR 打开后，会话会运行 nitpicker，用多个模型同时审 diff，把结论合并成一条评论。接着会话把这条评论当成真实的审查反馈，修掉有道理的问题，对没改的部分给出解释。于是第一个打开 PR 的人，看到的是已经经历过一轮批评、且分歧都写清楚了的代码。

还有一个细节很讨喜：修完后，会话会自己录一段演示视频。它用 shot-scraper 这个 Playwright 驱动的工具，把修好的功能实际操作一遍，再把录屏贴回 Slack 线程。工程师只需看视频、回一句 “Ship it”。

真正的问题：数据会流向哪里#

以上还只是「小 bug」的场景。可一旦把任务升级成「我们的 staging 部署变慢了，去查查为什么」，局面就不同了。agent 不能只读 diff，它得看运行中的系统：pod、重启记录、OOM、容器日志、资源限制，可能还要看通话录音、产品分析数据，以及那条三个人已经讨论到一半的 Slack 线程。

于是你手上有了这么一个东西：一个能读内部数据的 agent，客户名、租户数据、集群内部、生产截图都在它眼皮底下；同一个 agent 还有网络连接和 web 工具；而且它能把代码推到一个公开的 GitHub 仓库。这就是他们说的「致命三角」，还偏偏是在一台没人盯着的机器上、故意接通的。

你当然可以在 prompt 里写规则：用中性术语描述工作、绝不点名客户。但 prompt 指令的可靠性，跟模型当天的心情差不多，算不上「直接控制」。Simon Willison 今年早些时候就公开预测，2026 年会出现「编码 agent 安全的挑战者号灾难」，针对的正是这类攻击。

OpenAPPA：给数据打上「内部」标记#

他们的答案是 OpenAPPA，一个本地策略引擎，MIT 协议，目前还是预览版。思路很朴素：跟踪 agent 读过的数据，然后在每一次工具调用执行前检查一下，这次调用合不合规。

规则只有三条。会话一开始是「无限制」状态；一旦从内部工具读数据，会话就被标记为「内部」；被标记之后，它就不能再往公开目标发布内容，除非经过授权审查。比如读完内部 Slack 线程后，agent 没法顺手把学到的内部日志贴进一个公开的 GitHub issue，因为 OpenAPPA 会在工具调用执行之前把它拦下来。

它同时覆盖 MCP 工具和 CLI 工具。团队还加了个脚本，检查 kubectl 读的是哪个集群，非本地集群的输出一律标记为内部，云 API 的读取同理。万一 agent 用脚本认不出的方式伪装命令，OpenAPPA 内置的 LLM 分类器会作为第二道防线，帮忙识别那些读取内部数据的调用。

我的几点看法#

这套东西最打动我的，不是某个单独的技术点，而是它把「自动化」重新定义了一遍。过去我们聊编码 agent，焦点总在「它代码写得怎么样」；而这里，写代码只是其中一环，agent 真正接管的是从报修、排查、修复、自审、演示，一直到 PR 提审的完整流程。人的角色被压缩成四件事：描述 bug、看视频、说 “Ship it”、审 PR。

另一个值得注意的点是边界划分得很诚实。作者明说，这套东西擅长的是「小、描述清楚、自包含」的修复，但凡涉及品味、架构、需要争论的事，一律不让 agent 独立碰。PR 先开在私有镜像上，只有人说了 “Promote” 才会公开。这种「该放手的放手，该卡住的卡住」，比盲目鼓吹 agent 全能要务实得多。

至于 OpenAPPA，本质上是一种信息流控制（information flow control）：数据一旦被打上「内部」标签，这个标签就跟着它走，任何可能把它带出边界的操作都会被拦。这让我想起编程语言里 taint analysis 的老思路，只是它被搬到了 agent 的工具调用层。在 agent 越来越频繁接触生产环境的今天，这类「数据去哪儿」的护栏，可能比「代码写得好不好」更早成为标配。

结语#

把一个 bug 从「一张 ticket」变成「一条消息」，省下的不只是几分钟。它改变的是一种心态：当小 bug 的修复成本低到几乎可以忽略，很多以前「算了不修了」的问题，会重新变得值得修。前提是，你得先想清楚 agent 能读什么、能把数据带到哪里。否则，那只帮你修 bug 的螃蟹，也可能变成下一个上头条的安全事故。

参考来源：

  • 本文提炼并改写自 Archestra 团队 Joey Orlando 的文章《We Fix Small Bugs by Dropping a 🦀 in Slack》：https://archestra.ai/blog/fixing-small-bugs-from-a-slack-thread