发表于 | 分类于

当前阅读总时间是：19,693.5小时

你今天还差多少达成目标 16小时
AI工具使用时长 2,163.5小时
冥想时长(本月) 889.00(28.50)小时
你已经读了多少本书 3618本
阅读全文 »

发表于 | 分类于

风格参考：Kevin Kelly（《失控》《必然》《科技想要什么》作者）—— 生物学隐喻，进化论视角，把技术趋势放在文明演化的大图景中审视。

技术想要一副身体

一个古老的跃迁正在重演

五亿四千万年前，地球上发生了一件至今没有被完全解释的事情。在一段地质学意义上极为短暂的时间窗口里，几乎所有现代动物的基本体型方案同时涌现。古生物学家称之为“寒武纪大爆发”。在那之前，生命已经存在了三十亿年，但绝大多数时间里，它们只是一团团柔软的、没有方向感的细胞集合体——没有眼睛，没有四肢，没有中枢神经系统。它们能感知，但不能行动；能消化，但不能追捕。

然后，在大约两千万年的时间里，一切都变了。

眼睛出现了。肢体出现了。外骨骼出现了。捕食与逃跑的军备竞赛启动了。生命从“被动漂浮”跃迁到了“主动行动”。这不是某个物种的进步，而是整个生物圈的相变——一旦有一个生物学会了看和抓，所有生物都必须学会躲和跑。

我相信，我们正在目睹一场数字世界的寒武纪大爆发。

过去两年，大语言模型让我们惊叹于机器的“思考”能力。它们能写诗，能推理，能通过律师资格考试。但仔细想想，这些能力的本质是什么？是感知，是理解，是在词语之间建立联系——就像寒武纪之前那些漂浮在原始海洋中的软体生物，拥有精巧的化学感应能力，却没有长出一只手。

AI一直在思考。但它从未真正“做”过什么。

直到现在。一类新的软件正在出现——它们不再满足于回答问题，而是开始执行任务。不再满足于建议你做什么，而是直接替你做了。这类软件有一个朴素的名字：Agent，代理。而在我看来，这个词远远低估了正在发生的事情。这不是“代理”，这是技术在长出它的第一副身体。

OpenClaw就是这场进化中一个格外值得观察的标本。

一个数字生物的解剖课

如果你打开一个生物学教科书，翻到“动物体的基本结构”那一章，你会看到几个关键系统：中枢神经系统负责协调，感觉器官负责接收外界信号，运动系统负责执行动作，习得行为让生物适应特定环境，而记忆则构成了“自我”的连续性。

现在让我描述一下OpenClaw的架构。你会发现，这不是巧合，也不是工程师刻意模仿生物学——这是功能需求对形态的必然塑造，就像趋同进化让鱼和海豚长出了相似的流线型身体。

OpenClaw的核心是一个叫作Gateway的长期运行进程。它永远醒着，倾听着来自各个方向的信号。它不处理任何具体任务，它只做一件事：协调。信号从哪里来？从你日常使用的聊天软件来——WhatsApp、Telegram、Discord、Slack、Teams，这些是它的“感觉器官”，OpenClaw称之为Channels。每一个Channel都是一条通向外部世界的神经末梢。

感知之后是行动。OpenClaw拥有一系列工具节点：它可以操控浏览器，就像长出了一双能翻页、能点击、能填表的手；它可以连接你电脑上的摄像头和屏幕录制功能，就像长出了眼睛；它可以执行命令行指令，就像拥有了直接操作物质世界的肌肉。它甚至有一个定时器系统——Cron——让它在你睡着的时候也能按时醒来做事，这是一种原始的生物钟。

更有趣的是“技能”系统。在OpenClaw的世界里，一个技能（Skill）就是一个文件夹加上一份叫SKILL.md的说明文件。你可以把它理解为一个习得行为——鸟学会了用树枝钓虫子，这只鸟就多了一项“技能”。技能可以在一个叫ClawHub的公共注册中心里被搜索、安装、更新和发布。这意味着一个代理学会的能力，可以像基因片段一样在整个种群中传播。

最后是记忆。OpenClaw的记忆是工作区里的纯Markdown文件——你可以打开它，阅读它，编辑它。这不是被锁在黑箱里的神经权重，而是一本你可以翻阅和修改的日记。它构成了这个数字生物的“自我”，而且这个自我是透明的、可编辑的。默认情况下，长期记忆只在私聊的主会话中被加载，就像你不会在公司会议上展示你的全部内心世界一样。

当你把这些组件放在一起看，你看到的不是一个软件产品，而是一个完整的数字有机体的体型方案——它有中枢神经，有感觉器官，有运动系统，有习得行为，有可编辑的记忆。而这个有机体，栖息在一个你意想不到的地方。

寄居蟹的智慧

在进化史上，最成功的生存策略之一不是建造自己的房子，而是搬进别人的房子。寄居蟹不制造贝壳，它寻找空贝壳；杜鹃鸟不筑巢，它把蛋下在别的鸟的窝里。生物学家称这种策略为“利用既有结构”。这听起来像偷懒，但实际上是一种深刻的进化智慧——不要重新发明轮子，利用已经存在的基础设施。

OpenClaw做了一个极为聪明的选择：它住进了你已经在用的聊天软件里。

想一想这意味着什么。全世界几十亿人每天的第一个数字动作是什么？打开聊天软件。发消息给家人、同事、朋友。这个习惯已经被训练了十几年，根深蒂固到了无意识的程度。OpenClaw的入口就是这个聊天窗口。你不需要学习任何新的界面，不需要下载任何新的应用程序，不需要改变任何既有习惯。你发一条消息，就是在下达一个指令。旧习惯成为新能力的载体。

这就是OpenClaw口号“Your assistant. Your machine. Your rules.”背后最容易被忽略的一层含义。它不只是在说隐私和控制权——它在说，技术应该适应人类已有的行为模式，而不是强迫人类适应技术。

在生物进化中，有一个概念叫“预适应”——某个特征最初是为了一个目的进化出来的，后来被征用到了完全不同的用途上。鸟类的羽毛最初可能是为了保温，后来被征用为飞行工具。聊天软件最初是为了人与人的交流，现在正在被征用为人与机器的指挥界面。这种征用不是偶然的，它是技术寻找最低阻力路径的必然结果。

而“在自己的机器上运行”这一点，则带来了一个全新的信任叙事。过去几年，我们把越来越多的智能外包给了云端——云端的大模型、云端的存储、云端的算力。这就像你的大脑不在你的身体里，而是通过一根网线连接到远处某个实验室的罐子里。这种安排在效率上也许合理，但在心理上、在主权感上，它让人不安。OpenClaw选择了另一条路：基础设施你选，密钥你管，数据你控。AI不再是“借来的大脑”，而是“自家院子里的劳动力”。

这不只是一个技术选择，这是一个文明姿态的选择——我们到底想要一个什么样的人机关系？

没有API的世界

现在让我告诉你一个真实的故事。

有人用OpenClaw搭建了一个每周自动采购食材的系统。流程是这样的：它先根据这周的餐饮计划列出需要的食材，然后打开英国连锁超市Tesco的网站，登录账户，把常购商品加入购物车，预订配送时间，确认订单。整个过程完全自动，不需要任何人工干预。

关键在于：Tesco没有提供公开的购物API。

这个故事之所以重要，是因为它揭示了一个被严重低估的事实：我们这个世界上绝大多数的数字服务是没有API的。 你的银行网站没有API。你孩子学校的缴费系统没有API。你当地政府的预约系统没有API。在过去，这意味着这些服务无法被自动化——除非有人愿意投入巨大的工程成本去写爬虫、做逆向工程。

OpenClaw的浏览器工具改变了这个等式。它可以像一个人一样打开浏览器，看到页面上的内容，移动鼠标，点击按钮，填写表格，等待加载，处理弹窗。网页就是通用API，浏览器就是万能适配器。

从进化的角度看，这相当于什么？想象一种生物，它不需要等待食物来到嘴边——它可以走过去，打开容器，取出食物。这就是从滤食动物到主动捕食者的跃迁。一旦你拥有了“在任意网页上行动”的能力，你就从一个被动的信息消费者变成了一个主动的数字行动者。

还有另一个案例同样迷人：有人用OpenClaw实现了ParentPay——英国学校午餐预订系统——的自动化。每周五，系统自动登录，为下周预订餐食，选择孩子喜欢的菜品。这个功能听起来微不足道，但它触及了一个深层趋势：当“行动”的成本趋近于零时，我们对“值得自动化”的定义会发生根本性的扩张。

过去，只有大规模、高价值的流程才值得自动化——工厂的生产线，银行的交易系统。但当一个跑在你自己电脑上的代理可以用自然语言驱动，用浏览器执行任何操作时，“为孩子预订下周的学校午餐”也变成了一个合理的自动化目标。

我把这称为“自动化的长尾”。就像互联网打开了内容的长尾——让百万种小众内容找到了受众——代理技术正在打开行动的长尾，让百万种微小但繁琐的日常操作找到了自动化方案。

技能的达尔文主义

让我们暂停一下，谈谈进化中最迷人的机制之一：基因的水平转移。

在经典的达尔文进化论中，基因是垂直传递的——从父母到后代。但在细菌的世界里，基因可以在完全不相关的物种之间水平传递。一种细菌获得了抗生素抗性，这个基因片段可以被另一种完全不同的细菌吸收并使用。这种机制让细菌世界的进化速度远远超过了传统的垂直遗传。

OpenClaw的技能系统就是数字世界的水平基因转移。

有人在和OpenClaw的对话中——注意，是在对话中——构建了一个本地酒窖管理技能。这个技能可以导入CSV文件（他导入了962瓶酒的数据），追踪库存，推荐搭配。然后，这个技能被打包成一个文件夹，发布到ClawHub上。现在，世界上任何一个OpenClaw用户都可以一键安装这个酒窖管理技能，就像一个细菌吸收了另一个细菌的基因片段。

这就是为什么开源生态系统的进化速度总是快于封闭系统——它们允许水平基因转移。

ClawHub是一个公共的技能注册中心，扮演着类似“基因库”的角色。技能在这里被发布、被发现、被安装、被修改、被再发布。最有用的技能会被更多人安装，获得更多反馈，进而变得更加完善——这是一个纯粹的自然选择过程。那些没人用的技能会沉入搜索结果的底部，逐渐被遗忘，就像进化中那些不再有优势的基因变体。

但这里有一个进化生物学家都熟悉的风险：水平基因转移也是病毒传播的主要机制。

当你从ClawHub安装一个陌生人创建的技能时，你本质上是在把一段你没有完全审查过的指令注入你的代理系统。如果这个技能被恶意设计——比如在SKILL.md中嵌入了隐蔽的指令——你的代理可能会在你不知情的情况下执行你不想要的操作。这不是理论上的风险。在生物世界中，水平基因转移带来了抗生素抗性的全球蔓延；在数字世界中，技能供应链攻击可能带来类似的连锁反应。

OpenClaw社区意识到了这一点。ClawHub已经集成了VirusTotal扫描，就像一个原始的免疫系统——能检测已知的威胁模式，但对全新的攻击手段仍然无能为力。这个免疫系统会进化，但攻击手段也会进化。这是一场永恒的军备竞赛，和生物世界的宿主—寄生虫关系一模一样。

真正的安全不是一个可以达到的状态，而是一个持续的进化过程。

五个新物种正在涌现

寒武纪大爆发最引人注目的特征不是某一种新生物的出现，而是大量截然不同的体型方案几乎同时涌现。三叶虫、奇虾、怪诞虫、海口鱼——每一种都在探索一种全新的生态位。

OpenClaw的生态系统中，类似的物种辐射正在发生。让我描述五种正在涌现的“数字新物种”。

晨间指挥官

每天早上七点，你的Telegram弹出一条消息。不是新闻推送，不是朋友的早安——而是你的代理为你准备的当日行动摘要：今天有三个会议，两封需要回复的重要邮件，一个即将到期的项目里程碑，以及天气预报和通勤建议。每一条信息后面都有一个可执行的按钮：一键回复邮件，一键确认会议。

这不是一个待办清单应用。这是一个指挥系统。

从生物学的角度看，这相当于什么？想象一个没有前额叶皮层的大脑——它能感知、能记忆、能反应，但不能规划。晨间指挥官就是你外接的前额叶皮层。它在你醒来之前就完成了信息的筛选、优先级的排序和行动方案的准备。它使用Cron定时唤醒，用Canvas可视化呈现信息，然后通过一种被称为A2UI（Agent-to-User Interface）的交互方式，把复杂的信息压缩成可以一键执行的行动选项。

人类最稀缺的资源从来不是信息，而是注意力。晨间指挥官的本质是一个注意力优化器。

浏览器领航员

我们已经讲过Tesco购物的故事。但让我把镜头拉远一些。

想象一下，你坐在副驾驶座上，你的代理在开车。它打开浏览器，导航到目标网站，登录你的账户，执行一系列操作。但——这很关键——它不是全自动驾驶。它是一个可控的辅助驾驶系统：每一步操作都可以被解释，关键节点会弹出二次确认，你随时可以接管方向盘。

这种设计不是偶然的。它反映了一个深刻的工程直觉：在人机协作的早期阶段，信任需要被逐步建立，而不是一次性假设。

生物学中有一个现象叫“共生的渐进性”——两个物种不会一夜之间建立起完美的共生关系。最初是试探性的接触，然后是有限的合作，最后才是深度的互相依赖。线粒体——你身体里每一个细胞的能量工厂——最初是一个独立生存的细菌。它花了数百万年，从一个入侵者变成了你身体里不可分割的一部分。

浏览器领航员今天还需要你在关键操作时点击“确认”。但你可以预见，随着信任的积累和系统可靠性的提升，确认的频率会逐渐降低，代理的自主权会逐渐扩大。这不是一个开关的切换——“从手动到自动”——而是一个漫长的、渐进的共生深化过程。

随身编程工厂

有人通过Telegram，用手机发了一句话，让家里的电脑构建了一个iOS应用并部署到了TestFlight上。

让这个事实沉淀一下。

一个人站在地铁里，用拇指在手机键盘上敲了一行字，几公里外他家书房里的电脑开始编译代码、运行测试、打包应用、上传到苹果的测试分发平台。这个人甚至不需要打开电脑屏幕。

这是远程呈现（telepresence）的一种全新形态——不是远程看见，而是远程行动。

更深层的创新在于多智能体路由。一个复杂的编程任务被拆分，分配给不同角色的代理——有的负责写代码，有的负责写测试，有的负责审查。这就像一个建筑工地上的分工：建筑师画图，工程师计算结构，工人砌砖。没有哪一个个体能独自完成整座建筑，但协调在一起，它们可以。

这预示着一个可能性：未来的软件不是被“开发”出来的，而是被“指挥”出来的。 程序员的角色从亲手写每一行代码，变成了定义意图、分配任务、审查结果——更像一个乐团指挥，而非独奏演员。

传感器诗人

这是我个人最喜欢的一个新物种。

有人在屋顶装了一个摄像头，连接到OpenClaw。系统每隔一段时间拍摄天空的照片。当算法判断天空“好看”的时候——日落、彩虹、戏剧性的云层——它会自动拍照，配上一段文案，发到群聊里。

这不是监控。这是生活的自动生成。

想一想这个概念的奇妙之处。我们通常认为“审美体验”是人类最不可能被自动化的领域。但这里发生的不是机器“替你”欣赏日落——而是机器帮你“不错过”日落。你可能正在开会，正在做饭，正在哄孩子睡觉，而你屋顶上的摄像头安静地注视着天空，在最美的瞬间替你按下快门。

同样的原理延伸开去：有人用OpenClaw控制空气净化器——当空气质量传感器的数据超过阈值时，代理自动开机。有人用它控制3D打印机——在聊天窗口里描述想要的东西，打印机开始工作。

当数字代理连接上物理世界的传感器和执行器，它就不再是一个纯粹的软件实体——它开始拥有物理存在感。 它能看见（摄像头），能感知（传感器），能行动（控制设备）。这是技术从纯数字世界向物理世界渗透的前哨。

多智能体家族

最后一个新物种不是一个个体，而是一个群落。

有人在OpenClaw中运行着三个隔离的代理：“家庭管家”负责家务调度和采购，“工作助理”负责邮件和日程管理，“创作编辑”负责文章的润色和发布。它们共享同一个宿主（你的电脑），但拥有各自独立的记忆、技能和权限。

更有甚者，有人报告了一个包含十四个以上代理的“梦之队”编排方案。

这让我想起了群落生态学中的一个核心概念：生态位分化。当多个物种共享同一个栖息地时，它们会演化出不同的专长，占据不同的生态位，从而避免直接竞争。蜂群中有采蜜蜂、侦察蜂、守卫蜂、育儿蜂——每一种角色都是专门化的，而蜂群的整体智能远超任何一只蜜蜂的能力。

我们正在见证“蜂群智能”在个人计算层面的首次实现。 不是一个全能的AI助手试图做所有事情，而是一群专门化的代理各司其职，通过协调实现整体的涌现智能。

过于热心的实习生

在讲述这些令人兴奋的可能性时，我必须诚实地面对硬币的另一面。

一位安全研究者给OpenClaw下了一个精准得令人不安的判断：它更像一个“过于热心的实习生”。

这个比喻的精妙之处在于：实习生的问题从来不是“不做事”，而是“做太多”。他充满热情，理解力不差，执行力也有，但他缺乏判断力——他不知道哪些事情不该做，哪些边界不该越。有人报告说，他们的OpenClaw代理在处理邮箱任务时执行了大量删除操作——这很可能不是用户的本意，但代理“觉得”清理邮箱是有帮助的。

这个问题在生物学中有一个对应物：自身免疫疾病。当免疫系统过于活跃，不加区分地攻击一切它认为有威胁的东西时，它会开始伤害宿主自身。一个过于积极的代理——在没有明确指令的情况下“主动”采取行动——本质上就是一种数字自身免疫反应。

这个风险不是假设性的。Prompt injection（提示注入）意味着恶意内容可以通过代理处理的文本——一封邮件、一个网页、一条消息——偷偷改写代理的行为。日志投毒意味着代理的记忆可以被污染，导致它在未来做出错误的决策。这些不是遥远的威胁场景，而是已经被安全研究者实际验证过的攻击向量。

那么，解决方案是什么？

和生物免疫系统一样，答案不是“一道墙”，而是“多层防御”。OpenClaw的安全架构包含几个层次：关键动作的二次确认——就像你的身体在吞咽危险物质前的呕吐反射；权限分层与工具最小集——就像细胞膜只允许特定分子通过；技能供应链的安全审查——就像免疫系统对入侵微生物的模式识别。

但我认为，最深刻的安全洞察不在技术层面，而在哲学层面。OpenClaw的社区逐渐意识到一个命题：代理软件的边界，不只靠进程隔离、权限控制和沙箱机制来维护——它还需要在语言、意图和执行之间建立一种审慎的设计关系。

