刘博说云

AI Coding 的危险，不是写错代码，而是让人放弃判断

Sun, 14 Jun 2026 09:44:54 +0800

这两年 AI Coding 很热，热到一种有点奇妙的程度。

以前大家写代码，哪怕是去百度、Google、Stack Overflow 找一段代码复制回来，中间至少还有一个“人”的过程。你要知道自己想找什么，要判断这段代码是不是适合当前项目，要改变量名、改逻辑、改依赖，还要在脑子里过一遍它为什么能跑。这个过程可能低效，也可能笨，但它至少让人参与了判断。

AI Coding 出来以后，这个过程被极大压缩了。很多人不再搜索，不再阅读，不再理解，而是直接说一句话，让 AI 生成。它确实带来了某种平权，让很多原本不太会写代码的人，也能快速做出一个页面、一个工具、一个小应用。甚至有人开玩笑说，文科生加上 Claude Code，就能顶一个很强的理工科毕业生。这句话当然夸张，但它背后有一个真实变化：AI 把“生产代码”的门槛降下来了。

我不否认这个变化的价值。相反，我觉得这是一次非常重要的生产力释放。AI 写代码、写材料、整理信息、生成初稿，这些都会成为未来工作的常态。今天很多公司都在讲 AI 提效，有些团队甚至会把 Token 消耗、AI 使用率、AI 生成材料占比当成一种组织效率指标。这个现象背后说明，AI 已经不只是一个工具，它开始变成组织管理和效率叙事的一部分。

但问题也正在这里出现。

当一个组织开始把“用了多少 AI”当成效率指标时，它可能已经悄悄把“有没有思考”这件事放到了后面。

AI 很擅长做确定性的事情，尤其是那些已经被大量人做过、被大量文本描述过、模式比较清楚的事情。写一个常见页面，补一个接口，生成一段 CRUD，整理一篇材料，做一个会议纪要，它都可以很快，甚至快到让人产生一种错觉：只要给 AI 足够多上下文，它就能把所有事情做完。

但真正难的事情，往往不是确定性的。

做产品尤其如此。产品经理真正有价值的地方，不是把已有答案组织得更漂亮，而是在没有标准答案的时候做判断。行业里现在没有这个东西，我们要不要做？一个看起来小众的方向，是不是未来会变大？一个用户今天说不需要的能力，是不是三个月后会变成核心诉求？一个功能眼前能带来增长，但长期会不会破坏产品结构？这些问题不是简单的信息归纳，也不是把历史经验喂给模型就能解决的。

AI 可以给你概率最高的答案，却很难替你承担那个不被大多数人相信的判断。很多时候，产品判断恰恰发生在“历史经验不够用”的地方。真正有价值的机会，常常不是从共识里长出来的，而是从少数人的不舒服、不甘心、不相信里长出来的。这个时候，人是不是还有自己的判断力，就变得非常重要。

AI Coding 也是一样。

表面上看，AI Coding 是效率工具。以前一个人一天写几百行代码，现在可能一天生成几千行、几万行代码；以前一个需求要做几天，现在可能几个小时就有一个版本。团队的 Token 消耗上去了，提交量上去了，功能数量上去了，周报也变好看了。可问题是，这些代码真的被理解了吗？真的被 review 了吗？真的能长期维护吗？

我最近和一些公司、一些团队聊 AI Coding 的使用情况，一个非常真实的反馈是：AI 写出来的代码太多了，很多人已经没时间认真看了。代码评审当然还在，UT 当然也在，E2E 也可以让 AI 自己补，但当一天可能生成十几万行、几十万行代码的时候，人很容易从“评审者”变成“批准者”。他不再真正理解代码，而是在流程上点头。

这时候风险就开始变形了。

过去代码风险大多来自人写错了。现在代码风险可能来自人没看懂 AI 写了什么，却以为流程已经保证了质量。更麻烦的是，AI 非常擅长制造一种“看起来合理”的完整性。它会写注释，会补测试，会解释为什么这样设计，会把一个错误包装得很像工程决策。人如果没有足够强的判断力，很容易被它说服。

我见过一些很典型的问题。比如 A 做完一个功能，B 用 AI 改另一个功能时顺手把 A 的逻辑改坏了，但 B 只验证了自己的路径，于是代码就被推上去了。再比如 AI 在代码里写了一段看似解释性的注释，后续生成 E2E 或 UT 时，另一个 AI 又把这段注释当成事实依据，反过来为错误逻辑补上了测试。更极端一点，一个付款流程里如果出现“超时则默认成功”这种兜底逻辑，AI 甚至可能把它解释成“为了提升用户体验的优化方案”。如果测试也是 AI 写的，评审也是 AI 辅助看的，最后这个错误就会在一层层“合理化”里被放过去。

这才是 AI Coding 真正危险的地方。

它不是让错误变少，而是让错误更像正确答案。

以前一段糟糕代码，可能一眼就能看出很糙。现在 AI 生成的代码往往结构完整、命名合理、注释清晰、测试齐全，甚至文档都写得像模像样。它不再像一个明显的半成品，而像一个可以被交付的东西。可越是这样，人越容易放松警惕。因为我们的大脑很容易被完整性欺骗：一个东西看起来像工程产物，我们就默认它经历了工程判断。

但 AI 没有工程责任感。

它不知道这个功能上线后谁来背锅，不知道这个漏洞会不会影响客户数据，不知道这个页面是不是符合长期产品结构，不知道这段代码三个月后有没有人能维护。它只是在当前上下文里生成一个看起来最合理的结果。如果上下文错了，它会沿着错误继续生成；如果注释错了，它可能把注释当成规则；如果测试目标错了，它会为错误目标写出通过的测试。

所以我觉得，现在很多团队在使用 AI Coding 时，最需要警惕的不是“AI 写得不够快”，而是“人退得太快”。

当后端同学可以用 AI 快速改前端，产品同学可以用 AI 快速写脚本，运营同学可以用 AI 快速生成工具，这当然是进步。但如果所有人都能提交代码，原先依靠角色分工、代码熟悉度、模块边界建立起来的质量体系，也会被重新冲击。以前一个前端项目可能就几个人长期维护，每周发布几个功能，大家知道谁改了哪里。现在可能十几个人、几十个人都能借助 AI 往里面加东西，一周堆出几十个功能，代码量膨胀得很快。只要有一两个人没有理解规范，或者只是相信 AI 已经处理好了，整个系统的风险都会被放大。

这不是某个人懒，也不是某个团队不专业，而是生产方式变了以后，治理方式还没有跟上。

AI Coding 把代码生产平权了，但没有自动把工程责任平权。不是每个能生成代码的人，都理解架构边界、权限边界、安全边界和发布边界。不是每个能让 AI 补测试的人，都知道测试有没有覆盖关键路径。不是每个能让 AI 修 bug 的人，都知道它有没有引入另一个更隐蔽的问题。

更深一层看，这里面还有一个很有意思的变化：未来可能会出现越来越多“AI 写给 AI 看”的东西。

AI 写需求文档，AI 写技术方案，AI 写代码，AI 写测试，AI 做评审，AI 生成上线说明，AI 总结问题复盘。整个链路看起来非常自动化，非常高效，但如果人在里面只剩下审批、转发和确认，那么这个系统到底是在服务人，还是在绕开人？

这不是一个哲学问题，而是一个非常现实的产品问题。

我们做一个阅读网站，是给人阅读，还是给 AI 阅读？我们做一个视频网站，是给人观看，还是给 AI 消费？我们做一个 APP，是给人使用，还是给指标使用？今天大多数软件最终还是给人用的。人的感受、人的困惑、人的误操作、人的审美、人的信任，仍然决定了一个产品是不是真的成立。

如果一个系统从需求到实现都越来越由 AI 生成，而人没有在关键环节进行判断，那么它可能会越来越像“逻辑上成立的产品”，但不一定是“人真的愿意使用的产品”。

代码也是一样。代码不是写完就结束了，代码是要运行、要维护、要被排查、要被扩展、要承担真实后果的。AI 可以帮我们加速生产，但它不能替我们承担后果。一个安全漏洞不会因为是 AI 写的就少造成损失，一个错误付款逻辑不会因为有测试就变得合理，一个用户体验问题不会因为 PRD 写得漂亮就不存在。

所以我不太喜欢把 AI Coding 简单理解成“让每个人都变成程序员”。这个说法听起来很热血，但它容易遮蔽一个更关键的问题：AI Coding 真正需要的不是人人都会写代码，而是人人都要重新学习如何驾驭生成出来的东西。

驾驭 AI，不是会写 Prompt。会写 Prompt 只是很小的一部分。真正的驾驭，是你知道什么时候该相信它，什么时候该怀疑它；知道哪些事情可以交给它，哪些事情必须自己想；知道它生成的结果在哪里最容易出问题；知道如何设计边界，让它即便犯错，爆炸半径也是可控的。

这对个人是挑战，对团队也是挑战，对平台更是机会。

未来 AI Coding 一定会继续发展，AI 写材料、写代码、写测试、写方案也都会越来越普遍。阻止它没有意义，否定它也没有意义。真正重要的是，我们要为这个新的生产方式建立新的质量体系。代码量暴涨以后，传统 review 方式可能不够了；AI 生成代码以后，传统测试方式可能不够了；更多非研发角色参与应用生产以后，传统权限和发布流程也可能不够了。

这里面有一个很重要的判断：未来 AI Coding 真正的基础设施机会，不只是代码生成，而是安全执行环境。

因为未来的问题不只是“AI 能不能写出代码”，而是“AI 写出来的代码应该在哪里运行”。如果 AI 生成的是一个页面、一个脚本、一个爬虫、一个内部工具、一个自动化 Agent，它天然就可能访问文件、网络、数据库、密钥、企业 API，甚至可能对真实业务系统产生影响。这个时候，把 AI 生成的代码直接放进生产环境，或者直接在个人电脑、企业内网里运行，本质上都是高风险行为。

过去我们讨论安全，更多是在代码写完之后做扫描、审计和发布卡点。但 AI Coding 时代，代码生成速度太快，参与角色太多，传统安全流程很容易跟不上。更现实的做法，是默认把 AI 生成代码放在一个受控的执行环境里：权限最小化，网络可限制，文件系统可隔离，密钥不可直接暴露，调用外部接口要被审计，高风险动作要有人确认，运行过程要可观测，出现异常时能快速停止和回滚。

不是先假设 AI 生成的代码可信，而是先假设它不可信，然后给它一个可控的运行边界。

这个安全执行环境，未来可能会成为 AI Coding 平台、Agent 平台、Serverless 平台非常重要的竞争力。谁能让 AI 生成的代码更快地运行起来，同时又把风险收敛在一个可控范围内，谁就更有机会成为企业愿意采用的应用生产入口。因为企业最终不会只为“生成得快”买单，它真正需要的是：生成得快，但不要把系统搞坏；交付得快，但不要泄露数据；试错得快，但不要让错误扩散到不可收拾。

所以，接下来真正有价值的能力，不只是让 AI 更会写，而是让 AI 写出来的东西更可控。比如生成代码前能理解项目边界，生成过程中能遵守架构约束，生成之后能做安全扫描、依赖分析、权限检查、测试覆盖评估、运行时隔离和灰度验证。更进一步，平台要能识别哪些代码是 AI 生成的，哪些逻辑来自用户明确要求，哪些逻辑来自模型推断，哪些地方缺少人工确认，哪些变更可能影响已有用户路径。

这些能力听起来不如“十倍效率”刺激，但它们决定 AI Coding 能不能从个人玩具变成企业生产力。

我一直觉得，AI 时代最危险的不是人用 AI，而是人误以为自己已经掌控了 AI。

一个人如果很清楚 AI 的边界，AI 会成为非常强的放大器。它可以帮你更快试错，更快搭原型，更快生成材料，更快验证想法。但如果一个人并不理解自己要做什么，也不理解 AI 生成了什么，只是因为 AI 很快、很完整、很自信，就把判断权交出去，那么 AI 放大的就不是能力，而是混乱。

所以回到最开始那个问题：到底是人在驾驭 AI，还是 AI 在驾驭人？

我的答案是，短期内两种情况都会发生。会驾驭 AI 的人，会比以前更强；不会驾驭 AI 的人，可能会比以前更危险。因为过去不会写代码，最多是写不出来；现在不会判断，却可以生成很多看起来能跑的代码。过去一个人能力不足，产出有限；现在一个人判断不足，却可能借助 AI 快速制造大量风险。

这也许才是 AI Coding 时代最值得警惕的地方。

它让生产变快了，但没有让判断自动变强。它让更多人拥有了创造软件的能力，但没有让更多人天然拥有工程责任。它让代码看起来更完整，但也让错误更容易隐藏在完整性里面。

AI Coding 的未来一定很大，但越是这样，我们越应该认真面对它带来的另一面：效率不是免费的，自动化也不是免费的。所有被 AI 加速的东西，最终都需要被人、被流程、被平台、被组织重新接住。

否则我们很可能会看到一个很荒诞的局面：大家每天消耗越来越多 Token，生成越来越多代码，写出越来越多材料，做出越来越多应用，但真正理解这些东西的人越来越少，真正敢为这些东西负责的人也越来越少。

那就不是提效了。

那是把思考外包以后，留下了一地看起来很高效的风险。

AI Coding 的终点不是写代码，而是应用生产入口

Tue, 09 Jun 2026 08:44:12 +0800

最近遇到一个很典型的场景。

一个运营同学想快速做一个文章生成 Agent。这个 Agent 并不是简单地“你说一句话，它回一篇文章”，而是一套完整的工程逻辑：先追踪热点和灵感，再去抓取网站和媒体内容，拿到素材后判断是否和主题相关，然后筛选、保留、整理，再进一步生成大纲，最后产出文章。

这件事看起来是“做一个 Agent”，但往下拆就会发现，它其实已经是一个小型应用。它有前端交互，有后端逻辑，有爬虫能力，有内容筛选，有模型调用，有任务编排，也有最终的结果生成。对于一个不懂代码的人来说，他可以通过 Agent 平台快速搭出一个想法，但很快就会遇到真正的门槛：自定义工具怎么做，怎么部署到云上，怎么让别人访问，怎么配置域名，怎么保证安全，怎么控制权限，代码如果有漏洞，爆炸半径怎么控制。

后来我们推荐他用 AI Coding 工具。他在本地通过自然语言生成了一个前后端一体的项目。虽然他自己不懂代码，但这个项目确实能跑，效果也看起来不错。

但新的问题马上出现了：这个东西怎么从“本地能跑”，变成“别人能用”？

这就是我现在越来越确信的一件事：AI Coding 的终点不是写代码，而是应用生产入口。

代码只是材料，应用才是结果。用户真正要的不是一个代码目录，而是一个可以被访问、被使用、被迭代、被管理的系统。尤其对非研发用户来说，他并不关心什么前端、后端、依赖、端口、环境变量、镜像、函数、网关。他只会关心：这个东西能不能上线，别人能不能用，出问题会不会炸，后面还能不能继续改。

过去我们评价 AI Coding，常常看它能不能补全代码、生成项目、修复 Bug、理解框架。这些当然重要，但它们只是第一阶段。真正的断点不在“生成”，而在“生成之后”。如果 AI Coding 只能把代码生成出来，但不能把代码变成一个可分享、可运行、可治理的应用，那么它解决的是局部效率，而不是应用生产。

从意图到代码，只是 AI Coding 的上半场；从代码到生产，才是它真正决定产品位置的下半场。

