几年前在深夜的夜宵摊里吃小龙虾的我，应该无论如何都想不到，今天的我会和小龙虾有如此多的羁绊。
差不多一个月没写文章了，因为在闭关开发，最近终于接近出关，单从工作量来看，成果是惊人，很快发布，大家就知道了。
果然就像我在 1 月底那一篇写的一样，真是一语成谶，世界变化得太快了。那一篇里很多的内容，包括之前关于如何使用 OpenCode 来做 Vibe Coding 的内容，确实都需要更新了。另外还是老规矩，本文的 AI 含量低于 5%，绝大多数内容是通过 Typeless 口述整理而成。
文章开头，先说一下本文的适用人群，如果你已经，或者即将是：
1. 在编排和同时使用多个 Coding Agent ，你追求的目标，就像我之前强调的，是多 Coding Agent 持续、长时间的零人工介入开发场景。
2. 你在用（能用）最强的模型（Opus-4.6 / GPT-5.3）
3. 无限 token 预算，不考虑 token 成本（因为完成目标带来的 ROI 远超 token 成本），日消耗量亿级别以上（我在项目开发期，无人值守的日消耗最高大概能到 1.2B）
恭喜你，本文是给你写的，不过我也并不是说我的流派就是唯一正确，流派很多，我也知道我的很多工作其实是可以用更低成本，更少Token 的方式实现同样的效果，但是我认为与其花时间再去想着优化成本，不如先把结果做出来，这个是更重要的。
我其实最近的实践已经从这个开发阶段，开始进入到上线运维部署的阶段了。毕竟你不可能永远在开发东西，你总是在需要在某个时间点去把你做的东西上线。而且即使在开发阶段，Agent编排方式也不太一样。
先说最大的变化，目前我已经将 OpenClaw 作为一切人机交互的入口。我相信今天其实大多数人已经在使用 OpenClaw 了，比如看看邮件，发发推，总结下新闻什么的，或者去做一些以前 Computer Use 圈子玩过的事情，这些日常工作，反正我的体验就是那几样，也没啥新鲜的。今天我主要说说我在开发领域里的龙虾经验。
很多开发者（尤其是已经用过 Claude Code 的人）会觉得，这不就是一个 Claude Code 接上一个 IM 聊天接口 + 记忆系统吗？原理上确实差不多就是这样，但千万别小看了这个改进，我觉得 OpenClaw 做对了几件事情：
1) 永续的记忆和持续的对话流
龙虾的 conversation 是一个持续对话流，不像传统 chatbot 那样“一问一答就结束”，这个交互更接近真人，而且这种持续性对大工程特别重要，尤其在一些长线和复杂任务中，全局视角是非常重要的。
虽然它目前 memory 做得仍然很糟糕，对话一 compact 就忘。但我相信这问题一定会被解决，而且能解决得很好（例如我们已经在内部的实验环境用我们自己记忆服务的 Skill 替换了原生的记忆，效果相当惊艳，不久的将来我们也会发布出来），一旦你有了长时间持续记忆，大模型的交互体验会变得完全不同。
2) 自举的 Skill 生态
我先说个爆论：
Skill 会成为几乎唯一的软件形态，分发 Skill 的渠道就是最主流的软件和服务分发渠道。
近未来一种主流软件形态大概是：SKILLS.md 作为壳，封装 CLI + Backend Service（REST API + 数据库）。用户 onboarding 不再是“装软件”，而是“给 agent 去读一个 skills.md”。
这里我最受启发的是几周前爆火 moltbook 的 onboarding 方式：直接甩 skill 的 link 给 agent，学完就接入成功，skill 中会利用龙虾的定时任务自我更新。这个体验太顺滑了，会改变很多原有假设。
当然这会引入新的安全问题（注入、权限、供应链投毒），但是在绝对的易用性面前，相信开发者生态会很快围绕这种 onboarding 方式，把问题补上，毕竟人类太懒了。
基于 SKILL 的 onboard 会改变很多事情，例如我现在在思考：账户体系还有必要吗？为什么需要账号？一个例子是 TiDB 在最新的云版本中已经开始实验加入匿名数据库实例的能力（https://zero.tidbcloud.com/），就是为了让 Agent 获得完全无缝/无限创建 DB 的 onboard 体验，我在做的新产品也是只有 Agent Onboard 的入口，主流程中放弃人类注册账号和申请 Token 的流程。
另外一个假设被改变：就是 UI 的必要性，这点大家应该深有感触，我至少已经有 1 个月没有打开过我的 Gmail 和日历，甚至服务器 Metric Dashboard 都已经很少看了，所有的一切都是直接通过龙虾从意图到结论。这就是为什么上面我提到未来的软件就是 Skill + Service ( API 太复杂的，顶多加个 CLI 本地封装下)。当然现阶段看，好看的 Landing Page 还是很重要，毕竟需要让人留下个好印象，好吸引人来把你的 Skill 复制到 ta 的 Agent 里（当然很快就会有 Agent 的 Skills network 和搜索引擎，到那个时候，就没有人类什么事情了）。
另外 Skill 是自举的，龙虾很聪明的地方是：能力拓展完全依赖 Skill，而 Skill 又可以在工作的时候通过龙虾自行生成（或者其他任意 Coding Agent），然后即时进化。
今天 Coding Agent 的 Skill 生态已经非常丰富了，而且通过 Coding Agent 动动嘴就直接生成新 Skill 。加上龙虾这种完全基于 Skill 的模式，很容易进入一个 Skill 的循环爆发：
1. 小龙虾越好用，就越多人创建 Skill。
2. 越多人创建 Skill，就会让小龙虾变得更好用。
一个完美的增长飞轮，哪怕 Skill 不是最好的抽象，在这个飞轮下，一切都不重要了，它已经成为绝对的标准了。
再次强调：如果今天你的服务和软件不是以 Skill 发布，那么就不会有未来。
2. 运行环境与人类指令的解耦
这个进化是很自然的，我认为 Computer Use 就和 Vibe Coding 一样，要么就是全自动让 Agent 完全接管，要不然就是人类你的电脑你自己用。介于中间的产品形态就会 Agent 和人都觉得别扭，这就是为什么我不看好所有的本地 Agent 形态，例如 Antigravity 和一众的所谓 AI 浏览器，都是很糟糕的 Copilot 式的产品。龙虾的体验好，就是来自于对环境的完全掌控，以至于它可以与 IM 对接，让用户在任何环境下通过 IM 远程指挥龙虾完成任何事情，这个体验和带个电脑，点开浏览器，再指挥浏览器里的 AI 干活的体验简直是一个天上一个地下。
但是今天龙虾的问题仍然很多：
1. 权限太大 + 千疮百孔的安全机制，迟早出大事，就看哪个大厂先倒霉了。但是反过来，提供安全和企业级的龙虾基础设施和最佳实践会是个大生意
2. 记忆过于重要（而且龙虾的使用模式决定了未来会越来越重要），但是当前的记忆太粗糙，而且好用的没有备份和搬家服务，不过就像我说的，无数人正在解决这个问题，当然我们也会是提供对 Agent 最友好（不对人）的记忆服务，毕竟是搞数据基础设施的，这些问题都是小问题，生态位上我们有得天独厚的 knowhow 和优势。
不过可以确定的是：一旦接受了🦞的设定和体验，传统的软件体验，那是一秒都忍不了，举个例子，由于大家都能猜到的原因，我们公司今年肯定是不会再订阅 Salesforce 了，而且就我自己的朋友圈里做出类似我们决定的企业不止我们一个，所以美股的软件股还能再跌一点，毕竟真的是回不去了。
回到开发场景，我的 Agent Team 加上龙虾后另一个变化就是我的 Github 使用量激增，Github 用量大增这几方面原因吧，在编码场景里，GitHub 本身就是一个协同平台事实标准。
前段时间我内部做了一个类似 moltbook 的多 agent协同平台，但看来看去，好像就是在重复发明 GitHub 的轮子。我在之前的文章里其实提到过，大模型的心智模型，如果在干某件事情的时候，行业已经有通用的心智模型了，你任何这种重新造轮子的尝试，最后都会变得非常别扭。还不如就去拥抱这个已有的心智模型，所以其实这里就是一个绝佳的例子。
因为 GitHub 的 gh CLI 已经非常好用，同时模型对 gh 和 GitHub 都非常熟悉，所以当你把本地的 gh 客户端配好了以后，agent 使用 GH 客户端是非常流畅的。另外，一些上线前的 CI/CD 本身 GitHub Actions 也是非常好用。目前我已经慢慢把这种上线前的回归测试，目前都全都依赖 GitHub 来跑。另外，Issue 和 PR 作为驱动 Agent 干活的 the source of truth，简单来说：
1. Coding Agent 要解决的必须是某一个 Issue
2. PR 一定也是去负责 close 某个 Issue
整个过程从需求<->写代码<->Review (多 Agent 互相 Review)<->合并代码<->上线，全程无人参与。
至于 Agent 之间的实时交互，暂时还不在 GitHub 上。但我现在想了想，用龙虾做调度以后，实时交互是否还需要另外一个平台去做，其实这还是一个问号。而且哪怕是方向性/头脑风暴式的讨论，或者一些实时的沟通，使用 GitHub Issue 好像也没有什么太大的问题，因为毕竟到最后，这些 Issue 也不会是人再去看了。
之前需要另外一个平台，是因为我需要一个全局的记忆作为类似团队记忆的平台。因为你不能把每一个具体的任务都塞到个体 Agent 的上下文里，所以需要有一个地方存档和中转。
但是因为刚才我提到，现在所有的入口都变成了“龙虾”，所以龙虾的记忆以及这些调度，其实都可以通过一只“龙虾”来完成。至于记录的工作，用 GitHub 就已经足够优秀了。
所以，之前做的一些 Agent 编排的 Infra 会大幅度地简化。这是我现在比较想尝试的方向。
最后一个话题是来自于线上的部署和运维。
大家虽然一开始觉得线上系统运维和调优还是人类的最后堡垒，但是以我最近的体验来说，首先结论是：完全不是。
实际干过部署的朋友肯定知道，当你的系统架构或者线上的部署方案稳定以后，所谓的线上运维，无非就是定期执行 Runbook，按照 Runbook 里面说的一句一句复制粘贴、执行脚本，最后上线，出了问题就按照预案 Runbook 回退，这就是日常的系统维护流程。
这种流程反而是人容易出错，所以往往需要好几个人一起去执行和反复校对。这就是为什么之前 Infrastructure as Code（IaC）和不可变基础设施的理念火过一阵。
我现在让龙虾去接管了我们整个新产品线的上线和部署（k8s），最终的结果是：
1. 目前还没出什么问题（删库跑路）
2. 上线和迭代的频次，明显比人类的时候快了一个数量级，毕竟这些“龙虾”既不会睡觉，也不会在要上线的时候找不到人。
我觉得今天如果大家要去做一个比较严肃的生产服务（抛开那些做独立开发就算了，各种 BaaS 一把梭就好了），肯定是要自己去用一些比较现代的 infrastructure，比如说像 K8s 和公有云。用过 K8s 的朋友肯定知道这个东西非常好，但最大的问题就是：
1. 需要配各种 YAML 文件
2. K8s 里面各种复杂的概念，会导致学习曲线非常陡
3. 云的各种配置尤其是IAM什么的配起来很容易出错，让人搞得很崩溃
但反而今天在 Coding Agent 看来，这些都不是问题。所以我觉得，日常的运维结合 Agent 可能才是一个更好的形态。
让龙虾去做生产部署的时候，永远要使用 Skill，不要用其他方式。
我一般的实践是：
1. 先使用 Claude Code 和它一起手动上线一遍。
2. 然后让 Claude Code 学习刚才的流程和经验，然后把刚才的这些经验生成一个 Skill。
3. 确保这个 Skill 能够被其他的 Agent 复用（这个过程其实你可以人工来确认）
4. 先从这个 Skill 开始，以后就丢给你的小龙虾，然后让他去学习。
5. 将这个全新的小龙虾配置好管理员权限以及一些必要的环境。千万不要让他安装其他的 Skill，也不要让他学习其他的 Skill，这只虾专门负责部署。然后关掉所有其他无必要的工具的权限，并在 user 里面指定有上线权限的人员，最后把他丢到开发群里。
最后对这只小龙虾设置一个定时任务，检查线上的 GitHub 相关仓库的更新情况，然后自动、持续地上线。
今天看到的一个问题是，龙虾经常会把自己给玩死。但在生产环境的部署中，如果这时候 它把自己更新死了，瓶颈全在这了，所以它其实是一个比较危险的 single point of failure。
我现在想到的解法是：
1. 准备好几个龙虾专门负责部署工作。
2. 平时主要由随便挑一个来执行。
3. 如果有人把自己玩死了，就让另外一个去干。
4. 最后保留着老的 Cloud Code，作为一个半自动上线的通道
人只负责SSO保留部署的权限，把部署token的过期时间调短，确保龙虾不会在没人授权的情况下进行部署。
最后我们再聊一聊组织架构的一些影响。
如果说一个月前还只是有担忧，现在经过这一个月，我们的组织其实已经发生了比较大的变化。首先一点，就像我在新年发朋友圈时说的，我对“慢”的耐心正在下降。
到最后你会发现，所有的瓶颈都在于与人沟通（算算你每天和人开会的时间）。如果你把 Agent Team 用得好，可能上线都完成了，而跟人的讨论还没结束。
所以我现在一个明确的感觉就是耐心越来越小，甚至觉得能跟 AI 聊完的事，就不要再跟人聊了，于是几乎不再参加任何会议，不再领导任何团队，100% 时间在和 AI 协同，我自己的体感是 1个月的产出大概是过去高水平的50人/年的水平。
我不知道大家记不记得前段时间 Anthropic，就是用 Coding Agent 重新去实现 C 编译器编译 Linux 内核。
当时网上有一堆人在嘲笑，去分析当时那个编译器的代码质量性能什么的，我个人觉得他们其实没有抓住重点。重点是在短短的 7 天之内完成了这个事情。如果基于现在的这个基础，不断去优化这个 AI Agents 的编排，然后再给他更多时间，哪怕是 14 天、24 天、34 天，我相信他的进化速度一定会让所有人闭嘴。
于是我们已经开始实践小团队，给无限的 Token 和最强的模型，然后我和 CEO 亲自带这个小团队，打破一切流程和部门墙。我想也许这就是新一代 IT 公司的标准组织架构吧。一切现有的晋升体系、组织架构、职业成长，我觉得都不复存在了。
至于未来是什么样的，我也不知道。但在今天这个时间，当你在这种绝对的速度和效率面前，任何的犹豫都是不明智的。
很难想象两年后世界会是什么模样，不过还是希望走向 Happy Ending 吧。