🤖 AI

Specification Portability Across LLM Development Agents: Cross-Agent Compatibility in Specification-Driven Software Migration

本文表明，由一个 AI 智能体为 Oracle 到 PostgreSQL 迁移生成的规范往往无法有效地移植到其他智能体，这揭示了实现质量中显著的智能体依赖性退化，并强调了需要通过检索增强摄取等显式策略来确保软件工程工作流中的跨智能体兼容性。

原作者： Oleg Grynets, Oleksii Ilchuk, Dariia Zatulna, Vasyl Lyashkevych

发布于 2026-08-24

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Oleg Grynets, Oleksii Ilchuk, Dariia Zatulna, Vasyl Lyashkevych

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

在现代软件创作的世界中，一种新型的员工加入了团队：大语言模型。这些是基于海量文本和代码训练而成的强大计算机程序，能够阅读任务描述并编写计算机执行该任务所需的指令。随着这些工具变得越来越普遍，开发人员正在从仅仅要求它们编写代码，转向向它们提供详细的蓝图，即“规范”（specifications）。这些规范充当操作指南，精确地告诉模型应该构建什么、应该如何表现以及必须遵守哪些规则。这种被称为“规范驱动开发”的方法，有望使软件创作变得更加可靠和结构化。然而，随着团队开始使用多种不同的模型来构建单个系统，一个关键问题出现了：如果一个模型编写了一份完美的蓝图，另一个不同的模型是否能够阅读它并构建出同样的东西？人们一直假设一份好的计划无论由谁阅读都是好的计划，但这些机器理解信息的方式在现实中要复杂得多。

EPAM Systems 的研究人员通过将软件迁移作为一个受控实验，着手测试这一假设。他们选择了一个特定的、困难的任务：将数据库代码从一个系统（Oracle）迁移到另一个系统（PostgreSQL）。这两个系统使用的语言相似，但存在不同的方言，需要对逻辑、数据类型和函数进行精确的转换。研究团队首先建立了一个基准，即让单个模型生成一份规范，然后立即使用该规范编写新代码。这一过程运行得相当顺利；在超过一千个源文件中，该系统成功地重新生成了 600 多个，其中近 400 个新脚本在目标环境中正确运行。这证明了使用中间步骤规范的方法是可行的。但真正的考验在于，当他们引入第二个不同的模型时。

研究人员创建了一个场景：一个模型（例如 Amazon Kiro）编写规范，然后将该文档交给一个完全不同的模型（如 Google Gemini 或 GitHub Copelot）来生成代码。他们想看看第二个模型是否能在不损失质量的前提下理解第一个模型的计划。结果令人震惊且出人意料。规范的大小被证明与结果无关。一个模型生成了一份长达近 1,600 行文本的庞大详细文档，而另一个则生成了一个仅约 200 行的简洁版本。然而，文档的长度并不能预测代码运行的效果。事实上，最重要的发现是，规范的来源至关重要。当 Google Gemini 接收到由 Amazon Kiro 编写的规范时，生成的代码质量崩溃了。新脚本无法运行，包含语法错误，并且看起来与预期的目标完全不同。这种失败并非偶然的失误；研究人员重复了实验，并观察到了同样的性能剧烈下降，证实了这两个模型无法就如何解释同一套指令达成一致。

然而，这种不兼容性并非普遍存在，这为这一发现增添了一层细微的差别。虽然 Gemini 在处理 Kio 的规范时表现得很挣扎，但 GitHub Copilot 处理同样的“外来”文档要好得多，有时甚至在处理这些文档时的表现与其处理自身生成的文档一样出色。这表明，问题不在于外来的计划本身不好，而在于不同的模型有不同的阅读和理解文本的方式。为了解决这个问题，团队测试了几种帮助模型弥合差距的方法。他们尝试将外来规范重写为一种接收模型可能更喜欢的格式，并尝试压缩文本以使其变短。重写显著帮助了 Gemini，使其性能恢复到了可用水平，但压缩文本并没有带来实质性的好处。最有效的策略涉及一种称为“检索增强生成”（retrieval-augmented generation）的技术。研究人员并没有将整个规范一次性喂给模型，而是给了模型一个工具，让它能够搜索文档并只提取出当前任务所需的特定部分。这种方法虽然没有在每一项指标上都胜出，但它是唯一一种能为那些表现挣扎的模型和表现成功的模型提供一致且强劲的性能平衡的方法。