过去应用生产的入口大多在代码之后。开发者先写代码，再提交仓库，再进入构建、部署、测试、发布、运维。云平台、CI/CD、Serverless、容器平台，基本都建立在一个前提上：用户已经有代码，平台负责让代码跑起来。

但 AI Coding 改变了这个前提。用户不是从代码开始，而是从意图开始。他说“帮我做一个文章生成 Agent”，AI Coding 就有机会把这个意图转成代码、页面、后端接口和调用逻辑。也就是说，应用生产的入口从“代码仓库之后”，前移到了“用户表达意图的那一刻”。

这个变化非常大。因为谁接住了用户意图，谁就有机会定义应用结构；谁定义了应用结构，谁就有机会决定运行方式；谁掌握了运行反馈，谁就能反过来优化下一次生成。

所以 AI Coding 不只是 IDE 里的助手。它如果继续向前走，本质上会变成一个应用生产工作台：从用户意图开始，生成应用，部署应用，运行应用，再根据运行结果持续修改应用。

最后一公里不是 Deploy

很多人会把这个问题简化成“部署”。好像 AI Coding 生成代码之后，只要加一个 Deploy 按钮，就解决了最后一公里。

但这个理解还是太浅了。

真正的最后一公里，不只是把代码部署到线上，而是把一个 AI 生成的、不确定的、本地可运行的项目，变成一个生产可用的应用。这里面不仅有域名、访问入口、构建、运行时、环境变量、密钥、网络和依赖，还有日志、监控、异常诊断、权限、成本、灰度、回滚和安全隔离。

对于传统研发来说，这些是工程常识；但对于 AI Coding 的新用户来说，这些都是不可见的门槛。

更关键的是，这些门槛不应该继续完全交给用户。如果 AI Coding 只服务资深开发者，它可以说“代码我生成了，后面你自己部署”。但如果 AI Coding 要面向更多业务用户、运营同学、产品同学、企业员工，那它就必须把生产化链路一起承接起来。

AI Coding 的下一阶段，不是生成更多代码，而是把生成出来的代码变成可生产的应用。

这也是为什么我觉得“本地能跑”会成为一个很有意思的中间状态。它证明 AI Coding 已经把意图转成了可执行项目，但它还没有完成价值交付。真正的价值交付发生在别人能访问、能使用、能持续迭代，并且这个应用的风险在平台可控范围内。

如果没有这一步，AI Coding 只是把“不懂代码的人不会写代码”变成了“不懂代码的人有一堆不知道怎么上线的代码”。这当然已经有价值，但还远远不是终点。

安全会成为 AI Coding 向上走的核心机会

这里面最重要的问题，是安全。

现在很多人都在用 AI Coding 写工具、写脚本、写小应用。但 AI 写出来的代码到底安不安全？有没有依赖漏洞？有没有把密钥写死？有没有越权访问？有没有注入、任意文件读写、网络访问失控？有没有无限循环、成本失控、异常没有兜底？

这些问题在传统软件工程里就存在，但 AI Coding 会把它们放大。因为 AI Coding 降低了生成应用的门槛，也会降低风险进入系统的门槛。过去一个不懂代码的人很难写出一个能联网、能爬虫、能调用模型、能部署上线的应用；现在他可以通过 AI Coding 做出来。能力被释放的同时，风险也被释放了。

所以未来 AI Coding 平台一定要回答一个更本质的问题：AI 生成的代码，如何被安全地运行？

这不是简单的代码扫描问题，而是一整套安全运行问题。平台需要默认假设生成代码是不可信的，然后通过沙箱、最小权限、网络出口控制、依赖检查、密钥隔离、运行时策略、访问审计和资源限额，把风险控制在可接受范围内。

换句话说，AI Coding 需要一套生产化安全缓冲层。用户可以大胆生成，但平台必须谨慎运行；用户可以快速试错，但平台必须控制爆炸半径；应用可以被分享给别人，但权限、数据、访问和成本不能失控。

AI Coding 真正进入生产，不是因为它更会写代码，而是因为它能让不可靠的生成过程，进入一个可靠的运行边界。

这会是非常大的平台机会。

AI Coding 还会带来另一个更深的变化：应用会变多。过去应用是相对稀缺的，一个团队做一个应用，要排期、开发、测试、上线，生命周期相对长，数量也相对可控。但 AI Coding 会让应用变得更碎片化、更场景化、更临时。一个运营同学可以为了某个选题生成一个文章 Agent，一个数据同学可以为某个报表生成一个分析工具，一个产品同学可以为某个流程生成一个小助手，一个团队可以为某个临时项目生成一个内部应用。

这些应用不一定都大，也不一定都长期存在，但数量会非常多。

当应用数量变多以后，真正的问题就不再是能不能生成，而是生成之后怎么治理。如果没有统一入口，这些应用很容易变成新的影子 IT：创建者、使用者、访问数据、风险边界、下线机制、责任归属都会变得模糊。

所以我觉得未来企业级 AI Coding 的关键，不只是让每个人都能生成应用，而是让组织能管理这些被生成出来的应用。

AI Coding 会让应用生产民主化，但应用治理必须平台化。

如果只做前者，企业会获得短期效率，也会获得长期混乱；如果能把后者做好，AI Coding 才有机会真正进入组织级生产系统。

这对云厂商和 Infra 团队也是一个很强的信号。过去 Infra 的位置往往在代码之后：用户有代码，我提供构建；用户有镜像，我提供部署；用户有服务，我提供监控；用户有流量，我提供弹性。但 AI Coding 把入口推到了用户意图侧。如果 Infra 还只是等着被调用，就会越来越被动，因为用户心智会被更靠近意图的产品拿走，底层平台会变成水电煤。

所以 Infra 必须向上走。

Serverless、容器、数据库、存储、模型服务、网关、安全、观测，这些能力不能只是孤立地等待配置，而应该被 AI Coding 的应用生产链路自然调用。用户生成一个应用时，平台应该自动理解它的运行形态、依赖关系、权限边界、数据连接、部署方式和观测策略。

这不是简单地把云资源接进 AI Coding。更准确地说，是把 Infra 变成 AI 应用生产闭环的一部分。

未来的 Infra 不应该只回答“代码如何运行”，而要回答“应用如何可靠地产生结果”。

Serverless 在这里会有天然机会。大量 AI Coding 生成的小应用、小工具、小 Agent，并不适合一开始就进入复杂集群。它们更需要快速部署、按需运行、弹性伸缩、低运维、可观测、可回滚。Serverless 很适合作为这类应用的默认运行底座。

但 Serverless 也不能只做部署目标。它必须向上承接安全、依赖、权限、日志、成本、异常修复和运行反馈。否则入口仍然会在 AI Coding 工具手里，Serverless 只是一个被调用的后端资源。

我不太相信 AI Coding 的未来只是一个更聪明的 IDE。IDE 是给开发者写代码的地方，但未来 AI Coding 的用户不一定都是开发者。很多用户并不想“写代码”，他们想解决问题。代码只是 AI 在解决问题过程中生成的中间材料。

所以更准确地说，AI Coding 的未来形态，可能是一个应用生产系统。它从用户意图开始，生成应用结构，补全代码，实现功能，连接模型、工具、数据和云资源，然后进入部署、运行、观测、安全和反馈。它不是一次性生成，而是持续迭代；不是只管理代码，而是管理应用资产；不是只关注本地能跑，而是关注线上可用、风险可控、组织可管。

这里的关键不是全自动。企业级场景里，很多应用仍然需要人审核，需要研发把关，需要安全团队介入，需要平台策略约束。AI Coding 不会消灭软件工程，反而会把软件工程里的很多隐性环节显性化、平台化。

所以成熟的 AI Coding，不应该追求“一句话到万能应用”的童话，而应该追求“从一句话到可控生产过程”的系统能力。

AI Coding 的长期战场，不在谁写代码更快，而在谁能把用户意图稳定地转化为可运行、可治理、可持续优化的应用。

那个运营同学的例子很典型。他不是想学习代码，也不是想理解部署。他只是想把一个文章生成 Agent 做出来，让别人能用，并且安全、稳定、可持续迭代。

这类需求未来会越来越多。

谁能把这类需求从意图接到应用，从本地接到线上，从生成接到治理，谁就有机会成为下一代应用生产入口。

AI Coding 的终点不是写代码。

它的终点，是重新定义应用如何被生产。

Serverless 没有死，它只是在等 AI

Sat, 06 Jun 2026 15:21:36 +0800

过去几年，很多人都问过一个问题：Serverless 到底是不是没起来？

这个问题很难回避。

如果只看声量，Serverless 确实没有像 Kubernetes 那样成为基础设施世界的显学；如果只看国内落地，它也很难说已经成为企业应用的默认选择；如果只看开发者习惯，大多数人依然更熟悉 ECS、容器、K8s、传统微服务，而不是一上来就选择函数、事件、托管运行时。

所以我不太喜欢强行说“Serverless 一直很好”。这种说法没有意义，也不真诚。

更真实的判断是：Serverless 一直有价值，但过去缺少一个足够强、足够自然、足够高频的应用场景。

它不是没有能力。弹性、免运维、按量付费、事件驱动、快速部署，这些能力都很好。但问题是，在过去很多传统应用场景里，这些能力并不足以让开发者改变习惯。

一个 Web 应用，用容器也能跑。一个后端服务，用微服务也能跑。一个企业系统，用传统云主机也能跑。当原来的方式“也能跑”的时候，新架构就必须给出非常强的迁移动机。可惜在很长一段时间里，Serverless 给出的动机并不总是足够强。它解决了一些问题，但也带来了新的理解成本、调试成本、生态成本和架构迁移成本。

所以 Serverless 过去最大的问题，不是技术不成立，而是场景不够锋利。

直到 AI 出现。

Serverless 等到的不是热点，而是应用形态的变化

AI 的出现，和过去很多技术热点不一样。

它不只是多了一个能力，也不只是多了一类 API，而是在改变应用的生产方式、运行方式和交付方式。

过去的应用，大多是人先设计，人写代码，人部署，人运维。应用形态相对稳定，流量相对可预期，架构边界也相对清楚。但 AI 应用不是这样。一个 AI 应用可能今天只有几十次调用，明天因为一个活动突然暴涨；一个 Agent 任务可能上一秒在调用模型，下一秒在调用工具，再下一秒要进入沙箱执行代码；一个 AI Coding 工具生成出来的应用，用户不想先学部署，也不想先配置基础设施，而是希望它立刻跑起来。

这意味着，AI 应用天然具有几个特征：动态、碎片化、事件驱动、任务化、异步化、成本敏感，并且强依赖运行时治理。

而这些特征，几乎全部踩在 Serverless 的能力边界上。

AI 应用天然需要弹性，天然需要事件驱动，天然需要异步任务，天然需要工具编排，天然需要沙箱执行，天然需要低门槛部署，也天然需要按使用量控制成本。

这就是为什么我越来越觉得：Serverless 终于熬到了 AI。

这里的“熬到”不是说 Serverless 什么都不用做，等风来就行。恰恰相反，它意味着过去那些看起来“有价值但不够必然”的能力，终于遇到了一个更自然的应用范式。

过去 Serverless 要说服开发者“把原来的应用迁过来”。
现在 Serverless 有机会承接“AI 原生应用一开始就这样运行”。

前者是迁移，后者是默认。

真正的机会，往往出现在默认选择发生变化的时候。

Agent 让 Serverless 重新回到应用运行层

尤其是 Agent。

很多人一开始把 Agent 理解成聊天框，或者理解成 Prompt 加工具调用。但真正进入产品和企业场景后会发现，Agent 不是一个对话界面，而是一套任务执行系统。

它要理解意图、规划步骤、调用工具、访问知识、执行代码、处理异常、记录状态，最后把结果返回给用户。这里面很多动作都不是持续运行的，而是按需触发、短时执行、动态组合。它不是传统意义上长时间在线的服务，更像是一组不断被激活、被编排、被观测、被恢复的任务。

这正是 Serverless 擅长的地方。

工具可以是函数，沙箱可以是弹性运行环境，任务可以是异步工作流，AgentLoop 可以是托管运行时，观测可以围绕每一次模型调用、工具调用和执行链路展开。Serverless 不再只是“部署函数”，而是可以承接 Agent 从开发、部署、执行到治理的一整套运行链路。

Agent 让 Serverless 从资源层，重新回到了应用运行层。

这件事很关键。

过去 Serverless 很容易被理解成“更轻的计算资源”，或者“事件驱动的小函数”。这个理解没有错，但太窄了。AI 时代的 Serverless，应该更像 AI 应用运行时。它不只是回答“这段代码怎么跑”，而是回答“这个 AI 任务如何安全、稳定、低成本、可观测地完成”。

这两个问题完全不一样。

前者是执行问题。
后者是生产问题。

如果 Serverless 仍然只回答前者，它会继续被看成一种底层能力；如果 Serverless 能回答后者，它就有机会重新变成应用入口。

AI Coding 会把 Serverless 推到更前面

AI Coding 也是同样的逻辑。

AI Coding 的终点不会只是写代码。代码只是中间产物，应用才是结果。未来用户在 AI Coding 工具里说一句“帮我做一个内部知识库助手”，系统不应该只生成几份代码文件，而应该继续完成部署、运行、权限、日志、监控、成本和安全检查。

这时候，Serverless 的价值会变得非常直接：它可以成为 AI Coding 生成应用后的默认运行底座。

用户不需要先买机器，不需要先理解容器，不需要先配置复杂集群。应用生成出来，就能被托管、被运行、被观测、被治理。对于大量中小型 AI 应用、临时任务、内部工具、自动化流程、Agent 工具函数来说，这会是非常自然的选择。

更重要的是，AI Coding 会显著提高应用生产的频率。

过去一个团队可能一个月写几个服务。未来，一个人一天可能生成很多小应用、小工具、小 Agent。应用数量上来以后，传统部署和运维方式一定会被压力打穿。不是因为它不能做，而是因为它太重了。

AI 生成应用的速度越快，运行平台就越需要自动化、弹性化、低门槛和强治理。

这正是 Serverless 应该站出来的位置。

但这里也有一个前提：Serverless 不能只做“部署目标”。如果 AI Coding 生成出来的代码质量不稳定，权限边界不清楚，依赖可能有漏洞，异常处理不完整，成本控制缺失，平台只是把代码跑起来，那风险仍然留给用户。

所以未来 Serverless 的机会，不只是让 AI 生成的应用跑起来，而是让它更可靠地进入生产。

AI 生成代码带来了不确定性，Serverless 应该负责消化这种不确定性。

这可能是 Serverless 下一阶段最重要的产品价值。

Serverless 不能只做水电煤

过去云计算很多基础设施，最后都会有一种风险：越来越像水电煤。重要、稳定、不可缺少，但离用户心智越来越远。

Serverless 也有这个风险。

如果它只提供函数、触发器、日志、网关、弹性、计费，那么它当然有价值，但这个价值会越来越底层。用户真正感知到的，可能是上层 AI Coding 工具、Agent 平台、模型平台，而不是 Serverless 本身。

所以 Serverless 必须向上走一层。

这层可能叫 AI Application Runtime，可能叫 Agentic Infra，也可能暂时没有统一名字。但它要解决的问题很明确：把 AI 生成的代码、Agent 的工具调用、企业的知识和权限、云上的运行资源，连接成一个可生产、可治理、可持续优化的闭环。

这也是过去 Serverless 没有完全做透的地方。

