Nitric团队放弃单一AI代理，改用专用代理处理生产事故

我们是一个五人工程师团队，过去每周因生产事故被叫醒三到四次。大多数是噪音而非严重故障，但在凌晨两点，过度谨慎总比让真正的问题溜过去要好。

此后，我们通过迭代分诊流程并跟进调查直到修复，既减少了不必要的夜间打扰，也减少了反复出现的问题。专门的 AI agent 帮助我们调查事故、组织后续工作并准备变更，工程师则在此过程中审查和纠正工作。

让我们惊讶的是，我们逐渐对这套流程变得多么放心。工程师可以检查评估结果、质疑其假设，并利用这些修正来改进后续事故的处理方式。随着后续修复解决了反复出现的问题，我们对何时该叫醒值班工程师更有信心了。

这段经历让我们质疑交给 agent 的工作形态。一个能力强的编码 agent 有可能调查事故、创建工单并准备修复，那为什么要拆分这些职责？

“当 agent 的工作需要纠正时，你能识别出涉及的责任，并做出可以独立评估的改动吗？”

对我们来说，关键在于改进工作流中的某一部分，并判断改动是否有帮助。当 agent 的工作需要纠正时，你能识别出涉及的责任，并做出可以独立评估的改动吗？

人与 agent 的共享工作空间

我们正在构建 Sugabots，这是一个开源、自托管的工作空间，团队可以在同一任务上与多个 agent 协作。工程师可以提问、提供证据、审查发现并引入另一个 agent，这些交流对其他参与者可见。

我们将这些工作组织到称为 pod 的共享环境中，通过 MCP 连接外部系统。每个 agent 可以有自己的模型和指令，而 pod 的连接和工具策略定义了其 agent 共享的访问权限。团队可以为特定职责配置 agent，并在工程师审查工作时完善其指令。我们的事故工作流帮助我们探索了哪些职责适合这种分离。

我们如何在 Sugabots 中运行事故分诊

我们的事故工作流依赖于每位工程师或 agent 能够从调查期间记录的证据、决策和修正中继续推进。

我们的 Sentry 分诊 agent 调查新的、回归的或升级中的问题，并决定是通知值班工程师、请求工作时间内审查、将小修复直接交给实现 agent，还是将问题留在 Sentry 中监控。它在 Linear 中记录后续工作，由 backlog agent 帮助组织工单，实现 agent 则可以准备 GitHub pull request 供审查。

我们的事故工作流：agent 处理不同的职责，工程师参与共享调查。工程师可以承担图中所示的任何贡献。

工程师全程参与，审查发现、质疑紧急程度评估、纠正假设，并决定是否发布提议的变更。随着工作在人和 agent 之间流转，调查记录始终可用。

保障措施支撑着这种日益增长的信心。指令要求，当问题可能属于生产故障且紧急程度不确定时，应紧急升级。被归类为噪音的问题会被归档，直到升级；Sentry 保留了一条直接向 incident.io 发送尖峰告警的备用路径。

后续跟进与初始评估同样重要。以前，值班工程师可能会调查告警，判断可以等到工作时间，然后回去做其他工作。将底层问题记录在 backlog 中并确定优先级，让团队有机会在下一位值班工程师遇到同样的告警之前解决它。

让 backlog agent 在 Linear 中记录后续工作，为团队提供了一种一致的方式来优先处理导致中断的反复出现的问题的修复。

围绕决策进行专业化

我们为每个 agent 配置特定职责，选择适合该工作的模型和指令，并定义什么是有用的结果。

我们为 Sentry 分诊选择了 Opus 5.5，其指令涵盖证据收集、分类、升级、交接以及从工具故障中恢复。这段简短的摘录展示了我们要求它做出的决策：

检查完整的 Sentry 问题，包括客户影响、受影响用户、发布版本和事件趋势，然后检查现有工单或事故。 选择一种结果：

• 紧急：正在对客户造成损害，需要立即关注；通过 incident.io 通知值班工程师。
• 工作时间内审查：需要工程判断的缺陷，可以等待；以低紧急程度通知值班工程师。
• 自动修复：在认证、计费和迁移等受限区域之外的小型、非紧急代码变更；向实现 agent 简要说明以准备 PR。
• 不采取行动：预期内或短暂的噪音；归档直到升级，以便尖峰出现时将其重新带回。 说明决策背后的证据和不确定性。实现简报必须独立成立，并包含相关发现和链接。

backlog 管理器的指令反映了组织后续工作所涉及的决策：检查重复项、查找当前 Linear 周期，并区分可操作的工作与需要工程师澄清范围或做出设计决策的问题。这些规则提供了默认值，同时保留了团队关于优先级、分配和调度的明确选择，并且我们可以独立于评估事故紧急程度的标准来完善它们。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）