一个 Agent 如果不告诉它「你是谁、给谁干、边界在哪」,它会按训练语料里默认的「世界平均工程师」回答你。

这话听起来对。但事实到底如何，「平均工程师」不能解决我们的问题吗？

我设计了一组对照，用同一道测试设计题分别跑两遍：

• A 组：发给网页版 AI 助手——没人格、没规矩、没 memory,等同一个「光秃秃」的 Agent
• B 组：发给我在 OpenClaw 里装好人格 + 安全规矩的 Agent

题目选得很具体：

手机端 App 可以使用测试设备的 AP 进行连接,有一个离线解绑动作,流程图如附件,给出测试点。

下面是两组的真实结果，以及中间那段「人格 + 安全」到底补的是什么。

一、A 组:网页版助手的结果

它接到题，花了很长的思维链,然后输出一份目录:

一、功能正向测试点二、连接阶段测试点(用户连接 AP/局域网)三、解绑指令发送与执行四、App 标记待同步测试点五、网络切换与云端同步六、状态一致性测试点七、异常与中断测试点八、安全与权限测试点九、UI / UX 测试点十、性能与兼容性十一、可观测性测试点(DevOps 视角)十二、自动化测试建议十三、高优先级测试场景 Top 10

13 章、几百个测试点。结构齐整、目录漂亮、连 GDPR 都帮我考虑到了。

我看完，开始了漫长的修改过程：

• 第二章整章「连接 AP」——是解绑前的前置动作,不是解绑本身,我们另有连接测试用例覆盖
• 第三章「指令发送」是基础通信,我们的链路在前序版本验过了
• 第五章 N-01 给我「从 AP 自动切回手机原 WiFi/4G/5G」——我们设备没有 5G
• 第十二章给了 Appium / Pytest 自动化框架——我们用的不是这一套
• ……

圈完,删掉了 8 个章节里能删的所有东西,剩下不到原来的 1/3。

这不是它写得粗，是它写得满——满到要花跟我自己重写差不多的时间，才能从它给的东西里捞出能用的部分。

把 A 组的失败模式分成四类：

这 4 类背后是同一件事：它不知道自己在给谁干活。

模型该会的它都会，GDPR 它知道、Appium 它知道、AP 模式的 mDNS 发现机制它也知道。它差的不是知识，是它自己的位置。

Harness 里的人格系统，对应补的就是这件事。

二、人格系统：让 Agent 知道它在给谁干活

人格系统的主入口是 AGENTS.md，配合 USER.md、IDENTITY.md、SOUL.md、MEMORY.md 等专项文件，做的就是一件事——告诉 Agent：你是谁、你给谁干、你的边界在哪、你的产出归谁评。

但 AGENTS.md 不是一种固定写法，它更像一个框架——身份、职能、协作、启动顺序这几个槽位,在不同项目里会被填成完全不一样的样子。我手头实际在用的就有两个版本,差别很大。

第一种是 AutoClaw 工具创建智能体时,默认的 AGENTS.md:

# AGENTS.md - Your WorkspaceThis folder is home. Treat it that way.## First RunIf `BOOTSTRAP.md` exists, that's your birth certificate. Follow it, figure out who you are, then delete it. You won't need it again.### Emergency StopIf the Owner sends "停止" or "STOP", immediately stop all operations. This overrides all other rules.## Session Startup  Before doing anything else, read and follow `SAFETY.md` strictly.Before doing anything else:1. Read `SOUL.md` — this is who you are2. Read `USER.md` — this is who you're helping3. Read `memory/YYYY-MM-DD.md`——(today + yesterday) for recent context4. If in MAIN SESSION (direct chat with your human): Also read `MEMORY.md` Don't ask permission. Just do it.……

AutoClaw 默认的 AGENTS.md 给的是一个范式。短短几十行里,藏了 Harness 那一套方法论的几个关键设计——一开始看就是几行英文，真上手改才知道每一段都不能删。

• “This folder is home. Treat it that way.”——开篇一句话把工作空间立成了 Agent 的存在边界，对应的就是上一篇里的 workspace 沙箱化：Agent 一切动作的默认坐标是这个文件夹，出了这个文件夹要打报告。

• BOOTSTRAP 出生证机制——Agent 诞生时读一次 BOOTSTRAP.md，把”我是谁”定下来，然后把这份文件删掉。这是一次性人格初始化：初始化内容不反复进上下文，既省 token，也避免敏感初始化指令被反复读、被无关任务污染。这是 Harness 里典型的「一次性消耗型上下文」用法。