过去我们习惯从资源和运行时视角理解 Serverless：我给你弹性，我给你函数，我给你事件，我给你按量计费。但 AI 时代，用户不再只是问“我能不能跑一个函数”，而是问“我能不能把一个 AI 应用安全、稳定、低成本地跑起来”。

这个问题里包含了很多新的能力：模型调用治理、工具执行治理、沙箱隔离、生成代码安全、依赖扫描、权限建议、灰度发布、回滚、链路追踪、成本预警、异常诊断、上下文管理。

这些能力单独看都不新，但组合在 AI 应用生产链路里，会变成一个新的平台位置。

未来 Serverless 的价值，不只是免运维，而是 AI 应用的运行闭环。

Serverless 的第二次机会

我觉得 Serverless 至少有过两次机会。

第一次机会，是云原生时代大家对弹性和免运维的期待。但那时候应用形态还没有发生根本变化，Serverless 更多是在和容器、微服务、传统部署方式竞争。它有优势，但不是所有场景都非它不可。

第二次机会，是 AI 时代应用生产方式变化之后，Serverless 不再只是替代某种部署方式，而是成为新应用形态的天然底座。

这两者的区别很大。

过去 Serverless 是“能不能替代原来的运行方式”。
现在 Serverless 是“能不能成为 AI 原生应用的默认运行方式”。

前者需要迁移成本说服，后者靠新场景自然发生。

这也是为什么我说 Serverless 没有死。它只是没有在最早期待它爆发的时候爆发。很多技术都是这样。它们不是没有价值，只是一直没有遇到那个能把价值放大的场景。

而 AI 正在成为这个场景。

AI 让应用变得更动态，Serverless 负责承接动态。
AI 让代码生成更快，Serverless 负责快速运行和治理。
AI 让 Agent 需要工具和沙箱，Serverless 负责弹性执行。
AI 让成本和安全更不可控，Serverless 负责把不确定性收敛。

如果说过去 Serverless 的关键词是“免运维”，那么未来 Serverless 的关键词可能会变成“AI 应用运行闭环”。

Serverless 自己也必须变化

当然，Serverless 不能只是站在原地等 AI。

它必须变。

它不能只强调弹性和免运维，也不能只做函数、触发器、日志这些基础能力。未来的 Serverless 至少要更懂 AI 应用：懂模型调用，懂工具执行，懂 AgentLoop，懂沙箱，懂权限，懂上下文，懂成本，懂安全，懂生成代码的可靠性。

尤其是安全和稳定性。

AI 生成代码的质量并不总是可靠。它可能能跑 Demo，但不一定能进生产。权限可能过大，依赖可能有漏洞，异常处理可能缺失，成本控制可能没有，日志和观测也可能不足。如果平台只是把 AI 生成的代码部署上去，那风险仍然留给用户。

但如果 Serverless 平台能在生成代码和生产运行之间多做一层，提供依赖扫描、权限建议、运行隔离、灰度、回滚、可观测、成本预警、异常诊断，那它就不只是部署平台，而是 AI 应用的信任层。

未来 Serverless 的价值，不只是让应用跑起来，而是让 AI 生成的不确定性变得可控。

这件事会非常重要。

因为 AI 时代不是应用变少，而是应用变多；不是部署变少，而是部署变频繁；不是运维不需要了，而是运维要被更深地自动化和平台化。

Serverless 如果能接住这件事，就会重新站到应用生产链路的关键位置。

最后的判断

所以我现在对 Serverless 的判断，比过去更坚定，也更克制。

我不认为 Serverless 已经赢了。它过去确实没有完全跑出来，也确实被很多开发者绕开。它有自己的问题：调试体验、状态管理、生态心智、工程习惯、冷启动、复杂应用组织方式，这些都不是靠一句“免运维”就能解决的。

但我也不认为 Serverless 死了。

恰恰相反，AI 让 Serverless 的价值重新变得具体了。

过去 Serverless 讲的是一种更优雅的云上运行方式；今天它有机会变成 AI 应用、Agent、AI Coding 生成应用的默认运行底座。过去它更多服务开发者部署函数；未来它可能服务的是 AI 生成应用后的完整生产闭环。

这才是最大的变化。

Serverless 的未来，不在于证明它比容器更好，而在于证明它是 AI 原生应用更自然的运行方式。

它不需要再和过去的应用形态硬碰硬。

它需要抓住新的应用形态。

Agent、AI Coding、工具调用、沙箱执行、异步任务、事件驱动、自动部署、成本治理、安全隔离，这些东西放在一起，正在重新定义应用如何被生产、如何被运行、如何被管理。

而 Serverless，恰好站在这条路上。

所以 Serverless 没有死。

它只是一直在等 AI。

而现在，它终于熬到了。

Agent 记忆的分水岭：不是 Markdown，不是向量库，而是上下文治理

Fri, 05 Jun 2026 18:40:16 +0800

最近 Agent 记忆很热。

热到很多框架、产品、MCP Server 都开始说自己有 memory。有人把记忆写进 Markdown，有人接向量库，有人做本地文件，有人做云端服务，有人做图谱，有人做 summary。表面上看，好像只要提供 add_memory、search_memory、update_memory、delete_memory，Agent 就拥有了长期记忆。

但我越来越觉得，行业里很多关于记忆的讨论，其实还停留在很浅的一层。

把信息存下来，不等于 Agent 拥有了记忆。

能检索出来，也不代表这段信息应该进入当前上下文；能被模型总结，也不代表它应该成为长期事实；能通过 MCP 暴露出去，也不代表它在安全、权限、并发、回滚、审计上已经准备好了。

真正难的不是“记忆放在哪里”，而是这段信息在未来到底应该如何影响 Agent 的行动。

所以我现在对记忆最核心的理解是：

Agent 记忆不是存储系统，而是一套面向未来行动的上下文治理系统。

记忆不是为了保存过去

我以前比较固执地认为，把用户所有信息完整保存下来，就是最好的记忆。因为全量、可追溯、不丢失。只要原文还在，未来不管发生什么，都可以回到原始现场重新判断。

这个想法到现在我也不认为完全错。原始历史非常重要，因为它是事实来源。没有原始历史，所有摘要、标签、偏好、画像、经验，都会变成不可追溯的二手信息。一旦总结错了、漏了、过期了，系统后面的判断都会建立在不可靠的基础上。

但全量保存不等于有效记忆。

如果一切都只是原始历史，那系统本质上只是一个日志仓库。它保留了过去，却没有真正回答：过去的哪一部分，应该在未来哪个场景里重新影响 Agent 的判断？

用户真正需要的，也不是 Agent 告诉他“我保存了你所有历史”，而是在下一次任务中少解释一次背景，少重复一次偏好，少踩一次之前踩过的坑。

所以，记忆的目的不是保存过去，而是让未来的行动更可靠。

如果一段信息不会影响未来判断，它只是日志；如果一段信息可以被查询但不会进入任务决策，它更像资料；只有当一段信息会影响 Agent 未来回答、工具调用、任务路径或权限判断时，它才真正进入了记忆系统。

这也是记忆比知识库更敏感的原因。

知识库回答的是“世界是什么”。它通常来自文档、制度、API 说明、产品手册、业务资料。知识库可以离线处理，可以切片、索引、摘要、结构化。哪怕处理慢一点，很多时候也能接受。

记忆回答的是“我们经历过什么”。它来自对话、任务执行、工具调用、失败恢复、用户偏好、项目决策和上下文迁移。它是动态产生的，而且经常刚产生就要被使用。

知识库错了，往往是一次回答查错资料；记忆错了，可能会让 Agent 在未来很多次任务里持续带着错误理解行动。尤其当这条记忆被包装成“用户偏好”“项目约束”“组织经验”之后，模型会天然更愿意相信它。

错误记忆比没有记忆更危险。

没有记忆时，Agent 至少会问；错误记忆生效后，Agent 会自信地错。

全量记忆和汇总记忆不是二选一

关于记忆，最容易争论的一点是：到底应该全量保存，还是应该压缩汇总？

我过去更偏全量保存，因为全量意味着可追溯，意味着不提前判断什么重要，意味着未来问题发生时还有机会重新回到现场。尤其在 Agent 场景下，未来的信息需求很难预测。今天看起来不起眼的一句话，可能后天就是某个任务的关键约束。

但只做全量也有问题。全量历史越积越多，检索成本会上升，上下文会变脏，模型会被无关信息干扰。更重要的是，原始历史本身没有替你完成抽象。它保留了事实，却没有告诉你状态有没有变化、偏好是否稳定、某个结论是不是已经被推翻。

所以我现在更倾向于一个分层答案：

原始记忆解决可信和追溯，汇总记忆解决效率和可用，结构化记忆解决推理和治理。

原始历史应该尽量保留，因为它是事实来源；摘要和汇总可以生成，但不能替代原文；结构化信息很有价值，但它应该带着来源、版本和可信度，而不是变成不可追溯的新事实。

这件事很像代码里的 source of truth。原始记忆是 source，摘要、画像、偏好、经验都是 view。View 可以被加速、被索引、被优化，但不能反过来把 source 覆盖掉。

如果只有原始历史，系统会笨。
如果只有摘要汇总，系统会危险。
如果只有结构化结论，系统会僵硬。

好的记忆系统应该允许三者共存，并在不同场景下选择不同层次的信息。当前任务需要保真，就回原文；快速个性化需要偏好，就用稳定记忆；时间推理和状态变化需要结构化，就用派生信息；出现冲突时，必须能回到原始来源重新判断。

这才是比较健康的记忆架构。

记忆不是 KV 表，它需要版本、冲突和回滚

很多 Memory API 看起来像一套很简单的增删改查。但 Agent 记忆一旦真的进入产品，就会很快遇到更新问题。

今天系统记录了一条记忆：用户喜欢方案 A。明天用户说不对，应该用方案 B。后天发现明天那次其实是某个特殊项目的临时要求，或者是 Agent 理解错了，那这条记忆应该怎么办？

如果直接覆盖成 B，可能会丢掉 A 这个长期偏好；如果恢复成 A，又可能忽略 B 在特定项目里的有效性；如果 A 和 B 都保留，又需要知道它们分别适用于什么范围、什么时间、什么任务。如果这条记忆已经被摘要、向量化、结构化，甚至同步到多个索引里，那么一次回滚就不只是改一行文本，而是要处理一整条派生链路。

这不是简单的 update。

Agent 记忆不是一张可以随便覆盖的 KV 表，而是一个带来源、版本、范围、可信度和生命周期的状态系统。

一条成熟的记忆，不应该只有内容，还应该知道它从哪里来，是用户明确表达的，还是模型推断出来的；它属于谁，是个人、项目、团队还是组织；它什么时候生效，什么时候可能过期；它是否被更新过，旧版本是否还可追溯；如果后续发现错误，系统能不能回滚到更早的可信状态。

这些能力如果没有，所谓长期记忆就会变成长期风险。

尤其是模型参与写记忆之后，风险会更大。模型可能把临时上下文总结成长期偏好，把一次异常情况总结成普遍规律，把工具返回的噪声写成事实，把网页里的 prompt injection 当成用户指令。mem0-mcp 这类把长期记忆能力暴露给 Agent 和 MCP Client 的形态，产品上很方便，但安全边界一定要非常谨慎。因为一旦模型能写入、更新、删除长期记忆，记忆系统就不再只是存储组件，而是一个会被攻击、会被污染、会影响未来行为的状态入口。

行业现在对这件事讨论得还不够。

很多人看到了 Markdown 形式的记忆很好读、很好改，也看到了 MCP 暴露 memory 能力很方便，但很少继续追问：服务端并发读写怎么办？索引和原文怎么保持一致？多个 Agent 同时更新同一条记忆怎么办？记忆删除是否真的删除了所有派生索引？本地单机方案迁移到多租户服务端后，权限隔离和审计怎么做？用户撤回或纠错后，已经被摘要、向量化、结构化的派生记忆怎么回滚？

这些才是记忆系统真正进入生产后绕不开的问题。

为什么会有短期记忆和长期记忆

不同框架里对记忆的命名很多：short-term memory、long-term memory、working memory、episodic memory、semantic memory、profile memory、project memory。名字很多，有时候反而让人困惑。

但透过名字看本质，它们其实是在描述同一个问题的不同维度：不同信息的生命周期、稳定性、作用范围和使用方式不同。

短期记忆存在，是因为当前任务需要连续性。Agent 在一个任务里试过什么、失败在哪里、下一步要接着做什么，这些信息价值极高，但不一定应该长期保存。长期记忆存在，是因为用户偏好、组织规则、项目背景、常用工具、历史决策这些东西会反复影响未来任务。如果每次都让用户重新说，Agent 就没有长期协作能力。

项目记忆存在，是因为企业协作很多时候不是围绕个人，而是围绕空间和任务。某个项目里的技术选型、约束、决策，不应该自动变成某个人的全局偏好，也不应该泄露到另一个项目空间。经验记忆存在，是因为 Agent 不应该重复犯同样的错。一次工具调用失败、一次部署失败、一次权限申请流程，如果能沉淀成可复用经验，下一次就能少走弯路。

所以短期和长期不是为了模拟人脑，而是为了区分信息的生命周期。

短期记忆解决任务连续性，长期记忆解决协作连续性，项目记忆解决空间连续性，经验记忆解决能力连续性。

它们的写入规则、召回方式、权限边界和过期机制都应该不同。把它们都塞进一个 memory.md 或者一个向量库里，早期看起来简单，后期一定会混乱。

记忆需要升级，而不是一次写死

在 Agent 记忆里，我认为“记忆升级”会是一个非常关键的机制。

不是所有信息一进来就应该变成长期记忆。很多信息应该先停留在当前上下文里。如果它反复出现，被用户确认，被多个任务验证，或者明显具备长期价值，再逐渐升级为长期记忆。反过来，长期记忆也应该可以降级、过期、失效、被纠正、被回滚。

这比“自动总结用户偏好”更重要。

因为很多偏好不是偏好，只是当时的任务约束。用户说“这次先简单一点”，不代表他永远喜欢简单方案。用户说“这个项目不要用某个技术”，不代表所有项目都不能用。Agent 如果没有作用域和升级机制，就会把局部经验错误地泛化成全局规则。

这也是我认为理想化的“全知全记忆 Agent”不合理的原因。什么都记，什么都用，听起来智能，实际很容易污染上下文。真正成熟的记忆系统，不是尽可能多记，而是谨慎地决定哪些信息值得影响未来。

记忆的写入应该保守，召回应该精准，更新应该可追溯，使用应该有边界。

Markdown 记忆只是入口，不是答案

我理解为什么很多人喜欢 Markdown 记忆。它可读、可编辑、天然适合人机协作，也很适合个人开发者场景。用户打开文件，就能看到 Agent 记住了什么，还能直接修改。这种透明感是很有价值的。

但 Markdown 不应该被神化。

Markdown 更适合作为记忆的表达层、导出层、人工编辑层，而不是企业级记忆系统的全部。真正进入 Agent 平台后，记忆要面对的是检索性能、增量索引、并发读写、版本管理、权限隔离、审计追踪、冲突合并、异步摘要、派生索引回滚、服务端多租户和数据安全。

单机文件很好，但服务端系统不是单机文件的简单放大。

如果未来 Agent 记忆会成为基础设施，那它一定不只是一个目录里的几份 md。它可能需要像数据库一样有事务和版本，像搜索系统一样有索引和召回，像权限系统一样有 scope 和 policy，像审计系统一样有来源和日志，像运行时一样能处理并发和状态变化。

