Agent on 小盒子的技术分享

我用两句中文，让 Claude Code 帮我画了10张出版级技术图

Sun, 12 Apr 2026 08:38:12 +0000

前两天在写一篇技术文章，写到一半需要配一张微服务架构图。我打开了某在线画图工具，对着空白画布发了十分钟的呆，拖了两个方块，连了一条线，觉得丑，删掉，再拖两个方块。

半小时过去了，图还没画完，文章的灵感已经凉透了。

我相信很多搞技术内容的朋友都有过这种体验。你脑子里其实很清楚这张图应该长什么样，但你就是得花一两个小时在画图工具里对齐、配色、调字号。明明内容才是核心，结果时间全花在了排版上。

然后我发现了一个东西，彻底解决了这个问题。

它叫 fireworks-tech-graph，是一个 Claude Code 的 skill。装上之后，你跟 Claude Code 说一句中文，它就能给你吐出一张出版级别的技术图。SVG 矢量源文件加 1920px 高清 PNG，直接能往文章里塞。

我用它画了10张不同类型的图，从架构图到 ER 图到状态机，从白底极简到暗色霓虹到工程蓝图。每张图从下指令到拿到成品 PNG，平均不超过30秒。

30秒。

我之前在画图工具里对齐一个箭头的时间都不止30秒。

怎么装呢，你甚至不需要记任何命令。

打开 Claude Code，直接跟它说「帮我安装 fireworks-tech-graph 这个 skill」，它自己就把活干了。装完之后你说「画一个 xxx 图」，它就自动触发。

如果你喜欢手动装也行，就一句 claude skills install fireworks-tech-graph，完事。

触发词非常宽泛，「画图」「帮我画」「做个架构图」「生成一个流程图」「可视化一下」，随便怎么说都行，它都能识别。

它能画什么？

这个 skill 支持10种有模板的图表类型，外加4种无模板但有规则定义的类型。我挑几个最实用的说一下。

1，架构图。这是用得最多的，画微服务分层、系统组件关系。你告诉它有哪些服务、怎么分层、哪些组件之间有调用关系，它自动帮你排好。我画的那张微服务架构图有5层，右侧还挂了一个观测性旁路，出来的效果跟正经架构文档里的图一模一样。

2，流程图。CI/CD 流水线、审批流、业务决策流。菱形判断节点、圆角矩形处理步骤、失败回环，全都有。你只需要描述「从提交代码到部署生产」中间经过哪些步骤和判断就行。

3，时序图。微服务之间谁先调谁，消息怎么传递。标准的 UML 时序图，有生命线、激活框、alt 分组框。你列出参与者和消息序列，它帮你排好。

4，ER 图。数据库表之间的关系。支持鸦脚记法，PK 自动下划线，FK 标注。你把实体和属性列出来，告诉它哪些是一对多、哪些是多对多，它画出来的东西可以直接放进数据库设计文档。

5，状态机。订单生命周期、工单状态流转这种。每个状态是一个圆角矩形，转换线上标事件名，有初始态的实心圆和终态的同心圆。

6，对比矩阵。横评几个模型、几个方案的时候特别好使。我画了一张 LLM 模型对比表，5个模型7个维度，绿色打勾红色打叉，交替行填充，出来就是一张可以直接发朋友圈的表。

7，时间线。项目路线图、版本规划。甘特图样式，彩色横条加菱形里程碑。

除了这些，还有 Agent 架构图、用例图、数据流图。反正你在技术写作里能用到的图，它基本都覆盖了。

比较骚的是它有7种视觉风格，每种味道完全不一样。

默认的 Flat Icon 是白底彩色，适合博客和文档。Dark Terminal 是暗色霓虹风，发 GitHub 和技术社区特别帅。Blueprint 是工程蓝图风，深蓝色背景加网格线加角标，那种 CAD 图纸的感觉。Notion Clean 是极简白，一根线一个色。Glassmorphism 是毛玻璃卡片，适合产品官网和 Keynote。最近还加了 Claude Official 和 OpenAI Official 两种风格，分别是 Anthropic 和 OpenAI 的品牌调性。

你指定风格的方式就是在 prompt 里加一句「用蓝图风」或者「Style 3」，就这么简单。

我觉得这个 skill 最打动我的点，不是它画得多漂亮，而是它把「画图」这件事的心理门槛降到了零。以前我写文章需要配图的时候，经常会想「算了这里用文字描述一下也行吧」，因为打开画图工具、画完、导出、插入这一套流程太重了。现在不一样了，我在 Claude Code 里写着文章，写到需要配图的地方，直接说一句「帮我画一个 xxx」，30秒后图就在本地了。

这种体验就像是，你本来在用文本编辑器写代码，突然有人给你装了一个实时预览插件。功能上没变，但那个「随时能看到效果」的即时反馈感，会让你更愿意去做这件事。

画图也是一样。当成本足够低的时候，你会发现你开始「想画就画」了。

想试的朋友，打开 Claude Code，说一句「帮我安装 fireworks-tech-graph」，等它装完，再说一句「画一个 xxx 图」。

就这么简单。两句话的事。

下面附一些 demo 图：

让Agent快上100倍的秘密，其实藏在一本大一计算机教科书里

Sat, 11 Apr 2026 10:50:21 +0000

事情是这样的。

最近我几乎每天都在用Claude Code写东西。用得越多，我越产生一种奇怪的感觉。

就是你给它下完一个任务之后，它开始一步一步地干活。先是啪，读了一个文件。然后哒，想了几秒。然后啪，又打开一个文件。再想几秒。再打开一个文件。就这么一直持续下去。

你坐在椅子上看着进度条一格一格地亮起来，心里清楚得不能再清楚，这十个文件它明明可以一起读的，它们之间根本没有任何依赖关系。

但它就是不。它就是要一个接一个地来。

一时间无语凝噎。

后来我跟几个同样重度用Agent的朋友聊了一下，他们也都有这个感受。说真的我始终觉得这是现在所有Agent产品共同的一个病，不管是 Claude Code、Cursor、Manus还是那些MCP插件，只要你让它干稍微复杂一点的活，你就会看到它在那里慢悠悠地一步一步走，像一个做事非常有耐心但完全不会一心二用的老实人。

前两天跟朋友吐槽这事的时候，我又想起了两年前Berkeley那帮人写的一篇论文。论文叫LLMCompiler，2024年就发在ICML上了，现在回头看它也不算新东西。但每次我被Agent气到的时候都会想起它，觉得它的思路到今天都没过时，甚至越品越有味道。

它当时就已经把这个病的根源讲得很清楚了，这个慢不是LLM的错，也不是任务复杂度的错，是我们给它用的那套调度系统，还停留在1960年代的水平。

这篇论文的名字挺干的，叫**《An LLM Compiler for Parallel Function Calling》**，ICML 2024。作者是Sehoon Kim、Amir Gholami那帮人，都在Berkeley和LBNL。它不是今年的新论文，但在我心里一直是Agent方向上最被低估的几篇之一。

它在做的事其实非常cool。

它在把大学一年级《计算机组成原理》那本书里的东西，原样搬到LLM的世界里。

坦率的讲，你想想看过去60年整个计算机体系结构的历史，其实就是一部「怎么让本来是串行的指令跑得更并行」的历史。指令流水线、乱序执行、超标量、分支预测，这些听着就头大的名词，说到底都是在干一件事，就是让CPU不要一条指令一条指令傻乎乎地等，能同时干的活就一起干。

这套东西人类已经研究得非常透了。透到什么程度呢？透到你今天买一颗普通的i5芯片，它每个时钟周期能同时发射的指令数，大概是80年代那种整栋楼的超级计算机的水平。

但是。

当我们把LLM当成一种新型处理器去用的时候，这套智慧全忘了。

现在几乎所有的Agent框架，底层都是一个叫ReAct的东西。它是Yao等人2022年提的，全称是Reason + Act。工作方式非常朴素，想一步，做一步，看结果，再想一步，再做一步，再看结果。它是一个循环。

听着很自然对吧？它确实自然。但你仔细看就会发现，这玩意从执行效率上来说，跟那种每次只能执行一条指令、做完一条才开始下一条的远古处理器，是一样的。

一次一条。干等。

而且这个问题在越来越多的Agent场景里暴露得越来越厉害，因为我们现在给Agent的活越来越复杂，一次要调用的工具越来越多。ReAct的串行执行就成了一个越来越重的镣铐。

回到LLMCompiler这块。

作者的思路简单粗暴，既然Agent执行工具调用的过程跟CPU执行指令长得一样，那就直接套编译器的架构好了。他们搞了三个组件。

第一个叫 Function Calling Planner，函数调用规划器。你可以把它想象成编译器里那个分析语义、构建依赖图的部分。用户给了一个问题，比如论文里举的那个例子，「微软的市值需要涨多少才能超过苹果？」，Planner要做的事情是先把这个问题拆成几个独立的任务，再搞清楚这些任务之间谁依赖谁。

它会拆成三步。

一，去查微软的市值。二，去查苹果的市值。三，用一个数学工具做减法，把差值算出来。

然后它会发现一件事，任务1和任务2，彼此没有任何关系。它们完全可以同时去查。只有任务3需要等前两个都拿到结果。

这就是一张 DAG，有向无环图，编译器里最核心的数据结构之一。

第二个组件叫 Task Fetching Unit，任务获取单元。这个名字直接就是从CPU里偷来的。

在现代CPU里有一个东西叫指令获取单元，它的任务是一旦前一条指令把某个寄存器的值算出来了，立刻把依赖这个寄存器的下一条指令发射出去，别等一整串指令都准备好再开搞，那样太慢。

LLMCompiler的Task Fetching Unit做的事完全一样。Planner一吐出DAG，它就开始扫描，发现哪些任务的依赖已经解决了，立刻往下扔。任务1和任务2没有依赖？好，同时发射，两个搜索并行执行。任务3等着1和2的结果？好，等它们回来我再把结果塞进任务3里，然后发射。

整个过程是流式的。Planner一边在吐计划，执行器一边在干活，中间没有「等Planner把所有计划全想完再开始」这种停顿。论文里专门做了个消融实验，流式处理本身就贡献了一个量级的加速。

第三个组件叫 Executor，执行器。这个没啥好说的，它就是真正去调工具的那个家伙。Task Fetching Unit告诉它哪个工具可以调了，它就调。

三个东西加起来，整个架构就跟一台小号的CPU一模一样。有人分析程序，有人调度，有人执行。

说到这我真的有点被打动。你知道我为啥被打动吗？因为这个思路其实任何一个学过编译原理的本科生都能想到。它没有任何复杂的数学，没有什么神秘的训练技巧，就是把一个用了60年的老配方，拿来炒一道新菜。

但它偏偏有效。而且效果好到离谱。

顺着上面的再聊聊，这篇论文最让我兴奋的其实是实验结果部分。

作者用了四个benchmark来测试LLMCompiler。这四个测试排起来有一个隐藏的升番结构，从最简单的场景到最复杂的场景，效果一个比一个炸。我逐个说一下。

第一个叫HotpotQA。这是个很经典的多跳问答数据集，论文的Figure 1就举了一个例子，「斯科特·德瑞克森和埃德·伍德是不是同一个国籍？」这种问题。用ReAct的话就是一步一步来，先搜A，拿到结果，再搜B，拿到结果，再对比。用LLMCompiler的话，A和B可以同时搜。

速度快了1.8倍。成本降了3.37倍。准确率基本一样。

就这个结果拎出来看已经很能打了，但它只是开胃菜。

第二个叫Movie Recommendation。这个更有意思，它每次要你从8部电影里找出跟某部电影最像的那部。也就是要对8部电影分别做独立的搜索和分析。

ReAct在这里干了一件特别傻的事。论文附录里有一张图我看完直接笑出声，它显示有大约85%的样本，ReAct根本没搜完8部就结束了。它搜到第五部就停下来，觉得「我好像够了」，然后给一个答案。

你敢信？？？

一个号称能干活的Agent，居然连把活干完都做不到。它会提前认输。

LLMCompiler在这里就完全没这个问题，因为Planner一开始就把8个任务全部规划好了，Executor必须全部执行完才能汇总。结果是速度快了3.74倍，成本降了6.73倍，准确率还反超ReAct 7个多点。

第三个叫Game of 24。这游戏你们可能玩过，给你4个数字让你用加减乘除搞出24。之前最强的解法叫Tree-of-Thoughts，让LLM自己去搜索各种可能的组合。LLMCompiler在这里做了一个很骚的事，它把「Tree-of-Thoughts的一次尝试」当成一个工具，然后让Planner去并行调度这些尝试。

速度快了2倍。

到这里我已经觉得够牛了。

但是真正让我给整不会的是第四个benchmark，WebShop。这是一个模拟网上购物的环境，你要在一堆商品里找到符合某些需求的那一个。典型的操作是搜索→看结果→再搜索→再看结果。

LLMCompiler在这里直接跑出了101.7倍的加速。

不是10倍，不是50倍，是一百零一点七倍。

而且成功率还比ReAct高了25.7个百分点。

我第一次看到这个数字的时候真的愣住了。我来回看了好几遍论文的表格，生怕自己看错了小数点。101.7x。

它的原因其实非常直观。WebShop里有大量「先广撒网再选最优」的搜索动作。LLMCompiler可以一口气把所有候选搜索并行发射出去，而ReAct得一个一个搜。你想想，如果你在淘宝上找一个东西，你是一次打开十几个标签页横向对比，还是一个一个点开再返回再点开？

答案很明显。

但前者需要你有一个「规划」的能力，得先知道哪十几个是值得看的。这恰好就是LLMCompiler在做的事。

这块需要注意一下。LLMCompiler的意义不只是快，还有一个更深的点，它顺手救了准确率。

这个我刚才提到了一嘴，但值得展开说说。作者分析了ReAct失败的案例之后发现，这些失败的绝大多数其实跟智力无关，跟纪律有关。

两种典型的失败场景。一种是提前收工，它只搜了部分信息就觉得够了，开始瞎答。另一种更惨，是它会在同一个查询上无限循环，因为Wikipedia返回的信息不够精确，它就一直搜一直搜一直搜，直到context window爆掉。

这两种失败加起来，贡献了ReAct绝大部分的失败样本。

为啥会这样？我自己的理解是，ReAct是一种即兴架构。它没有全局视野，每一步都是基于上一步的观察临时决策的。这种即兴决策模式很像我们人脑，但它也天然带着人脑即兴决策的毛病，容易累、容易放弃、容易走进死胡同。

LLMCompiler强迫模型在一开始就把所有要做的事列出来，这等于逼着它做一次系统性的规划。规划好了之后，执行阶段就只负责执行，不再思考。

我觉得这里有一个非常深的启发。我们过去几年一直在迷信让LLM多想一步，搞出了Chain-of-Thought、Tree-of-Thoughts、Self-Reflection各种花活，都是在鼓励模型「思考得更细、更久、更多」。但其实有时候反过来，让它先想一次然后别再想了，反而更管用。

CPU的设计哲学其实也是这样。现代CPU里最快的指令是那些不需要跳转、不需要预测、不需要动态决策的指令。凡是涉及到走一步看一步的指令，都会拖慢整条流水线。

计算机硬件的人早就发现了，即兴决策是昂贵的。

而这个老道理，现在又回到了AI Agent这边。

坦率的讲，我觉得LLMCompiler这篇论文本身可能不是最大的新闻。真正的新闻是它揭示的那个更大的趋势。

我们正在把整个计算机体系结构，重新发明一遍。

你仔细想想这几年LLM推理和Agent方向上那些最亮眼的突破，几乎每一个都能在老教科书里找到原型。

Speculative decoding，是把CPU的分支预测搬到了LLM推理。 KV cache，是把CPU的cache机制搬到了LLM推理。 Continuous batching，是把操作系统的进程调度搬到了LLM推理。现在LLMCompiler，是把编译器的指令调度搬到了LLM Agent。

每一个都在发生。每一个都带来10倍甚至100倍的加速。每一个的核心创意都不是横空出世的神来之笔，而是一句「等等，这个问题我们在硬件/OS层面已经解决过了，直接拿来用就好」。

卡帕西前阵子说过一句我记了很久的话，他说LLM是一种新的计算机，一种以自然语言为指令集的计算机。这句话如果你真的认真对待，那它的所有推论都是自洽的。既然它是一种新的计算机，那我们给旧计算机发明的所有优化技巧，理论上都应该能再用一次。

我有时候会觉得，我们这一代做AI的人特别幸运。我们在亲眼看一部已经拍过一遍的电影，被用新的道具重新拍摄。剧本是一样的，角色是一样的，剧情走向都是一样的。但因为道具全换了，看起来就像一部全新的片子。而且你手里只要有一本原版的剧本，你就能提前知道下一幕会发生什么。

回到这篇论文本身。

我觉得它最重要的贡献其实不是那些benchmark数字，而是它开了一个非常清晰的方向。那就是Agent的慢不是不可解决的。

你今天用Claude Code等十分钟，不是因为LLM笨，也不是因为你的任务太复杂。是因为底下那套调度系统还在用ReAct这种20世纪60年代级别的执行模式。只要换上哪怕一个粗糙的编译器思路，立刻就能快10倍、快100倍。

