你可能已经听过这个故事：一位Meta高管让风靡一时的OpenClaw人工智能工具筛选她的收件箱并建议删除哪些邮件，随后惊恐地看着这个智能体失控，一口气删除了200多封邮件，而她疯狂输入的“停止OpenClaw”指令淹没在机器人庞大的操作中。
转折点在于？这位高管正是Meta的首席人工智能安全官Summer Yue。
Summer Yue的邮件灾难事件，突显了一种我们可以用来防止类似智能体人工智能恐怖故事的方法。
没错，Summer Yue在无意中让自己成了OpenClaw及其失控自动化操作的“小白鼠”——事实上，目前几乎所有使用OpenClaw的人都是“小白鼠”。
但Summer Yue的邮件灾难也揭示了一种我们可以预防类似智能体人工智能恐怖故事的方法，而且这种方法大多数程序员——甚至许多非技术人员——都已经很熟悉了。
它有不同的名称；例如，我听过有人称之为“智能体Git工作流”或“智能体功能分支”。但核心在于，将“Git”——那个用于追踪代码变更的命令行工具——的方法论应用到人工智能智能体上。
这个解决方案最棒的部分是什么？它让我们可以“鱼与熊掌兼得”（“熊掌”指的是人工智能智能体所能完成的超酷任务）。
鸡肉、鱼肉与OpenClaw
首先，来一个思想实验。假设你在餐厅，菜单上有两道菜：鸡肉或鱼肉。鸡肉听起来不错，但鱼肉——三文鱼！真是艰难的选择。
想象一下，与其冒着选鸡肉而不选鱼肉可能带来的代价高昂的错误风险（万一鸡肉变质了呢！），你可以创建一个你“即刻未来”的“分支”——一个时间线的临时副本，让你在永久做出选择之前先测试一下。
于是，你创建（或“检出”）了你“主”生命线的一个新分支——我们称之为“鸡肉分支”——然后你点餐并品尝了鸡肉。呃！真难吃。
没问题；我们丢弃这个“鸡肉分支”，回到“主”分支，然后检出第二个新分支——“鱼肉分支”。现在我们品尝三文鱼——美味！我们喜欢这个“鱼肉分支”，于是将其与我们的“主”生命分支合并，然后开始享用这顿保证美味的餐点。
在Git的代码追踪世界里，我们将这个功能（我描述得比较粗略）称为功能分支，它是一种巧妙的、久经考验的方法，可以在将重大变更和新功能提交到主项目之前进行测试。
Git中的功能分支实际上就是“主”分支的一个副本。我们像从图书馆借书一样检出它，进行所有想要的修改，测试它，发现漏洞，进行更多修改，等等。与此同时，我们项目的“主”分支始终安全且未被触及。
只有在我们对功能分支进行了一系列测试——有些是自动化的，有些由人类用户执行——并确定其状态完美无缺之后，我们才会考虑将“功能”分支合并到主分支。如果我们不喜欢功能分支的进展，可以直接丢弃它——无伤大雅，没有损失。
我的观点是什么？这种代码分支方法论同样适用于人工智能智能体。（当然，我并非第一个考虑这个想法的人。）
本可以如何做得更好
让我们回到Summer Yue的案例，试试我们的“分支”场景。这一次，Summer Yue坐下来使用OpenClaw，并给出指令：“浏览我的收件箱并建议删除。”（在真实故事中她的另一条指令——“等待批准”——很可能因为OpenClaw需要处理海量邮件而被挤出了其上下文窗口。）
现在，OpenClaw没有直接进入真实的收件箱，而是创建了一个分支——称之为“筛选分支”——使其能够在沙盒环境中模拟筛选、整理和清理她收件箱的结果，整个过程都不会触及她实际的邮件。
OpenClaw开始工作，可能一时兴起，开始随意删除邮件。如果发生这种情况，Summer Yue只需查看“筛选分支”，决定对结果不满意，然后要么丢弃该分支，要么继续与之协作，测试OpenClaw指令的不同版本，或者添加用Markdown格式编写的“脚手架”文档，从一开始就指导OpenClaw的行为。与此同时，她真实的收件箱安然无恙。
那么，这种“功能分支”方法适用于所有人工智能智能体场景吗？可能不行。将分支化的计算机代码放入沙盒并安全测试任意数量的操作和结果是很容易的。但就像你无法真正将“鸡肉还是鱼肉”的选择放入沙盒一样，现实世界中也有许多人工智能智能体的操作和角色（例如，专注于人力资源的人工智能智能体）不容易被模拟。
尽管如此，如果我们不认真对待这个“智能体功能分支”的想法，更多——可能更可怕的——类似Summer Yue那糟糕透顶、非常糟糕的邮件日子的版本将会再次发生。