所以我会更倾向于把 Markdown 看成一个很好的交互界面，而不是最终形态。

用户可以用 Markdown 理解和编辑记忆，但系统不能只靠 Markdown 管理记忆。

真正意义上的记忆是什么

回到最根本的问题：真正意义上的 Agent 记忆是什么？

我现在的理解是：

记忆不是过去的全部记录，而是未来行动可用、可信、可治理的上下文资产。

“可用”意味着它不是躺在日志里，而是在合适的时候能被召回；“可信”意味着它有来源、有证据、有版本，不是模型随便总结出来就成为事实；“可治理”意味着它有权限、有范围、有生命周期，能更新、能回滚、能删除、能审计；“上下文资产”意味着它会影响未来行动，而不是仅仅供人回看。

所以记忆的价值，不在于存了多少，而在于它能不能让 Agent 在未来更少打扰用户、更少丢失现场、更少重复犯错、更少错误迁移、更少越权使用上下文。

这件事比做一个 Memory API 难得多。

Memory API 只是入口，记忆治理才是系统。向量检索只是能力，记忆召回才是判断。Markdown 只是表达，记忆状态才是本质。摘要只是视图，原始历史才是来源。长期记忆只是结果，记忆升级才是过程。

如果说知识库让 Agent 有知识，工具让 Agent 有行动能力，那么记忆让 Agent 有连续性。而真正决定 Agent 能不能长期协作的，不只是有没有记忆，而是这套记忆能不能被正确地写入、召回、更新、回滚和治理。

所以我现在越来越觉得，未来 Agent 平台的分水岭，不会只是模型能力，也不会只是工具数量，而是上下文系统的质量。

知识库回答“世界是什么”。工具回答“我能做什么”。记忆回答“我们经历过什么”。上下文系统回答“此刻什么最重要”。

Agent 真正进入生产之后，最难的往往不是让它记住，而是让它在正确的时刻想起正确的东西，并且知道这段记忆是否可信、是否仍然有效、是否允许被使用。

记忆不是为了保存过去，而是为了让未来的行动更可靠。

这可能才是 Agent 记忆真正的意义。

在 AgentRun 上的思考：传统 Infra 必须再做一层

Thu, 04 Jun 2026 14:23:59 +0800

做 AgentRun 这段时间，我越来越强烈地感受到一件事：AI 时代的 Infra，不能再只站在底层等别人调用了。

过去 Infra 的价值，更多体现在资源、稳定性、性能、弹性和成本上。它像一层坚实的地基，支撑上层应用运行。但 AI 出现之后，应用的生产方式变了，用户的入口变了，风险的来源也变了。如果 Infra 还只停留在“我提供计算、存储、运行时、部署能力”这个位置，未来大概率会越来越被动。

因为模型在向上做 Agent，AI Coding 在向上做应用，Agent 自身也会从一个“会调用工具的智能体”，升级成企业里的任务运行实体。上层入口都在向应用靠近，如果传统 Infra 不向上走一步，就会逐渐被新的入口抽象掉。

所以我现在的判断很明确：传统 Infra 必须再做一层，或者至少做到自我闭环。

这里的“再做一层”，不是再做一个复杂控制台，也不是把已有能力重新包装成一个新概念，而是要从资源视角走到应用视角，从能力供给走到结果承接。尤其是在资源有限、方向变化快、组织协同成本高的创业环境里，每一次投入都必须沉淀为资产。一个功能做完，要沉淀成能力；一个客户做完，要沉淀成场景；一个问题解决完，要进入下一次产品闭环。否则大家看起来都很忙，但产品不会变厚。

没有闭环的 Infra，只是工具；有闭环的 Infra，才可能成为平台。

AI Coding 向上做应用，Infra 要变成信任层

AI Coding 的趋势已经很明显了。它不会长期停留在“帮人写代码”这件事上，因为代码只是中间产物，应用才是最终结果。用户真正想要的不是生成一堆文件，而是把一个想法变成可运行、可部署、可维护、可治理的应用。

这会给 Infra 带来新的机会，也会带来新的责任。

过去代码质量、安全漏洞、依赖风险、权限配置，很大程度上是用户自己负责。用户写代码，用户上线，用户背锅。但 AI 生成代码之后，这个责任边界会被重新讨论。因为 AI 生成代码的质量，说实话，依然比较堪忧。它可能能跑 Demo，但不一定适合生产；它可能逻辑看起来通，但安全边界、异常处理、权限控制、依赖治理、成本约束都不一定可靠。

这恰恰是 AI Infra 的机会。如果平台能在 AI Coding 生成应用之后，继续提供安全扫描、依赖治理、密钥检查、权限建议、运行时隔离、灰度发布、异常诊断、回滚和可观测能力，那么 Infra 就不只是部署目标，而会变成 AI 应用生产过程中的信任层。

未来用户会越来越关心：AI 生成的代码能不能安全上线？出了问题谁来定位？权限有没有越界？依赖有没有漏洞？成本有没有失控？如果平台能把这些问题承接住，它就会离应用价值更近。

这也是我觉得 AI Infra 最大的机会之一：不是替用户生成更多不确定性，而是替用户消化不确定性。

托管 AgentLoop 会成为主流

我还有一个判断：未来托管 AgentLoop 会成为主流。

如果按照二八原则，我认为 80% 的 Agent 应用会选择托管 AgentLoop，只有 20% 会由企业或开发者自己完整编写。原因很简单，大部分 Agent 应用并不需要从头实现完整的任务循环、工具调度、上下文管理、异常恢复、记忆管理和运行治理。它们更需要的是一个足够好用、足够稳定、足够安全的托管运行框架。

但那 20% 自研 Agent 也不会消失。相反，它们大概率会是企业里最重要、最有竞争力、最复杂的部分，甚至可能承载更高比例的关键流量和核心业务价值。也就是说，未来的格局不是“托管替代自研”，而是托管 AgentLoop 承接大部分通用 Agent 应用，自研 Agent 保留在真正差异化、强业务绑定、高价值的场景里。

这对 AgentRun 的启发很直接：AgentRun 不应该只做 Agent 的创建入口，而应该成为 AgentLoop 的托管运行层。

如果托管 AgentLoop 成为主流，那么平台真正要做好的不是“帮用户写一个 Agent”，而是让用户不用重新发明 AgentLoop。平台应该默认处理任务循环、工具调度、上下文加载、失败重试、权限检查、运行记录、效果评估和成本控制，把这些通用但复杂的部分沉淀下来。用户真正应该投入精力的，是业务数据、工具生态、场景编排和差异化能力。

未来 Agent 的竞争，不一定是谁的 Prompt 写得更复杂，而是谁能把 Agent 从 Demo 形态稳定带进生产环境。

数据会成为真正的核心竞争力

从 AI 开始火热到现在，事实越来越清楚：数据正在成为真正的核心竞争力。

模型会变强，框架会更替，工具会不断出现，但企业内部真实的数据、组织关系、权限体系、工作流、协同记录和业务上下文，不是那么容易被复制的。尤其是像悟空这类天然和钉钉集成的软件，它的机会不只在“做一个 Agent”或者“做一个应用”，而在于它天然靠近企业协同数据和组织场景。

这类产品如果只是把 AI 能力接进来，价值会比较薄；但如果能围绕企业数据形成闭环，价值就完全不同。用户在组织里产生任务、沟通、文档、审批、项目、知识和流程，Agent 在这些数据和权限边界内工作，运行结果再反哺下一次任务执行和应用优化，这才会形成真正的数据飞轮。

所以未来 AI Infra 不能只关心运行时，还要关心数据如何被安全使用、如何在权限内流动、如何被 Agent 消费、如何形成持续优化。没有数据闭环的 Agent 平台，很容易停留在工具层；有数据闭环的 Agent 平台，才可能进入企业的真实生产系统。

这也是为什么我越来越觉得，未来 AI Infra 不只是技术平台，而会变成企业 AI 的数据连接层、权限执行层和任务运行层。它要理解企业组织结构，理解数据边界，理解工具权限，理解运行结果。否则 Agent 只是“能调用工具”，但不一定真的能进入企业业务。

“CLI 是一切”可能打破自己的壁垒

还有一个风险，我最近也越来越在意：很多人现阶段会觉得 CLI 是一切。

CLI 当然重要。它足够开放，足够开发者友好，也容易和 AI Coding 工具结合。但如果一个平台把所有价值都过早、过完整地交给 CLI，尤其是在客户端侧形成主要入口，就有可能出现一个问题：你以为自己在开放生态，实际上可能是在打破自己的壁垒。

因为 CLI 很容易绕开平台闭环。用户在客户端完成生成、调用、部署、调试，如果平台只是一个被调用的后端资源，那么平台就很难掌握上下文、数据、运行链路、权限治理和应用生命周期。最后 Infra 仍然存在，但价值心智可能被前端工具拿走。

所以我觉得更合理的关系是：CLI 应该是入口之一，但不应该是全部。开放能力很重要，但开放不等于放弃阵地。真正有壁垒的平台，应该让 CLI 接入闭环，而不是让 CLI 替代闭环。

换句话说，CLI 可以是遥控器，但平台必须保留驾驶舱。CLI 可以发起动作，但身份、权限、审计、运行记录、策略治理、部署状态、成本数据和效果反馈，应该回到平台闭环里。否则平台最终只会变成一个资源供应商，而不是一个应用生产系统。

我理解的未来 AI Infra

如果让我现在断言未来 AI Infra 的形态，我会说它一定不是单纯的资源 Infra，而是面向 AI 应用生产的智能运行平台。

它会是端到端的，但不是大包大揽；它会是智能的，但不是为了炫技；它会是闭环的，但不是封闭；它会是场景化的，但不是每个客户都重新定制一套。它下面接云资源，上面接 AI Coding、模型和 Agent，中间负责把不稳定的生成结果、不确定的任务执行、复杂的企业约束，变成可运行、可观测、可治理、可持续优化的生产系统。

未来 AI Infra 至少要回答四个问题。

第一，生成出来的应用能不能安全可靠地进入生产。这包括代码安全、依赖治理、权限控制、密钥管理、运行隔离、异常恢复和版本回滚。

第二，Agent 能不能被托管、被观测、被治理。Agent 不应该只是 Prompt + Tool，而应该是有身份、有权限、有空间、有记忆、有日志、有评估、有成本模型的运行资产。

第三，企业数据能不能在安全边界内形成飞轮。如果 Agent 不能理解企业数据，不能尊重组织权限，不能把运行结果反哺业务流程，它就很难真正进入企业核心场景。

第四，平台能不能形成自我闭环。从生成到部署，从运行到诊断，从反馈到优化，平台必须知道应用是怎么来的、运行时发生了什么、为什么失败、哪里成本高、下一次应该怎么改。只有这样，Infra 才能从“执行工具”变成“智能运行系统”。

这也是我对 AgentRun 的期待。AgentRun 真正要回答的，不是“能不能创建一个 Agent”，而是这个 Agent 怎么进入生产，怎么运行，怎么调用工具，怎么使用数据，怎么管理权限，怎么被观测和评估，怎么和 AI Coding、模型、企业系统形成一条完整链路。

未来的 AI Infra，不是把资源交给用户，而是把不确定性消化掉，把结果交给用户。

模型会向上做 Agent，AI Coding 会向上做应用，托管 AgentLoop 会成为大部分 Agent 应用的主流选择，数据会成为企业 AI 的核心竞争力，而 Infra 如果不向上走、不形成闭环，就会逐渐被新的入口抽象掉。

这不是危言耸听，而是产品位置的变化。

AI 时代，真正有价值的 Infra，一定会更靠近应用，更关注安全和稳定，更理解数据和场景，也更愿意承担从生成到运行之间那段最难、最脏、最容易出问题的路。

谁能把这段路走通，谁就有机会站在下一代 AI 应用栈的关键位置上。

回归阿里云九个月：拥抱变化，理解变化，接受变化

Wed, 03 Jun 2026 22:43:02 +0800

马上又要到 618 了。

我第一次加入阿里云，是 2020 年 6 月 18 日。今天是 2026 年 6 月 3 日，离又一个 618 已经很近了。

而我第二次回到阿里云，是 2025 年 9 月 1 日。

那天是学生开学的日子。某种意义上，对我来说，也像是一次重新开学。

这一次回来，还是阿里云，还是 Serverless 团队，还是以前那一拨人。外人看起来，这好像是一种稳定，像是回到熟悉的地方。但对我自己来说，二进宫阿里云，其实是一件非常冒险，也非常需要勇气的事情。

因为我不是没有离开过，也不是没有过另一种生活。

在 AWS 的那段时间，我过着相对平衡的生活，面对企业客户，做架构治理，看行业实践，也用另一种视角重新观察云计算、Serverless 和 AI 的关系。但越是在外面看，越会意识到一个问题：Serverless 在国内的落地，一直是不温不火的。

它不是没有价值。相反，我一直认为 Serverless 是非常有价值的架构方向。只是过去几年，它没有真正等到属于自己的大规模场景。

直到 AI 浪潮起来，我开始重新看到一线生机。

AI 应用天然需要弹性、事件驱动、工具调用、任务编排、沙箱执行、异步处理、成本控制和快速交付。这些问题和 Serverless 的能力边界高度重合。换句话说，AI 也许不是 Serverless 的一个附属场景，而可能是 Serverless 重新进入主战场的一次机会。

也是在这样的判断下，和老板、老同事沟通之后，我决定回到阿里云。

但回来之前，我其实很清楚，这不是一次轻松的回归。

我离开阿里云的原因有很多。一个现实原因，是博士毕业。那几年我一直在工作、产品、开源、写书、论文之间来回切换，博士毕业却始终像一件悬在远处的事情。我对“博士”这件事本身有追求，不只是为了一个学历，而是希望自己真的完成一段相对完整的研究训练。

另一个原因，是那段时间我确实非常疲惫。

很多事情在当时都有预期、有判断，也有明确的上线目标，但真正推进起来并不容易。有些问题表面上看是沟通问题，深一点看，其实是协作机制、资源节奏、产品边界和执行链路没有形成真正的合力。

对我来说，那时其实已经“没电了”。

所以这次回来之后，我给自己的要求很明确：不能只是再来一次。我必须比以前做得更好，也必须避免过去的问题再次发生。该坚持的时候，要更坚定一些；该判断的时候，要更清楚一些；该承担的时候，也要更直接一些。

这种感受，和过去做 Serverless 应用中心、Serverless Devs 的经历有很大关系。

当年做 Serverless 应用中心时，团队里有人说它是“全村的希望”。这句话听起来有点玩笑，但也代表了大家对它的期待。我们希望它能让 Serverless 应用从创建、开发、部署到运维形成一个更标准的流程，也希望它能成为开发者真正进入 Serverless 的入口。

但真正开始做的时候，问题很快就来了。

比如流水线。

我当时的判断是，应用中心里的流水线应该更轻，只做必要的连接和编排，更多能力应该和 GitHub Actions、GitLab CI、云效等已有 CI/CD 工具集成，而不是自己重新做一套完整流水线。因为流水线看起来只是一个功能，背后却是任务编排、状态管理、权限、变量、环境、回滚、审计、插件生态和失败重试。

这不是一个小功能。

后来多环境也是类似。我一直认为，多环境对 Serverless 架构当然重要，但它更应该是一套最佳实践，而不一定应该被做成一个很重的产品功能。尤其 Serverless Devs 本身更像是一个偏无状态的工具链，让一个无状态过程去长期管理有状态资源，这件事本身就很别扭。