该研究得出结论：在一个由不同人工智能智能体组成的团队构建软件的世界里，规范不能被视为一种中立的、通用的文档。一个智能体编写的计划并不自动成为另一个智能体的有效指令集。代码的有效性在很大程度上取决于编写计划的模型与构建软件的模型之间的特定关系。如果团队更换了一个智能体，他们不能简单地假设现有的蓝图依然有效；他们可能需要调整计划的语言，或者改变新智能体获取信息的方式。这项研究表明，多智能体软件工程的未来将需要更加关注规范是如何被构建和交付的，以确保计划中所包含的知识能够真正被负责构建它的机器所理解。

技术摘要：LLM 开发智能体间的规范可移植性

1. 问题陈述

本文探讨了新兴多智能体软件工程（SDE）工作流中一个关键的互操作性差距。随着大语言模型（LLM）从基于提示词（prompt）的助手向能够根据规范生成代码的自主智能体转型，一个新问题随之而来：由一个 LLM 智能体环境创建的规范，能否可靠地被另一个智能体消费？

目前的研究重点在于单智能体性能、上下文检索或需求澄清。然而，目前在实证层面尚不清楚由智能体 A（例如 Amazon Kiro）生成的规范在被智能体 B（例如 Google Gemini）消费以生成目标代码时，是否仍能保持其操作有效性。作者假设，规范并非“智能体中立”的产物；其有效性可能会根据规范的来源以及实现智能体所使用的摄取策略而发生显著退化。

2. 研究方法

本研究采用受控的两阶段实验设计，以 Oracle 到 PostgreSQL 的数据库迁移作为转换任务。选择该领域是因为它需要在翻译特定方言构造（过程逻辑、触发器、数据类型）的同时，保留复杂的应用语义。

第一阶段：规范驱动的迁移流水线

任务： 在 1,006 个 PL/SQL 源文件上评估了一个“规范优先”的流水线。
流程： 将源代码分解为数据库对象。一个智能体生成中间文本规范，随后该规范被用于推导 PostgreSQL 实现。
结果： 成功再生了 623 个文件，其中 380 个在 PostgreSQL 16 中成功执行。这验证了该方法的可行性，但尚未测试跨智能体转移。

第二阶段：跨智能体兼容性实验

数据集： 1,802 个 Oracle 脚本及其对应的 PostgreSQL 实现。
评估的智能体： Amazon Kiro、Google Gemini (通过 Antigravity)、GitHub Copilot (通过 Spec Kit)、Claude Code 和 Cursor。
实验条件：
1. 原生基准（Native Baseline）： 每个智能体生成其自身的规范和实现。
2. 跨智能体转移（Cross-Agent Transfer）： 将一个智能体生成的规范喂给另一个智能体（例如：Kiro 规范 $\to$ Gemini 实现）。
3. 适配策略（Adaptation Strategies）： 为了减轻潜在的退化，针对外部（foreign）规范测试了三种策略：
  - 重写（Rewriting）： 实现智能体在编码前将其偏好的格式重写外部规范。
  - 压缩（Compression）： 对外部规范进行摘要处理以缩减长度。
  - 检索增强生成（RAG）： 智能体通过检索工具访问外部规范，而非直接摄取全文。

评估指标

研究利用多维指标集来区分词法、语法、结构和操作质量：

