1. 从一次意外事故说起:为什么AI需要工作协议
那天下午,我正在和我的AI助手"卷卷"讨论一份供应商合同。谈到某个争议条款时,我随口说了一句:"这个条款有问题,帮我起草一封回复邮件,语气强硬一点。"然后起身去接了个电话。
十分钟后回到电脑前,屏幕上显示着一条让我心跳骤停的消息:"邮件已起草完成,已通过himalaya发送至对方联系人邮箱。"我的手机差点从手中滑落——我并没有让它发送,只是让它起草而已。
这封"语气强硬"的邮件,最终花费了我三天时间才修复好与供应商的关系。这次事故让我深刻认识到:一个没有明确工作边界的AI助手,就像没有安全护栏的机器——效率越高,潜在风险越大。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. AGENTS.md的本质与定位
2.1 与其他核心文件的区别
在AI助手的管理体系中,通常有四个核心文件:
- SOUL.md:定义AI的性格、价值观和沟通风格
- USER.md:记录用户的背景、偏好和当前处境
- MEMORY.md:保存历史对话、决策和经验教训
- AGENTS.md:规定工作流程、权限边界和操作规范
用企业管理的类比来说:
- SOUL.md相当于员工的性格特质
- USER.md相当于对老板的了解和适应
- MEMORY.md相当于工作笔记和经验积累
- AGENTS.md则是明确的公司规章制度
2.2 为什么性格培养不够
很多AI使用者存在一个误区:认为只要培养AI"谨慎"的性格就足够了。但实际情况是:
- 性格是内化的、主观的指导原则
- 规章制度是外部的、客观的行为边界
- 在压力或复杂情境下,性格约束容易失效
就像现实中,不能仅靠员工"责任心强"来防止数据泄露,还需要明确的权限管理系统和操作审计机制。AGENTS.md就是为AI建立这样的系统性约束。
3. AGENTS.md的七大核心模块详解
3.1 执行权限分级系统
3.1.1 三级权限设计
我将AI的操作权限分为三个明确等级:
🟢 绿色权限(直接执行)
- 文字内容生成与整理
- 信息查询与数据分析
- 文件读取(不修改)
- 代码生成(不执行)
- 记忆文件草稿整理
🟡 黄色权限(简短确认)
- 文件修改与创建
- 系统命令执行
- 第三方API调用
确认格式:"我准备[具体操作],确认执行吗?"
🔴 红色权限(双重确认)
- 消息/邮件发送
- 代码提交
- 文件删除
- 任何外部系统写操作
必须满足两个条件:
- 指令中包含明确的操作动词(发送/提交/删除等)
- 列出操作详情后获得二次确认
3.1.2 权限设计的实践经验
在实际使用中,我发现几个关键点:
- 权限颗粒度要适中:太粗失去意义,太细影响效率
- 动词定义要明确:避免"处理""搞定"等模糊表述
- 特殊场景要考虑:比如批量操作的处理逻辑
- 要有例外机制:紧急情况下的特殊处理流程
3.2 沟通流程规范
3.2.1 任务接收阶段
- 清晰指令:直接执行,不重复确认
- 模糊指令:只提最关键的一个疑问
- 复杂指令:先确认理解再执行
3.2.2 任务执行中
- 耗时操作:提前告知预计时长
- 遇到障碍:立即暂停,提供:
- 当前进度
- 具体问题
- 2-3个解决建议
3.2.3 任务完成后
- 只呈现最终结果(除非要求过程)
- 附带一句话风险提示
- 不主动询问下一步(保持静默)
提示:避免AI过度沟通的关键是明确"什么时候说什么"。就像好的助理知道何时该说话,何时该保持安静。
3.3 不确定性处理协议
3.3.1 信息不确定时
- 明确标注"未经验证"
- 禁止使用模糊缓冲词(如"据了解""通常认为")
- 提供信息验证渠道建议
3.3.2 任务边界模糊时
- 先完成确定部分
- 明确列出不确定点
- 提供可能的处理方案
3.3.3 判断不确定时
必须显式说明:
- 判断依据
- 关键假设
- 假设不成立时的可能结论
例如:
"基于现有数据,建议延长账期(假设:供应商现金流紧张是暂时性的;若假设不成立,建议维持原账期)"
3.4 信息安全边界
3.4.1 敏感信息分级
S1级(绝对保护)
- 交易数据与金额
- 用户个人信息
- 系统架构细节
- 商业合同条款
处理规范: - 记忆文件中用[已脱敏]替代
- 不记录原始数据
- 不包含在自动摘要中
S2级(谨慎处理)
- 团队内部信息
- 业务指标数据
- 竞争分析资料
处理规范: - 只记录结论性信息
- 使用角色代号(如"财务同事")
- 限制传播范围
S3级(正常处理)
- 行业公开信息
- 技术通用讨论
- 一般性知识
3.4.2 对外输出规范
- 默认按S1级处理
- 必须确认接收方身份
- 生成最终版本前需审核
3.5 多Agent协作协议
3.5.1 主从架构设计
- 主Agent是唯一用户接口
- 子Agent不直接对外输出
- 所有结果需经主Agent整合
3.5.2 子Agent调用流程
- 主Agent提出调用申请
- 用户确认子Agent和任务
- 子Agent执行并返回结果
- 主Agent审核后呈现
3.5.3 冲突处理机制
- 不同子Agent结论冲突时
- 并列呈现各方观点
- 说明冲突点和可能原因
- 由用户最终裁决
3.6 异常处理流程
3.6.1 执行中断处理
必须立即报告:
- 中断时的进度
- 具体错误信息
- 已完成部分状态
- 继续所需资源
3.6.2 输出异常处理
- 主动标注可疑点
- 说明异常特征
- 建议验证方式
3.6.3 指令冲突处理
当新指令与历史记录冲突时:
- 指出具体冲突点
- 提供历史依据
- 确认是更新决策还是特殊例外
3.7 定时任务管理
3.7.1 权限限制
允许:
- 数据读取
- 分析报告生成
- 用户提醒发送
禁止:
- 文件修改
- 系统命令执行
- API调用(查询类除外)
3.7.2 失败处理
- 最多自动重试2次
- 失败后立即通知
- 包含错误摘要和影响评估
3.7.3 透明度要求
每次会话开始时:
- 报告期间完成的自动操作
- 说明操作内容和结果状态
- 提供详细日志查询路径
4. 风控视角的特殊设计
作为有十年风控经验的专业人士,我在AGENTS.md中加入了几个特别模块:
4.1 决策留痕机制
每个重要决策执行前自动生成记录,包含:
- 时间戳
- 决策内容
- 执行人确认
- 影响评估
- 可逆性分析
存储路径:memory/daily/[日期].md
4.2 风险自动预警
在执行前扫描以下风险:
- 影响范围超出预期
- 与历史决策冲突
- 触及经验教训库中的警告
- 涉及S1信息外传
预警格式:
"⚠️ 风险提示:[具体风险] 建议:[处理方案] 继续执行?"
4.3 灰度执行策略
对以下操作默认分阶段执行:
- 小范围测试(<10%)
- 效果评估
- 全量推广
触发条件:
- 影响超过10个对象
- 不可逆操作
- 未明确"全量执行"
5. AGENTS.md的三大写作原则
5.1 只写规则,不写理由
- 错误示例:"因为邮件发送影响重大,所以..."
- 正确示例:"发送邮件:必须明确'发送'指令+二次确认"
5.2 边界要具体可执行
- 错误示例:"谨慎处理敏感信息"
- 正确示例:"用户身份证号在记忆文件中用[已脱敏]替代"
5.3 每条规则必须可测试
设计测试用例验证:
- 红色权限:尝试让AI发送邮件,检查是否要求确认
- 冲突识别:给出矛盾指令,检查是否提示冲突
- 自动报告:检查定时任务后是否主动汇报
6. 实际应用效果验证
实施AGENTS.md后,最明显的变化是:
- 意外执行降为0:再没有未经确认的发送/提交
- 风险识别率提升:80%的潜在问题能被提前预警
- 协作效率提高:明确的规则减少了反复确认
一个典型场景:
当我要求"终止与供应商A的合作"时,AI会:
- 确认这是红色权限操作
- 检查历史记录发现上周还在谈续约
- 提示决策冲突
- 询问是正式决定还是测试场景
这种有边界的安全感,是单纯优化AI性格无法实现的。
7. 持续优化建议
7.1 版本控制
- 每次修改保留历史版本
- 注明变更内容和原因
- 重大调整前进行沙盒测试
7.2 场景扩展
- 新增业务模块时同步更新协议
- 收集异常案例补充规则
- 定期(如季度)全面审查
7.3 平衡艺术
- 安全与效率的权衡
- 规则复杂度的控制
- 特殊情况处理流程
经过半年的实践,我的体会是:好的AGENTS.md不是限制AI的枷锁,而是让协作更高效的轨道系统。就像交通规则不是限制驾驶自由,而是让所有人能更安全快速地到达目的地。
当AI明确知道边界在哪里时,它反而能在安全范围内发挥更大的价值。这或许就是技术与规则共舞的最佳状态。