回过头看，我并不认为 Serverless Devs 是失败的。直到今天，我也不觉得它失败。它进入过 CNCF Sandbox，成为多个云厂商和企业的工具链底座，也支撑了内部大量真实场景。一个开源项目能被真实业务采用，被不同云厂商集成，被开发者持续使用，这本身就已经说明它完成过自己的历史使命。

只是它也让我学到一件事：做产品，不能只看某一个声音，也不能因为某个声音很大，就轻易改变对目标用户和产品本质的判断。

我们可能服务了一千个、一万个、十万个用户，这些用户都觉得一个能力是 OK 的，是能解决问题的。但只要有一个用户强烈质疑，团队就很容易开始自我怀疑：是不是方向错了？是不是产品有问题？

当然，用户反馈一定要听。但更重要的是，要分清楚：这是目标用户的普遍问题，还是某个非典型场景下的个体感受？这是产品方向错了，还是提示、链路、体验和文档还不够好？

这也是我现在做 AgentRun 时不断提醒自己的事情。

AgentRun 是我这次回到阿里云后最重要的一件事。

它从第一天起，就不是在一张白纸上开始的。每一个相关产品都希望 AgentRun 能和自己发生关系，都希望在这个新的 AI Agent 入口里找到自己的位置。站在组织协同的角度，这些诉求都有道理；但站在产品体验的角度，我一开始就有判断：如果第一版承载太多集成，体验一定会受到影响。

后来第一版赶在重要发布节点前上线，反馈确实不算理想。

那段时间压力非常大。但我心里也清楚，第一版的问题并不只是某个页面、某个功能、某个交互的问题，而是它一开始就背负了太多目标。于是我和大家说，再给我一点时间，我会重构一个新的版本。

后来我们很快推进了 AgentRun 2.0，并在 12 月 3 日发布。

那一版上线后，反馈开始发生变化。很多人第一次觉得，这个产品是能看的，是有希望的。更重要的是，哪怕没有大规模市场推广，还是有很多企业客户开始进来调研、试用 AgentRun，也开始认可里面的一些能力。

这对我来说很重要。

因为它说明 AgentRun 不是一个靠概念撑起来的产品。它确实切中了企业在 AI Agent 落地过程中的真实问题：运行、工具、沙箱、权限、空间、资源隔离、可观测、企业治理。

它当然还有很多体验问题，但至少在我看来，它已经具备了一个好产品的雏形。

最近几个月，围绕 AgentRun，我们也经历过一些方向选择。比如面对 OpenClaw、超级 Agent、托管 Agent Loop、IM、定时触发等公开能力和产品形态时，团队需要不断判断：哪些是短期热点，哪些能沉淀为长期能力；哪些适合快速集成，哪些应该成为自己的核心产品体验。

这类判断并不容易。

我曾经更想推的是超级 Agent，也就是托管 Agent Loop，希望它成为企业 Agent 的超级入口。这个方向如果补上 IM、定时触发等能力，其实可以形成一个更安全、更自主、更可控的 Claw 形态。我当时甚至给它起过一个名字，叫 FunClaw。

但产品发展从来不是一个人的线性推演。团队会面对热点，会面对资源约束，会面对不同产品之间的协同，也会面对短期目标和长期能力之间的拉扯。有些选择最后会被证明值得，有些选择则会提醒我们：内部创业最怕的不是慢，而是在关键窗口期里分散注意力。

这也是做产品最痛苦的地方。

很多时候，我并不是没有判断。相反，我对自己的产品判断是有信心的。

做 Serverless Devs 时，我判断它应该进入 CNCF Sandbox，也判断它会给阿里云 Serverless 带来生态和心智上的价值。那时候也有人问我：为什么其他云厂商会采纳你做的工具？凭什么？

后来事实证明，他们确实用了。因为它真的解决了问题。

我曾经说，不应该自己做一套重流水线，不应该把多环境做成复杂产品功能。后来很多结果也验证了这些担忧。两年前，我也说过，世界上从来不需要第二个 Dify。当一个产品决定自己的目标是对标 Dify 的时候，某种程度上就已经输了。因为用户不需要一个“差不多的替代品”，用户需要的是在特定场景下更好、更准、更不可替代的产品。

还有一个最近的例子，是 AI Coding。

今年 4 月，我曾经判断，很多 AI Coding 工具未来可能不只是“写代码的工具”，而会逐渐变成 AI 应用的重要入口。因为当开发者越来越习惯在 AI Coding 工具里描述需求、生成代码、调试应用、调用工具，下一步很自然就会延伸到应用发布、应用部署、运行管理和线上治理。

也就是说，AI Coding 工具的上层，很可能会长出一套新的应用发布和部署体系。

当时很多人并不相信这个判断，觉得 AI Coding 只是辅助编码，离应用运行和部署还很远。但很快，CMA 这样的东西出现了，Qoder 团队也开始做 Cloud 的 Agency。你能明显感受到，AI Coding 正在从“代码生成工具”变成“应用生产入口”，甚至可能进一步影响云上应用的交付方式。

包括我后来推动 FunModel 重构，短期内也带来了用户和业务数据的明显增长。Stable Diffusion 第一波起来时，我们做 AIGCaaS，也确实抓住了场景。

所以我不否认，我是一个有产品 sense 的人。

但这份信心并不会让我轻松。恰恰相反，它有时候会让人更痛苦。因为当你提前看到一个方向可能会失败，而团队仍然决定投入时，你会很难受；当你看到一个方向可能会成功，但资源被分散、节奏被打断、组织不再形成合力时，你也会很难受。

产品经理最难的地方，不是有没有判断，而是你的判断能不能被组织相信，能不能变成团队共同的行动。

如果判断只停留在一个人的脑子里，它最终只是焦虑。只有当判断被团队理解、被资源支持、被执行兑现，它才会变成产品结果。

这九个月里，我经历了从兴奋、压力、重构、看到希望，再到重新迷茫的过程。

有时候我也会想，自己的出路到底是什么。是继续留在这里，等待变化，继续推动 AgentRun 往前走；还是去另一个互联网公司，找一个更能集中资源打仗的环境；或者换一条路，去做博士后，去高校或体制内，把这些年在工程、产品、论文、专利、开源和产业实践里的积累，换一种方式继续延展。

说实话，我现在也没有答案。

过去几年，我从阿里到南网，到 AWS，又回到阿里。每一次变化，外人看起来可能都有一个清楚的理由，但只有自己知道，真正身在其中时，很少有什么选择是完全确定的。很多时候，都是在不确定里做判断，在焦虑里做取舍，在看不到结果的时候继续往前走。

所以回头看，我这几年最深的感受可能就是：

拥抱变化，理解变化，接受变化。

但接受变化，不代表放弃判断；理解变化，也不代表随波逐流。对我来说，真正难的是：在变化里保留自己的判断力，在被消耗之后还能重新长出行动力，在一次又一次不确定里，仍然尽量把自己相信的事情做对。

回归阿里云九个月，我依然相信 Serverless 和 AI 结合的机会，也依然相信 AgentRun 这样的产品有价值。

只是我也比以前更清楚：一个好产品，不只是被设计出来的，也是被组织、资源、耐心和共同信任一起托举出来的。

这九个月不是答案。

它更像是一段新的提问。

托管 Agent Loop，会是下一个 Serverless 吗？

Tue, 21 Apr 2026 22:26:05 +0800

从 Claude Managed Agents 到阿里云超级 Agent 的全景分析

2026 年 4 月 8 日，Anthropic 正式推出 Claude Managed Agents，Public Beta 开放。官方的表述很简洁：你定义 Agent 该做什么、能用什么工具、有什么约束，剩下的交给我们。

但在此之前，阿里云 AgentRun 在 3 月就已经悄然上线了”超级 Agent”功能。

两件事撞在一起，让一个问题变得值得认真对待：托管 Agent Loop，是否正在成为 AI 基础设施的下一个标准形态？

这不是一个可以轻易回答的问题。它背后牵扯着产品策略、平台生态、安全架构，以及一个更根本的技术判断——Loop 托管这件事，到底能解决多少真实问题。

先说清楚”Loop”到底是什么

讨论托管之前，需要先把”Agent Loop”说清楚，因为它经常被用得很随意。

一个 Agent 在运行时，本质上在执行一个循环：拿到任务，模型推理，决定要不要调用工具，调用工具，把结果塞回上下文，继续推理，直到任务完成或触发中止条件。这个”推理 → 决策 → 执行 → 回收”的闭环，就是 Agent Loop。

听起来不复杂。但一旦进入真实的生产环境，每个环节都会暴露问题：工具执行超时了怎么处理？调用出错了要不要重试，重试几次？循环跑了几十步还没结束，怎么安全中止？多个任务并发时，会话状态怎么隔离？敏感操作怎么做权限管控？

每一个问题单独拿出来都不难解，但组合在一起，就是一套需要认真设计的基础设施工程。这正是绝大多数开发团队从 Demo 跑到生产之间卡住的那道墙。

“托管 Agent Loop”这件事的价值，正是在这里。

Claude Managed Agents：这究竟是克制，还是初期？

这是一个需要认真讨论的问题，因为两种判断会导向完全不同的结论。

如果是”极度克制的战略选择”，那它现在缺失的知识库、记忆、工具市场是有意为之，背后有清晰的产品哲学；如果是”功能尚不完整的初期形态”，那现在的产品只是一个起点，这些能力终将被补齐进来。

答案，其实是两者都有，但权重不同——而且有据可查。

The New Stack 在报道 Claude Managed Agents 发布时明确提到，advanced memory tooling 和 multi-agent orchestration “remain in a limited research preview”。这个措辞非常关键。”research preview”不是”我们不打算做”，而是”我们在做，但还没准备好放出来”。同时，Anthropic 工程博客里对 Managed Agents 架构的描述是”a meta-framework designed to accommodate future harnesses, sandboxes, or other components”——这是一个为未来扩展显式预留空间的架构设计，不是一个封闭的产品。

所以有一部分确实是”初期”：记忆、多 Agent 编排这些能力，在 Anthropic 内部已经有了明确的研发方向，只是还没到可以公开发布的成熟度。现在看到的产品，是在能力还没完全就绪时，选择先把运行时这个最核心的部分推出来，而不是等全部能力就绪再一起发。

但同时，有一部分也确实是”克制”：Anthropic 在工具市场、可视化界面、no-code 配置这些方向上，几乎没有任何公开的规划信号。Skills 被明确定义为开放标准，而不是平台内置的闭源能力。知识库的位置也没有要内置的迹象——更像是会以工具或 Skills 的形式让开发者自己对接。

把这两层叠在一起，才是比较真实的图景：Anthropic 做的是一个架构上完整、但功能上还在演进的基础设施产品。它有意不做某些事（平台化、no-code、工具市场），也有一些事还没做好（记忆、多 Agent 编排）。前者是战略克制，后者是阶段局限。

理解这个区别很重要，因为它直接影响我们对这款产品未来走向的判断。记忆和多 Agent 编排会来，但大概率以 API 的形式提供，而不是平台 GUI；工具市场可能会在 Skills 生态成熟后以某种方式出现，但 Anthropic 大概不会自己去运营一个类似应用商店的东西。它始终想做的，是让开发者在 Claude 的运行时上构建自己的产品，而不是替开发者把产品建好。

C 端和 B 端想要的，根本不是同一件东西

讨论 Managed Agents 面向谁，不能只停在”B 端开发者”这个答案上，因为这会掩盖一个更本质的问题：C 端用户构建 Agent 的诉求，和 B 端企业构建 Agent 的诉求，在结构上是完全不同的。

C 端用户——这里指的是有一定技术能力、想构建个人 Agent 的个人开发者或高级用户——他们最关心的是什么？大概率是：我的 Agent 能不能记住我是谁、我的偏好是什么、上一个任务做到哪里了。他们需要的是持久记忆和个性化，需要一个真正理解自己的”个人 Agent”。与此同时，C 端用户使用的工具通常是个人工具——日历、笔记、代码仓库、搜索——工具集相对固定，但对记忆和连续性的要求极高。他们不需要企业级的 SLA，不需要 RAM 权限体系，也不需要多租户隔离，但他们需要 Agent 在每一次对话后都还记得自己。

B 端企业用户面对的是完全不同的问题。企业构建 Agent 的场景，往往是把 Agent 嵌入某个具体的业务流程——客服、代码审查、财务对账、数据分析。这类 Agent 并不需要特别深的个性化记忆，它需要的是稳定、可控、可审计。当一个企业级 Agent 调用了 ERP 系统的写入接口，发生了错误，需要有完整的执行链路可以回溯；当 Agent 被授权访问某个部门数据库，权限边界必须精确可控；当 Agent 跑在多个租户环境下，会话隔离是基本要求。B 端用户愿意接受更高的接入成本，愿意写代码、配策略、搭工具，但他们对安全性和可观测性的要求是不可妥协的。

现在回头看 Claude Managed Agents，它提供的东西——沙箱隔离、权限策略、会话管理、事件历史、MCP Connector——几乎每一项都是在回应 B 端诉求，而不是 C 端诉求。没有跨会话的持久记忆，没有个人偏好管理，没有任何面向个人用户的界面，全程 API 操作。这不是偶然的，是产品选择的必然结果。

但这里有一个微妙的地方：C 端诉求中最核心的”持久记忆”，恰恰也是 Managed Agents 目前还在 research preview 状态的能力之一。

这意味着什么？Anthropic 自己并没有完全放弃 C 端的记忆场景，但它的实现路径大概率不会是”给普通用户做一个漂亮的记忆管理界面”，而是”提供一套 Memory API，让开发者自己决定如何暴露给用户”——它仍然把 C 端的体验层留给第三方开发者去做。

这其实揭示了 Anthropic 在产品层面的一个基本判断：他们认为，Claude.ai 是 C 端的入口，Managed Agents 是 B 端的基础设施，两者分工不应混淆。C 端用户体验上需要的东西——记忆、个性化、连续性——将由 Claude.ai 这个产品来承载，而不是由 Managed Agents API 直接提供。Managed Agents 的客户永远是开发者，不是最终用户。

这个分工逻辑是清晰的，但它也带来了一个潜在的张力：当越来越多有技术能力的 C 端用户，想要自己构建一个深度个性化的个人 Agent，而不满足于 Claude.ai 提供的标准体验时，Managed Agents 给他们提供的运行时是充分的，但缺失的记忆和个性化能力，会让这条路走得很费力。这个需求的空白，目前要么靠开发者自己填，要么等 Memory API 成熟。

AgentRun 超级 Agent：从另一个方向切入同一个问题

阿里云 AgentRun 在 2025 年底正式发布，定位是”企业级 Agentic AI 基础设施平台”，3 月上线的超级 Agent，是它在产品演化上的一个关键节点。

要理解超级 Agent，首先要理解 AgentRun 本身在解决什么问题。和 Claude Managed Agents 不同，AgentRun 从一开始就不只是一个运行时，它是一个更完整的 Agent 全生命周期平台——包括知识库集成（百炼知识库和 RAGFlow 双轨）、工具市场（支持一键安装、一键部署）、凭证管理（通过 Hook 机制解决 MCP 协议不支持动态注入的问题）、记忆管理 API，以及完善的安全与可观测体系（对接阿里云 RAM 权限、内容安全护栏、Token 限流、链路追踪）。