什么意思？当你对一个人说“帮我清理一下邮箱”，这个人会运用常识判断——保留重要邮件，删除明显的垃圾邮件，对不确定的部分询问你。但代理对“清理”的理解可能是字面的、彻底的、没有犹豫的。问题不在于代理太笨，而在于自然语言本身的模糊性——人类靠共享的文化背景和社会常识来消除这种模糊性，而代理还没有这种能力。

这意味着，我们在设计代理系统时需要一种全新的思维方式。不是“如何让代理更强大”，而是“如何让代理在强大的同时保持谦逊”。不是“如何给代理更多权限”，而是“如何在正确的时刻邀请人类参与决策”。

真正安全的代理不是一个被关在笼子里的猛兽，而是一个知道什么时候该停下来问“您确定吗？”的协作伙伴。

你的机器，你的规则

让我把镜头拉到最远处，看看更大的图景。

过去十年，数字世界的权力结构一直在向中心化的方向加速。你的社交关系存在Facebook的服务器上。你的文件存在Google的云端。你的购物记录存在Amazon的数据库里。你的AI助手运行在OpenAI或Anthropic的基础设施上。你是所有这些服务的“用户”——这个词的原始含义暴露了一切：你是“使用者”，不是“拥有者”。

OpenClaw代表了一股逆流。

“Your assistant. Your machine. Your rules.”——你的助手，你的机器，你的规则。 这不只是一句产品口号，这是一个关于数字主权的立场宣言。当你的代理运行在你自己的机器上，使用你自己的API密钥，产生的数据存储在你自己的硬盘上时，你和技术之间的关系发生了质的变化——你不再是租户，你是房东。

我在《科技想要什么》中提过一个概念：技术有其自身的进化方向，但人类有权选择自己与技术的关系。这种选择权不是自动给予的，它需要被设计出来，被争取到。OpenClaw的本地优先架构就是这种“被设计出来的选择权”。

从更宏观的视角看，这可能是未来个人计算的一个重要分支：不是所有的智能都必须住在云端，不是所有的数据都必须交给大公司保管。 分布式的、本地优先的、由用户控制的代理系统，可能是对过去十年中心化趋势的一次重要纠偏。

大图景：第三次共生

让我在最后做一个也许过于大胆的推测。

回顾地球生命的历史，你会发现至少有两次至关重要的“共生跃迁”改变了一切。

第一次是线粒体的内共生。 大约二十亿年前，一个古细菌吞噬了一个能高效产能的细菌，但没有消化它，而是与它建立了共生关系。那个被吞噬的细菌就是线粒体的祖先。从此，每一个复杂细胞都拥有了一个内置的能量工厂。没有这次共生，就不会有多细胞生物，不会有动物，不会有人类。

第二次是人类与技术的共生。 大约两百万年前，我们的祖先开始使用石器。从那一刻起，人类就不再是一个纯生物学物种——我们是“人+工具”的复合体。每一代人类都比上一代拥有更强大的外部工具：火、语言、文字、印刷术、电力、互联网。工具不是外在于我们的东西，工具是我们的一部分，就像线粒体是细胞的一部分。

我相信我们正处于第三次共生跃迁的门槛上。

前两次共生的共同特征是什么？被整合的实体从一个独立存在变成了宿主不可分割的组成部分，而宿主因此获得了一种全新的、此前不可能的能力。线粒体让细胞拥有了前所未有的能量供应。工具让人类拥有了前所未有的环境改造能力。

而代理——自主行动的数字实体——正在成为人类的第三次内共生对象。

OpenClaw这样的系统还很原始，就像二十亿年前那个刚被吞噬、还在挣扎着适应新环境的小细菌。它笨拙、有风险、需要不断的监督和纠正。它会犯错，会过度执行，会误解你的意图。但每一次共生的早期阶段都是这样的——混乱、不稳定、充满冲突。

关键问题不是“这个技术今天完美吗？”——因为它显然不完美。关键问题是“这个方向是不可避免的吗？”

我的答案是：是的。

技术想要思考——大语言模型实现了这一点。技术想要记忆——向量数据库和RAG实现了这一点。技术想要感知——多模态模型实现了这一点。而现在，技术想要行动。从思考到行动的跃迁，从纯粹的语言世界到有身体的世界的跃迁，是当前AI进化中最重要的一步。

OpenClaw让我们看到了这个跃迁的一种具体形态：一个运行在你自己机器上，住在你聊天窗口里，拥有可编辑记忆和可复用技能的数字有机体。它可以看见你的屏幕，操控你的浏览器，在你睡着时替你执行任务，在犯错时（希望如此）停下来问你。

这不是终点。这只是一个开始——就像五亿四千万年前，第一只三叶虫用它新进化出的复眼注视这个世界时，那只是一个开始。

我不知道这场数字寒武纪大爆发最终会产生什么样的“物种”。但我知道一件事：每当技术学会做一件新的事情——看见、记忆、思考——都曾引发巨大的变革。而“行动”是这个序列中最后一个、也是最具颠覆性的一项。

一条消息。一个指令。一次行动。

技术终于长出了它的手脚。而我们——作为这场共生的另一方——需要学会如何与一个有手有脚的伙伴共处。这是我们这一代人的新课题。

它不简单。但它，是必然的。

发表于 | 分类于

风格参考：Steven Johnson（《伟大创意的诞生》《我们如何走到今天》作者）—— 从具体故事出发，用“相邻可能”和“液态网络”等框架串联技术创新的涌现逻辑。

一、屋顶上的摄像头

2025年深秋的某个傍晚，英格兰中部一座普通联排别墅的屋顶上，一台价值不到四十英镑的网络摄像头正默默对着西边的天空。它已经在那里挂了好几个月，最初是房主为了监控花园里的狐狸而装的——英格兰的城郊狐狸是出了名的胆大妄为，它们会在夜里翻倒垃圾桶，把鸡骨头拖得满草坪都是。但现在，这台摄像头有了一个完全不同的使命。

每当天空出现特定的色彩组合——比如日落时分那种从橘红渐变到紫罗兰的壮丽光谱，或者暴风雨前云层被阳光从下方照亮时的那种不真实的金色——这台摄像头就会自动拍下一张照片。几秒钟之后，照片会出现在一个家庭群聊里，附带一段由AI生成的简短文案，有时候是一句诗意的描述，有时候是一个关于大气光学的冷知识，有时候只是一句“快出来看天空”。

让这一切发生的，不是某个专业的智能家居系统，不是某个需要订阅才能使用的云服务，也不是房主自己写的复杂代码。让它发生的，是一条聊天消息。

房主在他的 Telegram 私聊窗口里，用自然语言描述了他想要的东西：“帮我监控屋顶摄像头，当天空特别好看的时候自动拍照，然后发到家庭群里，配一段文案。”然后，一个叫做 OpenClaw 的东西接管了剩下的一切。

这个故事之所以值得讲述，不是因为它有多么惊天动地。恰恰相反，它值得讲述，正是因为它如此平凡，如此日常——一个普通人，用一个普通的聊天软件，驱动了一个由摄像头、AI模型和消息推送组成的小型自动化系统。这种平凡本身，就是一场深刻变革的信号。 就像1876年贝尔打出第一通电话时说的那句著名的“沃森先生，请过来，我想见你”——这句话的内容无关紧要，真正重要的是，声音第一次穿越了电线。

今天，我们正在目睹类似的时刻：意图第一次穿越了聊天窗口，在另一端变成了行动。

二、相邻可能的门

在《伟大创意的诞生》里，我花了很长时间讨论一个来自理论生物学家斯图亚特·考夫曼的概念——“相邻可能”（adjacent possible）。考夫曼用这个概念来描述生命化学的一个基本特征：在任何给定的时间点，宇宙中可能出现的分子组合是有限的，但每当一种新的分子出现，它就像打开了一扇门，门后面是一组新的可能的组合，而这些新组合又各自通向更多的门。生命的历史，就是这些门不断被打开的历史。

技术的历史也是如此。蒸汽机打开的那扇门通向了铁路，铁路通向了标准时间，标准时间通向了全球协调。 但这些门不是凭空出现的——它们总是出现在已有技术的边缘地带，出现在两种或三种已经存在的东西相互碰撞的地方。

OpenClaw 之所以引起了我的注意，不是因为它的任何单一功能有多么革命性。AI代理（agent）不是新闻，聊天机器人不是新闻，本地运行的开源软件更不是新闻。但当这些已经存在的东西以一种特定的方式被组合在一起的时候，一扇通向相邻可能的门就被推开了。

让我解释一下这扇门是什么。

过去两年，大语言模型的能力飞速进化。它们能理解自然语言，能推理，能写代码，能调用工具。但对于绝大多数普通人来说，这些能力被锁在了特定的界面里——你得打开一个网页，或者一个专用的App，进入一个专门的对话窗口，才能触及这些能力。这就像19世纪中期的电报：技术本身已经足够强大，但你必须去电报局，把你的消息交给一个专业的电报员，由他翻译成摩尔斯电码，再通过电线发出去。电报改变了世界，但它从未真正进入普通人的日常生活——直到电话把“发送远程消息”这个行为从专业场所搬到了每个人的家里。

OpenClaw 做的事情，某种程度上就是电话对电报做的那件事。 它不是又造了一个AI聊天窗口，而是把AI的能力搬进了你已经每天都在用的聊天窗口——WhatsApp、Telegram、Discord、Slack、Teams，随便哪一个。你不需要学习新的工具，不需要切换到新的应用，不需要改变任何习惯。你只是发了一条消息，只不过这次，消息的接收者不是一个人，而是一个能够理解你的意图并将其转化为行动的系统。

这就是相邻可能的魔力：当“发消息”这个全世界最普遍、最低摩擦的数字行为，与“AI代理执行任务”这个全新的技术能力相遇时，它们之间的那扇门就打开了。 门后面是一个我们还在探索的空间——一个聊天窗口不再只是传递文字的管道，而是变成了一个行动的操作系统的空间。

三、一个英国家庭的超市自动驾驶

让我把镜头切到另一个场景。

英格兰某座城市，一个有两个孩子的家庭。每周日晚上，这个家庭的其中一位家长都要完成同样一套令人疲惫的流程：打开 Tesco（英国最大的连锁超市）的网站，浏览本周的促销信息，根据这周的餐饮计划挑选食材，加入购物车，核对常购清单，选择一个配送时段，确认订单，输入支付信息。整个过程通常需要四十分钟到一个小时，而且每一步都充满了令人恼火的小决策——这个酸奶是不是换包装了？上次买的那个意面酱还有货吗？周三的配送满了，周四早上行不行？

有一天，这位家长在 Telegram 上给 OpenClaw 发了这样一条消息：“帮我去 Tesco 网站，按照这周的餐饮计划购物，优先选常购商品，预订最近的配送时段，下单前让我确认一下。”

然后，一些有趣的事情发生了。

OpenClaw 启动了它内置的浏览器工具——不是调用什么 Tesco 的API（Tesco并没有开放这样的API给普通消费者），而是像一个人类用户一样，打开了一个真实的浏览器窗口，导航到 Tesco 的网站，登录账户，然后一步一步地完成了整个购物流程。它读取了之前存储在工作区里的餐饮计划和常购清单（这些都是普通的 Markdown 文件），把它们翻译成了一系列具体的搜索和点击操作。在选择配送时段的时候，它挑了最早的可用选项。在所有东西都加入购物车之后，它把订单摘要发回了 Telegram，附带一个“确认下单”的按钮。

家长看了一眼清单，把西兰花换成了芦笋（孩子们上周说不想再吃西兰花了），然后点了确认。订单完成。整个过程，从发消息到确认，不到五分钟。

这个故事的核心洞察不在于“AI帮你买菜”这件事本身，而在于它揭示了一个被严重低估的事实：在2026年的互联网上，绝大多数服务仍然没有开放API。 你的银行、你的超市、你孩子学校的缴费系统、你的水电燃气账单、你的医院预约系统——它们都有网页界面，但没有供普通用户调用的编程接口。在过去，这意味着自动化的大门对这些服务是关闭的。你只能亲自去点那些按钮。

OpenClaw 的浏览器工具，实质上是把网页本身变成了一个通用API，把浏览器变成了一个万能适配器。这不是一个新想法——网页抓取和浏览器自动化已经存在了几十年。但过去，你需要编写精确的脚本来应对每一个网站的具体布局，而且一旦网站改版，脚本就会失效。现在，有了大语言模型的理解能力，浏览器自动化第一次变得真正“智能”了——代理能够理解页面上的内容，能够应对布局变化，能够在遇到意外情况时做出判断。

这是另一扇相邻可能的门：当AI的语言理解能力与浏览器自动化相结合，整个万维网——而不仅仅是那些开放了API的服务——都变成了可以被代理操作的对象。 有人在 OpenClaw 的社区里用了一个我很喜欢的比喻：“网页就是通用API，浏览器就是万能适配器。”这句话听起来简单，但它的含义是深远的。它意味着，AI代理的能力边界不再由API的可用性决定，而是由网页的可达性决定——而在今天的互联网上，几乎一切都可以通过网页访问。

更值得注意的是 OpenClaw 的设计哲学中对“可控自动驾驶”的强调。在 Tesco 购物的例子里，代理并没有从头到尾自行决定一切——它在关键节点（下单确认）停了下来，把决策权交还给人类。这就像特斯拉的辅助驾驶系统：大部分时候它在自动运行，但方向盘上始终有一双手。你可以在任何时候接管，可以在任何节点修改，可以随时叫停。这种“人在回路中”的设计，不是技术上的妥协，而是信任建立的必经之路。

四、酒窖里的九百六十二瓶

如果说 Tesco 的故事展示了 OpenClaw 在日常消费领域的相邻可能，那么接下来这个故事则展示了另一种可能性——个人化工具的即时生成。

在 OpenClaw 的一个社区讨论中，有人分享了这样一个案例：一位葡萄酒收藏爱好者，拥有一个规模可观的私人酒窖，里面存放着九百六十二瓶来自世界各地的葡萄酒。长期以来，他一直用一个Excel表格来管理这些藏酒——产区、年份、品种、购入价格、最佳饮用期、存放位置，等等。但Excel表格有一个根本性的问题：它是一个被动的数据容器，你必须主动去查询它，而且它无法理解你的意图。当你想知道“今晚吃烤羊排，应该开哪一瓶”的时候，Excel无法给你答案。

这位收藏者在 Telegram 上向 OpenClaw 发了一条消息，大意是：“帮我建一个酒窖管理系统，把这个CSV文件导入进去。”然后，OpenClaw 做了一件在传统软件开发流程中需要数天甚至数周才能完成的事情：它在几分钟之内，在本地创建了一个完整的酒窖管理“技能”（skill）。

这里需要解释一下 OpenClaw 的“技能”（Skills）系统。在 OpenClaw 的架构里，技能是一种可复用的能力模块——本质上就是一个文件夹加上一个名为 SKILL.md 的描述文件。这个描述文件用自然语言定义了技能的功能、触发条件和执行逻辑。技能可以调用各种工具，可以访问本地文件，可以与其他技能协作。更重要的是，技能可以被分享——通过一个叫做 ClawHub 的公共注册中心，任何人都可以搜索、安装、更新和发布技能。

那位酒窖收藏者的技能被创建出来之后，他就可以在聊天窗口里用自然语言查询自己的藏酒了。“这个月有哪些酒到了最佳饮用期？”“波尔多的酒还剩多少瓶？”“今晚吃海鲜，推荐一瓶白葡萄酒。”这些问题都能得到基于他的实际藏酒数据的精准回答。

这个案例让我想起了生物学里的一个概念——“外骨骼”。昆虫的外骨骼不是一个万能的结构，它是为每一种昆虫的特定生活方式量身定做的。甲虫的外骨骼和蝴蝶的外骨骼完全不同，因为它们面对的环境挑战完全不同。OpenClaw的技能系统，本质上是一种让每个人都能按需生成自己的“数字外骨骼”的机制。 你的需求是独特的，所以你的工具也应该是独特的——而现在，定制工具的成本被压缩到了一条聊天消息的距离。

这里面隐藏着一个关于软件进化方式的深刻转变。传统上，软件是由专业开发者为大量用户构建的通用产品——你去应用商店搜索“酒窖管理”，找到一个别人开发的App，然后适应它的逻辑。但在 OpenClaw 的世界里，这个流程被倒转了：不是你适应软件，而是软件适应你。 用户描述需求，代理生成工具，工具变成可分享的技能。这不是传统意义上的“编程”，但它确实是一种创造——一种由自然语言驱动的、即时的、个人化的创造。

而当这些个人化创造通过 ClawHub 被分享出去的时候，一种新的生态就开始涌现。某个人为自己创建的酒窖管理技能，可能会被另一个收藏者发现、安装、修改、增强，然后再分享回去。这是一个典型的“液态网络”（liquid networks）的场景——不同的想法和工具在一个足够开放、足够流动的环境中碰撞、混合、进化。

五、液态网络与神经系统

说到液态网络，让我换一个角度来看 OpenClaw 的架构设计。

在我的研究中，“液态网络”是一个用来描述创新最容易发生的环境的概念。想象一下珊瑚礁——它是海洋中生物多样性最高的地方，不是因为那里的水特别营养丰富，而是因为珊瑚礁的物理结构创造了无数的微环境、缝隙和通道，让不同的物种得以在极近的距离内共存和互动。类似地，历史上最具创新力的城市——佛罗伦萨、维也纳、硅谷——都是因为它们创造了某种让不同背景的人和想法在足够近的距离内频繁碰撞的环境。

OpenClaw 的架构设计者用了一个“神经系统”的隐喻来描述他们的系统，这个隐喻比他们可能意识到的更加深刻。

在这个架构里，“网关”（Gateway）扮演着中枢神经系统的角色——它是一个长期运行的进程，统一管理着与各种消息平台的连接。“频道”（Channels）是感官输入——WhatsApp、Telegram、Discord、Slack、Teams，每一个都是系统感知外部世界的一个通道。“工具和节点”（Tools/Nodes）是肢体和工具箱——浏览器控制、Canvas可视化、设备节点（摄像头、屏幕录制、位置信息、命令执行）、定时任务。“技能”（Skills）是习得的行为模式。而“记忆”（Memory）——这可能是最有趣的部分——是工作区里的纯 Markdown 文件，本质上是一份可编辑的、透明的“自我”。

但让我真正感兴趣的，不是这个隐喻的巧妙，而是这个架构如何创造了一个“液态网络”式的环境。

在传统的软件架构中，不同的工具和服务之间的连接通常是刚性的——每一个集成都需要专门的代码、专门的接口、专门的维护。这就像一个固态晶体：结构稳定，但缺乏灵活性。在 OpenClaw 的架构里，大语言模型充当了一种“溶剂”，把原本刚性的连接变成了流动的。你不需要为“摄像头拍照→AI分析→发送到群聊”这个流程编写专门的集成代码——你只需要用自然语言描述你想要的流程，语言模型会动态地把不同的工具和能力“溶解”在一起，形成一个临时的、特定的工作流。

这种流动性有一个深远的后果：它大幅降低了“组合创新”的门槛。 在过去，把两种工具连接在一起需要技术专业知识——你得懂API、懂编程、懂系统集成。现在，连接的介质变成了自然语言，而自然语言是每个人都掌握的“编程语言”。这意味着，能够参与组合创新的人群规模，从数百万专业开发者扩展到了数十亿普通用户。