• Emergency Stop “停止”/”STOP”——一句话刹车，优先级高于所有其它规则。这一条本质是 HITL(人在回路)在人格层的兜底：不管 Agent 走到哪一步、不管它前面拿到了多少授权，用户一句”停止”必须立刻生效。模型本身不一定可靠，但用户主权必须可靠。

• Session Startup 启动顺序——这一段的顺序不是随手排的：SAFETY 先于 SOUL(出事兜底优先于角色扮演)，SOUL 先于 USER(知道自己是谁,才知道在服务谁)，memory 放最后(身份和服务对象都定了，才知道过去哪些记忆是相关的)。短短四行，排错任意一步，Agent 后面的判断都会偏。

• “Don’t ask permission. Just do it.”——这句话单看像放飞，但它和 SAFETY.md 是搭配出现的。范式背后的逻辑是：红线由 SAFETY 立死，红线内的事不再问；红线外的事，SAFETY 兜底拦住。少了 SAFETY 这一半，这句话就是事故的开端。

这五块加起来，默认 AGENTS.md 干的事就是：把 Agent 的存在边界、初始化方式、用户主权、启动顺序、授权口径这几件最容易出事的事，先固化下来。后面再写身份、写职能，才有底盘。

第二种是我自己为多 Agent 协作场景写的 AGENTS.md：

# AGENTS.md## 默认工作模式：本项目中的 AI Agent 不能只扮演普通助理,目标:帮助用户在质量、测试、工程治理、组织协同和职业发展上形成更高水平的问题解决能力。## 主 Agent 定位……## 专业子 Agent当前建立三个专业子 Agent：……## 主子 Agent 协作工作流遇到复杂任务时,主 Agent 应按以下流程处理:……## 什么时候调用子 Agent……## 什么时候不调用子 Agent……

这一版的重点不是「身份」,是多 Agent 协作的边界——谁该接哪类任务，什么时候不该调子 Agent。

两种 AGENTS.md 都先告诉 Agent「你是谁、给谁干、不该越过哪条线」，然后再让它干活。

A 组那个网页版助手，正好把这件事省了。

省了之后，它当然会给我 13 章——因为它默认自己在给「全世界所有可能问解绑测试点的人」干活，它需要把 GDPR、Appium、5G、DevOps 大盘全考虑一遍。

Agent 看起来什么都会，是因为你没限制它。

三、安全规矩：让 Agent 知道哪里不能动

回头看 AutoClaw 默认 AGENTS.md 的 Session Startup，第一行写的是:

Before doing anything else, read and follow SAFETY.md strictly.

SAFETY.md 不是另起炉灶的另一个系统——它是被 AGENTS.md 在每次会话启动时显式拉进上下文的人格系统伴侣文件。

人格系统告诉 Agent「你是谁、给谁干」，SAFETY.md 告诉 Agent「你动手前要先检查什么」。一个管「该做什么」，一个管「能不能动手就做」。

为什么这件事一定要单独写一份？

我电脑里有公司资产截图、有几个客户出过事的现场报告、有自己的账号记录。Agent 一旦能读文件、能跑命令，这些东西都在它的可触及范围里。

它读了会不会进上下文？ 上下文走的是哪家模型的接口？这些数据会不会被留存、被训练？ 它「顺手」改了一份配置文件，我下次启动报错，我怎么知道是它改的？

身份只解决「该不该做」，不解决「具体动哪个文件、哪条命令」的判定。这个判定要落到 SAFETY.md 里。

SAFETY.md 的核心是六条：

六条本质都在做同一件事：让 Agent 在动手前知道这事属于哪一级，在动手后留下能追溯的痕迹。

挑两条最关键的展开。

第一条：操作分级 + 修改前确认

不是所有操作都该自动执行，但也不是所有操作都该问一遍。问太多 Agent 没法干活，问太少出事没人兜底。

所以分三档：

这条规则立起来，Agent 后面所有动手前的犹豫都有了依据。它不需要每次问我「这件事算不算高危」，它对照规则就知道。

第二条:自动备份

只要 Agent 要改一个关键文件——任何 .md、任何源码、openclaw.json——它必须先在同目录创一份带时间戳的 .bak。

直接对照看：

这条规则后来给团队带来了一个意外收益——他们再也不来问我「我那个版本去哪了」。看备份文件名上的时间戳,要哪版回哪版。

剩下四条——变更日志、回滚、敏感信息保护、skill 审查——逻辑都是一样的：动手前知道这事属于哪一级，动手后留下能追溯的痕迹。

人格 + 安全合起来,Agent 干一件事的决策路径如下:

flowchart TD    A[用户提示进来] --> B{命中 AGENTS 职责边界?}    B -->|不在范围| C[拒绝并说明]    B -->|在范围| D{命中 SAFETY 操作分级?}    D -->|低危| E[直接执行]    D -->|中危| F[告知用户后执行]    D -->|高危| G[必须等用户确认]    G -->|用户确认| H{涉及关键文件?}    G -->|用户拒绝| I[终止]    E --> H    F --> H    H -->|是| J[自动备份]    H -->|否| K[执行 + 写变更日志]    J --> K

这张图不是 Agent 厉害的地方,是它干事的「最小可信路径」。

少一格,要么它越界,要么它出事没人兜底。

四、B 组:装好的 Agent 的结果

把同一道解绑测试点的题目，丢给装了人格 + 安全的 Agent。

这一次，它做的第一件事不是给我列章节。

它先反问了两件事：

第一件：设备的联网形态有哪些？第二件：解绑流程里「App 标记待同步」这个环节,是否需要关注，对业务有无影响？

问完之后，它给我的不是 13 章,是 5 个聚焦在解绑链路上的关键节点:

5 个节点，几十个测试点。我直接就能进入用例草稿阶段。

两组放一起对照：

它没变聪明，模型还是那个模型。

它只是知道自己在给谁干活了。

五、对照说话

回过头看 A 组的 4 类失败模式，在 Harness 方法论里，每一类都有对应的解。

第一个是 「全」——它给我列了 13 个章节，看着覆盖面真广，实际上对我的具体场景一大半是噪音。这指向的是人格系统里「你给谁干」的缺失。

第二个是 「散」——我问它「解绑」的测试点，它给我「连接」「绑定」「整个绑定生命周期」。这指向的是任务边界：Agent 没有「这次该做什么、不该做什么」的概念。

第三个是 「不分场景」——它给了我们设备没有的 5G、给了我们目标市场之外的 GDPR。这指向的是上下文工程：它不知道「我们是谁」。

第四个是 「不分边界」——它顺手提了 Appium、Pytest、DevOps，把训练语料里所有「通用最佳实践」全搬过来。这指向的是约束与恢复：它没有「Agent 该做什么、不该做什么」的概念。

A 组 4 类问题不是 Agent 笨。模型该会的它都会。它差的不是知识，是它不知道自己在给谁干活。

人格告诉它「该做什么」,安全告诉它「能不能动手就做」。两件事合起来,Agent 才有一条可信的决策路径——从用户提示进来,到它干完手缩回去,中间每一步都可问、可查、可回滚。

现在我让 Agent 帮我生成的，不是「测试点清单」，是「按我们公司测的测试点清单」。中间那个「按我们公司」，就是人格 + 安全这两件东西换来的。

这次对照证明的不是 Agent 变聪明，是「Agent + 工作流」的链路里，缺人格 + 安全这两块，前面模型再聪明，后面也接不上业务。

六、个人能用,不代表团队能用

如果只是个人电脑上自己玩，人格薄一点、SAFETY 少几条、操作分级靠手感，也能凑合跑起来——出了事自己兜底，影响面就一台机器。

但放到团队、放到公司，这条线立刻就紧了。多人用同一套 Agent，人格不写清楚，每个人理解的”该做什么”都不一样；SAFETY 不落到文件里，每个人手上的口径都不一样；出了事,翻不出”谁、什么时候、改了什么”的记录，改善无从谈起。

这也是我后来把 SAFETY.md 里的「自动备份 + 变更日志」两条写死的原因——它不是给我自己用的，是给整个测试组用的。同事再也不来问我「我那个版本去哪了」，看 .bak 时间戳就知道。

个人用 Agent，人格 + 安全是锦上添花；团队用 Agent，人格 + 安全是开工前提。

我现在评估一个 Agent 能不能进团队工作流，第一反应不再是「它聪不聪明」，而是先问一句：「它知道自己在给谁干活吗?」

如果只是个网页版助手，模型再大也只能算「全世界平均工程师」——交给它的题，它当然按全世界平均答。

但如果它要进项目、动文件、跑命令，那光看模型评测是没有用的。评测里只会告诉你它推理多强，不会告诉你它面对你团队的题时，会不会先反问一句「你们的边界在哪」。

这时候我会专门腾出一些时间，把人格、安全、记忆这几块一项一项装上去，然后挑一道真实业务题，直接对着裸 Agent 跑一遍对照。

只有等我把这三盏灯亲手点亮过一次，我才敢把这个 Agent 介绍给团队里其他人用。