第 01 模块 · 3 节

工具集成与权限设计

《Codex 生产级工程》01 自定义 Agent 构建 · 本节时长 36 分钟

给 Agent 能力,也要给它「锁」

自定义 Agent 要对接内部系统才有价值——能查订单、能读报表。但能力给了它,就必须同时管住它。这一节讲工具集成与权限设计:能用的给够,危险的锁死。

贯穿项目这一节给 deploy-bot「接手」也「上锁」:它要连 git、部署 CLI、云平台、通知这些工具才能干活,但也正因为它能碰部署,权限必须设计到「最危险的操作一个都越不过去」。

工具集成:给 Agent 它需要的「手」

先想清:这个 Agent 完成任务,需要接哪些内部系统

Agent 任务 需要的工具
工单处理 工单查询接口
订单查询 订单查询接口
报表分析 数据查询接口

只接它完成任务需要的工具,别的别接。多一个工具,多一分风险。

deploy-bot 需要的「手」,是最小集:

deploy-bot 任务 需要的工具
拉取代码 git
执行部署 部署脚本 / 云平台 CLI
上报结果 通知接口(IM/邮件)

至于查询业务数据库、改用户数据、访问内部报表——一个都不接。它部署要用到的凭据另配,跟其它系统完全隔离。


权限设计:能碰的给,不能碰的锁

权限的核心是「最小权限」——恰好够用,不多给一分:

  • 能读的:允许查询的数据
  • 不能读的:隐私、无关数据 → 锁死
  • 能操作的:只读?还是能改?能改到哪?
  • 不能操作的:改状态、删数据 → 锁死
订单查询 Agent
能:查询订单状态、发货进度
不能:修改订单、访问客户完整隐私、删除记录

deploy-bot 的权限,是「部署机器人」里最该抠细节的:

deploy-bot 权限设计
能:读 git 仓库;执行 staging/production 部署脚本;查部署状态;触发回滚
不能:读写生产数据库;删除任何线上数据;直接改服务器配置;越权访问无关环境
凭据:staging 与 production 用独立密钥,production 密钥单独保管、门禁通过才注入

权限的常见分级

按操作类型分级,越往右越要严:

只读查询 → 写操作 → 敏感/删除操作
  低风险        中风险         高风险
  可放开        需把关         必须锁/确认

风险越高,权限越严,是铁律。

对 deploy-bot,这个分级直接决定了它能不能「自主部署生产」:staging 属于「中风险,可把关放行」,production 属于「高风险,必须门禁 + 确认」。别让它在只该部署 staging 的场景里就拥有生产权限。


一个实践清单

给 Agent 配权限时,过一遍:

  • [ ] 只接它完成任务需要的工具?
  • [ ] 只给最小必要的权限?
  • [ ] 读/写分开,写操作严格把关?
  • [ ] 敏感/删除操作锁死或需确认?
  • [ ] 权限边界写进配置了?
  • [ ] 高危环境的凭据单独保管、按需注入?

一个「权限映射」落地例子

把上面的权限设计落成一眼能查的表,运维和 Agent 都好对齐:

操作 staging production 凭据
拉取 git 代码 只读 token
执行部署脚本 门禁通过才可 staging 独立 key
跑测试 / 构建 无敏感凭据
改 / 删数据库
回滚到上一版 需人工确认 production 独立 key

这张表,就是 deploy-bot 权限的「说明书」。权限不是拍脑袋配的,是列成表、逐项核对、跟着任务走的。


常见误区

  • 图省事全接全开:工具权限一把全给,风险最高
  • 接了能改的:查询 Agent 却给写权限,危险
  • 权限不跟任务走:任务变了,权限没收

权限要跟着任务和风险走,够用就好,绝不贪多。

对 deploy-bot 还有个典型误区:把生产权限当成「工作必须」一开始就全给。其实它完全可以先只拥有 staging 权限跑通流程,等验证稳定了,再用「门禁通过才注入生产密钥」的方式放开——权限是能「分级分步给」的。


常见坑:给 Agent 的密钥「一把共享」,越权无从追究

最危险的坑之一,是给 Agent 一把「能碰所有环境的万能密钥」。

真实场景:你把同一个部署密钥给了 deploy-bot,这个密钥既能部署 staging 又能部署 production。有一天 deploy-bot 因为配置写错,把 staging 的改动直接推到了生产。你事后想查「是哪个环节越的权」,却发现权限根本没法区分——因为它本来就都打得开。

为什么:权限和风险不分级,一旦出事就既拦不住、也查不清。共享高权限密钥让「最小权限」彻底失效。

怎么破:staging 和 production 用独立密钥;production 密钥放平台 Secret,只有门禁通过才注入;部署脚本里明确区分环境参数,禁止「不指定环境就部署」。让每次越权都「够不到」,而不是「靠自觉」。


小结

  1. 工具集成:只接完成任务需要的,多一个多一分险
  2. 权限设计:最小权限,能碰的给、不能碰的锁
  3. 风险分级:只读放开、写把关、敏感锁死
  4. 过一遍权限清单,权限跟任务走
练习给 deploy-bot 列出工具清单和权限边界。①三步走:a. 列出它完成任务最少需要的 3 个工具;b. 给 staging 和 production 各定一套「能/不能」;c. 用「图省事全接全开」的反面清单自检一遍。②怎么判断做对了:工具清单里没有一件「跟部署无关」的东西;staging 和 production 权限明显不同、production 更严;明确写了「不碰数据库、不删数据」。③卡住了怎么办:不确定某个工具该不该接,就问「没有它能不能完成部署」——能完成就别接;production 权限不知道怎么收,就先只给 staging,让它先跑通。

下一节,讲 Agent 的调试与迭代。