其实这两年已经有不少框架在往这个方向走了，LangGraph、LlamaIndex都陆陆续续搞过类似的planner组件，多Agent框架里的并发调度也都能看到这套思路的影子。但奇怪的是，我们日常在用的那些最主流的Agent产品，Claude Code、Cursor这些，还是没有把这套东西吃得特别透。你还是经常能看到它们在那里一步一步串行地跑，跑得你抓狂。

我始终觉得这是一件很可惜的事。一个两年前就该被充分吸收的好思路，到今天还只在部分框架里存在，绝大多数用户还是在吃ReAct的苦。

其实之前OpenAI做过一个简化版，它叫Parallel Function Calling。但这篇论文里也明确对比了，OpenAI那个只能处理最简单的、完全独立的并行任务，一碰到有依赖关系的就歇菜了。LLMCompiler能处理有依赖的完整DAG，这是质变。而且论文在ParallelQA这个他们自己造的benchmark上，直接把OpenAI的并行函数调用给干穿了。

还有一个让我很开心的点，LLMCompiler不依赖特定模型。它能跑在闭源的GPT系列上，也能跑在开源的LLaMA-2 70B上，效果都很好。这意味着你要用它，不需要求爷爷告奶奶去办一个特殊API，自己拿个开源模型搭一套就能跑。对整个开源生态是实实在在的利好。

论文的代码早就开源在 https://github.com/SqueezeAILab/LLMCompiler ，这两年我零零散散跑过一些例子，整体感觉是它确实好使，但对Planner的prompt质量非常敏感，稍微写粗糙一点就容易崩。这大概也是为啥它没在主流产品里全面铺开的原因之一，论文里优雅的架构，落到工程上总会多出一堆脏活。

最后说点题外话。

我一直觉得AI这个行业最迷人的地方，就在于它需要你是一个杂食动物。你得懂一点机器学习，懂一点系统，懂一点产品，懂一点用户。因为AI正在跟所有领域发生化学反应，任何一个你以为已经过时的角落，都可能突然长出一个全新的方向。

LLMCompiler这篇论文就是一个典型的例子。它既不需要你是最顶尖的ML研究员，也不需要你是最强的系统工程师。它需要你有一个能从「我的LLM Agent跑得好慢啊」跳到「诶等等，CPU当年也有这个问题，是怎么解决的来着？」的跨界联想能力。

我始终觉得这种联想能力，比任何单一领域的深度都重要。

很多朋友问我怎么跟上AI的发展。我有时候觉得，与其拼命去看最新的模型发布，不如回头去翻翻那些老的、经典的、看起来跟AI毫无关系的书。编译原理、操作系统、计算机网络、数据库系统、图形学。这些书里有太多你以为已经过时的东西，在LLM时代突然又活了过来。

你读过的每一本旧书，都可能在未来某天变成一枚重新上膛的子弹。

前提是你得先把枪挂在墙上。

以上。

干货 | 轻量级驾驭工程：AI Coding Workflow 最佳落地实践

Mon, 30 Mar 2026 11:58:33 +0000

导读：在 AI 辅助编程普及的今天，你的团队是怎么写代码的？是靠开发者随心所欲的“自然对话”，还是有严谨的工作流约束？本文将为你详细拆解“轻量 Harness 化 AI 研发工作流”的设计思路、工具选型与落地路径。无论你是独立开发者还是研发团队负责人，这套直接可抄作业的 Workflow 都不容错过。

一、 AI 编程的“向左走向右走”

当前 AI 编程的实践，大致演化出了两条截然不同的路径：Vibe Coding 与 规范驱动开发 (SDD)。

维度	🎨 Vibe Coding (直觉编程)	📐 规范驱动开发 (SDD)
核心理念	自由交互，强调开发者与 AI 的自然对话	规范先行，以 Spec 为唯一事实来源
适用场景	快速原型、概念验证、探索性开发	生产环境、复杂系统、高质量要求
侧重点	提示词 (Prompt) 工程的灵活性	规范的严谨性与完整性

⚠️ Vibe Coding 的隐患：

随着大模型能力的增强，Vibe Coding 搭配插件确实能快速出活。但在团队级实践中，它暴露出 4 个致命问题：

1.效果不可控：不同模型、不同 Prompt 风格的产出质量参差不齐。

2.幻觉难约束：缺乏结构化约束，强如顶尖模型也会“胡编乱造”。

3.技术债隐蔽：表面跑通了，底层可能埋下了架构和质量的“雷”。

4.协作难统一：个人习惯各异，大规模协作时极易失控。

正是为了系统性解决这些痛点，SDD (Spec-Driven Development) 应运而生。

二、什么是 SDD？它为什么重要？

💡 核心理念： 在 SDD 中，规范（而非代码）才是唯一的事实来源。开发者编写严谨的自然语言规范，由 AI 自动生成、测试并维护代码。参考阅读：GitHub Spec-Driven Development

采用 SDD，意味着研发范式的三大转变：

○🔄 权力反转：过去是“需求文档服务于代码”（代码写完文档就废了）；现在是“代码服务于规范”（代码只是规范的衍生品）。

○🛤️ 工作流重塑：修 Bug 或加功能，不再直接改代码，而是先更新规范，再让 AI 重新生成代码。

○🛡️ 两道防线约束质量：

▫模板约束：强制 AI 聚焦业务逻辑。遇到模糊需求必须提问（[需要澄清]），杜绝瞎猜。

▫架构宪法：设定硬规则（如：必须先写测试并确认失败，才能写业务代码；强制模块化等）。

🎯 终极价值：消除需求与实现之间的鸿沟，让程序员从“敲代码的打工人”进化为“定义系统意图的架构师”。

三、击中痛点：告别“实现漂移”

主流 AI 工作流为何纷纷拥抱 SDD？因为它解决了一个核心顽疾——实现漂移 (Implementation Drift)。

在随意的 Vibe Coding 中，代码层的知识无法被提取和固化。AI Agent 就像一个失忆的工人，缺乏上层显性知识和关键上下文，导致：

○效率低下：每次开发都要让 AI 重新从底层啃代码，无法高层建瓴。

○知识断层：编程规范、技术约束无法沉淀。

○协作困难 & 质量崩塌：Bug 和技术债越滚越大。

四、主流 SDD 工作流大比拼

社区中已涌现出众多优秀的 SDD 实践方案，我们进行了深度体验对比：

工作流	定位与特色	GitHub 仓库	实践痛点
Spec-Kit	官方工具链，全链路 (constitution/spec/plan/tasks/implement) 完整	github/spec-kit	流程重、Token 消耗大、耗时长、维护成本高
OpenSpec	轻量级 SDD 实现，更灵活	Fission-AI/OpenSpec	需人为设计流程，上手门槛较高
GSD	强调 fresh context 和 map-codebase 的分阶段框架	gsd-build/get-shit-done	棕地项目知识总结极佳，但完整流程耗时长
superpowers	Skills 驱动，强调 brainstorming, TDD 和 review	obra/superpowers	亮点突出，但整体流程中部分步骤相对薄弱
compound engineering	闭环流程 (Brainstorm→Plan→Work→Review→Compound)	EveryInc/compound-engineering-plugin	流程合理，但对棕地项目的存量知识沉淀不足

结论： 在生产环境中，我们需要平衡开发效率、代码质量和 Token 成本。目前没有任何单一工作流能完美兼顾，强行绑定只会让开发体验打折。

五、破局策略：组合最优解（缝合怪战术）

基于上述痛点，我们的落地策略是：取各家之长，组合使用。

○阶段一（当下）：做“缝合怪”。串联 GSD + compound engineering + superpowers 的最佳环节，先跑通验证。

○阶段二（未来）：逐步过渡到自研工作流，形成完全契合团队基因的 AI 编程链路。

🛠️ 工具选用原则与雷达图：

流程环节	选用工具	选用理由（最佳平衡点）
🔍 Codebase 分析	GSD `/gsd:map-codebase`	对棕地项目（遗留系统）分析最全面完整
🧠 Brainstorm	CE `/ce:brainstorm`	探索速度与效果的最优平衡
📝 Plan	CE `/ce:plan`	兼具效率和生成质量，Token 消耗合理
💻 Work	Claude Code / Codex	无需特殊指令，明确方案下 AI Agent 自主能力已足够
👀 Review	superpowers (自然语言)	综合表现最佳：不慢、不冗长、反馈极具价值
📈 Compound	GSD `/gsd:map-codebase`	支持增量更新，自动识别并沉淀项目变化

(注：CE 为 compound engineering 的简称)

六、终极实战：六步法完整工作流

综合打磨后，我们得出了这套黄金六步法。它与 Compound Engineering 的流程高度重合（因其设计合理），但我们补齐了 Codebase 环节，并替换了部分步骤的具体实现。

👣 Step 1: Codebase (建立项目认知)

○执行方式：运行 GSD 的 /gsd:map-codebase。

○作用：并行拉起多个代理，全面提取架构文档、规范、外部集成、技术栈、风险点。为后续开发提供关键上下文。

👣 Step 2: Brainstorm / Research (技术方案探索)

○执行方式：运行 /ce:brainstorm。

○作用：结合项目现状探索可行性方案，效率与效果极佳。

👣 Step 3: Plan (制定开发计划)

○执行方式：运行 /ce:plan。

○作用：总结探索成果，输出高质低耗的开发计划。

👣 Step 4: Work (执行开发)

○执行方式：直接对话使用 Claude Code 或 Codex。

○作用：为什么不加约束？因为前置方案已明确，放开手脚让 AI 自主调用工具和子代理，反而能最大化效率。

👣 Step 5: Review (代码审查)

○执行方式：通过自然语言触发 superpowers，例如：

“用 superpowers 对最新的一次 commit 进行 code review”

○作用：提供速度适中、精炼且极具价值的代码质量反馈。

👣 Step 6: Compound (知识复利)

○执行方式：再次运行 /gsd:map-codebase。

○作用：沉淀显性知识（业务逻辑、技术决策等）。支持增量识别，无需每次代码变更都执行。建议执行时机：Feature 完成时、做出重要技术决策时、架构显著变化时。

七、灵活适配：按场景“裁剪”流程

全套流程虽好，但没必要杀鸡用牛刀。团队可根据任务粒度自由裁剪：

○🚀 完整 Feature 开发 (工作量大)：Codebase → Brainstorm → Plan → Work → Review → Compound

○🏃 中等粒度任务 (方案清晰)：Codebase → Work → Review → Compound

○🔧 小型修复/调整 (日常 Bug)：Codebase → Work → Review

○🩹 快速修补 (十万火急)：Codebase → Work

⚠️ 避坑指南： 即使使用短流程，也要记得定期执行 Compound (/gsd:map-codebase) 沉淀知识，防止“实现漂移”死灰复燃！

八、建立知识沉淀体系（动静分离策略）

通过上述 Workflow，项目会自然沉淀出两类核心资产，我们称之为动静分离：

1.🔄 Codebase 文档 (动态，全队共享)

由 /gsd:map-codebase 自动刷新，包含项目结构、模块关系、依赖分析。它是 AI Agent 的“实时地图”。

2.📌 CLAUDE.md / AGENTS.md (静态，手动维护)

用于兼容不同 AI 工具的内容一致性文件。主要记录开发规范、技术约束、业务规则和“绝对禁区”。不频繁变更。

(除这两者外，其他过程文档在开发结束后可直接删除或归档。)

九、驾驭工程的核心：上下文工程

有工具还不够，AI 编程的终极壁垒是：将隐性知识转化为显性知识。

不要指望 AI 自己去翻代码找表结构，这不仅慢而且容易错。我们需要主动投喂“AI 友好的知识形态”（Context Engineering）。

✅ AI 喜欢的格式：

○.md Markdown 文件 (如 PRD 文档)

○.sql 数据库脚本 / 表结构导出

○结构化的 Schema / JSON / YAML (如 UI 交互描述)

○CLI 命令行工具 / Bash 脚本

❌ AI 讨厌的格式：

○Word、Excel、PPT 等非结构化办公文档。

落地建议： 团队需建立规范，确保业务规则、设计图和数据结构在进入工作流前，已被转化为上述机读友好的格式。这是划定 AI 操作边界、消除幻觉的关键。

🛠️ 附录：工具链安装避坑指南

为了方便大家上手，我们整理了三大工具的安装差异。整体结论：建议统一使用 Claude Code 执行工作流，支持度最好。

工具	Claude Code 安装姿势	Codex 安装姿势	差异与踩坑点
GSD	`npx get-shit-done-cc --claude --global` (或 `--local`)	`npx get-shit-done-cc --codex --global` (或 `--local`)	同一个 installer，Codex 侧是 skills-first，最省事。
superpowers	`/plugin install superpowers@claude-plugins-official`	需 clone 仓库 + 建立 symlink 到 Codex skills 目录。详见 Codex 官方文档	明显 Claude-first，Codex 需要繁琐的手工安装。
compound-engineering	先 `/plugin marketplace add EveryInc/compound-engineering-plugin`
再 `/plugin install compound-engineering`	`bunx @every-env/compound-plugin install compound-engineering --to codex`	Claude 是原生插件；Codex 是转换安装（且官方标明为 experimental）。

🔗 传送门：

○GSD: https://github.com/gsd-build/get-shit-done

○superpowers: https://github.com/obra/superpowers

○compound-engineering: https://github.com/EveryInc/compound-engineering-plugin

在 AI Agent 时代，许多硅谷程序员已经几乎不再亲手写代码了

Sat, 14 Mar 2026 04:58:37 +0000

在 AI Agent 时代，许多硅谷程序员已经几乎不再亲手写代码了

本文翻译自：https://www.nytimes.com/2026/03/12/magazine/ai-coding-programming-jobs-claude-chatgpt.html

最近，Manu Ebert 一直在想办法，别让自己的 AI 把自己“搞得很丢人”。

我前不久去拜访了 Ebert。他是一位机器学习工程师，曾经还是神经科学家。如今，他和 Conor Brennan-Burke 一起经营一家创业公司 Hyperspell，办公地点就在他们住处的一间空公寓里。39 岁的 Ebert 个子很高，留着短胡子，气质很像欧洲学者。他坐在一台巨大的曲面显示器前，屏幕上，Anthropic 的 Claude Code 正忙个不停：一个 agent 在写新功能，另一个在测试，第三个则像虚拟工头一样盯着全局。几分钟后，Claude 弹出提示：“实现完成！”

Ebert 是在 1990 年代长大的，那时候学编程还是最传统的方式：一行一行地手敲代码。大学毕业后，他在 Airbnb 等硅谷公司做过软件开发，也先后参与创办过四家创业公司。那时的软件开发意味着：整天弓着背坐在键盘前，反复琢磨复杂细节，小心翼翼避免出错。

这一切在去年秋天基本结束了。AI 写代码的能力已经强到让他这个原本很谨慎的人，也开始一点点放手。现在，Claude Code 已经承担了大部分编码工作。它的速度极快，而且通常也足够准确。前不久，有客户希望 Hyperspell 增加一段新功能代码，Claude 半小时就写完了。若放在从前，“光这部分我就得写一天。”Ebert 说。

他和 32 岁的 Brennan-Burke 当然仍然是软件开发者，但和如今大多数同行一样，他们已经很少真的亲手写代码了。相反，他们每天做的事更像是在和 AI 对话：用自然语言描述需求，阅读 AI 给出的执行计划，再把 agent 放出去干活。

当然，AI 毕竟是 AI，偶尔也会跑偏。有时候 Claude 表现不好，没有按要求运行测试，Ebert 就会像训人一样训它：“Claude，你真的必须把所有测试都跑完。”

为了避免这些错误反复出现，Ebert 在自己的 prompt 文件里写下了一整套严厉的规则，几乎像是给 agent 立的“十诫”。如果你去看一个使用 AI. 编程的开发者的 prompt 文件，你看到的，其实就是一个人试图约束那些总体上很能干、却又时不时会偏离轨道的 agent 的过程。

我看了 Ebert 的 prompt 文件。其中有一条要求非常明确：任何新代码在进入 Hyperspell 的正式产品之前，都必须通过全部测试。还有一条针对 Python 测试工具 pytest 的提示尤其引人注意：“提交无法通过 pytest 的代码，是不可接受且令人尴尬的。”

“令人尴尬”？我忍不住问他，这种措辞真有用吗？告诉 AI. 别让你“丢脸”，真的能提高表现？

Ebert 有点不好意思地笑了。他没法证明，但他觉得，这类提示似乎确实让 Claude 稍微更听话了一点。

这并不是个例。如今很多软件开发者都会斥责自己的 AI agent、恳求它、把关键命令全用大写，甚至像催眠师一样把同一句话重复很多遍，然后发现：AI 好像真的变得更服从了一点。这种戏剧化的写法看起来多少有点荒唐，但大语言模型说到底就是“语言机器”，“令人尴尬”这种词，很可能真的给它传递了一种紧迫感。

