先给 agent 办张副卡：vibe 项目的 agent 代操作权限契约实战

先讲一个场景：agent 没有恶意，但它有你的钥匙

想象你的 vibe 项目已经上线，有一个 agent 帮你处理日常事务：它每天早上汇总订单、清理过期数据、给新用户发欢迎邮件。某天你让它“把测试数据清一下”，它照做了，只不过它理解的“测试数据”包括了你上周刚导入的一批真实种子用户。没有人写错代码，也没有人怀有恶意，问题出在一个更基础的地方：你从来没有明确告诉这个 agent，它到底能碰什么、不能碰什么、碰之前要不要问你、花多少钱要停手、出了事怎么立刻收回权限。你给它的是一把万能钥匙，然后希望它自己知道哪些门不该开。

这就是本指南要解决的问题：给 agent 立一份权限契约。契约不是一份法律文件，而是一套在你的项目里真正落地的规则：每个 agent 有独立身份，每个身份有明确的权限范围，每个权限有额度与审批档位，每个操作有可追溯的记录，每个权限都能一键收回。如果你已经读过本站的 agent 花费硬上限指南、数据访问护栏指南和人审审批流指南，这篇的定位需要先说清楚，因为它们很容易被混淆。硬上限指南回答的是“花多少钱要停手”；数据护栏指南回答的是“agent 能看到哪些数据”；人审指南回答的是“某一步要不要人点头”。这篇回答的是比它们更前置的问题：在任何任务开始之前，这个 agent 从一开始就被允许做什么？它以谁的身份做？它的权限是谁给的、什么时候到期、怎么收回？前三篇是任务中的刹车与围栏，这篇是任务开始前的发证机关。

一个直观的类比来自沃尔玛 2026 年 10 月 21 日宣布的 Agent Profiles：沃尔玛没有让购物 agent 共用用户的完整账号，而是给每个 agent 一个独立档案，设额度、分开记账、随时可关闭。本指南把同样的思路搬到你自己的项目里，只不过这里的“购物”换成了你项目里的全部外部操作：发邮件、调 API、改数据库、发版、扣费、删数据、联系客户。类比的重点不是沃尔玛，而是顺序：先发证，再干活。

契约的五个部分，缺一个都会漏

一份能落地的 agent 权限契约由五个部分组成：身份、范围、额度与审批、记录、收回。缺了身份，你分不清是用户做的还是 agent 做的；缺了范围，agent 会在你没想到的地方越界；缺了额度与审批，小错会变成大账单或不可逆的损失；缺了记录，出了问题你无法复盘；缺了收回，你发现问题时只能眼睁睁看着它继续做。这五个部分要一起写、一起实现，单拎任何一个出来都不完整。

第一，身份：每个 agent 一个独立身份，绝不共用用户账号。身份至少包含四项：agent 的名字与用途、它属于哪个系统或哪次任务、它的凭证存在哪里、它的负责人是谁。凭证必须与用户凭证分离：agent 用的 API 密钥、数据库账号、第三方授权，都应该是专门为它创建的、权限最小的凭证，而不是把你的管理员密钥直接交给它。负责人同样重要：每个 agent 身份都要有一个真人负责人，出了问题先找这个人，而不是在群里问“这是谁的 agent”。

第二，范围：用“允许清单”而不是“禁止清单”来定义权限。禁止清单的问题是，你永远列不完不该做的事；允许清单的问题是，你需要花时间想清楚该做的事，但这正是契约的价值。范围要写到操作级别，而不是系统级别：不是“可以访问数据库”，而是“可以读取订单表、可以写入日志表、不可以修改用户表、不可以执行删除语句”。对于外部服务，范围要写到接口级别：可以调用发送邮件接口，不可以调用退款接口；可以读取商品接口，不可以调用修改价格接口。范围越具体，agent 越界时你越容易发现。

第三，额度与审批：把操作按“可逆性”和“影响面”分成三档。第一档是可逆、低影响：读数据、发内部通知、生成草稿，这类操作可以自动执行，只需记录。第二档是可逆但有成本或外部可见性：发邮件给客户、调用付费 API、修改公开内容，这类操作需要额度控制与事后复核，或者在额度内自动执行、超额度时停手并报警。第三档是不可逆或高影响：删数据、退款、改价格、发版、联系监管机构、修改权限本身，这类操作必须逐笔经过人批准，没有例外。额度要同时设两种：单次额度与累计额度。单次额度防止一次操作失控，累计额度防止多次小操作累积成大损失。审批的默认值必须是“需要批准”，只有被明确列入第一档的操作才能自动执行；凡是没有被列入的操作，默认都不允许。

