我们把 26 个接口自动化场景接进了 Agent，效果真是没想到！！

本文围绕我们把 26 个接口自动化场景接进了 Agent，效果真是没想到！！整理关键信息和实用建议，帮助读者快速了解主题重点。

事情是这样的。

一次看起来不大的互动业务调整，改动可能就那么一点点。

但真正开始测试后，事情会迅速膨胀。

主播、普通用户、新用户，不同角色要测。

普通礼物、盲盒类礼物、抽奖、榜单联动，不同互动类型要测。

再换上不同房间、不同业务场景和特定时间条件，一张回归矩阵很快就铺开了。

按我们对这类已覆盖回归范围的经验估算，完整跑一轮，过去大约需要三天。

把其中的高频操作接入接口自动化后，同类验证可以压缩到半天左右。

这组耗时只对应上面这个多角色、多场景的具体回归范围。省下来的时间，主要来自反复切换角色、寻找脚本、准备环境和拼接参数。

不过，三天变半天，还不是这件事最值得复盘的地方。

真正让我们重新看待这批脚本的，是后来公司开始建设自己的 Agent 平台。

一段脚本能跑，和一段脚本能被团队、甚至被 Agent 稳定调用，原来完全是两回事。

这中间差的东西，比想象中多。

一、脚本能跑，为什么 Agent 还是用不了

这批接口脚本出现得比 Agent 平台更早。

最初写它们，就是为了少做一些重复操作。

脚本写给自己用的时候，真的很容易。

路径我知道，依赖我装过，参数我记得，执行前要准备什么，我也清楚。真报错了，打开源码看两眼，大概就知道卡在哪。

时间久了，同一个送礼动作、查询动作，不同同学可能各自保存了一份实现。每一份都能跑，每一份也都带着作者自己的环境和使用习惯。

这对个人来说没什么问题。

换个人，麻烦就来了。

入口在哪，参数怎么填，缺了什么上下文，失败以后该看哪里，都要重新问一遍。一个同学把单次操作跑快了，其他人还是得重新找脚本、配环境、读代码。

现在再把 Agent 放进来，问题更明显。

人遇到不懂的地方，还能回头问作者。Agent 看见仓库里有一段脚本，并不会自动知道它对应什么业务场景，也不会凭空知道哪些参数能推导、哪些参数必须由使用者确认。

更麻烦的是，接口操作不是聊天。

普通问答理解错了，可以重新解释。接口执行错了，测试环境里可能已经产生业务动作和数据。

所以我们当时要解决的，并不是让 Agent 听懂更多话。

而是让它少猜一点。

最好别猜。

二、我们先做了一件不太像 AI 的事

把范围圈住。

我们把自然语言入口限制在一份有限的场景清单里，不允许系统自行寻找任意脚本。

进入清单的都是日常使用频率较高、输入能够整理成标准参数，并且已经有稳定底层能力承接的场景。

目前一共登记了 26 个，覆盖登录、房间信息查询、互动操作、道具操作和状态查询等测试需要。

每个场景都要先写清一份小型契约。

场景标识支持哪些表达必填参数可选参数默认值和可推导参数对应的底层执行能力成功与失败怎样返回

只有注册过场景、定义过参数规则、绑定了底层执行能力的请求，才允许继续往下走。

这件事乍一看有点保守。

聊 Agent 时，大家很容易先留意它能理解多少种表达，能不能更自由地完成任务。可一旦落到真实接口执行，自由并不是第一目标。

可确认，才是。

一句自然语言进来后，系统先判断它有没有命中已登记场景，再从表达里抽取参数，把不同说法统一成标准字段。必填项不够，就停下来暴露缺失条件。能够从上下文推导的参数，放到计划阶段补齐。

确认没有缺失和冲突后，才进入执行。

如果场景不支持、参数缺失、自动推导失败，或者底层调用失败，系统会停在对应阶段，返回结构化错误。

不是接住一句话以后一路冲到底。

而是每走一步，都知道自己走到了哪。

三、五个入口，只有一个真的执行

顺着这个思路，我们把调用入口拆成了五个。

parse 只管理解，不自动补齐运行时上下文，也不会触发接口。

plan 往前走一步，把能够推导的参数补上，同时把仍然缺失的条件摊开。

只有 run，才会真正调用底层能力。

这五个入口其实很像一次执行前的逐级确认。

第一次使用某个场景，可以先看说明，再看执行计划。场景和参数已经明确时，可以直接运行。中间出了问题，也能判断错误是在场景识别、参数准备，还是已经到了底层执行。

听起来只是多拆了几个命令，对吧。

但对 Agent 来说，这个拆分很关键。

它不用在一句话里同时完成理解、补参数、做决定和执行。能力发现、参数解析、执行规划和真实调用，被拆成了几个边界清楚的动作。

我们已经用秀场送礼、公共房全麦送礼等场景完成了真实调用验证。

一个典型请求，可以直接从业务表达开始。

Agent 先匹配已登记场景，再检查发送方、接收方、礼物和房间等必要信息。能从上下文获得的参数，由计划阶段补齐。条件齐全以后，底层脚本才会被真正调用。

执行完成后，结果会给出命中的场景、关键参数、执行状态和结果摘要。

以前那套找脚本、开代码、翻注释、拼参数的过程，被收进了一条稳定链路里。

把镜头再往后拉一点，整条运行链路其实分成四层。

自然语言或结构化命令↓统一入口层↓场景与解析层识别场景、提取参数、检查缺失项↓执行路由层把场景和参数映射到已有能力↓底层接口脚本完成测试环境里的查询或业务操作

