By 黄金金枪鱼 
> 面试题：一个 3 人团队要用 Vibe Coding 构建客服工单分流 Agent，你会如何定义 MVP、让 AI 分阶段生成模块并控制上线风险？
这是 3 道 Vibe Coding 面试题里最难的一题——前两题问的是「单点能力」（提示词工程 / CI/CD 门禁），这一题把视角拉到「真实业务落地」。面试官想看的不是「你会写客服 Agent」，而是「你怎么在一个 3 人小团队里把 Agent 推到生产环境，同时不把公司搞炸」。
下面从五个维度展开——MVP 边界、模块拆分、评测体系、上线门禁、风险兜底。
## 一、先把 MVP 边界划清：让 Agent「只做 3 件事」
最容易踩的坑是把客服 Agent 做得「无所不能」——既分类又承诺赔付又改账户又续费提醒。3 人团队这么做，Agent 必然脆弱：每一处越权都可能引发客诉。
合理的 MVP 边界只包含三项核心能力：
- **工单分类**：根据用户描述判断「账单类」「技术类」「账号类」「投诉类」中的哪一类
- **优先级判断**：根据情绪词、关键词、用户付费等级把工单标为 P0/P1/P2/P3
- **人工转派**：把低置信度或高风险工单按规则分给对应客服
**明确「禁止项」**：Agent 不能直接承诺赔付、不能修改用户账户、不能取消订单、不能调高权限、不能调用退款接口。
## 二、分阶段生成模块：6 个 Stage，每个有「接口契约 + 离线评测集」
3 人团队在 Vibe Coding 阶段最容易犯的错是「一口气生成全栈」。LLM 超过一定代码量后会出现隐性回归。所以团队必须**按模块分批生成**，每批都有验证。
下面是 6 个 Stage 拆分：
每个 Stage 之间必须有**接口契约**（OpenAPI / JSON Schema）和**离线评测集**（golden dataset）。LLM 生成完一个 Stage，立刻用评测集跑通——通过率低于阈值就回滚重做，**不要在评测不通过时硬往下走**。
## 三、构建四套离线评测集，覆盖三类核心指标
上线前必须量化「Agent 究竟做得怎么样」。建议构建四套评测集：
- **分类准确率集**：覆盖各业务线历史工单的典型与边界样本
- **转人工率集**：判断低置信度工单「应转人工」的正确性
- **响应时延集**：覆盖长文本、多轮、知识库命中 / 未命中
- **误分流率集**：评估「账单类错分投诉类」「P0 错标 P3」等严重错误
四套评测的产物是上线门禁的硬指标——低于阈值则禁止上线。
## 四、上线门禁四道关：灰度 + 观察 + 告警 + 回滚
3 人团队做客服 Agent 的最大风险不是「模型能力不够」，而是「上线一刀切、出了问题再回滚」——这会让 70% 的客诉在第一天就涌进来。正确的门禁设计如下：
上线四道关：
1. **灰度发布**：1% → 10% → 50% → 100%，每阶段观察 ≥ 1 周
2. **实时观察**：监控分类置信度分布、转人工率、响应时延
3. **自动告警**：误分流率超阈值、置信度骤降、API 失败率攀升时触发
4. **一键回滚**：保留稳定版本镜像 + DB schema 版本，5 分钟内可回滚
## 五、关键点：3 人小团队的工程纪律
把以上 5 段压成「3 人小团队能落地的工程纪律」：
- **不要让 Agent 触碰金钱 / 权限 / 数据删除**——这是 3 人团队最稀缺的资源，碰了赔不起
- **每个 Stage 都有接口契约 + 离线评测集**——LLM 输出的代码不能裸进生产，必须有回归
- **上线必须分阶段灰度**——1% → 10% → 50% → 100%，每阶段观察 ≥ 1 周
- **客服的人工兜底永远在线**——任何「低置信度 + 高风险」的工单必须能秒级转人工
- **审计日志要全**：谁触发的、调用了哪个工具、返回了什么、谁最终处理的——全部留痕
- **回滚演练定期跑**——避免「出问题才发现脚本跑不起来」
## 六、面试答题模板（生产工程师视角）
建议用 STAR-L 结构答这道题：
- **S（场景）**：复述问题边界——3 人团队、Vibe Coding、客服工单分流、Agent
- **T（目标）**：定义 MVP 三项核心能力 + 明确禁止项
- **A（行动）**：6 个 Stage 分批生成 + 4 套评测集 + 灰度发布 + 一键回滚
- **R（结果）**：上线 4 道关通过后逐步放量，关键指标全部达成
- **L（学习）**：3 人小团队要把「工程纪律」当核心能力
面试官考察的不是「你能不能写客服 Agent」，而是「你能不能在 3 人约束下用工程纪律把 AI 系统推上生产、并在出问题时收得住」。
## 七、行业影响：从「单点工具」到「团队级 AI 工程」
这题反映的趋势是——AI 求职已从「会不会调 prompt / 调 API」演变为「能不能用工程纪律把 AI 推上生产」。客服、合同审查、内容审核等场景都在重复这条规律：单点能力不再稀缺，**「在小团队里把 AI 做成可维护、可回滚、可审计的生产系统」才是真正的护城河**。
## 结语
把 Agent 推上生产这件事，3 人小团队最稀缺的从来不是「写 Agent 的能力」，而是「限制 Agent 边界的纪律」——MVP 划清、模块分阶段、四套评测、灰度四道关、人工兜底 + 一键回滚，五条合一。
---
> **本文由 AI 生成**。内容基于公开资料整理，可能存在事实偏差，引用链接请以原始来源为准。
## 参考资料
**官方文档**
- Anthropic Claude Sonnet 介绍 [200] - 2026
- Anthropic Agent Loop 文档 [200] - 持续更新
- AWS Connect 客服联络中心 [200] - 持续更新
**开源项目**
- langchain-ai/langgraph 元数据 [200] - 多 Agent 编排框架
- all-hands-ai/openhands 元数据 [200] - AI 编程 Agent 开源实现
- crewAIInc/crewAI 元数据 [200] - 多 Agent 协作框架
- langflow-ai/langflow 元数据 [200] - 可视化 Agent 构建
**行业报道**
- HN Algolia 搜索: AI customer support routing agent [200] - 持续聚合
**社区讨论**
- arXiv: Toolformer 论文 2406.01574 [200] - 工具调用范式
**对比基准**
- fixie-ai/ultravox 元数据 [200] - 实时语音客服 Agent 框架
- huggingface/smol-course 元数据 [200] - 小模型微调课程（含客服分类样例）