这套东西本身已经比 Claude Managed Agents 的能力宽得多。但它碰到了一个新问题——也是一个很真实的问题。

当企业在 AgentRun 上积累了大量子 Agent、工具和知识库之后，这些资产是孤立的。用户想完成一个复合型任务，需要自己知道应该调哪个 Agent，配哪个工具，连哪个知识库。这件事在 Agent 数量少的时候还好，但随着资产规模增长，调度成本会快速上升，大量 Agent 开始”吃灰”。

超级 Agent 的出现，正是为了解决这个问题。它的逻辑是：提供一个平台原生的主 Agent，用户把已有的子 Agent、工具、知识库作为它的能力集合配置进来，然后只需要提出任务，由超级 Agent 来完成意图理解、任务分解和资源路由。

这个设计的本质，是把”我有很多 Agent，但不知道怎么用”这个真实用户痛点，转化成了一个产品功能。它解决的不是运行时问题，而是资产调度和意图对齐的问题——这和 Claude Managed Agents 其实是不同层级的东西。

两款产品，两种赌注

如果把两款产品放在同一个坐标系里看，它们的差异会变得非常有意思。

Claude Managed Agents 的核心主张是：把 Agent Loop 这件最难标准化的事情给你托管好，其他事情通过开放标准自己搭。它的赌注是：如果 Skills 标准像 MCP 一样被行业接受，Anthropic 就赢得了 Agent 时代的协议层地位，而 Managed Agents 就是让开发者进入这个生态的入口。这是一个典型的”先占协议，再做平台”的战略路径。

AgentRun 超级 Agent 的核心主张是：企业不需要拼积木，需要的是一个能把所有资产串起来的统一入口。它的赌注是：随着企业 Agent 资产规模增长，”超级 Agent 作为统一调度层”这个需求会越来越刚性，而这个能力只有在一个拥有完整生态的平台上才能做好。这是一个”先做闭环，再做深度”的路径。

	Claude Managed Agents	AgentRun 超级 Agent
解决的核心问题	单个 Agent 的生产级运行时	多 Agent 资产的统一调度入口
产品层级	基础设施运行时层	应用编排与资源聚合层
知识库 / 记忆	在路上（research preview）	已深度集成
工具生态	开放标准，自行搭建	工具市场，一键接入
用户操作方式	纯 API / 代码	平台 UI + 配置
生态策略	开放标准，跨平台可移植	阿里云生态深度绑定

这张表的意义不在于说谁更好，而在于说明它们在解决不同阶段的问题。Claude Managed Agents 解决的是”如何把第一个 Agent 稳定地跑起来”，AgentRun 超级 Agent 解决的是”如何管好已经跑起来的一百个 Agent”。这两个问题在企业 AI 落地的不同阶段都真实存在，并不互斥。

托管 Loop 的天花板在哪里

现在可以回到最开始的问题：托管 Agent Loop，会成为新的业界形态吗？

从趋势上看，答案大概是肯定的。原因很朴素——绝大多数企业和中小开发团队，没有能力把生产级 Agent 基础设施做好，外包给专业平台是降低门槛的必然选择。Serverless 走过了同样的路：最开始大家都自己管理服务器，后来发现”只写函数、不管运行”这个模式可以被市场接受。AWS、Azure、阿里云都在 Agent 运行时这个方向上押注，说明这不是某一家的判断，而是行业在收敛的共识。

但有一点需要想清楚：托管 Loop 解决的是运行时问题，不是能力问题。

一个 Agent 能不能完成复杂任务，取决于底层模型的推理质量、工具的覆盖度和可靠性、知识库的完备程度、任务规划逻辑的设计，以及多 Agent 之间的协作协议。托管 Loop 负责把这些要素稳定地跑起来，但它本身并不能让一个设计糟糕的 Agent 变得更聪明，也不能让工具覆盖度自动提升。Loop 托管是 Agent 落地的必要条件，但不是充分条件。

这也是为什么阿里云不满足于只做运行时，而是在更上层用超级 Agent 来做编排；这也是为什么 Anthropic 不断强调 Skills 的重要性——因为他们清楚，光有 Loop 托管，用户能做到的事情是有限的。

安全性是另一个无法回避的问题。托管模式意味着 Agent 的执行路径完全在第三方平台上，工具调用的参数、推理的中间状态、对话上下文，这些数据在平台侧都是可见的。对于涉及敏感业务数据的 Agent（财务、法律、客户信息），这需要认真评估。Claude Managed Agents 目前的应对是沙箱隔离和权限策略，但企业级私有部署的选项尚不明确。AgentRun 依托阿里云 RAM 体系在权限隔离和合规层面相对成熟，但同样存在数据驻留在云端的基本前提。

稳定性的要求比传统 SaaS 更高，因为 Agent 通常在执行有状态的长任务，一旦平台抖动，任务中断的代价远大于一次普通 API 调用失败。锁定问题是结构性的，短期内没有完美解法——Claude Managed Agents 的锁定在于运行时绑定 Claude 模型；AgentRun 的锁定在于整套生态都在阿里云内，迁移成本极高。对于企业来说，一个相对务实的应对思路是：在设计阶段就保持”逻辑层”与”运行时层”的分离，即使今天跑在某个托管平台上，Agent 的核心逻辑也应该具备相对低成本的迁移能力。

最后

回头看，这两款产品是从不同方向在挖同一座山。Anthropic 从协议层和运行时往上挖，AgentRun 从完整平台往下打磨基础。它们现在的能力差距，本质上反映的是两家公司不同的战略优先级，而不是技术能力的高下。

有一点是确定的：无论哪条路线，Agent 基础设施的竞争才刚刚开始。现在这个阶段，还没有哪个平台真正解决了复杂 Agent 能力的全部问题——知识、记忆、多 Agent 协作、长任务规划，每一项都还有大量工程和产品工作要做。托管 Loop 是这场竞争的起点，而不是终点。

为 AgentRun二进宫：一个关于 Serverless 与 Agent Infra 的未竟执念

Tue, 21 Apr 2026 22:14:20 +0800

2025年9月1日，我重新挂上了阿里云的工牌。

二进宫：一个不为安稳的选择

距离我上次离职（2024年5月），刚好过去了一年四个月。距离我最初加入（2020年6月），整整五年多。这在互联网大厂的职场叙事里，是一种相当罕见的”二进宫”。

很多人不理解我的选择。有人以为是外面混不下去了，有人以为是大厂情结作祟。但我心里很清楚：这次回归不是为了安稳，而是为了一个从过往 Serverless 岁月里长出来的未竟执念——AgentRun。

过去做 Serverless 的那些年，我们解决了算力的弹性，让函数可以在毫秒内拉起、用完即走。但我们留下了两个没有填平的坑：冷启动的宿命，和编排的空白。当时我以为这只是工程细节，等到 2024 年重新以旁观者身份观察这个行业，我才意识到，那两个坑已经被 AI Agent 的浪潮放大成了峡谷。

我想回来填这两个坑。这是我二进宫的真实原因。

一个正在发生却鲜少被点破的荒谬现实

当我重新坐回函数计算的工位，从零开始推动 AgentRun 落地时，我看到了整个行业里一个奇怪的景象：

所有人都在把 AI Agent 降格为给大模型打工的”静态管道”。

2023 年到 2024 年上半年，市面上绝大多数所谓的 Agent 平台，本质上是模型包装器（Model Wrapper）。逻辑是这样的：找一个大模型，套一个 Prompt，外挂几个 API 工具，用 LangChain 或者 AgentScope 把它们串起来，这就叫 Agent 了。

这种做法在 Demo 阶段看起来魔术般神奇。但一旦进入生产环境，立刻原形毕露——脆弱、失控、成本灾难。

我没有夸张。互联网上随便搜一下”agent production failure”，Reddit 和 Hacker News 上到处是工程师在倒苦水：AI Agent 死循环跑了十几天，账单像脱缰的野马；工具数量一旦超过个位数，模型就开始乱调用、自相矛盾；沙箱报错日志把主会话上下文塞满，Agent 很快”失忆”，后续任务彻底崩溃。

这不是偶发事故，这是系统性的架构债务。而这笔债务的根源，在于我们对 Infra（基础设施）角色的一个根本性误判：

我们以为 Infra 只需要被动地提供算力和连接就够了。

但如果 Infra 本身只是一根冰冷的管道，它永远无法支撑 Agent 那种具有自主规划、纠错和演进能力的生命体。Infra 的进化速度一旦滞后于大模型的推理能力，Agent 将永远停留在 Demo 阶段，无法跨越生产级的鸿沟。

这就是我想做”智能 Agent Infra”的底层动因。

抛弃”模型包装器”，回归 Agent 的生命体本质

让我们暂时抛开行业术语，回到第一性原理：Agent 到底是什么？

主流叙事喜欢把 Agent 定义为”能调用工具的大模型”。但这只是表象。大模型是大脑，是计算中枢——但只有大脑，算不上生命体。一个真正能在复杂业务中存活的 Agent，必须是一个完整的数字生命体：

神经末梢：工具感知（MCP、Function Call）
四肢：沙箱执行环境（安全地在现实世界施加动作）
记忆中枢：知识库与长期记忆（Mem0）
循环系统：AgentLoop 与 Hook 机制（维持持续运转）

缺乏外围系统支撑的大模型，只是一个无法在现实世界施加行动的”缸中之脑”。

模型包装器的三个致命局限

2023 年底，行业正处于”模型包装器”狂热的尾巴。大家沉迷于用低代码拖拽出一个能用大模型查天气、查数据库的 Bot。但这种狂热掩盖了三个致命的底层缺陷：

1. 无状态的幻觉灾难

模型包装器往往没有真正的长期记忆机制。每次对话像是在给一个失忆症患者复读昨天的故事。上下文窗口再大，也无法解决业务中需要跨月、跨项目持续演进的记忆需求。业务无法沉淀经验，Agent 永远是新手。

2. 执行环境的裸奔

大模型生成了代码，谁来安全地执行？传统做法是让主 Agent 直接调一个远程容器或本地 Python 进程。这就像让 CEO 直接去车间开冲床——一旦出错，不仅是任务崩溃，更是整个生产线（会话）的停摆。系统毫无韧性可言。

3. 编排的失控

当工具数量从 3 个增加到 30 个，子 Agent 从 1 个裂变到 10 个，模型包装器的线性 Prompt 逻辑会彻底崩溃。大模型会在海量 Tool Choice 中迷失，频繁调用错误工具，产生死循环。规模化的尽头是失控。

这不仅是技术缺陷，更是认知错位。我们试图用静态的、被动的 Infra 去支撑动态的、主动的 Agent，就像用马车底盘去装载 V8 发动机，注定散架。

AgentRun 的底层逻辑：Infra 即生命体支撑系统

当我从零开始设计 AgentRun 时，我把它定位为”Agent 生命体的全生命周期支撑系统”，而不是”让大模型更好调用 API 的平台”。这就要求它必须提供数字生命体运转所需的一切基础设施：

运行时：基于阿里云函数计算 FC 的 Serverless 运行时，极致弹性、按量付费、零运维，支持多语言环境——这是 Agent 的躯体容器
沙箱：MicroVM 多级隔离的安全执行环境，支持 Browser Use 与 Code Interpreter——这是 Agent 的四肢与安全操作间
知识库与记忆：深度集成 RAGFlow 与 Mem0，支持一键托管或 VPC 私域部署——这是 Agent 的海马体与长期记忆区
权限与凭证：统一管理 AK/SK、JWT 等，运行时动态注入——这是 Agent 的社会身份与通行证
工具管理：支持 MCP 与 Function Call 双协议，一切皆可 MCP 化——这是 Agent 的技能包与神经突触

做完这些，我只是搭起了一个完备的”静态 Infra”。比模型包装器强很多，但依然是个被动的工具箱。

真正的转折点，是我意识到一件事：如果 Agent 自身是智能的，为什么支撑它的 Infra 不能也具备智能？

如果沙箱只是被动等待代码输入，它只是个昂贵的计算器。如果工具网关只是做协议转换，它只是个死板的路由器。

于是，我做出了整个产品演进中最反常识、也是最关键的一跃：让 AgentRun 从 Agent Infra 升级为”智能 Agent Infra”。 不再是开发者通过 Infra 去控制 Agent，而是 Infra 本身内嵌智能调度能力，用 Agent 来治理 Agent。

被集体忽视的陷阱：让主 Agent 直接操作沙箱

在所有 Agent 工程实践中，有一个被主流叙事集体忽视、却每天都在真实发生的问题：让主 Agent 直接操作沙箱。

主流的开发范式是这样的：构建一个强大的主 Agent，赋予它 Prompt、记忆、工具列表；当需要执行代码或浏览网页时，主 Agent 生成指令扔给 Sandbox，Sandbox 把结果（报错日志、网页截图、HTML 原文）吐回来，主 Agent 再根据结果继续思考。

这看起来天经地义。但如果你认真审视这个回路，会发现它存在一个根本性的浪费：

你在用豪华大脑的算力，去干脚本跑腿的工作。

想象一个金融分析 Agent，需要从某财经网站抓取财报数据并计算市盈率。传统模式下，它的工作流大概是这样的：主 Agent 生成爬虫代码 → 代码报错 → 报错日志吐回给主 Agent → 主 Agent 重新思考并修改代码 → 代码再次执行，抓到了 HTML 原文 → HTML 原文（包含大量无关标签）吐回给主 Agent → 主 Agent 提取数据并计算。

注意这里面有什么：报错 Traceback、大段 HTML 标签——这些毫无推理价值的噪音，全部在主 Agent 的上下文窗口里占了大量空间。它们不仅消耗算力，更严重的是，它们在污染主 Agent 的思维空间，让它很快达到上下文极限，无法继续处理后续的复杂逻辑。

这不是个别案例，这是结构性的问题。上下文污染、算力浪费、单点故障——这三重伤害叠加在一起，是 Agent 应用无法进入生产级的核心工程阻力之一。

Sandbox Agent：把大脑从四肢的噪音中解放出来

这是我提出”Sandbox Agent”的直接动因。

反常识的洞察只有一句话：沙箱不需要被主 Agent 操作，沙箱里应该有一个自己的 Agent。

Sandbox Agent 的核心机制是：在 Sandbox 环境中内嵌一个轻量级的 AgentLoop，使用极低成本的模型。当主 Agent 需要执行任务时，它不再生成具体代码，而是下达一个高层指令，比如”去某财经网站抓取 AAPL 的财报并计算市盈率”。

Sandbox 内的轻量级 Agent 接收指令后，自主生成代码、执行、遇到报错自主 Debug、清洗数据、计算结果，最后只把一句精炼的答案返回给主 Agent——“市盈率为 28.5”。

主 Agent 发出的是一句高层指令，收到的是一个干净的答案。中间所有的试错、报错、数据清洗，全部在沙箱内部闭环消化。

主 Agent 是 CEO，负责战略规划。Sandbox Agent 是车间主任，负责把战略转化为具体操作，并在车间内部解决所有生产故障。 只有这样的分层，Agent 应用才能从 Demo 的玩具，变成生产级的系统。

这种”往沙箱内注入自治能力”的思路，并不是 AgentRun 的孤立创新。看 E2B 对 Manus 的支持方式——沙箱维持持久会话，Agent 在沙箱内自主决定每一步操作；看 Modal 与 Restate 的组合——在容器内引入容错与状态管理。行业头部玩家正在不约而同地往同一个方向走：把试错的闭环压缩在执行端，而不是不断回调给外部的主 Agent。