自然语言在最上面。

确定性执行在最下面。

中间的场景契约和执行路由，把两边接起来。

Agent 没有变成新的接口执行器。它负责理解请求、选择 Skill 并组织调用，真正完成测试环境操作的，还是我们已经验证过的底层脚本。

到这里，调用链路已经能跑了。

可运行还不够。

接下来还有一个很现实的问题，怎么把它稳定交到别人手里。

四、本机能跑以后，怎么交给别人继续用

做交付方案时，我们面对的约束很具体。

日常开发环境同时有 Windows 和 Linux，Agent 的目标运行环境是 Linux。平台通过 CLI 接入 Skill。我们不想为这项能力再单独部署和维护一个服务，也不希望平台直接接触整个 Python 源码仓库。

还有一个经常被忽略的问题。

本地代码一直在迭代，但别人正在使用的版本，不能跟着开发目录一起变化。

直接上传 Python 源码最省事，可源码、依赖和运行环境会耦在一起，本地迭代和平台使用之间也没有清晰的发布边界。

单独部署服务可以统一调用，却会多出服务部署、运行和维护成本。

二进制加完全外置配置，隔离会更彻底，只是当前阶段还没必要先把这件事做得这么重。

综合这些约束，我们选了 Linux CLI 二进制。

在 Windows 和 Linux 环境维护 Python 源码↓统一 CLI 契约↓GitLab Linux Runner 安装依赖并自动测试↓PyInstaller 构建 Linux 可执行文件↓组装 Skill Bundle↓从 CI artifact 下载并上传 Agent 平台

CI 会先检查场景解析、执行路由、调用协议和五个 CLI 入口。测试通过以后，再生成 Linux 运行产物，并按照 Skill 需要的目录和说明文件组装交付包。

源码继续由我们维护，Agent 平台拿到的是经过测试和构建的固定产物。

只有重新构建、生成制品并上传新包，修改后的代码才会进入平台。某个同学本地正在开发的内容，不会直接影响其他人当时使用的版本。

说真的，这一段没有什么炫技的 Agent 玩法。

但它决定了这项能力是一次现场演示，还是别人明天仍然能继续使用的东西。

五、接口调用成功以后，测试还没结束

能力接进 Agent 后，使用者不必再记脚本路径和命令格式，可以直接从业务表达进入已经登记的场景。

门槛确实低了。

责任不能跟着变模糊。

当前这项能力只在测试环境使用。在这个范围里，它向所有成员开放，服务端、前端、客户端和运营同学都已经实际调用过。

执行时，Agent 负责理解请求、选择 Skill 并组织调用。场景与解析层负责限制范围、检查参数和暴露错误。底层脚本完成确定性的测试环境接口操作。

调用完成后，系统会返回结构化的成功或失败结果，业务数据侧也会留下相应记录，方便继续查询和复核。

但接口返回成功，只能说明这次调用完成了。

测试范围怎么选，后置状态怎么查，完整业务结果怎么判断，失败和异常怎么处理，仍然由我们负责。

最终测试结论，不是 Agent 替我们做。

写到这里再回头看，最开始吸引注意力的确实是自然语言。

对着 Agent 说一句话，它就能去执行接口。这个画面足够直观，也足够像 AI。

但这套能力真正能落地，靠的几乎都是那些不太显眼的东西。

场景清单、参数契约、执行边界、五个 CLI 入口、CI 测试、Linux 构建、固定制品、版本隔离，还有人与 Agent 的责任分工。

现在已经验证的部分很明确。

我们登记了 26 个高频场景，还在陆续迭代当中，在 Agent 中完成了多个真实测试场景的调用，也在一个具体的多角色、多场景回归范围内，把过去约三天的执行过程压缩到了半天左右。

说实话，我们还差得远。

目前能力只服务测试环境。完整端到端断言还需要继续补。批量执行、并发和性能测试不属于现阶段已经交付的能力，其他测试类型也还没有覆盖。已有调用结果和业务数据记录可以复核，但独立的 Agent 审计系统尚未建立。

如果你也准备把团队里的内部脚本交给 Agent，可以先检查下面这些问题。

[ ] 支持范围有没有收敛成明确的场景清单[ ] 每个场景有没有写清参数和返回方式[ ] 解析、计划和真实执行有没有分开[ ] 场景背后是不是经过验证的确定性能力[ ] 有没有固定的测试、构建和版本交付链路[ ] 使用环境、执行记录和人工责任有没有说清楚

一个脚本能跑，解决的是一次操作。

一批脚本能被别人理解、调用和稳定交付，才开始成为团队能力。

自然语言只是入口。

契约、工程交付和人的判断，才是这套能力真正站住的地方。

下一篇，我们会继续沿着真实测试流程往下走，拆解测试数据、缓存状态和消息结果怎样协同验证，以及查询、修改和人工确认分别应该放在哪里。

另外，我们还建了一个「技术交流群」，欢迎留意「花椒技术」平台账号，回复「AI」进群，和一线技术从业者一起研究 AI 工程化、AI 编程、Agent 落地，也交流代码评审、企业内部 AI 助手等真实实践。

这是个只聊技术和工程落地的交流群（不卖课、不讲空话、不制造焦虑、不拿工具清单冒充实战，只分享真实经验、踩坑过程和技术细节，希望能帮你少走一些弯路）

群里还会同步每日精选的研发向 AI 日报、文章延伸资料，以及正文中没有展开的技术细节。

以上内容可作为基础参考，实际处理时再结合具体场景灵活调整。