Agent SQL 部署之争：遮蔽提取还是本地草稿模型？

引言：当 Agent 改写出代价高昂的查询

一个平台团队目睹过这样的事故：Agent 在发布评审时改写了营收查询。新语句连接了三张大表，却遗漏了选择性谓词，查询规划器随即选择了大范围扫描。工程师在锁被持有之前取消了语句，然后记录了草稿路径而非模型品牌。剩下的关键决策是：下一份草稿应该在哪里运行，以及哪些数据可以离开生产边界。

这是一个用于本次讨论的复合场景，并非来自某家公司的实测故障报告。但它确实对应了一种反复出现的模式——当 Agent 在没有放置规则的情况下针对实时目录起草 SQL 时，问题就会出现。更好的语言模型本身并不能决定 schema 文本是否可以跨越网络边界。围绕放置、脱敏和预演的软件控制，仍然决定着流畅的草稿是否可以被接受并运行。

rss source: Masked Extracts or Local Draft Models: A Debate for Agent SQL Placement

选择性谓词（selective predicate）是 SQL 中能把结果集从整表缩小到少量行的过滤条件，例如 WHERE created_at >= DATE '2026-10-01' 或 WHERE user_id = 42。查询规划器会依据这些谓词估算返回行数：当谓词选择性强时，它倾向于走索引扫描；一旦谓词被遗漏或写成 WHERE 1=1 之类恒真条件，估算行数会急剧上升，规划器便可能退化为全表扫描或大范围顺序扫描。在同一事务中，扫描范围越大，锁持有时间与 I/O 竞争越严重，这正是文中事故里工程师必须在锁被持有前取消语句的原因。因此在 Agent 草稿评审中，除了看 SQL 是否语法正确，还应专门核对选择性谓词是否被保留或改写，因为遗漏谓词往往不会触发语法错误，只会在运行时以成本和锁的形式暴露。

两种可信的立场

立场 A 将脱敏后的目录提取发送给免费托管模型，然后在免费的一次性服务器上预演返回的 SQL。立场 B 将所有草稿生成保留在团队信任边界内的本地模型上。该立场仅将外部服务器用作执行见证者，并加载合成行数据。

两方的分歧在于：哪个工件可以移动，以及哪个系统可以看见真实的对象名称。

立场 A：托管脱敏草稿

立场 A 主张，当提示包含当前表名和关键关系时，托管模型往往能起草更流畅的 SQL。脱敏提取可以在托管调用之前移除行样本、注释和高敏感列名。免费服务器随后提供隔离的规划器和生产角色不共享的权限集。其核心论点是：将草稿生成与生产执行分离，比未经预演的本地草稿更能降低锁风险。

立场 B：边界内的本地模型

立场 B 反驳说，即使移除了行样本，列名、检查约束和关系图仍可能揭示产品结构。本地模型可以通过内部工具读取实时目录，永远不传输这些文本。免费服务器如果使用，也只应接收合成标识符和候选语句。其核心论点是：执行见证者并不要求草稿模型位于边界之外。

信任边界（trust boundary）指系统中数据与指令可以在不违反安全或合同约束的前提下自由流动的边界。边界之内通常是团队直接控制的机器、网络和身份体系；边界之外则是托管模型、第三方服务器或其他组织控制的资源。判断一个工件能否移动，实质上是在判断它跨越边界后是否仍受原团队的策略约束：即使内容被脱敏，一旦发送到外部，就同时受对方日志、保留策略和条款的约束，原团队无法单方面撤回。文中把“哪个工件可以移动”与“哪个系统可以看见真实对象名称”并列为核心分歧，正是因为跨越边界后，访问控制、审计与删除权都会发生转移。团队应在起草任何提示之前先书面标定这条边界，否则技术上的脱敏措施无法替代合同与合规层面的判定。

可实际核查的证据

两种立场都不是普遍更便宜、更安全或更准确，本文也不报告任何基准测试。有用的证据是定性的，每个团队都可以对照自己书面的目录策略来核查。

托管草稿质量只有在团队被允许导出定义的 schema 子集时才重要。本地草稿质量只有在团队确实能在目录旁运行模型时才重要。预演价值取决于一次性服务器是否具有相似的索引，而不是服务器是否免费。

下表比较这些放置输入因素，不对任何供应商、模型家族或托管方案进行排名。免费托管模型和免费服务器的可用性可以使立场 A 对未分类的练习目录变得可行。但这种可用性不能改变合同禁令，也不能证明脱敏名称是无害的。

决策输入	支持脱敏托管草稿	支持本地草稿模型	拒绝两种外部跳转
Schema 分类	名称是内部的但不受监管	名称揭示未发布的产品范围	任何目录文本均禁止导出
提示内容	行样本已被剥离	目录文本从不离开主机	有用草稿将需要样本
规划器保真度	合成服务器可镜像索引	本地数据库已镜像索引	本周没有安全镜像可供使用
坏连接失败成本	预演可在生产前捕获	本地 explain 可在评审前捕获	无法阻止写访问
运营约束	托管调用和服务器当前可用	本地模型由团队维护	外部条款不可接受

带编号检查的放置工作流

以下工作流是用于本次讨论的具体放置程序，可在未分类目录上运行。每个编号步骤生成一个评审者可检查的工件，无需信任 Agent 的解释。命令是 PostgreSQL 风格预演的模式，应根据所用服务器版本进行调整。

在构建任何提示之前对目录提取进行分类，将每张表标记为可导出、需要遮蔽或仅限本地。
仅从目录元数据构建提取，保留名称、类型和声明的键，同时删除注释和样本值。
用自动门禁对提取进行评分，在缺失标签、敏感类别或从日志复制的字面量上失败。
仅当门禁通过且评审者可以在调用前阅读确切载荷时，才选择托管放置。
在具有合成行、只读角色和执行前捕获的 explain 计划的一次性服务器上预演。
在语句哈希旁记录模型放置、提取哈希、服务器身份和 explain 输出，以供后续评审。

