Multi-Agent 开发中，如何处理「需求变更「

1️⃣ 考察意图

面试官想看你能否设计一个应对需求变更的 Agent 协作机制。刁钻点在于：需求变更不仅影响 Developer，还影响 Architect 的设计、Tester 的测试用例、DevOps 的部署计划。很多人只答"重新开发"，但说不出影响分析、任务重排、版本控制的系统性方案。

2️⃣ 标准答

需求变更处理是"影响分析→任务重排→增量开发→回归测试"的四步流程，核心是精确评估变更影响范围。

1. 影响分析（Architect Agent）

输入：变更请求（如"注册功能增加手机号登录"）
处理：Architect Agent 分析变更对现有系统的影响：数据模型：User table 需要增加 phone 字段
API：POST /api/register 需要增加 phone 参数，新增 POST /api/login/phone
前端：注册页面需要增加手机号输入框
测试：需要新增手机号相关的测试用例输出：影响分析报告（受影响的文件列表、修改类型、预计工作量）

2. 任务重排（Architect → Developer）

输入：影响分析报告
处理：更新 Task DAG——新增 Task（如"实现手机号登录 API"）、修改已有 Task（如"更新 User model"）、重新计算依赖关系
关键决策：是否需要暂停当前开发？如果变更影响正在开发的 Task，需要暂停并重新规划

3. 增量开发（Developer Agents）

输入：更新后的 Task 列表
处理：Developer 只修改受影响的部分，而非重写整个模块
版本控制：所有修改通过 Git 分支管理（如 feature/phone-login），与主分支隔离
关键原则：最小化修改范围——只改必须改的，不做"顺手重构"

4. 回归测试（Tester Agent）

输入：修改的代码 + 原有测试用例
处理：(1) 运行全量回归测试，确保变更没有破坏现有功能；(2) 新增变更相关的测试用例（如手机号格式校验、手机号重复检测）
质量门禁：全量测试通过率 100% 才能合并

5. 变更通知机制

所有受影响的 Agent 自动收到变更通知（通过 EventBus）
Agent 更新自己的上下文（如 Tester 更新测试计划、DevOps 更新部署配置）
人类收到变更摘要，确认变更合理性

3️⃣ 答题模板（30 秒电梯版）

"四步流程：影响分析（Architect分析变更对数据模型/API/测试的影响）→任务重排（更新Task DAG，新增/修改Task）→增量开发（Developer只改受影响部分，Git分支隔离）→回归测试（全量测试+新增测试用例）。变更通知通过EventBus自动推送。关键原则：最小化修改范围、版本控制隔离、全量回归测试。"

4️⃣ 高频追问 & 应对

追问 1：如何评估变更的影响范围？Agent 怎么知道哪些文件受影响？

两种方法：(1) 依赖图分析——Architect Agent 维护一个文件间依赖图（如 register.py 依赖 user_model.py），变更 user_model.py 时自动找到所有依赖文件；(2) 语义搜索——用 embedding 搜索代码库中与变更相关的代码（如搜索"register"找到所有注册相关代码）。实践中两者结合：依赖图找直接依赖，语义搜索找间接影响。

追问 2：如果需求变更频繁（如每天 3-5 次），Agent 团队怎么应对？

频繁变更说明需求不明确，Agent 团队需要：(1) 敏捷迭代——将大需求拆成小迭代（如每天一个可交付的小功能），变更只影响下一个迭代而非当前；(2) 需求缓冲——PM Agent 在 PRD 中预留 20% 的"可能变更"空间，变更时在缓冲范围内调整；(3) 变更成本量化——每次变更时 Architect 输出"变更成本估算"（如"这个变更需要 2 小时开发 + 1 小时测试"），帮助人类决策"是否值得变更"。

追问 3：变更导致的"半成品代码"怎么处理？

三层处理：(1) Git 分支隔离——所有开发在 feature 分上进行，变更不影响 main 分支的稳定代码；(2) Feature Flag——用功能开关控制新功能的启用/关闭，半成品代码可以合并到 main 但不启用；(3) 回滚机制——如果变更导致问题，Git revert 到变更前的 commit。关键：不要在 main 分支上直接修改，所有变更通过 PR 流程。

5️⃣ 避坑 · 常见错误答法

❌ "需求变更就重新开发" → ✅ "重新开发成本太高。应该做增量修改——只改受影响的部分，通过影响分析精确定位修改范围。"
❌ "Agent 可以自动处理所有变更" → ✅ "Agent 可以自动分析影响和重排任务，但变更的合理性需要人工确认——有些变更可能是用户临时起意，不值得实施。"
❌ "变更不需要回归测试" → ✅ "变更可能破坏现有功能（如修改 User model 影响所有依赖它的 API）。必须做全量回归测试，不能只测变更部分。"

6️⃣ 简历呼应

如果你有 Agent 项目：从"变更管理机制"切入，描述你实现的影响分析+任务重排流程，给出变更响应时间（如从需求到部署 2 小时）
如果你只做过敏捷开发：用"Sprint Backlog"类比——Agent 团队的 Task DAG 类似 Sprint Backlog，变更时重新排优先级
如果你是校招：用 AutoGen 实现 3-Agent 团队，测试需求变更场景下的影响分析和任务重排效果
"MetaGPT: Meta Programming for Multi-Agent Collaborative Framework" (Hong et al., 2023)
"ChatDev: Communicating Agents for Software Development" (Qian et al., 2023)

—— 本场面试完 ——