Ryan Carson：一个经理智能体协调 20 个编码智能体

我创立 Untangle 是为了减轻离婚带来的痛苦。我们最初做的是面向消费者的应用，后来转型，为家庭法律师事务所提供 AI 法律助理。这个问题与我个人有关：我的父母和两个姐妹都经历过离婚。

我创办过四家公司，上一家公司扩张到约 110 人。我发现管理人的经验也适用于管理智能体。在 Untangle，人负责确定优先级、与客户交谈，智能体则完成大量实施工作。

我们的工程工作使用云端的 Devin。每个工程经理智能体其实只是一个持续的会话：它不写代码，而是协调子会话，代我回答技术问题。

我主要通过语音与经理智能体交流，因为我更容易吸收音频。Linear 工单看板是工作的共同依据，每张工单对应一个拉取请求；经理按照依赖关系挑选任务。

一个经理可以同时管理约 20 个构建智能体，有时是 5 个，有时多达 25 个。实际限制在于我是否能理解经理汇报的内容；并发推得太高，整个流程就会失控。

我不会亲自进入构建智能体的会话。经理负责回答它们的问题并解决小障碍。一个定时自动化会强制经理每 15 分钟检查所有子会话；幻灯片上写的是 10 分钟，但我现在采用 15 分钟，因为不能指望智能体自行记住这种不确定的检查。

每个构建智能体都会调用审查智能体。我们通常最多进行三轮审查和修复；如果重要问题仍未解决，就上报经理，必要时再上报给我。这样可以限制审查循环。

除了代码和测试，构建智能体还会启动独立的 QA 智能体验证工作。按我的经验，增加智能体检查成本很低，但团队要在检查和合并队列的速度之间取得平衡，避免无休止地审查每个拉取请求。

每个构建智能体还会录制功能使用和测试通过的视频。对于用户界面变更，测试通过很有用，但视频能让人看到预期交互是否真的发生，以及界面看起来是否合适。

视频准备好后，经理会通知我。在批准发布之前，我会阅读拉取请求摘要并仔细观看。演讲前我曾想在手机上批准一个变更，但屏幕太小，看不清细节，于是等到能使用电脑再看。

产品负责人需要投入时间完成这一步人工审查，不能图省事跳过。我们的流程已经迭代了数百次，如今对我们有效，未来也很可能继续变化。对于这种工作方式，我强烈倾向于使用云端智能体，而非本地开发。

团队规模扩大时，每个人通常有一个工程经理会话；我有时会同时开两个。这些会话需要知道彼此的存在并互相传递消息，才能共享信息、解决跨团队的阻塞。

另一个专门的合并队列经理负责协调大量拉取请求。它可以避免数据库迁移编号等共享资源发生冲突，并帮助安排合并顺序。它也是一个有名字的智能体会话，与 GitHub 合并队列配合使用。

我们的招聘流程一开始不安排筛选电话。我认为早期交谈容易让我因为候选人的爱好或表达方式产生偏见，而忽略我想考察的技能：操作智能体。

候选人提交一段约 45 分钟的全屏录制，展示自己如何用智能体在已有维护的应用中交付功能，通常是一个拉取请求。我们不提供详细指引，也不为这一初始提交付费。

我们将录像和文字稿交给智能体，对候选人排序。第一次我不喜欢它的结果，所以不相信排名；但有一次，我后来认为自己确实应该雇用它排第一的人。

长录像可以展示实际工作，但有些候选人不会说出自己的思路，或说话不够清晰，使他们的判断过程难以观察。人也可以逐个观看；当录像时间太长时，排序智能体可以提供帮助。

我们邀请前五名参加付费项目：为 16 小时工作支付固定费用，提供 Devin 席位，并要求他们准备一个真实的拉取请求以便合并。候选人签署保密协议并录制工作过程；我们使用 Loom，再让智能体比较录像。

上一轮我观看了全部 16 小时的录像，这很费力，但帮助我了解候选人。确定最终候选人后，我才打电话进行最后的人际交流，而不是把电话作为第一道筛选。

这一流程仍在快速变化，但基本做法一致：把协调和验证交给智能体，人仍负责确定优先级、检查产品并作出招聘决定。