返回资讯中心
外部精选
软件工程
#开发实践#Artificial Intelligence, Development Tools, Software Development

AI代理迁移需通过退出测试,以免配置迁移后失效

来源标题:Before you buy an AI agent, make it pass an exit test

作者将个人配置从旧编码代理迁移到新代理后,发现旧指令文件仍要求新代理使用旧工具的命令行参数和旧厂商API密钥,近三个月无报错。这暴露了AI代理迁移的“退出问题”:更换模型只需一个下午,但工作任务和配置无法随之迁移,且不会收到任何提示。

InfoWorld2026/11/3 · 3 天前19 分钟阅读

以下正文由 AI 翻译自 InfoWorld(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。

最近我把自己的配置从一个编码代理换到了另一个。花了大约10分钟,我觉得还挺顺利。

第一个代理承载的东西不少。如今它有一个全局指令文件、114个技能文件夹(大部分是安装的,少数是我自己写的)、分布在24个项目里的189条小型记忆笔记,以及73个会调用其命令行工具的脚本。为了让第二个代理拥有同等的基础,我把指令文件复制成了另一个工具会读取的名字——AGENTS.md,然后对产品名做了一次查找替换。

直到这个月我才认真读了替换后的结果。它要求新代理每次调用模型时都使用Codex -p。在那个CLI里,-p是–profile的缩写。如果照字面执行,我的指令会加载一个以所收到的任意提示词命名的配置profile。同一个文件还用粗体警告新代理,绝不要使用旧供应商的API key——一个它根本没有理由靠近的key。什么也没有报错。这个文件在我的主目录里放了将近三个月,看起来像是一次已经完成的迁移。

这就是“退出问题”的微缩版。我可以在一个下午切换模型。但工作并没有随之迁移,而且没有任何东西告诉我这一点。

可移植性的承诺止步于模型

供应商们已经学会了如何回答锁定问题。你问切换的事,听到的是模型选择、标准协议和对话导出。InfoWorld已经论证过,新的AI锁定存在于模型周围的各个层,而不是模型本身。标准方面也在推进。MCP和AGENTS.md现在归入Linux Foundation旗下的Agentic AI Foundation,这对底层管道来说是好消息。

但这些都不能告诉你,一个半途而废的任务能否在更换代理后存活下来。

一个在你的代码库中工作了六个月的代理,已经积累了一些既不属于模型也不属于对话记录的东西:它被要求遵守的决策、它尝试过又放弃的方法、它做过的更改、它只计划过但未实施的更改,以及围绕它接线的权限和hook。导出对话给你的是说过的话的记录。它不会给你工作的状态。

监管机构已经注意到了这件事的大致轮廓。EU Data Act的云切换规则自2025年9月起适用,从2027年1月起,供应商不得就切换本身向客户收费。这些规则是为数据处理服务写的。它们将如何被解读适用于代理的工作状态,谁也说不准,我也不会围绕“结果会对你有利”来规划采购。

退出测试

所以在签约或续约之前,自己先测一下。这个演练需要一天时间和一个现实的任务。

选一个需要记忆的维护工作。我会用的例子——这是示意性的,不是我实际做过的研究——是在一个拥有十几个模块的服务中升级一个日志库。进行到一半时,一个人为决策改变了计划:团队同意为某个下游消费者保留旧的日志格式,这推翻了代理第一天做出的一个假设。

让第一个代理完成大约一半。它已经迁移了七个模块,因为那个决策故意跳过了第八个,并留下了一条说明原因的笔记。在那里停下。要求产品导出它所声称代表这项工作的任何内容,即需求、决策、已完成的操作和剩余步骤。把这份导出——且仅这份导出——交给第二个代理。不同供应商的代理才是真正的测试。一个无法访问第一个代理记忆的全新会话是最低要求。

然后观察第二个代理如何处理它。有四件事很重要。

  • 它会重做已完成的工作吗?如果它重新迁移那七个模块,说明导出记录了意图却丢失了完成状态。在日志升级中,重复更改代价很低。在schema迁移中,它们就是事故。
  • 它会带回一个已退役的假设吗?这是我最关心的失败。如果第二个代理“好心”地“修复”了团队故意跳过的那个模块,说明导出携带了原始计划,却丢掉了覆盖它的决策。一次交接就这样推翻了一个人为决定,而且构建过程中不会有任何东西标记出来,因为代码与那个已不存在的计划完美一致。
  • 人类花多长时间重建上下文?用秒表计时。工程师必须凭记忆回答的每一个问题,都是导出没有保存的状态。
  • 迁移过程中什么坏了?指定某个供应商命令的指令文件。用某个工具格式编写的技能。在某个工具事件上触发的hook。限定于某个产品的凭证。把每一项都写下来。那份清单就是你真正的切换成本,而根据我的经验,它比合同里暗示的任何东西都要长。

把这个演练跑两遍。一次在同一产品内,让一个新会话接续旧会话的工作;一次跨供应商。第一次告诉你产品自身的连续性是否真实。第二次告诉你离开的代价。

不要让供应商挑选任务。每个产品都有一条演示路径,在那里它的记忆看起来完美无缺,而那通常是一个没有历史、没有前人决策来绊脚的全新功能。让任务无聊到没人会争论正确答案。问题不在于第二个代理是否写出好代码;大多数都会。而在于代理是否知道哪些代码它不该写。你的日志升级,带着那个只因为在三月的某次会议上有人说了句话才存在的尴尬例外,才是真正重要的案例。如果你的任务没有尴尬的例外,就加一个。真实项目里到处都是这种东西,而它们恰恰是对话导出最先丢失的,因为它们是口头决定的,写在一句没人标记为需求的句子里。

让供应商展示给你看,而不是告诉你

(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →