我为什么从深度学习转去写 OpenClaw

我在公众号写了三年深度学习。

论文解读、模型架构、Transformer 变体、各种 benchmark 对比。读者大多是在高校、研究院、大厂做 AI 的人。

然后有一天，我开始写一个 AI 代理网关的零基础教程。

很多老读者不理解。

"你不是搞深度学习的吗？""怎么去写工具教程了？"

这篇文章，就是我的回答。

我们都盯错了方向

做技术的人，容易陷入一种惯性：把理解系统，等同于掌握系统。

研究模型的人更严重。

我们花大量时间搞清楚注意力机制怎么工作、RLHF 怎么训练、scaling law 意味着什么——这些都是真实的知识，有真实的价值。

但有一件事，我在某个时刻突然意识到：

懂模型怎么工作，和知道怎么让模型为你工作，是两件完全不同的事。

更刺痛我的是：后者，不需要前者。

一个从没看过论文、不知道 Transformer 是什么的人，如果他知道怎么用这些工具，他能做出来的东西，可能比我强。

这不是在否定技术深度的价值。这是在说，普通人和 AI 的关系，已经悄悄变了。

不懂模型，照样能做事。而且是以前需要一个团队才能做的事。

GovClaw：让我真正改变看法的那一天

我用龙虾调用 Claude Code，花了 1 天，做出了一个政务版的 OpenClaw——GovClaw。

架构、设计、编码、测试、文档，全部是 AI 完成的。

在说感受之前，我想把这个过程还原一遍。因为只说结论没有说服力——我需要让你看到，每一步交出来的东西是什么水平。

第一步：架构

我告诉 AI 我要做什么：一个政务场景的 AI 代理网关，需要支持多部门、多租户、多模型，要符合等保 2.0 合规要求。

AI 没有直接开始写代码。

它先做了一件事：分析 GovClaw 和 OpenClaw 原版之间的核心差异，指出了一个我自己没有意识到的设计陷阱——

OpenClaw 的本质是「单进程 + WS Gateway + Lane Queue + .ts Skills 文件」，不是微服务。GovClaw 应该是在这个 agent loop 核心上薄薄叠加政务层，而不是重新搭一套 Spring Boot 风格的服务。

然后给出了两阶段演进策略：Phase 1 先跑通核心，Phase 2 再叠加政务属性。核心原则是"阶段二全部是加法，不修改阶段一任何核心代码，降低回归风险"。

这是一个有经验的架构师会给出的判断。不是照着需求翻译，是在想"这个系统以后会怎么演进"。

最终落地的项目结构，47 个文件：

govclaw/├── packages/│   ├── api/                      # 后端 Express + TypeScript│   │   ├── src/config.ts         # 环境变量统一配置│   │   ├── src/middleware/       # JWT鉴权 / RBAC / 审计日志│   │   ├── src/routes/           # 6个路由模块│   │   └── src/services/         # ModelRouter（统一多模型 + SSE流式）│   └── web/                      # 前端│       └── src/│           ├── pages/            # 8个页面│           └── store/auth.ts     # Zustand 认证状态持久化


    
├── nginx/nginx.conf               # SSE 流式支持配置├── docker-compose.yml             # 7个服务一键编排└── start-dev.sh                   # 本地开发一键启动

第二步：设计

架构定了之后，是模块设计。

政务场景有特殊要求：多租户隔离、RBAC 四级权限、等保合规的审计日志，每一块都不是简单的 CRUD。我最担心的是细节会漏。

AI 的设计方案里，几个地方让我印象深：

多租户 Lane 隔离：不同部门的 Agent 数据严格隔离，请求通过 Lane 队列分流，一个部门的异常不会影响其他部门的响应。

RBAC 权限矩阵：超管 / 管理员 / 操作员 / 只读，四个层级，每个层级边界清晰，没有模糊地带。

ModelRouter 容错设计：Anthropic / OpenAI / DeepSeek / Dashscope 统一接入，任何一个模型服务不可用时自动 Fallback，调用方感知不到切换。

这些设计决策背后，是对"这个东西上线之后会遇到什么问题"的真实思考，不是对需求文档的机械翻译。

第三步：编码

设计方案确认之后，AI 开始写代码。

我没有逐行审查，我在做的事情是：提需求，确认方向，处理几个需要我判断的业务规则。

