Can AI Agents Generate Microservices? How Far are We?

该研究评估了 AI 代理生成微服务的能力，发现尽管其生成的代码质量较高且能较好遵守 API 契约，但在功能正确性上仍存在不一致性，表明完全自主的微服务生成尚未实现。

要点

这篇论文就像是在做一场**“超级实习生”的入职大考**。

想象一下，你是一家大型科技公司的架构师（老板），你手下有一群由人工智能（AI）驱动的“超级实习生”。你的任务是：让这些实习生去写微服务（Microservices）。

🏗️ 什么是“微服务”？（先打个比方）

如果把一个大型软件系统比作一家超级大餐厅：

• 传统单体应用就像是一个全能厨师，他一个人负责切菜、炒菜、摆盘、甚至收银。一旦他生病或忙不过来，整个餐厅就瘫痪了。
• 微服务架构则像是把餐厅拆分成多个独立的小档口：有的专门负责“炒菜”，有的专门负责“收银”，有的专门负责“送外卖”。每个档口（微服务）都是独立的，它们之间通过**严格的菜单和订单规则（API 合同）**互相沟通。

这篇论文的核心问题就是： 现在的 AI 实习生，能不能独立把这些“小档口”建好，并且让它们能完美配合，不出乱子？

---

🧪 实验设计：两种“入职场景”

研究者找了 3 个不同的 AI 实习生（Claude Code, Codex, Code Qwen），让他们在两种不同的场景下工作：

场景一：【老员工带教模式】（增量生成）

• 情况： 餐厅里已经有很多档口在运转了。现在要加一个新的“甜品档口”。
• 任务： AI 需要看着现有的厨房（代码库），了解大家怎么配合，然后写出新的甜品档口，确保它能和现有的“收银台”、“送餐员”无缝对接。
• 提示方式：
  • 极简提示（P1）： 只给个名字和任务书：“去写个甜品档口，看着点规矩。”
  • 详细提示（P2）： 给名字、任务书，还有一份**“老员工写的详细说明书”**（总结），告诉它以前是怎么做的。

场景二：【从零创业模式】（清洁状态生成）

• 情况： 这是一个全新的商场，没有任何档口。
• 任务： AI 只能看到一张**“需求清单”**（比如：我们要卖奶茶、要支持扫码支付），然后完全从零开始，自己设计并搭建整个“奶茶档口”，还要确保它以后能跟别的档口配合。
• 挑战： 没有现成的代码可以参考，全靠 AI 自己猜和创造。

---

📊 考试结果：AI 表现如何？

研究者让 AI 们写了 144 个微服务，然后进行了严格的“压力测试”（运行单元测试和集成测试）。

1. 谁更聪明？（功能正确性）

• 在“老员工带教”场景下：

  • 意外发现： 给 AI 看越详细的说明书（P2），它反而越容易犯错！
  • 原因： 就像实习生如果太依赖“老员工写的笔记”，可能会忽略现场的实际变化。相反，只给个简单任务（P1），让 AI 自己去探索现有的代码库，它反而能更好地适应环境，通过率在 50% - 76% 之间。
  • 表现最好的： Codex（GPT-5 的早期版本）和 Claude Code。

• 在“从零创业”场景下：

  • 大反转： 这次 AI 们表现惊人地好！通过率高达 81% - 98%。
  • 原因： 因为没有现成的代码“干扰”，AI 可以完全按照需求清单自由发挥。只要它生成的“奶茶档口”能跟“收银台”对上号（API 合同），就算成功。哪怕它内部结构跟人类写的有点不一样，只要功能对，就能通过。
  • 注意： 这里有个陷阱，AI 生成的代码结构可能跟人类习惯的不一样（比如包名变了），导致人类写的旧测试用例跑不通，但实际功能是对的。

2. 代码质量如何？

• 更简洁： AI 写的代码通常比人类写的更短、更简单（复杂度更低）。
• 比喻： 人类厨师可能会写 100 行代码来处理一个切菜动作，AI 可能只用 30 行就搞定了。虽然短，但有时候可能少了点“防御性”（比如没考虑到切到手怎么办），不过在这个实验中，它确实能跑通。

3. 谁更省钱、更快？（效率）

• 速度：
  • Claude Code 和 Code Qwen 是“快手”，平均 7-8 分钟 搞定一个档口。
  • Codex 是个“慢性子”，平均要 16 分钟，甚至有一次花了 104 分钟（超时了！），就像有个实习生发呆了一个半小时。
• 成本：
  • Code Qwen 最便宜，写一个档口只要 3 美元。
  • Claude Code 最贵，要 13 美元。
  • Codex 居中，但因为它写得啰嗦（输出 Token 多），成本也不低。
