Tina 小姐姐三个月前，我们数据分析组的小张还在一张张地写SQL报表，接口测试脚本每次接口一改就得跟着改一大片，他甚至为了一个复杂的多表关联查询憋了一下午。后来我把手里那套基于大模型Agent的无脚本自动化框架开放给组里试用，他的第一反应是“这玩意儿能听懂我在问什么？”——等他在对话框里用大白话敲出“我要看上个月华东区每个品类的销售额环比，异常下降的标出来”然后直接拿到一张可用的图表和一段可复查的SQL时，他愣了半天。这就是自然语言驱动的无脚本自动化：把意图理解、任务规划、工具调用这一整套流程交给Agent，让用户不再写代码、不再写脚本，只用说话就能完成从查数到跑测试再到操作网页的完整闭环。
这篇文章是我自己把这套东西从0到1落地的全过程复盘，包括Agent的核心架构、自然语言转SQL的链路设计、生产环境的安全护栏，以及如何把同一套能力泛化到自动化测试和RPA场景。我会把关键代码、Prompt设计、权限模型和踩过的坑都放进来说清楚，适合正在做AI自动化落地、想用大模型改造内部工具链的工程师和数据同学参考。如果你只是想了解概念，这文章也能帮你看到“无脚本自动化”到底能省下什么、哪些事不能省。
1. “无脚本”不是没有脚本：先说清楚边界再谈自动化
很多人一听“无脚本自动化”，第一反应是彻底告别代码、告别脚本，从此一切自动化都由AI包办。这种理解既是趋势，也是坑。我落地这半年最深的体会是：无脚本是相对使用者而言的，不是相对系统而言的。
1.1 无脚本到底省掉了哪层东西
传统自动化的核心资产是脚本：SQL脚本、Python脚本、Selenium用例、Jenkins流水线声明、RPA流程配置。这些脚本有几个共同问题——有学习成本、有维护成本、有环境依赖。你写一段自动化脚本可能要一小时，维护它可能要一整个迭代周期。最崩溃的是业务规则一变，改脚本的时间比重写一遍还长。
无脚本自动化的思路是把脚本这层从用户侧抹掉，用户只提供自然语言描述，系统内部的Agent负责把意图解析成可执行的计划，再调用底层工具去执行。比如用户说“每天上午10点把销售日报发到钉钉群”，传统做法是写一个Python脚本挂到定时任务里，再写个钉钉机器人推送。无脚本化之后，Agent会自己拆解出“定时触发、查数、汇总、推送”这几个步骤，并调用对应的工具函数完成。用户不需要知道SQL怎么写，更不需要知道发钉钉消息要调哪个SDK的哪个方法。
但系统内部依然有脚本，只是这些脚本从“用户维护”变成了“平台沉淀”。我做的框架里，底层工具都是可复用的原子操作函数，Agent负责把它们按需组合。这些原子操作本身需要工程师写代码，但这是一次性成本，之后所有人都在复用。
1.2 为什么是现在才可能做这件事
早些年也有一堆“自然语言转SQL”的尝试，效果普遍很差，核心原因是当时的模型对复杂语义和长上下文的建模能力不够。到了大模型时代，尤其是支持Function Calling和ReAct模式的模型成熟之后，Agent可以做到：
- 理解用户的话并拆解出明确的执行步骤；
- 判断每一步需要调用哪个工具、传什么参数；
- 执行后读取结果，判断是否达到目标；
- 结果不对时自己修正策略，具备基础的反思和重试能力。
这套能力使得自然语言不再是仅供查询的玩具，而是可以驱动机器执行真实业务的接口。注意，它并不聪明到可以完全自主处理一切异常，但配合良好的工具设计和人机校验机制，落地是可行的。
1.3 三条技术路线的选型对比
我做过三轮方案对比，分别是纯Prompt套壳、单Agent+Function Calling、多Agent协作。这里把差异讲清楚，帮你少走弯路。
| 路线 | 核心思路 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 纯Prompt套壳 | 把用户问题和工具说明都塞进上下文，让模型输出JSON格式指令，外部解析执行 | 实现最简单，几小时能跑通Demo | 工具一多上下文爆炸、格式不稳定、无法处理连续多步任务 | 极少数固定工具的轻量场景 |
| 单Agent+Function Calling | 模型内置工具定义，模型自主决定调用哪个函数，循环执行直到完成任务 | 任务分解和执行连贯，工具扩展容易，有反馈修正能力 | 长任务容易出现错误累积，复杂场景下模型可能陷入重复循环 | 单领域多工具的自动化，是我最终选用的路线 |
| 多Agent协作 | 分为Planner、Executor、Validator等多个角色Agent，各司其职 | 复杂任务拆分清晰，各环节可独立优化，适合大规模流程 | 架构重、调试成本高、token消耗大得多 | 跨部门级复杂流程编排 |
我最终选了单Agent+Function Calling作为主架构，原因很实际：我们的场景以“查询-分析-执行-反馈”为主线，单Agent的循环足够覆盖，而且多Agent之间本身也存在上下文传递的损耗，调试起来让人头大。先跑通单Agent，后续再按需拆成Planner和Validator，比一开始就上重架构要稳。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 自然语言转SQL：Agent架构里的核心链路拆解
“Agent实现把自然语言转换成SQL”是最近社区里最火的方向之一，也是我这个无脚本框架里最先落地、反馈最好的一块。很多人以为这事就是把表结构丢给大模型然后让它输出SQL，实际远没有这么简单。我趟了大概两周的坑，才把这条链路跑到生产可用。
2.1 先让Agent认识你的数据：Schema上下文工程
模型不知道你库里有几张表、每张表什么含义、字段是什么业务口径。如果你只把“users”“orders”这种表名和字段名