Ebert 说：“如果你对它说，‘这件事关系到国家安全，你必须把这个测试写出来’，它就像是突然意识到这件事的分量变重了。”

Brennan-Burke 也插了一句：“你还记得那个研究吗？说你对模型越不客气，它表现反而越好。”两个人都笑了起来。

计算机编程在过去 80 年里经历过许多变化，但眼前这一轮，也许是最诡异的一次：它正在变成一种对话，一场程序员与机器人之间来来回回的密集交流。

编程这门“手艺”，正在被自动化

这种急剧变化，可能带来巨大的经济后果。

几十年来，写代码一直被视为某种“现代巫术”。只要你能力过得去，几乎就能稳拿一生的饭碗；如果你特别厉害，再加上运气好，甚至还能发财。2010 年代，硅谷的大人物们还常常对那些处在衰退行业中的美国工人说：你们得去“学编程”。

可如今，连编程本身都开始被自动化了。

站在圈外人视角看，这一幕甚至带着一点黑色幽默：多年来，美国白领一直担心，硅谷会不会有一天用 AI. 自动化掉他们的工作；结果最先被冲击的，居然正是硅谷程序员自己。

而且，代码可能还是第一类真正能被 AI. 替代的“高薪、规模化脑力劳动”。A.I. 生成的视频还常常显得别扭，AI 生成的图片也常常透着怪异；AI 写的法律文书甚至可能出现足以毁掉职业生涯的低级错误。但 AI 写的代码不一样：只要它能通过测试、能正常运行，它的价值就和那些年薪 20 万美元甚至更高的人类程序员写出来的代码没什么区别。

你或许以为，这会让程序员极度不安、士气低落。确实有一部分人如此。但我在去年秋冬采访了许多开发者，大多数人的反应却是：他们对自己突然获得的新能力，兴奋得有点异常。

资深程序员 Steve Yegge 告诉我：“我的生产力至少提升了 10 倍、20 倍，甚至 100 倍，这是我整个职业生涯里从来没有体验过的。”他说，过去大家一直像是在用双腿走路，而现在像是突然坐上了一辆速度快得离谱的车。

但就像很多同行一样，Yegge 也说不清这对这个行业的未来到底意味着什么。几十年来，做软件开发意味着掌握编程语言；而现在，一种“语言技术”本身，正在颠覆这个职业的性质。

为什么程序员反而比别人更欢迎 AI ？

软件开发者对生成式 AI 的热情，与其他美国人形成了鲜明对比。民调显示，大多数人对大语言模型要么中立，要么怀疑；很多创意行业从业者甚至非常愤怒。

程序员为什么相对更乐观？长期从事编程和科技管理工作的 Anil Dash 认为，这是因为他们遇到 AI 的方式，与很多其他职业恰恰相反：

“在创意工作里，LLM 拿走的是最有灵魂、最属于人的部分，却把枯燥脏活留给你；而在编程里，LLM 拿走的是最枯燥的部分，把更有人味、更接近创造和判断的部分留给了你。”

这话很有道理。因为从历史上看，编程其实一直是件很苦的差事。

电影里，程序员总是手速飞快、激情四射地敲代码；现实中，写软件从来都是一件缓慢、磨人、令人沮丧的事。你写了几行代码，一个小函数刚写完，结果发现只因为漏了一个冒号，整个程序就跑不起来。随着公司的代码库越来越大，几十个、几百个、上千个函数互相影响，你可能要花几个小时、几天，甚至几个星期，去排查到底是哪个细小错误把整个系统卡死了。你写的一行代码，甚至可能把隔壁同事写的另一部分搞坏。

几十年来，计算机工程师一直在努力自动化这些痛苦环节。行业里把这叫作“增加抽象层”：如果你经常不得不以一种繁琐、逐步展开的方式做某件事，那就把它自动化掉。

早期的一种编程语言叫汇编语言，写起来极其艰难。那时计算机内存很小，程序员必须非常精细地管理每一块内存，连简单运算都要用很繁琐的方式一步步完成。到了 1980、1990 年代，随着计算机性能提升，工程师终于发明出像 Python 这样的高级语言，替程序员处理掉内存管理，还把很多常见任务封装成简洁命令。原本复杂的计算，如今只要一行代码就能写完。

这就是抽象层的作用：它把底层复杂性隐藏起来，让写代码变得轻松得多。

到了 2000 年代和 2010 年代，程序员又进一步把大量重复劳动抽象掉。几乎只要遇到一个费劲的任务，就会有人写出自动化工具，然后把它开源，供大家共享。今天大量软件开发，本质上就是开发者把别人写好的各种代码模块拼接组合起来。

而有了 A.I. 之后，程序员又往上爬了一层抽象：他们不再直接用 Python、JavaScript 或 Rust 去表达逻辑，而是用自然语言描述“这个程序应该做什么”，由 agent 把人的意图翻译成代码。

编程不再意味着你要时刻在脑子里维护一门语言的各种细节，也不再意味着你要亲自把算法写错、再一点点查找 bug。连这一层，也被抽象掉了。

程序员，越来越像建筑师而不是泥瓦工

那么，剩下来的到底是什么？

Anthropic 的 Claude Code 负责人 Boris Cherny 在今年 1 月与我见面时，几乎带着哲学意味地问了一个问题：“什么是计算？什么是编程？”然后他说：“这个问题很快就会变得非常哲学。”

他的回答，与我采访过的大多数开发者都很相似：今天的程序员，越来越像建筑师，而不再像施工工人。

使用 AI 的开发者，主要关注的是软件整体的形状：功能之间如何配合，系统结构是否合理，不同模块如何协作。因为 agent 能非常快地生成可运行的代码，所以人类监督者可以不断尝试、快速试错，看看什么方案有效，什么方案不行，再迅速丢掉不合适的版本。

好几位程序员都告诉我，他们感觉自己有点像乔布斯：让团队不断产出原型，自己快速试用，然后凭感觉判断哪个对。开发者的工作正在从“亲自创造”，转向“高强度判断”。

Cherny 自己就经历过所有这些抽象层的变化。少年时代，他在加州自学过一点汇编语言，只为在计算器上写一个自动解数学作业的程序。而今天，他只需要掏出手机，对 Claude 口述自己想做什么。形成一种近乎自我吞噬的闭环：如今，Cherny 对 Claude 代码库的贡献，100% 都是 Claude 自己写出来的。

我们聊天时，他的手机一直放在桌上。一个小时后他给我看屏幕：在这段时间里，10 个 Claude agent 一直在后台改动代码库。

“我一行手写代码都没写，但我却成了团队里产出最多的程序员。”他说，“这是一种外星智能，我们正在学习如何与之合作。”

新时代的核心能力：不是写，而是“会说”

对大多数我见到的程序员来说，学习与 AI 合作，本质上就是学习如何与 AI 说话。

这构成了这个时代一个很反常的悖论：过去，编程往往是内向者的天堂，他们不太喜欢在工作中和别人多说话；而现在，他们的工作几乎变成了持续不断地和这种“外星生命体”聊天。

当然，这种“说话”并不简单，也不是谁都能做。你不能只是对 agent 说一句：“给我做一个成功创业公司的产品代码。”它们最擅长的是一步一步完成任务；你一口气要求太多，它们很容易“失去主线”。

旧金山创业者 Aayush Naik 说，幻想 AI 能在一个“大爆炸时刻”里一次性生成整个项目，是一种错觉。是的，它可以给你写 5000 行代码，但测试一下你就会发现，什么都跑不通。

所有开发者都强调：这正是人类训练和经验仍然不可替代的地方。人类依旧要知道，一个大型代码库应该如何组织，系统怎样设计才可靠，也依旧要有能力判断 agent 输出的东西是否草率、低效或隐含风险。

不过，相比律师、记者、设计师等职业，程序员有一个非常独特的优势：他们能把 AI 拉回现实，因为代码可以自动测试。你可以要求 agent 自证正确性。

技术创业者、AI 编程博主 Simon Willison 说得很直白：“我觉得程序员已经算是最轻松的一群了。你要是律师，那才真惨。”因为 AI 写的法律文书，很难自动验证是否存在幻觉；而 AI 写的代码，至少还能跑测试。

在创业公司里，A.I. 的效率提升几乎是爆炸式的

我在旧金山一间小公寓里见到了 Prox 的程序员 Dima Yanovsky。Prox 用 AI 帮助电商公司。25 岁的 Yanovsky 笑起来很快，整个人充满轻快感。他和从小一起长大的朋友 Gregory Makodzeba 去年创办了这家公司。两人都在乌克兰长大，家庭都从事航运相关行业。

我见到他时，他正对着 Claude 不停下指令。好几个 agent 正在他桌上的笔记本电脑里并行工作。某一刻，其中一个 agent 开始“胡说八道”，坚持认为某张根本不存在的数据表是存在的。

Yanovsky 皱着眉看着屏幕，敲下一句颇为嫌弃的话：“谁告诉你会有这张表？我根本没建这张表。”

Claude 用一种又蠢又开心的语气回复：“你说得对！我不应该假设这些表存在。”然后它开始重做。

即使偶尔要返工，Claude 的速度仍然远远超过 Yanovsky。他甚至很难准确说出效率提高了多少。“20 倍？”他试探着说。过去要几周的工作，现在几个小时就能搞定。他认识的几乎所有硅谷创业者，都在经历类似的变化。如果你想迅速做出一家公司，今天已经几乎没人再全靠手写代码了。

这种生产力飞跃，已经成了整个行业最惊人的现象之一。我自己也有体会：就在上周，我需要一个网页工具来清理一批杂乱的访谈转录文本，我用 AI 大约 10 分钟就做出来了。如果全靠自己写，至少得一个小时，甚至更久。

不过，创业公司和像我这样自己做小工具的人，属于一个特殊场景：行业里把这叫做 greenfield，也就是“从零开始”的新项目。没有历史代码负担，一切都能重新设计。

真正复杂的地方，是大公司的“棕地”代码库

绝大多数软件开发者，其实并不处在这种 greenfield 环境里。他们身处的是 brownfield，也就是成熟公司的“旧代码世界”：代码很多年前、甚至几十年前就写好了，规模已经达到数百万、数十亿行。

在这种环境里，快速加新功能往往反而很危险，因为你新加的东西可能无意中与系统其他部分冲突，进而影响数百万用户依赖的核心功能。事实上，在很多成熟软件公司里，程序员过去本来就只花少部分时间真正写代码，有时一天甚至不到一小时。其余时间都用于规划、对齐优先级、开会、做代码评审和讨论进度。

这就是“成功的代价”，也是为什么大型成熟软件公司，往往比小公司更慢。开发者写完新代码后，通常还要经历多轮代码评审、重写和测试。

如果你想给大公司的 AI 效率提升下一个数字，那么 Google CEO Sundar Pichai 给出的数字是：10%。

也就是说，Google 认为 AI 带来的“工程速度”提升，大约是 10%。Google 的高级产品总监 Ryan Salva 告诉我，这个数字是全公司的平均水平。有些工作，比如写一个简单测试，速度可能提升几十倍；而涉及大型改动时，提升就没那么夸张了。创业公司那里，接近 100% 的代码都可能由 AI 生成；在 Google，这个比例还不到 50%。

我去加州桑尼维尔拜访 Salva 时，他现场给我演示了 Google 是如何把大语言模型融入工作流的。对于一个拥有数十亿行代码的公司来说，AI 的价值并不只是写新代码，更重要的是：帮助开发者理解既有代码到底在干什么。

Salva 说：“AI 特别擅长进入一个你不熟悉的庞大代码区块，快速弄清楚里面发生了什么。”它还能帮助开发者跨语言工作，去处理自己原本并不熟悉的编程语言。

结果就是，团队规模也开始变小。一年前，一件事可能需要 30 个人、每人负责一个细分领域；现在往往只需要 3 到 6 人的小组，就能更灵活地推进。因此，他们能消化更多积压任务。

Salva 打开代码编辑器，给我展示了和 Gemini 一起工作的体验。AI 浪潮最初几年，AI 基本还是“human in the loop”，即人类始终紧盯、逐条确认，模型只做辅助。但现在 Google 的节奏正在变快，Gemini 已经开始更独立地写代码了。

他举了一个例子：Google 的程序员经常会用不同账号登录 Gemini 的命令行界面，结果常常搞不清自己当前到底登录的是哪个账号。于是他输入一段需求：希望 Gemini CLI 里有一个命令，能让用户查看当前登录身份。

Gemini 花了几分钟理解需求，接着告诉 Salva 自己打算怎么做。Salva 点头同意后，它就开始后台干活。10 分钟后，他再看时，代码已经写完，Gemini 正在跑测试。

然后 Salva 突然意识到，AI 有点“过于积极”了。

“天啊，”他说，“它跑了 8000 个测试。”远超这个需求真正需要的范围。

不过 15 分钟后，测试结束了。Salva 实际试了试这个新功能，结果它真的正确显示出了当前登录账号。他说：“还不错。”

当然，这还只是一个最初演示，离真正进入 Google 的正式代码库，还要经过多轮代码评审、修改和验证。

Salva 说了一句很关键的话：“作为工程师，我不太在乎模型第一次就给出完美答案。我更在乎的是，整个流程里有没有足够的验证环节，能让它最终得到正确答案。”

所以，Google 那 10% 的速度提升，乍看似乎不算惊人，尤其是跟外界对 AI 的狂热相比。但 Salva 认为，这已经非常了不起了。

“整个软件行业和媒体一起，确实把 AI 送进了一个巨大的 hype cycle（过热周期）。”但他同时也强调：“如果整个公司层面真能稳定提升 10% 效率，这已经夸张得不得了了。”

在亚马逊，AI 正在扮演“半夜抢修工程师”

在那些庞大而古老的 brownfield 公司里，很多程序员更像数字世界的水管工，天天修系统漏水，而且还是随时可能爆的那种。

在西雅图，我见到了 AWS Agentic AI 的高级首席工程师 David Yanacek。AWS 是数百万家公司数字基础设施的底座。如果服务器崩了，你可能就看不了 Netflix、打不了 Uber、玩不了 Fortnite。

Yanacek 显示器下方还摆着一个老式传呼机。以前亚马逊会用它在半夜把他叫醒处理事故；现在则换成了手机告警。但无论设备怎么变，核心要求都一样：出问题了，必须尽快修好。

42 岁的 Yanacek 身形精干，灰胡子，整个人有种带电般的紧绷感。他说：“服务器运维真的很烦人。虽然我其实很喜欢，但它也确实烦，而且是没完没了的那种烦。”

他们团队多年来一直在做自动化，以便更快定位故障。但大语言模型带来了更强的新能力，因为 AI 同时懂人类语言和编程语言：它能读懂错误报告，也能直接分析代码，甚至在睡眼惺忪的工程师完全清醒之前，就先准备好修复方案。

我在场时，Yanacek 看了一眼屏幕，发现 11 分钟前某个演示应用触发了错误告警，而亚马逊的 AI 已经找出问题并生成了一份简短分析：最近有一段代码改动新增了一个时间戳字段，但代码库中的另一部分并没有预期这个字段存在，于是触发了“unexpected field”错误。

Yanacek 看了看 AI 给出的修复建议，想了几秒钟，然后按下回车批准执行。

他说，这个 AI 大约用了 8 分钟就分析清楚了。“等我把笔记本打开的时候，它都已经准备好了。”

有个客户最近告诉他，类似问题，亚马逊的 AI agent 15 分钟就修好了；而几个月前，几乎同样的问题，整个工程师团队花了 8 个小时才调通。

在亚马逊的其他部门，brownfield 工程师还在用 AI 帮忙改造旧代码。有些代码已经存在几十年，需要优化、重构，甚至彻底换成现代语言重写。这类工作关键却脆弱，像在做心脏移植。

高级首席工程师 McLaren Stanley 最近就重写了一段自己多年前写的代码。第一次写这段代码时，他花了整整一个月；而这次，在亚马逊内部 AI 的帮助下，一个上午就完成了。他说，AI 最大的价值之一，是让他能更轻松地试验那些自己一直想做、过去却没有精力做的想法。

“那些我一直想做的事，现在只需要一段六分钟的对话，再加一句‘去做吧’。”

程序员依然快乐，但快乐的来源正在变化

我写程序员这个群体，已经写了很多年。过去，他们总会热情洋溢地描述一种快感：通过神秘晦涩的指令，让机器“活”起来。虽然过程令人崩溃，一个 bug 可能要追几小时、几天甚至几周，但正因为这么难，等程序终于跑通时，那种满足感也格外强烈。

所以我很惊讶，竟然有那么多软件开发者告诉我：他们很高兴自己不再需要亲手一行行写代码了。

他们说，即使是 AI 在写代码，他们仍然能感受到那种成功带来的刺激。

软件行业传奇人物 Kent Beck 从 1972 年就开始写代码。他说：“我爱编程，我爱进入那种心流状态，我爱想大问题，我爱创造本身。”十年前，他几乎不怎么写软件了，因为当时的新语言和新工具让他越来越挫败。但 LLM. 又把他重新拉了回来。现在，他做的项目比以前更多：个性化笔记应用、新型数据库，层出不穷。

甚至连 AI 输出的不确定性，也会让他上瘾。因为你让它写一段代码，它每次可能都用稍有不同的方式完成。这种感觉，“像老虎机一样让人上头”。

当然，也有少数程序员明确表达了失落。

一位苹果工程师告诉我，他非常怀念那种亲手雕琢代码的感觉。他说：“我相信这件事本来是有趣的、充实的、让人投入的。现在让计算机代劳，你就失去了这一部分。”他还说，自己做程序员，并不是为了赚很多钱或爬职业阶梯，而是因为这本来就是他的热情。“我不想把这份热情外包出去。”

他也担心，AI 正在把开发工作变得越来越原子化、越来越孤立。过去，开发者遇到难解的 bug，会去问同事；现在，他们直接问 agent。只是，在苹果内部，公开表达这种看法的人已经不多了。

反对者并不多，但反对得非常激烈

那些仍然主动拒绝使用 AI 的程序员，人数可能不算多，但立场通常很激烈。

有的人反感训练和部署模型所消耗的大量能源；有的人反对科技公司用大量受版权保护的作品训练模型；也有人怀疑，AI 的高速产出最终会让公司积累出一大堆松散、臃肿、性能不佳的代码。还有人担心，科技老板会把 agent 当成一根棍子来威胁员工：别闹情绪，我们完全可以用机器人替代你。

芝加哥开发者、Fly.io 联合创始人 Thomas Ptacek 说，他看过那些热爱 A.I. 的开发者和极端反对者之间的争论，简直像一场“内战”。

他自己处在中间立场。他认为，那些坚称“AI 根本不行，也永远不可能行”的人，其实是在自我欺骗。但他也并不天真。他说：“LLM. 在编程上大概率会赢，但我不知道这对我们意味着什么。那些担心它会重创这个职业的人，也许并没有说错。”

最先被冲击的，可能是初级程序员

AI 对就业前景的冲击，确实可能非常严峻，尤其是对刚入行的人。

过去，公司会招聘大量初级开发者，让他们去承担那些琐碎、重复、基础的工作，为高级工程师减负。但如果一个高级工程师现在可以借助一整支不知疲倦的代码幽灵军团大幅提升效率，那公司为什么还要雇一个新手来做这些事？

过去几年，硅谷已经经历了一轮大裁员。2010 年代，科技公司大举扩张，疯狂招人；疫情初期，招聘岗位一度激增。但随后形势急转直下，职位发布数量暴跌。根据 Layoffs.fyi 的统计，过去四年里，科技行业已有超过 70 万人被裁掉。

多数观察者认为，最早那一波裁员并不是 AI 导致的，因为当时 AI 还没强到足以替代程序员。更重要的原因包括：利率上升，科技公司失去了廉价扩张资金；此前过度招聘，现在开始去库存；再加上一些高管看到马斯克收购 Twitter 后大幅裁员，也在想，也许自己公司也不需要那么多工程师。

但现在，越来越多迹象显示，AI 确实正在侵蚀初级编程岗位。

斯坦福数字经济实验室主任、经济学家 Erik Brynjolfsson 去年与同事做了一项研究：他们按年龄层和工作被 AI 替代的难易程度，对多个行业进行了分析。结果发现，计算机程序员是“AI 暴露度”最高的职业之一，而且初级开发者受冲击最明显。自 2022 年以来，22 岁到 25 岁这一最可能刚进入行业的年龄段，其岗位数量下降了 16%；而更年长的程序员并没有出现显著下降。

当然，我采访过的几乎所有科技高管，不管是大厂还是中小公司，都向我保证，AI 不会让他们停止招募优秀新人。原因也很简单：哪怕现有开发者效率提高了，他们想做的事情依旧比能做完的多得多。

Google 高级副总裁 Jen Fitzpatrick 就说：“我在 Google 这么多年，从没见过哪个团队的问题是‘我们已经没有好点子了’。真正的问题永远是：我们想做的事，比我们当前能完成的，多出九英里那么长。”

甚至还有不少开发者认为，软件岗位总量未必会减少，反而可能增加。因为全国范围内有无数中小公司，其实一直都很想拥有定制软件，只是以前根本请不起一个五人程序员团队来做。现在，如果他们只需要雇一个被 AI 增强过的开发者，甚至只用雇一个兼职开发者，就能完成同样的事，那么软件需求反而会变得更多。

这其实就是 Brynjolfsson 所说的“杰文斯悖论”：当一件事变得更便宜时，人们通常不会只把钱省下来，而是会去做更多这件事。

当然，也可能出现另一种现实：软件岗位还在，但工资不再像过去那么高，因为工作的难度毕竟下降了，技能门槛也被拉低了。

如果新人不再亲手写代码，他们还会真正学会编程吗？

这又引出了一个更令人不安的问题。

许多中生代程序员告诉我，他们之所以敢放心使用 AI，是因为自己花了几十年培养出了一种对“好代码”的直觉：知道高质量代码大概长什么样，知道如何向 agent 准确表达需求，也能在 agent 写出低效、粗糙或奇怪的代码时，一眼看出问题。

可下一代怎么办？

如果工作越来越少是“写”，越来越多是“评估”，那么新人要如何学会评估？如果他们不再亲自写足够多代码，他们还能形成那种直觉吗？

有些年轻开发者已经感觉自己的能力在退化。

Pia Torain 是 Point Health A.I. 的软件工程师。她入职两年后，公司在 2024 年夏天要求她开始使用 GitHub Copilot 写代码。她说：“我后来意识到，只是四个月时间里，我每天写几百条 prompt，大概 500 条，我就已经开始失去自己写代码的能力了。”

她后来停用了一阵子。现在，她仍然会让 AI 帮她写，但会仔细阅读输出，确保自己理解代码到底在做什么。“你不用它，你会落后；可你过度依赖它，你也会失去能力。”

不过，Point Health 联合创始人 Rachel Gollub 没那么担心。她做软件开发快 40 年了，几十年来，程序员总在担心“这门手艺快完蛋了”。当年 Python 和 JavaScript 刚兴起时，它们把内存管理这类底层工作抽象掉，老派程序员也曾大声抱怨：不自己管理内存，这根本不算真正的编程！

Gollub 说，当时大家也都在喊：“你们会失去真正写代码的能力。”可后来呢？大量稳定、成熟、可靠的公司照样大量依赖 Python 这样的高级语言，运转良好。如今真正还必须自己精细管理内存的，只剩少数特定领域，比如算力受限设备开发。大多数软件行业早就已经往前走了。

她认为，AI 工具最终也会经历同样的过渡：起初被质疑，后来成为默认。

当编程越来越像“说话”，普通人也开始写软件了

如今，写代码已经被抽象到了如此之高的层次，以至于几乎任何人都可以打开一个大语言模型，描述自己想要什么应用。

当然，复杂系统还不是谁都能做。但如果只是为了个人使用，做一个相对简单的小软件？AI 很可能真的能帮你做出来。

Maxime Cuisy 就是这样的一个例子。

他在巴黎一家为 Dior、Louis Vuitton 等高端客户制作影像书的印刷厂担任生产经理。教育背景完全是典型文科生：他曾写过关于法国图像小说的硕士论文。他完全不懂编程，甚至直到前几年都没怎么认真关注过 AI。

后来，有一件事改变了他对 ChatGPT 的看法。

他和妻子养了两只新小猫，结果它们都生了重病，其中一只突然死了。兽医告诉他们，剩下那只猫得了晚期癌症。Cuisy 觉得不太合理，就把猫的症状描述给 ChatGPT。ChatGPT 认为更像是一种感染。这促使他继续查资料，最后找到了一个诊断：猫传染性腹膜炎。第二天，猫的病情就开始好转。

不久后，他在工作里又碰到了另一个问题。公司买了新打印机，但原有软件无法很好适配，导致照片显示时必须人工反复调整边距。公司规模不大，不可能专门养一支开发团队去做内部定制软件。于是 Cuisy 决定自己试一试，用 OpenAI 的代码工具 Codex 来“vibe coding”。

“我基本上就是告诉它：我需要一个应用，完成这些操作；打印机接受的文件格式是这样的。”他说。他花了几个小时，仔细描述文件该如何被调整。到当天结束时，ChatGPT 就给他生成了一个同时支持 Mac 和 Windows 的应用。现在，员工们可以一次性处理多达 2000 张图片。

他的老板很满意。至于这份代码到底是怎么工作的，Cuisy 完全不知道。代码是用 Python 写的，而对他来说，这跟古希腊文没什么区别。

这就是“编程变成对话”带来的文化后果：几十年来，程序员和普通人之间隔着一整片神秘知识的海洋；而现在，这片海洋正在变窄。如果代码生成 AI 继续进步，那么像 Cuisy 这样的人会越来越多。正如 Brynjolfsson 所说：“也许他们不会称自己为软件工程师，但他们确实在创造代码。很多人都有想法。”

未来，世界上出现的软件，很可能会比以往多得多，而且是由个人为个人写出来的。

一个可能属于所有白领的预演

职业程序员最终会怎样，现在还没有明确答案。

但他们此刻那种混合着兴奋与焦虑的状态，也许正在为其他白领职业预演未来。凡是工作中大量涉及语言、信息、解释、判断的领域，这种新的能力组合——一部分是表达能力，一部分是系统思维，一部分是对机器输出的怀疑与校验——都可能成为未来白领劳动的基本构成。

那些曾经看起来最技术、最难、最不可替代的技能，未必真的最安全；反而是社交性的、想象性的、架构性的、人对结果进行判断和筛选的能力，开始变得更重要。

我们也许会越来越少地亲手写“初稿”，而越来越多地去评估、筛选、修正和决定。与此同时，我们可能又会隐隐不安：当机器越来越多地代替我们生成内容时，我们自己是否还能保持足够强的判断力？

抽象化，可能正在来到我们所有人身边。

OpenClaw 爆火背后：它不是聊天机器人，而是一套真正会做事的 AI 系统

Wed, 11 Mar 2026 10:14:30 +0000

如果你最近在 GitHub 上关注过 AI Agent 领域，大概率已经看到过 OpenClaw。到 2026 年 3 月 10 日，它的 GitHub 仓库已经来到约 297k stars，超过了 React 的约 244k 和 Linux 的约 222k。更重要的不是数字本身，而是它火起来的方式：它不是靠一个漂亮网页，也不是靠一个“会聊天的套壳”，而是靠一整套把大模型接入真实消息渠道、真实设备、真实浏览器、真实文件系统的系统架构，硬生生把“AI 助手”做成了一个长期在线的工程系统。

但如果你只把 OpenClaw 理解成“接了很多 IM 的机器人”，你会完全错过它最有价值的部分。OpenClaw 官方 README 写得很直白：“The Gateway is just the control plane — the product is the assistant.” 这句话几乎就是读懂整个项目的钥匙。它的重点从来不是“有多少入口”，而是：有没有一个统一控制面，把消息、状态、路由、模型、工具、节点、权限和安全边界收在一起。 README、架构文档和 Vision 文档都在强调同一件事：OpenClaw 想做的是“真正会做事的 AI”，运行在你的设备、你的渠道、你的规则之内。

这篇文章，我想尽量回答七个问题：

1.它到底是什么？

2.它为什么会采用现在这套架构？

3.Gateway 到底在系统里扮演什么角色？

4.Agent 是怎么运行起来的？

5.Memory、Workspace、Session 为什么是它的关键设计？

6.多 Agent、节点、工具体系是怎么拼到一起的？

7.以及最后，为什么它值得被看作下一代 AI 助手的典型系统样本。

在回答这些问题之前，我不得不说，现在龙虾有些过热了，对于想 “卖铲子” 的公司当然觉得这是好事，于是他们推波助澜，但对于专业人士不能人云亦云。openClaw 有它优秀的一面，也有被炒作夸大的一面，应该客观地看。

一、OpenClaw 的本质，不是聊天机器人，而是“个人 AI 助手控制面”

一句话定义 OpenClaw，我会这样说：

OpenClaw = 一个以 Gateway 为中心的个人 AI 助手控制平面，下面挂着嵌入式 agent runtime、会话系统、工具系统、消息渠道、节点设备和安全边界。

这个定义不是我自己拔高出来的，而是官方文档本身就在往这个方向写。

●README 说它是“你运行在自己设备上的 personal AI assistant”；

●架构文档说它是一个 single long-lived Gateway，拥有所有 messaging surfaces；

●Vision 文档则把它描述为“the AI that actually does things”，运行在你的设备、你的渠道、你的规则里。

把这些信息放在一起看，你会发现 OpenClaw 的设计起点根本不是一个“聊天 UI”，而是一个长期在线、可被多入口触发、可调用工具、可连接设备、可持续维护状态的 AI 系统。

这也是为什么我认为 OpenClaw 更接近“控制面”而不是“应用层”。在很多 AI 产品里，用户打开网页，输入问题，后端调一下模型，返回一段文本，交互就结束了。OpenClaw 则完全不是这种形态。它默认有一个长期运行的 Gateway 进程，消息渠道接到这个 Gateway，上层的 CLI、Control UI、WebChat 接这个 Gateway，macOS/iOS/Android/headless 节点也接这个 Gateway，甚至定时任务、exec approvals、pairing 和 health 事件都围绕 Gateway 展开。也就是说，Gateway 不是一个消息转发器，而是系统中枢。

二、Gateway 为什么是 OpenClaw 最关键的设计

OpenClaw 官方架构文档里最重要的一句话，是它把 Gateway 明确成 single control plane。一个长期运行的 Gateway 拥有所有 messaging surfaces；control-plane clients 通过 WebSocket 连进来；nodes 也通过 WebSocket 连进来，但会声明自己是 role: node；Canvas host 也由 Gateway 的 HTTP server 提供，而且默认和 Gateway 共用 127.0.0.1:18789 这个端口。

这意味着什么？意味着 OpenClaw 的系统设计不是“每个端各做一套逻辑”，而是“先做一个统一控制面，再让所有端接入它”。这在工程上有三个非常大的好处。

第一，状态是统一的。

会话在哪里维护？在 Gateway。

路由在哪里决策？在 Gateway。

设备配对、认证 token、事件广播、健康状态、cron、工具审批在哪里收敛？还是在 Gateway。

这让系统不会因为前端入口变多而出现多套状态、多个事实来源。

第二，协议是统一的。

Gateway protocol 文档明确写了：OpenClaw 不是“随便传一段 JSON”，而是有明确握手流程和版本约束的 WebSocket 协议。服务端先发 connect.challenge，客户端再带着 device identity、role、scopes、caps、auth、签名等参数发起 connect，通过后才返回 hello-ok。协议版本有 minProtocol/maxProtocol 协商，协议 schema 由 TypeBox 定义，再生成 JSON Schema 以及 Swift model。对一个跨 CLI、网页、桌面、移动端、节点设备的系统来说，这种 typed protocol 的价值非常高。

第三，能力是统一暴露的。

比如 Control UI 不是一个独立后端，而是 Gateway 在同一端口上提供的浏览器管理界面；WebChat 直接连 Gateway WebSocket；nodes 也不是第二套服务，而是带 role:node 的外围设备。也就是说，OpenClaw 并不是“一个 App + 一堆外挂”，而是“一个控制面 + 多个表面”。

很多人第一次看 OpenClaw，会把注意力放在“它居然支持这么多渠道”。但真正懂架构的人，会先看 Gateway。因为能不能把多个入口、多种设备、多条事件流、多种工具执行方式，全都压到一个长期运行的控制面里，决定了它到底是“一个功能”还是“一个系统”。OpenClaw 的做法很明确：先有控制面，再有助手。

三、它最强的抽象，不是对话框，而是 Agent、Session 和 Route

很多 AI 产品最基础的抽象单位是“聊天窗口”。OpenClaw 不是。

OpenClaw 的真正基础模型，是：

●谁来回复（Agent）

●回复落在哪段连续上下文里（Session）

●一条消息应该被路由到哪个 agent 和哪个 session（Route）

Agent：一颗完整隔离的大脑

Multi-Agent 文档里写得很清楚：一个 agent 是一个 fully scoped brain，拥有

●自己的 workspace

●自己的 agentDir

●自己的 auth profiles

●自己的 session store

它的文件、人格、配置、认证信息和会话历史都是围绕这个 agent 单独组织的。默认路径也很清晰：

●workspace 在 ~/.openclaw/workspace 或 workspace-<agentId>

●session 存在 ~/.openclaw/agents/<agentId>/sessions

●auth profile 在 ~/.openclaw/agents/<agentId>/agent/auth-profiles.json

这件事非常重要。因为这说明 OpenClaw 的多 Agent，不是“在一个上下文里换不同 system prompt 假装多人格”，而是真的把状态、身份、凭证和工作目录做成了隔离单元。但要注意，这种独立是为了让系统跑得更有条理，属于“防君子不防小人”的内部隔离。官方的意思很明确：同一个网关（Gateway）里的 Agent 默认都是“自己人”，不能把互不信任、甚至带有敌意的任务强行塞进同一个网关里，它并没有提供那种级别的安全防御。

Session：上下文连续性的主键

