事情是这样的。
一次看起来不大的互动业务调整，改动可能就那么一点点。
但真正开始测试后，事情会迅速膨胀。
主播、普通用户、新用户，不同角色要测。
普通礼物、盲盒类礼物、抽奖、榜单联动，不同互动类型要测。
再换上不同房间、不同业务场景和特定时间条件，一张回归矩阵很快就铺开了。
按我们对这类已覆盖回归范围的经验估算，完整跑一轮，过去大约需要三天。
把其中的高频操作接入接口自动化后，同类验证可以压缩到半天左右。
这组耗时只对应上面这个多角色、多场景的具体回归范围。省下来的时间，主要来自反复切换角色、寻找脚本、准备环境和拼接参数。
不过，三天变半天，还不是这件事最值得复盘的地方。
真正让我们重新看待这批脚本的，是后来公司开始建设自己的 Agent 平台。
一段脚本能跑，和一段脚本能被团队、甚至被 Agent 稳定调用，原来完全是两回事。
这中间差的东西，比想象中多。
一、脚本能跑，为什么 Agent 还是用不了
这批接口脚本出现得比 Agent 平台更早。
最初写它们，就是为了少做一些重复操作。
脚本写给自己用的时候，真的很容易。
路径我知道，依赖我装过，参数我记得，执行前要准备什么，我也清楚。真报错了，打开源码看两眼，大概就知道卡在哪。
时间久了，同一个送礼动作、查询动作，不同同学可能各自保存了一份实现。每一份都能跑，每一份也都带着作者自己的环境和使用习惯。
这对个人来说没什么问题。
换个人，麻烦就来了。
入口在哪，参数怎么填，缺了什么上下文，失败以后该看哪里，都要重新问一遍。一个同学把单次操作跑快了，其他人还是得重新找脚本、配环境、读代码。
现在再把 Agent 放进来，问题更明显。
人遇到不懂的地方，还能回头问作者。Agent 看见仓库里有一段脚本，并不会自动知道它对应什么业务场景，也不会凭空知道哪些参数能推导、哪些参数必须由使用者确认。
更麻烦的是，接口操作不是聊天。
普通问答理解错了，可以重新解释。接口执行错了，测试环境里可能已经产生业务动作和数据。
所以我们当时要解决的，并不是让 Agent 听懂更多话。
而是让它少猜一点。
最好别猜。
二、我们先做了一件不太像 AI 的事
把范围圈住。
我们把自然语言入口限制在一份有限的场景清单里，不允许系统自行寻找任意脚本。
进入清单的都是日常使用频率较高、输入能够整理成标准参数，并且已经有稳定底层能力承接的场景。
目前一共登记了 26 个，覆盖登录、房间信息查询、互动操作、道具操作和状态查询等测试需要。
每个场景都要先写清一份小型契约。
text
场景标识
支持哪些表达
必填参数
可选参数
默认值和可推导参数
对应的底层执行能力
成功与失败怎样返回只有注册过场景、定义过参数规则、绑定了底层执行能力的请求，才允许继续往下走。
这件事乍一看有点保守。
聊 Agent 时，大家很容易先关注它能理解多少种表达，能不能更自由地完成任务。可一旦落到真实接口执行，自由并不是第一目标。
可确认，才是。
一句自然语言进来后，系统先判断它有没有命中已登记场景，再从表达里抽取参数，把不同说法统一成标准字段。必填项不够，就停下来暴露缺失条件。能够从上下文推导的参数，放到计划阶段补齐。
确认没有缺失和冲突后，才进入执行。
如果场景不支持、参数缺失、自动推导失败，或者底层调用失败，系统会停在对应阶段，返回结构化错误。
不是接住一句话以后一路冲到底。
而是每走一步，都知道自己走到了哪。
三、五个入口，只有一个真的执行
顺着这个思路，我们把调用入口拆成了五个。
| 命令 | 用来做什么 | 是否执行真实操作 |
|---|---|---|
scenes |
查看当前支持哪些场景 | 否 |
help-scene |
查看某个场景需要哪些参数 | 否 |
parse |
判断命中了什么场景、提取了哪些参数 | 否 |
plan |
补齐可推导参数，并暴露仍然缺失的条件 | 否 |
run |
按准备好的场景和参数执行 | 是 |
parse 只管理解，不自动补齐运行时上下文，也不会触发接口。
plan 往前走一步，把能够推导的参数补上，同时把仍然缺失的条件摊开。
只有 run，才会真正调用底层能力。
这五个入口其实很像一次执行前的逐级确认。
第一次使用某个场景，可以先看说明，再看执行计划。场景和参数已经明确时，可以直接运行。中间出了问题，也能判断错误是在场景识别、参数准备，还是已经到了底层执行。
听起来只是多拆了几个命令，对吧。
但对 Agent 来说，这个拆分很关键。
它不用在一句话里同时完成理解、补参数、做决定和执行。能力发现、参数解析、执行规划和真实调用，被拆成了几个边界清楚的动作。
我们已经用秀场送礼、公共房全麦送礼等场景完成了真实调用验证。
一个典型请求，可以直接从业务表达开始。
在测试环境执行一次秀场送礼，发送方使用测试账号 A，接收方使用测试账号 B，发送指定测试礼物。
Agent 先匹配已登记场景，再检查发送方、接收方、礼物和房间等必要信息。能从上下文获得的参数，由计划阶段补齐。条件齐全以后，底层脚本才会被真正调用。
执行完成后，结果会给出命中的场景、关键参数、执行状态和结果摘要。
以前那套找脚本、开代码、翻注释、拼参数的过程，被收进了一条稳定链路里。
把镜头再往后拉一点，整条运行链路其实分成四层。
text
自然语言或结构化命令
↓
统一入口层
↓
场景与解析层
识别场景、提取参数、检查缺失项
↓
执行路由层
把场景和参数映射到已有能力
↓
底层接口脚本
完成测试环境里的查询或业务操作自然语言在最上面。
确定性执行在最下面。
中间的场景契约和执行路由，把两边接起来。
Agent 没有变成新的接口执行器。它负责理解请求、选择 Skill 并组织调用，真正完成测试环境操作的，还是我们已经验证过的底层脚本。
自然语言在入口层被逐步收敛，最终由已经验证过的底层脚本完成确定性执行。
到这里，调用链路已经能跑了。
可运行还不够。
接下来还有一个很现实的问题，怎么把它稳定交到别人手里。
四、本机能跑以后，怎么交给别人继续用
做交付方案时，我们面对的约束很具体。
日常开发环境同时有 Windows 和 Linux，Agent 的目标运行环境是 Linux。平台通过 CLI 接入 Skill。我们不想为这项能力再单独部署和维护一个服务，也不希望平台直接接触整个 Python 源码仓库。
还有一个经常被忽略的问题。
本地代码一直在迭代，但别人正在使用的版本，不能跟着开发目录一起变化。
直接上传 Python 源码最省事，可源码、依赖和运行环境会耦在一起，本地迭代和平台使用之间也没有清晰的发布边界。
单独部署服务可以统一调用，却会多出服务部署、运行和维护成本。
二进制加完全外置配置，隔离会更彻底，只是当前阶段还没必要先把这件事做得这么重。
综合这些约束，我们选了 Linux CLI 二进制。
text
在 Windows 和 Linux 环境维护 Python 源码
↓
统一 CLI 契约
↓
GitLab Linux Runner 安装依赖并自动测试
↓
PyInstaller 构建 Linux 可执行文件
↓
组装 Skill Bundle
↓
从 CI artifact 下载并上传 Agent 平台CI 会先检查场景解析、执行路由、调用协议和五个 CLI 入口。测试通过以后，再生成 Linux 运行产物，并按照 Skill 需要的目录和说明文件组装交付包。
源码继续由我们维护，Agent 平台拿到的是经过测试和构建的固定产物。
只有重新构建、生成制品并上传新包，修改后的代码才会进入平台。某个同学本地正在开发的内容，不会直接影响其他人当时使用的版本。
说真的，这一段没有什么炫技的 Agent 玩法。
但它决定了这项能力是一次现场演示，还是别人明天仍然能继续使用的东西。
源码通过 CI 测试和 Linux 构建生成固定交付物，再组装成 Skill Bundle 上传到 Agent 平台。
五、接口调用成功以后，测试还没结束
能力接进 Agent 后，使用者不必再记脚本路径和命令格式，可以直接从业务表达进入已经登记的场景。
门槛确实低了。
责任不能跟着变模糊。
当前这项能力只在测试环境使用。在这个范围里，它向所有成员开放，服务端、前端、客户端和运营同学都已经实际调用过。
执行时，Agent 负责理解请求、选择 Skill 并组织调用。场景与解析层负责限制范围、检查参数和暴露错误。底层脚本完成确定性的测试环境接口操作。
调用完成后，系统会返回结构化的成功或失败结果，业务数据侧也会留下相应记录，方便继续查询和复核。
但接口返回成功，只能说明这次调用完成了。
测试范围怎么选，后置状态怎么查，完整业务结果怎么判断，失败和异常怎么处理，仍然由我们负责。
最终测试结论，不是 Agent 替我们做。
写到这里再回头看，最开始吸引注意力的确实是自然语言。
对着 Agent 说一句话，它就能去执行接口。这个画面足够直观，也足够像 AI。
但这套能力真正能落地，靠的几乎都是那些不太显眼的东西。
场景清单、参数契约、执行边界、五个 CLI 入口、CI 测试、Linux 构建、固定制品、版本隔离，还有人与 Agent 的责任分工。
现在已经验证的部分很明确。
我们登记了 26 个高频场景，还在陆续迭代当中，在 Agent 中完成了多个真实测试场景的调用，也在一个具体的多角色、多场景回归范围内，把过去约三天的执行过程压缩到了半天左右。
说实话，我们还差得远。
目前能力只服务测试环境。完整端到端断言还需要继续补。批量执行、并发和性能测试不属于现阶段已经交付的能力，其他测试类型也还没有覆盖。已有调用结果和业务数据记录可以复核，但独立的 Agent 审计系统尚未建立。
如果你也准备把团队里的内部脚本交给 Agent，可以先检查下面这些问题。
text
[ ] 支持范围有没有收敛成明确的场景清单
[ ] 每个场景有没有写清参数和返回方式
[ ] 解析、计划和真实执行有没有分开
[ ] 场景背后是不是经过验证的确定性能力
[ ] 有没有固定的测试、构建和版本交付链路
[ ] 使用环境、执行记录和人工责任有没有说清楚一个脚本能跑，解决的是一次操作。
一批脚本能被别人理解、调用和稳定交付，才开始成为团队能力。
自然语言只是入口。
契约、工程交付和人的判断，才是这套能力真正站住的地方。
下一篇，我们会继续沿着真实测试流程往下走，拆解测试数据、缓存状态和消息结果怎样协同验证，以及查询、修改和人工确认分别应该放在哪里。
另外，我们还建了一个「技术交流群」，欢迎关注「花椒技术」公众号，回复「AI」进群，和一线技术从业者一起研究 AI 工程化、AI 编程、Agent 落地，也交流代码评审、企业内部 AI 助手等真实实践。
这是个只聊技术和工程落地的交流群（不卖课、不讲空话、不制造焦虑、不拿工具清单冒充实战，只分享真实经验、踩坑过程和技术细节，希望能帮你少走一些弯路）
群里还会同步每日精选的研发向 AI 日报、文章延伸资料，以及正文中没有展开的技术细节。