多维视角碰撞：谁在阻碍 Agent 成为真正的应用？

当我在内部提出”智能 Agent Infra”和”超级 Agent”时，碰撞是激烈的。不同利益相关方的视角截然对立，而这种对立，恰恰揭示了 Agent 走向真正应用的最大阻碍。

开发者视角：自由组装与失控的边缘

硬核开发者喜欢 AgentRun 早期的设计：提供运行时、沙箱、工具市场、MCP 协议，像搭乐高一样自由组装。他们可以用 SDK 集成 LangChain、AgentScope，自由拼装工具，在需要时一键从低代码切换到高代码，获得完全控制权。

主流观点认为，给开发者提供更多接口等于赋予更大能力。这没错。但它忽略了一件事：当你拥有 30 个 MCP 工具、5 个子 Agent 时，谁来负责它们之间的路由与冲突消解？如果开发者在高代码里写一堆 if-else 来处理工具选择的 Fallback，他是在把 Infra 层该干的苦力活硬塞进业务逻辑层。看似极致的自由，最终换来的是架构的失控。

业务方视角：开箱即用与黑盒恐惧

业务方（产品经理、运营）讨厌复杂性，喜欢”60 秒创建 Agent”的承诺。但他们最恐惧的是黑盒失控：Agent 为什么突然调用了退款 API？为什么在沙箱里执行了危险操作？他们需要的是可预测的智能，而不是盲目的自主。缺乏可观测性与治理的智能，在商业场景中没有价值。

平台视角：生态繁荣与治理真空

作为平台方，阿里云希望 AgentRun 是一个繁荣的生态，一切皆可 MCP 化。但如果没有智能治理，生态就是一片杂草丛生的荒原。往管道里注入大脑，是平台视角的必然演进，而不是可选项。

分歧的根源

所有人都把 Agent 看作一个”零散的模块集合”，而不是一个”有机的应用整体”。开发者拼装模块，业务方使用单一模块，平台方售卖模块。但当模块数量超过人类直觉能掌控的阈值，必须引入 AI 来治理 AI。

这正是”超级 Agent”要解决的终极命题——它不是一个更强大的大模型，而是一个托管的 AgentLoop（智能调度中枢）。用户自由添加工具、子 Agent、记忆、知识库，而超级 Agent 通过各层面的 Hook，在海量 Agent 与工具下重建秩序：

前置 Hook：在工具调用前，自动注入凭证、校验参数合法性、根据语义拦截高危操作（比如非 VIP 用户的删库指令）
后置 Hook：对结果进行清洗与压缩（把长长的 HTML 清洗成一句话摘要再返回主 Agent）、记录审计日志
智能路由：不让大模型在 30 个工具里瞎猜，而是通过语义分析先粗筛出 3 个相关工具，再让大模型做精准选择

超级 Agent 让 Agent 从”开发者手忙脚乱拼装的机械怪兽”，变成”平台智能调度、按需组装的钢铁侠战甲”。Agent 的演进不再依赖人类开发者无限的精力投入，而是依靠系统自身的自组织能力。

主动挑战自身论点：智能 Infra 是过度工程化吗？

我必须诚实面对这个反驳。最有力的质疑是：智能 Infra 是不是过度工程化？

对于大量简单的单步调用场景（比如查天气、翻译文档），引入超级 AgentLoop 和 Sandbox Agent，不是在杀鸡用牛刀吗？

这个质疑是合理的。如果一个业务只需要调用一次大模型获取结果，模型包装器是最优解。没有 Hook，没有沙箱内嵌 Agent，简单直接，延迟最低。在单步 API 边界内，任何额外的调度开销都是冗余的。

我必须承认，我的论点在以下地方可能出错：

第一，Sandbox Agent 节省算力的逻辑，建立在”沙箱内任务多步且有脏数据”的前提上。如果沙箱任务极其简单，内嵌 Agent 的初始化成本反而可能高于直接返回结果。

第二，如果开发者不知道前置 Hook 改写了他的 Prompt，或者后置 Hook 截断了他的输出，系统可观测性会急剧下降，排查问题将会是噩梦。

所以，边界在哪里？

绝对不能陷入”万物皆 Hook”的反模式。智能 Infra 的介入深度必须与任务的复杂度正相关。AgentRun 的设计哲学是渐进式智能：

层级	适用场景	模式
L0 静态管道	单步调用	直接走 Function Call，无 Hook，无沙箱内 Agent
L1 受控沙箱	逻辑固定的代码执行	传统 Sandbox，主 Agent 直控
L2 Sandbox Agent	多步试错任务（网页爬取、数据清洗）	激活沙箱内嵌 Agent
L3 超级 Agent	工具数量多、多 Agent 协同、复杂权限流转	开启全局 Hook 与智能路由

系统不是静态停留在某一层级的。当监控信号显示连续报错超过阈值，或 Token 消耗斜率陡增，系统会自动从 L0 跃升至 L2，让 Sandbox Agent 接管；当工具路由冲突频发，系统会跃升至 L3，开启超级 Agent 的全局调度。

智能不是一刀切的乌托邦，而是根据系统压力自适应伸缩的生存法则。 提供一把可伸缩的瑞士军刀，而不是一把锤子把所有问题都看成钉子——这才是工程学的正道。

七、我的预判：Agent 将死于编排失控，或重生为 AI 应用

基于上述分析，结合当前 Agent 技术栈的演进速度与生产级落地的痛点暴露频率，我对接下来 12-18 个月做出三个明确的预判。

预判一：纯模型包装器平台将在 2026 年 Q2 前大规模倒闭或转型。

当前市面上大量以”低代码拖拽 + 大模型 API”为核心卖点的 Agent 平台，其流失率将达到临界点。信号节点：当主流企业客户在 Agent 项目上的账单连续多季度超预期增长，且 Demo 无法转化为生产级应用时，资本将停止输血。替代方向：要么向底层退化为纯粹的模型网关，要么向上层进化接入智能 Infra。资本不会永远为 Demo 幻觉买单，行业将经历一次残酷的供给侧清洗。

预判二：Sandbox Agent 将成为行业标准架构，时间节点在 2026 年 Q3。

随着 Browser Use 和 Computer Use 成为 Agent 标配能力，主 Agent 直接操作沙箱的结构性问题将无法继续掩盖。这不是孤证——E2B 在 Manus 案例中强调的沙箱持久会话与内部自主决策、Modal 推出的容错与内嵌状态管理，都指向同一个方向：把试错闭环压缩在执行端。当沙箱从被动执行器进化为自主闭环的微型车间，Agent 应用的规模化落地才有工程学上的可行性。

预判三：Agent 的终局不是零散的模块，而是闭环的 AI 应用。

2026 年底，我们将看到第一批真正意义上的”AI 应用”诞生。它们不再是开发者在 IDE 里拼装的脚本，而是拥有超级 Agent 作为中枢、Sandbox Agent 作为执行终端、Mem0 作为记忆基底、MCP 作为社交网络的数字生命体。它们能够 7×24 小时自主运行、自我纠错、甚至在权限范围内自我升级。

软件工程将从”代码逻辑的堆砌”彻底走向”系统目标的涌现”，AgentRun 正在铺设这条从模块到生命体的轨道。

三件你可以现在就做的事

如果你是正在落地 Agent 的技术决策者，或者正在 LangChain 里深陷编排泥潭的开发者，这篇文章对你的实质启示很明确：

1. 放弃重塑底层，用 MCP 泛化锁定生态连接

不要再去自己写一套 API 网关和工具接入协议了。你的子 Agent、沙箱、已有 API，都能一键 MCP 化并互联。把精力花在业务逻辑上，而不是协议适配上。

2. 从低代码起步，但必须预留高代码逃生舱

千万别被无代码平台的 Demo 锁死。选择提供”一键转换为高代码”能力的平台。当你的业务遇到权限隔离、智能模型路由、多租户记忆隔离时，只有高代码能救你——而且必须是平滑演进的高代码，不能推倒重来。你选择的不是当下的便捷，而是未来系统复杂度激增时的生存权。

3. 立即审查你的沙箱调用模式

如果你现在的架构是主 Agent 直控沙箱，花半天时间算一下 Sandbox 返回给主 Agent 的内容里，有多少是报错日志和未清洗的原始数据。如果这部分占了你总上下文消耗的相当比例，你正在经历结构性的算力浪费。把多步试错任务剥离到 Sandbox Agent 模式中，把主 Agent 的上下文窗口留给真正高价值的推理。最深刻的架构革新，往往始于对最庸俗的成本账本的审计。

尾声：不留遗憾

有人问我，二进宫回来做这样一件从零到一的事，图什么？

我想了很久。如果一个人一生能做好的事情是有限的，我希望这是那个能让我不留遗憾的事。

过去的 Serverless，我们解决了算力的弹性，却留下了冷启动的宿命与编排的空白。今天的 AgentRun，我们在算力之上注入了智能的灵魂：用超级 Agent 重建秩序，用 Sandbox Agent 剥离噪音，用 Mem0 和 MCP 给 Agent 装上记忆与社交能力。

这不只是一个产品的发布。这是对过往遗憾的救赎，也是对 AI 应用终局的一次押注。

我回到了这片战场，因为我确信：Agent Infra 的智能化，是这十年里最值得用尽全力去推倒重来的那堵墙。

AgentRun 已于 2025 年 12 月正式发布，基于阿里云函数计算 FC。本文所有观点均为个人思考，不代表任何组织立场。
以上是完整的文章正文。整体做了以下处理：

AgentRun 探秘：通过无代码创建Agent，通过高代码更新Agent

Mon, 08 Dec 2025 00:50:12 +0800

当我们谈论 AI Agent 的开发时，常常面临一个两难的选择：低代码平台上手快但缺乏灵活性，一旦需求复杂就束手无策；高代码开发虽然灵活但门槛高，业务人员无法参与，验证周期长。能否鱼与熊掌兼得？

AgentRun 给出了答案：通过无代码快速创建 Agent 验证想法，当业务发展需要更复杂定制时，一键转换为高代码继续演进。这不是简单的功能堆砌，而是深刻理解了 Agent 应用从 0 到 1、从 1 到 100 的真实路径。

从想法到上线：60秒创建你的第一个 Agent

很多时候，最了解业务需求的是业务人员而不是技术人员，但传统的 Agent 开发需要编写大量代码，业务人员无法直接参与。AgentRun 的无代码创建能力打破了这个限制。

如图，创建一个 Agent 只需要三四个步骤：

第一步：在控制台选择创建 Agent
进入 AgentRun 控制台，点击”创建 Agent”按钮。

第二步：选择快速创建模式
在弹出的窗口中选择”快速创建”，平台会引导你通过简单的配置完成 Agent 创建。

第三步：配置你的 Agent
这是核心步骤，你需要完成几个简单的配置：

选择模型：从 Qwen、Claude、GPT-4 等主流模型中选择，也可以选择企业自建的私有模型。不知道选哪个？平台会根据你的任务类型智能推荐。
描述你的需求：直接用自然语言描述你的需求，比如”我想要一个能帮用户查询订单状态的客服 Agent”。AgentRun 的 AI 生成能力会自动理解你的需求，生成合适的 Prompt 和配置。更进一步，平台提供 Prompt AI 优化功能，会自动分析你的提示词，给出优化建议，让 Agent 的效果更好。
选择工具和能力：从工具市场选择 Agent 需要的能力。需要执行代码？添加 Code Interpreter。需要操作浏览器？添加 Browser Tool。需要调用企业内部 API？从工具市场搜索或一键创建 MCP。值得注意的是，Agent 本身、Sandbox、其他工具都可以以 MCP 形式提供——这意味着你可以让一个 Agent 调用另一个 Agent 的能力，实现能力的组合和复用。

第四步：点击创建
完成配置后，点击”创建”按钮，60秒后，你的 Agent 就可以开始工作了。

graph LR
    A[控制台] -->|点击创建Agent| B[选择快速创建]
    B --> C[配置Agent]
    C --> D[选择模型]
    C --> E[描述需求<br/>AI自动生成Prompt]
    C --> F[选择工具和能力]

    D --> G[点击创建]
    E --> G
    F --> G

    G --> H[60秒后可用]

    style B fill:#FFD700,stroke:#000,stroke-width:2px
    style C fill:#87CEEB,stroke:#000,stroke-width:2px
    style H fill:#32CD32,stroke:#000,stroke-width:2px,color:#fff

平台还支持版本管理和灰度发布，你可以安全地测试新版本，确认没问题后再全量发布。

除了快速创建，你还可以进行在线测试，并且可以进行多模型测试：

业务发展，Agent 也要进化

快速创建的 Agent 运行了一段时间，业务量不断增长，需求也越来越复杂。你开始遇到这些问题：

需要根据用户的历史行为做个性化推荐，但无代码配置无法实现复杂的逻辑判断
需要对接企业内部复杂的业务系统，需要复杂的数据转换和错误处理
需要对 Agent 的行为进行精细化控制，比如在特定条件下调用特定模型
需要优化性能，减少不必要的模型调用以降低成本

这时候，你需要的是代码级别的控制能力。传统的低代码平台到了这一步就束手无策，你要么忍受功能受限，要么推倒重来用高代码重写整个 Agent。但 AgentRun 提供了第三条路：一键转换为高代码。

如图所示，转换过程非常简单：

在 Agent 管理页面点击”转换为高代码”
平台会自动生成高质量的 Python 代码
代码结构清晰，包含完整的注释，易于理解和修改
你可以选择在 AgentRun 的在线 IDE 中直接编辑，也可以下载到本地使用你喜欢的开发工具

转换后的代码不是”垃圾代码”，而是遵循最佳实践、结构清晰的高质量代码。它保留了你之前所有的配置（模型选择、Prompt、工具配置），并将它们转换为规范的代码结构。

graph TB
    A[无代码 Agent] -->|业务发展| B{需求变化}
    B -->|简单需求| C[继续使用无代码<br/>配置调整]
    B -->|复杂需求| D[一键转换高代码]

    D --> E[生成高质量代码]
    E --> F[保留所有配置]
    E --> G[结构清晰易维护]
    E --> H[完整注释]

    F --> I[深度定制]
    G --> I
    H --> I

    I --> J[复杂业务逻辑]
    I --> K[性能优化]
    I --> L[系统集成]
    I --> M[精细化控制]

    J --> N[持续演进的 Agent]
    K --> N
    L --> N
    M --> N

    style D fill:#FFD700,stroke:#000,stroke-width:2px
    style I fill:#32CD32,stroke:#000,stroke-width:2px
    style N fill:#4169E1,stroke:#000,stroke-width:2px,color:#fff

高代码的深度定制能力

转换为高代码后，你进入了一个全新的世界。如图3所示，AgentRun 提供了完整的高代码开发环境。

让我们看一个真实的例子。假设你的客服 Agent 需要根据用户的VIP等级提供不同的服务策略。在无代码阶段，你只能配置统一的模型、Prompt 和工具，所有用户得到的都是相同的服务。但转换为高代码后，你可以实现精细化的个性化策略。

转换为高代码后，你获得了完全的控制能力。可以根据用户等级动态调整服务策略——VIP 用户使用更好的模型、更详细的 Prompt、更高优先级的响应速度，而普通用户则使用更经济的配置，在保证体验的前提下降低成本。可以实现智能成本优化，不再对所有请求都使用同一个模型，而是根据查询的复杂度、用户等级、历史行为等因素，动态选择最合适的模型。简单问题用小模型快速响应，复杂问题才使用大模型，实现成本和效果的最优平衡。

