发表于 | 分类于

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

你今天还差多少达成目标 13小时
AI工具使用时长 2,173小时
冥想时长(本月) 889.58(29.08)小时
你已经读了多少本书 3620本
阅读全文 »

发表于 | 分类于

风格参考：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.

发表于 | 分类于

一把更快的锤子

我有个朋友在做金融ToB的管理后台。去年他兴冲冲地告诉我，团队全面用上了AI编程工具，代码产出提升了三倍。

三个月后他又来找我，说交付速度反而变慢了。

我说你等等，代码写得更快了，交付怎么会更慢？

他说：以前一个需求改三个文件，现在AI一口气帮我改了十五个。改完发现权限漏了一个口子，回归测试没覆盖到，线上出了个事故，然后花了三天善后。

我突然想起了一个老笑话：给一个不会用锤子的人一把更大的锤子，他不会钉得更好，他会砸得更烂。

AI编程工具就是那把更大的锤子。问题从来不在锤子上。

The Architecture Tax

我在做Fog Creek的时候发明了一个叫“Joel Test”的东西——12个简单的是/否问题，用来判断一个软件团队的水平。今天我想发明一个新测试，叫Architecture Tax Test。

所谓Architecture Tax，就是你的系统结构每天在暗中向你征收的隐形税。每次你改一个小需求却要动七八个文件，那是结构税。每次上线前要花半天手工回归，那也是结构税。每次新同事问“这个逻辑在哪”你得想半天，那还是结构税。

问题在于，这种税是渐进的。就像温水煮青蛙，你每天多花20分钟不觉得什么，累积一年就是上千小时。

AI编程工具不仅不能减免这种税，反而会放大它。因为AI产出的速度更快，每天触发“结构税”的次数也更多了。以前你一天写一个功能，交一次税。现在你一天写三个功能，交三次税。而且AI不懂你系统里那些没写在文档里的潜规则，所以它触发的税率往往比你自己写的还高。

这就解释了我朋友的困境：AI让他写得更快了，但Architecture Tax也涨了。净效果反而是负的。

对金融系统来说，这不是效率问题，是安全问题

如果你做的是社交APP或者内容平台，Architecture Tax顶多让你慢一些。但如果你做的是金融系统，这税交不起。

金融系统有几样东西是绝对不能出错的：钱不能算错，权限不能漏洞，操作不能无法追溯。

想象一下：AI帮你快速写了一个新的退款接口，但它没注意到你们的系统里退款需要走审批流程。代码跑起来了，测试也过了（因为测试也没覆盖审批逻辑），上线后有人绕过审批直接退款。这不是bug，这是事故。

所以对金融ToB来说，架构不是“让你写得更好”的锦上添花，而是“让你不出事”的安全网。

两件事，而不是二十件事

大多数架构文章会给你列一个长长的清单：分层、DDD、微服务、事件驱动、CQRS、SAGA……看完之后你的感觉不是“我知道该怎么做了”，而是“我更迷茫了”。

我觉得金融ToB的小团队需要做的就两件事。不是二十件，是两件。

第一件：画清楚边界

你的系统里，订单是订单，流水是流水，账本是账本。这三样东西不能混在一张表里，也不能混在一个模块里。

听起来像废话对吧？但我见过太多金融系统，订单表里存着渠道状态，流水记录和业务订单纠缠不清，想做对账的时候发现数据根本对不上。

边界不仅仅是“代码放在不同的包里”。边界意味着：数据归属明确（谁能写这张表）、接口契约清晰（模块之间怎么通信）、变更范围可控（改一个模块不会把别的模块弄坏）。

当边界清晰的时候，AI的产出立刻变得安全很多。因为你可以告诉AI：“在这个模块里写代码，只通过这些接口和其他模块交互。”AI的活动范围被限定了，你的审查范围也被限定了。

第二件：建好护栏

护栏是什么？就是那些能帮你自动发现“AI搞错了”的东西。