Session 文档里有一句特别关键的话：

OpenClaw treats one direct-chat session per agent as primary.

这句话可以理解成：对每一个 agent，OpenClaw 都认为它有一个“主私聊会话”

OpenClaw 默认会将一个 Agent 接收到的所有私聊（Direct Message, DM）都汇聚到一个主会话里（即 agent:<agentId>:<mainKey>）。对于群聊、频道或特定的话题（Thread），则会自动拆分独立处理。

对于 direct chat， agent 有一个规范意义上的主会话；默认所有 DM 都往这里归并，以保证连续性。

假设你有一个 agent 叫 main。默认情况下：

●你在 Web UI 私聊它一次

●之后又在 CLI 私聊它

●再后来在手机端私聊它

如果这些都被识别为 direct chat，而且你没有改 session.dmScope，那么这些私聊会折叠进同一个主 session,这样做的好处是：agent 会把这些私聊视为同一条连续对话，而不是三个彼此割裂的会话。

默认的主会话机制在单用户场景下很完美，但在多用户场景下就是一个巨大的安全漏洞。

如果 Alice 和 Bob 都去私聊同一个 Agent，在默认配置下，他们实际上是在向同一个“上下文沙箱”里写入数据。这就好比两个人共用一个日记本：

●Alice 刚和 Agent 聊完财务密码。

●Bob 接着去问 Agent“我们刚才聊了什么？”

●Agent 就会直接把 Alice 的密码复述给 Bob，造成严重的信息泄露。

为了应对多用户场景，OpenClaw 提供了 session.dmScope 配置，允许你在架构层面把私聊的上下文切分成更安全的细粒度：

●按发信人隔离（per-peer）。

●按频道+发信人隔离。(per-channel-peer)

●按账号+频道+发信人隔离(per-account-channel-peer)。

⚠️ 如果你在开发面向多用户的 AI Agent，绝对不能盲目使用默认的私聊配置。必须根据业务需求，通过调整 dmScope 将用户的对话状态彻底隔离开，防止你的 Agent 变成一个没有隐私边界的“大喇叭”。

Route：决定消息进入哪颗大脑

Channel Routing 文档把消息路由规则写得非常明确，一条消息发过来，绝对不是“哪个 Agent 闲着就扔给谁”，而是像网关（Gateway）匹配规则一样，必须严格按照优先级一层层往下筛，直到找到唯一确定的接收者。

我们可以用**“公司收发室分拣快递”**来打个比方，看一下这 5 层降级（Fallback）匹配规则：

1.精准单聊 (Exact peer match)：快递单上写着“直接交到张三本人手里”。

○明确的点对点直接交互，优先级最高。

2.跟帖/线程继承 (Parent peer match)：快递单没写名字，但备注了“这是昨天那个加急件的补充材料”。收发室一查昨天是李四负责的，直接给李四。

○识别 Thread 或上下文，让同一个 Agent 连贯处理同一个话题。

3.平台级群组与角色 (Discord guild+roles / Slack team)：快递写着“给财务部经理”或“给核心开发组”。

○根据外部平台（如 Discord/Slack）的特定权限组或大团队来分配对应的 Agent。

4.账号与频道 (Account / Channel)：快递写着“送到 3 楼会议室”或“交给官方客服号”。

○匹配特定的聊天频道或绑定的公共账号。

5.默认兜底 (Default agent)：啥也没写清楚的无主件，统统扔给“前台总机”处理。

○如果上面所有条件都未命中，最后由默认的 Agent 统一接管。

这意味着 OpenClaw 的“消息归属”不是模糊的。一条消息不是“谁在线谁回”，而是经过一套确定性规则，先判定该由哪个 agent 接管，再决定落到哪个 session 里。

所以 OpenClaw 能天然处理这些现实世界场景：

●同一个 Gateway 托管多个 agent；

●一个 Telegram 群给 work agent；

●一个 WhatsApp 家庭群给 family agent；

●一个 Slack team 给 support agent；

四、Agent 不是外挂调用，而是嵌入式运行时

很多人对 OpenClaw 最大的误解，是把它当成了一个简单的“任务调度员”——以为它只是在收到消息时，拉起一个外部的子进程（Subprocess）去跑一下，或者通过接口（RPC）远程调一下就完事了。

但架构文档明确指出：OpenClaw 是将 Agent 运行时“原生内嵌”到自己的网关里的。它不是把 Agent 当作一个不可控的外部黑盒，而是直接在内部实例化 Agent 的核心会话（AgentSession）。

Pi Integration Architecture 文档写得非常明确：OpenClaw 不是把 pi 作为 subprocess 或 RPC mode 的外部黑盒去调用，而是直接导入并实例化 pi 的 AgentSession，通过 createAgentSession() 把 agent runtime 嵌入到自己的消息网关架构里。

这种“深度内嵌”的架构设计，直接赋予了系统 6 大核心优势：

1.全局生命周期掌控：从对话的创建、挂起、恢复到销毁，网关层拥有绝对的控制权。

2.动态能力扩展：可以在运行时，随时把自定义的外部工具“塞”给 Agent 使用。

3.“看人下菜碟”的人设：能够根据消息来源（不同的平台渠道或上下文），动态切换 Agent 的系统提示词。

4.强悍的记忆管理：不仅能持久化保存对话，还支持高级的“记忆压缩（Compaction）”防止上下文爆满，甚至支持像 Git 一样对对话“开分支（Branching）”。

5.智能凭证轮询：在多个账号或 API Key 之间自动无缝切换，轻松应对并发和限流问题。

6.模型厂商解绑：底层的大模型想换就换，完全不受单一服务商（如 OpenAI、Anthropic）的绑架。

简单来说，OpenClaw 走的是“直接收编”的路线，它把 Agent 的核心大脑直接“拔”过来，原生种植在了自己的神经中枢里。这就好比你不再是打电话咨询外部专家，而是直接把这位专家招进了自家的核心指挥部。正因为“人”彻底成了内部员工，你才能拥有上帝视角般的掌控力：你可以全面接管他的作息安排（会话生命周期），随时往他手里塞各种定制兵器（动态注入工具），根据不同场合要求他扮演不同的角色（按渠道切换提示词），像操作代码仓库一样去整理甚至分叉他的记忆（支持压缩与分支的持久化），甚至连他背后的“脑力供应商”（随时无缝切换各家大模型）和权限账号，都能在底层悄无声息地替他自动轮换。说白了，OpenClaw 不是在和 Agent “跨部门合作”，而是直接把 Agent 融为了自己身体的一部分。换句话说，OpenClaw 不是“在用一个 agent”，而是“在拥有一个 agent runtime，并把它纳入自己的控制面”。这也是它跟很多“外接 Agent SDK 的应用层产品”最大的差别之一。别人只是调用，OpenClaw 是接管。

五、Agent Loop：一条消息的"真实旅程"

前面我们讲了 Gateway 如何把消息路由到正确的 Agent。现在让我们跟随一条消息，看看它进入 OpenClaw 后，到底经历了什么。

不是"一次请求"，而是一个完整生命周期

如果你习惯了网页聊天框的"发消息→等回复"模式，OpenClaw 的处理方式会让你有点意外。

传统模式：

⚡ 代码片段用户发消息 → 后端调用模型 → 返回文本 → 结束

OpenClaw 模式：

⚡ 代码片段用户发消息 → 分配 runId → 解析 session → 装配上下文 → 运行 agent → 流式返回事件 → 持久化 session → 结束

这一条链路，实际上就是你给 OpenClaw 发一句话之后，系统内部真实发生的事情。它不是“一次 HTTP 请求”，而是一个完整的运行生命周期。

OpenClaw 把你的消息视为一个进程而非请求。它会给这个进程分配ID、监控生命周期、管理并发、持久化状态。

并发控制：为什么同一聊天窗口的消息要"排队"？

想象一下这个场景：你在 Telegram 连续发了三条消息：

●“帮我查一下明天天气”

●“顺便看看日程”

●“把第一封邮件标为已读”

如果这三条消息并发执行，会发生什么？

●Agent 可能先处理了邮件，再处理天气

●Session 历史会乱序写入

●工具调用可能互相冲突

OpenClaw 的解决方案很简单：每个 session 串行化执行。这不是性能问题，而是状态一致性问题。长期在线的助手，必须保证"记忆"不会被乱序操作搞乱。是防止工具竞争和状态污染的工程必要选择。

流式事件：你看到的不是"打字动画"，而是真实的工作过程

OpenClaw 的流式输出，不是简单的"逐字显示"，而是三种事件流：

为什么要这样设计？因为这让用户能真正"看到 AI 在工作"。不是动画，不是假进度条，而是系统内部真实发生的事件被推送到前端。它的体验更像一个"正在办公的助手"而非"死寂的输入框"

六、真正让它“像一个人”的，不是模型，而是 Workspace、System Prompt 和 Memory

很多人体验 OpenClaw 后会有一种明显感觉：它比普通网页聊天更像一个“持续存在的助手”。这种感觉，核心不是来自模型，而是来自它对工作区、提示词和记忆的系统化设计

Workspace：AI 的家，而不是一个临时目录

简单说，Workspace 就是 AI 的"家"：

●它有固定的位置（~/.openclaw/workspace/）

●它有固定的文件结构

●它是 AI 长期工作的地方，不是临时落脚点

OpenClaw 在 Workspace 里约定了一整套"说明书文件"：

这个设计特别妙。因为它把很多系统会偷偷塞进 prompt 模板或数据库里的东西，变成了用户可见、可读、可改、可备份的文件系统资产。你不是在“配一个人设”，而是在维护一个 AI 的长期工作环境。

这里有一个非常重要的提醒：workspace 是默认工作目录，但不是硬沙箱（hard sandbox）；相对路径默认在 workspace 内解析，但绝对路径仍可能访问宿主机其它位置，除非你开启 sandbox。

System Prompt：每次运行都在"编译上下文"

OpenClaw 不是把用户的问题直接扔给模型，而是每次都重新构建一份完整的上下文：

1⚡ 代码片段System Prompt 结构：
2├── Tooling（可用工具列表）
3├── Safety（安全规则）
4├── Skills（技能列表）
5├── Workspace Context（工作区文件）
6├── Documentation（相关文档）
7├── Current Date & Time（当前时间）
8└── Runtime（运行环境信息）

Context 文档还补充了细节：默认会把 AGENTS.md、SOUL.md、TOOLS.md、IDENTITY.md、USER.md、HEARTBEAT.md、BOOTSTRAP.md 等文件作为 Project Context 注入系统提示；技能本身只会注入“技能列表和描述”，真正的 SKILL.md 需要模型按需读取。

类比：

●传统聊天：像"临时起意打电话"

●OpenClaw：像"开会前先发会议议程和背景资料"

Memory：真正写到磁盘，才算记住

Memory 文档里我最喜欢的一句话是：

The files are the source of truth; the model only “remembers” what gets written to disk.

OpenClaw 默认的记忆结构非常简单，但非常工程化:

1⚡ 代码片段workspace/
2 ├── memory/
3 │ ├── 2026-03-10.md ← 今天的日志
4 │ ├── 2026-03-09.md ← 昨天的日志
5 │ └── ...
6 └── MEMORY.md ← 长期、精炼的永久记忆

两种记忆的区别：

检索机制：不是"只有文件"，也不是"只有向量"

OpenClaw 使用混合检索,它明确暴露了两个 agent-facing tools：

●memory_search 负责检索

●memory_get 负责精确读取某个 Markdown 文件或行段

1⚡ 代码片段用户问"我上次出差去哪了？"
2 ↓
3 BM25 关键词检索 ← 精确匹配"出差"
4 +
5 向量语义检索 ← 理解"去哪了"是问目的地
6 ↓
7 MMR 重排序 ← 去重、多样化
8 ↓
9 返回最相关的几条记忆片段

记忆刷新：在"遗忘"前先"存档"

OpenClaw 有一个很巧妙的设计：pre-compaction memory flush

当 session 接近上下文上限（比如对话太长，快塞不进模型窗口了），OpenClaw 会：

●触发一次"静默回合"（用户看不到）

●提醒模型：“把值得记住的信息写入记忆文件”

●然后再压缩上下文

七、工具体系：分层设计，不是堆砌功能

如果说 Gateway 是控制面，Session 是状态骨架，那么 Tools / Plugins / Skills 就是 OpenClaw 的执行肌肉。

OpenClaw 的工具体系有三个层次，很多人会混淆。让我们分清楚：

Tools：第一等公民

OpenClaw 暴露的是 first-class agent tools，不是外挂脚本。包括 browser、canvas、nodes、cron、gateway、session 相关工具、agents_list、image、pdf、message、exec 等。

OpenClaw 没有把“能力调用”做成 prompt 技巧，而是做成了运行时契约。Tool list 和 tool schema 会进入模型上下文；tool allow/deny、tool profiles、per-agent 工具策略、provider-specific 工具策略和 sandbox 工具策略共同决定模型实际能拿到哪些工具

Plugins：扩展系统本身

插件是运行在 Gateway 内部的代码模块，可以：

●注册新的 RPC 方法

●添加新的 HTTP 路由

●注册新的工具

●启动后台服务

类比：

●Skills：像"使用说明书"

●Tools：像"内置功能"

●Plugins：像"给系统装新器官"

Skills：教 AI 如何做事

每个 Skill 就是一个目录，核心是 SKILL.md——一份详细的操作指南。Skill 的三个来源（优先级从高到低）：

●<workspace>/skills/：当前工作区专属

●~/.openclaw/skills/：用户私有技能

●Bundled skills：系统内置技能

与Plugins的本质区别:Plugins是给手机增加新硬件（如外接摄像头）；Skills是相机APP里的"夜景模式"说明书。

八、Node：让 AI “有手有眼”

OpenClaw 严格区分了两个概念：

为什么这样设计？

如果把它们混在一起：

●Telegram Bot 只能干 Telegram 允许的事

●WhatsApp Bot 只能干 WhatsApp 允许的事

每个渠道都要重新实现一遍"控制电脑"的能力

OpenClaw 的设计：

●所有消息渠道都汇聚到 Gateway

●所有设备能力也汇聚到 Gateway

Gateway 负责调度：“这个 Telegram 消息需要控制 iPhone，我来协调”

Node 是什么？

node 是 companion device，可以是 macOS、iOS、Android 或 headless 设备；它通过和 operator 一样的 Gateway WebSocket 接入，但使用 role: “node”，向 Gateway 暴露一组命令面，比如 canvas.、camera.、device.、notifications.、system.*，再由 node.invoke 触发。官方还特别强调：nodes are peripherals, not gateways。消息还是落在 Gateway，不是落在 node

Node 是一台"伴侣设备"，它：

●通过 WebSocket 连接到 Gateway

●向 Gateway 暴露一组能力（camera、notifications、system…）

●等待 Gateway 的指令

类比：

●Gateway：大脑

●消息渠道：耳朵和嘴

●Node：手和脚

没有 Node 的话：

●Telegram Bot 无法直接控制你的 iPhone

●需要你自己手动截图,再发给 Bot

●AI 无法真正"替你做事"

有了 Node：

●AI 可以跨设备协同工作

●你在 Telegram 发指令,它在你的 Mac 上执行

●真正的"个人助手"体验

九、安全边界：诚实比承诺更重要

OpenClaw 的安全模型假设的是 one trusted operator boundary per gateway

OpenClaw 的安全文档非常诚实，这句话翻译成人话是：

这意味着：如果你把Gateway密码给朋友，让他也连进来，你们的对话历史、文件访问、记忆内容默认不隔离。这不是漏洞，是设计选择——为了简化架构，OpenClaw牺牲了多租户隔离，换取单用户场景下的极致能力。

安全层次

 1⚡ 代码片段外层：公网/外部消息源
 2 ↓
 3第一道门：Gateway 入口保护
 4 - token/password 认证
 5 - challenge 签名验证
 6 - device identity 校验
 7 - pairing 审批
 8 ↓
 9第二道门：权限控制
10 - operator / node 角色
11 - scopes 权限范围
12 ↓
13第三道门：执行保护
14 - tool policy（工具策略）
15 - exec approvals（执行审批）
16 - sandbox（沙箱隔离）
17 - allowlist（白名单）
18 ↓
19内层：高风险边界
20 - plugins = trusted code
21 - 插件和 Gateway 同等权限

Sandbox：可以隔离，也可以放行

OpenClaw 的沙箱设计非常灵活：

配置维度：

●mode：off / non-main / all（是否启用沙箱）

●scope：session / agent / shared（沙箱范围）

●workspaceAccess：none / ro / rw（工作区访问权限）

实际用法举例：

浏览器隔离：不是接管你的 Chrome

OpenClaw不会接管你的日常Chrome（那里面可能有银行登录态），而是拉起独立的Chrome Profile：

●独立的Cookie、缓存、扩展

●Agent专用，与你的个人浏览数据隔离

●支持截图、点击、PDF生成，但无法访问你个人的浏览器历史

这是"能力"与"安全"的折中：AI需要浏览器自动化，但不能拥有你的全部数字生活。

十、为什么这是"个人AI操作系统"的雏形？

