团队放弃异步后台代理，转向交互式代理机器人

00:00 1 2 6 447 那一刻我意识到，如果你把异步工作交给 agent 处理，最好要么闭环，要么关掉会话，否则最稀缺的资源——人的注意力——就会被频繁切换任务给淹没。异步唯一可行的方式，是你已经闭合了整个验证回路，能立刻自动推送到 main。但我们很多人还没到那一步——在「上线」这个环节，我们还是更愿意亲自盯着。

总之，10 月 8 号那天早上，Igor 叫团队快速聊一下。接通电话后他特别兴奋，给我们展示了 @ calvin 这个 bot——「兄弟们看，它太快了，我甚至都不用离开聊天窗口」，他说。

确实如此，它的响应和反馈几乎是瞬时的。即使是它在工作的时候，也用一种很有魅力的方式展示进度，细节量_恰到好处_。

再补充一些背景，说说我们为什么选了这条路：今年早些时候，我们对用什么工具其实没什么偏好，每个人都用自己觉得合适的工具。结果挺让人头疼的，因为我们会以 PR 的形式交付功能。有意思的是，很多导致这个 PR 的决策、讨论和探索，往往都丢在你和 agent 的聊天记录里了。那一刻我意识到，把聊天上下文分享给团队是多么有价值。本质上就是把「该分享的东西」从 PR 往左移——因为所有有价值的知识都在那里。

所以那天我们决定把所有功能开发和修复工作都迁到 Slack 上，并把我们的应用重新命名为 @ computer，走《星际迷航》主题。回头看十月，这是全团队的成绩：

我个人在十月完全没碰过本地的 codex，除了在我已登录的浏览器会话里做一些浏览器控制类的任务。

你也会注意到，它的用途已经超出了写代码，延伸到了研究不同方法、自动化、数据分析以及一些 GTM 相关的工作。对我个人来说最大的转变是，你几乎不用等回复，所以当我在 @ computer 的某个 thread 里时，上下文切换几乎不会发生：

我们的代码分散在 3 个 repo 里，另外还有一个「knowledge」repo，所有 agent 的规划工作都放在那里。对于任何超出小修复范围的工作，我们通常会要求 agent 写一份详细的 plan spec 并推送到 knowledge repo，这样后续的会话就能看到它。

plan 完成后，agent 就可以实现这一部分并创建必要的 pull request，它会写基础测试，必要时还能在 preview 环境里验证。

把会话迁到 Slack 之后，最酷的一点是它瞬间变成了多人协作。以前你想让另一个团队成员参与某个决策，得把本地的 agent 上下文复制粘贴过去，拿到他们的想法再回来。但现在你只需要 @ 他们，就能得到他们的意见，或者直接分享结果：

在这个例子里，Utpal 当时在做站点可发现性方面的工作。最酷的是他不需要解释做了什么，一切都在 thread 里。

拥有一个共享的上下文空间也更酷，因为如果一个功能有多个人在参与，你可以开一个 thread，第二个人直接进去继续做。或者如果某人开了一个 quick thread 但放弃了，另一个团队成员可以直接跳进去接着干。

此外，如果客户在 Slack 里抱怨某个 bug，把请求转发到某个频道、@ computer，就能直接开始处理。

一开始我们有一个统一的 #dev 频道处理所有工作，每个功能工作是一个 thread。但后来我们开始把它们拆分成 ux、features、bugs，每个都有单独的频道。不得不说

在 Slack 里做所有事情，我们面临的问题是：还是很难一眼看清做了什么，所以 UI 在这方面不太行。Slack 里有个「agents & tools」标签页，但如果 thread 超过几个，我经常会在里面迷失。

如果能有一种方式，一眼看出还有哪些在等我处理、哪些是已经闭环可以隐藏的，那就太好了，这样我的注意力回路能管理得更好。

如果你也想在团队里开启这段旅程、寻找从哪里入手，试试 opencomputer.dev，它是最快的 coding agent，天生就是为在 Slack 里使用而打造的。