AI Agent

今晚十几分钟把 OpenClaw 两个新功能配好了，记录一下。 Chrome DevTools MCP：AI 直接操作你的浏览器 这是什么？ 以前让 AI 帮你在网页上干活，要么截图给它看，要么把网页内容复制出来。 现在可以直接接入你的 Chrome 浏览器了。AI 看到你看到的，操作你能操作的。 这不是模拟点击，是真正的 Chrome DevTools Protocol，和你用 F12 开发者工具是一个原理。 它能看到什么？ 页面上的所有元素（按钮、输入框、链接、图片） 网络请求（API 调用、加载的资源） 控制台日志（错误信息、调试输出） 页面的无障碍树（结构化的页面内容） 它能做什么？ 基础操作 点击：点任何按钮、链接、元素 输入：在输入框里打字 导航：打开网址、前进、后退、刷新 截图：截取整页或某个元素 滚动：上下滚动页面 表单：一次性填写多个字段 文件上传：选择本地文件上传 键盘：发送快捷键（Ctrl+C、Enter 等） 高级功能 Lighthouse 审计：跑性能、无障碍、SEO 测试 性能追踪：录制性能 trace，分析瓶颈 内存快照：抓取 heap snapshot 调试内存泄漏 网络监控：查看所有请求的详情 控制台：执行 JavaScript 代码 怎么配？ 第一步：Chrome 开启远程调试 打开 Chrome，访问： chrome://inspect/#remote-debugging 把那个开关打开。第一次连接时 Chrome 会弹窗问你要不要授权，点允许。 需要 Chrome 144 以上版本。查看版本：chrome://version 第二步：安装 mcporter ...

上篇「差生文具多」聊了一个现象：很多人一上来就搞 4 个 Workspace，结果每个都空着。 写完之后我发现，这不只是 OpenClaw 的问题。 OpenClaw 的每个配置概念，都能映射到一个管理学原理。 理解这些映射，既能帮你用好 OpenClaw，也能让你重新思考「管理」这件事。 一张映射表 先上结论： OpenClaw → 管理学 Workspace → 部门（边界在哪？） Agent → 员工（专才还是通才？） Skill → 技能培训（培训还是招人？） Memory → 知识库（什么该记？） Context Window → 认知负荷（信息多少合适？） Cron → 流程自动化（什么该自动？） Handoff → 交接（怎么减少出错？） 下面一个一个聊。 Workspace = 部门 这个在「差生文具多」里聊过了，核心是科斯的问题： 部门的边界在哪里？ 答案是：当内部协调成本 = 外部交易成本时。 Jeff Bezos 有个著名的「两块披萨」规则：一个团队应该小到两块披萨能喂饱，大概 5-10 个人。 为什么？因为随着团队变大，沟通链路呈指数增长。10 个人的团队有 45 条沟通链路，20 个人就变成 190 条。协调成本会吃掉专业化带来的收益。 Amazon 的做法是把自己变成「一支小团队组成的舰队」，而不是一个庞大的官僚机构。每个 Two-Pizza Team 有清晰的职责边界，独立决策，减少跨团队协调。 翻译成 OpenClaw 语言： 拆 Workspace 的收益 > 协调成本 → 拆 拆 Workspace 的收益 < 协调成本 → 不拆 大部分人的问题是拆太早。还没遇到瓶颈，就急着搞多 Workspace。 ...

一个反直觉的观察 最近在 OpenClaw 社区里看到一个有趣的现象：很多人刚上手，就急着配置一堆 workspace。 架构图画得漂亮： 角色分工清晰、职责边界明确。然后呢？ 每个 workspace 都空空如也，Coordinator 自己就能干完所有事。 这让我想起小时候老师说的：差生文具多。 不只是新手在犯错 你可能觉得这是新手问题。但不是。 前几天在 Reddit r/n8n 看到一个帖子。n8n 是 no-code 工作流平台，用户大多是有经验的开发者和自动化专家。帖子说： 「看到太多 5-6 个 specialized agents 互相协调的 workflow，打开一看，其实 3 个 node + 一个 agent 就能搞定。」 他举了个例子：有人搞了三个 agent，email drafting、email sending、email followup tracking。 明明一个 agent + 三个 tool 就能搞定的事，非要拆成三个 agent。 类似的声音也出现在大厂。GitHub 最近发了篇博客《Multi-agent workflows often fail》，复盘了他们在 Copilot 和内部自动化中踩过的坑： 「Most multi-agent failures come down to missing structure, not model capability.」 ...