OpenClaw 测试团队实践(二)

决定自己下场之后,我做的第一件事,是把 OpenClaw 装到自己的电脑上。

资料这一关其实已经过了——博客、官网、几个 up 主的视频,我都过了不止一遍;Agent 的人格、记忆、skill、上下文这几块,我也断断续续看了一阵。但我一直清楚一件事:Agent 这种”能动我电脑”的新技术,资料看完只是准备阶段。

那天晚上从七点开始上手,到十点,demo 一个都没跑出来。那一晚我大部分时间都在回答这几件事:这玩意儿,我到底该给它开多大权限? 哪些命令自动放? 哪些数据不该让它碰?

 一、资料过完,不等于上手

接新技术前,我习惯先把官网、博客、视频过一遍,搭好心智模型,再上手。这套打法,过去十几年都是奏效的。

Agent 这件事,我看的资料比平时还多。除了入门,Harness 那几本书我也专门看过,人格、记忆、skill、上下文这几块翻来覆去地看,边看边记笔记。

但我也清楚:资料过完不代表上手。资料告诉我「这件事的边界在哪个方向」,上手才能告诉我「我自己这台电脑上,边界画在哪条线」。

这次跟以往那些技术(Jenkins、K8s、测试方法论)不一样的地方,在于 Agent 会真的动我的文件、动我的命令行、动我的数据。经过我的学习,我认为有四个问题需要自己实践理解——纸上得来终觉浅,绝知此事要躬行,只有自己亲自上手,才知道这条河的水到底有多深。

二、四个问题的实践

视频几乎全在讲”功能”和 happy path:喂一个需求,它生成漂亮的用例;丢一段日志,它给你分析得井井有条。但真正决定一个 Agent 能不能在我工作流里活下来的,是这些视频从不讲的东西。

第一件:权限边界

让 Agent 在我们工作电脑或个人电脑上跑,需要回答的第一个问题就是权限问题。随着Agent的能力越来越多，关于Agent安全的讨论和新闻也越来越多。我们都不希望它拿我们的个人数据去训练。它能访问哪些目录? 是只开一个工作文件夹,还是整个 D 盘? 它要读项目资料,需不需要再放开 C 盘里某些位置? 放得太大,如何确保我们的信息安全;放得太小,它连最简单的任务都干不了。

最终我的选择是给它一个工作文件夹的权限，就是常用的 workspace概念，在任务执行过程中，需要什么资料我再提供什么资料，虽然麻烦一点，但是安全是底线。

第二件:命令执行

Agent 要装包、要跑脚本,会向我要”执行命令”的权限。给不给?

由于前面已经确定只能访问工作目录，所以这里便不再纠结于文件的读写属性，而是将防线划在了“进程调用”上。策略很直接：所有工作目录内的文件操作（读/写/编辑）全部自动放行，只要它老老实实待在数据层；但只要涉及“执行命令”（哪怕是看似无害的 ls或 dir），一律挂起等待确认。 这种防御逻辑很实用——我未必看得懂每一条晦涩的参数，但我可以根据它的命令意图和内容，看出它是否试图跳出工作区、触碰注册表，或是通过管道把数据往外送。

第三件:AGENTS.md 怎么写

这个东西看文档像配置文件，自己写了之后就会知道有哪些问题:人格怎么定、规矩往哪写、工具清单怎么排序、教过的规则要不要塞进去——塞少了模型输出质量下降,需要反复调;塞多了会带来比较大的 token 浪费,本来是提效,结果又花了一个员工的钱干半个员工的活,这对公司和团队都是不可接受的。

其实最佳方式是先看推荐的AGETNS.md 框架,比如 autoclaw 或 cherrystudio 新建智能体时默认的AGENTS.md。根据范式来写，会轻松很多。我选择分层写,而不是堆在一起:AGENTS.md 主文件只放身份和三条最关键的边界,控制在 200 行以内;SOUL.md / USER.md / SAFETY.md 这些专项文件拆出去,按需加载。人格部分宁可写少不写多，根据后面实际使用情况再调整。

