两人工程团队如何用 Cosmos 智能体处理 6 倍产品反馈并保持交付
How a two-person engineering team handled 6× more product feedback and kept shipping
两人 Cosmos Advisor 团队用 Cosmos 构建了 Feedback Triager 智能体，把每周产品反馈从约 5 条增至 30+ 条、两周 60 条的压力接了过来。
TL;DR
随着我们由两名工程师组成的 Cosmos Advisor 团队向更多客户交付更多自动化功能，每周的产品反馈迅速增长——达到每周 30 多条反馈线程。调查问题、复现 bug、寻找负责人、提交工单以及提交修复，开始占用我们大约 90% 的时间。我们的路线图几乎停滞。
我们没有立即扩充团队，而是用 Cosmos 构建了一个 Feedback Triager 专家（即 agent）。它会跟踪每一条 Slack 报告走完整个生命周期：收集证据、执行根因分析（RCA）、回答问题、将反馈路由到其他渠道、创建工单，并在修复方案明确时，将问题交给 PR Author 专家（即 agent）。人类保留产品判断和优先级排序；agent 负责围绕这些决策进行重复性的调查和执行。
结果是一个小团队，既能持续响应客户，又不会让路线图变成支持队列。
成功制造了新的瓶颈
由两名工程师组成的 Cosmos Advisor 团队负责构建开箱即用的自动化功能，以及跨代码托管平台、工单跟踪器和协作平台的 Advisor 体验。这包括针对代码审查、事件响应、反馈分诊以及大型工程项目的工作流，覆盖 GitHub、GitLab、Slack、Microsoft Teams、Jira 和其他界面。
随着我们的功能集和客户群扩大，反馈量激增。成功制造了一个新的瓶颈：我们交付得越快，花在支持已构建内容上的时间就越多。
报告会进入我们团队专用的 Slack 反馈频道。它们来自：
- 市场推广（GTM）团队转达的外部客户反馈
- 内部团队对新功能和现有功能的内部试用
在最近的两周内，我们处理了 60 条产品反馈线程——平均每周 30 条，而仅仅几周前还只有每周约 5 条：
| 类型 | 典型示例 | 线程占比 |
|---|---|---|
| 功能请求 | 客户需要新的工作流或配置选项。 | 8.33% |
| 平台支持 | 某个工作流在 GitLab、Azure DevOps、Teams 或 Jira 上表现不同——这些平台我们无法像主要技术栈那样深入地进行内部试用。 | 8.33% |
| 生产环境 bug | 已发布的工作流在客户环境中失败或表现异常。 | 6.67% |
| 发布前反馈 | 内部试用在客户遇到问题之前，先在新自动化功能中发现了问题。 | 68.34% |
| 其他产品反馈 | 内部发现的发布后 bug、正面反馈或更广泛的产品问题。 | 8.33% |
| 总计 | 100.00% |
在这 60 条线程中，50% 在报告后不久就被修复，或已有具体修复方案正在进行中。
问题并不只是 Slack 消息的数量。每份报告都可能需要阅读线程、复现行为、搜索代码和文档、检查日志、查找相关工单、决定归属、回答后续问题，有时还要编写修复。
在高峰期，我们估计这占用了团队大约 90% 的时间。我们仍能保持响应，但长期工作的执行已经开始停滞。
招聘是一种选择，但大部分工作负载是重复性的上下文重建，而不是产品判断。我们希望由 agent 承担调查和常规执行，而工程师保留优先级排序和产品决策。
我们的反馈循环如何运作——从报告到解决
我们团队反馈频道中的每条新根消息都会启动一个长期运行的 Feedback Triager 会话。该会话在其生命周期内拥有整个线程，因此它可以纳入回复、更正、编辑和新证据，而无需在每一轮都重建对话。
Feedback Triager 将每份报告通过受理和调查引导至正确的处理结果，然后将明确的修复交给软件工厂中其他地方使用的同一批 PR Author、审查和验证专家。
1. 受理
Triager 阅读报告及周边上下文，予以确认，并确定需要哪些信息。当缺少关键事实时，它最多提出一个有针对性的澄清问题。
2. 调查
对于缺陷、回归和意外行为，它会在代码、配置、测试、文档、日志、指标、部署状态、现有工单和相关 Slack 线程中执行 RCA。运行时证据确立发生了什么；静态证据解释为什么。Triager 将结论标记为已确认、暂定或仍缺少证据，而不是将看似合理的猜测当作事实呈现。
3. 行动
下一步取决于证据：
| 发现 | 行动 |
|---|---|
| 一个问题、一次性事项、预期行为或不支持的请求 | 在 Slack 中回答或解释决定；无需工单。 |
| 该问题属于另一个团队 | 将其连同已附上的 RCA 和证据路由给正确的团队。 |
| 已存在匹配的问题 | 链接或丰富现有工单，而不是创建重复项。 |
| RCA 和局部修复明确 | 启动 PR Author 立即实施修复，然后将其送交审查和验证。 |
| 问题开放或 RCA 仍不明确 | 创建一个 Linear 待办事项，附上目前已收集的证据；将其与路线图其余部分一起排定优先级并调查。 |
明确、范围清晰的修复不应等待另一个规划周期；模糊的问题和功能请求应放入 Linear 以进行优先级排序和更深入的工作。
Feedback Triager 正在运行，在建议行动之前调查一份报告。
如何让反馈分诊有效
- 上下文：Triager 可以访问工程师使用的仓库、文档、工单历史、Slack 线程、日志和指标。没有这些输入，智能体只能总结报告；有了它们，智能体就能调查报告。
- 自定义：每个团队都可以自定义分类、路由、工单、证据和沟通规则，使 Triager 反映该团队的实际运作方式。
- 证据纪律：Triager 独立验证报告者的诊断，并在证据指向不同的原因、负责人或严重程度时如实说明。
- 人在回路中：人的投入很少，且集中在最高杠杆的任务上：利用 RCA 和支持证据做出决策。一旦人类选择了路径，智能体就可以处理常规执行，例如提交工单或启动 PR Author。
- 记忆：对分类、路由、去重或响应行为的更正会成为明确的频道特定规则，使未来的分诊更加一致。
反馈分诊需要一个软件工厂
Feedback Triager 可以比手动队列更快地产生可执行的工作。如果下游工程系统无法吸收这些工作，代码审查和验证就会成为新的瓶颈。
因此，我们的反馈闭环连接了多位专门的 Cosmos 专家：
- 反馈分诊员调查报告并选择下一步行动。
- PR 作者实施清晰、已获批准的修复。
- 代码审查专家检查变更并推动从 PR 到合并的循环直至解决。
- 验证者端到端地检验行为。
- 人类做出产品、优先级和生产风险决策。
目标不是优化某一步，而是缩短从产品反馈到验证结果的完整闭环。同一软件工厂还支持大型工程项目和事件响应。
最终状态：反馈规模扩大，团队规模不变
我们对当前的运营模式很满意。我们两人的团队现在大约30% 的时间花在反馈上，低于此前估计的90%，我们的主要精力重新回到了长期路线图上。
我们不再需要仅仅为了跟上反馈而扩充团队。随着我们创建更多功能，反馈分诊员扩展了我们调查和分流由此产生的反馈的能力，而 PR 作者、代码审查和验证专家则承接下游的修复工作。
其他早期经验：
- 最好的分诊结果往往是不开单。问题、已知限制、重复项和一次性故障不应让待办事项膨胀。
- 模糊性属于规划阶段，而非推测性代码。开放式问题需要优先级排序和更深入的调查。
如何采用这一工作流
请 Cosmos Advisor 为你的团队设置反馈分诊员。借助标准的协作与工单技术栈——Slack 或 Microsoft Teams 搭配 Jira、Linear、GitHub Issues 或 GitLab Issues——Advisor 可以自主配置专家、集成、触发器和路由工作流。
从一个团队和一个反馈渠道开始。Advisor 将连接代码库、跟踪器和证据来源；配置回答、路由、去重和归档规则；选择人工审批的级别；并连接下游的审查和验证。先测量基线，然后随着工作流被证明可靠而逐步扩大权限。
目标不是创建更多工单或 PR，而是让每一条产品反馈线程都能以更少重复性人工工作达到正确的结果——这样一个小团队就能支撑不断增长的产品，并继续构建下一步。
构建你自己的反馈闭环
Cosmos 为工程团队提供共享上下文、运行时控制、集成和人工检查点，以分诊反馈、调查根本原因并将其路由到正确的结果。
来源：Augment Code Blog · augmentcode.com