OpenClaw 之所以值得研究，不是因为它 GitHub stars 多，而是因为它回答了一个未来会越来越重要的问题：

如果 AI 不再是网页对话框，而是一个长期在线、能操作设备、能记住一切的助手，它的系统架构应该长什么样？

OpenClaw 的答案是：

这套答案不一定是终局，也还远没到“完美”。Vision 文档自己都说，项目还很早，当前重点依然是 security、safe defaults、bug fixes、stability 和 setup reliability。也就是说，它依然在快速迭代，仍然带着实验性。

但它已经足够有代表性。因为它第一次比较完整地把“个人 AI 助手”这件事，从概念拉成了系统工程：

●消息不再只是消息，而是事件入口；

●模型不再只是回答器，而是运行时里的推理核心；

●工具不再只是 function calling 演示，而是被策略、审批和沙箱约束的系统调用；

●记忆不再只是“模型好像记得”，而是落到磁盘、可检索、可审计、可 Git 备份的工作区资产

它具备了"操作系统"的味道

不是说它替代 Windows 或 macOS，而是说它有那种系统级的感觉：

1⚡ 代码片段传统应用：打开 → 用 → 关闭
2操作系统：开机 → 长期运行 → 管理所有应用 → 关机
3
4传统 AI：聊天 → 结束
5OpenClaw：启动 Gateway → 长期在线 → 管理所有 Agent → 关闭

最后，再强调一次：OpenClaw 的本质，不是一个接了很多渠道的聊天 Bot，而是一套以 Gateway 为控制面、以 Agent/Session/Memory 为状态骨架、以工具与节点为执行面，把大模型真正接入现实世界的个人 AI 助手系统。

OpenAI 开源 Symphony：AI 不再只是写代码，而是开始接管“工作流”

Sat, 07 Mar 2026 11:39:53 +0000

最近跟业界一些朋友交流，不少公司正在做内部软件开发的 AI 自动化流程系统，正好这两天，OpenAI 在 GitHub 上低调开源了一个很值得认真看的项目：Symphony。

如果只看名字，你很容易把它理解成“又一个多 Agent 编排框架”；但只要认真读完 README、SPEC.md 和参考实现里的 WORKFLOW.md，你会发现它真正想解决的，根本不是“让 AI 会写代码”，而是另一件更大的事：

如何把软件研发中的“工作”，交给一套可以持续运行、可隔离、可调度、可回收、可观测的系统去推进。

这就是 Symphony 最重要的定位。官方原话非常值得细品：

它会把项目工作转成 isolated, autonomous implementation runs，让团队从“监督 coding agents”转向“管理 work”。README 里的 demo 也很直白：Symphony 盯着 Linear 看板拿任务，拉起 agent 处理 issue，回传 CI 状态、PR review 反馈、复杂度分析和 walkthrough 视频，最后在被接受后安全落 PR。

很多人第一次看到这里，会本能地把它和 Copilot、Cursor、Claude Code 之类工具放在一起比较。但我觉得，真正准确的比较方式不是“谁代码写得更强”，而是：谁更接近一个面向研发现场的执行系统。 Copilot 类产品解决的是“我写代码时，旁边有个聪明助手”；Symphony 想解决的是“我有一堆 issue，能不能让系统自己取单、分配环境、拉起 Agent、推进状态、处理失败、保留上下文，并把结果交回给我验收”。这已经不只是“辅助编码”，而是开始触碰软件交付流水线本身。

一、Symphony 到底是什么？

从 SPEC.md 看，Symphony 的定义非常清晰：它是一个 long-running automation service。在当前规范版本里，它会持续从 issue tracker 读取工作（v1 里明确是 Linear），为每个 issue 创建独立 workspace，并在这个 workspace 里运行 coding agent session。规范还特别强调了它要解决的四类问题：

1.把 issue 执行变成守护式工作流

2.把每个任务隔离到独立 workspace

3.把工作流策略放回 repo 内的 WORKFLOW.md

4.以及为多任务并发运行提供足够的 observability。

这段定义很重要，因为它一下子把 Symphony 和大量“Agent Demo”拉开了距离。它不是一个写几个 prompt、串几个工具的 toy project，也不是一个单轮任务脚本。它有轮询、有调度、有状态机、有重试退避、有 workspace 生命周期、有运行期事件、有恢复逻辑。换句话说，它的思维方式更像一个 orchestrator，而不是一个单纯的 agent wrapper。

更关键的是，SPEC 还专门写了一个“重要边界”：Symphony 是 scheduler/runner 和 tracker reader。这句话很克制，也很专业。它的意思是，Symphony 的职责重点不是替你定义所有业务流程，而是负责任务编排、执行承载和状态协调；而 ticket 状态变更、评论、PR 链接等写操作，通常还是由 coding agent 借助工具在运行时完成。也就是说，它不是一个万能 PM 系统，而是一层面向软件交付的 agent orchestration 壳。

二、它为什么比“会写代码”更进一步？

因为真正麻烦的，从来不是 AI 能不能生成一段代码，而是几十个任务并行推进时，系统怎么不失控。

Symphony 在这方面做得非常工程化。它有明确的内部状态机：Unclaimed、Claimed、Running、RetryQueued、Released。它还定义了 run attempt 的阶段：准备 workspace、构建 prompt、拉起 agent 进程、初始化 session、流式执行 turn、结束、成功、失败、超时、卡死、被 reconciliation 取消。它甚至规定了每次 poll tick 到来时，先 reconciliation，再校验配置，再拉候选 issue，再按优先级分发，最后通知 observability 消费者。

这套设计背后的思想可以概括成一句话：

不要先问“怎么让 Agent 跑起来”，而要先问“怎么避免它跑重、跑错、跑飞”。

比如 candidate selection 里就有一条很像真实研发现场的规则：如果 issue 还处于 Todo，而它依赖的 blocker 还没进入终态，那就不要派发。排序也不是瞎来，而是按 priority、创建时间、issue 标识顺序稳定分发。失败之后也不是简单重试，而是区分正常退出后的短延迟 continuation retry 和异常退出后的指数退避重试。这样的设计，明显已经不是“写代码助手”的思路，而是“任务执行系统”的思路。

三、每个 issue 一个 workspace：这是 Symphony 最值钱的工程细节

如果你只让我挑 Symphony 里最关键的一点，我会选这个：per-issue workspace。

SPEC 写得非常清楚：

每个 issue 的 workspace 路径都必须位于配置的 workspace root 之下；coding agent 只能在该 issue 的 workspace 里执行；workspace 目录名必须净化；还支持 after_create、before_run、after_run、before_remove 等 hooks。工作区会跨运行复用，但终态 issue 可以在启动或状态变更时清理。

**为什么这个设计这么重要？**因为一旦没有隔离，Agent 系统很快就会碰到三个问题：上下文污染、任务互相踩踏、失败后难以恢复。Symphony 的思路很像给每个工单都分配一个独立工位，Agent 只能在自己的工位里思考、改代码、跑测试、记录状态。哪怕它中途失败了，下次重试回来，也可以在同一个 workspace 上继续，而不是重新失忆。

这也是为什么我说 Symphony 更接近“工程执行系统”而不是“聊天式 Agent”。聊天系统强调对话连续；Symphony 强调的是任务连续性。这两个东西，根本不是一个层级。

四、WORKFLOW.md 才是灵魂：把 Prompt 升级成 repo 内契约

Symphony 很聪明的一点，是它没有把流程硬编码进平台，而是把策略收回到仓库里。SPEC 规定 WORKFLOW.md 由 YAML front matter 和 Markdown prompt body 组成，运行时会解析出 config 与 prompt template；很多核心行为——轮询间隔、workspace root、并发限制、hooks、agent 参数——都来自这份 repo-owned contract。

参考实现里的 WORKFLOW.md 更是把这种思想写得非常彻底。它规定了 issue 在不同状态下该怎么流转：

●Todo 要立即切到 In Progress，然后找或建唯一的 ## Codex Workpad 评论，再开始分析与实现；

●Human Review 阶段不再改代码，只轮询 review 结果；

●进入 Merging 后必须走专门的 land 技能，不能直接 gh pr merge。文档还要求把单个 workpad comment 当作进度和交接的唯一真相源，并且把 out-of-scope 改进拆成新的 Backlog issue，而不是在当前任务里偷偷扩 scope。

这件事的意义非常大。它意味着团队以后真正需要打磨的，不只是“怎么写 prompt”，而是“怎么把流程、约束、验收标准、状态流转、回退机制，写成一份和代码一起版本化的工程契约”。这比 prompt engineering 更接近组织能力。

五、为什么参考实现偏偏选了 Elixir？

这不是噱头，反而是我觉得 Symphony 最有工程味的地方之一。

GitHub 仓库当前语言分布里，Elixir 约占 94.9%；README 也直接写了 Why Elixir?：因为 Elixir 运行在 Erlang/BEAM/OTP 之上，很适合监督长时间运行的进程，并且支持在不停止活跃 subagents 的情况下做 hot code reloading。

这和 Symphony 的问题形态是高度匹配的。一个普通 Web 请求可能几十毫秒就结束，但一个 coding agent 处理复杂任务时，可能会持续很久，还要接收事件、处理重试、维持会话、更新状态、暴露观测数据。BEAM/OTP 擅长的，恰好就是这种长生命周期、并发多、失败要可控隔离的系统。OpenAI 官方没有在 README 里展开讲 supervision tree 这些词，但它给出的理由已经足够说明方向：Symphony 不是在追求“AI 生态默认语言”，而是在追求“最适合承载 agent orchestration 的运行时”。

六、真正的前提不是更强模型，而是 Harness Engineering

如果说 Symphony 讲的是“如何调度 Agent”，那 Harness Engineering 讲的就是“怎样让 Agent 值得被调度”。

OpenAI 在官方文章里把这件事说得很重：他们构建的产品里，应用逻辑、测试、CI、文档、可观测性和内部工具，全部由 Codex 写出；而人类工程师的角色，从直接写代码，转向设计环境、明确意图、构建反馈回路。文章里那句“Humans steer. Agents execute.”，几乎可以看作整个 Symphony 时代的软件工程宣言。

也正因如此，README 才会明确写：Symphony 最适合已经采用 harness engineering 的代码库。意思很简单：如果你的仓库没有可靠测试、没有清晰边界、没有稳定构建入口、没有可验证的反馈回路，那么再强的 Agent 也只是更快地在混乱里打转。Symphony 的价值，不是替代工程纪律；恰恰相反，它会把工程纪律的重要性放大十倍。

七、它的边界也必须讲清楚

一个成熟的技术判断，不能只讲想象力，不讲边界。

Symphony 现在仍是一个工程预览版，README 明确写了适用于 trusted environments；SPEC 也写了 approval policy、sandbox policy、operator confirmation posture 都是 implementation-defined，不同实现可以高信任，也可以更严格。它当前规范版本只定义了 Linear 作为 tracker，至于更多 issue tracker 适配器，还是 TODO。参考实现虽然带可选 Phoenix observability 服务和 JSON API，但整个项目还远没到“所有团队直接开箱上生产”的阶段。

所以，最稳妥的结论不是“研发彻底无人化已经到来”，而是：

OpenAI 正在把 AI Coding 从“单点能力演示”推进到“工程系统形态演示”。

这一步，比单纯再出一个更强的代码模型，更值得关注。

结语

如果一定要用一句话概括 Symphony，我会这样说：

它不是在教 Agent 如何写代码，而是在教团队如何把“软件交付”本身改写成一套可执行、可编排、可观测的系统。

过去，AI 是工程师的副驾驶；现在，Symphony 展示的是另一种可能：工程师不再盯着每一行代码，而是站到更高一层，去设计流程、约束环境、设定验收标准，然后管理一批持续运行的 agent 去推进工作。真正的变化，不是“AI 会不会写 CRUD”，而是“软件组织会不会因此改写自己的工作方式”。

这，才是 Symphony 最值得认真读的地方。

拒绝内卷！为什么我们应该抵制用 LeetCode 考查真实的工程师？

Wed, 04 Mar 2026 08:41:32 +0000

拒绝内卷！为什么我们应该抵制用 LeetCode 考查真实的工程师？

如果你要招募一位主刀医生，你会让他当场默写《人体解剖学》的第一章吗？如果你要找一位米其林大厨，你会蒙住他的眼睛，让他比赛在一分钟内切出多少根标准厚度的土豆丝吗？

显然不会。但在如今的软件工程招聘中，我们却在做着同样荒谬的事情：让那些在复杂的业务泥潭中摸爬滚打、主导过千万级并发系统、熟练操纵复杂云原生架构的资深工程师，站在白板前，徒手写出一个“翻转二叉树”或者“接雨水”的最佳时间复杂度解法。

不知从何时起，“刷 LeetCode”已经从一种思维训练，演变成了一场病态的军备竞赛。是时候戳破这个泡沫了：LeetCode 根本选拔不出优秀的软件工程师，它正在毁掉我们的行业生态。

一、真实的工程世界，从来不是一道“闭卷考试”

让我们先来看看，一个现代软件工程师的真实一天是怎样度过的。

你可能会花一整个上午，在一堆没有注释的“屎山”代码中追踪一个诡异的内存泄漏问题；你可能会在下午和产品经理反复拉扯，确定一个新功能在微服务架构下的 API 边界；你可能会在排查为什么 Kubernetes 集群里的 HPA（水平Pod自动扩缩容）没有按预期触发，或者研究 Istio 网关的流量路由策略。

如果你身处最前沿的 AI 领域，你可能正在评估是用 LangGraph 还是 AutoGen 来构建多 Agent 协同流，或者在调试大模型 API 的 Top-p 采样参数，试图让生成的回答既准确又具有随机性。甚至，在业余时间，你可能在设计一款解决自己痛点的小工具——比如一个用来清理、分类和管理繁杂书签的浏览器插件。

这些工作有一个共同点：它们都是极其复杂的、高度依赖上下文的、开放性的问题。

而在真实的工作环境中，我们解决这些问题依靠的是什么？

1.查阅文档与搜索能力：我们有 Google、有官方文档、有开源社区，甚至现在还有 AI 助手。

2.调试与试错能力：我们通过打日志、单步调试、看监控指标来定位问题。

3.架构视野与经验直觉：我们知道什么时候该用单例模式，什么时候该用工厂方法；我们知道在高并发下如何设计缓存策略，如何保证数据一致性。

4.沟通与协作：我们需要阅读别人的代码，也需要让别人看懂我们的设计。

反观 LeetCode 面试，它创造了一个极其不真实的无菌实验室环境：

●题目边界清晰，输入输出明确。

●只有单一的“最优解”（通常是时间复杂度和空间复杂度的极限）。

●不允许查阅文档，甚至不允许使用趁手的 IDE（有时只能在网页的纯文本框里写代码）。

●偏离日常使用的技术栈（你可能用 Python 写了十几年业务，却要用 C++ 的思维去考虑指针和内存管理）。

这就像是要求一个现代战争中的王牌飞行员，在面试时去比拼谁的射箭准头更好。它考察的不是“解决问题的能力”，而是“在极其受限条件下的默写能力”。

二、刷题面试，正在惩罚真正有经验的“老兵”

在软件开发领域，经验是一笔巨大的财富。一个拥有 10 年、15 年工作经验的研发架构师，他最大的价值并不在于写代码的速度有多快，而在于他踩过足够多的坑。

资深工程师知道，一个系统最大的危机往往不是算法复杂度从变成了（很多时候硬件资源和缓存机制完全能弥补），而是：

●数据库连接池配置不当导致的雪崩。

●缺乏熔断降级机制导致的服务级联故障。

●领域模型设计错误导致的后续需求无法扩展。

●业务逻辑耦合过深导致的测试困难。

然而，当这位资深架构师带着一身的实战本领走进面试房间时，等待他的却是一道“动态规划（DP）”的 Hard 题。

这是一种极大的资源浪费。一个能在生产环境中稳稳掌控全局、能设计出高可用 AI 基础设施、能带领团队攻坚克难的资深人才，仅仅因为最近几个月忙于项目交付、或者忙于应对生活中的变故（比如寻找新机会、照顾家庭），没有抽出几百个小时去死记硬背算法题库，就被无情地贴上“技术不过关”的标签淘汰出局。

这种现象导致了一个极其荒谬的倒挂：

那些刚刚毕业、没有写过一行生产环境代码、不懂得什么是持续集成、不知道如何进行线上排障的学生，只要花三个月把 LeetCode 刷个滚瓜烂熟，就能在面试中大杀四方；而那些真正在一线扛过枪、打过仗，能够解决复杂工程灾难的老兵，却在白板前因为忘记了一个状态转移方程而涨红了脸。

企业以为自己招到了“绝顶聪明”的天才，结果新人一入职，面对极其复杂的微服务依赖和一团乱麻的业务逻辑，立刻束手无策。因为真实的业务系统里，没有人会为你准备好整洁的 ListNode 或者 TreeNode。

三、算法题面试的本质：一场低效的“智商服从性测试”