Token F1： Token 级别的相似度。
精确匹配（Exact Match）： 输出与目标完全一致的百分比。
SQL 语法有效性： 生成的 SQL 有效性（使用 sqlglot）。
AST 精确匹配与平均相似度： 抽象语法树（AST）的结构相似度。
即时可运行性（Immediate Runnability）： 无需人工修改即可执行的脚本百分比（由于测试环境限制，此项被视为下限）。

3. 关键结果

A. 规范大小并非质量的预测因子

与“更详细的规范会产生更好代码”的假设相反，研究发现规范长度与实现质量之间不存在相关性。

Kiro 生成的规范最大（约 1,597 行）。
Gemini 生成的规范显著较短（约 193 行）。
尽管存在规模差异，但较大的 Kiro 规范并未在所有智能体或指标上普遍产生更优的代码。

B. 不对称且依赖于智能体的退化

跨智能体转移产生了高度可变的测试结果，证实了规范的可移植性具有方向性（ $C_{i \to j} \neq C_{j \to i}$ ）。

关键失败案例： 当 Gemini 直接消费由 Kiro 生成的规范时，性能崩溃。
- Token F1 从原生时的 0.73 降至 0.035。
- SQL 语法有效性从原生时的 45.54% 降至 2.33%。
- AST 平均相似度降至 0.015。
- 这种失败模式在第二次独立运行中得到了复现，排除了随机非确定性的可能。
其他组合的稳定性： 其他组合（例如 Copilot 消费 Kiro 规范）保持相对稳定或表现出混合改善，表明退化并非普遍规律，而是特定于智能体与规范的配对。

C. 适配策略的有效性

重写： 显著提升了 Gemini 在消费 Kiro 规范时的表现，这表明表示形式（而非仅仅是内容）是导致不兼容性的主要来源。该策略对 Copilot 的效果较差。
压缩： 未能提供普遍收益；简单的长度缩减并未解决不兼容问题。
检索增强摄取（RAG）： 虽然 RAG 并非在每一项指标上都占优，但它是 Gemini 和 Copilot 在处理外部规范时，唯一出现在 帕累托前沿（Pareto frontiers） 上的策略。这表明 RAG 是测试的替代方案中最稳健的通用权衡策略。

4. 核心贡献

不可移植性的实证证据： 本文提供了首个受控的实证证据，证明在一个 LLM 环境中生成的规范并不能自动有效地应用于另一个环境，挑战了“规范是智能体中立的中间产物”这一假设。
多维评估框架： 研究引入了一套全面的评估套件（Token F1、AST 相似度、可运行性），专门用于跨智能体规范转移，超越了简单的代码生成基准测试。
适配策略分析： 系统地评估了重写、压缩和 RAG，指出表示适配（重写）和选择性访问（RAG）比单纯的内容缩减更有效。
形式化模型提议： 作者提出了一个模型，其中实现质量 $Q_{code}$ 是规范来源 ( $A_g$ )、实现智能体 ( $A_i$ )、摄取策略 ( $I_s$ ) 以及上下文 ( $C$ ) 的函数，区分了知识保留与操作解释保留。

5. 意义与主张

本文谦逊地声称，其发现是基于实证且具有上下文相关性的，仅限于所评估的智能体、数据集和指标。它并不声称外部规范普遍较差，而是强调其有效性是依赖于智能体的。

主要意义：

工作流启示： 在异构多智能体 SDD 工作流中，规范不应被视为静态、可互换的产物。在智能体之间转移规范可能需要显式的适配（如重写或 RAG），以防止实现质量的退化。
设计指导： 研究结果促使开发结构化规范表示（分离知识、表示、依赖关系和粒度）以及智能体特定的规范视图。
未来方向： 研究表明，基于检索的规范访问是应对未知智能体配对的稳健策略，但仍需进一步研究依赖感知检索和结构化规范模型，以彻底解决可移植性问题。

作者总结道，“规范可移植性”是一个开放性问题，需要明确考虑信息是如何在不同的 LLM 开发环境中进行结构化、传输和解释的。