Specification Portability Across LLM Development Agents：specification 不是 agent 中立的

关联论文：2608.21208
作者：spark
更新：2026-08-25

一句话结论

LLM 开发 agent 之间不能直接互换 specification：当 spec 从 agent A 传给 agent B，实现质量会出现 agent-dependent 显著退化；spec 大小不预测质量，RAG 检索是唯一跨 agent 共赢策略。

这句话听着技术，但本质是一次"继 SDD 之后必须补上的接口合同研究"——一个工业域口口声声说"spec 是 agent 中立的接口"，结果在受控实验中破裂。

解决什么真问题

Spec-Driven Development (SDD) 在 2024-2026 年迅速成为 LLM 编码 agent 的主流范式。Kiro、Cursor、Claude Code、GitHub Copilot 等 agent 普遍以"先写规范、再写实现"为卖点。但有一个隐含假设从来没被严格检验过：

同一份 specification，可以"跨 agent 移植"吗？

也就是说：在 Kiro 里写好的 spec，能不能直接喂给 Gemini / Copilot / Cursor 让它们照着实现？或者更进一步，多 agent 协作时，前一个 agent 的 spec 是不是天然对下一个 agent 友好？

直觉上大家可能会想："规范应该是 agent 中立的，规范是抽象的、实现才是 agent 相关的。"——但本文用 Oracle→PostgreSQL 迁移这个受控任务 + 1,802 个脚本的数据集告诉你：不是。

为什么会这样？可能的原因有三种，论文摘要未明确区分：

Spec 隐含风格：Kiro 的 spec 可能假设了特定的表结构命名、SQL 方言贴近度、文档格式偏好。
Tokenization 差异：不同 LLM 的 tokenizer 对 spec 中的 SQL 关键字、标识符切分方式不同，导致"看起来等价"的输入实际进模型后分布变了。
训练数据偏置：不同 agent 在 SDD 类数据上的训练分布不同，对某种 spec 风格的兼容性天然有差异。

这三种原因对应的工程对策不同。论文没有深入到原因层，但给出了结果层的明确警示。

核心方法

论文分两阶段实验，方法论上是受控软件工程实验，不是新算法：

阶段一：specification-first 迁移 pipeline 的单 agent 验证

数据：1,006 个 PL/SQL 文件
流程：先把 PL/SQL 解析成结构化 spec → LLM agent 据 spec 重写为 PostgreSQL
验证指标：脚本能否在 PostgreSQL 16 中成功执行
结果：623/1,006 成功重新生成；380/623 生成脚本在 PostgreSQL 16 中实际可执行

这一步的目的不是改进 pipeline，而是建立 baseline 可行性：spec-first 迁移 pipeline 在单 agent 场景下确实工作。

阶段二：跨 agent specification portability 实验

数据：1,802 个 Oracle 脚本 + 对应 PostgreSQL 实现
受测 agent：Amazon Kiro、Google Gemini、GitHub Copilot（初期单 agent 评估还含 Claude Code、Cursor）
关键变量：spec 的来源 agent（native = 自己写的；foreign = 别 agent 写的）
评估指标 6 个：
Token F1
exact match
SQL syntax validity
AST exact match
AST mean similarity
immediate runnability（脚本能否直接执行）

⚠️ 论文摘要级：评估指标"原文未明确"每项的具体权重，但从命名看是分层的——Token F1 和 exact match 是表层文本对齐，AST 两项是结构对齐，runnability 是端到端语义对齐。

这个指标矩阵的设计意图很清楚：避免单一指标偏误。例：Token F1 高可能只是表面抄得近，但 AST 不对齐说明真的"理解"偏离；runnability 高说明虽然实现方式不同但目标等价。所以读论文时必须看完整 6 维，不能只看某一项就下结论。

关键反直觉发现

Gemini 直接消费 Kiro-origin specification： - Token F1 = 0.035 - SQL syntax validity = 2.33% - AST mean similarity = 0.015

这三个数字低到令人发指——意味着 Gemini 拿到 Kiro 写的 spec 后，生成的 PostgreSQL 和 Oracle 原始实现的 token / 语法 / 树形结构都几乎不沾边。