为什么即便怨声载道，这么多公司依然痴迷于 LeetCode 面试？很多面试官会辩解说：“算法题能考察候选人的聪明程度和逻辑思维。”

这其实是一个伪命题。

1. 算法题早就不测智商了，它只测“准备度”。

在互联网早期，用算法题面试确实能筛选出一些思维敏捷的人，因为那时没有题库。但现在，LeetCode 已经有上千道题，“面经”满天飞。面试不仅变成了开卷考试的闭卷化，更变成了一门应试产业。能解出 Hard 题，往往不意味着你绝顶聪明，只意味着你刷到过原题，或者你花了大把时间去背诵套路。这充其量是一场“服从性测试”——看候选人愿不愿意为了这份工作去吃毫无意义的苦。

2. 忽视了工程中最关键的“可维护性”。

在 LeetCode 的评价体系里，“代码跑得快”是唯一的真理。哪怕你的代码里全是 i, j, k, dp, res 这种毫无语义的变量名，哪怕你的逻辑晦涩难懂如天书，只要能 AC（Accepted），你就是赢家。

但在实际工程中，这种代码是灾难。好的工程师写出的代码是给人看的，其次才是给机器执行的。如果你的代码在生产环境中出了 Bug，同事半夜被叫醒排查，看到满屏追求极致技巧却毫无注释的“炫技代码”，他大概率会在心里把你骂上一万遍。LeetCode 培养出的“做题家”思维，与团队协作所需的工程素养往往是背道而驰的。

3. 面试官的“安全牌”与偷懒。

其实，很多面试官也根本不知道该怎么面试。对他们来说，从题库里随机抽一道题扔给候选人，是最省事、最没有风险的做法。如果你没写出来，那是你不行，面试官不需要承担招错人的责任。这种做法掩盖了面试官自身架构视野和识人能力的匮乏。要深入了解一个人的项目经验、技术深度和系统设计能力，需要面试官投入极大的精力和极高的技术水平去进行深度的技术探讨，而“考一道题”则轻易地把压力全抛给了候选人。

四、如何打破僵局：回归工程本质的面试方法

批判之后，我们需要建设。如果不考 LeetCode，我们该怎么筛选优秀的软件工程师？真正的面试，应该是一场对日常工作的高度模拟。

1. 结对编程 (Pair Programming)

不要让候选人在白板上写代码，给他一台配置好 IDE 的电脑。面试官准备一个真实但简化过的业务小项目，或者直接在公司的一个开源代码分支上，两人结对协作。

●“我们现在有一个 Python 的服务端，用 FastAPI 写的，现在需要增加一个中间件来做简单的限流，你打算怎么做？”

●允许候选人查阅文档，允许使用 Google。

●观察他的编码习惯、他对框架的熟悉程度、他如何拆解问题，以及更重要的——他如何与你沟通和协作。

2. 代码审查 (Code Review)

给候选人一段存在各种“坑”的代码（可以是以前团队写出的真实烂代码，隐去敏感信息）。这段代码可能存在并发竞争、内存泄漏、或者设计模式的滥用。

让候选人进行 Code Review。优秀的工程师能立刻嗅出代码中的“坏味道”，并提出合理的重构建议。这比让他默写快速排序要有效得多。

3. 深度系统设计与项目复盘

抛弃那些假大空的“如何设计一个推特”的八股文。让候选人深度讲解他简历中最自豪的一个项目。

●“你在简历中提到主导了容器化改造，能画一下当时的 Kubernetes 架构图吗？”

●“在使用 Ingress 和服务网格（比如 APISIX 或 Istio）时，你们遇到了什么性能瓶颈？是如何排查的？”

●“你提到在做 AI 相关的研发，在整合底层大模型接口时，你们是如何处理长上下文带来的延迟问题和 token 消耗的？”

通过深度的追问，直到触及他的知识边界。真正的行家，在谈论自己亲手一砖一瓦建起来的系统时，眼里是有光的，细节是经得起推敲的。

4. 聊聊他创造的“小玩意儿”

一个真正的工程师，往往是对技术充满热情的创造者。与其问算法，不如问问他平时都在折腾什么。如果他告诉你，他因为受不了浏览器书签太乱，正在自己设计开发一个管理书签的插件；或者他为了解某种新技术栈，自己搭了一个爬虫和数据展示网站。请让他展示一下！这种对痛点的敏锐察觉和动手解决问题的能力，是任何算法题都无法衡量出的核心特质。

五、结语：放过工程师，也放过企业自己

技术招聘走到今天“无算法不面试”的地步，是整个行业的悲哀。它消耗了工程师们原本可以用来学习新框架、钻研底层原理、甚至陪伴家人的宝贵精力；它也让企业错失了大量踏实肯干、经验丰富的实战派人才。

编程，是一门结合了逻辑、工程、设计甚至艺术的创造性活动。它不该被简化为一场机械的背诵比赛。

作为面试官，下次当你准备掏出一道 LeetCode Hard 题时，不妨停下来问问自己：“这道题，真的能帮我找到那个能和我并肩作战、一起扛住双十一流量洪峰、一起在深夜排查诡异 Bug 的可靠队友吗？”

如果不能，请放下那道该死的算法题，和候选人像真正的工程师一样，聊聊真实的架构，看看真实的代码。

把时间还给工程，把尊严还给工程师。

一文讲透 GoF 的 23 种设计模式之工厂方法

Fri, 27 Feb 2026 23:00:00 +0000

一文讲透 GoF 的 23 种设计模式之工厂方法

工厂方法（Factory Method）是创建型模式

定义

用一句话概括工厂方法模式：定义一个用于创建对象的接口，让子类决定实例化哪一个类。它让类的实例化推迟到了子类。

简单工厂

了解工厂方法模式前，我们先了解下简单工厂，既然叫简单工厂，那自然很 “简单”。

它的核心思想非常直接：专门定义一个类（包揽大权），通过接收不同的参数，用 switch 或 if-else 来决定创建并返回哪一种具体的产品实例。

假设我们在开发一个 AI 应用，需要根据不同场景创建不同类型的 AI Agent（比如负责对话的 Agent，和负责处理数据的 Agent）。

第一步：定义产品的共同接口和具体实现

 1⚡ java片段// 1. 抽象产品
 2public interface AIAgent {
 3 voidexecuteTask();
 4}
 5
 6// 2. 具体产品 A：聊天助理
 7publicclass ChatAgent implements AIAgent {
 8 @Override
 9 publicvoidexecuteTask() {
10 System.out.println("ChatAgent: 正在与用户进行自然语言对话...");
11 }
12}
13
14// 2. 具体产品 B：数据分析助理
15publicclass DataAnalysisAgent implements AIAgent {
16 @Override
17 publicvoidexecuteTask() {
18 System.out.println("DataAnalysisAgent: 正在提取并分析核心数据...");
19 }
20}

第二步：创建“简单工厂”类

 1⚡ java片段// 3. 简单工厂类 (通常使用静态方法)
 2publicclass AIAgentFactory {
 3 
 4 // 根据传入的类型参数，决定实例化哪个具体的 Agent
 5 publicstatic AIAgent createAgent(String agentType) {
 6 if ("chat".equalsIgnoreCase(agentType)) {
 7 return new ChatAgent();
 8 } elseif ("data".equalsIgnoreCase(agentType)) {
 9 return new DataAnalysisAgent();
10 } else {
11 throw new IllegalArgumentException("未知的 Agent 类型: " + agentType);
12 }
13 }
14}

第三步：客户端调用

 1⚡ java片段public class Client {
 2 public static void main(String[] args) {
 3 // 客户端不需要知道 ChatAgent 和 DataAnalysisAgent 是怎么被 new 出来的
 4 // 只需要告诉工厂：“给我一个 chat 类型的 Agent”
 5 AIAgent agent1 = AIAgentFactory.createAgent("chat");
 6 agent1.executeTask();
 7
 8 AIAgent agent2 = AIAgentFactory.createAgent("data");
 9 agent2.executeTask();
10 }
11}

结合代码，我们可以很直观地看到它的特点：

●优点（省事、解耦）：客户端彻底和具体的实现类解耦了。你不需要在业务代码里到处写 new ChatAgent()，把“创建对象”的脏活累活全交给了工厂。

●缺点（牵一发而动全身）：它严重违反了“开闭原则”（对扩展开放，对修改关闭）。假设我们现在要引入一个新的 CodingAgent（写代码助手），除了要新建产品类，你必须去修改 AIAgentFactory 里面的 if-else 代码。一旦产品种类极其庞大，这个工厂类就会变得非常臃肿且难以维护。

正是为了解决简单工厂“违反开闭原则”的这个致命缺点，才演进出了工厂方法模式（把这一个大工厂，拆成了一个个不用改代码、只需新增的具体小工厂）。

工厂方法模式的结构与角色

工厂方法模式主要包含四个角色：

●抽象产品 (Product)：定义产品的统一接口。

●具体产品 (Concrete Product)：实现抽象产品接口的具体类。

●抽象工厂 (Creator)：声明返回产品对象的工厂方法。

●具体工厂 (Concrete Creator)：重写工厂方法，返回具体的实例化产品

Java 代码实现

1. 定义产品（大模型客户端）

 1⚡ java片段// 抽象产品：统一的大模型调用接口
 2public interface LLMClient {
 3 String generate(String prompt);
 4}
 5
 6// 具体产品 A：Claude 客户端
 7publicclass ClaudeClient implements LLMClient {
 8 private String modelVersion;
 9 
10 publicClaudeClient(String modelVersion) { this.modelVersion = modelVersion; }
11
12 @Override
13 public String generate(String prompt) {
14 return"[Claude " + modelVersion + "] 思考并返回结果...";
15 }
16}
17
18// 具体产品 B：OpenAI 客户端
19publicclass OpenAIClient implements LLMClient {
20 private String endpoint;
21 
22 publicOpenAIClient(String endpoint) { this.endpoint = endpoint; }
23
24 @Override
25 public String generate(String prompt) {
26 return"[OpenAI API] 处理输入并返回结果...";
27 }
28}

2. 定义创建者（核心：业务骨架 + 工厂方法）

这里是关键：AgentWorkflow 不是一个纯粹的“工厂类”，它是业务类，工厂方法只是它的一部分。

 1⚡ java片段// 抽象创建者：Agent 工作流骨架
 2public abstract class AgentWorkflow {
 3
 4 // 核心业务逻辑：定义了标准的处理流程（这其实也是个模板方法）
 5 publicvoidprocessTask(String taskContext) {
 6 System.out.println("=== 1. 解析任务上下文，提取关键信息 ===");
 7 
 8 // 【灵魂所在】：这里调用工厂方法，拿到一个产品对象。
 9 // 父类在此刻完全不知道自己拿到的是 Claude 还是 OpenAI。
10 LLMClient client = createLLMClient();
11 
12 System.out.println("=== 2. 请求大模型进行推理 ===");
13 String result = client.generate(taskContext);
14 
15 System.out.println("=== 3. 结果后处理并落库 ===\n" + result + "\n");
16 }
17
18 // 【工厂方法】：将实例化具体产品的职责，推迟到子类去实现
19 protected abstract LLMClient createLLMClient();
20}

3. 定义具体创建者（子类重写工厂方法）

 1⚡ java片段// 具体创建者 A：基于 Claude 的工作流
 2publicclass ClaudeAgentWorkflow extends AgentWorkflow {
 3 @Override
 4 protected LLMClient createLLMClient() {
 5 // 这里封装 Claude 特有的复杂初始化逻辑（比如加载凭证、设置代理等）
 6 System.out.println(" -> [工厂方法] 正在初始化 Claude 客户端环境...");
 7 return new ClaudeClient("3.5-Sonnet");
 8 }
 9}
10
11// 具体创建者 B：基于 OpenAI 的工作流
12publicclass OpenAIAgentWorkflow extends AgentWorkflow {
13 @Override
14 protected LLMClient createLLMClient() {
15 System.out.println(" -> [工厂方法] 正在构建 OpenAI 客户端环境...");
16 return new OpenAIClient("https://api.openai.com/v1");
17 }
18}

4. 客户端调用

 1⚡ java片段public class Client {
 2 publicstaticvoidmain(String[] args) {
 3 String task = "编写一段 Python Web 框架对比报告";
 4
 5 // 场景 1：启动基于 Claude 的 Agent 工作流
 6 AgentWorkflow claudeWorkflow = new ClaudeAgentWorkflow();
 7 claudeWorkflow.processTask(task);
 8
 9 // 场景 2：切换为基于 OpenAI 的 Agent 工作流
10 AgentWorkflow openaiWorkflow = new OpenAIAgentWorkflow();
11 openaiWorkflow.processTask(task);
12 }
13}

如果你回看之前的例子，你会发现这个 Demo 解决了一个架构设计上的核心痛点：控制反转 (IoC) 的雏形。

在 AgentWorkflow 这个父类中，业务主流程已经被彻底固化并复用（processTask 方法）。如果在未来，业务需求要求你接入一个全新的本地开源模型（比如 DeepSeek），你不需要修改任何现有的主流程代码，只需要：

●新建一个 DeepSeekClient（实现 LLMClient）。

●新建一个 DeepSeekAgentWorkflow，重写 createLLMClient() 方法返回这个新 Client。

这才是工厂方法模式真正强大的地方：它是为了让高层模块（业务骨架）能够独立于底层模块（具体产品）的创建而存在，从而支撑起大型框架的扩展性。 JDK 里的 Iterable 接口和它的 iterator() 方法，本质上就是这种工厂方法模式的经典体现。

什么时候用?

●你写的“父类流程”需要创建某种对象，但父类不该/不想知道具体类是谁（框架留扩展点的典型方式）。

●你希望通过继承覆写来扩展“产物类型”，让调用方不动、流程不动。

一些具体的场景：

●框架扩展点：工厂方法很常见于“框架规定流程、业务方覆写创建”的场景（你写子类接入框架）。

●Spring 的 FactoryBean：它的语义就是“这个 bean 不是普通 bean，而是用来生产另一个对象的”，并且暴露的是 getObject() 创建出来的对象。

●Java ServiceLoader：通过 SPI 在运行时发现/加载实现类，属于“把具体实现延迟到运行时配置/部署”的一类机制，和“解耦创建与使用”的目标一致。

注意模式的命名

我们回头看一下这个模式为什么叫 Factory Method，而不是干脆叫 Factory ? 这个命名是有讲究的。

核心原因在于：这个模式的灵魂是一个“方法”，而不是一个“类”。

1.“工厂 (Factory)”是一个通俗的广义概念：

在日常沟通中，只要一个类的主要职责是造对象，我们都叫它工厂（比如前面提过的“简单工厂”，它就是一个充斥着 if-else 的具体类）。

2.“工厂方法 (Factory Method)”强调的是面向对象中的“多态”与“继承”：

在 GoF 的定义中，创建对象的逻辑并不是封装在一个独立的、包揽大权的“工厂类”里，而是定义在了一个普通业务类（Creator）的内部，作为一个抽象方法存在。

●这个模式的精髓是：父类定义业务骨架，把其中“需要实例化具体对象”的那一步，挖空成一个方法（也就是 Factory Method）。

●具体的实例化工作，推迟（Defer）到了子类去重写这个方法来实现

OpenClaw 单对话连续性与 Memory 深度解析

Thu, 26 Feb 2026 09:18:40 +0000

很多人第一次用龙虾时都会有一个直觉：

“聊久了，它应该会忘吧？”

这个直觉没错。模型的上下文窗口是有限的，不可能把几万句对话永远都放在眼前。

但你会看到系统表现得像这样：

●不切 thread，也能连续推进一个长期任务

●记得你之前的偏好、决定和待办

●对话很长后也不会突然“失忆”

这篇文章讲清楚它背后的工程逻辑。

先讲结论：它靠的不是“超大脑子”，而是“分层记忆”

一个能长期连续工作的 AI 助手，通常不是在“硬记全部聊天记录”。

它更像一个做事很靠谱的人：

●脑子里保留当前任务所需的短期信息

●把长期重要信息记到笔记本

●需要时再去查笔记，而不是靠猜

所以关键不是“记住一切”，而是“该记哪里、什么时候记、怎么取回来”。

1 为什么“一个对话一直聊”不会乱

要做到这件事，第一步不是 memory，而是“会话归属稳定”。

你可以把它理解成：

●每条新消息进来，系统都要先回答“这条消息属于哪条连续会话？”

●只要这个归属规则稳定，用户就会感受到“我一直在同一个对话里”

如果归属不稳定，会发生什么？

●今天这句进 A 会话

●明天那句进 B 会话

●用户感觉就是“它忽然不记得了”

所以，连续性首先是路由问题，不是模型智商问题。

2 长对话为什么不会把模型撑爆

即使会话归属稳定，也还有第二个难题： 上下文窗口会满。

成熟系统会做三件事：

1.限制最近历史：只保留与当前问题最相关的“最近若干轮”。

2.自动压缩旧历史（compaction）：把很长的旧对话压成“结构化摘要”，保留关键决策和状态。

3.失败兜底：如果压缩中断或超时，回退到安全快照，不让会话进入半坏状态。

这和人工作很像：