第四件:个人信息安全(最警惕的一件)

每个人的工作电脑都有很多项目、客户内容、账号记录等，Agent 一旦能读文件,这些东西就在它的可触及范围里。信息安全这件事情是一以贯之的，从工作目录访问、命令执行分类、AGENTS.md 编写等都有部分涉及，但是还是没有成体系化、工程化，也就是说，如果是在一个空白电脑或者个人使用从这些方面考虑是没有问题的，但如果要在团队内、公司内使用，那这些是远远不足的。

最终我的选择是单独使用一个 SAFETY.md 文件来处理个人安全事宜，分层处理:敏感目录直接列黑名单(Agent 进不了禅道截图、客户报告、账号记录这几个目录);要发给模型的内容先过一遍脱敏(公司名、客户名、型号一律替换);关键操作开本地审计日志,谁动了哪个文件、什么时候动的、都留痕。安全这件事没有银弹,只能多层兜底。

虽然Demo 没有跑起来，在刚开始下水的四个问题已经形成了基本的答案，这四个答案，比 Demo 本身更重要。

• 文件系统：沙箱化隔离。权限只给工作目录，如果有需要的项目信息，项目目录也可以给，但是不能给其他无关的项目。凡是 C 盘、系统路径或其他非相关区域，一律锁死。AI 不需要知道你的电脑里还有什么，它只需要知道它能碰什么。

• 指令执行：分级熔断。命令必须分级处理：工作区内命令自动放行;非工作区内的所有命令全部需要确认，不要让自动化变成失控，HITL（人在回路）是目前最稳妥的安全阀。

• 上下文管理：极简主义。AGENTS.md主文件只放身份和三条最关键的边界。别急着堆砌提示词。Token 的预算是有限的，要把大头留给业务逻辑，而不是喂给冗长的规则说明。

• 数据安全：使用配置文件形式处理。对于敏感目录（配置、密钥、证书），直接在配置层拦截；原则很简单：不进上下文，不进日志。从物理层面杜绝数据泄露的可能。

很多人还在刷视频，兴奋于 “它能做什么”。而我们在实际工程化落地的时候，需要冷静地回答 “我准许它做什么”。

这两者之间，隔着的不是知识的差距，而是工程的手感。

这种手感，无法从教程里学到，只有在你自己的电脑、自己的数据、自己的预算里，真实地撞过南墙，才能长出来。

三、学过 ≠ 上得了手

那一晚之后,我把脑子里”我学过这套东西”这句话,改了一下:

学过,意味着我知道这件事的边界存在;上得了手,意味着这条边界在我自己电脑上画到了哪条线——而这条线只能自己画。

对于一个会真正进入我工作流的新技术,看再多视频也只能算”准备阶段”,真正的工作量在准备完之后才开始——在一台不会出大事的机器上,把它的危险动作、它的配置颗粒度、它和我个人数据的接触面,一项一项自己过一遍。

其实在 Harness 那套方法论里，这些都有名字——约束与恢复、上下文管理、工具系统。这些词我看资料的时候就读到过。读到那一刻它们是抽象的,过完那一晚它们才落到我这台电脑上、落到我团队这个场景里。

下场不是为了”重新发现”这些词,是为了把这些词变成自己能复用的手感。

我现在评估一个新工具，第一反应不再是“它能帮我提效多少”，而是先问一句：“它手里握着我几把钥匙？”

如果只是个纯网页工具，那看看 Demo 就算了。

但如果它需要读文件、跑命令，那光看视频或完全照搬是没有用的，甚至有害。视频里只会告诉你它能一键生成，但不会告诉你它删库前有没有确认框。

这时候我会直接关掉 B 站，腾出一两个晚上。

我会专门开个隔离环境，把权限给它，然后故意让它去做那几件我最怕它做的事：

• 看看它删文件前会不会停？

• 看看它改配置前能不能拦？

• 看看它执行未知命令时，我有没有机会按下去那个“暂停键”。

只有等我把这几个红灯亲手摸亮过一次，我才敢说这个工具我能用。