• 结论： 贵的不一定快，快的不一定便宜，而且代码写得长（啰嗦）并不代表质量更好。

---

💡 核心结论：我们离“全自动”还有多远？

1. AI 能干活，但还没法“完全放手”：
   AI 确实能写出能运行的微服务，代码质量也不错。但是，它经常犯一些“结构性错误”（比如包名不对、配置文件漏了）。就像实习生把“甜品档口”建好了，但把“收银台”的接口搞错了，导致没法结账。
   所以，人类老板（架构师）必须还要在旁边盯着，做最后的检查和修正。

2. 场景决定成败：

   • 如果是在旧系统里加新功能，别给太多说明书，让 AI 自己去“读”代码，效果反而更好。
   • 如果是全新项目，AI 的表现非常惊艳，几乎能独立完成任务。

3. 数据“污染”是个问题：
   AI 在那些著名的开源项目（比如 GitHub 上很火的）上表现特别好，但在私有的、没公开过的学生项目上表现就差很多。这说明 AI 可能只是“背下了”那些热门项目的代码，而不是真的学会了“怎么思考”。

🚀 总结

这篇论文告诉我们：AI 已经是软件开发的得力助手了，但它还不是那个能独当一面的“首席架构师”。

• 它能做： 快速生成代码、简化逻辑、在明确需求下从零搭建。
• 它不能做： 完全理解复杂的上下文、自动处理所有边界情况、不需要人类检查。

未来的方向： 我们需要更聪明的“人类-AI 协作模式”。人类负责定规矩、做最终审核，AI 负责快速执行和生成草稿。就像人类是总指挥，AI 是那个反应极快但偶尔会走神的超级副手。

技术摘要

论文技术总结：AI 智能体能否生成微服务？我们走得多远？

论文标题：Can AI Agents Generate Microservices? How Far are We?
作者：Bassam Adnan, Matteo Esposito, Davide Taibi, Karthik Vaidhyanathan
机构：印度 IIIT 海德拉巴、芬兰奥卢大学、丹麦南丹麦大学

---

1. 研究背景与问题 (Problem)

随着大型语言模型（LLM）在代码生成领域的进步，研究焦点正从单一的 LLM 转向具备工具使用、记忆和迭代优化能力的AI 智能体（AI Agents）。尽管已有研究探索了从需求到架构再到代码的生成，但针对**微服务（Microservices）**这一特定架构风格的端到端生成研究仍然匮乏。

微服务架构具有高度复杂性，要求每个服务不仅具备局部逻辑正确性，还需严格遵循跨服务的 API 契约和交互模式。现有的自动化工具在处理这种细粒度服务间的集成和依赖时面临巨大挑战。

核心研究问题：

1. 功能正确性与代码质量：AI 智能体在不同上下文场景下（增量生成 vs. 从零开始生成）生成微服务的能力如何？
2. 效率对比：不同 AI 智能体在生成微服务时的时间、成本和 Token 消耗表现如何？

---

2. 研究方法 (Methodology)

本研究采用实证方法，设计了严谨的实验流程来评估 AI 智能体的能力。

2.1 实验设计

• 数据集：选取了 4 个项目（2 个开源项目：PiggyMetrics, Train-Ticket；2 个私有学生项目：TeamSync, Project Management），每个项目选取 3 个关键微服务进行移除和重新生成，共生成 144 个微服务实例。
• AI 智能体：选取了 3 个主流编码智能体：
  • Claude Code (基于 Claude Sonnet 4)
  • Codex (基于 GPT-5)
  • Code Qwen (基于 Qwen3-Coder)
• 生成场景 (Scenarios)：
  1. 增量生成 (Incremental Generation)：移除目标微服务代码，但保留现有系统架构、依赖和 API 契约。智能体需在现有上下文中工作。
  2. 从零开始生成 (Clean State Generation)：完全移除目标微服务及其相关配置和调用痕迹，仅保留需求文档。智能体需推断架构和实现细节。
• 提示策略 (Prompting Strategies)：
  • P1 (最小上下文)：仅提供微服务名称和需求路径，让智能体自行探索代码库。
  • P2 (详细上下文)：在 P1 基础上，增加由智能体生成的“实现摘要”（包含功能范围、API 职责、集成点等）。

2.2 评估指标

• 功能正确性：
  • 增量场景：运行原有的单元测试，计算通过率。
  • 从零场景：运行集成测试（依赖该服务的其他服务测试），因为智能体生成的代码结构可能与原单元测试预期不同，但功能可能正确。
• 代码质量：使用 SonarQube 测量代码行数 (SLOC)、圈复杂度 (Cyclomatic Complexity) 和认知复杂度 (Cognitive Complexity)。
• 效率：生成时间、Token 消耗量、货币成本。

---

3. 关键贡献 (Key Contributions)