抽查了几个核心模块——JWT 中间件的边界情况（token 过期、伪造、格式错误）都处理了。审计日志的写入是异步的，不阻塞主流程。ModelRouter 的接口抽象是干净的，新增一个模型只需要实现接口，不需要改调用方。

中途出现过一次问题：AI 发现自己之前的实现偏离了 OpenClaw 的设计哲学——把 Agent 设计成了"可启动/停止的进程"，但 OpenClaw 的 Agent 根本不是进程，是"配置+身份"的集合。

它自己识别了这个偏差，重构了相关模块，然后告诉我为什么要改、改了什么、改完之后的架构更接近 OpenClaw 的原始设计。

这不是在执行指令。这是在理解系统。

第四步：测试

这一步是我最没预期会让我意外的地方。

测试通常是最容易被偷工减料的环节。很多团队的测试要么覆盖率很低，要么全是 happy path，边界情况一个没有。

AI 交出来的结果：

71 个测试，71 个通过。

覆盖率：Statements 84.32% / Branches 71.26% / Functions 90.14%，全部超过 70% 阈值。

我看了一部分测试用例，边界情况是有的：token 失效的处理、并发请求的隔离、模型服务超时的 Fallback——这些都在覆盖里。

E2E 测试覆盖了从登录到 Agent 对话的完整链路，跑完是绿的。

这不是数字好看。这是真的在测该测的东西。

第五步：文档

项目完成之后，AI 给了我两样东西。

第一是技术文档。 架构说明、模块职责、接口定义、部署步骤、环境变量配置，写得清楚，格式规整。一个新人接手这个项目，看文档能跑起来。

第二是后续迭代路线图。 分三个阶段：

P1 核心功能完善——智能体真实对话接入、知识库 RAG 管道（文档上传 → 向量化 → Qdrant 存储 → 检索召回 → 注入 Agent 提示）、审计日志中间件写入。

P2 管理能力增强——工作流可视化编辑器（React Flow 节点画布）、用户权限细化、模型监控限流（Token 用量图表 + 限额告警）。

P3 生产化——Docker Compose 一键部署、数据库迁移机制、健康检查与优雅重启、安全加固。

这不是一份完工报告。是一份真实可执行的产品路线图，下一步做什么、为什么、优先级怎么排——全都写清楚了。

我在旁边做了什么

整个过程，我做的事情是：告诉 AI 这是政务场景，需要符合等保要求。在几个业务规则上给了判断。在 AI 识别出架构偏差之后，确认了修正方向。

没有写一行代码。

以前这种事，需要一个三到五人的小团队，至少两三周：架构师出设计、工程师写代码、QA 跑测试、技术写手出文档。

现在，一个人，一天，全流程。

"会做软件"这件事变了

我说质量高，现在你知道我说的是哪个级别的高了。

不是"考虑到是 AI 做的，凑合能用"。是架构有设计判断，编码有重构能力，测试有 84% 覆盖率，文档有接手价值，路线图有执行价值。

但真正让我震动的，不是质量本身。

是这件事意味着什么："会做软件"这件事，正在被重新定义。

以前"会做软件"的门槛是什么？能写代码，懂架构，熟悉工程实践。这些能力需要多年积累。

现在呢？

会定义问题，懂判断，知道一个好的系统应该长什么样——这些能力同样重要，但门槛完全不同。

做出一个软件这件事，对"工程能力"的依赖正在快速降低，对"判断能力"的依赖正在快速升高。

这个转变，我觉得做技术的人比任何人都应该正视。

我想对技术人说的话

我没有放弃深度学习，那三年让我能清楚地看到模型的边界在哪里，什么时候该信任它，什么时候不该。

但正因为我有这个背景，我才能更清楚地说：

模型的能力，已经足够了。

对于绝大多数真实世界的问题，模型能力已经不是瓶颈。瓶颈在你会不会用，在你有没有把自己的判断和经验，转化成 AI 能执行的东西。

GovClaw 那一天，我看着 AI 一步步完成架构、设计、编码、测试、文档，有一个念头一直在转：

如果我早两年就在这个层面认真工作，我能做出什么？

我写 OpenClaw 这个系列，是因为我觉得这个问题值得让更多人来问自己。

尤其是那些花了很多年搞清楚 AI 怎么工作的人。

你们最懂这个技术。

但你们有没有认真想过，用它，你能做出什么？