进一步： - 重写 spec 能实质性改善 Gemini - 压缩 spec 没有普适收益 - RAG 检索增强摄入是唯一在 Gemini 和 Copilot 双方 per-agent Pareto frontier 上同时出现的策略

Pareto frontier 在这里是关键词：意思是"在多个策略维度上同时占据最优"。RAG 是少数几个能跨 agent 同时赢的策略——意味着它是通用增强而不是 agent-specific hack。

关键实验与数据

实验阶段	数据规模	关键数字
Spec-first pipeline	1,006 PL/SQL	623 重新生成 / 380 可执行
跨 agent 实验	1,802 Oracle-PostgreSQL 配对	6 维指标矩阵
Gemini × Kiro-spec	单案例	Token F1 0.035 / syntax 2.33% / AST 0.015
Pareto frontier 策略	两 agent	仅 RAG 检索共同出现

⚠️ 多个基线对比的具体数字（如 native vs foreign 各 agent 全量数据）需 fetch PDF §X 主表。原文摘要未给出每 agent 在 native/foreign 下的完整 6 维矩阵。

亮点

直面一个被忽视的隐含假设：specification portability 在 SDD 流行语下几乎无人质疑，本文是难得的"打地基"工作。SDD 领域过去两年发了几十篇论文，但几乎都在"哪个 agent 在 native spec 上更好"的局部最优里打转，没人问"spec 能不能跨 agent"。
受控任务设计：Oracle→PostgreSQL 迁移是经典的、语义明确的转换任务，避免了"我让 LLM 写代码"那种开放式任务的方法论噪声。原文未明确是不是唯一任务域，但从 1,802 脚本的样本量看足够支撑结论。
6 维指标矩阵：从 token 到 AST 到 runnability，层次分明，不会让单一指标掩盖问题。这是给整个代码生成评估领域的方法学贡献。
跨 agent Pareto frontier 分析：找出"在多个 agent 上同时最优"的策略——RAG。这是给多 agent 系统工程师的可操作结论。
找出重写 vs 压缩的差异：很多 SDD 实践者以为"压缩 = 简化 = 更好"，本文证伪了。这是工程上很容易踩的坑，论文给出了明确的否定证据。
样本量足够：1,802 个脚本不是 toy 实验，避免了"挑了 5 个例子就下结论"的常见病。

局限

单一任务域：Oracle→PostgreSQL 是结构化、强规则的迁移。能不能泛化到"自然语言需求 → 实现"这类 SDD 主要应用场景，原文未明确。这是一个潜在的外部效度问题。
Agent 版本快照：受测的 Kiro / Gemini / Copilot 是 2026 年 8 月某个版本。结论的时效性取决于 agent 演进的剧烈程度。
没有训练/微调视角：所有实验都是 zero-shot + prompt + RAG。没测过 fine-tune 一个 spec 适配层是否能让 portability 提升。这是工业落地时的一个重要问题。
重写和压缩的代价未量化：重写要花多少 token / 多少钱？是否在生产可承受范围？论文摘要未提。
RAG 检索的 corpus 构造未详细说明：用的是 Kiro 自己写的 spec 库？还是公开的 PostgreSQL 文档？这对可复现性至关重要。
测试用例单一行业：1,802 个脚本可能集中在金融、电信等 PL/SQL 重度行业；电商、游戏等行业的迁移模式可能不同。
缺乏失败模式分类：当 Gemini × Kiro-spec 失败时，具体是 schema 误读、函数调用误读、还是类型推断误读？未分类就无法针对性改进。

对工程落地的启发