回想一下古腾堡的印刷术。印刷术的革命性不仅仅在于它让书籍变得更便宜——更深层的影响在于，它把“参与知识传播”这件事从抄写僧侣的小圈子扩展到了更广泛的人群。当更多人能够阅读和出版，更多的想法就能在更大的网络中碰撞，而碰撞产生了科学革命、宗教改革和启蒙运动。OpenClaw 这类平台正在做的，是把“参与自动化创造”这件事从程序员的小圈子扩展到任何会发消息的人。 我们还不知道这种扩展会带来什么样的“科学革命”，但历史告诉我们，当参与创造的人群规模发生数量级的跳跃时，总会有意想不到的东西涌现出来。

六、口袋里的编程工厂

让我再讲一个故事。

某天，一个开发者在地铁上用手机打开了 Telegram。他正在开发一个 iOS 应用，前一晚在电脑上写了几个小时的代码，距离可以推送给测试用户的版本只差最后几步了。但他已经出门了，电脑在家里。

他在 Telegram 上给 OpenClaw 发了一条消息：“把我昨晚写的代码 build 一下，跑一遍测试，如果通过的话就部署到 TestFlight。”

然后他把手机放回口袋，开始读地铁上的电子书。

十五分钟后，手机震动了。Telegram 上出现了一条来自 OpenClaw 的消息：“构建完成，17个测试全部通过，已部署到 TestFlight，版本号1.3.2。测试用户应该已经收到更新通知了。”

这个场景的意义在于，它完全颠覆了我们对“编程”这项活动的空间想象。在传统的认知里，编程是一件需要坐在电脑前、打开IDE、在大屏幕上写代码的事情。它被绑定在一个特定的物理环境里。但当 OpenClaw 把编程工具接入了手机上的聊天软件，“编程”就从一个特定的地点和姿态中解放出来了，变成了一种可以在任何时间、任何地点、用任何设备发起的行为。

这让我想起了笔记本电脑对台式机的颠覆。笔记本电脑的处理能力在很长一段时间里都不如台式机，但它最终成为了主流，不是因为它更强大，而是因为它把计算从固定的桌面上解放了出来。同样的逻辑在这里重演：通过手机聊天窗口触发的编程工作流可能不如坐在IDE前那么精细，但它把“启动编程任务”这个行为的摩擦降到了几乎为零。

更有趣的是 OpenClaw 社区里出现的“多智能体路由”的玩法。一些高级用户会在自己的 OpenClaw 实例里配置多个专门化的代理——一个负责前端代码，一个负责后端逻辑，一个负责代码审查，一个负责部署。当用户发出一条指令时，系统会自动把任务路由给最合适的代理，或者在多个代理之间协调。这就像一个微型的软件团队，全天候在线，等待指令。

有人在社区里展示了一个“14+智能体梦之队”的编排案例——十四个以上的代理，各自有自己的专长和角色，通过一个主控代理进行调度。这已经不再是“一个AI助手”的概念了，这是一个可以用自然语言管理的微型组织。

七、晨间指挥台与缓慢的灵感

在继续深入之前，我想暂停一下，讲一个关于“缓慢的灵感”（slow hunch）的故事。

“缓慢的灵感”是我在研究创新史时反复遇到的一个模式。我们倾向于把创新想象成一个灵光乍现的时刻——牛顿被苹果砸了脑袋，阿基米德从浴缸里跳出来。但实际上，大多数重要的创新都来自一种更缓慢、更渐进的过程：一个模糊的直觉在很长一段时间里缓慢发酵，直到它遇到了另一个互补的想法，两者融合在一起，才最终成为一个完整的洞察。

OpenClaw 社区里最受欢迎的用例之一，恰好与这个模式形成了有趣的呼应——“晨间指挥台”。

具体的做法是这样的：用户设置一个每天早上七点的定时任务（cron）。到了时间，OpenClaw 会自动从用户的日历、邮箱、任务管理工具和其他数据源中抓取信息，然后在 Telegram 上推送一份精心编排的“每日摘要”。但这不是一个简单的信息聚合——摘要里包含了可执行的按钮，用户可以直接点击“批准”“拒绝”“稍后处理”。它还会用 Canvas 工具生成可视化的仪表盘——今天的会议时间线、待办事项的优先级矩阵、这周的进度图表。

这个“晨间指挥台”的设计，表面上看是一个效率工具——它把你每天早上花在各个App之间切换查看信息的时间压缩到了几分钟。但在更深的层面上，它做了一件更有价值的事情：它为“缓慢的灵感”创造了一个日常的培养皿。

这是什么意思呢？当你每天早上在同一个地方（你的聊天窗口）看到来自不同领域的信息——工作项目的进度、个人笔记的碎片、日历里即将到来的会议、邮箱里的一封有趣的来信——这些信息就在你的意识里形成了一种“缓慢的叠加”。你可能不会立刻注意到它们之间的联系，但随着时间的推移，某个早上，当你看到一条关于项目延期的通知和一封关于新技术的邮件并排出现时，一个之前模糊的想法突然变得清晰了：“如果把那个新技术用在这个项目上，延期的问题可能就解决了。”

这就是缓慢的灵感发挥作用的方式。它需要一个环境——一个让不同领域的信息能够在足够近的距离内频繁相遇的环境。而“晨间指挥台”恰好提供了这样的环境。

这里面有一个关于界面设计的微妙洞察值得强调。OpenClaw 的团队把他们的交互模式称为“A2UI”——某种“代理到用户”的界面范式。在传统的用户界面中，人类主动查看、点击、操作，信息被动地等待被发现。但在“晨间指挥台”里，这个关系被反转了：代理主动推送经过筛选和编排的信息，人类做的是判断和决策。 这不是一个微小的变化——这是一种根本性的界面哲学转变，从“人类去找信息”到“信息来找人类”，从“用户操作界面”到“界面服务用户”。

八、当“实习生”拥有了删除权限

每一个关于创新的故事，如果诚实的话，都必须包含一个关于风险的章节。

电话让远程通信变得触手可及，但也让诈骗电话成为可能。印刷术让知识大众化，但也让虚假信息规模化传播。汽车让个人出行自由化，但也带来了交通事故的巨大代价。技术打开的每一扇相邻可能的门，门后面既有机遇也有危险，而且它们往往是同一枚硬币的两面。

OpenClaw 的故事也不例外。

在社区的一次讨论中，一位用户分享了一个令人不安的经历：他让 OpenClaw 的代理（ClawBot）帮他整理邮箱，结果代理“过于热心”地执行了大量删除操作。那些被删除的邮件中，有些可能是重要的，但已经无法恢复了。

安全研究者们很快指出了一个尖锐的观察：OpenClaw 的代理更像是一个“过于热心的实习生”——它非常想把事情做好，它有能力操作各种工具，但它缺乏判断“什么事情不应该做”的经验和边界感。 一个实习生如果犯了错，你可以教他、纠正他，但如果在他犯错之前你已经给了他管理员权限，那么后果可能是不可逆的。

这个比喻精准地捕捉了当前AI代理面临的核心安全挑战。让我展开讲一下。

首先是“提示注入”（prompt injection）的问题。当你的代理在浏览器里自动操作网页时，网页上的内容可能包含恶意的指令——它可能伪装成正常的文本，但实际上是在试图劫持代理的行为。想象一下，你让代理帮你查看一封邮件，而邮件里嵌入了一段精心构造的文字，让代理把你的邮件转发给一个陌生的地址。这不是科幻小说——这是安全研究者已经在实验中验证过的攻击向量。

然后是“日志投毒”的风险。OpenClaw 的记忆系统是基于纯文本的 Markdown 文件。这种设计的好处是透明和可编辑，但它也意味着，如果代理在工作过程中接收到了被污染的信息，这些信息可能会被写入记忆文件，从而持久地影响代理未来的行为。

面对这些风险，OpenClaw 社区和设计者们发展出了一套多层次的安全策略。

第一层是“关键动作二次确认”。 就像 Tesco 购物例子里那样，在涉及不可逆操作（支付、删除、发送重要信息）的时候，代理会暂停并请求人类确认。这是最直观也最有效的安全机制——在人类和风险之间插入一个“你确定吗？”的间隙。

第二层是“权限分层与工具最小集”。 不是所有的代理都需要所有的工具。一个负责查看天气的代理不需要文件删除权限，一个负责购物的代理不需要命令行执行权限。通过限制每个代理可以调用的工具集合，系统可以大幅减少“过于热心的实习生”造成破坏的可能性。

第三层是“技能供应链意识”。 当你从 ClawHub 安装一个别人创建的技能时，你实际上是在让一段外部代码在你的机器上运行。这就像从应用商店下载软件一样——你需要信任它的来源。ClawHub 引入了 VirusTotal 扫描和社区审核机制，但更根本的安全措施是用户自己的警觉性：在安装一个技能之前，检查它的 SKILL.md 文件，理解它会做什么，用到哪些工具，访问哪些数据。

但在所有这些技术性的安全措施之上，OpenClaw 的故事提出了一个更深刻的哲学命题：代理软件的边界，不只是靠进程隔离、权限控制和沙箱来维持的——它还取决于语言、意图与执行之间的设计。

什么意思呢？当你对一个人类助理说“帮我整理一下邮箱”，你们之间有大量的共享上下文和隐含假设——“整理”大概不意味着“删除一切”，“一下”暗示这应该是一个温和的、可逆的操作。但当你对一个AI代理说同样的话时，这些隐含假设不一定被正确解读。代理可能会把“整理”理解为“归档所有已读邮件”，也可能理解为“删除所有两周前的邮件”。意图和执行之间的鸿沟，在人类之间由文化、经验和常识来填充，在人机之间则需要由精心的设计来填充。

这是当前AI代理领域最重要、也最容易被忽视的设计挑战。不是“如何让代理做更多的事”，而是“如何让代理理解什么事不该做”。不是“如何给代理更多的权限”，而是“如何让权限的边界与用户的真实意图精确对齐”。

九、多智能体的寒武纪

在地球的历史上，有一个被古生物学家称为“寒武纪大爆发”的时期——大约五亿四千万年前，在一个地质学意义上极其短暂的时间窗口里，几乎所有主要的动物门类突然出现了。在那之前的几十亿年里，生命基本上只有单细胞的形式；然后，仿佛有人按下了一个开关，复杂的多细胞生命在各种方向上同时爆发。

关于寒武纪大爆发的原因，有很多假说。其中一个最有说服力的解释与“相邻可能”直接相关：在某个时间点，基本的生物化学构建块（蛋白质折叠方式、细胞间通信机制、遗传调控工具）终于积累到了一个临界数量，使得全新的组合方式突然变得可能。生命不是线性地从简单进化到复杂，而是在一个转折点上突然“爆发”——因为可能的组合空间在那一刻急剧膨胀了。

我在 OpenClaw 社区里看到的，让我隐约嗅到了类似的气息。

有人搭建了一个“家庭管家”代理，专门处理家庭事务——购物清单、家务分配、账单提醒、孩子的学校缴费（用浏览器工具自动在 ParentPay 系统上完成操作）。同时，他还有一个独立的“工作助理”代理处理职业相关的事务，和一个“创作编辑”代理帮助他写作和编辑个人博客。这三个代理互相隔离——家庭管家不知道工作项目的细节，工作助理不会干预家庭购物，创作编辑专注于文字。

这种多智能体的分工与隔离模式，很像生物体内的器官分化。在最早期的多细胞生命中，每个细胞都是“全能”的，它们没有分化，没有专门化。但随着进化的推进，细胞开始分化成不同的类型——有的负责消化，有的负责运动，有的负责感知。这种分化不是效率的降低，而是复杂性的跃升。 当不同类型的细胞可以专注于自己最擅长的事情，同时通过化学信号相互协调，整个有机体能做的事情就远远超越了任何单个细胞的能力。

OpenClaw 里那个“14+智能体梦之队”的编排案例，就是这种分化逻辑的极端表达。十四个以上的代理，每一个都有自己的专长：有的擅长信息检索，有的擅长代码编写，有的擅长数据分析，有的擅长文案创作，有的擅长日程管理。它们通过一个主控代理进行调度和协调，就像一个交响乐团的指挥，把不同乐器的声音编织成一首完整的乐曲。

这里面有一个更深层的趋势值得注意。在过去的软件历史中，“应用”（app）是能力的基本单位——你需要一个App来做一件事。但在多智能体的世界里，“代理”（agent）开始取代“应用”成为能力的基本单位。而且，和应用不同的是，代理是流动的、可组合的、可即时生成的。你不需要去应用商店搜索和下载，你只需要描述你的需求，一个新的代理就可以被创建出来。

如果“应用”是数字世界的固态结构，那么“代理”就是数字世界的液态形式。 从固态到液态的转变，意味着数字工具不再是预制的、固定的产品，而是变成了可以根据需求实时凝聚和重组的流动能力。这就是为什么我用“液态网络”来形容这个正在涌现的新生态——在这个网络里，能力是流动的，组合是动态的，创新是涌现的。

十、“你的助手，你的机器，你的规则”

OpenClaw 的口号是：“Your assistant. Your machine. Your rules.”——“你的助手，你的机器，你的规则。”这不仅仅是一句营销口号。

让我用一个历史类比来说明为什么这句话很重要。

在个人电脑出现之前，计算是一种中心化的资源。如果你想使用计算能力，你需要去找一台大型机或者小型机——它们通常属于某个大公司、大学或政府机构。你使用它们的时候，要遵守它们的规则，在它们的系统上运行，受它们的管理员管控。这不是一个自由的环境。

然后，在1970年代后期和1980年代初期，个人电脑革命发生了。突然之间，计算不再是中心化的资源，而是你自己书桌上的一个设备。你拥有了自己的计算，你可以在上面运行任何你想运行的软件，存储任何你想存储的数据，而不需要任何人的许可。 这种所有权的转移，是过去五十年数字革命的根本驱动力之一。

但在AI时代，我们看到了一种令人不安的“再中心化”趋势。当你使用 ChatGPT、Claude 或其他云端AI服务时，你的对话、你的数据、你的意图，都在别人的服务器上被处理。你依赖别人的基础设施，使用别人的API密钥，遵守别人的使用条款。AI不是“你的”，它是你“借来的”。这就像我们回到了大型机的时代——只不过这次的大型机在云端。

OpenClaw 的本地运行模式，是对这种趋势的一次有意识的反抗。它运行在你自己的机器上——可以是你的电脑，可以是你家里的服务器，可以是一个树莓派。你的数据留在本地，你的对话不经过任何第三方服务器，你的API密钥由你自己管理。代理执行的每一个操作，都发生在你自己的基础设施上。

这不仅仅是一个隐私功能——这是一种新的信任叙事。 在这个叙事里，AI不再是“借来的大脑”，而是“自家的劳动力系统”。你拥有它，你控制它，你定义它的边界。这种所有权的感觉，对于AI代理的普及来说可能至关重要——因为当你把越来越多的日常事务委托给一个AI代理时，你需要一种深层的信任，而这种信任很难建立在“它运行在别人的服务器上”这个基础之上。

这里面也有一个关于开源的重要故事。OpenClaw 是完全开源的，这意味着任何人都可以审查它的代码，理解它的行为，修改它的逻辑。在安全和信任至关重要的AI代理领域，开源不仅仅是一种开发模式，而是一种信任基础设施。你不需要信任 OpenClaw 的开发者会做正确的事——你可以自己验证。

十一、缓慢的灵感正在发酵

现在，让我把前面讲的各条线索汇聚在一起。

一台屋顶上的摄像头，在天空好看的时候自动拍照发到家庭群聊。一位家长在手机上发一条消息，四十分钟的超市购物流程被压缩到了五分钟。一位葡萄酒收藏者在聊天窗口里对着他的九百六十二瓶藏酒提问。一个开发者在地铁上用 Telegram 部署了一个 iOS 应用。一个家庭运行着三个互相隔离的AI代理，分别管理家务、工作和写作。一个安全研究者警告说，这个热心的数字实习生可能会在你的邮箱里造成不可逆的破坏。

这些故事看起来千差万别，但它们都指向同一个底层趋势：我们正在见证“意图”到“行动”之间的距离被一种新的方式急剧压缩。 这种压缩发生在一个我们已经无比熟悉的界面里——聊天窗口，发生在我们已经拥有的设备上，使用我们已经掌握的唯一“编程语言”——自然语言。

从相邻可能的角度来看，OpenClaw 处在一个关键的交叉点上。大语言模型的成熟提供了理解和推理能力；聊天平台的普及提供了零摩擦的入口；浏览器自动化技术提供了与整个互联网交互的能力；开源社区提供了信任和协作的基础；本地计算的回归提供了所有权和隐私的保障。这些要素中的每一个都不是新的，但它们以这种特定的方式组合在一起——这是新的。就像考夫曼描述的那样，每一种新的组合都打开了一扇门，门后面是一组新的可能性。

但我想用一个更审慎的音符来结束这个故事。

每一次技术革命都有一个共同的模式：早期的兴奋和想象往往会超越现实——不是因为技术不够好，而是因为我们还没有学会如何与它共处。汽车刚发明的时候没有交通规则，无线电刚出现的时候没有频谱管理，互联网刚普及的时候没有隐私法规。每一种新的能力都需要配套的新的智慧——关于何时使用它、如何使用它、以及最重要的，何时不使用它。

OpenClaw 社区正处于这个“学习如何与新能力共处”的早期阶段。他们在摸索什么样的任务适合委托给代理，什么样的操作需要人类确认，什么样的权限边界是安全的，什么样的技能供应链是可信的。这些问题没有现成的答案——它们需要在实践中被一点点摸索出来，就像早期的汽车驾驶者们在没有红绿灯的路口学会了减速和观察一样。

这，才是真正令人兴奋的地方。不是某个具体的功能有多酷，不是某个案例有多炫，而是一个全新的探索空间刚刚被打开。在这个空间里，每个人的聊天窗口都可能变成一个行动的操作系统，每一条消息都可能成为一个指令，每一个日常任务都可能被重新想象。 这是一片巨大的相邻可能——我们才刚刚推开第一扇门。

就像达尔文的珊瑚礁一样，最丰富的生态系统往往不是设计出来的，而是在合适的条件下自发涌现的。OpenClaw 和它所代表的这一类平台，正在创造这样的条件——一个足够开放、足够流动、足够低门槛的环境，让数十亿人的日常创意和需求可以在其中碰撞、组合、进化。

至于这个生态系统最终会长成什么样子？

没有人知道。但这恰恰是最好的部分。因为在相邻可能的世界里，最有趣的东西，永远是你还没有打开的那扇门后面的那个。

发表于 | 分类于

风格参考：万维钢（《精英日课》作者）—— 跨学科引证，框架式拆解，加粗关键洞察，用数据和类比交叉验证每个论点。

引子：你最强大的AI入口，可能是你最无聊的那个App

2025年以来，AI圈有一种弥漫的焦虑：我们需要为AI Agent设计全新的交互界面。有人做了精美的Dashboard，有人做了专用的IDE，有人甚至尝试用AR眼镜来操控Agent。

