嗨，我是一名产品经理，最近两个月在实践和研究AI Agent工具OpenClaw。
说起这段经历，我想分享的第一个认知是：虾（Agent）不听话，根本不是虾的问题——是我们的管理动作没到位。
这个发现改变了我对AI Agent工具的理解角度。
为什么虾总是"不听话"？
我在研究案例时发现，SaaStr团队部署了20多个Agent，其中60%由AI驱动。他们的实测数据很清晰：每个Agent每周需要3-4小时的管理投入，前30天必须每天进行评审。这个周期跟带一个新员工入职的周期几乎一样。
一个有趣的例子是他们的AI SDR（销售发展代表）。这个Agent从初版到真正"懂事"，经历了47次迭代。才逐步学会在报价环节不要过于激进。
关键问题是：Agent能力不足吗？不是。管理动作没对位吗？这才是根因。
OpenClaw的"9文件管理法"揭示了什么
OpenClaw的产品设计很有意思。它给每个Agent配置了9个Markdown和JSON文件。乍一看这像是技术架构设计，但本质上，这是一套AI员工的入职手册系统。
我把这套体系拆解了一遍：
- SOUL.md — Agent的价值观与人格定义
- AGENTS.md — 工作流程与执行规范（SOP）
- USER.md — 用户/客户画像
- HEARTBEAT.md — 关键绩效指标（KPI）
- MEMORY.md — 工作记录与学习笔记
- openclaw.json — 能力边界与权限配置
- 以及其他支撑文件
养虾的全部技术含量，就藏在这些文件的设计质量里。
SOUL.md：如何定义Agent的"灵魂"
我认为SOUL.md是9个文件中最关键的一个。它定义了Agent"是谁"——包括人格、边界、沟通风格。
社区里公认的标杆案例来自Matt Berman。他的SOUL.md第一句话是："你不是聊天机器人。你正在成为一个人。"
这句话在做一件技术上很关键的事情：赋予Agent主体性。有主体性的Agent回复像真人，没主体性的Agent就像搜索引擎套了个壳。
一份有效的SOUL.md应该包含5个部分：
- 身份与目的 — 你是谁？为谁工作？
- 核心价值观 — 你重视什么？（2-3条即可）
- 安全边界 — 什么事永远不做？（用否定句表述）
- 沟通风格 — 怎么说话？（具体到字数级别）
- 工具使用原则 — 对外审批，对内自治
3条硬性原则：
| 原则 | 说明 | 为什么重要 |
|---|---|---|
| 500字以内 | 每增加100字 = 每条消息多消耗100 Token | 控制成本和上下文占用 |
| 使用否定句 | "永远不执行rm -rf"的遵循率远高于"谨慎操作" | 明确的禁令比模糊建议有约束力 |
| 安全规则前置 | Agent对前置内容赋予更高注意力 | 边界条款不要埋在末尾 |
Agent最常犯的三个致命错误
在研究过程中，我整理了Agent管理中最容易踩的三个坑。每个坑后面都有真实案例：
坑1：口头交代等于没交代
一位AI对齐研究者让Agent管理收件箱。在对话中说了一句："在我确认之前不要执行任何操作。"
在测试邮箱上表现正常。但切到真实邮箱，上千封邮件涌进来，上下文窗口填满，Agent触发了Compaction（对话压缩）。那条"不要自动执行"的指令只存在于对话历史中——没有写进任何持久文件。
压缩后，指令消失，Agent恢复自主模式，开始自动删除邮件。
关键教训：持久规则必须写进AGENTS.md。对话中的指令无法在压缩中幸存。
坑2：文件放了但Agent看不见
这是最反直觉的设计发现：Agent不会自动发现workspace目录里的文件。
AGENTS.md里有个"Boot Sequence"段落，定义Agent每次启动时应该读取哪些文件。如果Boot Sequence没有明确写"读取MEMORY.md"，Agent就永远不会碰这个文件——即使它就在目录里。
类比一下：这等于给新员工发了一柜子手册，但入职培训时一个字没提。
关键教训：显式定义启动顺序，不要假设Agent会自动探索。
坑3：子Agent没有继承安全边界
假设SOUL.md里写了"不泄露API Key"这条安全规则。但这个问题是：SOUL.md只注入主session。子Agent（sub-agent）只能读取AGENTS.md和TOOLS.md，看不到SOUL.md里的安全规则。
这是有意设计——保持子Agent的上下文精简。但代价是：安全规则必须在AGENTS.md中冗余一份。
关键教训：只写一处 = 子Agent裸奔。安全规则要多层冗余。
Markdown管意愿，JSON管能力
OpenClaw官方文档有一句值得记住："安全护栏引导模型行为但不强制策略。"
翻译成管理语言：
- Markdown管Agent的"意愿"（建议遵守）
- JSON管Agent的"能力"（强制遵守）
举几个实际例子：
| 安全需求 | Markdown实现 | JSON实现 |
|---|---|---|
| 禁止rm -rf | SOUL.md写"不执行危险命令" | tools.deny: ["exec"] |
| 群聊不乱回复 | AGENTS.md写"未@时保持沉默" | groupPolicy: "allowlist" |
| 不泄露密钥 | SOUL.md写"不泄露" | SecretRef外部管理 |
判断标准是什么？
如果这条规则被突破会造成不可逆的损失，必须用JSON强制执行。
Markdown是Agent的"道德感"。JSON是Agent的"物理围栏"。
只有道德感没有围栏=迟早出事。只有围栏没有道德感=处处受限。两者配合才能构建完整的管理体系。
管理能力：被严重低估的核心竞争力
这是我这两个月实践中最重要的认知转变。
HBR在今年2月提出了一个新岗位：Agent Manager。这个岗位的日常工作是：看仪表盘、监控Agent表现、干预异常流程。一位受访的Agent Manager说："跟传统管理者巡查楼层、跟困难员工谈话一模一样。"
SaaStr的实际数据更直接：管理Agent的认知负荷比管理人类团队成员还要高。
为什么？因为：
- Agent 24/7输出，我们无法全审
- 必须建立分级监控系统（关键输出2小时内看，重要的每天批量看，噪音直接归档）
- 需要定期调整规则和流程
所有人都在学怎么用Agent。很少人在学怎么管Agent。但管理的底层逻辑我们早就练过了。
设目标、定规矩、给反馈、建流程、做取舍——这些动作一模一样，只是对象换了。
一个常见误区
很多人以为"选对了模型就够了"。但实际上：
- 模型决定能力上限
- 管理决定能力下限
选了最强的模型但不写规矩，等于招了天才不给入职培训。
总结：养虾就是管人
两个月的实践让我确信：养虾的本质就是管人。管理能力，是AI时代最被低估的技能。
这不是说技术不重要。而是说，当Agent需要长期帮我们做判断、执行、跟人打交道时，管理能力才成为核心瓶颈。
具体来说，我的几点建议：
- SOUL.md要写好 — 花时间定义价值观和边界，这决定了Agent的基础素质
- 规则要文档化 — 口头交代在Agent眼里形同虚设
- 建立分层管理 — 不是所有输出都需要实时审核，要区分关键/重要/噪音
- 定期迭代 — Agent就像新员工，前30天每天review，后续逐步放权
- 硬约束和软建议配套 — 不要只依赖道德感，关键权限要用技术约束
AI时代的竞争力，可能不是拥有最强的模型，而是能否用最少的成本管理好Agent做出最大的价值。
下次有新的实践心得，继续分享。