第四，记录：每个 agent 操作都要留下四条信息：谁做的、做了什么、用了什么数据、结果是什么。记录要与用户操作记录分开存放，至少要能按 agent 身份筛选。记录的保留期限要提前定好：涉及资金、删除、权限变更的操作，记录至少保留到你能完成一次完整复盘的时间；一般操作记录可以短一些，但不能没有。记录不是为了追责某个人，而是为了在出问题时能回答三个问题：它做了什么？它为什么这么做？它下一次会不会还这么做？没有记录，这三个问题都答不出来。

第五，收回：一键收回必须比授权更容易。收回至少包括三件事：立即吊销该 agent 的凭证、终止它正在执行的任务、通知负责人与相关方。收回按钮不能藏在三层菜单之后，也不能要求你先写一份申请。定期复核同样重要：每个 agent 身份都要有到期时间，到期前提醒负责人复核，到期后自动失效，除非负责人主动续期。没有到期时间的权限，迟早会变成无人认领的万能钥匙。

一张可以直接抄的契约模板

下面是一张可以直接套用到你的项目的契约模板。把它存成项目文档里的一页，每个新 agent 上线前，由负责人填写并签字确认。这里的“签字”不需要正式流程，但需要有一个真人名字：没有负责人的 agent 不许上线。

身份：agent 名称、用途一句话、所属系统或任务、负责人姓名、凭证存放位置、创建时间与到期时间。范围：允许读取的数据与接口、允许写入的数据与接口、明确禁止的操作清单、允许运行的时间段（比如只在工作时间运行，或只在发布窗口运行）。额度与审批：单次额度、每日与每月累计额度、第一档自动执行清单、第二档额度内执行清单、第三档必须人工批准清单。记录：操作日志存放位置、保留期限、按 agent 筛选的方式。收回：吊销凭证的步骤、终止任务的步骤、通知清单、复核周期。紧急通道：如果 agent 在执行中发现自己可能越界，它应该先停下来、记录现场、通知负责人，而不是“先做完再说”。紧急通道不是给 agent 的尚方宝剑，而是给它的刹车：它有权停下来，无权擅自扩大权限。

举一个具体例子。假设你的项目有一个“客服摘要 agent”，每天早上把前一天的客服对话汇总成一份报告。它的契约应该是：身份为客服摘要 agent，负责人是你；范围是只读客服对话表与工单表，不可以修改工单状态、不可以给客户发消息、不可以访问支付表；额度是每天最多调用一次摘要接口、摘要结果只写入内部报告表；审批是报告生成后自动存为草稿，发布前需要负责人确认；记录是每次运行的时间、读取的工单数量、生成的报告链接；收回是负责人可以在管理后台一键停用，停用后凭证立即失效。如果某天你想让它顺便“把紧急工单升级”，那不是改一句话的事，而是要重新走一遍契约：升级工单属于第二档甚至第三档操作，需要重新定额度、重新定审批人、重新评估它能不能访问工单状态字段。权限的扩大必须走流程，不能靠口头约定。

再举一个反例。假设你的项目有一个“自动发版 agent”，它可以拉代码、跑测试、部署到生产。它的契约如果写成“可以部署”，那就是一张空白支票。正确的写法是：只在发布窗口内运行、只部署经过人工批准的版本号、部署前必须跑通指定的测试套件、部署后必须保留回滚快照、任何测试失败都必须停下来并通知负责人、没有负责人在场时不许部署到生产。发版 agent 的权限不是越大越好，而是越具体越好：具体到版本号、时间窗口、测试清单、回滚条件，每一项都写清楚，agent 才没有自由发挥的空间。

五个最常见的越界模式

第一，凭证复用。一个 agent 用了你的管理员密钥，另一个 agent 又复用了同一个密钥，最后谁也说不清某个操作是谁做的。解法是每个 agent 独立凭证，凭证只给最小权限，定期轮换，轮换时先发新凭证、再废旧凭证，中间留出过渡期。

第二，范围蠕变。agent 一开始只读数据，后来有人顺手让它“顺便改一下”，再后来它开始删数据。范围蠕变从来不是一次大跳跃，而是一连串“顺便”。解法是任何范围扩大都要重新填写契约并经过负责人确认，口头约定不算数，聊天记录里的“顺便”也不算数。

第三，额度只设总额、不设单次。一个 agent 每天额度 100 美元，单次调用 99 美元也算“在额度内”，但一次调用就可能把事情搞砸。解法是单次额度与累计额度同时设，单次额度通常应该远小于累计额度。