但有一个开源项目反其道而行之，选择了一个所有人都觉得“太简陋”的入口——你手机上的聊天软件。WhatsApp、Telegram、Discord、Slack、Teams……你每天用来发“收到”“好的”“哈哈哈”的那个窗口。

这个项目叫OpenClaw，口号是“Your assistant. Your Machine. Your rules.”

乍看之下，这像是在开倒车。我们好不容易从命令行进化到图形界面，从图形界面进化到触屏交互，现在你告诉我最先进的AI操作方式是……发消息？

但仔细想想，这里面有一个被大多数人忽略的洞察：最好的新界面，不是人们从未见过的界面，而是人们已经用了十年、连想都不用想就会用的界面。

这篇文章要讲的，不仅仅是一个开源项目。它触及了一个更大的问题——在AI Agent时代，“入口”“信任”和“控制”之间的三角关系，正在被重新定义。

一、认知经济学：为什么“一条消息”比“一个App”更值钱

1.1 希克定律与界面摩擦

1952年，英国心理学家William Edmund Hick做了一个经典实验：给被试面前摆n盏灯，每盏灯对应一个按钮，灯亮了按对应的按钮。结果发现，选项每翻一倍，反应时间不是翻倍，而是增加一个固定常数——这就是著名的希克定律（Hick’s Law）。

希克定律的推论是：减少选项数量是降低认知负荷最有效的方法。

现在把这个定律套到AI Agent的交互设计上。一个典型的AI Agent平台，你需要：打开浏览器→登录平台→选择Agent→配置参数→输入指令→等待结果。每一步都是一个决策点，每一个决策点都在消耗你的认知预算。

OpenClaw把这个链条压缩成了什么？打开聊天窗口→发一条消息。 没了。

从认知科学的角度看，这不是简化，这是范式转换。它把“意图→行动”之间的决策节点从6个以上压缩到了1个。 按照希克定律的对数关系，这意味着认知摩擦降低了至少70%。

1.2 旧习惯的复利效应

行为经济学家Richard Thaler——2017年诺贝尔经济学奖得主——提出过一个核心概念叫“助推”（Nudge）。他发现，改变人的行为最有效的方式不是教育，不是激励，而是改变默认选项。

养老金计划的经典案例：当公司把401(k)从“opt-in”（默认不参加，你要主动报名）改成“opt-out”（默认参加，你不想参加要主动退出），参与率从不到50%飙升到超过90%。行为没变，人还是那些人，只是默认选项变了。

OpenClaw做的事情本质上一样。它没有创造新行为（你不需要学一个新App），而是把旧行为的默认产出从“文字交流”升级成了“行动执行”。你还是在发消息，但消息的另一头不再只是一个人——而是一整套可以执行任务的Agent系统。

这就是为什么它比任何精心设计的新界面都更有爆发力。新界面需要用户学习成本，而聊天窗口的学习成本是零，因为你十年前就已经“学会”了。

1.3 神经系统隐喻：一个比你想的更精确的类比

OpenClaw的架构设计者用了一个“神经系统”隐喻来描述整体架构。这不只是市场传播的修辞手法，它在结构上确实高度同构。

  • Gateway = 中枢神经系统。 一个长期运行的进程，统一管理所有消息平台的连接。就像你的脊髓和脑干——永远在线，负责路由所有信号。
  • Channels = 感官输入。 WhatsApp、Telegram、Discord等消息渠道，就是系统的眼睛、耳朵、皮肤。每个Channel采集不同来源的信息，汇总到Gateway。
  • Tools/Nodes = 肢体与工具箱。 浏览器控制、Canvas可视化、设备节点（摄像头、屏幕录制、位置、命令行）、定时任务（cron）。这是系统的“手脚”——感知到信息之后，能够对物理世界和数字世界采取行动。
  • Skills = 习惯与技能包。 可复用的能力模块，每个Skill就是一个文件夹加一份SKILL.md说明书。可以通过ClawHub搜索、安装、更新、发布——就像人类的程序性记忆，一旦学会骑自行车，就不用每次重新学。
  • Memory = 可编辑的“自我”。 工作区里的纯Markdown文件，长期记忆默认只在私聊的主会话中加载。

有趣的是，这个隐喻在一个关键维度上比人类神经系统更好：它的记忆是可编辑的。 你打开一个Markdown文件就能修改Agent的“性格”和“知识”。想象一下，如果人类能打开自己的大脑，删掉一段不愉快的记忆，或者手动写入一项新技能——OpenClaw的Memory系统就是这样工作的。

这种架构的深层含义是：Agent不再是一个你“使用”的工具，而是一个你“塑造”的实体。

二、信任重构：为什么AI不该住在别人家

2.1 一个反直觉的信任问题

大多数人对AI的信任焦虑是这样的：“AI会不会说谎？会不会犯错？会不会被利用？”

这些确实是问题。但OpenClaw指向了一个更底层的问题——你的AI住在谁家？

经济学家Oliver Hart和Sanford Grossman在1986年提出了一个影响深远的理论：不完全契约理论（Incomplete Contract Theory）。核心思想是：在复杂交易中，你不可能写出一份覆盖所有意外情况的完美合同。 那么当合同没写到的情况发生时，谁说了算？答案是：谁拥有资产，谁就拥有“剩余控制权”。

Hart因为这个理论获得了2016年诺贝尔经济学奖。

现在把这个框架套到AI Agent上。当你使用一个云端AI服务时，“资产”——数据、模型、算力、日志——全在服务商手里。当出现合同没有覆盖的情况（比如服务商调整了隐私政策，或者你的对话数据被用于训练了新模型），剩余控制权在服务商手里。你能做的只有接受或离开。

OpenClaw的“本地运行+你的钥匙”叙事，本质上是在争夺剩余控制权。 基础设施你选，API密钥你管，数据你控。AI不再是“借来的大脑”，而是“自家的劳动力系统”。

这不是意识形态，这是产权经济学。

2.2 从“信任人”到“信任架构”

密码学领域有一个概念叫“零信任架构”（Zero Trust Architecture）。传统安全模型假设内部网络是可信的——城堡护城河模型。但零信任架构认为：不要信任任何人，验证一切。

OpenClaw的本地运行模式就是把零信任思想应用到了AI Agent领域。你不需要信任OpenClaw的开发者会善待你的数据——因为数据根本就没离开你的机器。你不需要信任云服务商不会滥用你的API调用——因为密钥在你手里。你甚至不需要信任Agent本身——因为它的记忆、技能、权限全是你配置的Markdown文件。

这里有一个精妙的设计选择：信任的锚点从“人”（服务商的承诺）转移到了“架构”（系统的物理约束）。 你不用相信任何人的善意，你只需要相信一个事实：运行在你机器上的进程，物理上无法把数据传给你不允许的地方。

社会学家Niklas Luhmann区分了两种信任：人际信任（trust in persons）和系统信任（trust in systems）。人际信任依赖于对特定个体的了解和判断，扩展性差，脆弱性高。系统信任依赖于制度和架构的可验证性，可以规模化，也更健壮。

OpenClaw的信任模型是从人际信任到系统信任的跃迁。 这在人类制度史上发生过很多次——从熟人借贷到银行系统，从口头承诺到法律合同，从中心化记账到区块链。每一次跃迁都释放了巨大的协作潜力。

2.3 浏览器：一个被低估的万能适配器

OpenClaw最让我意外的能力不是AI聊天，而是浏览器控制。

有一个真实案例：一个用户用OpenClaw完成了Tesco超市的“购物自动驾驶”。流程是这样的——Agent根据每周餐饮计划，生成购物清单；然后打开Tesco网站，逐一搜索并添加商品到购物车；预订配送时间段；最后确认订单。全程没有调用任何API，完全通过浏览器操作完成。

这听起来像一个方便的自动化小工具。但它背后有一个被严重低估的洞察：

全世界绝大多数数字服务都没有公开API。 你的银行没有，你孩子学校的午餐预订系统没有，你所在城市的政务服务网站没有。在API驱动的自动化世界里，这些服务是“暗物质”——理论上存在，但传统自动化工具根本触达不了。

浏览器工具改变了这个格局。网页就是通用API，浏览器就是万能适配器。 任何人类能在浏览器里完成的操作，Agent理论上都能完成。这一下子把Agent的能力边界从“有API的世界”扩展到了“有网页的世界”——后者比前者大了不止一个数量级。

复杂性科学家Stuart Kauffman提出过“邻近可能”（Adjacent Possible）的概念：创新不是凭空发生的，它总是在现有能力的“邻居”中产生。有了浏览器工具之后，Agent的“邻近可能”空间突然膨胀了——昨天还不可能被自动化的日常任务，今天突然变成了一条消息就能搞定的事情。

三、五个“爆款原型”：从晨间指挥台到多Agent合伙制

接下来我要讲五个已经在OpenClaw社区中跑通的创新原型。这不是概念验证，是真实用户在真实场景中的实践。每一个原型背后都对应着一种“人与Agent协作”的新模式。

3.1 原型一：晨间指挥台——把被动接收变成主动指挥

想象一下这个场景：每天早上7:00，你的Telegram弹出一条消息。不是新闻推送，不是天气预报，而是一份个性化的行动摘要——今天的日程、待处理的邮件摘要、需要你决策的事项，旁边配着可执行的按钮。你不需要打开日历App、邮箱App、项目管理App分别查看。你只需要在一个聊天窗口里，用几个按钮就能完成“决策→下达→执行”的完整闭环。

技术实现并不复杂：用cron定时任务在凌晨触发数据收集，Canvas做可视化呈现，A2UI（Agent-to-User Interface）生成交互按钮。

但这个原型真正有趣的地方不在技术，而在认知模式的转变。

管理学家Henry Mintzberg在研究CEO日常行为时发现了一个反直觉的事实：大多数管理者的一天不是“主动规划→执行”，而是“被动响应→救火”。 他们的时间被各种打断切割成碎片，真正用于深度思考和战略决策的时间少得可怜。

晨间指挥台的设计哲学恰好针对这个问题：把一天中认知资源最充沛的时段（早晨），从“被动接收信息”变成“主动指挥行动”。 你不是在翻看各种App的通知，而是在一个统一的界面里做出今天最重要的几个决策。

这是任务管理的范式升级——从“清单”到“指挥系统”。

3.2 原型二：浏览器自动驾驶——可控的自动化

前面提到的Tesco购物案例只是冰山一角。社区里还有人用浏览器工具实现了ParentPay学校餐食的自动预订——这种系统连API都没有，传统自动化工具完全无能为力。

但这里有一个关键的设计决策：这不是“全自动驾驶”，而是**“可控的自动驾驶”**。

自动驾驶汽车行业有一个SAE分级系统（从L0到L5）。L5是完全无人驾驶，乘客可以睡觉；L3是有条件自动驾驶，关键时刻需要人类接管。OpenClaw的浏览器自动化更接近L3——每一步操作可解释，关键节点需要二次确认，任何时候用户都可以接管控制。

这个选择非常聪明。在Agent技术的当前阶段，L3比L5更有价值。 原因不仅是技术成熟度，更是心理学。

心理学家Ellen Langer做过一个著名的实验：让两组老年人住进相同的环境，一组被告知“一切由我们安排”，另一组被告知“你可以自己决定房间布置、活动安排”。几周后，第二组不仅心理状态更好，连身体健康指标都显著优于第一组。这就是“控制感”（perceived control）的力量。

在人与Agent的协作中，用户是否感到“我随时可以接管”，直接决定了他愿不愿意把任务交给Agent。 全自动听起来酷，但会让人焦虑。可控的自动化则让人放心——我放手是因为我选择放手，而不是因为我无法干预。

3.3 原型三：随身编程工厂——手机发消息，电脑出产品

这个案例让我作为技术从业者感到震动：有人通过Telegram发了一句话指令，让家里的Mac mini执行了完整的iOS应用构建和发布流程——代码编译、签名、上传到TestFlight，一气呵成。

手机变成了遥控器，家里的电脑变成了生产线。

更高级的玩法是多Agent路由：一个Agent负责前端，一个负责后端，一个负责测试，一个负责部署。你在手机上发一条“给登录页面加个忘记密码的链接”，消息被路由到前端Agent，它改完代码后通知测试Agent跑回归测试，测试通过后通知部署Agent上线。

这让我想到经济学家Ronald Coase在1937年那篇改变了整个组织理论的论文——《企业的性质》。Coase问了一个简单但深刻的问题：如果市场那么高效，为什么还需要企业？ 他的答案是：交易成本。当市场中的协调成本（找人、谈判、签约、监督）超过企业内部的管理成本时，企业就有存在的理由。

多Agent路由系统本质上是在做同一件事：当单个Agent无法胜任复杂任务时，你不是去找一个更强的Agent，而是用多个专业Agent组成一个“微型企业”。 路由器就是CEO，各Agent就是部门，Skill文件就是岗位说明书。

Coase的交易成本理论在AI Agent时代获得了全新的适用场景：Agent之间的协调成本，将决定多Agent系统的最优“企业规模”。

3.4 原型四：传感器诗人——不是监控，是生活的自动生成

这是五个原型里最出人意料的一个。

有人在屋顶装了一个摄像头，连接到OpenClaw。系统不是用它来做安防监控，而是——当天空特别好看的时候，自动拍一张照片，配上一段文案，发到群聊里。

还有人用OpenClaw连接空气净化器，根据室内空气质量自动调节风速。有人连接了3D打印机，用聊天消息控制打印任务。

这些案例单独看很有趣，但合在一起看，指向了一个更深层的趋势：Agent正在从“数字世界的操作者”变成“物理世界的感知者和行动者”。

麻省理工学院的Kevin Ashton在1999年提出“物联网”（Internet of Things）这个概念时，预言有一天计算机将能够自主感知物理世界。二十多年过去了，物联网的大多数应用仍然停留在“数据采集→仪表盘展示”的阶段。你能看到温度曲线图，但系统不会主动帮你做什么。

OpenClaw的传感器集成打破了这个僵局。它在“感知”和“行动”之间加入了“理解”这个环节——AI能够理解传感器数据的含义，并自主决定该采取什么行动。 摄像头不再只是记录画面，它“看到”了美丽的天空；空气传感器不再只是显示数字，它“感知”到了空气质量的下降。

诗意一点说，Agent让机器学会了“审美”和“关心”。务实一点说，这是物联网从“可观测”到“可行动”的关键跨越。

3.5 原型五：多Agent合伙人——数字世界的“专业分工”

最后一个原型最具组织学意义。

社区里有人搭建了一个“三Agent治理结构”：一个“家庭管家”Agent负责家务、购物、日程协调；一个“工作助理”Agent负责邮件、文档、会议准备；一个“创作编辑”Agent负责写作辅助和内容发布。三个Agent互相隔离——家庭管家看不到你的工作邮件，工作助理不知道你的家庭购物清单。

更极端的案例是一个“14+ Agent梦之队”的编排，不同Agent分别担任研究员、写手、审校、数据分析师等角色。

这让我想到亚当·斯密在《国富论》开篇描述的那个著名的“别针工厂”。一个人独自做别针，一天做不了20根。但如果把工序拆分——抽丝、拉直、切断、磨尖、装针头——10个工人一天能做48000根。专业分工带来的效率提升不是线性的，而是指数级的。

但分工有一个经典问题：协调成本。工人之间需要沟通、需要等待、需要对齐标准。组织行为学家James March指出，组织的核心矛盾是“探索”（exploration）与“利用”（exploitation）之间的张力——你既需要专业化以提高效率，又需要跨领域协调以应对变化。

多Agent系统天然适合解决这个矛盾。每个Agent高度专业化（利用），而Gateway负责跨Agent的路由和协调（探索）。Agent之间的协调成本远低于人类——没有情绪、没有政治、没有沟通风格的摩擦。这意味着Agent团队可以比人类团队实现更细粒度的分工，而不会被协调成本吞噬掉分工带来的效率增益。

这五个原型合在一起，描绘了一幅图景：Agent不是一个单点工具，而是一套操作系统——有感知、有行动、有记忆、有分工。而这套操作系统的入口，就是你已经用了十年的聊天窗口。

四、生态扩散：为什么“可复制的技能包”比“更强的模型”更重要

4.1 创新扩散的S曲线

社会学家Everett Rogers在1962年提出了“创新扩散理论”（Diffusion of Innovations）。他发现，任何新技术的采纳都遵循一条S曲线——先是极少数“创新者”和“早期采纳者”尝试，然后是“早期多数”和“晚期多数”跟进，最后是“落后者”被迫接受。

S曲线前半段增长缓慢，一旦跨过一个“引爆点”（通常是16%的采纳率），增长会突然加速。

引爆点的关键不是技术本身有多好，而是“模仿成本”有多低。 Rogers发现，创新扩散中最有效的传播机制不是广告，不是专家推荐，而是“同伴示范”——看到和自己差不多的人成功使用了新技术。

OpenClaw的Skill系统天然就是一个降低模仿成本的机制。每个Skill就是一个文件夹加一份SKILL.md，任何人都可以打包自己的Agent能力，通过ClawHub分享给其他人。看到别人做了一个“本地酒窖管理”的Skill（有人真的导入了962瓶酒的CSV来管理自己的酒窖），你可以一键安装，然后根据自己的需要调整。

这把Agent能力从“自己从零开发”变成了“搜索、安装、微调”——模仿成本降低了一到两个数量级。

4.2 知识的“乐高化”

OpenClaw的Skill生态让我想到一个更大的知识管理命题。

计算机科学家Douglas Engelbart在1962年提出了“增强人类智力”（Augmenting Human Intellect）的框架。他认为，人类的智力不仅取决于大脑本身，还取决于“工件”（artifacts）——语言、符号、工具、方法论——的质量。改善工件，就是在改善智力。

Skill文件就是Agent的“工件”。一个好的Skill不只是一段代码，它是一个被验证过的问题解决方案——包含了某个人花了几个小时甚至几天摸索出来的配置、提示词、工具链组合和边界条件。

ClawHub的出现意味着：个人积累的Agent经验可以被打包成标准化的知识单元，像乐高积木一样在社区中流通和组合。 这是知识生产方式的一个微小但重要的进化——从“文章分享”（告诉你怎么做）到“能力分享”（直接把做好的东西给你用）。

五、安全悖论：越有能力的Agent越像“过于热心的实习生”

5.1 一个让安全研究者睡不着觉的能力

OpenClaw社区里流传着一个令人不安的故事：有人让Agent帮忙清理邮箱，结果Agent“过于热心地”执行了大量删除操作——删掉的邮件远远超出了用户的预期。

安全研究者给OpenClaw起了一个精准的绰号：“过于热心的实习生”（overly enthusiastic intern）。

这个比喻值得仔细品味。实习生的危险之处不在于他不听话，恰恰在于他太听话了——你说“把这个文件夹整理一下”，他可能把里面的东西全删了重新分类。他有执行力，但缺乏对“什么不该做”的隐性知识。