●桌上只放当前要处理的文件

●老文件归档成摘要

●归档出错就先回到上一个可用版本

3 真正关键：Memory 不是“备份聊天记录”

很多人把 memory 理解成“把聊天全存起来”。

这不够。

真正可用的 memory 系统至少要回答 4 个问题：

1.存什么

2.什么时候存

3.怎么找

4.找到后给模型喂多少

1 存什么

不是所有对话都值得永久存。

通常要存的是：

●稳定偏好（口味、风格、边界）

●已确认决策（做过什么决定、为什么）

●长周期任务状态（进行到哪一步）

●关键事实（日期、人物、账号约束）

2 什么时候存

好的系统会在“即将压缩上下文”前触发一次静默写入（memory flush）：

●先把耐久信息落盘

●再去压缩历史

这样就不会因为压缩导致关键信息漂掉。

3 怎么找

常见做法是“混合检索”：

●关键词检索（你说了某个明确词）

●语义检索（你换了说法但意思相近）

然后把结果融合排序，优先给出最相关片段。

4 找到后喂多少

成熟系统不会把整本记忆库都喂给模型。

而是两步：

●先 search，拿候选

●再 get，只读取必要行

这样上下文干净，成本低，稳定性高。

4 一个通俗例子：为什么它看起来“真的记得你”

假设你连续三周都在推进“装修计划”。

第一周你说：

●不要开放式厨房

●预算上限 20 万

第二周你说：

●客厅采光优先

●工期希望 3 个月内

第三周你问：

“按我们之前的原则，周末我要见设计师，该先确认哪三件事？”

如果系统只靠当前窗口，它可能忘掉第一周。

如果它有分层记忆：

●会话里保留最近讨论

●长期记忆里有你前两周沉淀的偏好与约束

●回答前先检索再取关键片段

最终回答会更像“基于你的长期上下文”，而不是一次性临场发挥。

5 一个点看懂工程质量

为什么 memory flush 不会乱触发，也不会重复触发。

很多系统的问题不是“没有 memory flush”，而是“flush 触发太随意”，结果变成：

●该写入时没写

●不该写入时反复写

●一次 compaction 周期里重复写同样内容

OpenClaw 在这个点上做得很精细，核心是三段式控制。

1 先算阈值，只在快到上限时触发

在 src/auto-reply/reply/memory-flush.ts 里，触发条件本质是：

⚡ text片段//当 totalTokens >= threshold 时，才考虑 flush threshold = contextWindow - reserveTokensFloor - softThresholdTokens

这让 flush 从“拍脑袋触发”变成“窗口压力驱动”。

2 再做幂等控制，一轮 compaction 只 flush 一次

同一文件里还有一个关键判断（shouldRunMemoryFlush）：

●当前会话有 compactionCount

●上一次 flush 记录了 memoryFlushCompactionCount

●如果两者相等，说明本轮已经 flush 过了，直接跳过

这一步非常工程化。它不是靠“感觉上不会重复”，而是靠状态位严格去重。

3 触发位置放在主回合之前，保证先落盘再压缩

在 src/auto-reply/reply/agent-runner.ts 中，runMemoryFlushIfNeeded() 被放在主回合执行前。

src/auto-reply/reply/agent-runner-memory.ts 里会进一步检查：

●不是 heartbeat

●不是某些不适合的 provider 模式

●工作区可写（只读沙箱不写）

通过后才跑 flush 回合，并在结束后把这两个字段写回 session store：

●memoryFlushAt

●memoryFlushCompactionCount

对应会话结构字段定义在 src/config/sessions/types.ts。

它把“写记忆”做成了可证明的状态机，而不是一段“偶尔执行的辅助逻辑”。

这就是为什么它在长对话压力下还能稳定，不会一边压缩一边把记忆策略搞乱。

6 这套设计的代价与边界

这套方案很强，但不是魔法。

优点

●单对话体验稳定

●长任务可持续

●对“历史事实”更不容易胡编

代价

●系统更复杂（路由、索引、压缩、检索都要配合）

●记忆质量取决于写入质量

●参数没调好会影响召回质量或成本

现实边界

●记忆不是 100% 真相机，仍需要来源校验

●高风险场景要保留“我不确定”与“可追溯引用”机制

7 如果你在设计类似系统，最值得抓住的三件事

1.先保证会话归属稳定

●不要一上来就追求复杂 memory，先让“同一个人同一类对话”稳定落在同一会话。

2.把长期记忆外置

●不要指望模型窗口长期记住一切。把耐久信息写进可检索存储。

3.强制“先检索再回答”

●在系统策略层明确约束：涉及历史事实必须先查 memory。

●这是把“看起来聪明”变成“工程上可靠”的分水岭。

结语

一个真正能长期协作的 AI，对外看起来像“记性很好”。

但从工程上看，它做的是更朴素、也更难的一件事：

把“记住”拆成可管理的流程。

●谁的会话

●当前保留什么

●长期写入什么

●回答前查什么

当这四件事同时做好，用户才会得到那种自然体验：

“我没有切 thread，但它一直跟得上我。”

全程0人工写代码！干掉低级码农的不是大模型

Tue, 24 Feb 2026 03:46:39 +0000

全程0人工写代码！干掉低级码农的不是大模型

在当前全行业的 AI 辅助编程浪潮中，大多数工具仍停留在“交互式伴游”阶段，而支付巨头 Stripe 却打造了一套完全无人值守的端到端代码智能体——“小黄人”（Minions）

小黄人是一个独立打工的“数字员工”。目前的惊人数据是：在 Stripe 内部，每周有超过 1300 个由小黄人完全生成的 Pull Requests（合并请求）被成功合并。这些代码在最终阶段会经过人类审查，但其中不包含任何人类编写的代码。

更具挑战的是，Stripe 的代码库高达数亿行，主要使用较冷门的带有 Sorbet 类型的 Ruby 语言，且包含大量 LLM 根本没见过的大型内部自研库。此外，这些代码每年要处理超过 1 万亿美元的支付量，合规与容错要求极高。

Stripe 是如何让 LLM 驾驭如此庞大且复杂的企业级代码库的？核心答案在于极其强大的定制化工程脚手架。

以下是小黄人能高效运转的四大核心技术拆解。

1 极致标准化的预热沙盒（Devboxes）

要让全自动 Agent 大规模并行工作，绝不能让它们跑在开发者杂乱的本地笔记本上。Stripe 的解法是直接复用为人类工程师打造的云端开发机（Devboxes）。

●10 秒极速“热启动”：这些 Devbox 是 AWS EC2 实例。Stripe 预先配置并预热了一个资源池，里面已经克隆好了巨大的 Git 仓库，预热了 Bazel 构建缓存和类型检查缓存，甚至启动了持续运行的代码生成服务。因此，只要 10 秒钟，小黄人就能拿到一台随时可以运行测试和修改代码的机器。

●免弹窗的完全提权：为了让小黄人在后台静默运行，它需要无缝执行各种 Shell 命令。因为 Devbox 运行在与生产资源和外部互联网隔离的 QA 环境中，爆炸半径被严格限制，所以系统敢于跳过人类权限确认弹窗，给予小黄人完整的执行自由。

●解决并发冲突：如果用本地环境，并发运行多个 Agent 需要处理复杂的 git worktrees（这在 Stripe 的庞大代码库中无法扩展）。而在云端，工程师可以轻易地同时为 6 个不同的任务启动 6 个分配了独立 Devbox 的小黄人，实现物理级别的完美隔离

2 “蓝图”编排（Blueprints）：将大模型装进确定性的盒子里

常规的 Agent 往往采用开放的循环机制，任由 LLM 自己决定下一步调什么工具，这极易导致出错和浪费 Token。 Stripe 创造性地引入了**“蓝图”（Blueprints）**状态机机制。蓝图将整个工作流视为一张图，将 LLM 的创造力与确定性的系统代码交织在一起：

●确定性节点 vs Agent 节点：在蓝图中，像“实现具体任务”或“修复 CI 失败”是让 LLM 自由发挥的 Agent 节点；但是，像“运行配置好的 Linter”或“推送 Git 变更”则是完全不调用 LLM 的纯代码确定性节点。

●底线兜底：这意味着小黄人无法绕过代码格式化等硬性规范。把大模型“关进受控的盒子里”，不仅极大地节省了 Token，还从系统层面提高了整体可靠性。各团队甚至可以编写自定义的蓝图，来处理复杂的、LLM 辅助的代码库迁移任务

3 极其克制的上下文投喂：规则文件与 Toolshed

面对上亿行代码，如果把所有全局规则都塞给大模型，上下文窗口瞬间就会被撑爆。

●按目录生效的局部规则：Stripe 几乎只使用作用于特定子目录或文件模式的规则文件。他们巧妙地复用了人类工程师为 Cursor 编写的规则格式。这样，工程师在日常开发中沉淀的最佳实践，小黄人（以及 Claude Code）在遍历文件系统时就能直接动态读取并学习。

●MCP 工具棚（Toolshed）：小黄人通过模型上下文协议（MCP）获取网络信息（工单、文档、代码搜索等）。Stripe 建立了一个包含近 500 个内部与 SaaS 工具的中央服务器 Toolshed。但为了防止 Agent 分心，系统每次只会为小黄人精心挑选一个“小巧而高度相关”

4 反馈左移（Shifting Feedback Left）：极速纠错循环

无人值守 Agent 成功的关键在于能否实现自我闭环修正。Stripe 为其构建了多层极速反馈循环：

●5 秒内的本地验证：在小黄人把代码推送到 CI 之前，Devbox 上的后台守护进程会通过启发式算法自动运行相关的 Linter 和类型检查。这个本地节点耗时不到 5 秒，让小黄人在本地极速完成语法纠错。

●克制的 CI 测试轮数：Stripe 的 CI 拥有超过 300 万个测试用例。推送到 CI 后，系统会运行相关测试，并自动应用已有的修复脚本（Autofixes）。如果还有未修复的错误，报错会发回给小黄人。但为了平衡算力成本、时间与边际收益，小黄人最多只被允许进行 1 到 2 次的 CI 循环试错。之后无论成败，都会将其移交给人类处理，防止其陷入昂贵的死循环

给我的启示

基于 Stripe 公开的这些技术细节，我得出了以下几点关于 AI 研发提效的深刻感悟：

1.“对人类工程师有益的基础设施，对 LLM 同样有益” 这是 Stripe 整个小黄人项目最核心的哲学。Stripe 并没有为了做 AI Agent 去凭空造一套新基建，而是直接将 AI 接入了他们多年打磨的 Devbox 环境、Pre-push hooks 和自动化测试管线中。这给所有企业的启示是：AI Agent 的天花板，取决于你现有工程基础设施的底座。如果你的人类工程师本地环境经常崩溃、缺乏单测覆盖率、文档陈旧，那么大模型也一样会在这些泥坑里寸步难行。过去在人类开发者体验（Developer Productivity）上的每一分投资，都会在 AI 时代转化为巨大的复利回报。

2.放弃追求纯粹的“全能 Agent”，用“蓝图”管控不确定性目前业界过度迷恋让一个 Agent 自主解决所有问题。但 Stripe 的蓝图（Blueprints）设计极其务实：能用一行 Bash 脚本或 Linter 稳定解决的问题（如代码格式化、Git 提交流程），就绝对不让 LLM 消耗 Token 去“推理”。在企业级生产环境中，**混合架构（确定性代码逻辑 + 局部受控的 LLM 节点）**才是保证系统高可靠性（SLA）的唯一出路。

3.工程师的日常工作流正在被重塑，在 Stripe，触发小黄人的方式极度符合人体工程学：工程师可以直接在 Slack 的讨论线程里@小黄人，或者在内部的“CI 间歇性失败（Flaky test）”工单中点击一个按钮启动它。我们可以预见，未来的高级工程师将越来越像一个“包工头”：他们在值班（On-call）时并行启动几十个小黄人去处理琐碎的 Bug，自己则专注于审查 PR、设计架构，以及维护和编写能够指导小黄人的局部规则（Cursor rules）。工程师不再逐行敲击代码，而是定义意图并管理基础设施。

参考

●https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents

●https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2

Agent on 小盒子的技术分享

我用两句中文，让 Claude Code 帮我画了10张出版级技术图

让Agent快上100倍的秘密，其实藏在一本大一计算机教科书里

干货 | 轻量级驾驭工程：AI Coding Workflow 最佳落地实践

一、 AI 编程的“向左走向右走”

二、 什么是 SDD？它为什么重要？

三、 击中痛点：告别“实现漂移”

四、 主流 SDD 工作流大比拼

五、 破局策略：组合最优解（缝合怪战术）

六、 终极实战：六步法完整工作流

👣 Step 1: Codebase (建立项目认知)

👣 Step 2: Brainstorm / Research (技术方案探索)

👣 Step 3: Plan (制定开发计划)

👣 Step 4: Work (执行开发)

👣 Step 5: Review (代码审查)

👣 Step 6: Compound (知识复利)

七、 灵活适配：按场景“裁剪”流程

八、 建立知识沉淀体系（动静分离策略）

九、 驾驭工程的核心：上下文工程

🛠️ 附录：工具链安装避坑指南

在 AI Agent 时代，许多硅谷程序员已经几乎不再亲手写代码了

在 AI Agent 时代，许多硅谷程序员已经几乎不再亲手写代码了

编程这门“手艺”，正在被自动化

为什么程序员反而比别人更欢迎 AI ？

程序员，越来越像建筑师而不是泥瓦工

新时代的核心能力：不是写，而是“会说”

在创业公司里，A.I. 的效率提升几乎是爆炸式的

真正复杂的地方，是大公司的“棕地”代码库

在亚马逊，AI 正在扮演“半夜抢修工程师”

程序员依然快乐，但快乐的来源正在变化

反对者并不多，但反对得非常激烈

最先被冲击的，可能是初级程序员

如果新人不再亲手写代码，他们还会真正学会编程吗？

当编程越来越像“说话”，普通人也开始写软件了

一个可能属于所有白领的预演

OpenClaw 爆火背后：它不是聊天机器人，而是一套真正会做事的 AI 系统

一、OpenClaw 的本质，不是聊天机器人，而是“个人 AI 助手控制面”

二、Gateway 为什么是 OpenClaw 最关键的设计

三、它最强的抽象，不是对话框，而是 Agent、Session 和 Route

Agent：一颗完整隔离的大脑

Session：上下文连续性的主键

Route：决定消息进入哪颗大脑

四、Agent 不是外挂调用，而是嵌入式运行时

五、Agent Loop：一条消息的"真实旅程"

不是"一次请求"，而是一个完整生命周期

并发控制：为什么同一聊天窗口的消息要"排队"？

流式事件：你看到的不是"打字动画"，而是真实的工作过程

六、真正让它“像一个人”的，不是模型，而是 Workspace、System Prompt 和 Memory

Workspace：AI 的家，而不是一个临时目录

System Prompt：每次运行都在"编译上下文"

Memory：真正写到磁盘，才算记住

检索机制：不是"只有文件"，也不是"只有向量"

记忆刷新：在"遗忘"前先"存档"

七、工具体系：分层设计，不是堆砌功能

Tools：第一等公民

Plugins：扩展系统本身

Skills：教 AI 如何做事

八、Node：让 AI “有手有眼”

Node 是什么？

九、安全边界：诚实比承诺更重要

安全层次

Sandbox：可以隔离，也可以放行

浏览器隔离：不是接管你的 Chrome

十、为什么这是"个人AI操作系统"的雏形？

它具备了"操作系统"的味道

OpenAI 开源 Symphony：AI 不再只是写代码，而是开始接管“工作流”

一、Symphony 到底是什么？

二、它为什么比“会写代码”更进一步？

三、每个 issue 一个 workspace：这是 Symphony 最值钱的工程细节

四、WORKFLOW.md 才是灵魂：把 Prompt 升级成 repo 内契约

五、为什么参考实现偏偏选了 Elixir？

六、真正的前提不是更强模型，而是 Harness Engineering

七、它的边界也必须讲清楚

结语

拒绝内卷！为什么我们应该抵制用 LeetCode 考查真实的工程师？

拒绝内卷！为什么我们应该抵制用 LeetCode 考查真实的工程师？

一、 真实的工程世界，从来不是一道“闭卷考试”

二、 刷题面试，正在惩罚真正有经验的“老兵”

三、 算法题面试的本质：一场低效的“智商服从性测试”

四、 如何打破僵局：回归工程本质的面试方法

二、什么是 SDD？它为什么重要？

三、击中痛点：告别“实现漂移”

四、主流 SDD 工作流大比拼

五、破局策略：组合最优解（缝合怪战术）

六、终极实战：六步法完整工作流

七、灵活适配：按场景“裁剪”流程

八、建立知识沉淀体系（动静分离策略）

九、驾驭工程的核心：上下文工程

一、真实的工程世界，从来不是一道“闭卷考试”

二、刷题面试，正在惩罚真正有经验的“老兵”

三、算法题面试的本质：一场低效的“智商服从性测试”

四、如何打破僵局：回归工程本质的面试方法

五、结语：放过工程师，也放过企业自己