工件：门禁、角色和四项检查

以下 Python 是步骤 3 中门禁的提案，并非生产策略引擎。本文未针对私有目录执行过它，因此团队应将输出视为起始检查。通过结果意味着载荷避免了三种明显失败，而非 schema 可以安全导出。

import re
from hashlib import sha256

SENSITIVE = {"email", "phone", "ssn", "api_key"}
LITERAL = re.compile(r"[A-Z0-9._%+-]+@[A-Z0-9.-]+\\.[A-Z]{2,}", re.I)

def gate(columns, payload):
    missing = [c["name"] for c in columns if "class" not in c]
    leaked = [c["name"] for c in columns if c.get("class") in SENSITIVE]
    literals = LITERAL.findall(payload)
    ok = not missing and not leaked and not literals
    digest = sha256(payload.encode("utf-8")).hexdigest()
    return {"ok": ok, "missing": missing, "leaked": leaked, "digest": digest}

通过门禁是必要的但不充分，因为预演角色仍需要数据库侧边界。在 PostgreSQL 上，评审者可以创建只读角色并在不授予写权限的情况下检查计划。以下语句是用于一次性服务器的模式，并非声称每个主机都使用相同的默认值。

CREATE ROLE agent_reader NOLOGIN;
GRANT CONNECT ON DATABASE rehearsal TO agent_reader;
GRANT USAGE ON SCHEMA public TO agent_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO agent_reader;
SET ROLE agent_reader;
EXPLAIN (FORMAT TEXT)
SELECT o.id
FROM orders AS o
JOIN payments AS p ON p.order_id = o.id
WHERE o.created_at >= DATE '2026-10-01';

PostgreSQL 在官方参考中记录了 EXPLAIN 和权限规则，这是这些命令的主要来源。团队应该阅读该版本的页面后再复制授权，因为默认权限可能因版本而异。如果一次性服务器无法承载忠实的索引集，请将计划标记为语法见证而非成本预测。

在任何人都信任该辅助工具之前，运行四项检查，并记录返回的字典而非聊天截图。这些检查是提案的预期行为，并非已执行的私有运行记录。

传递一个仅列出可导出列且类别存在的载荷，预期 ok 标志为 true。
使包含类别为 email 的列的载荷失败，预期该列名出现在 leaked 下。
使文本中包含 email 字面量的载荷失败，预期门禁拒绝该载荷。
使省略 class 字段的列条目失败，预期该列名出现在 missing 下。

EXPLAIN 是 PostgreSQL 用于展示查询计划的命令，它本身不执行语句，只返回规划器选择的访问路径与估算成本，可配合 ANALYZE 选项实际执行以获取真实行数与耗时。默认的 EXPLAIN 在只读角色下即可运行，因此可以安全地用于一次性预演环境。需要注意的是，成本数字依赖统计信息：若预演库缺少 ANALYZE 生成的列统计，规划器可能低估或高估行数，导致计划与生产环境不一致。文中强调“空统计信息会导致误导性成本预测”正是指这种情形，此时应把输出视为语法与结构上的见证，而非可直接外推到生产的成本预测。团队在对比计划前，最好确认预演库的索引与统计信息已尽可能贴近生产。

免费练习场景的适用位置

一些团队缺乏维护良好的本地模型，但仍需要一个不触及生产环境来练习 Agent SQL 的地方。在这种情况下，MonkeyCode 的免费模型访问和免费服务器选项可以作为该门控路径的练习场景。披露：本文是作为 MonkeyCode 产品推广的一部分准备的。读者在依赖任一场景之前应确认当前条款，因为本文不将可用性视为永久。

本文不提及模型、配额、硬件或时长，因为这些事实未被提供为稳定规格。免费选项可以降低在已通过门禁的未分类目录上尝试工作流的成本。它不能替代分类门禁，也不应被视为永久控制边界。如果门禁失败，评审者保留本地草稿，仍使用隔离数据库进行 explain 步骤。

局限性与适用边界

遮蔽列名并不能匿名化 schema，因为唯一的表名可以揭示发布、合作伙伴关系或欺诈规则。因此，对于名称本身机密的目录，立场 A 是不安全的，即使行样本从未出现在提示中。具有空统计信息的免费服务器会误导成本比较。

样本门禁还遗漏许多秘密形态，包括不类似电子邮件地址的内部标识符。当合同禁止外部推理或分类标签不完整时，团队不应使用托管路径。当 Agent 可以在任何可达数据库上获得写凭证时，也应跳过该路径。如果无法为每个提升的语句配备人工验收步骤，这场讨论就是错误的工具。

决策规则

评审者只有在三个条件同时满足时，才应选择脱敏托管草稿：每个引用的对象必须在载荷组装前被分类为可导出；门禁报告必须显示无敏感列和无字面量；预演服务器必须与生产隔离。当任何对象为仅限本地，或团队无法在调用前评审确切载荷时，选择本地草稿模型。

当无法阻止写访问，或不存在忠实的非生产镜像时，拒绝两种外部跳转。当证据混合、不完整或仍在等待分类时，该规则偏好更严格的放置。流畅性不是安全性的证据，免费练习场景不是可接受边界的证据。记录的提取哈希、角色授权和 explain 输出是后续评审者应信任的验收包。

如果评审笔记已经捕获计划但未捕获放置，请在下次 Agent SQL 变更前添加提取哈希。这单个字段使讨论可审计，无论草稿模型在本地还是免费托管练习路径上运行。