一名云计算从业者的思考

大家都在搜：

热搜词1 热搜词2 热搜词3

当前位置：首页 > 产品思考 > 正文内容

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

anycodes2个月前 (04-21)产品思考1970

> 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 机制（维持持续运转）

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

![第一性原理：Agent 生命体结构示意图](https://kroki.io/mermaid/png/eNptkM1OIkEUhfc-BS_gQsHtJCY-gZldhYXxP5lIwjCZLaabH6HpRiAk2gjyJ62CYJwZsLvBl6l7q3rlK3ibbmeDtauq891zzj36kfi9f7KXTEW-76xF6OwmEikmhkM-S2N6AHpLlLNYzMpB99293j4-PEthYyj_WPHI-vq3yM7pz_295AHDggmuQgq02tAsgpaR3QxcWVJTwDXi_ycvod3D1K_kGQOzCfPK51RRa8HlnM-r4fi1JRPOD7w2GF_cyL91r6PKpwUaZdGz5bjk3T9DwYqv6jeZ7DzSF1RLYNegV_cUC7Ucd3pfiKMMGzZ2Jlh0Ue_LiSJqFkz7kJl-IY4x4dr81YBsBhoWWRDLZ7own_A2F0YPWgaFNxiqLdHqU1lfnD4X-hg6Crd73K74YOEfPUp9CkY9vkJvMsi-iFGdaJl74DMHVQPMBW0M82WiueNAoS0HKuQrq3SUybZGrkQT6q9j2SpoSDReDEiwysUYGCXvLk-ccKrYbMixyt2Jn9YxvAeNfjF981k2FkBbTL6ZoPlRUTsXzghGd_z1liBKjvlL-TbiTjc0i4bLCW5bYdkPDnJVzQ==)

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

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

**1. 无状态的幻觉灾难**

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

**2. 执行环境的裸奔**

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

**3. 编排的失控**

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

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

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

![AgentRun 底层逻辑示意图](https://kroki.io/mermaid/png/eNptks9y0lAYxfc-BS_QV3DG8d90oQvtLtNFGi-YgSZOSKrdARYKaQBRhFpmiqi0EYdAq0MDKeRl8t2bvIU3uaHNgizuZCbn5Dvnd790Tn4vvOUVNbXz5EGKPo8ySFJfaRK3fkmRdh9aS2_5ZTe1tfUwtS2lFZ6LzvtPuD3Bn1vkr0Oc_m70n-hgqtD1EikHiCPDc-I0k7J7xWNREbQcr8rKIQerEWlMNuu29_c1CXFQrpPOn82SF0jl9-ScKHCe89Of_tisep1FOaTKEheMzGB065cMv1TbLH2Owon9BfS-Q2_lT68SHaNmbGw-w-FZFRcnuOCQhevZDf9mQtqxOlGQFZb332kqhWJ1Qe_504-wuKAWqFaCcj1OEHVlaZGgKaJK2Vg1KJvB6TXWf4Vyax60vzH5XW8WR5ZEOozD3SG4XdJr4cYlNRB9hgtFaNaDiyqzrUGwOdTCZxCHjaI3L4PRgfEplMywizUFt8IsIZC4hJQWM2xZaGyytKgSmwM4Pwl-X4FuJkhRPmzEoSTEju4_qDfhkxEUzjx3EHNiXCLpDp_P0kt0QB_AfAbNVvj32qU_MOLoMRW2GXmZ4hXpjfqrOflq0L5QnYWMbktg2_7xCB_FlWM2ke0ZQm_2eCHLsbvHR33SH4Yu3aSg6L34eimextisi6vog8pRrT-p4OsavilQk2frnn2CO8fgzIgzXjcKIUW2pwdyTmMZB4ZnL8A68-a1kK7bo7B9d0xXNsFsHS65MSwLhXiH6D-8sr_c)

当我从零开始设计 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 的思维空间，让它很快达到上下文极限，无法继续处理后续的复杂逻辑。

![Token 爆炸示意图](https://kroki.io/mermaid/png/eNplkc1u00AUhfc8xagrWHRBl1kg0aZ_LMqmEgsrSAiBkEBUQkiwTNI4f2A7Vdo6LWlIUKFORe1WSUMygeZlfO-M34LrO61UhFdXnvudc-bMyzdbH56_evbuvdjM3hH0PbSg5qDXyAgdXkF4qK-aYH8H6UHVT_ZmIH_EYyk2cmJ-_oFYtLAtoTqi5copDgIseVD_osOeCn2MvHh8urn1-sVbiCZgj-LpPtby2K7xP3VYAnugC7s5tl1kvSULphKDXkZgp5SON5J4tJ1UHPW1n7QuxRODLDGStdR0SKkI-WdHkIE54bziI2VmLMvYsmVSZoQBwN5Wwy7mp7h3zkCabzLA_YmhlplasebQDSD6fT-tJ-Xh2MGj4rXL47sbTxfuzd0mVm-IhYyAsg1nLdWXiT8Ep6t2g_-gFYbWLGJ0KAn507xdPd0DvnWg3kV_dB0gqVDNrpGGnWosP-PPHsXGWZ5WjeqqUeV5jed1CzuF5KDBDqSqR5_0bCeWLvpd1f8FxyfscFlC2UjaebwoxmMHvAjdEyO5zjKPqPwmB6Xa4IxKqOuogC03lmXBzyxUtayKY-We64te2imlbAe5vyM0UFs=)

这不是个别案例，这是结构性的问题。上下文污染、算力浪费、单点故障——这三重伤害叠加在一起，是 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 是过度工程化吗？

![过度工程化挑战示意图](https://kroki.io/mermaid/png/eNp1ks1S4kAQx-_7FHmA9UC4eVir1r3sbdfyNpUDZWFpFQVViLVXBF0gazDIh0ESFQXBjw3FoiwkK3mZdM_kLRzix6LROcyhu3_9__f0rMYSP1bWIsmUsPzlg8DP983oRmo9ESe4p0LOwpMROFl206W10ryAdYtl777GV5MR1HrMyYF1Dn_btPsLdmugHixIwtzcJ-FbMkHw9xnWxqyToZkxBwPV0gs1H1vkqrCnzGDuSHmP9C8u9CQYInBXhoLijg5BbrLONnabHGfDgWu3sdLD_ZL0mhEJHdjUPqb2DcotzKuoX3Mx70oLlIYJymnUe3iSh5aCRmbqyByjVoZWH4udGVOL_8cJEc84BbWE-iUa7QdT05c6PfKqjqensZ-RXjMi4Tnm6F5d4XZ4KVbzWBnShozahJUOAkDYX5WSe5ylOwDzENMdd1TkBr1KnRZzL58s5JOfI7FIfCVK2OSC9bYg_xOPVM6gkWXN5vP84mztUzAcCE5nfSsovhUM4v71GPCTS9GNzVgqRKhdZqY1L3jaEM1bPhX-qzCn8VHwthzYUWjjD22YbLjDFy-900R8buI6Bq3WH340Fi6gX-WfGWTeDXcLfBtgW8ycSPfuHX5g)

我必须诚实面对这个反驳。最有力的质疑是：**智能 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 正在铺设这条从模块到生命体的轨道。

---

## 三件你可以现在就做的事

![实操建议示意图](https://kroki.io/mermaid/png/eNplkN1KAkEYhs-7ir0Bb6FAAw8LsaNhEdENhYUJ3aUgg5XWVk1zD0JSqBT8Q9A9SHHXTbyZ-fMumsZwZZuDGQbe9_memWsV3mZy6YImJc9PJL4SEGoAOx5zfGZUaNfE8w-2mBCzhbyaLEUip1IsB_MZ5Z68OdgeUX9M_dnO6LHNHM_sswdBEds-91sp8WxJiup5NQuYNWX9xqEgh6OcWZISil5UAB406euEVG369EnaHulX5YAuaMInGbtIXd0AfhBjiGtj5NZx05JDqZh2l7qEqqprCuAJ5D6TtkXXDrYMvB7x667T3Hf2PFFKKEVd1VLRdBbsOitcGbKlSdY2WU7ZwkPuC_UXpD4gX0Oymf29JBgTIgTq4nUH9bieLmQBnlfRpsXvcigigHqBS2_fSaP8Xz2QFqTjqXEI-YeXu9QckZ6Lt4_I7eJ6H_krbHwf-XJ8uPYD9kPzlw==)

如果你是正在落地 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。本文所有观点均为个人思考，不代表任何组织立场。*
以上是完整的文章正文。整体做了以下处理：

扫描二维码推送至手机访问。

本文链接：https://www.runor.cn/?id=49

分享给朋友：

返回列表

上一篇：Agent平台：脏活累活，也许才是竞争力的基础

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

刘博说云

大家都在搜：

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

“为 AgentRun二进宫：一个关于 Serverless 与 Agent Infra 的未竟执念” 的相关文章

产品对标的陷阱：为何技术优势不等于市场成功

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

流量漩涡中的产品决策：从AI热潮看独立思考的稀缺性

"用户第一"的悖论：从三朵云看产品设计的中庸之道

自证害死的不仅仅是产品经理，更是一个团队

发表评论

Powered By Z-BlogPHP. Theme by TOYEAN.

刘博说云

大家都在搜：

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

“为 AgentRun二进宫：一个关于 Serverless 与 Agent Infra 的未竟执念” 的相关文章

产品对标的陷阱：为何技术优势不等于市场成功

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

流量漩涡中的产品决策：从AI热潮看独立思考的稀缺性

"用户第一"的悖论：从三朵云看产品设计的中庸之道

自证害死的不仅仅是产品经理，更是一个团队

发表评论取消回复

Powered By Z-BlogPHP. Theme by TOYEAN.

发表评论