幂等是一道护栏：同一个请求发两次，结果应该一样。这在支付场景里是生死攸关的事情——你不希望用户的钱被扣两次。做法也不复杂：每个请求带一个唯一ID，服务端维护一张去重表，先查再写。

对账是一道护栏：你的系统算出来的数字和渠道方的数字每天自动比对，有差异就报警。这意味着就算有bug偷偷溜进去了，最迟第二天你就能发现。

审计是一道护栏：每个敏感操作都记录谁做的、什么时间做的、做之前是什么样、做之后是什么样。不是为了抓人，是为了出问题的时候能快速定位。

自动化测试是一道护栏：AI写完代码之后，一键跑测试，通过了才允许合并。这是你对AI产出最基本的质量把关。

这些护栏不需要很花哨。它们需要的是存在和自动化。手动的护栏等于没有护栏，因为人会忘记、会偷懒、会侥幸。

模块化单体：不是因为简单，而是因为诚实

有一种流行的说法：微服务是“现代架构”，单体是“遗留系统”。这完全是胡说八道。

微服务解决的是一个非常具体的问题：当你的团队大到几十上百人时，如何让不同团队独立开发和部署。 如果你的团队只有五到十个人，微服务带来的好处几乎为零，但带来的成本是真实的——分布式事务、网络延迟、服务发现、独立部署流水线、运维复杂度。

模块化单体是一种更诚实的选择。它承认你是一个小团队，你的精力应该花在业务上而不是基础设施上。同时它又不放弃结构：模块之间有清晰的边界和接口，只是它们恰好运行在同一个进程里。

将来如果你真的需要把某个模块独立出去（因为它需要独立伸缩、或者有团队需要独立负责），你可以把它从模块“升级”为服务。但在此之前，你不用付那笔分布式的税。

关于Outbox模式的一个故事

我再讲一个我朋友的故事。

他们的系统需要在数据库里写入一条支付记录，同时往消息队列里发一条通知。听起来简单对吧？写完数据库，发个消息，搞定。

但有一天MQ挂了。数据库写成功了，消息没发出去。结果下游系统不知道这笔支付成功了，客户投诉了。

他们的第一反应是：加分布式事务。我说，别。分布式事务在这种场景里是用大炮打蚊子，而且大炮还可能炸到自己。

用Outbox模式就行了：在同一个数据库事务里，既写业务表，也写一张outbox表（记录“待发送的消息”）。然后用一个后台任务定期扫outbox表，把消息发到MQ。发成功了就标记为已发送。

这个方案简单到有些无聊。但它有一个非常好的性质：因为业务表和outbox表在同一个本地事务里，要么一起成功，要么一起失败。 你不需要分布式事务，不需要两阶段提交，不需要任何花哨的东西。

有时候最好的架构决策就是选择最无聊的方案。

The AI-Friendly Codebase Test

最后，我想留给你一个测试。就像Joel Test一样，这个测试用简单的是/否问题来判断你的代码库是否“AI友好”。

  1. 你的项目有清晰的模块目录结构吗？
  2. 每个模块的职责能用一句话说清楚吗？
  3. 模块之间是通过显式接口通信的吗？（而不是互相访问数据库表）
  4. 你有可以一键运行的测试套件吗？
  5. 你有统一的错误码和日志规范吗？
  6. 敏感操作有审计记录吗？
  7. 外部接口有幂等处理吗？
  8. 你有可以一键回滚的发布流程吗？
  9. 新功能可以用feature flag控制上线吗？
  10. AI在你的项目里写代码时，你有信心在10分钟内验证它的产出吗？

每个“是”得1分。8分以上，你的代码库已经是AI友好的了。5到7分，你需要花几周时间补课。4分以下，AI对你来说可能是负资产——它在帮你更快地挖坑。

这个测试的核心思想其实就一句话：AI的产出质量取决于你系统的结构质量。 如果你的系统是一个清晰的、有边界的、可验证的系统，AI就是一个极其高效的助手。如果你的系统是一团意大利面，AI就是一台更快的意大利面制造机。

给自己两到六周的时间，把分数提上去。你会发现这是你今年回报率最高的技术投资。

注：本文风格参考Joel Spolsky的技术写作风格。

发表于 | 分类于

一个反直觉的现象

最近和不少做金融ToB的朋友聊，发现一个很有意思的现象：大家都开始用Cursor、Codex写代码了，产出速度确实快了不少，但交付速度并没有等比例提升。有些团队甚至觉得更慢了——代码改得多了，回归测试跟不上，线上问题反而变多了。

这个现象反直觉，但并不难解释。

AI加速的是“写”，但交付瓶颈从来不在“写”。 交付瓶颈在于：你改了A模块，B模块会不会炸？你加了个新功能，权限有没有漏洞？你重构了一段逻辑，账务会不会算错？

说白了，AI是一台马力很大的引擎，但你的系统是一条坑坑洼洼的路。引擎越猛，你翻车越快。

所以今天我想聊的不是AI工具怎么用——那些技巧层面的东西你自己摸索就行。我想聊的是：在AI编程时代，你的系统需要什么样的架构基底，才能让AI的速度安全落地。

这件事对金融ToB场景尤其重要，因为金融系统不允许“快而不准”。

架构的本质：控制变更成本曲线

很多人对“架构”有误解，觉得架构就是画框图、选中间件、搞微服务。这些都是手段，不是目的。

架构的本质是什么？是一组关于系统结构的决策，这些决策决定了你未来每次变更的成本。

如果架构好，系统越做越顺，每次改动的范围可控、可验证、可回滚。如果架构差，系统越做越慢，每次改动都像在拆炸弹。

对于“小团队+金融ToB”的场景，架构要解决的核心问题就两类：

第一类：边界决策。 哪些东西必须隔离？租户隔离、权限隔离、账务与业务隔离、对外接口与内部实现隔离。边界清晰了，AI才能在一个模块里放心地写代码，而不会牵一发动全身。

第二类：护栏决策。 哪些东西必须可验证？幂等、对账、审计、回滚、测试、可观测性。护栏到位了，AI产出的代码才能被你快速验证，而不是写完之后你还得逐行审查。

当边界清晰、护栏到位时，AI才能在“可控范围”里高速产出。否则，AI只是帮你更快地制造技术债。

金融ToB的质量属性排序

不同系统的架构优先级完全不同。做社交的可以先跑起来再说，做游戏的可以容忍偶尔的数据不一致。但金融ToB不行。

我认为金融ToB管理后台的质量属性优先级应该是这样的：

1. 正确性与可审计性。 钱和权限必须算得清、查得到、追得回。这是底线，没有商量余地。

2. 安全与合规。 身份、权限、数据访问、密钥管理、操作留痕。金融监管越来越严，这个不是可选项。

3. 可维护性。 需求频繁变、人员有限，必须靠结构降低理解成本。这一点直接决定你的交付速度。

4. 交付效率。 自动化测试、灰度发布、快速回滚、环境一致性。

5. 可靠性与可用性。 故障隔离、降级、恢复、告警。

6. 性能与成本。 不是不重要，而是在结构正确之后更容易优化。

你会发现，大多数团队喊“成本高、交付慢”，根源都在第3、第4项：可维护性差导致每次改动都要全局理解，回归范围大，交付自然慢，人力成本自然高。

所以你最先要补的，不是什么高并发、分布式，而是“模块化+工程化交付”这条链路。

模块化单体：小团队最务实的选择

大厂喜欢上来就搞微服务，但我一直觉得这对小团队是灾难。

微服务的分布式成本是真实的：服务发现、链路追踪、分布式事务、独立部署流水线、网络延迟、运维复杂度。这些东西每一项都需要人力和基础设施来支撑。一个5到10人的团队去搞微服务，大概率的结果是把80%的精力花在运维和联调上，真正写业务的时间反而更少了。

我推荐小团队用模块化单体（Modulith）。

什么意思？在一个代码仓里，把系统按业务边界划分成独立的模块，模块之间通过显式接口通信，不允许互相直接访问数据库表。像微服务一样有边界，但不承担微服务的分布式成本。

你可以把系统分成四层，但重点不在分层，在于依赖方向：

Interface层：Controller、RPC、MQ Consumer、Job Handler。接收外部请求。

Application层：用例编排。事务边界、权限检查、调用顺序、DTO转换。

Domain层：领域模型与规则。状态机、金额计算、风控规则、权限策略。

Infrastructure层：DB、Cache、MQ、第三方支付、对象存储。

关键原则是：依赖方向向内，Domain层不依赖DB和MQ。 IO和业务规则必须分离。AI写代码时最容易把IO和业务搅在一起，你要用结构纠正它。

当你未来真的遇到独立伸缩或团队扩张的需求时，再把某个模块“自然地”拆成服务。这比一开始就搞微服务然后到处踩坑要高效得多。

模块边界怎么划

金融ToB系统的模块划分，我推荐三种方式混合使用。

按业务能力划分

这是最常见的方式：Tenant（租户）、Identity（认证）、Permission（权限）、Order（订单）、Ledger（账本）、Settlement（清结算）、Risk（风控）、Reporting（报表）、Integration（对外接口）。

按数据归属划分

这在金融系统里特别重要。谁拥有数据、谁能写、谁能改规则，边界就在哪里。

举个例子：Order模块拥有订单表的写权限，Ledger模块拥有流水分录表的写权限，Reporting模块只读。如果Reporting模块能改交易表，边界就崩了。

按变化频率划分

高变化：运营规则、活动配置、报表、流程编排。低变化：账务规则、权限模型、核心状态机。

把高变化的东西隔离出来，你会明显感觉“改起来更轻”，AI也更容易在高变化模块里安全产出。

金融系统的六块硬骨头

做金融ToB管理后台，有六件事处理不好就会反复拖慢你的交付。

多租户隔离

小团队从逻辑隔离起步没问题，但要把它做“硬”：每张业务表都有tenant_id，所有查询默认带tenant_id（在ORM层做拦截），管理员跨租户访问要显式标记并进入审计。

这三条是底线，不做到位后面全是坑。

权限模型

RBAC打底，ABAC兜底。权限检查集中在Application层，不要散落在Controller里到处if。所有敏感操作引入maker-checker（四眼原则）——提交人和审批人必须分离。

权限策略要写成可测试的函数，不要搞一堆注解魔法。AI能帮你写测试，但前提是你的权限逻辑是可测试的。

审计日志

金融系统的审计不是记个“谁点了什么按钮”就完事。你要能回答：谁、在什么时间、对哪个租户、做了什么操作、操作对象是什么、操作前后的差异是什么、操作依据是什么。

建议把审计当成独立模块，事件不可变（append-only），与业务写入解耦。

幂等

幂等不是加个唯一索引那么简单。你至少要定义：幂等的粒度（接口级还是业务动作级）、幂等key（谁生成、如何传递）、重复请求的返回策略。

实用做法：每个外部请求带request_id，维护一张idempotency_record表，先insert利用唯一键判重，冲突了就返回已存在的结果。这样你可以抵抗重试、超时、消息重复投递。

对账

对账的本质是：在两个或多个系统之间，基于同一批事实，重复计算并比较差异。

架构要点：保留原始回执，记录对账批次和差异项，差异处理走审批流程并可追溯。绝对不允许“手工改账本”，只能通过冲正或补录形成新的事实。

状态机

金融流程一旦复杂（支付、退款、清结算、额度变更），状态机是最有效的治理手段。明确状态集合、事件集合、每个转换的前置条件与副作用，每次状态变化记录事件日志。

状态机的好处在AI时代特别明显：当你有清晰的状态机定义时，AI生成代码更不容易“漏一个分支”，你也更容易验证AI的产出是否正确。

一致性：别和CAP辩论，先把工程问题拆清楚

小团队的ToB项目不是超大规模分布式系统，但你依然会遇到MQ重复消费、第三方超时回调乱序、跨模块一致性、报表最终一致这些问题。

我的建议是：统一你的可靠性语义。 把几类常见动作统一成可复用的模式，减少每个业务都重新发明轮子。

超时：每个外部调用都必须有超时，没有例外。

重试：只对幂等动作重试，指数退避，有最大次数。

去重：消费者基于幂等key去重。

补偿：失败后有可执行的补偿流程。

当你需要“写DB+发消息”保持一致时，用Outbox模式：在同一个本地事务里写业务表和outbox表，用后台任务把outbox发到MQ。简单、可靠、可追溯，是小团队做最终一致的性价比之王。

当你确实跨多个步骤时，用SAGA。小团队建议用编排式SAGA（中央流程编排器），比协同式更易理解和排错。

让AI真正提效的关键：把项目改造成“AI友好型”

你已经在用AI工具了，这是好事。但大多数人只是用AI来“写代码”，我认为这浪费了AI80%的能力。

AI真正能帮你做的事情远不止写代码：需求分析、方案比较、测试生成、代码审查、文档维护、重构规划。但前提是你的项目结构能让AI“理解”你的系统。

三个前提条件，缺一不可：

稳定的项目结构。 目录、命名、模块边界清晰。AI需要从结构中理解上下文。

可运行的自动化。 最少要有一键测试、一键启动。AI产出的代码必须能被自动验证。

清晰的契约与规范。 接口契约、错误码、日志字段、DTO规则。AI需要这些来保持一致性。

这三点是AI提效的放大器。否则AI会把耦合与混乱也加速放大。

当你把这些基础设施建好之后，你可以让AI做更多事情：写ADR草案、生成测试用例、做Code Review、规划重构路径。每一件事都能节省你大量的时间和精力。

写在最后

我一直认为，架构能力不是一种“高级技能”，而是一种工程纪律。它不需要你读多少论文、用多少新技术，而是需要你对“边界”和“护栏”有清醒的认识，并且有纪律地执行。

在AI编程时代，这种纪律变得更重要了。因为AI给了你前所未有的产出速度，而速度在没有结构约束的情况下，只会加速制造混乱。

对于金融ToB的小团队，我的建议很简单：不要追求架构的“全面”，追求架构的“准确”。 把模块边界画清楚，把自动化护栏建到位，把AI工具用对地方。用两到六周的时间，把项目改造成一个“模块边界清晰、自动化护栏到位、可灰度可回滚”的AI友好型系统。

当你做到这一点，你会发现：需求更敢接、重构更敢做、上线更敢频繁、成本开始下降。

这不是什么宏大的架构蓝图。这就是工程纪律。

注：本文风格参考陈皓（左耳朵耗子）的技术写作风格。

发表于 | 分类于

你的问题真的是“架构”吗？

很多人跟我说：“我需要学架构。”

我通常会问：你遇到的具体问题是什么？

答案往往是这样的：改一个需求要动很多地方，上线怕出问题，回归测试跟不上，新人看不懂代码。

这些问题听起来像“架构问题”，但我想请你停下来想一想：你现在的痛点，真的需要“更多的架构”来解决吗？还是说，你需要的其实是“更好的设计”？

架构和设计是两件不同的事情。架构是关于系统级别的大决策——技术选型、部署形态、模块划分。设计是关于每一天、每一行代码的小决策——职责怎么分配、接口怎么定义、依赖怎么管理。

很多团队的问题不在于缺少架构，而在于日常的设计太粗糙。代码没有清晰的职责划分，模块之间随意调用，接口定义含糊不清。这些问题积累起来，系统就变成了一团纠缠不清的线球。

而AI编程工具的到来，让这个问题变得更加紧迫了。因为AI产出的速度很快，如果你的设计不能给AI一个清晰的框架，它只会以更快的速度向这团线球里缠入更多的线。

所以在聊“架构”之前，我想先聊一个更基本的问题：分离关注点。

分离关注点：一个被说烂了但很少被做好的事情

“分离关注点”这几个字，每个程序员都听过。但我的观察是，真正在日常工作中贯彻它的团队并不多。

什么叫分离关注点？我举一个金融系统的例子。

一个支付场景里，至少有三个不同的关注点：

业务订单：用户发起了什么操作？状态是什么？这是业务维度的事情。

资金流水：钱从哪里到哪里？渠道返回了什么？请求是否成功？这是资金维度的事情。

账务分录：记账的借方是多少？贷方是多少？余额变化了吗？这是会计维度的事情。

很多系统把这三样东西混在一起。订单表里存着渠道状态，流水和订单共享同一个状态机，账务余额直接在订单表上计算。

一开始，这样做看起来很“高效”——少建几张表，少写几个模块，代码量也少。但随着业务复杂度增加，问题会越来越明显：改订单逻辑怕影响账务，做对账发现数据对不上，退款的时候状态机打架。

这就是没有分离关注点的代价。三个不同的关注点被绑在一起，一个变了其他两个都受影响。

正确的做法是：订单是订单，流水是流水，账本是账本。 三个独立的模块，各自有自己的数据表和状态机。它们之间通过明确的接口通信，而不是共享数据库表。

这样做一开始会多写一些代码，但你获得的是：每个模块可以独立修改、独立测试、独立理解。AI在一个模块里写代码时，不需要理解其他模块的内部逻辑。

小步走：把大问题变成小问题

分离了关注点之后，下一个问题是：怎么改进？

很多人的思路是“大重构”——画一个理想的架构图，然后花几周时间把系统从旧结构迁移到新结构。

我不建议这样做。

大重构的问题在于：它的反馈周期太长了。你花了两周写代码，上线的时候才发现一堆问题。而且在这两周里，业务需求还在持续进来，你的重构分支和主干的差异越来越大，合并的时候冲突满天飞。

更好的方式是小步走。

每次只做一件事：提取一个接口，移动一段代码，消除一个循环依赖。每一步都可以独立提交、独立测试、独立上线。如果出了问题，回滚的范围也很小。

小步走在AI时代特别好用。你可以把每一步交给AI来做：

“帮我把Controller里的权限检查逻辑提取到Application层。”

“帮我给这个支付状态机写一组单元测试。”

“帮我把这个模块对外的接口定义成一个独立的Interface。”

每一步都很小，AI很容易做对。做完之后你可以快速验证。这比让AI做一个大重构要安全得多。

你真的需要微服务吗？

我经常听到这样的话：“我们的系统越来越复杂了，应该拆微服务了。”

每次听到这句话，我都想问一个问题：你的系统复杂在哪里？

如果复杂性来自于模块之间没有清晰的边界——代码互相调用、数据互相访问、改一个地方到处出问题——那拆微服务只是把一团乱麻变成了分布在不同机器上的一团乱麻，外加网络延迟和分布式事务的复杂度。

你的问题不在于代码跑在几个进程里，而在于代码之间的依赖关系没有管好。

模块化单体是一种更务实的选择。它的意思是：在一个代码仓里，把系统按业务领域分成独立的模块。每个模块有自己的代码包、自己的数据表、自己的接口。模块之间不能互相访问数据库表，只能通过接口调用。

这听起来很像微服务。区别在于：它们运行在同一个进程里，所以没有网络延迟、没有分布式事务、没有服务发现。

关键的设计约束是：依赖方向向内。 最内层是领域逻辑（Domain），它不依赖任何外部技术——不依赖数据库、不依赖消息队列、不依赖HTTP框架。技术细节在外层，领域逻辑在内层。这样你的核心业务规则可以独立测试，不需要启动任何中间件。

如果将来你确实需要把某个模块独立部署，边界已经在那里了，拆分是自然而然的事情。但在大多数情况下，你不会需要。

护栏：不是防别人犯错，是防自己犯错

做金融系统的人都知道“正确性”很重要。但“知道”和“做到”之间有巨大的鸿沟。

我见过太多系统，大家都知道幂等很重要，但真正落地的时候只是在接口上加了个唯一索引。当遇到超时重试、消息重复投递、回调乱序这些真实场景时，系统的行为是不可预测的。

问题出在哪里？出在我们把“护栏”当成了“事后补救”，而不是“设计的一部分”。

我认为，在金融系统里，幂等、对账、审计这些东西不是“非功能性需求”，而是一等公民。它们应该在设计阶段就被考虑进去，而不是上线之后才补。

幂等的设计方式：定义清楚幂等的粒度和幂等key的来源。维护一张去重表，每个请求先查表再处理。重复请求返回第一次的结果，而不是报错。这个逻辑要抽象成通用组件，不要每个接口自己实现一遍。

对账的设计方式：保留所有的原始回执和原始数据。每天自动运行对账，比较你的记录和对方的记录。有差异就进入处理流程，不允许手工改账本——只能通过冲正和补录来修正。

审计的设计方式：把审计事件设计成不可变的事件流。每条记录包含操作人、操作时间、操作对象、操作前后的关键字段快照。不要把审计逻辑散落在业务代码里，把它集中到一个独立模块。

这些护栏建好之后，你会发现一个有趣的现象：你对AI产出的代码更有信心了。因为就算AI写的代码有bug，幂等机制可以防止重复操作，对账可以在第二天发现异常，审计可以帮你追溯问题。AI不需要是完美的，它只需要在护栏的范围内工作。

可测试性：比什么架构模式都重要

如果让我只选一个标准来判断一个系统的设计好不好，我会选可测试性。

可测试性好意味着什么？意味着你的模块职责清晰（否则你不知道测什么），接口定义明确（否则你不知道怎么mock），副作用被隔离（否则测试要启动一堆中间件）。

可测试性差意味着什么？意味着代码的职责、接口、副作用都是模糊的、纠缠的、不可控的。

换句话说，可测试性是设计质量的一面镜子。如果你的代码难以测试，那一定是设计出了问题，而不是测试出了问题。

在AI编程时代，可测试性还多了一层意义：它是你验证AI产出的最高效手段。

你可以让AI先写测试，再写实现。或者你写测试，让AI写实现。不管哪种方式，测试都是你和AI之间的“契约”——它定义了正确的行为是什么，AI的代码要通过这个契约才能被接受。

金融系统里最需要测试的几个方面：

状态机的完整性：每个状态转换都有对应的测试？不允许的转换有没有被拒绝？

权限的边界：同角色不同租户能访问吗？不同组织的数据能看到吗？越权操作会被拦截吗？

幂等的正确性：同一个请求发两次，结果一样吗？并发发送呢？

金额计算的准确性：边界值对不对？精度有没有丢失？冲正之后余额对不对？

这些测试写好之后，你让AI改代码就心里有底了。因为测试会告诉你AI有没有破坏已有的行为。

最小的下一步

如果你看完这篇文章，觉得有道理但不知道从哪里开始，我给你一个建议：找到你系统里最痛的那个点，用最小的步骤去改善它。

不要试图一次解决所有问题。不要画一个宏大的架构蓝图。不要花两周时间做一个大重构。

找到那个“每次改需求都要碰、每次碰了都怕出事”的模块。看看它为什么痛——是职责不清？是接口模糊？是缺少测试？还是和其他模块纠缠在一起？

然后做一件最小的事情来改善它。也许是给它的核心逻辑写几个测试。也许是把它和另一个模块之间的直接数据库访问改成接口调用。也许是把散落在各处的权限检查集中到一个地方。

每件事都很小。每件事做完之后，系统都比之前好一点。

这就是我理解的好设计：不是一步到位的完美方案，而是持续改善的能力。

在AI编程时代，这种“小步改善”的能力比以往任何时候都重要。因为AI给了你前所未有的改代码的速度，而你需要的是让每一次改动都是向更好的方向走，而不是更乱的方向走。

分离关注点，小步前进，建好护栏，保持可测试。

做到这四件事，你的系统就能在AI的加持下越来越好，而不是越来越乱。

注：本文风格参考郑晔（开源项目moco作者，《软件设计之美》作者）的技术写作风格。

发表于 | 分类于

风格参考：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 去执行、让保证层来兜底、让人类做最终裁决。

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