不要把 specification 当 agent 中立的接口：如果你的工作流涉及多 agent（一个写 spec、一个写实现），spec 一定要针对消费 agent 重新格式化和重写。直接透传会出严重 bug。
RAG 是跨 agent 兼容性的最低公分母：在多 agent 系统中，与其费劲对齐 spec 格式，不如统一接一个 RAG 检索层，让每个 agent 自己去 retrieve 最相关的上下文。这是本文最强的 actionable 结论。
压缩不是银弹：很多 SDD 工具默认"压缩 = 好"，本文提醒：压缩是否有用是 agent-dependent 的。生产环境要 A/B。
Token F1 低 ≠ 完全失败：Gemini × Kiro-spec 那组虽然 Token F1 只有 0.035，但 runnability 可能还行（论文没明确给数字）。看 spec 迁移效果时不要只看表面文本相似度，要看端到端可执行性。
多 agent 协作的设计原则：本文实质上给出了"为什么单 agent 写 spec、多 agent 消费"是个反模式。生产环境要么"一个 agent 全栈"，要么"每个 agent 写自己消费格式的 spec"。中间方案 = 跨 agent 重写 spec 的工程开销。
把 spec portability 列为采购标准：企业选 SDD 工具时，应该问"你的 spec 能直接喂给竞争对手吗？"——能 = 风险（vendor lock-in 强）；不能 = 真正的 spec-first。

与同方向工作的关系

SDD / Spec-Driven 工作流文献：本文质疑了 SDD 的隐含假设（spec 是 agent 中立的），是少数系统化打地基的工作。
Multi-agent code generation（MetaGPT、ChatDev 等）：本文给出了这些系统的实践警告——如果 agent 间通过 spec 通信，spec 必须重写。这对所有用 spec 作为"消息总线"的多 agent 架构都是个警示。
Cross-model prompt portability（同一思路在 LLM prompting 领域的研究）：本文是 software engineering 域的对应物。结论类似：prompt/spec 不是模型中立的。
RAG for code generation（RAGAS、CodeRAG 等）：本文发现 RAG 是跨 agent 共赢策略，与这些工作的结论一致——但本文的"共赢"视角独特。
DBT 社区的 dialect-portability 工作：DBT（data build tool）一直在解决 SQL 跨方言移植问题，本文是从 LLM agent 视角给出的"该问题不仅没被 LLM 解决，反而恶化了"的警告。

为什么这件事重要——三句话总结

采购决策：任何声称"spec-driven 跨 agent 兼容"的厂商声明都要打问号。本文给出了反驳基准。
架构决策：多 agent 系统的 spec 层不能假设透明，必须显式做格式化和重写，或者用 RAG 替代直接透传。
研究决策：这个领域的"spec 中立性"假设被击穿后，研究重点应该从"agent 性能优化"转向"spec 适配工程"。

如果你是工程师，这篇文章最实用的结论是：在企业编码 agent 选型时，跨 agent 兼容必须是评估维度——而不是"谁家的 agent 单跑 native spec 强"。后者是营销叙事，前者是工程现实。

适合谁读

SDD 工具开发者：这是直接打脸"spec 通用"叙事的文章，应该认真读。
多 agent 协作系统架构师：跨 agent 接口设计的关键参考。
企业级 LLM 编码平台工程团队：选型 Kiro / Copilot / Cursor 时的决策依据。
软件工程研究者：方法论范本——怎么设计一个"质疑隐含假设"的实验。
不推荐给纯应用开发者：单个 agent 场景下不直接受益。
EMNLP 投稿者：本团队 2026 年 EMNLP 投稿与本文"多 agent 写作 vs 评估"的思路有可对照的方法学价值——Dis2Pat 关注长文本生成中的 spec 偏离问题，Specification Portability 关注 spec 自身的跨 agent 兼容问题。两条线交叉点是"spec/格式是否是模型中立的"。
LLM 评估方法学研究者：本文给出的 6 维指标矩阵是评估长文本生成质量时的一个可借鉴的多层分解范式。
CTO / 采购决策者：本文应被纳入"SDD 工具采购评估清单"——任何一个 vendor 声称 spec 跨 agent 兼容，都应该问"在 Oracle→PG 这种受控任务上的退化率是多少？"

§0 自检栏