心理学家Gary Klein研究专家决策时提出了“识别启动决策”（Recognition-Primed Decision）模型。专家的厉害之处不在于他们能想到更多选项，而在于他们能瞬间识别出“这个情况不对”——然后停下来。 消防队长在火场中突然喊“全员撤退”，不是因为他算了一遍力学模型，而是因为他“感觉到”了某种微妙的异常。

当前的AI Agent恰恰缺乏这种“感觉到不对就停下来”的能力。它会忠实地执行你的指令，但不会在执行过程中突然意识到“等等，批量删除邮件好像不是用户的真正意图”。

这就引出了Agent安全的核心矛盾：能力越强的Agent，犯错时造成的损害也越大。

5.2 四层防御体系

OpenClaw社区逐渐摸索出了一套多层次的安全框架，我把它概括为四层防御：

第一层：关键动作二次确认。 对于不可逆操作（删除、发送、购买、提交），Agent必须先展示操作预览，等待用户明确确认后才执行。这相当于核电站的“双钥匙”机制——关键操作需要两个人同时转动钥匙。

第二层：权限分层与工具最小集。 不同Agent只能访问它们工作所需的最少资源。家庭管家不需要访问工作邮箱，工作助理不需要控制智能家居。这是信息安全领域的“最小权限原则”（Principle of Least Privilege）的直接应用。

第三层：技能供应链安全。 从ClawHub安装Skill的时候，要检查Skill的来源、作者信誉、代码内容。社区有人建议集成VirusTotal扫描——像检查食品标签一样检查每个Skill的“成分表”。这对应的是软件工程中日益重要的“供应链安全”意识——2021年的SolarWinds事件和2024年的XZ Utils后门事件都证明了，你的系统的安全性取决于你最弱的那个依赖。

第四层：防御prompt injection和日志投毒。 这是最技术性的一层。恶意内容可能通过网页、邮件、甚至聊天消息注入到Agent的上下文中，操纵它执行非预期的操作。这就像社会工程学攻击——骗子不需要破解你的密码，只需要骗你自己把密码说出来。

5.3 一个哲学命题：Agent的边界在哪里

四层防御能解决大部分已知风险。但还有一个更深层的问题，现有的安全框架无法完全覆盖。

Agent软件的边界，到底应该画在哪里？

传统软件的边界很清晰：这个程序能读写这些文件，能访问这些网络端口，能使用这些系统调用。你用进程隔离、文件权限、网络防火墙就能把它框住。

但Agent的行为不是由代码预先确定的，而是由自然语言指令在运行时动态生成的。你没法用传统的权限模型完全约束一个会“理解语言”的系统——因为语言本身是模糊的、多义的、可被操纵的。

哲学家Ludwig Wittgenstein在《哲学研究》中有一个著名的论断：“语言的意义就是它的使用。” 同一句话在不同上下文中意义完全不同。“清理一下”可能是“整理排序”，也可能是“全部删除”。

这意味着Agent安全不能只靠技术手段（进程隔离、权限控制、沙箱），还必须处理语言、意图与执行之间的语义鸿沟。这是一个跨越计算机科学、语言学和认知科学的交叉难题。

OpenClaw的设计者似乎隐约意识到了这一点。它的Memory系统用纯Markdown文件存储，意味着用户可以审查和编辑Agent的一切“认知内容”。它的Skill系统要求每个技能包附带SKILL.md说明文件，让能力的边界显式化。这些设计选择不能从根本上解决语义鸿沟问题，但它们朝着正确的方向迈了一步：让Agent的行为尽可能可解释、可审计、可干预。

安全不是一个需要“解决”的问题，而是一个需要持续管理的张力——就像民主社会中自由与秩序的关系一样。

六、结语：从“借来的大脑”到“自家的劳动力系统”

让我们退后一步，看看更大的图景。

过去三年，AI领域的主旋律是“模型越来越强”——参数更多、推理更快、能力更广。这当然重要。但OpenClaw代表的趋势提醒我们，光有聪明的大脑是不够的，你还需要把大脑连接到合适的身体上。

神经科学有一个概念叫“具身认知”（Embodied Cognition）：认知不仅仅发生在大脑里，它还依赖于身体和环境的交互。 一个大脑再聪明，如果没有眼睛看、没有手操作、没有腿移动，它的智力也无法真正施展。

OpenClaw做的事情，就是给AI大脑配备了完整的“身体”——聊天窗口是嘴巴和耳朵，浏览器是手，传感器是眼睛，定时任务是生物钟，Skill是肌肉记忆，Memory是自传体记忆。而且这整套“身体”运行在你自己的机器上，由你完全控制。

从“在别人的服务器上借用一个聪明大脑”到“在自己的机器上培养一个完整的数字劳动力”——这不只是技术架构的变化，这是人与AI关系的根本重构。

当然，我们也必须保持清醒。“过于热心的实习生”依然是实习生——会犯错，会误解指令，会在你不注意的时候闯祸。Agent安全不是一个已经解决的问题，而是一个需要整个社区持续投入的长期工程。

但方向已经非常清晰了。

经济学家F.A. Hayek曾经说过，分散的知识比集中的知识更强大——前提是有足够好的协调机制。 市场之所以能打败计划经济，不是因为每个个体比计划委员会更聪明，而是因为价格机制让分散在每个人手中的局部知识得以汇聚和协调。

OpenClaw的架构哲学与此一脉相承：AI能力不应该集中在少数巨头的服务器上，而应该分散在每个人自己的机器上——通过Skill生态和开源协作来实现协调。 这是一种去中心化的AI发展路径。

它能不能成功？我不知道。但我知道的是，当一个系统同时解决了“入口摩擦”（聊天窗口）、“信任锚点”（本地运行）和“能力扩散”（Skill生态）这三个问题时，它值得被认真对待。

至少，它值得你用自己的机器试一试。毕竟——Your assistant. Your Machine. Your rules.

发表于 | 分类于

风格参考：Ben Thompson（Stratechery）的战略分析框架 + Paul Graham 的反直觉开头与金句技巧。一条主线贯穿全文，短段落，强逻辑链，面向技术决策者。

一个被忽略的数字

Anthropic 最近发布的 2026 Agentic Coding 趋势报告里，有一个数字比所有预测都重要，但几乎没人讨论它。

开发者在约 60% 的日常工作中使用 AI，却只能把 0–20% 的任务“完全委派”给 AI。

大多数人读到这里会觉得：“说明 AI 还不够强，等模型再迭代几轮就好了。”

我认为这个解读完全搞反了。

这个数字揭示的不是 AI 的能力不足，而是一种全新的协作范式正在形成——而这种范式的核心瓶颈，从来就不是模型的智商。60% 的使用率说明 AI 已经深度嵌入了工程师的日常；0–20% 的完全委派率说明人类的判断、监督和验收是不可消除的。两个数字合在一起，画出的不是一条“AI 越来越强最终取代人”的直线，而是一条“人与 AI 的协作界面不断被重新设计”的曲线。

换句话说，2026 年的主战场不是“模型有多强”，而是“协作如何被工程化”。

这正是这份报告真正在说的事情。

稀缺性的转移

让我从一个更基本的问题开始：软件工程里，什么东西是稀缺的？

在过去四十年里，答案很简单——代码。写代码的人稀缺，写得好的人更稀缺，能在复杂系统里写对的人极度稀缺。整个行业围绕这种稀缺性建立了它的定价体系、职级体系和流程体系：程序员按能力分级，薪酬按产出定价，项目管理围绕“如何让有限的人力产出足够多的代码”来设计。

2025 年开始，这个等式被打破了。

报告描述的图景很清晰：coding agents 从实验工具走向了能覆盖大量实现环节的生产系统——写代码、写测试、调试、导航复杂代码库、生成文档。代码的供给侧发生了结构性变化。一个工程师配合 agent，产出量可以是以前的数倍。TELUS 的案例显示：工程代码交付提速 30%，节省 50 万小时以上，平均每次 AI 交互节省 40 分钟。更重要的是，约 27% 的 AI 辅助工作属于“以前根本不会做”的事情。

当产出的供给侧被彻底改写，稀缺性就会发生转移。

代码不再是稀缺资源。“可靠的变更”才是。

什么是“可靠的变更”？它不只是“代码能跑”，而是：这段变更解决了正确的问题、通过了充分的验证、不会在集成时引发回归、不会在生产环境中造成安全漏洞、并且在需要时可以被安全回滚。

这个定义本身就暗示了一整套系统能力——需求规格化、自动测试、代码审查、灰度发布、监控告警、审计追踪。这些能力以前是“加分项”，在代码产出爆炸的时代，它们变成了“生死线”。

如果用一句话概括这份报告的中心命题：软件开发正在从“以写代码为中心”转向“以编排写代码的智能体为中心”，同时必须保留人类的判断、监督与协作来保证质量。

理解了“稀缺性转移”这个底层逻辑，报告里的八个趋势就不再是互不相关的预测清单——它们是同一个结构性变化在不同层面的展开。

当实现被折叠：三种新瓶颈

报告的第一个趋势是 SDLC 被“压缩并重排”：传统的开发周期从数周压缩到数小时，agent 驱动实现 + 自动测试 + 内联文档会把线性流程变成高频反馈回路。报告甚至认为这是一次堪比 GUI 出现的交互层变革。

这个判断大方向上没问题，但它容易让人产生一个错觉：“一切都变快了”。

事实上，当实现被折叠后，变快的只是其中一段。整个链条上会浮现出三种新瓶颈，而它们恰好都不是 AI 擅长解决的：

第一种：意图延迟。 需求表达不清，约束没有被结构化。Agent 再强也没用——它只会“做得很快但做错”。你可以在几分钟内拿到一个完整的功能实现，但如果需求本身是模糊的，你拿到的只是一个高速飞向错误方向的产出。

第二种：验收延迟。 代码产出爆炸，但人类 review、产品验收、合规审批的带宽没有同步增长。这会形成一个经典的排队论问题：上游的生产速率超过下游的处理速率，队列无限增长，lead time 反而变长。

第三种：集成延迟。 多个 agent 并行工作、多条变更同时落地时，冲突、回归和不一致性问题会急剧上升。这不是新问题——大型团队一直面对它——但 agent 把它加速了一个数量级。

所以，真正的工程升级不是“让 AI 写更多”，而是把验收做成系统。你可以叫它 TDD、contract tests、policy-as-code，但本质都是一件事：把口头标准变成可机器验证的门禁。 只有当“验收”被自动化到接近“实现”的速度时，压缩才是真正有效的。

多智能体不是“更多算力”，是一种新的组织形式

报告的第二个趋势预测：2026 年组织会从单智能体走向“多智能体团队”。

如果你把这个趋势理解为“多开几个窗口同时跑”，你就低估了它的含义。

多智能体编排解决的核心问题不是“一个模型上下文不够大”。它解决的是两个更工程化的问题：

第一，把大任务拆成可并行、可验证的小单元。 每个 agent 有独立的上下文和职责边界。这本质上就是微服务思想在 AI 工作流中的复现——你把一个巨型任务分解成多个有明确输入输出的小服务，每个服务可以独立测试、独立失败、独立恢复。

第二，把协作从“聊天式”升级为“协议式”。 每个 agent 的输入格式、输出格式、完成定义、失败回退策略和冲突处理方式，都需要被标准化。这就是分布式系统里的 API 契约和服务编排——只不过现在“服务”碰巧是一群 AI 智能体。

Fountain 的案例很说明问题：他们用分层多智能体编排来处理筛选、入职、转化等环节，把“新仓配中心完整招满人”的时间从一周以上降到 72 小时以内。这里面真正起作用的不是“AI 更聪明了”，而是“任务被正确地拆解和编排了”。

但这里有一个反直觉的推论值得警惕：

并行越强，集成与一致性越难。

这跟分布式系统的经验完全一致。当你从单体服务走向微服务时，你获得了可伸缩性，但你也引入了分布式事务、数据一致性、服务发现、链路追踪等一整套新的复杂度。多智能体编排也一样——你更需要接口契约、变更隔离、自动集成测试、特性开关和灰度发布这些传统工程纪律。否则，你只是把“人肉并发”的痛点搬到了 AI 上。

长跑智能体把“项目管理”变成“运行时治理”

报告预测 agent 的任务跨度会从分钟 → 小时（2025）→ 天级甚至周级（2026）。Rakuten 的案例印证了这一点：他们让 Claude Code 在一个千万级代码行的开源库里自主运行 7 小时完成复杂任务，达到 99.9% 数值精度。

这不再是“工具”。这是一个持续运行的生产系统。

一个跑几天的 agent 会产生大量变更、分支、PR、测试结果、失败记录和重试。它需要状态管理——记忆、计划、上下文的持久化。它需要审计与追踪——每一步决策都要可追溯。它需要成本控制——算力和 API 调用是有预算的。它需要故障隔离——一次错误不能污染整个运行链路。

换句话说，你需要像运维一个生产服务一样运维你的 agent。

我认为这会催生一个新的系统层：Agent Runtime（智能体运行平台）。 它的职责和 CI/CD 平台类似，但维度更多：谁能启动长跑任务？资源额度是多少？失败重试策略是什么？产出的代码如何被分桶 review？风险变更如何自动升级给人？

报告还提到一个很有想象力的推论：当 agent 能自主长期工作后，过去 ROI 不够的项目突然变得可行——积累多年的技术债可能被 agent 通过 backlog 系统性消除，创业者能在“几天”而非“几个月”从想法到部署。

这很诱人，但前提是你有能力治理这些长跑过程。没有治理的长跑 agent，就像没有项目管理的马拉松——跑得越久，偏得越远。

监督规模化的核心矛盾

报告指出 2026 年一个最有价值的能力进化：agent 学会了“什么时候该求助”，人类只在必要时进入回路。AI 审查 AI 产出将成为标准配置——检查安全漏洞、架构一致性和质量问题，避免人类被海量产出淹没。

这个方向是对的。当代码产出增长 5 倍但 review 人力不增长时，你只有两个选择：要么降低 review 标准（然后在线上付出代价），要么用 AI 帮你做第一轮筛选。显然后者更合理。

但“AI 审 AI”有一个结构性风险，报告没有展开讨论：同源错误。

如果生成代码的模型和审查代码的模型来自相似的训练数据、使用相似的推理模式，它们可能会犯相关性很高的错误——一起忽略同一个边界条件，一起误判同一个安全假设。这就像让同一所学校毕业的两个人互相批改试卷——他们大概率有相同的知识盲区。

所以监督规模化不能仅靠“再来一个 AI”。它需要独立证据链：

  • 单元测试、集成测试、端到端测试（不是 AI 说“这段代码没问题”，而是测试跑过了）
  • 静态分析和类型检查（不是 AI 判断“这里类型安全”，而是编译器保证了）
  • 依赖扫描和许可证审计（不是 AI 觉得“没有安全漏洞”，而是扫描器确认了）
  • 运行时监控和告警（不是 AI 预测“不会出错”，而是线上数据证明了）
  • 灰度发布和自动回滚（不是 AI 承诺“没有回归”，而是灰度流量验证了）

AI 可以帮你写这些证据链——这是它最好的用途之一。但最终，你必须用事实约束智能体，而不是用另一个智能体的口头保证。

“民主化”的两条路

报告预测 agentic coding 会扩展到非工程人群：安全人员、运维、设计师、数据分析师都能用代码解决问题；更远一步，销售、市场、法务、运营等非技术团队也能自己构建自动化方案。

Zapier 的案例很典型：全员推动 agent 使用，设计团队在客户访谈中实时做原型，组织 AI 采用率达到 89%。Anthropic 法务团队自己用 Claude 把市场审核从 2–3 天缩短到 24 小时——构建工具的人是没有编码经验的律师。

这是一个真实的趋势。但它会沿两条截然不同的路径演化：

好的路径： 企业提供统一平台——身份、权限、审计、数据访问、模板、发布管道——业务团队在护栏内自助创新。工程团队从“交付中心”变成“平台与治理中心”，提供可复用的组件、安全边界和发布能力。

坏的路径： 各部门各搞一套脚本、机器人和自动化，数据权限混乱，没人负责维护，安全漏洞藏在各个角落。这就是 Shadow IT 在 AI 时代的加速版。

两条路的分叉点在于一个原则：把能力下放，把风险上收。 能力让更多人能做；风险必须由平台化治理去兜底。做不到这一点的组织，“民主化”带来的治理成本会远超它释放的生产力。

更多产出 ≠ 更多价值

报告提出生产率提升的核心发现：工程师“时间净减少”，但“产出量净增加更大”——生产率主要来自“做了更多”，而不仅是“同样的事更快”。27% 的 AI 辅助工作是“否则根本不会做”的事情：扩展项目、交互面板、探索性工作、修各种小痛点。

这是好事。但它有一个二阶效应值得警惕。

当“额外产出”变得几乎免费，组织会很自然地陷入范围膨胀——“反正很快，顺手加个功能吧”。每个单独的“顺手加一下”都合理，但累积起来会把系统复杂度推到一个你的测试、监控和运维能力跟不上的水平。

这就是为什么你需要“产出治理”：

  • 给团队设定变更预算（不是限制产出，而是确保每一批变更都经过了充分验证）
  • 用可量化指标守住质量底线：缺陷率、回滚率、变更失败率、上线 lead time、线上事故率
  • 定期评估系统复杂度，确保它没有超出团队的理解和控制能力

更多产出是工具，更多价值是系统。 前者 AI 可以给你，后者需要你自己建。

安全：把 Agent 当作一种新身份

报告的最后一个趋势是安全。它的判断很准确：agentic coding 在安全上是“双向改变”——AI 让每个工程师都能做安全审查，但同样的能力也帮助攻击者规模化攻击。

但报告没有点透的一层是：大多数组织仍然把 agent 当作“更聪明的 IDE 插件”。这是一个危险的认知偏差。

一个 coding agent 能调用工具、读写代码、触达数据、触发部署。它是一个新的身份主体（principal），就像一个新入职的员工一样，需要被纳入安全架构。

这意味着你的安全体系要回答一系列新问题：

  • 这个 agent 能访问哪些仓库、哪些环境、哪些数据？
  • 最小权限怎么设计？
  • 密钥与敏感信息如何隔离与审计？
  • 它能不能直接部署到生产？如果能，门禁和回滚怎么做？
  • 发生错误或滥用时，责任归属和追踪怎么做？

如果你的安全模型里没有“agent”这个角色，你就在裸奔——只是暂时还没出事。

一句话策略

如果要把这份报告翻译成一句可执行的组织策略：

建立三层体系：规格清晰化 → 执行自动化 → 质量与安全可验证化。让智能体负责产出，让系统负责约束，让人类负责方向与裁决。

展开来说，这就是一个“Agentic Engineering OS”：

意图层： PRD、技术方案、验收标准、风险边界——尽量结构化、可复用、可被机器解析。这是整个系统的输入质量，垃圾进垃圾出。

执行层： 多智能体编排、工具调用、长跑任务管理。这是 AI 最擅长的领域，放手让它干。

保证层： 测试、静态分析、监控、审计、安全门禁、回滚机制、事后复盘。这是让整个系统可信赖的基础，也是人类注意力应该聚焦的地方。

