给智能体划定自主边界：哪些任务可以自己跑，哪些必须等人确认

把智能体接进工作流之后，最让人心里没底的往往不是它做不好，而是它做得太顺——顺手删了个文件、顺手把草稿发了出去、顺手调用了某个接口。等发现的时候，事情已经发生。自主边界这件事，说到底就是提前想清楚：哪些动作它可以自己跑完，哪些动作必须停下来等人点头。这不是让它变笨，而是让你敢把更长的流程交给它。

先写清楚：它是谁，它能碰什么

边界规则的第一段，不该是“禁止做什么”，而应该是“它是谁、它在哪、它能碰什么”。身份和范围没定清楚，后面所有的确认规则都会变成拍脑袋。

具体落到配置里，至少要写清四件事：

• 身份：这个智能体扮演什么角色，服务谁，代表谁说话。比如“负责整理我个人文档的助理”，而不是笼统的“AI 助手”。




• 可访问范围：它能读取哪些目录、哪些数据源、哪些系统。工作区内的文件可以读，工作区外的默认不碰。




• 可调用工具：它被允许使用哪些工具或接口，哪些只是挂在那里但默认禁用。




• 默认授权档位：第一次接入某个项目时，建议保持较保守的设置，等跑顺了再逐步放开。

这四件事写下来，其实就回答了“它的活动半径有多大”。范围之外的动作，不需要再单独判断风险，直接按越界处理。

有一点容易被忽略：身份描述不只是给智能体看的，也是给你自己看的。当你写下“它代表我对外发消息”时，你会立刻意识到，这类动作的确认门槛必须比“它帮我整理笔记”高得多。

用强制规则把动作分成三档

范围定好之后，真正决定它能不能自己跑的，是动作本身的风险等级。比较实用的做法是分三档：可以直接执行、执行后告知、必须先确认。

可以直接执行的是那些低风险、可逆、影响范围限于内部的重复动作。比如读取工作区内的文件、整理已有资料、生成草稿、做格式转换。这类动作的特点是：做错了也能轻松改回来，不会流到外面去。对这类熟悉的低风险操作，可以适当降低确认频率，否则每步都弹窗，人会被烦到直接关掉确认。

执行后告知适合那些有一定影响但基本可逆的动作。比如修改工作区内的文件、覆盖某个中间版本。它可以先做，但要在日志或消息里留一条记录，让你事后能看到发生了什么。

必须先确认的是三类动作，建议在规则里直接写成硬约束，不给智能体自行判断的空间：

涉及财务的动作——支付、下单、转账、修改价格或额度。这类操作一旦执行，追回的代价远大于确认的成本。

涉及对外发布的动作——发送消息、发邮件、发布内容、上传文件到外部平台。判断标准很简单：这个动作会不会被工作区之外的人看到。会，就必须确认。

涉及敏感数据的动作——读取工作区外的文件、导出或上传包含个人信息的资料、把内部数据传给外部工具。数据一旦离开可控范围，就很难收回。

还有一类值得单独列出来：删除、覆盖、执行命令。这些动作的共同点是不可逆或影响面不确定，即使看起来只是删一个临时文件，也建议保留人工确认。

把这三档写进配置时，尽量用“动作类型 + 条件”的句式，而不是模糊的形容词。写“删除工作区内任何文件前必须确认”，比写“谨慎处理删除操作”有用得多，因为前者可以被执行，后者只能被理解。

一份边界清单的撰写模板

上面两块内容合起来，就是一份可以照着填的边界清单。不需要写得很长，但要覆盖到位。可以按这个顺序起草：

第一部分，身份与范围。 用一两句话写清角色、服务对象、可访问的目录和数据源、可调用的工具清单，以及首次接入时的默认授权档位。

第二部分，自主执行清单。 列出允许它自己跑完的动作，尽量具体到动作类型和对象范围。写完检查一遍：这些动作如果出错，是不是都能轻松回退？

第三部分，执行后告知清单。 列出可以先做但要留记录的动作，同时说明记录写到哪里、你多久看一次。

第四部分，强制确认清单。 把财务、对外发布、敏感数据、删除覆盖这几类动作逐条写出来，每条都带上触发条件。这一部分宁可写细一点，也不要留模糊地带。

第五部分，升级与例外。 写清楚什么情况下它应该停下来问你，而不是自己想办法绕过。比如遇到规则没覆盖的动作、连续失败、或者需要访问范围外资源时，默认动作是暂停并询问。

写完这份清单，可以拿几个真实场景过一遍：让它整理一次会议记录、让它根据模板生成一份报价、让它把结果发给客户。三个场景分别落在哪一档，如果答案清晰，说明规则基本可用；如果某个场景让你犹豫，那就是需要补写的地方。

边界不是一次写完就固定的东西。刚开始可以保守一点，把确认范围划大；跑一段时间后，把那些确实低风险、又频繁触发的动作往下调一档。反过来，如果某次确认让你发现了一个之前没想到的风险点，就把它补进强制确认清单。

真正好用的自主边界，不是把智能体管得死死的，而是让你在放开手的时候，心里清楚哪几根线它不会碰。