当 AI agent 开始接活，问题就不再只是模型本身

为什么我越来越不愿意只把 agent 当成一个工具

中文互联网最近开始把 OpenClaw 叫“龙虾”。这个名字本身有点戏谑，我也不太想把注意力都放在这个叫法上， 但它背后确实对应着一个很真实的变化：这类 agent 一旦进入工作流，你和它的关系就不再只是“装了一个工具”。 它会接消息、调工具、读文件、跑流程，也会误解、跑偏、犯错。它更像一个刚进组、能动手、但需要被带的新同事。

从官方定义看，OpenClaw 本身就是一个 self-hosted gateway。它能接到你本来就在用的沟通渠道里， 比如 WhatsApp、Telegram、Discord、Slack、iMessage，然后再把模型、工作区、工具、记忆和消息路由接在一起。 这就意味着，它天然不像一个“开箱即聊”的网页产品，更像一个要被纳入你日常工作流的助理系统。

所以对我来说，真正值得讨论的不是这个外号，而是 agent 带来的管理问题。你怎么给环境，它就怎么长；你怎么设边界， 它就怎么做事；你怎么沉淀流程，它就会继承什么样的工作方式。

很多人以为自己在部署能力，实际上是在给一个岗位搭系统

很多工具的体验是，装上、点开、直接用。OpenClaw 不是。官方 quickstart 写得很清楚，前提是 `Node 22+`， 推荐先跑 `openclaw onboard --install-daemon`，把 gateway、auth、workspace、channels 这些东西一步步配起来。 也就是说，你第一件事不是提需求，而是先把一个能工作的环境搭起来。

这个过程特别像新人入职。你得先给位置、给账号、告诉他文档放哪、和谁对接、什么事情走什么流程。对 agent 也是一样。 你不给它模型，它没有脑子；你不给它渠道，它没有嘴；你不给它工具，它没有手；你不给它 workspace，它就没有一个真正能工作的“场”。

OpenClaw 的 gateway 也是这种设计逻辑。它不是那种只会在聊天框里出字的东西，而是一个长期运行的中枢， 管消息入口、会话路由、workspace、控制界面和工具调用。工具一旦变成系统，你跟它的关系自然也就不再只是“用一下”， 而是“收进工作流里长期共事”。

难点从来不在启动，而在于让它形成稳定的工作方法

一个刚进组的人最麻烦的地方，往往不是不努力，而是努力错方向。你说“帮我整理一下”，他也会整理，但可能整理成一个你根本不需要的版本。 你说“先看看资料”，他也会看，但看完不知道重点在哪。Agent 也是一样。它一旦进入执行层，最大的风险不再是不会做， 而是做得很勤快，但做偏了。

OpenClaw 的文档其实已经把这个问题讲得很明白。它会把 `AGENTS.md`、`SOUL.md`、`USER.md`、`IDENTITY.md`、 `TOOLS.md`、`HEARTBEAT.md` 这些 workspace 文件注入到每次运行的上下文里。换句话说，你不是在单次提需求， 你是在持续给它写“岗位说明书”和“做事方法”。

这也是为什么我现在越来越不相信那种“写一个很神的 prompt，一把梭全部搞定”的想法。真正稳定的 agent， 不是靠一条 prompt 突然开悟，而是靠你把工作方式一点点写进环境里。哪些问题先查哪里，哪些事情可以自己判断， 哪些必须先来问我，什么叫完成，什么叫不要自作聪明，这些东西你不写，它永远只能靠猜。

没有外部记忆，它每天都像重新入职

我觉得普通聊天机器人最让人疲惫的一点，就是你永远在重复自己。昨天说过的事，今天像没说；上周定好的风格，这周重新开始。 它每次都很礼貌，但每次都像第一次见你。

OpenClaw 想解决的，很大一部分就是这个问题。它的 memory 不是一种很玄的“模型好像知道一点”，而是工作区和索引系统里的真实结构。 文档里写得很直接：workspace 本身就应该被当成 memory 来对待；日常记忆可以写进 `memory/YYYY-MM-DD.md`； `memory_search` 和 `memory_get` 则负责在这些持续记录里检索和回读。

这个设计为什么重要？因为它把“记住”从模型内部挪到了你能看到、能编辑、能备份的外部系统里。一个顺手的新人会记会议纪要、 记老板偏好、记项目状态、记坑点；而一个顺手的 agent，其实也是这个过程。不是它突然更聪明了，而是它终于不再把昨天的自己忘光。

所以 agent 的成长，本质上不是训练出一个无所不能的神，而是慢慢把它从“每次都要重新说明白”，养成“知道你在怎么工作”。

Skills 不是外挂，更像被沉淀下来的做事方法