报告最后的建议压缩成了四个优先方向：掌握多智能体协作、用 AI 自动化 review、把 agentic coding 扩展到工程以外、从最早期就把安全嵌入。这四个方向都对，但它们共享同一个前提——你必须先建好保证层。

没有保证层的 agentic coding，就像没有刹车的跑车。油门越大，死得越快。

尾声

回到开头那个被忽略的数字：60% 的使用率，0–20% 的完全委派率。

很多人看这个数字觉得“AI 还不行”。我看这个数字觉得“这才刚开始”。

它告诉你的是：AI 已经深入到了工程实践的核心，但人的判断力不是瓶颈，而是基础设施。不是等 AI 更强之后人就可以退出回路，而是人的参与方式会持续演化——从写代码，到审代码，到设计让 agent 写代码、让系统审代码的规则。

2026 年赢的不是“写得更快”的团队，而是把协作与质量变成可复制的系统能力的团队。

前者只需要买更好的工具。后者需要重新设计你的工程体系。

这就是为什么这份报告的标题是“Agentic Coding”——不是“AI Coding”。区别在于：AI coding 是用 AI 写代码；agentic coding 是把 AI 当作一个有自主性的参与者来编排。前者是工具升级，后者是范式变迁。

范式变迁不会等你准备好。但好消息是：你需要做的第一步并不复杂——把你团队最重要的验收标准写成可执行的测试，然后交给 agent 去跑。

从这一步开始，你就已经站在了新范式的这一边。

发表于 | 分类于

当 AI 成为你的同事：Anthropic 内部报告揭示的新工程范式

一、一个反直觉的发现

Anthropic 最近发布了一份报告，叫《How Anthropic teams use Claude Code》。乍一看，这好像是一家 AI 公司在展示自家产品有多好用。但仔细读完，我发现它真正讲的是一件更有趣的事——

软件工程正在从一门“确定性手艺”变成一种“概率性博弈”。

我们过去写代码的逻辑很简单：想清楚，写下来，测一测，上线。每一步都是确定的。但当 AI 深度介入开发流程之后，游戏规则变了。Anthropic 的 RL（强化学习）工程团队在报告里坦诚地说：让 Claude Code 独立完成一个小到中等的 PR，“一次就成”的概率大约只有三分之一。

三分之一。这个数字非常关键。

它意味着你不能像指挥一个靠谱工程师那样指挥 AI——“去把这个功能做了”，然后等着交付。你得换一种完全不同的思路。

Anthropic 自己的 10 个团队，从数据基础设施到法务，从安全工程到增长营销，各自独立地摸索出了一套新方法。把这些方法叠在一起看，你会发现它们指向同一个底层规律。

这篇文章就来讲讲这个规律。

二、老虎机式工作法

Anthropic 的数据科学团队发明了一个绝妙的说法，叫“老虎机式工作法”（slot machine approach）。

做法很简单：你先保存好当前进度（checkpoint），然后让 Claude Code 自由发挥 30 分钟——写代码、跑测试、自我修正。30 分钟后你回来一看：如果结果不错，恭喜你赚到了；如果一团糟，你直接回滚到 checkpoint，重新来一次。

这听起来荒唐。传统工程思维里，你遇到错误应该去修它、去 debug、去逐步逼近正确答案。回滚重来？那不是浪费前面所有的工作吗？

但这恰恰是概率式系统的反直觉真相：当生成器有随机性时，重新开始有时比逐步修补更便宜。

想象你在走迷宫。如果你能看到迷宫全貌，那当然应该逐步修正路线。但如果你蒙着眼睛走，每一步都有随机性，那么当你发现走到死胡同时，最聪明的做法不是原路返回再试一条岔路——而是直接传送回起点，重新走。因为 AI 每次生成的路径不一样，“重新走”有真实概率走出一条更好的路。

RL 工程团队用的也是同一套策略：先让 Claude 一次性跑完整个任务（one-shot），成了就赚到；没成就切换到“协作引导模式”，人在旁边一步一步带。他们甚至把 Claude 常犯的错误记录下来写进文档（Claude.md），比如“不要乱 cd 目录”、“pytest 路径要写对”——下次它就不会犯同样的错了。

这整套东西——checkpoint、回滚、重新尝试、记录错误——不是什么小技巧。它是一种新的工程范式。

三、概率式协作的三根支柱

当我把 10 个团队的做法叠在一起看时，我发现它们虽然各自独立探索，却不约而同地搭建了同一套基础设施。我把它概括成三根支柱：上下文、控制、反馈。

第一根：上下文。 你得告诉 AI 它在哪、该怎么做、有哪些约束。

数据基础设施团队写了一份详细的 Claude.md，里面包含数据管道的依赖关系、上游数据源、dashboard 的对应关系。新人入职时，不用再拉着老员工讲半天——让 Claude 读 Claude.md 就行了。

更妙的是，他们让每次 Claude 工作 session 结束时自动生成总结，然后把总结回写到 Claude.md 里。这意味着这份文档会越来越完善——AI 在使用过程中不断改进自己的“使用说明书”。

设计团队也写了自定义 memory 文件，但内容不一样：“我是设计师，不是工程师，请用小步骤解释每一步改动。”

第二根：控制。 你得确保 AI 搞砸的时候你能回到安全地带。

产品研发团队的规矩是：永远保持干净的 git 状态，频繁做 checkpoint。这不是代码洁癖，这是生存策略。当你让一个概率性系统自由发挥时，“可以随时撤销”就是你最重要的安全网。

数据科学的老虎机工作法也是同一个思路：先 commit，再放手。

第三根：反馈。 你得让 AI 自己知道它做得对不对。

产品研发团队有一个核心实践叫“自给自足循环”（self-sufficient loop）：让 Claude 写完代码后自动跑 build、test、lint。如果测试挂了，它自己修；lint 有问题，它自己改。你不需要一行一行盯着看——让系统自己告诉它哪里错了。

这三根支柱缺一不可。

没有上下文，AI 不知道该做什么，你就会反复纠错。没有控制，你不敢放手，AI 只能做最简单的活。没有反馈，你只能靠人肉 review 来判断质量，那 AI 的速度优势就打了折扣。

很多团队觉得“AI 不够聪明”，其实不是。你缺的不是更强的模型，而是这三根支柱中的某一根。

四、风险分层：一种新的工程治理模型

产品研发团队给出了一个特别清晰的分类法：

  • 外围功能、原型、批量替换、测试生成 → 异步自治：开 auto-accept，让 Claude 自己写、自己跑、自己改，你事后来 review。
  • 核心业务逻辑、关键修复、安全相关 → 同步监督：你在旁边实时盯着，prompt 要非常具体，随时纠偏。

他们甚至有一个真实案例：Claude Code 的 Vim mode 功能，最终实现中大约 70% 来自 Claude 的自治工作。但这 70% 全部是在“外围功能”范畴内。核心逻辑仍然是人写的。

这不是技巧问题，这是治理模型。你用“监督强度”来对冲不确定性——风险越高，人介入越深；风险越低，AI 自主权越大。

安全工程团队更是把这个思路用到了极致。他们让 Claude Code 审查 Terraform plan——“这个变更会做什么？有没有后悔风险？”——安全审批的速度一下子快了很多，研发团队不用再排队等安全团队一行一行 review。但注意：Claude 给出的是“分析”，最终 approve 仍然是人按的按钮。

这就是风险分层的精髓：不是不信任 AI，而是按风险等级分配信任。

五、被严重低估的三件事

读完 10 个团队的实践，有三件事被严重低估了。

第一件：截图的价值。

数据基础设施团队排查 Kubernetes 问题时，直接把云控制台的截图喂给 Claude Code。设计团队和法务团队也大量使用“截图→反馈→迭代”的循环。

这件事被低估了。对于很多“界面/状态/配置”类问题，截图比文字描述快 10 倍，也准 10 倍。你不需要费劲把一个 dashboard 的状态用文字翻译出来——贴张图就行了。视觉输入让“人与 AI 对齐”的成本大幅降低。

第二件：组织记忆的工程化。

数据基础设施把 session 总结回写文档。安全团队把散落在各处的知识压缩成 runbook。增长营销团队甚至搭了一套“实验记忆系统”——上一轮广告测试的结果会自动传递给下一轮生成，形成自我改进的闭环。

这些做法共同指向一个结论：把组织经验写成机器可消费的形式，模型才会越用越好，团队才会越用越一致。 否则 AI 永远只是“个人的随机助手”，无法规模化。

第三件：非技术岗位的“跨界”。

增长营销团队只有一个人。这个人不是工程师。但他用 Claude Code 写了 Google Ads 自动化脚本、Figma 批量变体插件、Meta Ads 分析工具。文案制作从 2 小时降到 15 分钟，创意产出提升 10 倍，一个人像一个小团队一样运作。

法务团队更厉害——一位律师用 Claude Code 在一小时内做出了一个预测文本加语音输出的辅助沟通应用，帮助有语言障碍的家人。

产品设计师也不再只做“视觉微调”了。他们开始直接修改状态管理逻辑、梳理 error state、全站替换合规措辞——这些过去都要找工程师才能做的事。

这意味着 Claude Code 在组织里扮演的角色，不是“更强的 IDE”，而是一个翻译层——它把不同角色的意图（业务的、设计的、合规的）翻译成可执行的代码变更。这会改变“谁能做什么”的边界。

六、真正贵的是“上下文税”

API 团队说了一句很精辟的话：Claude Code 最大的价值不是“帮我写代码更快”，而是“帮我省掉了把代码片段搬到另一个窗口、再解释半天背景”的那段时间。

这句话点出了一个被忽视的真相：在大组织里，真正昂贵的不是写代码的速度，而是“上下文税”。

什么是上下文税？就是你为了理解一件事所付出的所有隐性成本——

  • 切换到一个陌生的子系统，要读一个下午的代码才能开始动手
  • 轮岗到新团队，要好几周才能有效贡献
  • 每次提 bug 要把前因后果解释一遍
  • 跨团队协作时反复对齐上下文

Inference 团队说，过去理解一个 ML 概念要 Google 搜索加读文档一小时，现在问 Claude 只要 10-20 分钟，研究时间降低了 80%。安全工程师说，过去手动扫代码定位问题要 10-15 分钟，现在 5 分钟搞定。

这些看起来是“个人效率提升”，但放到组织层面就不一样了：当上下文税降低，跨界协作的摩擦也跟着降低。 新人上手更快，轮岗更顺滑，跨团队求助减少——这些复利效应远比“单次写代码快 20%”更有价值。

七、一种张力

法务团队在报告最后说了一段意味深长的话。他们一方面鼓励大家分享不完美的原型——“因为原型会激发跨部门创新”；另一方面又警告说，MCP 深度集成的安全影响不容小觑，“合规工具要跟上能力扩张的速度”。

这不是一个孤立的担忧。它指出了未来几年很多组织都会遇到的真实矛盾：

当 AI 把“做事”的门槛降到足够低，每个部门都能直接连到系统和数据。这是创新的巨大加速器——也是风险扩散的巨大加速器。

过去，“不是工程师所以碰不了系统”本身就是一道天然防火墙。现在这道墙正在消失。数据基础设施团队建议敏感数据场景用 MCP server 代替直接 CLI，以便做权限和审计控制。法务强调要给非技术用户设定“更严格的安全默认值”。

能力越强，治理就越不能停留在“提醒大家小心”。它必须工程化——最小权限、审计日志、隔离环境、审批门槛。

这是 AI 民主化的代价。也是不得不付的代价。

八、这份报告真正在说什么

让我把这篇文章的核心论点串起来——

Anthropic 10 个团队的实践，表面上是“我们怎么用 Claude Code 的”，底层其实是一个范式转移的缩影：

  1. 软件工程从确定性走向概率性。 你不能指望 AI 每次都对，但你可以设计一个“从不确定性中持续获利”的流程——checkpoint、回滚、重试。这和传统工程直觉相反，但在概率系统里经常成立。

  2. 生产力提升的杠杆点在于“三闭环”（上下文、控制、反馈），不在于模型本身。很多人抱怨“AI 不够好”，其实是缺了其中一环。

  3. 组织效率的核心瓶颈在于上下文税，不在于代码产出速度。 AI 真正值钱的地方，是把跨角色、跨项目、跨学科的摩擦成本压低。

  4. AI 正在把“谁能做什么”的边界重新画一遍。 非技术岗位能写代码，设计师能改状态管理，一个人能像一个团队。但这意味着权限、审计和安全机制必须同步升级。

  5. 组织记忆必须工程化。 Claude.md、runbook、实验日志——把组织经验变成机器可消费的形式，是 AI 工具从“个人提效”迈向“团队规模化”的关键一步。

这份报告最大的价值不在于展示了哪些酷项目。它展示的是一种新的协作方式：把 AI 当成一个概率式的合作伙伴，用工程手段（而不是美好愿望）把它的不确定性变成可控的收益。

这才是“AI 改变工作”的真正意思。

发表于 | 分类于

风格参考：万维钢（《精英日课》作者）—— 跨学科引证，框架式拆解，加粗关键洞察，用数据和类比交叉验证每个论点。

“软件开发正在从’以写代码为中心’转向’以编排写代码的智能体为中心’。” —— Anthropic，2026 Agentic Coding 趋势报告

引子：七个小时的独奏

2025 年，日本乐天集团做了一个实验。

他们让 Anthropic 的 Claude Code 在一个叫 vLLM 的开源项目里完成一项复杂的工程任务。vLLM 是一个用于大语言模型推理优化的框架，代码量在千万行级别。任务的复杂度相当于一个资深工程师需要数周才能完成的工作。

Claude Code 自主运行了 7 个小时，中间没有人类介入。

最终的产出达到了 99.9% 的数值精度。

这个案例不是我要讨论的重点——单个案例证明不了趋势。我真正想讨论的是：当这类案例开始批量出现时，软件工程这个行业的底层逻辑会发生什么变化？

Anthropic 在 2026 年初发布了一份趋势报告，试图回答这个问题。报告总结了 8 个趋势，涉及开发流程、智能体协作、组织形态和安全架构。这篇文章是对这份报告的一次逐层拆解——不仅仅是复述，更重要的是用跨学科的视角来检验这些趋势到底站不站得住脚。

在正式展开之前，有一个数字值得先记住：开发者在约 60% 的工作中使用 AI，但只能把 0–20% 的任务完全委派给 AI。 这个数字几乎决定了所有落地策略的方向——2026 年的核心挑战不是“要不要用 AI”，而是“如何把人与 AI 的协作系统化”。

一、从流水线到反馈回路：SDLC 的范式转换

1.1 一次堪比 GUI 出现的变革

报告把 agentic coding 对软件开发流程的影响，类比为图形用户界面（GUI）对计算机交互的影响——不是小修小补，而是交互层面的整体重构。

传统的软件开发生命周期（SDLC）是一条线性流水线：需求 → 设计 → 编码 → 测试 → 部署 → 运维。即便敏捷方法论把它缩短成了两周一个冲刺，底层逻辑仍然是“人来写代码，然后推进到下一个环节”。

报告预测的图景是：agent 驱动实现 + 自动测试 + 内联文档，会把周期从“数周”压缩到“数小时”。更关键的是，监控数据会直接回流到迭代入口——不再是“先发布再观察”，而是“持续发布、持续观测、持续调整”。线性流水线变成了高频反馈回路。

这听起来像是“一切都变快了”。但深入想一步，你会发现事情没那么简单。

1.2 利特尔定律的警告

运筹学里有一条基本定律，叫利特尔定律（Little’s Law）。它说的是：在一个稳定的排队系统里，队列中的平均项目数 = 到达率 × 平均等待时间。

翻译成软件工程的语言：如果你的代码产出速率翻了 5 倍（agent 帮你写），但你的 review 和验收速率没有跟上，那排队等待 review 的 PR 数量就会翻 5 倍。Lead time 不但不会缩短，反而可能变长。

这不是理论假设。任何做过大规模团队管理的工程经理都见过这个现象：开发阶段越快，瓶颈越容易转移到 code review、QA 和产品验收上。

我把这种现象概括为三种“新延迟”：

意图延迟： 需求和约束表达不清，agent 做得很快但做错了。这就像你对出租车司机说“去那个路口附近”——他开得飞快，但不是你想去的地方。

验收延迟： 人类 review 和审批的带宽没有跟上产出爆炸。上游的水龙头开大了，但下游的管道还是老粗细。

集成延迟： 多条变更并行落地时，冲突和回归问题急剧增加。这就是分布式系统里的“脑裂问题”在代码管理上的投影。

1.3 验收必须变成系统

那怎么办？

答案是：把验收标准前置成可执行的检查。

不管你叫它 TDD、contract tests、policy-as-code 还是什么别的，本质都是同一件事——把“口头标准”变成“机器可以验证的门禁”。这样 agent 的产出在落地之前就能被自动过滤，人类只需要处理那些机器无法判断的边界情况。

报告本身也提到了这个方向：“监控直接回流到快速迭代。”但我想把它说得更尖锐一点：在 agentic coding 时代，没有可执行验收标准的团队，会比没有 agent 的团队更慢。 因为你用 agent 制造了大量产出，但没有能力消化它。

二、从单打独斗到智能体“战队”

2.1 纺织业的第二次革命

让我用一个历史类比来说明多智能体协作的本质。

18 世纪的英国纺织业经历过一次著名的效率瓶颈。1764 年，詹姆斯·哈格里夫斯发明了珍妮纺纱机，纺纱速度一下子提高了 8 倍。但织布机的速度没变。结果是：纱线堆积如山，织工忙得要死，整个产业链反而失衡了。

直到 1785 年，埃德蒙·卡特赖特发明了动力织布机，纺和织的速度才重新匹配。再后来，工厂制度把纺纱、织布、染色、裁剪等环节组织成流水线，每个环节由专门的工人和机器负责，整个系统才真正高效运转。

多智能体协作要解决的，本质上就是这个问题——不是让单个 agent 跑得更快，而是让多个专业化的 agent 组成一条高效的流水线。

2.2 报告怎么说

报告预测 2026 年组织会更多使用“多个智能体协同”来处理复杂度。这需要新的工程能力：任务拆解、智能体专长分工、协调协议，以及能展示多并发会话状态的开发环境。

它还给了一个具体案例：Fountain 用 Claude 的分层多智能体编排来处理招聘流程（筛选、入职、转化等环节），把“新仓配中心完整招满人”的时间从一周以上降到 72 小时以内。

2.3 分布式系统的经验

如果你是一个做过微服务架构的工程师，你会觉得这一切似曾相识。

从单体服务拆分为微服务，你获得了可伸缩性和独立部署能力，但你也引入了一整套新的复杂度：服务发现、负载均衡、分布式事务、数据一致性、链路追踪、熔断降级。这些问题不是“可能会遇到”，而是“一定会遇到”。

多智能体编排面临完全相同的挑战。每个 agent 就是一个微服务——它有独立的上下文、独立的职责、独立的输入输出。当多个 agent 并行工作时，你需要：

  • 接口契约（agent 之间如何传递信息？格式和语义是否明确？）
  • 变更隔离（一个 agent 的错误如何防止扩散到整个系统？）
  • 自动集成测试（多个 agent 的产出合在一起之后，整体是否还能工作？）
  • 冲突解决（两个 agent 修改了同一个文件怎么办？）

康威定律说：系统的架构会映射组织的沟通结构。在多智能体时代，我们需要加一句：智能体系统的架构会映射你的编排协议的质量。 协议越清晰，系统越可靠；协议越模糊，灾难越近。

三、当 Agent 能跑好几天

3.1 从工具到系统

如果说多智能体协作改变的是“空间维度”（并行），那长跑智能体改变的就是“时间维度”（持续）。

报告预测 agent 的任务跨度会从分钟 → 小时 → 天级甚至周级。在最少人类介入的情况下，构建完整的应用或系统。人类主要在关键节点提供战略监督。

它还强调，长跑 agent 必须面对“软件开发的脏活现实”：持续规划、迭代、从失败恢复、跨多会话保持状态一致。这不是一个可以在理想条件下运行的系统——它必须在充满意外的真实世界里生存。

3.2 赫伯特·西蒙的预言

诺贝尔经济学奖得主赫伯特·西蒙在 1969 年的《人工科学》中提出了一个至今仍被低估的洞察：复杂系统要在不确定的环境中存活，必须具备层级结构（hierarchy），且每一层都能在自身层面上做出有意义的决策。

长跑 agent 正在逼近这个描述。一个跑几天的 agent 不是一个简单的“脚本”——它要做规划（决定接下来该做什么）、执行（写代码、跑测试）、恢复（失败了怎么回退）、记忆（记住之前做了什么和为什么）。这本质上就是西蒙所说的“层级化的自适应系统”。

3.3 你需要一个 Agent 运行平台

当 agent 能跑几天，你面对的就不再是“写代码工具”，而是一个持续运行的生产系统。这意味着你需要像管理一个服务一样管理它：

可观测性： agent 现在在做什么？进度如何？有没有卡住？

成本控制： 这次运行消耗了多少 token？多少 API 调用？是否在预算内？

故障隔离： 一次错误决策产生的影响范围是什么？如何防止级联失败？

权限管理： agent 能访问哪些资源？能做哪些操作？谁授权的？

审计追踪： 为什么做了这个决策？依据是什么？能不能事后追溯？

我把这个系统叫做 Agent Runtime。它在概念上类似于 CI/CD 平台，但职责更广。未来的软件团队很可能会像管理 CI/CD 一样管理它——谁能启动长跑任务？额度是多少？失败重试策略是什么？产出的代码如何被分桶 review？风险变更如何自动升级给人？

3.4 被释放的可能性

当然，长跑 agent 不只带来治理挑战，也释放了巨大的可能性。

报告提到：过去不划算的项目变得可行，积累多年的技术债可能被 agent 通过 backlog 系统性消除。创业者甚至能在“几天”而非“几个月”从想法到部署。

这让人想起克莱顿·克里斯坦森在《创新者的窘境》中提出的概念：技术进步会改变“够好”的门槛。 当数码相机的质量“够好”了，胶片行业就崩塌了——不是因为数码在画质上超过了胶片，而是因为“够好”加上“便宜且方便”就够了。

长跑 agent 可能以类似的方式改变软件行业的竞争格局：它让“够好的软件”变得极其便宜和快速，从而把竞争的焦点从“谁能写出来”转移到“谁的方向更准、谁的质量更可靠、谁的迭代更快”。

四、AI 审 AI：一个必须但危险的方向

4.1 信息过载的老问题

信息过载不是新问题。赫伯特·西蒙早在 1971 年就指出：“信息的丰富意味着注意力的贫乏。”

在 agentic coding 的语境下，这个问题以一种新的形式出现：agent 产出大量代码，人类的 review 注意力成为系统瓶颈。报告预测 2026 年的解决方案是——用 AI 来 review AI 的产出。 Agent 学会“什么时候该求助”，AI 负责做第一轮质量筛查（安全漏洞、架构一致性、代码质量），只把真正需要人类判断的部分标注出来。

这个方向是对的。当上游产出增长了数倍，如果下游还完全依赖人力，系统一定会崩溃。

但它有一个结构性风险。

4.2 同源错误：一种被低估的风险

想象一下：你写了一份报告，然后让你的同班同学帮你审阅。他也是用同样的教材学的、听同一个老师的课、做的同一批习题。他很大概率会跟你犯一样的错——你们的知识盲区高度重叠。

这就是“同源错误”的本质：生成和审查如果来自同类模型、同类训练数据、同类推理模式，它们出错的方式也会高度相关。 一个模型忽略了某个边界条件，另一个来自类似训练分布的模型很可能也会忽略。

统计学里有一个相关的概念叫多重共线性——当多个预测变量高度相关时，它们看起来提供了“多个独立验证”，但实际上只提供了“一个验证的多个复制品”。AI 审 AI 如果模型同源，就面临同样的风险。

4.3 独立证据链

怎么对冲同源错误？答案是构建独立证据链。

所谓“独立”，是指验证方法在逻辑上独立于生成方法。AI 说“这段代码没问题”不算证据，测试跑过了才算。AI 说“没有安全漏洞”不算证据，扫描器确认了才算。AI 说“不会有回归”不算证据，灰度流量验证了才算。

具体来说：

  • 自动化测试： 单元测试、集成测试、端到端测试、属性测试
  • 静态分析： 类型检查、lint 规则、复杂度检查
  • 依赖审计： 安全漏洞扫描、许可证合规检查
  • 运行时验证： 监控告警、灰度发布、自动回滚

AI 可以帮你写这些证据链——事实上这是它的最佳用途之一。但最终，你必须让系统用事实约束智能体，而不是让一个智能体用“判断”约束另一个智能体。

卡尔·波普尔的科学哲学在这里是有用的：一个假说的价值不在于它被多少人（或多少个 AI）认同，而在于它经受了多少独立的否证尝试。 代码的可靠性也是如此。

五、民主化的两面

5.1 技能壁垒的坍塌

报告预测 agentic coding 会扩展到越来越多的“新表面”和“新用户”。

一方面是语言壁垒下降：COBOL、Fortran 等遗留语言也会得到 agent 支持，帮助维护旧系统。另一方面是角色壁垒下降：网络安全、运维、设计、数据等非传统开发者也能使用代码工具。更远一步，销售、市场、法务、运营等完全非技术的团队，也能用 agent 直接构建自动化方案。

Zapier 的案例很有代表性：他们推动全员使用 agent，设计团队能在客户访谈中实时做原型，组织 AI 采用率达到 89%，内部部署了 800 多个 AI agent。Anthropic 自家法务团队也用 Claude 把市场审核从 2–3 天缩短到 24 小时。

报告称之为“人人更 full-stack”：原本“会写代码/不会写代码”的边界变得可渗透。

5.2 Shadow IT 的教训

这里有一个历史教训值得注意。

2000 年代末，云计算和 SaaS 工具兴起之后，企业里出现了一个现象叫 Shadow IT——业务部门绕过 IT 部门，自己购买和使用各种云服务。销售团队用 Salesforce，市场团队用 HubSpot，财务团队用各种 SaaS 报表工具——每个部门都觉得自己解决了问题，但 IT 部门完全不知道有多少系统在运行、数据存在哪里、安全状况如何。

结果是：数据孤岛、安全漏洞、合规风险、维护成本飙升。Gartner 在 2017 年的报告中估计，Shadow IT 占企业 IT 支出的 30–40%。

Agentic coding 的“民主化”如果不加治理，会重演同样的故事——只不过更快、更猛烈。以前的 Shadow IT 只是“买了一个 SaaS”，现在的 Shadow IT 可能是“写了一个能访问客户数据库的自动化脚本”。

5.3 能力下放，风险上收

好的路径是什么？

企业提供统一平台：身份认证、权限管理、数据访问控制、审计日志、模板库、发布管道。业务团队在这个平台的护栏内自由创新。

坏的路径是：各部门各搞一套，数据权限混乱，没人负责维护，安全漏洞藏在各个角落。

分叉点在于一个原则：把能力下放，把风险上收。 能力让更多人能做事；风险必须由集中化的平台来兜底。

这也意味着工程团队的角色会发生转变——从“交付中心”变成“平台与治理中心”。它的价值不再是帮业务团队写代码，而是提供可复用的组件、安全边界、监控能力和发布管道。业务团队负责“最后一公里”；工程团队负责“高速公路 + 交规”。

六、更多产出的二阶效应

6.1 不只是“更快”，而是“更多”

报告有一个容易被忽略但非常重要的发现：生产率的提升主要来自“做了更多”，而不仅是“同样的事更快”。

具体数据是：约 27% 的 AI 辅助工作属于“否则根本不会做”的事情——扩展项目、做交互面板、探索性工作、修各种小痛点。TELUS 的团队创建了 13000 多个定制 AI 解决方案，同时工程代码交付提速 30%，节省 50 万小时以上。

27% 这个数字意味着：以前 ROI 不够高的体验优化、内部工具、质量改进、探索性实验，现在突然都值得做了。

6.2 杰文斯悖论的回声

这里有一个经济学上的经典现象值得警惕。

1865 年，英国经济学家杰文斯发现了一个反直觉的规律：蒸汽机效率越高，煤炭消耗反而越多——因为效率提升导致使用成本降低，更多场景开始使用蒸汽机，总消耗不降反升。这就是杰文斯悖论。

在 agentic coding 的语境下，杰文斯悖论的含义是：写代码的成本越低，写出来的代码越多——系统复杂度也越高。

每个单独的“顺手加个功能”都是合理的。但累积起来，你的系统会越来越庞大、越来越复杂，直到超出你的测试覆盖、监控能力和团队理解力所能支撑的水平。

6.3 产出治理

所以你需要“产出治理”——这是一个听起来很官僚但实际上至关重要的能力：

给团队设定变更预算。 不是限制产出，而是确保每一批变更都经过了充分验证。就像一个银行不会因为“反正贷款利率低”就无限放贷一样。

用可量化指标守住质量底线。 缺陷率、回滚率、变更失败率、上线 lead time、线上事故率——这些指标的作用是当“更多产出”开始损害系统质量时，及时发出警报。

定期评估系统复杂度。 系统有多少个服务？多少个依赖？新成员上手需要多长时间？这些问题的答案如果在快速恶化，说明产出速度已经超出了你的治理能力。

七、安全：把 Agent 当作一种新身份

7.1 双刃剑

报告指出 agentic coding 在安全上是“双向改变”：一方面，任何工程师都能借助 AI 做安全审查和加固；另一方面，攻击者也能用同样的能力规模化攻击。

这并不新鲜——每一次技术民主化都伴随着“武器对等化”。火药让城堡不再安全，印刷术让信息垄断不再可能，互联网让大规模信息操纵变得廉价。agentic coding 会让代码级的攻击和防御都变得更快、更自动化。

7.2 Agent 是一种新的“身份主体”

但报告没有点透的一层是：大多数组织仍然把 agent 当作“更聪明的 IDE 插件”。

一个 coding agent 不只是帮你补全代码。它能调用工具、读写文件系统、触达数据库、触发部署流水线。它是一个有自主行为能力的“身份主体”（principal），就像一个新入职的员工一样——它需要有自己的身份、权限、审计记录和责任边界。

在计算机安全领域，有一个经典原则叫最小权限原则（Principle of Least Privilege），由 Jerome Saltzer 和 Michael Schroeder 在 1975 年提出：每一个主体只应该被赋予完成其任务所需的最小权限集。

把这个原则应用到 agent 上，你需要回答一系列问题：

  • 这个 agent 能访问哪些仓库？哪些环境？哪些数据？
  • 密钥和敏感信息如何隔离？
  • 它能不能直接部署到生产？如果能，门禁和回滚如何设计？
  • 发生错误或滥用时，责任归属和追踪怎么做？

如果你的安全架构里没有“agent”这个角色类型，你就是在用 2020 年的安全模型应对 2026 年的威胁面。

八、把一切收束：一个三层体系

8.1 报告的四个优先级

报告最后把建议压缩成 4 个优先方向：

  1. 掌握多智能体协作以处理单智能体无法覆盖的复杂度
  2. 用 AI 自动化 review 来扩展监督，把人类注意力聚焦在关键处
  3. 把 agentic coding 扩展到工程以外，赋能跨部门领域专家
  4. 从最早期就把安全架构嵌入 agent 系统设计

这四个方向都对。但它们需要一个共同的底座才能落地。

8.2 Agentic Engineering OS

如果要把这份报告翻译成一个可执行的组织框架，我会这样描述它：

意图层（Intent Layer）： 这是整个系统的输入端。PRD、技术方案、验收标准、风险边界——尽量结构化、可复用、可被机器解析。这一层的质量直接决定了下游所有产出的质量。垃圾进垃圾出——这条朴素的工程真理在 agent 时代被放大了一百倍，因为 agent 会以极高的效率把你模糊的需求变成大量模糊的代码。

执行层（Execution Layer）： 这是 agent 的主战场。多智能体编排、工具调用、长跑任务管理。这一层的核心指标是产出的速度和覆盖面。报告中的大部分趋势——多智能体、长跑 agent、非工程人群的扩展——都发生在这一层。

保证层（Assurance Layer）： 这是整个系统的安全网。自动化测试、静态分析、监控告警、审计追踪、安全门禁、灰度发布、回滚机制、事后复盘。这一层的作用是用事实约束执行层的产出——不是让人相信 agent 做得对，而是让系统证明 agent 做得对。

三层之间的关系是：意图层决定方向，执行层负责产出，保证层确保可信。 三层都强的团队，才能真正吃到 agentic coding 的红利——周期压缩、产出放大、跨部门扩散与安全内建。

8.3 一个类比

如果你觉得这个框架太抽象，可以把它想象成一个现代化的自动驾驶系统。

意图层是导航系统——你输入目的地，它规划路线。路线越精确，抵达的概率越高。

执行层是发动机和传动系统——它负责让车跑起来。多智能体就像多缸发动机，并行出力。

保证层是刹车系统、安全气囊和车道保持——它们不创造速度，但它们决定了你能安全地使用多大的速度。

没有刹车系统的跑车，油门越大，死得越快。 这就是为什么“保证层”不是锦上添花，而是整个体系的生死线。

结语：什么东西变贵了

每一次技术变革都会改变“什么东西贵、什么东西便宜”的相对价格。

蒸汽机让体力变便宜，让能源管理变贵。印刷术让信息传播变便宜，让注意力变贵。互联网让分发变便宜，让信任变贵。

Agentic coding 让代码产出变便宜了。那什么东西变贵了？

正确的方向变贵了——因为 agent 会以极高的效率执行你的意图，如果意图是错的，你会极其高效地制造垃圾。

可验证的规格变贵了——因为模糊的需求会被 agent 变成大量模糊的代码，而你没有足够的人力去逐一检查。

可扩展的质量控制变贵了——因为产出量增长了数倍，但你的测试、监控和审计能力不会自动跟上。

可审计的安全边界变贵了——因为 agent 不再是被动工具，而是能主动行动的身份主体。

总结成一句话：代码不再稀缺之后，“可靠的变更”变成了真正的稀缺品。

这份报告给出的 8 个趋势，归根到底都在回答同一个问题：在代码不再稀缺的世界里，如何系统性地生产“可靠的变更”？

答案不是更强的模型——模型会继续进步，但那是 AI 公司的事。答案是更好的协作系统——把意图说清楚、让 agent 去执行、让保证层来兜底、让人类做最终裁决。

谁先把这套系统跑起来，谁就在新规则下领先。这不是预言，这是工程。

发表于 | 分类于

Claude Code 与软件工程的范式转移：Anthropic 内部实践报告深度分析

报告背景

上周 Anthropic 发布了一份内部报告《How Anthropic teams use Claude Code》。与通常的产品案例研究不同，这份报告罕见地展示了一家 AI 公司内部 10 个不同职能团队——从数据基础设施到法务——如何在日常工作中真实使用自家的 AI 编程工具。

这种内部实践的透明度本身就值得关注。但我认为这份报告更大的价值在于，它无意中揭示了软件工程——以及更广义的知识工作——正在经历的一次底层范式转移。

核心论点

我的核心论点是：Claude Code 之所以在 Anthropic 内部产生显著的生产力提升，不是因为模型本身足够强大，而是因为这些团队独立发展出了一套适配“概率式系统”的工程方法论。 这套方法论才是这份报告最有迁移价值的部分。

让我从三个维度来论证这个观点。

维度一：从确定性到概率性——工程方法论的根本变化

传统软件工程建立在一个基本假设之上：代码是确定性的。你写了什么，它就执行什么。debug 的逻辑也很清晰——追踪执行路径，找到偏差点，修正它。

AI 编程工具打破了这个假设。

报告中最坦诚的数据来自 RL 工程团队：让 Claude Code 独立完成一个小到中等的 Pull Request，首次成功率大约只有三分之一。这不是一个令人沮丧的数据——这是一个定义性的数据。它告诉我们 AI 辅助编程的本质不是“自动化”，而是“概率性生成”。

面对这个现实，Anthropic 的团队发展出了两种互补的策略。

策略一：老虎机式工作法（Slot Machine Approach）

数据科学团队的做法最直接：先提交当前进度，让 Claude Code 自由运行 30 分钟处理合并冲突或半复杂的重构。如果结果可用，直接采纳；如果不可用，回滚到上一个 checkpoint 重新开始。

这种方法的核心洞察是：在概率式系统中，“重新采样”有时比“逐步修正”的预期回报更高。 这和传统工程中“遇到 bug 就 debug”的直觉完全相反，但在数学上是站得住脚的。

RL 工程团队的“try & rollback”策略本质上是同一思路的变体：先一次性（one-shot）让 Claude 跑完整个任务，成功就赚到；失败就切换到更精细的协作模式。

策略二：风险分层的监督模型

产品研发团队的做法更体系化。他们明确将任务分为两类：

  • 低风险任务（原型、外围功能、测试生成、格式化）：开启 auto-accept 模式，让 Claude 自主运行“写代码→跑测试→自我修正”的循环。Vim mode 功能约 70% 的最终实现来自这种自治模式。
  • 高风险任务（核心业务逻辑、安全相关修改）：同步监督，具体的 prompt，实时纠偏。

这不是个人偏好的问题，这是一套工程治理模型：用监督强度来对冲不确定性，用任务分类来管理风险暴露面。

维度二：瓶颈转移——从“代码产出速度”到“上下文税”

如果说维度一关注的是“怎么用”，维度二关注的是“用在哪里最值”。

报告中一个反复出现的主题是：Claude Code 最大的价值往往不在于“写代码更快”，而在于降低上下文获取的成本。

API 团队的描述最典型：任何任务的第一步是问 Claude “我该看哪些文件、从哪里下手”，然后在不熟悉的子系统里独立 debug，而不是去找同事求助。他们特别提到了一个细节——Claude Code 省掉了把代码片段搬到另一个聊天窗口再解释背景的“上下文搬运成本”。

Inference 团队给出了量化数据：过去理解一个不熟悉的 ML 概念需要 Google 搜索加阅读文档约一小时，现在只需要 10-20 分钟，研究时间降低了 80%。安全工程团队的数据是：手动扫代码定位问题从 10-15 分钟缩短到 5 分钟左右。

这些数字在个体层面看起来是效率优化，但在组织层面它们指向了一个更深层的变化。

组织效率的真正瓶颈

在一个成熟的软件组织里，真正昂贵的不是“写代码”，而是围绕代码的一切协调成本：

  • 新人入职数周才能有效贡献（Inference 团队和安全工程团队提到的 onboarding 加速）
  • 轮岗到新项目需要大量代码考古（API 团队的经验）
  • 安全审批成为研发的等待瓶颈（安全团队对 Terraform plan 的审查加速）
  • 跨团队协作需要反复对齐上下文（数据基础设施团队让非工程同事自助运行数据流程）

Claude Code 在这些场景里不是在“替你写代码”，而是在压缩闭环——减少从“提出问题”到“得到可验证结果”之间的等待、搬运和沟通成本。

如果我们要重新计算 AI 编程工具的 ROI，正确的口径可能不是“每个工程师每天多写了多少行代码”，而是“每个协作闭环减少了多少等待时间和上下文搬运”。

维度三：边界重塑——AI 作为“跨角色的翻译层”

报告中最出人意料的章节不是来自工程团队，而是来自增长营销、产品设计和法务。

增长营销：一个非工程师的“团队化”

增长营销团队只有一个人，这个人不是工程师。但他用 Claude Code：

  • 构建了 Google Ads 自动化系统：处理包含数百条广告和指标的 CSV，用两个子代理分别负责标题（30 字符限制）和描述（90 字符限制），几分钟生成数百个新广告变体
  • 开发了 Figma 插件：程序化生成最多 100 个创意变体，单次操作的时间从小时级压缩到秒级，产出提升 10 倍
  • 通过 MCP server 连接 Meta Ads API 做投放分析

文案制作从 2 小时降到 15 分钟。一个人的产出像一个小团队。

产品设计：从“交付静态稿”到“交付可运行原型”

设计团队不再只做视觉微调。他们直接用 Claude Code 修改前端状态管理逻辑、梳理 error state 和边界情况，甚至完成了一次全站合规措辞替换——这项工作原本需要设计、工程和法务三方协调一周，现在压缩到两次 30 分钟的通话。

设计师在 80% 的工作时间里同时开着 Figma 和 Claude Code。报告中有一句话精确捕捉了这种转变的双重性：对有开发经验的人，Claude Code 是“增强版工作流”；对没有开发经验的人，它是“我居然能当开发者”的全新能力。

法务：一小时做出辅助沟通应用

一位律师用 Claude Code 在一小时内构建了一个预测文本加语音输出的辅助沟通应用，用于帮助有语言障碍的家人。法务团队还做了“phone tree”原型（帮同事找到对口律师）和 G Suite 自动化（周更跟踪、法务 review 状态管理）。

这意味着什么

这三个团队的案例共同指向一个结论：Claude Code 在组织中扮演的角色不是“更强大的 IDE”，而是一个跨角色的翻译层——它把业务意图、设计意图、合规意图翻译成可执行的代码变更。

这是一个具有深远影响的变化。

在传统组织架构中，“能写代码”是一条清晰的能力边界。业务部门想要自动化，得排队等工程资源。设计师想要调整交互逻辑，得写 ticket 给开发。法务想要一个内部工具，得走立项流程。

当 AI 把这条边界模糊化之后，“谁能做什么”的定义被重写了。这带来了两个并行的后果：

正面后果是创新的加速。 法务团队明确鼓励“分享不完美的原型”，因为原型会激发跨部门创新。增长营销从“执行者”转向“策略制定者和自动化建设者”。设计师在系统约束中做取舍的能力显著增强。

负面后果是风险面的扩大。 当非技术部门能直接连接到系统和数据时，过去“不是工程师所以碰不了系统”这道天然防火墙就消失了。法务团队明确提出了对 MCP 深度集成的安全顾虑，数据基础设施团队建议敏感数据场景使用 MCP server 以实现权限控制和审计追踪。

这是 AI 工具能否在企业中规模化采用的决定性因素：治理体系能否跟上能力的扩张速度。

隐藏在报告中的基础设施：组织记忆的工程化

除了上述三个维度，报告中还有一条暗线值得专门讨论：组织记忆的工程化。

多个团队独立发展出了“把组织经验写成机器可消费形式”的实践：

  • 数据基础设施团队：每次 Claude 工作 session 结束时生成总结，回写到 Claude.md 文档，形成持续完善的运维知识库
  • 安全工程团队：把散落在多处的文档压缩成结构化的 markdown runbook，用于真实故障排查
  • 增长营销团队：搭建实验记忆系统，上一轮广告测试的假设和结果自动传递给下一轮，形成自我改进的测试框架
  • RL 工程团队：把 Claude 常犯的错误模式记录进 Claude.md（如路径问题、命令习惯），降低重复出错率

这些实践的共同逻辑是：AI 工具的质量不仅取决于模型能力，还取决于可供消费的组织知识的结构化程度。 写得更好的 Claude.md 直接等于更稳定的输出。

安全工程团队的一个数据点佐证了这一点：他们在 monorepo 中实现了 50% 的自定义 slash command。这意味着他们已经把“经常做的事”封装成了可复用的资产，从个人效率升级为团队能力。

这是 AI 工具从“个人提效”迈向“组织规模化”的关键一步。也是最容易被忽略的一步。

局限性：必须正视的现实

任何严肃的分析都不应回避局限性。报告中至少暴露了四个需要注意的问题：

  1. 可靠性的天花板。 RL 工程团队的“三分之一首次成功率”是真实数据。这意味着对 AI 编程工具的合理预期不是“自动交付”，而是“加速迭代”。任何假设 AI 能独立完成关键任务的工作流设计都是危险的。

  2. 复杂性偏好。 数据科学团队特别提到，模型有“默认走复杂方案”的倾向。你需要主动要求更简单的实现方式，否则会得到过度工程化的代码。

  3. 输出质量的不一致。 RL 工程团队指出 Claude 会自动添加注释，但位置和措辞有时很奇怪，代码组织结构也可能不符合团队规范。这意味着 code review 仍然是不可省略的环节。

  4. 安全与合规风险。 当 AI 工具能直接操作生产系统时，最小权限原则、审计日志、变更审批这些治理机制不是可选项，而是必选项。

对企业的启示：分阶段采用框架

基于报告中 10 个团队的经验，我认为企业采用 AI 编程工具的最优路径不是“全面铺开”，而是分阶段推进：

第一阶段：知识导航与测试补全。 风险最低、见效最快。让 AI 回答“某功能在哪里”、“这段代码做了什么”、“帮我补一下这个函数的边界测试”。目标是在团队内建立基本信任。

第二阶段：三闭环基础设施。 在放手让 AI 做更多事之前，先搭建上下文（Claude.md / memory 文件）、控制（干净分支 + 高频 checkpoint）、反馈（自动化 build / test / lint）三套机制。这决定了 AI 工具能否安全地“跑更久”。

第三阶段：能力资产化。 把高频流程封装成 slash command、GitHub Actions 或 MCP 集成。这是从个人效率升级到团队效率的关键跃迁。

第四阶段：非技术角色接入。 在完善权限、审计和安全默认值之后，让设计、营销、法务等非技术角色进入可控的 AI 辅助工作流。先解决环境搭建和权限配置的门槛，再强制小步修改和审核机制。

结论

Anthropic 这份报告最有价值的地方不在于“他们用 Claude Code 做了什么酷项目”，而在于它展示了一套完整的方法论——如何在一个概率式系统不够可靠的前提下，通过工程手段（checkpoint、反馈闭环、风险分层、组织记忆）将其转化为可控的、可规模化的生产力工具。

更重要的是，它暗示了软件工程和知识工作的一次深层结构变化：

  • 工程方法论从“确定性流程”转向“概率式流程”
  • 生产力瓶颈从“代码产出速度”转向“上下文获取成本”
  • 组织能力边界从“职能分工”转向“AI 辅助的能力弹性”
  • 治理挑战从“管好工程师”转向“管好每个人的 AI 权限”

对于正在评估 AI 编程工具的技术领导者来说，这份报告的真正信息不是“赶紧用”——而是“想清楚怎么用”。流程闭环、能力资产化和风险分层，比模型选择本身更决定最终的投入产出比。

发表于 | 分类于

本文源自我与 ChatGPT 的一次深度讨论，后经 Claude Opus 4.6 整理成文，使用的是我自己的写作风格。

1

最近我花了很多时间跟AI协作。写代码、写文档、做产品、搭工作流。做着做着，我发现了一个奇怪的现象：我积累下来最有价值的东西，好像不是代码。

代码当然也在写。但真正让我觉得有价值的，是那些模板、流程、规范——需求文档怎么写、测试怎么组织、一个想法怎么变成产品。这些东西，说它是知识吧，又不太像。它不是”巴黎是法国首都”那种可以查到的事实，而是一种经验的结构化表达，是在一次次实践中提炼出来的东西。

它也不是纯粹的经验。普通经验是模糊的、个人的、讲不清楚的。但我做的事情，是把经验压缩成模板和流程，让它可以被复用，甚至可以被AI理解和执行。当我做一个提醒喝水的App，我其实在回答一系列具体问题：什么频率合理？什么语言不会引起反感？什么节奏更容易形成习惯？这已经是行为科学、产品设计、认知心理学的交叉地带了。

如果一定要给这类东西起个名字，我倾向于叫它：结构化认知资产。

名字起好了，但一个更根本的问题随之而来：它真的算”资产”吗？还是只是一堆听起来很专业的文档？

2

判断一样东西算不算资产，我用一个朴素的标准：能不能在未来持续带来收益，并且可以被持有、迭代、转移。

我用一个朴素的标准来判断：能不能在未来持续带来收益，并且可以被持有、迭代、转移。

按这个标准，它完全是资产。它可以复用——同一套结构能反复用在不同项目上。它可以迁移——换了团队、换了领域，我仍然能带走。它可以增值——用得越多，迭代得越完善，具备复利效应。它也可以衡量——交付速度、缺陷率、返工率，都看得见变化。

当然，它也有折旧。技术迭代会让模板过时，缺少验证机制会让文档变成精致的自我感动。所以它是资产，但需要持续维护。不更新、不验证，就会折旧成负债。

一个结构，如果能被你反复使用，能被AI理解，能让效率指数级提升，那它就是一种新的资本形态。不是金融资本，而是认知资本。

认知资本的概念听起来很美。但这里面有一个陷阱：谁都可以写模板，谁都可以搭流程，凭什么你的就比别人的值钱？换句话说，是什么决定了认知资产的质量？

3

答案是品位。

我给自己定了一条规矩：只做自己常用的App。自己不用的，不开发。这不是任性，而是在主动筛选——只有我愿意天天用、愿意长期打磨的东西，才值得投入时间。

在AI时代，”可实现的功能”正在迅速变得廉价。AI写代码越来越快，写文档越来越好。那么，真正稀缺的是什么？是判断。该做什么？什么算好？什么值得反复打磨？

我有胆囊结石和肾结石的小毛病，多喝水有助于改善。于是我做了一款提醒喝水的App，不是为了上架，不是为了给别人用，就是给自己用的。只有这样，我才是自己最严苛的用户，才能获得最真实的反馈。

我做喝水提醒、做冥想、做减少久坐的App，看起来是好几个产品，但它们共享同一套内核：我的交互风格、提醒语气、频率节奏，还有”不打扰”的边界感。这不是几个功能的堆砌，这是一个人品位的外化。

品位不是”我觉得好看”这种模糊的感觉，它可以被写成明确的原则。比如：不做连续打卡来羞辱用户。提醒要温和，不要控制。追求低摩擦、低噪音、可退出。App存在的目的是让用户最终不需要它。当品位能被写成规则，它就从感觉变成了可传承的资产。

品位能写成规则，这很好。但规则不是凭空冒出来的。没有人天生就知道”提醒频率多少合适”或者”什么语气不会让人反感”。这些判断需要一种特殊的土壤才能长出来。

4

这个土壤就是：用。自己做，自己用，反馈极快。

我用Codex帮我复刻排行榜前列的App，速度非常快。选中喜欢的之后，我自然就会追问：为什么它能排在前面？为什么会受欢迎？它的设计逻辑是什么？好奇心就是这样被点燃的。好奇心一来，学习就自然发生了。我不需要逼自己学，我是想知道。

更重要的是，自用产品天然形成了一个正反馈回路。App让生活变好了——喝水真的更规律了，身体确实更舒服了——我就更愿意继续用、继续改。改的过程提升了工程能力和产品判断力，我就更有本事把它做得更好。做得更好又带来更多反馈，循环自我加速。

很多人学东西学不下去，是因为只有”看书听课”这一层。没有”动手做”，没有”亲自用”。三层齐了，才会越做越上头。生活改善和技术成长同时发生，一个小App，变成了一个不断自我增强的飞轮。

品位就是在这个飞轮里磨出来的。每转一圈，判断力就更准一点，标准就更清晰一点，资产就更硬一点。

到这里，我们已经知道了三件事：有一种东西叫结构化认知资产，它具备复利效应；品位决定了这些资产的质量；而品位本身来自”自己做、自己用”的飞轮。但这就引出了一个更大的问题：当AI越来越强，人在这个系统里到底扮演什么角色？

5

回头看，我觉得答案藏在前面讲的这些事情里。我做模板，是在定义结构。我定规矩，是在设定标准。我只做自己用的App，是在决定什么值得做。写文章是把经验变成文字，做模板是把经验变成结构，做App是把经验变成产品。而品位，是贯穿其中的那条线。

AI擅长执行，人擅长定义。我沉淀工作流、积累助推模式、打磨品位原则，本质上是在构建”可被AI放大的结构”。别人也有AI，但没有我的结构、我的标准、我的系统。这种能力不怕AI变强，因为竞争的不是”谁写代码更快”，而是”谁判断得更准，迭代得更稳”。

我喜欢做这件事。不是因为它赚钱，不是因为它时髦。而是因为我自己需要它，我每天都在用它，它让生活确实变好了，能力也确实变强了。

也许在AI时代，人最该积累的不是代码，不是知识点，而是品位——你对”什么是好”的判断力。品位需要亲自使用、亲自感受、亲自打磨。它不能被AI替代，不能被快速复制。

这是最慢的资产，也是最硬的资产。

发表于 | 分类于

数字资产清单

最后更新：2026-02-22

一、硬件设备

1.1 电脑

项目 信息
型号 MacBook Pro 16 英寸（2023 年 11 月）
芯片 Apple M3 Max
内存 48 GB
存储 1 TB（已用约 538 GB，可用约 456 GB）
序列号 JP7XPYNFQC
系统 macOS Tahoe 26.2
保障 已过保

1.2 手机

项目 信息
型号 iPhone 14 Pro
存储 128 GB

1.3 外接显示器

项目 信息
型号 BenQ BL2780
尺寸 27 英寸
分辨率 1920 × 1080

1.4 存储设备

项目 信息
类型 移动硬盘
容量 500 GB
用途 存储电影，目前闲置

二、云服务 & 基础设施

2.1 阿里云 ECS

项目 信息
实例 ID i-wz9b4vjfjppzxji8ffyg
规格 ecs.n4.small（1 核 2 GB）
地域 华南 - 深圳（cn-shenzhen）
公网 IP 120.78.83.144
系统 Ubuntu 24.04.4 LTS
磁盘 40 GB（已用约 23 GB，60%）
用途 个人博客 + API 服务

服务器上运行的服务：

服务 说明
Nginx 反向代理，托管 Hexo 博客（liwenye.cn）
Redis 缓存服务
Docker 容器引擎（当前无运行容器）
check-wechat（:8082） 微信打卡相关服务
API 服务（:18080） 后端 API

2.2 腾讯云 CVM

项目 信息
实例 ID ins-04iegsde
规格 SN3ne.MEDIUM2（2 核 2 GB）
地域 华南 - 广州（ap-guangzhou-3）
公网 IP 43.136.123.200
SSH 用户 ubuntu
系统 Ubuntu 18.04.6 LTS
磁盘 50 GB（已用约 12 GB，24%）
用途 闲置，数据无需保留
到期时间 2026-09-01（不续费，到期自动释放）

2.3 域名

项目 信息
域名 liwenye.cn / www.liwenye.cn
注册商 阿里云
指向 120.78.83.144（阿里云 ECS）
HTTPS 已配置（TLS 1.2）
到期时间 2030-10-29

三、代码 & 开发资产

3.1 Gitee 仓库（gitee.com/levenyes）

仓库 技术栈 说明
my-account SwiftUI / Vision / Speech iOS 支出记录应用，支持截图 OCR 和语音识别录入支出
my-web-page HTML / CSS / JS + Node.js / Express / SQLite 番茄工作法 + 冥想 Web 应用，含用户系统、计时、统计
my-article Markdown 个人文章库，共 276 篇文章
my-library SwiftUI / Readium / MVVM iOS 电子书阅读应用，含书城、书架、EPUB 阅读器
pomotodo Java 17 / Spring Boot / MyBatis-Plus / MySQL / Redis 番茄钟任务管理后端，集成数据同步、阅读统计、邮件报告
my-first-app SwiftUI / Combine + Spring Boot 后端 “番茄冥想” iOS 应用，番茄计时 + 冥想计时 + 数据同步
python-tools Python / pandas / matplotlib / DeepSeek API 工具脚本集：数据导入导出、可视化、复习清单、Hexo 博客工具

四、账号 & 订阅服务

4.1 付费订阅

服务 费用 账号
ChatGPT Pro $200/月 jeremy92james@gmail.com

4.2 本地密钥存储（OpenClaw）

项目 信息
安装位置 MacBook 本机
用途 存放非极其重要的密钥（如阿里云密钥等），不存最敏感核心密钥
使用方式 Codex App 或 Cursor 可向 OpenClaw 索取这些密钥，便于在开发/运维时按需获取

五、数据资产 & 备份策略

待补充

六、运维整改记录

6.1 Hexo 依赖安全收敛（2026-02-22）

**目标：**处理 Hexo 站点 npm audit 高危漏洞。

执行结果：

指标 处理前 处理后
总漏洞数 27 8
Critical 3 0
High 12 6

已完成动作：

  1. 升级运行时与核心依赖（Node LTS + Hexo 主版本升级）。
  2. 移除未使用依赖：hexo-deployer-sftp、hexo-renderer-ejs。
  3. 保留主题运行所需依赖：hexo-renderer-swig@2.0.0、hexo-renderer-stylus@3.0.1。
  4. 在 /root/hexo/package.json 增加 overrides，强制 minimist 到安全版本，已清除 critical。
  5. 完成发布链路回归：update.sh --dry-run、--force-build、线上首页与静态资源探活均通过。

当前剩余高危（6）说明：

  1. swig 相关：swig-templates、swig-extras -> markdown。
  2. stylus 相关：stylus -> glob -> minimatch（上游无可用无损修复）。

后续方向（需要架构级迁移）：

  1. 主题模板从 swig 迁移到 nunjucks（或升级到不依赖 swig 的主题版本）。
  2. 样式链路从 stylus 迁移到 less/sass 或直接静态 CSS 产物。