1. 首个实证研究：首次系统性地评估了 AI 智能体在不同上下文场景下生成微服务的能力，填补了从需求到微服务代码生成的研究空白。
2. 场景化对比分析：揭示了“增量生成”与“从零生成”两种场景下智能体表现的显著差异，挑战了“提供更多上下文（摘要）总是更好”的直觉。
3. 效率与成本基准：提供了不同商业和开源智能体在微服务生成任务中的详细效率对比（时间、成本、Token 使用），为工程实践选型提供数据支持。
4. 数据污染警示：通过对比开源项目与私有项目，证实了 LLM 在流行开源库上的表现可能源于训练数据记忆（Data Contamination），而非真正的推理能力。

---

4. 主要结果 (Results)

4.1 功能正确性 (RQ1)

• 增量生成 (Incremental)：
  • 反直觉发现：最小提示 (P1) 优于详细提示 (P2)。
    • Codex: P1 (75.9%) > P2 (50.3%)
    • Claude Code: P1 (73.7%) > P2 (63.2%)
  • 原因：详细摘要可能导致智能体“锚定”在摘要的高层描述上，而忽略了代码库中具体的实现细节（如特定的 MongoDB 转换器配置），导致单元测试失败。
  • 表现：平均单元测试通过率在 50% - 76% 之间。Codex 表现最佳。
• 从零生成 (Clean State)：
  • 表现优异：所有智能体的集成测试通过率显著提高，平均在 81% - 98% 之间。
  • 原因：集成测试只验证 API 契约和交互，对内部代码结构（包名、类名）的偏差容忍度更高。
  • 提示影响：Code Qwen 在 P2（有摘要）下表现显著提升（从 33% 提升至 97%），说明在缺乏上下文时，显式指导对开源模型至关重要。
• 统计显著性：从零生成场景的正确性显著高于增量生成场景 ($p < 0.001$)。

4.2 代码质量

• 复杂度更低：生成的微服务代码在圈复杂度和认知复杂度上普遍低于人类编写的基线代码（降低约 15-40%）。
• 代码更简洁：生成的代码行数通常少于或等于基线，但保持了功能正确性。

4.3 效率 (RQ2)

• 时间：
  • Claude Code 和 Code Qwen 平均耗时约 7-8 分钟。
  • Codex 平均耗时 16.6 分钟，且存在极端异常值（最长 104 分钟），存在超时风险。
• 成本：
  • Code Qwen 最便宜：约 $2.98/服务。
  • Codex 中等：约 $5.92/服务。
  • Claude Code 最贵：约 $13.28/服务。
• Token 消耗：
  • Claude Code 输出极其简洁（平均 2.1K tokens），而 Codex 输出非常冗长（平均 37.5K tokens）。
  • 关键发现：输出的冗长程度并不与功能正确性正相关。Claude Code 用最少的 Token 实现了最高的正确率。

---

5. 意义与结论 (Significance & Conclusion)

5.1 结论

• 能力边界：AI 智能体可以生成功能正确且可维护的微服务代码，特别是在从零开始（Clean State）的场景下，集成测试通过率极高。
• 局限性：在增量生成（集成到现有系统）场景下，表现不稳定（约 65% 正确率），且过度依赖详细摘要反而可能降低性能。
• 人类角色：完全自主的微服务生成尚未实现。人类监督对于确保 API 契约一致性、处理架构权衡以及审查生成结果仍然是必要的。

5.2 实践建议

1. 提示策略需因地制宜：不要盲目使用详细摘要。在增量开发中，让智能体自行探索代码库（P1）往往效果更好；在从零开发中，提供结构化摘要（P2）对开源模型至关重要。
2. 选型建议：
   • 追求速度和成本：选择 Code Qwen。
   • 追求稳定性和简洁性：选择 Claude Code（尽管成本较高，但 Token 效率高）。
   • 谨慎使用 Codex：存在严重的超时风险和成本波动。
3. 风险管理：必须为生成过程设置超时机制（如 15-20 分钟），并建立人工审查流程，特别是针对 API 契约的合规性检查。
4. 基准测试警示：公开基准测试（基于流行开源库）可能高估模型在私有代码库上的表现，实际部署前应进行小规模试点。

5.3 未来方向

• 建立专门的微服务架构基准测试（包含明确的 API 契约和集成测试）。
• 研究人机协作框架，确定人类介入的最佳时机（如中间产物审查）。
• 开发针对架构特定任务（如依赖分析、契约验证）的专用智能体工具。

---

总结：该论文表明，AI 智能体在微服务生成领域已取得显著进展，能够生成高质量代码，但其表现高度依赖于上下文场景和提示策略。目前阶段，它们更适合作为辅助开发工具，而非完全自主的架构师。