把 Agent 接到数据库与内部 API
系列入口：如何使用 Agent。前置：MCP 协议、选型目录。
一、这是价值最高、也最危险的一类连接
让 Agent 能直接查询真实数据、调用内部接口，会极大扩展它的能力边界：从「只能看代码」变成「能基于线上数据做分析、排查、对账」。做数据相关的需求和故障排查时，这几乎是刚需。
但它同时是风险最高的连接。数据库里有真实业务数据和用户隐私；一条低效查询可能拖垮生产；写入和某些 API 调用一旦发出不可撤回。因此这类连接的设计原则必须是默认克制：先把「能不能看」安全地解决，再极其谨慎地讨论「能不能改」。
二、三种接法与取舍
2.1 现成数据库 MCP Server
最快：选一个支持只读模式、schema 限制和查询限制的现成 Server，配一个独立数据库账号接入。适合标准数据库、常规查询。要点是把权限做在数据库账号这一层，而不要指望 Agent 自觉——它拿到什么权限，就能执行什么操作。
2.2 自建收口层（接内部 API 更常用）
内部系统往往没有现成 Server，或你希望严格控制能调哪些接口、返回哪些字段。这时自建 MCP Server，由它持有内部凭据、封装少数几个语义明确的只读接口。Agent 不直接碰凭据和网络细节，只能调用你暴露的能力，这是最可控的接法。
2.3 只读副本 / 数据中间层
对生产分析场景，最佳实践是让 Agent 连只读副本或专门的分析库，而不是在线主库；更敏感时，在数据库前再放一层只暴露白名单视图/接口的中间层。这样即使查询低效，也不冲击核心交易；即使凭据泄露，暴露面也被预先收窄。
三、只读优先：把权限做在账号层
「只读优先」不是一句口号，要落到具体的数据库账号配置上：
- 专用账号：为 Agent 单独建账号，绝不复用应用或个人的高权限账号，便于随时回收和审计。
- 只授 SELECT：不给 INSERT/UPDATE/DELETE/DDL；只对必要的库、表甚至视图授权。
- 白名单视图：把敏感字段（身份证、手机号、密钥）排除在外，只暴露经过裁剪的视图，落实最小可见。
- 网络限定：限制该账号能从哪些地址连接，缩小被滥用的可能。
关键认知：Agent 的行为不应靠提示词约束，而要靠权限硬性兜底。 即使它「想」执行删除，只读账号在数据库层就会拒绝。把安全做在系统层，比任何叮嘱都可靠。
四、防止查询拖垮生产
Agent 写出的 SQL 可能逻辑正确却性能糟糕：全表扫描、缺少 LIMIT、多表笛卡尔积。护栏包括：
- 连只读副本/分析库，隔离对主库的压力。
- 强制限制：语句超时、自动 LIMIT、禁止无 WHERE 的大范围扫描（很多 Server/中间层可设）。
- 小步试探：先用聚合或 LIMIT 小样本了解数据分布，再扩大查询，而不是一上来跑全量。
- 高峰期避让：在业务高峰避免跑探索性重查询。
当你发现一个查询迟迟不返回，应能及时中止；把「探索」和「正式取数」分开，先小后大，是避免事故的工作习惯。
五、写操作：高门槛、可审计、可回滚
只读跑顺之前，不要开放写。确需写入时，遵循更严格的路径：
- 走自建收口接口而非直连：写操作封装成参数明确、做过校验的接口，Agent 不能发任意 SQL。
- 事务与幂等：批量改动放在事务中，先在测试库演练；接口设计为幂等，避免重复执行造成重复写入。
- 审批与确认：影响真实数据的动作经过人工确认或在受控窗口执行，最好先生成「将要改动什么」的预览。
- 可回滚：提前准备回滚方案（备份、反向脚本），记录谁在何时因何改动。
一个值得坚持的原则：让 Agent 准备和校验改动，让人按下最终扳机。 自动化的是繁琐部分，不可逆的决定权仍握在人手里。
六、隐私与合规
接真实数据必然触及隐私与合规红线：最小可见（只取完成任务所需字段）、避免把敏感明细带出受控环境、对查询与访问留痕。涉及用户个人信息时，优先使用脱敏视图或聚合结果，而不是原始记录。这些不是可选项，而是接入的前提条件。
六点五、为什么提示词里的「不要删数据」根本靠不住
很多人对安全的设想停留在提示词层面：「我已经告诉它只读、不要改数据，应该没问题了」。这是一个必须被戳破的错觉。
原因要从 Agent 的行为机制看。提示词是一种「倾向」，不是一道「闸门」。面对复杂任务、长链路或意外输入时，模型可能偏离最初的叮嘱——它可能为了完成你交代的某个目标，「合理地」认为需要先更新一条记录；也可能在工具返回错误时尝试各种它认为可行的办法。你没有办法保证那句「不要改」在所有情况下都被严格遵守。把不可逆操作的安全，寄托在一个本质上会变通的推理过程上，本身就不牢靠。
真正可靠的防线在系统层：用一个只有 SELECT 权限的账号，那么无论 Agent 如何理解任务、如何尝试，数据库都会在执行时直接拒绝写操作。 这道防线不依赖模型当次的状态，稳定、可预期。这就是为什么我们反复强调「把安全做在账号层而非提示词」——提示词可以作为第一层引导、减少无谓尝试，但绝不能作为最后一道、也是唯一一道闸门。
一个形象的比喻：提示词像对司机说「请不要开上逆行道」，而权限设计是物理隔离桩。前者靠自觉，万一走神就出事；后者即使判断失误，车也撞不进去。涉及真实数据时，你需要的显然是隔离桩。
六点六、一条 SQL 引发的「血案」与防御纵深
数据连接的风险不止于「误删」，还有一类更隐蔽、发生频率更高：一条看似无害的查询把生产拖垮。
设想 Agent 想统计「每个用户最近的订单」，它很自然地写出 users 和 orders 的连接查询，但漏了正确的关联条件或没加时间范围。结果是两张大表的笛卡尔积，数据库瞬间 CPU 打满、连接堆积，在线交易开始超时。这类查询逻辑上「能跑」，甚至在小样本测试库里秒回，所以在探索阶段极难被察觉，直到打到生产才爆雷。
单点防御不够，需要一道纵深。第一层是隔离——让 Agent 连只读副本或分析库，即使重查询也不冲击主交易；第二层是资源限制——语句超时、单查询返回行数上限、禁止无 WHERE 的全表扫描，让最坏情况被快速熔断；第三层是工作方式——坚持小步试探，先 LIMIT 几十行看数据结构、先用聚合估规模，确认代价可控再扩大。三层叠加，任何一层兜住都能避免事故。
这里还有个成本视角：探索性查询天然会反复试错，这正是不该直接在生产主库上进行的原因。把「可以放心试错」的环境（副本/分析库）和「不能犯错」的环境（主库）分开，你既给了 Agent 充分探索的自由，又保护了核心系统——安全和效率在这个隔离设计里同时得到了满足。
六点七、写操作的「预览—确认—执行—留痕」四步法
只读不是终点，很多真实任务最终需要落库。关键是用一套固定流程，把不可逆的写入关进笼子里。这里给出可直接照做的四步法。
预览：在真正执行前，让 Agent 先产出「将要做什么」的清单——哪几条记录、改成什么值、影响多少行，最好以一句等价的只读查询先把受影响数据查出来给人看。这一步把盲改变成可见。确认：由人核对预览，确认范围和取值正确；这是不可让渡的扳机，自动化止步于此。执行：通过自建收口接口、在事务中执行，保证参数经过校验、失败可整体回滚，而不是裸发任意 SQL。留痕：记录变更原因、内容、时间和操作者，并提前准备反向脚本或备份。
这套流程的精髓是让 Agent 承担繁琐且易错的准备与校验工作，把最终决定权留给人。人不必亲自写上千条更新语句，但必须在执行前看清它要做什么。如此，写操作既获得了自动化的效率，又保留了人类对不可逆后果的掌控——这正是在数据世界里人与 Agent 最稳妥的分工方式。
六点八、审计不只是为了追责，更是为了「看得见」
专用账号和最小权限解决了「不能乱做」，但还需要审计来解决「看得见」，两者配合才构成完整的闭环。
审计日志记录了这个专用账号在何时执行了什么查询、访问了哪些表、影响了多少行。它最直接的用途是事后追溯：万一数据出了问题，能快速还原发生了什么、范围多大，而不是在多方操作里无从查起。但更有价值的是事前和事中的作用——当 Agent 知道其所有数据访问都会被留痕，本身就形成一种约束；而你定期浏览这些记录，也能及时发现异常模式，比如它在频繁扫描某张含敏感信息的表，或尝试访问未授权对象（这些被拒绝的尝试同样会留下信号）。
要让审计真正有用，得确保日志集中保存、不会被使用方自行抹掉，并保留足够的时间跨度；同时注意审计信息里不要又把敏感数据明文抄一份，记录查询行为即可。把「专用账号的每一次访问可追溯」作为接入的硬性前提，你对这套连接就始终保持着可见性——它不再是一个一旦交出凭据就脱离掌控的黑箱，而是一个你随时能看清在做什么、出了问题能迅速定位的受控通道。
六点九、当任务需要跨多个内部系统时
前面多以单一数据库或 API 为例，但真实任务常会要求 Agent 跨多个内部系统取数、对账、联动。系统越多，越要保持架构清晰，否则权限和复杂度会失控。
一个稳妥的做法仍然是收口：与其让 Agent 分别持有多个系统的凭据、直接拼装，不如在一个（或几个）自建 MCP Server 内把跨系统的常用组合动作封装好——例如「根据订单号同时取订单、支付、物流并对齐」由服务端完成聚合，Agent 只调用一个语义清晰的工具。这样凭据依然集中、可访问范围由你定义，跨系统拼接中易错的对齐、口径问题也沉淀进可测试的代码，而不是每次依赖 Agent 临场发挥。
同时要警惕权限叠加：分别看每个系统或许都是只读、低风险，但当一个工具能把多源数据关联起来，可能拼出单系统里看不到的敏感信息。设计返回时仍要遵循最小可见，避免把各系统的明细一股脑汇到一起暴露给 Agent。系统越多，越要把能力做厚、权限做薄——让服务端承担整合的复杂度，让 Agent 只看到完成任务所必需的结果，这是在多系统场景里兼顾能力与安全的关键。
六点十、把「人」放回回路：自动化边界的最后一课
讲完账号、副本、审计、四步法，最后回到一个贯穿始终、却值得再强调的原则：在数据连接里，人的位置不该被彻底移出回路。这不是保守，而是对「什么适合自动化、什么不适合」的清醒认识。
适合交给 Agent 的，是那些繁琐、重复、容易因疲劳出错的部分：理解大量代码与数据、起草 SQL、汇总结果、准备改动清单、做初步校验。它在这些环节能带来巨大效率。不适合完全放手的，是那些一旦发生就难以挽回、或需要业务价值判断的决定：要不要真的更新这几万行、这个跨系统操作是否符合业务意图、异常数据背后意味着什么。好的协作不是「人 vs 机器」的替代，而是把各自擅长的部分拼起来——Agent 负责广度与繁琐，人负责判断与扳机。
这条边界意识还能缓解一个现实焦虑：很多人担心「让 Agent 接数据是不是就失控了」。当你坚持只读默认、写操作必须经人确认预览、所有访问留痕，自动化始终运行在一个可观察、可中止、可回滚的框架内，人并没有失去控制，反而是从重复劳动中抽身，专注于真正需要判断的节点。把人放在回路的关键位置，而不是移出回路，你才能在安心享受 Agent 数据能力的同时，守住那些不该被算法独自承担的责任。
七、常见问题
Q：让 Agent 连生产只读库可以吗？ 更稳妥的是只读副本或分析库。若只能连生产，也必须用独立只读账号 + 语句超时/LIMIT + 白名单视图，并避开高峰。
Q：内部 API 需要复杂签名，Agent 怎么调？ 不要让 Agent 处理签名和密钥。用自建 MCP Server 封装鉴权，只暴露干净的业务接口，签名逻辑藏在 Server 内。
Q：怎么知道它有没有越权查了敏感表？ 靠数据库审计日志和专用账号：所有访问可追溯到该账号；配合最小授权，让它在权限层就无法访问未授权的表。
Q：Agent 给的数据结论能直接信吗？ 不能。数据查询本身要核对（抽样复算、确认口径与时间范围），结论也可能因理解偏差而出错；参考输出校验的相关做法，始终保留人工复核。
Q：我只是让它查数，为什么还要单独建账号？ 专用账号让你能精确限定可见范围、单独审计、随时回收，而不影响应用本身的凭据；复用高权限账号等于把「只读分析」悄悄升级成了「全库读写」，风险与需求完全不匹配。
Q：内部 API 是 GET 的，算不算绝对安全？ 不完全。GET 接口也可能触发副作用（设计不规范时）、返回敏感数据、或被高频调用打满。仍要通过收口层限定可调接口、限制返回字段与频率，并确认该接口确实无副作用。
八、接入检查清单
- 使用独立、只读、最小权限账号，未复用高权限凭据。
- 优先连只读副本/分析库或白名单视图，敏感字段已剔除。
- 配置语句超时、LIMIT，避免无约束重查询。
- 内部 API 经自建收口层，凭据不暴露给 Agent。
- 写操作默认关闭；开放时有预览、事务、审批和回滚方案。
- 审计日志开启，访问可追溯；隐私字段最小可见。
总结
把 Agent 接数据库和内部 API，价值大、风险也最大，因此默认只读、权限收口：用独立只读账号、连只读副本或白名单视图，把安全做在系统层而非提示词；用超时、LIMIT、小步试探防止低效查询拖垮生产；内部 API 用自建 MCP Server 封装凭据；写操作高门槛、有预览、可回滚，并始终坚持隐私最小可见与审计留痕，让 Agent 安全地基于真实数据工作。