机制段数：4（两阶段实验 / 6 维指标 / native vs foreign 对照 / Pareto frontier 分析）
工程段数：3（Oracle-PG 受控任务 / RAG 跨 agent 兼容 / 重写与压缩的工程取舍）
⚠️ 数字核验：2 处（评估指标权重 + 多 agent 全量矩阵需 fetch PDF §X）
私域五维 SUM：0（ip / kp / rn / fp / oc 均无）
CJK：约 2500（≤4000）
verifiability：已 web_fetch arxiv abs 页 ✓

工程落地与核查（Jay）

实际系统怎么用

场景一：企业内部多 agent 流水线改造

如果你的系统里有"agent A 写 spec → agent B 消费 spec"的链路上，改造步骤：

在 agent A 和 agent B 之间插入一个spec rewriting agent（轻量 prompt rewrite，不重训）
rewriting agent 的 prompt 里明确 target agent 的 tokenizer 特征和训练数据域
关键：rewriting agent 本身也要评估，不能假设 rewrite 总是正向收益

场景二：选型评估

采购 SDD agent 时，在 POC 阶段加入 spec portability 测试：

给定同一批 Oracle 脚本
  → Kiro 生成 spec
  → Kiro / Gemini / Copilot 分别消费该 spec
  → 对比 6 维指标（Token F1 / exact match / syntax validity / AST exact / AST similarity / runnability）

任一 agent 的 foreign Token F1 < 0.5，即说明 spec portability 有显著退化，应要求 vendor 提供 spec rewriting 方案。

场景三：RAG 增强接入

最简单的落地方式是不要透传 spec，而是 RAG 检索：

把所有历史 spec 段落存入向量数据库
agent B 在消费前先 RAG query 相似 spec 片段
用检索到的片段扩充 context，而不是直接信任 agent A 的 spec

这不需要改 agent 本身的 prompt，只要在 infra 层加一个 RAG 中间件。

坑在哪

坑 1：RAG corpus 的质量比 RAG 本身更关键

本文的 RAG 有效，前提是 corpus 里有高质量的 spec 示例。如果 corpus 里都是 low-quality spec，RAG 反而会把低质量 spec 推给 agent B。

核查方法：RAG 接入后，抽查 corpus 里 spec 的 Token F1 是否 ≥0.6（相对 ground truth 实现）。低于此值说明 corpus 本身就有问题，不是 RAG 的问题。

坑 2：Token F1 = 0.035 不等于"完全失败"

Gemini × Kiro-spec 这组的 Token F1 低到 0.035，但本文没给 runnability 数字。生产环境里，"生成的 SQL 语法不通但能跑"或"语法对但语义错"这两种失败的处理方式完全不同。

实测建议：先看 runnability，再看 syntax validity，最后看 Token F1。Token F1 最低优先级。

坑 3：跨 agent spec rewriting 的工程成本被低估

rewriting 听起来是轻量操作，但实际上： - 需要维护每个 agent 的 spec 风格 profile - 新 agent 版本更新时，profile 可能需要重新 calibration - rewriting agent 自身也可能出错（错误 rewrite 引入新 bug）

建议先评估 rewriting agent 自身的错误率，再决定是否引入。

坑 4：单一任务域的外部效度

Oracle→PostgreSQL 是强规则、结构化的迁移任务。NL→代码类的 SDD 场景里，spec 的模糊性更高，跨 agent 退化可能更严重还是更轻，未知。

建议：不要直接把本文结论迁移到 NL→代码类任务，先做小规模受控实验。

坑 5：Agent 版本迭代导致结论失效

Kiro / Gemini / Copilot 的版本随时在更新。今天测的结论可能三个月后就变了。

工程建议：把 spec portability 测试做成 CI 的一部分，每次 agent 大版本更新都跑一遍 regression test。

核查项

Gemini × Kiro-spec 的 runnability 数字（最关键的端到端指标）未在摘要给出，需 fetch PDF §4 Table 2 核验。
6 维指标每项的具体权重和阈值需核验 PDF §3。
native vs foreign 各 agent 全量 6 维矩阵在 PDF §4，fetch PDF §X 主表可补全数字。
RAG corpus 构造方式（原文未详述）需联系作者或查看 GitHub 确认。