很多人第一次看 skills，会下意识把它理解成插件。但我后来越来越觉得，它更像一种能力沉淀。OpenClaw 的技能系统其实很像工作方法库： 每个 skill 都是一个带说明的目录，能从 bundled skills、`~/.openclaw/skills`，再到 workspace 里的 `skills/` 分层加载，而且本地的可以覆盖默认的。

这个逻辑特别像带人。你教会一个实习生怎么拉数据、怎么写日报、怎么检查异常、怎么按模板发消息、遇到问题先排查什么， 他以后就少占用你一次注意力。你给 agent 配好一个 skill，本质上也是一样。它最有价值的地方不是“懂了一个概念”， 而是“会做一件事了”。

所以我现在会觉得，skills 不是外挂，更像是你教会它的一套活法。你给它的不是魔法，而是方法；不是临时灵感，而是重复可执行的动作。 这也是 agent 真正开始接活的时候最让人上头的地方，因为那一刻你会意识到，它不再只是一个会聊的模型，而开始像一个能分担流程的人。

会做事，不等于应该拿到最高权限

这件事我反而觉得最重要。OpenClaw 的安全文档写得很直白：inbound DMs 要锁住，陌生人默认不能直接碰；群里最好要求 mention； links、attachments、pasted instructions 都应该默认按不可信内容处理。更关键的是，就算只有你自己能和它对话， prompt injection 也依然会通过网页、邮件、文档、附件和日志这些外部内容进来。

这件事为什么值得被反复强调？因为 agent 和普通聊天模型的风险不是一个量级。聊天机器人答错一段话，问题通常还停留在信息层； 但 agent 一旦能读文件、跑命令、发消息、连外部服务，错一次就可能真的删东西、发错消息、带走信息，或者把不该碰的上下文暴露出去。

所以成熟的用法，从来不是“它已经会干活了，那我就把最高权限都给它”。真正靠谱的带法，反而是分级授权： 先从低风险、可回滚、可审核的任务开始；让它读，不一定让它写；让它建议，不一定让它执行；让它接触信息，不一定让它接触核心权限。 你不是在阻碍它成长，你是在防止它把工位炸了。

为什么这类 agent 最近会突然出圈

因为它正好踩中了一个特别诱人的想象：不只是问 AI，而是把 AI 变成“我手下会干活的人”。最近关于 OpenClaw 的讨论之所以会突然出圈， 我觉得不只是产品本身做得多酷，而是它第一次把很多人脑子里那个模糊的愿望具象化了。不是聊天，而是代办；不是建议，而是接活。

媒体最近的报道也能看出这种热度。Semafor 提到，中国最近对 AI agents 的热情明显升温，像 OpenClaw 这种能在设备上自主执行任务的工具， 正在从开发者圈往更广的人群扩散，甚至有上千人去参加线下安装活动。与此同时，SCMP 也写到，金融机构和监管部门开始对 OpenClaw 提高警惕， 原因很简单：它需要接触的设备权限和工作流边界，远比普通软件更敏感。

所以它会火，其实一点都不奇怪。因为它既不是单纯买个软件，也不是学个模型，而是在用一种更贴近人的方式进入工作关系。 你在和它磨合，你在等它长本事，你在嫌它费钱，你在夸它偶尔真的很顶，你也在吐槽它有时候忙活半天只交出一堆废话。 这种关系感，才是最近很多人真正上头的地方。

所以我更愿意把它理解成一个需要被管理的新同事

我的理解是，这里面至少有四层意思。第一，别把它当魔法，要当作一个需要被管理的执行体。第二，别把流程留在脑子里， 要把偏好、记忆、技能和验收标准写进系统。第三，它需要成长，但成长的前提不是放养，而是持续反馈。第四，它本质上仍然需要监管， 因为会做事和能承担后果，从来不是一回事。

这也是为什么我后来会把 OpenClaw 和 Codex 放在同一个问题里看。它们做的事情不完全一样。OpenClaw 更像接在消息、渠道和个人工作流上的助理系统； Codex 更像在代码仓库和任务环境里工作的执行型 agent。可它们最后都在逼你面对同一个问题：如果你手下真的多了一个不会累、会接活、 能调工具、也可能犯错的数字执行体，你到底知不知道该怎么带。

对我来说，这已经不只是效率问题了。它更像 2026 年一个很新的管理学问题。因为你最后管理的不是模型本身，而是上下文、流程、权限、反馈和边界。 说到底，agent 没有把人从系统里拿掉，它只是逼着人从“亲自做每一步”，转向“亲自设计这套系统”。

而我对这件事持续感兴趣，也正是因为这里面有一种我很在意的东西：如何把复杂问题讲清楚，如何把模糊流程变成结构，如何让一个系统真正稳定地做成事。 从这个角度看，管理 agent 其实也像在训练自己。