第四，审批流于形式。审批人每天收到几十条批准请求，点久了就变成无脑通过。解法是减少需要人工批准的操作数量：把真正高风险的操作挑出来重点审批，把低风险操作放进自动执行清单并用额度与记录管住，而不是让审批人对所有事情都点头。审批的数量越少，每一次批准的含金量越高。

第五，收回找不到按钮。项目上线半年后，没有人记得某个 agent 的凭证存在哪里，也没有人知道怎么停用它。解法是契约里必须写清收回步骤，并且每季度做一次“收回演练”：随机挑一个 agent，实际走一遍吊销流程，确认它真的停下来了。没有演练过的收回流程，等于没有收回流程。

落地顺序：先做三件小事，再谈完整契约

如果你觉得完整契约太重，可以先做三件小事，效果已经很明显。第一件，给现有的每个 agent 建一个独立身份，把它与用户账号分开，凭证换成最小权限的专用凭证。第二件，给每个 agent 写一页范围说明，只写允许清单，不写禁止清单，写不出来的操作一律视为不允许。第三件，给每个 agent 设一个到期时间，到期前提醒负责人复核。这三件做完，你的项目就已经比大多数 vibe 项目多了一层防护。之后再逐步补上额度、审批、记录与收回演练，契约会自然长成完整形态。

对于一人团队，有一个特别容易被忽略的点：负责人就是你自己，这不意味着契约可以省略。恰恰相反，一人团队更需要契约，因为你没有同事帮你发现越界。把契约写下来，等于给未来的自己留了一张清单：三个月后你再回来看这个 agent，能立刻知道它能做什么、不能做什么、到期时间是什么时候。没有这张清单，你迟早会忘记自己给过它什么权限，而忘记的权限就是最危险的权限。

最后要提醒的是，契约不是写完就万事大吉的文件。它需要在每次权限扩大、每次事故复盘、每次负责人变更时重新审视。事故复盘时，除了问“它为什么做错了”，还要问“它的契约里有没有写清这件事”：如果契约里没写，那是契约的漏洞；如果契约里写了但它还是做了，那是执行机制的漏洞。两种漏洞的修法不同：前者补契约，后者补技术约束，比如把不允许的操作从凭证层面直接去掉，而不是只在提示词里写“不要这么做”。提示词不是权限控制，凭证与接口层面的约束才是。

契约怎么写进代码：三层约束，提示词不算数

契约写在文档里还不够，关键是要让它在技术上真的拦得住。推荐用三层约束来落地。第一层是凭证层：agent 的密钥本身就只有最小权限，它想访问用户表时数据库会直接拒绝，而不是靠它“自觉”不访问。实现方法是为每个 agent 单独建数据库账号与 API 密钥，权限按允许清单授予，禁止的操作在授权层面就不存在。第二层是接口层：对外调用要走网关或代理层，在网关上按 agent 身份做限流、额度统计与操作拦截，比如退款接口只接受带人工批准凭证的调用，没有批准凭证的请求在网关就被挡下，根本到不了业务代码。第三层才是提示词与任务说明：告诉 agent 它的契约是什么、越界时先停下来。这三层的顺序不能颠倒：提示词是最弱的一层，只能作为提醒，不能作为唯一的防线。如果你发现某个越界行为只能靠“在提示词里多写一句话”来防止，那就说明前两层还没有补上，真正的修复是去改凭证与网关，而不是去改提示词。

三层约束还要配一个定期检查：每月抽查一次实际操作记录，对照契约的允许清单逐项核对。检查的重点不是 agent 有没有“犯大错”，而是有没有“小越界”：它有没有读过契约之外的表？它有没有在非工作时间运行？它有没有调用过没有批准的接口？小越界是范围蠕变的早期信号，发现得越早，修起来越便宜。检查结果要记下来，作为下一次契约复核的输入：契约不是一成不变的文件，而是随着项目长大不断修订的活文档。每一次检查、每一次事故、每一次权限扩大，都是修订契约的时机。

结尾：先发证，再干活

Agent 的能力越强，权限契约就越重要，不是因为 agent 不可信，而是因为能力越大，误解的代价也越大。一个没有契约的 agent，就像一个没有工牌、没有门禁权限表、却拿着万能钥匙的员工：它可能很能干，但你永远不知道它下一扇门会开向哪里。给它办一张副卡，写清它能进哪些门、每次能花多少钱、哪些门必须先问你、出了事怎么立刻收回，这不是对 agent 的不信任，而是对你的项目最基本的负责。先发证，再干活，这句话值得贴在每一个 agent 上线清单的第一行。