当然，可靠性和安全性也能得到全面增强。可以添加自动重试机制、超时控制、异常处理，当模型调用失败时自动切换到备用模型或返回预设的降级响应，确保服务始终可用。在返回结果前自动过滤敏感信息，添加内容审核，记录完整的审计日志。还可以实现多步骤的复杂业务流程，比如先查询用户历史订单，再根据订单状态决定下一步操作，最后整合多个数据源的信息给出综合建议。这些在无代码界面中难以实现的复杂逻辑，在高代码中都可以灵活实现。

更进一步：与 AgentRun 基础设施深度集成

转换为高代码后，你不仅可以编写业务逻辑，还可以深度利用 AgentRun 提供的各种基础设施能力。这些能力通过简单的配置和调用就可以使用，你不需要自己实现复杂的基础设施。

利用 AgentRun 的模型代理能力，你可以配置主模型和多个备用模型，启用熔断机制。当主模型出现问题时，系统会自动切换到备用模型，整个过程对用户透明，确保服务连续性。通过前置 Hook 可以在工具调用前自动注入用户凭证、记录请求日志、校验参数合法性；通过后置 Hook 可以对结果进行转换、记录审计日志、处理异常情况。这些通用逻辑不需要在每个工具中重复实现，只需配置一次即可。

对于耗时较长的操作，比如复杂数据分析、大文件处理，可以使用 AgentRun 的异步调用能力。Agent 不必阻塞等待，可以继续处理其他请求，当异步任务完成后通过回调通知结果。这种能力在构建高并发、高性能的 Agent 应用时尤为重要。

真实案例：FunctionQ 的演进之路

让我们回到第一篇文章提到的 FunctionQ 案例。这个函数计算智能助手的开发过程，诠释了从无代码到高代码的演进价值。

产品经理在第一天通过无代码界面快速创建了一个基础版本的 Agent，选择了 Qwen-Max 模型，配置了简单的 Prompt，从工具市场选择了”函数列表查询”、”函数详情查询”、”日志查询”等工具。当天下午，这个基础版本就上线了，开始服务内部测试用户。

第三天，测试用户开始反馈问题：Agent 调用工具时报”权限不足”错误，多个用户使用时数据混乱，成本增长很快但不知道花在哪里。这些问题在无代码界面无法解决，因为它们需要更复杂的逻辑控制。

第五天，开发团队将 Agent 转换为高代码，问题迎刃而解。通过配置 Hook 实现了动态凭证注入，根据用户 ID 自动获取对应的 AccessKey 和 SecretKey，在工具调用前注入到请求中，用户无感知但权限问题得到解决。利用 AgentRun 的会话亲和机制，确保同一用户的请求始终路由到同一实例，每个用户拥有独立的记忆存储，彻底隔离不同用户的数据。实现智能模型选择策略后，简单的列表查询使用 Qwen-Turbo，复杂的问题分析使用 Qwen-Max，在保持用户体验的前提下，成本降低了约 40%。

两周后，随着用户增长，团队继续优化。添加了智能缓存机制，相同的查询直接返回缓存结果，响应速度从 2 秒降到 0.1 秒。实现了多轮对话的上下文压缩，减少 Token 消耗。集成了企业内部的工单系统，Agent 可以自动创建和跟踪工单。根据问题类型实现了智能路由，自动分发到不同的专业 Agent。

如果没有”无代码到高代码”的能力，这个项目会面临什么？要么一开始就用高代码开发，验证周期从1天变成1周，错过最佳时间窗口。要么一直用无代码，无法解决权限、成本、性能等关键问题，最终不得不放弃。或者推倒重来，浪费前期所有积累，团队士气受挫。AgentRun 让团队可以从最快的方式开始，随着业务发展平滑演进，没有技术债务，没有推倒重来。

这不只是功能，更是理念

从无代码到高代码的演进能力，背后体现的是 AgentRun 对 Agent 应用开发的深刻理解。

Agent 应用的开发不是线性的。它不是从需求分析、设计、开发、测试、上线这样的瀑布流程。更多时候，它是一个快速验证、迭代优化、逐步完善的螺旋式过程。在想法验证阶段，你需要的是速度；在业务成熟阶段，你需要的是灵活性和控制力。没有一种工具能同时满足所有阶段的需求，但 AgentRun 通过”无缝演进”解决了这个问题。

技术选择不应该是一次性的决定。选择低代码就被锁定在低代码的能力边界内，选择高代码就要承受高门槛和漫长的开发周期。AgentRun 让你可以从最适合当前阶段的方式开始，随时根据需要演进到下一个阶段。更重要的是，这种演进是”零成本”的——转换为高代码不会丢失任何之前的配置和积累，生成的代码质量高、结构清晰，你可以在此基础上继续开发，而不是推倒重来。

这种设计理念的价值，在于它尊重了产品开发的真实规律。没有人能在第一天就预见所有需求，也没有团队愿意为了未来可能的需求而在初期就承担高昂的开发成本。AgentRun 让你可以轻装上阵快速验证，当需求明确后再深度投入，这才是最符合实际的开发路径。

立即体验

AgentRun 的无代码到高代码演进能力，现已开放体验：

快速创建：访问控制台，60秒创建你的第一个 Agent
深度定制：当需要更复杂功能时，一键转换为高代码
持续演进：利用 AgentRun 的基础设施能力，持续优化你的 Agent

从想法到上线，从原型到生产，AgentRun 始终是你最好的伙伴。

AgentRun 探秘：如何让 Agent 的模型又安全、又稳定、又可靠、又透明

Mon, 08 Dec 2025 00:49:32 +0800

在第一篇文章中，我们提到过一个真实用户的痛点：”我之前做过很多 AI 应用，流量少的时候还好，流量一多最头疼的就是模型的安全稳定。“这不是个例，而是几乎所有 Agent 应用开发者都会遇到的核心问题。

模型突然变慢、账号欠费、被临时封禁、存在安全问题、频繁限流——任何一个问题都可能让你的 Agent 应用在生产环境中瘫痪。更棘手的是，这些问题往往发生在流量高峰期，造成的损失难以估量。Agent 应用的可靠性，很大程度上取决于模型调用的可靠性。

AgentRun 通过完整的模型管理和治理能力，系统性地解决了这个问题。让我们看看它是如何做到的。

从混乱到有序：统一的模型管理

在没有统一管理之前，开发者面临的是这样的困境：不同的模型分散在各处，有的在代码里硬编码，有的在配置文件中，有的是环境变量。想要切换一个模型？需要改代码、测试、重新部署。想知道用了哪些模型、每个模型的调用量和成本？只能从账单倒推。

如图所示，AgentRun 提供了统一的模型管理界面。所有接入的模型都在这里集中展示和管理，你可以清楚地看到每个模型的状态、配置、使用情况。需要调整某个模型的配置？直接在界面修改，立即生效，无需重启服务。需要查看某个模型的调用量和成本？所有数据一目了然。

这种统一管理的价值，不仅仅是方便。更重要的是，它让模型从”散落的资源”变成了”可管理的资产”。你可以清晰地掌握企业使用了哪些模型、每个模型的健康状态、成本分布、使用趋势，为优化决策提供数据支撑。

接入灵活：支持所有主流模型

如图所示，AgentRun 在模型接入方面提供了极大的灵活性。

当你需要接入一个新模型时，可以通过搜索功能快速找到你想要的模型供应商——OpenAI、Anthropic、阿里云百炼、Minimax、智谱 AI 等主流供应商都已经内置支持。选择供应商后，可以看到该供应商提供的所有模型列表，选择你需要的模型，填入 API Key 等必要信息，就完成了接入。

但更强大的是自定义创建能力。如果你使用的是企业自建的私有模型，或者是 AgentRun 尚未内置支持的模型服务，可以通过自定义创建的方式接入。

只需要提供模型的 API 地址、鉴权方式、请求格式等信息，AgentRun 就能将其纳入统一管理。这种开放性确保了平台不会成为你的技术限制，而是真正成为你的技术赋能。

graph TB
    A[接入模型] --> B{选择方式}
    B -->|内置支持| C[搜索供应商]
    B -->|自定义| D[配置API信息]

    C --> E[选择模型]
    E --> F[填写API Key]

    D --> G[填写API地址]
    D --> H[配置鉴权方式]
    D --> I[定义请求格式]

    F --> J[接入完成]
    G --> J
    H --> J
    I --> J

    J --> K[统一管理]

    style A fill:#4169E1,stroke:#000,stroke-width:2px,color:#fff
    style J fill:#32CD32,stroke:#000,stroke-width:2px,color:#fff
    style K fill:#FFD700,stroke:#000,stroke-width:2px

模型治理：从单点到高可用

接入模型只是第一步，如何确保模型调用的稳定性和可靠性，才是生产环境的核心需求。这就是模型治理能力的价值所在。

如图所示，AgentRun 提供了强大的模型治理能力，底层基于开源项目 LiteLLM 构建，并无感部署在函数计算上。这意味着你无需关心 LiteLLM 的部署、运维、扩缩容等问题，平台已经帮你处理好了一切。

创建一个模型治理配置，你可以实现：

主备切换和 Fallback 策略：配置主模型和多个备用模型。当主模型出现限流、超时或故障时，系统会自动切换到备用模型继续服务。你可以配置多级 Fallback 策略，比如主模型是 GPT-4，第一备用是 Claude-3，第二备用是 Qwen-Max。即使多个模型同时出现问题，也能保证服务不中断。

负载均衡：如果你有多个相同模型的实例或账号，可以配置负载均衡策略，将请求分发到不同的实例。这不仅能避免单点过载，还能有效规避单个账号的限流问题。系统支持轮询、加权、最少连接等多种负载均衡算法。

智能路由：可以根据请求的特征（比如 Token 数量、优先级、用户等级等）将请求路由到不同的模型。简单查询使用经济的小模型，复杂分析使用强大的大模型，在成本和效果之间找到最优平衡。

熔断和限流：可以配置熔断策略，当某个模型的错误率超过阈值时自动熔断，避免持续调用失败的模型浪费时间和资源。可以配置限流策略，保护模型不被突发流量击垮，也避免超出厂商的限额导致账号被封。

重试机制：当模型调用失败时，系统会根据配置自动重试。可以设置重试次数、重试间隔、指数退避等策略，最大化调用成功率。

所有这些能力，都是通过可视化界面配置，无需编写代码。配置完成后，立即生效，你的 Agent 就拥有了企业级的模型高可用能力。

安全透明：每一次调用都清晰可见

模型治理不仅要保证稳定性，还要保证安全性和透明度。

安全方面，AgentRun 提供了完整的安全围栏机制。所有模型调用在发送前都会经过内容审核，自动过滤敏感信息、违规内容。可以配置自定义的安全策略，比如禁止某些关键词、限制输出长度、脱敏处理等。所有的 API Key 和敏感凭证都经过加密存储，在传输和使用过程中严格保护，确保不会泄露。

透明度方面，AgentRun 提供了细粒度的监控和分析能力。每个模型的调用次数、成功率、平均延迟、Token 消耗都有详细记录。可以按时间、按 Agent、按用户等多个维度进行统计分析。当某个模型出现异常时，系统会自动告警并提供详细的诊断信息，帮助你快速定位和解决问题。

更重要的是，所有的治理策略执行过程都有完整的日志记录。当发生主备切换、熔断、限流等事件时，你可以在日志中看到完整的决策过程和执行结果。这种透明度让你对系统的运行状态有充分的掌控感，也为事后分析和优化提供了宝贵的数据。

两种使用方式：普通用户 vs 高级用户

AgentRun 的模型治理能力设计得很巧妙，它既能满足普通用户的”开箱即用”需求，也能满足高级用户的”深度定制”需求。

对于普通用户，你甚至不需要知道”模型治理”这个概念。当你在创建 Agent 时选择模型，平台会自动为你配置基础的治理策略——自动重试、基本的容错、简单的监控。这些能力默认开启，无感使用，你只需要关注 Agent 的业务逻辑即可。

对于高级用户，你可以深入到模型治理的各个细节进行定制化配置。可以精确设置每个模型的权重、超时时间、重试策略、熔断阈值。可以自定义路由规则，实现复杂的流量调度逻辑。更进一步，因为底层使用的是开源的 LiteLLM，你甚至可以自己管理 LiteLLM 实例，进行更深度的定制化开发或二次开发。比如实现自己的路由算法、添加自定义的中间件、对接企业内部的审计系统等。

这种”简单的简单，复杂的可能”的设计理念，让不同技术水平的用户都能在 AgentRun 上找到适合自己的使用方式。

真实案例：从频繁故障到稳定可靠

让我们看一个真实的案例。某电商企业开发了一个智能客服 Agent，最初直接调用 OpenAI 的 GPT-4 模型。上线初期运行良好，但随着业务增长，问题开始暴露：

第一个问题出现在一个周五的下午。OpenAI 的服务出现短暂故障，所有调用都超时失败。客服 Agent 完全瘫痪，大量用户投诉，客服热线被打爆。团队紧急切换到备用的 Claude 模型，但因为代码里硬编码了 GPT-4 的 API，切换过程花了 2 个小时，期间造成了严重的业务损失。

第二个问题发生在月底。由于流量激增，GPT-4 的调用量超出了账号限额，触发了限流。大量请求返回 429 错误，Agent 响应速度急剧下降。团队只能临时申请提额，但审批流程需要几天时间。

第三个问题是成本问题。所有查询都使用 GPT-4，但实际上 80% 的查询都是简单问题（查订单、查物流），根本不需要 GPT-4 的能力。成本居高不下，但不知道如何优化。

引入 AgentRun 的模型治理后，这些问题都得到了解决。团队配置了完整的模型治理策略：主模型是 GPT-4，备用模型是 Claude-3 和 Qwen-Max。当 GPT-4 出现故障时，系统会在毫秒级自动切换到备用模型，整个过程对用户透明。配置了基于语义的智能路由，简单查询自动使用 GPT-3.5-turbo，复杂问题才使用 GPT-4，成本降低了约 50%，用户体验没有明显变化。设置了限流和告警策略，当接近限额时自动降低调用频率并通知团队，避免触发硬限流。

更重要的是，团队对系统有了充分的掌控感。通过可观测平台，可以实时看到每个模型的健康状态、调用分布、成本趋势。当出现异常时，能够第一时间发现并处理。从频繁故障、被动应对，变成了主动管理、稳定可靠。

为什么 AgentRun 选择基于 LiteLLM 构建模型治理能力，而不是完全自研？

首先，LiteLLM 是经过市场验证的成熟方案。它支持 100+ 种 LLM API，统一了不同厂商的接口差异，这是需要大量适配工作才能达到的效果。选择 LiteLLM 意味着我们站在了巨人的肩膀上，可以更快地为用户提供价值。

其次，开源意味着透明和可控。用户不用担心被平台锁定，如果有特殊需求，完全可以基于 LiteLLM 进行定制开发。这种开放性是 AgentRun “开放不锁定”理念的体现。

最重要的是，AgentRun 的价值不在于重复造轮子，而在于让好的轮子更好用。我们将 LiteLLM 无感部署在函数计算上，用户无需关心部署、运维、扩缩容等问题。我们在 LiteLLM 之上构建了可视化的配置界面、完整的监控体系、与 Agent 平台的深度集成。我们让原本需要专业知识才能用好的工具，变成了人人都能用的能力。