刘博说云

托管 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 平台的深度集成。我们让原本需要专业知识才能用好的工具，变成了人人都能用的能力。

AgentRun 探秘：如何把 LangChain 等框架部署到 AgentRun 上

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

当你已经用 LangChain、AgentScope、LangGraph 等框架开发了 Agent 应用，如何让它们享受 AgentRun 提供的 Serverless 运行时、企业级 Sandbox、模型高可用、全链路可观测 等能力？好消息是，你几乎不需要改动现有代码，只需要简单的适配就可以迁移到 AgentRun。

这篇文章将通过真实的代码示例，展示如何将不同框架的 Agent 应用部署到 AgentRun 上，以及如何充分利用 AgentRun 的各种能力。

为什么要部署到 AgentRun？

在讨论具体的集成方案前，让我们先明确一个问题：如果你的 Agent 应用已经在本地或自建服务器上运行良好，为什么还要迁移到 AgentRun？

答案很简单：从开发环境到生产环境，有一道巨大的鸿沟。 本地运行只需要考虑功能实现，但生产环境需要考虑性能、稳定性、成本、安全、可观测等一系列问题。AgentRun 提供的不是又一个 Agent 框架，而是让你的 Agent 能够以企业级标准运行的完整基础设施。

具体来说，部署到 AgentRun 后，你能获得：零运维的 Serverless 运行时（自动扩缩容、按量付费），企业级的 Sandbox 环境（高性能、安全隔离），模型高可用保障（自动熔断、多模型 Fallback），全链路可观测（完整的 Trace、成本归因），以及统一的工具和 MCP 管理。

graph LR
    A[本地开发] -->|传统部署| B[自建服务器]
    A -->|AgentRun| C[Serverless 平台]

    B --> D[需要自己管理<br/>• 服务器运维<br/>• 扩缩容<br/>• 监控告警<br/>• 成本优化]

    C --> E[平台自动提供<br/>• 零运维<br/>• 自动弹性<br/>• 全链路可观测<br/>• 成本透明]

    style B fill:#ffd93d
    style C fill:#51cf66,color:#fff
    style D fill:#fff,stroke:#ff6b6b,stroke-width:2px
    style E fill:#fff,stroke:#51cf66,stroke-width:2px

快速上手：5分钟部署你的第一个 LangChain Agent

让我们从最流行的 LangChain 框架开始，通过一个完整的例子展示如何将 LangChain Agent 部署到 AgentRun。

第一步：安装 Serverless Devs

AgentRun 使用 Serverless Devs 作为部署工具。如果你有 Node.js 环境，一行命令即可安装：

npm i -g @serverless-devs/s

第二步：创建项目

使用脚手架快速创建项目（注意：需要 Python 3.10 及以上版本）：

# 初始化模板
s init agentrun-quick-start-langchain

# 进入代码目录
cd agentrun-quick-start-langchain/code

# 初始化虚拟环境并安装依赖
uv venv && uv pip install -r requirements.txt

第三步：配置认证信息

通过环境变量（建议使用 .env 文件）配置你的 AgentRun 访问凭证：

export AGENTRUN_ACCESS_KEY_ID="your-access-key-id"
export AGENTRUN_ACCESS_KEY_SECRET="your-access-key-secret"
export AGENTRUN_ACCOUNT_ID="your-account-id"
export AGENTRUN_REGION="cn-hangzhou"

第四步：理解集成方式

这是最关键的部分。打开生成的代码，你会看到集成非常简单：

from agentrun.integration.langchain import model, sandbox_toolset
from agentrun.server import AgentRunServer

# 使用 AgentRun 的模型（自动享受高可用、熔断等能力）
llm = model("<your-model-name>")

# 使用 AgentRun 的 Sandbox 工具
tools = sandbox_toolset(
    template_name="<your-sandbox-name>",
    template_type=TemplateType.CODE_INTERPRETER,
    sandbox_idle_timeout_seconds=300,
)

# 创建 LangChain Agent（和原来的代码完全一样）
agent = create_agent(
    model=llm,
    tools=tools,
    system_prompt="你是一个智能助手"
)

# 定义调用函数
def invoke_agent(request):
    result = agent.invoke({"messages": request.messages})
    return result["messages"][-1].content

# 启动 HTTP Server（提供 OpenAI 兼容的 API）
AgentRunServer(invoke_agent=invoke_agent).start()

核心要点：

model() 函数返回的是 LangChain 可以直接使用的模型对象
sandbox_toolset() 返回的是 LangChain Tools 列表
你的 Agent 创建代码完全不需要改动
AgentRunServer 自动处理 HTTP 请求，提供标准的 OpenAI API

第五步：本地测试

启动服务后，可以通过 HTTP 请求测试：

curl 127.0.0.1:9000/v1/chat/completions \
  -X POST \
  -H "content-type: application/json" \
  -d '{"messages": [{"role": "user", "content": "通过代码查询现在是几点?"}], "stream":true}'

第六步：部署到生产环境

项目中已经包含了 s.yaml 配置文件。你只需要修改其中的 role 字段为你的阿里云角色：

role: acs:ram::{您的阿里云主账号 ID}:role/{您的阿里云角色名称}

配置部署密钥：

s config add
# 按照引导输入 Access Key ID 和 Secret，记住密钥对名称（如 agentrun-deploy）

执行部署：

s deploy -a agentrun-deploy

部署完成后，你会得到一个 HTTPS URL，就可以在生产环境调用你的 Agent 了。

不同框架的集成案例

AgentRun 不仅支持 LangChain，还深度集成了主流的 Agent 开发框架。所有框架都遵循同样的理念：通过简单的适配层，让你的代码无缝迁移到 AgentRun，享受企业级能力。

LangGraph：工作流编排

LangGraph 是 LangChain 团队推出的工作流编排框架，适合构建复杂的多步骤 Agent。集成方式和 LangChain 类似：

from agentrun.integration.langgraph import model, tools
from langgraph.graph import StateGraph, MessagesState
from langgraph.prebuilt import ToolNode

# 使用 AgentRun 的模型和工具
llm = model("<your-model-name>").to_langgraph()
agent_tools = tools()

# 构建 LangGraph 工作流（和原来的代码一样）
def call_model(state: MessagesState):
    messages = state["messages"]
    response = llm.invoke(messages)
    return {"messages": [response]}

workflow = StateGraph(MessagesState)
workflow.add_node("agent", call_model)
workflow.add_node("tools", ToolNode(agent_tools))
workflow.set_entry_point("agent")

# 定义条件边...
app = workflow.compile()

# 调用
result = app.invoke({"messages": [HumanMessage(content="查询上海天气")]})

LangGraph 的优势是可以精确控制 Agent 的执行流程，比如条件分支、循环、并行执行等。部署到 AgentRun 后，这些复杂的工作流都能自动享受弹性伸缩和可观测能力。

AgentScope：多智能体协作

AgentScope 是阿里达摩院开源的多智能体框架，特别适合构建多Agent协作场景。集成方式：

from agentrun.integration.agentscope import model, tools
from agentscope.agent import ReActAgent
from agentscope.tool import Toolkit

# 使用 AgentRun 的模型和工具
llm = model("<your-model-name>").to_agentscope()
agent_tools = tools()

# 注册工具到 Toolkit
toolkit = Toolkit()
for tool in agent_tools:
    toolkit.register_tool_function(tool)

# 创建 Agent（和原来的代码一样）
agent = ReActAgent(
    name="assistant",
    sys_prompt="你是一个智能助手",
    model=llm,
    toolkit=toolkit,
)

# 调用
result = await agent.reply(Msg(name="user", content="查询上海天气", role="user"))

AgentScope 的优势是对多Agent系统的原生支持，包括Agent之间的通信、协调、记忆共享等。部署到 AgentRun 后，每个 Agent 都在独立的隔离环境中运行，确保安全性。

PydanticAI：类型安全的 Agent 框架

PydanticAI 是一个新兴框架，强调类型安全和结构化输出。集成方式：

from agentrun.integration.pydantic_ai import model, tools
from pydantic_ai import Agent

# 使用 AgentRun 的模型和工具
llm = model("<your-model-name>").to_pydantic_ai()
agent_tools = tools()

# 创建 Agent
agent = Agent(
    llm,
    instructions="Be concise, reply with one sentence.",
    tools=agent_tools,
)

# 同步调用
result = agent.run_sync("上海的天气如何？")

# 异步调用
result = await agent.run("上海的天气如何？")

PydanticAI 的优势是强类型和结构化输出，特别适合需要严格数据验证的企业场景。

充分利用 AgentRun 的核心能力

将 Agent 部署到 AgentRun 后，你不仅获得了 Serverless 运行环境，还可以深度利用平台提供的各种企业级能力。

模型高可用：告别单点故障

部署到 AgentRun 后，你的 Agent 自动享受模型高可用能力。当你配置的主模型出现故障、限流或超时时，系统会自动切换到备用模型，整个过程对你的代码完全透明。

在 AgentRun 控制台配置模型代理时，可以设置：主模型（如 GPT-4），备用模型列表（如 Claude-3、Qwen-Max），熔断策略（错误率阈值、超时时间），负载均衡策略（轮询、权重、最少连接）。

你的代码完全不需要改动，只需要在创建模型时使用 AgentRun 的模型名称，所有的容错、切换、负载均衡都由平台自动处理。

企业级 Sandbox：安全执行代码

AgentRun 提供的 Sandbox 不是简单的代码执行环境，而是企业级的安全隔离沙箱。每个 Sandbox 实例都是独立隔离的，支持多种执行类型：

Code Interpreter 支持 Python、Node.js、Java、Bash 等语言，可以执行数据分析、文件处理等任务。Browser Tool 提供浏览器自动化能力，支持网页爬取、表单填写、截图等操作。All In One 集成了代码解释器和浏览器工具，提供更丰富的交互能力。

使用时，通过 sandbox_toolset() 函数就可以获取相应的工具集合，这些工具会自动转换为你使用的框架所需的格式。

工具和 MCP：标准化集成

AgentRun 提供统一的工具管理和 MCP（Model Context Protocol）机制。你可以从工具市场选择现成的工具，也可以自定义工具并发布到市场。

更强大的是 MCP 的 Hook 机制。通过前置 Hook，可以在工具调用前自动注入用户凭证、记录请求日志、校验参数合法性。通过后置 Hook，可以对结果进行转换、记录审计日志、处理异常情况。这些通用逻辑不需要在每个工具中重复实现，大大提升了开发效率。

全链路可观测：不再是黑盒

这是 AgentRun 最强大的能力之一。你的代码不需要做任何改动，平台会自动记录 Agent 的完整执行链路。

在可观测平台上，你可以看到：Agent 接收到用户请求的时间和内容，调用了哪个模型、使用了多少 Token、花费了多少钱，调用了哪些工具、每个工具的执行时间和结果，访问了哪些知识库、检索了多少数据，每个环节的耗时分布，完整的调用链 Trace。

这些能力都是平台自动提供的，通过探针注入实现，无论是高代码还是低代码创建的 Agent，都自动享受这些可观测能力。

记忆和知识库：数据不出域

AgentRun 深度集成了 RAGFlow、Mem0 等开源项目，提供灵活的记忆和知识库管理。你可以选择一键托管模式，由平台统一管理部署运维，享受 Serverless 的弹性和按量付费优势。也可以选择绑定模式，将 Agent 连接到已经部署在企业 VPC 或 IDC 内的实例，数据完全不出企业内网。

这种灵活性让你可以根据数据的敏感级别选择不同的策略：核心业务数据私有化部署，一般数据托管上云，在安全性和便利性之间找到最佳平衡。

AgentRun 探秘：为什么要对 MCP 做进一步的拓展（智能路由，规则路由，Hook能力）

Mon, 08 Dec 2025 00:45:42 +0800

MCP（Model Context Protocol）正在成为 Agent 应用中工具调用的事实标准。它提供了一套统一的协议，让 Agent 可以标准化地调用各种工具和 API。但当我们真正开始构建企业级 Agent 应用时，发现原生 MCP 协议解决了”如何调用”的问题，却没有解决”如何用好”的问题。

企业级 Agent 应用面临的四大挑战

挑战一：相关工具太多，配置和管理成本高

用户说”写一段代码读取 data.csv 文件，处理后保存为 result.csv”。系统提供了代码解释器 Sandbox，包含多个独立的工具：execute_code 执行代码、upload_file 上传文件、download_file 下载文件、delete_file 删除文件、list_files 列出文件等。

问题是什么？每个工具都需要单独配置 Sandbox 参数（超时时间、环境变量、资源限制等），5 个工具就要配置 5 次，容易遗漏或不一致。在 Agent 配置中需要逐一声明这 5 个工具，管理起来很繁琐。当 Sandbox 参数需要调整时（比如增加超时时间），需要修改 5 处配置。更头疼的是，Agent 的 Prompt 需要详细描述这 5 个工具的用途和使用方法，Prompt 变得冗长复杂。

本质问题：原生 MCP 把一个完整能力拆成了多个孤立工具，但这些工具本应作为一个整体被使用和管理。

挑战二：工具越来越多，Agent 不知道该用哪个

平台上有几十个甚至上百个 MCP 工具：code-executor-mcp、browser-automation-mcp、cloud-logs-mcp、database-query-mcp……当用户发起请求，Agent 如何选择？

传统做法是在 Prompt 中详细描述每个工具的用途，让大模型自己判断。但这会导致：Prompt 过长影响理解和成本；更致命的是，无法处理模糊请求——用户说”跑个脚本”、”看看服务有没有问题”，这些表达没有明确关键词，单纯靠 Prompt 描述很难准确匹配。

本质问题：原生 MCP 是纯协议，不关心”该用哪个工具”，只关心”如何调用工具”。

挑战三：需要用户的云服务密钥，但绝对不能暴露

构建云厂商智能助手，用户 A 说”查询我的错误日志”，需要调用云厂商 API，这需要用户 A 的 AccessKey 和 SecretKey。密钥不能硬编码（每个用户不同），不能让 Agent 持有（安全风险），不能让用户每次输入（体验差），也不能明文存储（合规风险）。

需要的是：在工具调用前动态获取并注入密钥，调用后清理痕迹，全程对 Agent 和大模型透明，还要记录审计日志满足合规要求。

本质问题：原生 MCP 没有提供在工具调用前后插入自定义逻辑的机制。

这四大挑战可以总结为一个核心问题：原生 MCP 提供了标准化的调用协议，但缺乏企业级场景所需的工具协作、智能选择、安全治理和状态管理能力。

graph TB
    A[原生 MCP 协议] --> B[标准化的工具调用]

    B -.-> C1[❌ 挑战1<br/>工具孤立，状态不共享]
    B -.-> C2[❌ 挑战2<br/>工具选择依赖 Prompt]
    B -.-> C3[❌ 挑战3<br/>无法插入安全逻辑]
    B -.-> C4[❌ 挑战4<br/>无状态，无法连续操作]

    C1 --> D[企业级 Agent 应用<br/>无法落地]
    C2 --> D
    C3 --> D
    C4 --> D

    style A fill:#e3f2fd
    style D fill:#ffebee,color:#c62828
    style C1 fill:#fff3e0
    style C2 fill:#fff3e0
    style C3 fill:#fff3e0
    style C4 fill:#fff3e0

AgentRun 的解决方案：三大扩展机制

面对这些挑战，AgentRun 对 MCP 进行了三个方向的深度扩展，每个扩展都是为了解决一类核心问题。

解决方案一：MCP 打包机制 - 让工具协作成为可能

核心思路：将相关的工具打包成一个完整的能力单元，共享实例和状态。

如何实现？ 创建 MCP 工具时，指定类型（sandbox、browser、memory 等），配置参数，选择要包含的工具列表。所有包含的工具自动共享同一个底层实例。

{
  "name": "code-executor-mcp",
  "type": "sandbox",
  "description": "完整的代码执行环境",
  "sandboxId": "sandbox-xxx",
  "includedTools": [
    "execute_code",
    "upload_file", 
    "download_file",
    "delete_file"
  ],
  "config": {
    "timeout": 30000,
    "pythonVersion": "3.10"
  }
}

对于 Browser 的特殊支持： Browser MCP 支持配置 CDP 端点，包含的 18 个浏览器工具（点击、输入、导航、截图等）自动共享同一个浏览器实例，保持 cookies 和 session。

{
  "name": "browser-automation-mcp",
  "type": "browser",
  "config": {
    "cdpEndpoint": "ws://browser.example.com/cdp",
    "browser": "chrome",
    "viewportSize": "1280x720"
  },
  "includedTools": [
    "browser_navigate", "browser_type", 
    "browser_click", "browser_screenshot"
  ]
}

解决了什么？ 配置集中管理，一次配置所有工具继承；状态自动共享，文件路径、环境变量在工具间保持；降低 Agent 复杂度，从”理解 4 个独立工具”变成”使用一个完整能力”。

解决方案二：智能路由 - 让工具选择自动化

核心思路：通过规则路由和语义路由的组合，自动将用户请求匹配到最合适的 MCP 工具。

规则路由：处理明确意图

配置关键词或正则表达式，快速匹配常见场景。

routing:
  rules:
    - condition: 
        keywords: ["执行代码", "运行Python"]
      target: code-executor-mcp

    - condition:
        regex: ".*打开网页.*|.*浏览器.*"
      target: browser-automation-mcp

语义路由：处理模糊意图

当规则路由无法匹配时，使用 embedding 模型计算用户请求与每个 MCP 工具描述的语义相似度，选择最匹配的工具。

semantic:
  enabled: true
  threshold: 0.75
  modelConfig:
    type: "system"
    modelName: "text-embedding-3-small"

工作流程：

graph LR
    A[用户请求] --> B{规则路由}
    B -->|命中关键词| C[立即路由到目标 MCP]
    B -->|无匹配| D[语义路由]
    D --> E[计算语义相似度]
    E --> F{相似度 > 0.75?}
    F -->|是| G[路由到最相似的 MCP]
    F -->|否| H[提示无法处理]

    style B fill:#51cf66,color:#fff
    style D fill:#51cf66,color:#fff
    style C fill:#4169e1,color:#fff
    style G fill:#4169e1,color:#fff

解决了什么？ 不需要在 Prompt 中描述所有工具，减轻大模型负担；规则路由快速处理常见场景，语义路由兜底处理边缘情况；支持自然语言多样性，用户怎么说都能匹配；降低 Token 成本，工具选择不消耗大模型资源。

解决方案三：Hook 机制 - 让企业级需求落地

核心思路：在 MCP 调用前后提供标准化的拦截点，插入自定义逻辑。

前置 Hook：Token 换密钥并注入

async function beforeExecute(context) {
  const { token, params } = context;

  // 1. 验证 Token，获取用户身份
  const user = await TokenService.verify(token);

  // 2. 从密钥管理服务获取该用户的云服务密钥
  const credentials = await SecretManager.get(user.id, 'cloud-api');

  // 3. 动态注入到工具参数中
  params.accessKey = credentials.accessKey;
  params.secretKey = credentials.secretKey;

  return params;
}

后置 Hook：审计和清理

async function afterExecute(context, result) {
  // 记录审计日志
  await AuditLog.create({
    userId: context.user.id,
    action: context.toolName,
    timestamp: Date.now()
  });

  // 清理敏感信息（如果结果中包含）
  delete result.credentials;

  return result;
}

完整流程：

sequenceDiagram
    participant U as 用户 A
    participant A as Agent
    participant Pre as 前置 Hook
    participant SM as 密钥服务
    participant Tool as MCP 工具
    participant Post as 后置 Hook

    U->>A: "查询我的错误日志"<br/>(携带 Token)
    A->>Pre: 调用 cloud-logs-mcp

    rect rgb(200, 230, 200)
        Note over Pre,SM: 安全处理
        Pre->>Pre: 验证 Token
        Pre->>SM: 获取用户密钥
        SM-->>Pre: AccessKey + SecretKey
        Pre->>Pre: 注入到参数
    end

    Pre->>Tool: 执行工具<br/>(使用用户密钥)
    Tool-->>Post: 返回结果

    rect rgb(200, 220, 240)
        Note over Post: 审计和清理
        Post->>Post: 记录审计日志
        Post->>Post: 清理敏感信息
    end

    Post-->>A: 返回安全结果
    A-->>U: 展示错误日志

    Note over U,Post: 密钥从未暴露给 Agent 和大模型

解决了什么？ 密钥零暴露，从未出现在 Agent、大模型、日志中；多租户自动隔离，每个用户获取各自的密钥；关注点分离，鉴权、凭证、审计等横切逻辑统一处理；满足合规要求，审计日志自动记录。

AgentRun 的完整技术架构

三大扩展机制协同工作，形成完整的企业级 MCP 调用体系：

graph TB
    A[用户请求] --> B[智能路由层]

    subgraph route[智能路由]
        B --> C1[规则路由<br/>关键词/正则]
        B --> C2[语义路由<br/>相似度计算]
    end

    C1 & C2 --> D[选定 MCP 工具]

    D --> E[前置 Hook]

    subgraph hook1[前置处理]
        E --> E1[Token 验证]
        E1 --> E2[获取密钥]
        E2 --> E3[参数注入]
    end

    E3 --> F[MCP 工具包]

    subgraph mcp[MCP 打包 - 状态共享]
        F --> F1[工具 1]
        F --> F2[工具 2]
        F --> F3[工具 3]
        F1 & F2 & F3 --> F4[共享实例]
    end

    F4 --> G[后置 Hook]

    subgraph hook2[后置处理]
        G --> G1[结果处理]
        G1 --> G2[审计日志]
        G2 --> G3[清理敏感信息]
    end

    G3 --> H[返回结果]

    style B fill:#51cf66,color:#fff
    style E fill:#51cf66,color:#fff
    style G fill:#51cf66,color:#fff
    style F fill:#4169e1,color:#fff
    style H fill:#ffd700

协同工作流程：

智能路由层：用户请求进来，先尝试规则路由快速匹配，如果没有命中则启用语义路由分析
选定 MCP：确定要调用哪个 MCP 工具
前置 Hook：验证身份、获取密钥、注入参数、记录日志
MCP 打包：调用工具包内的一个或多个工具，所有工具共享底层实例和状态
后置 Hook：处理结果、记录审计、清理敏感信息
返回结果：给 Agent 和最终用户

如何使用 AgentRun 的 MCP 能力

基于以上技术架构，AgentRun 提供了三种使用 MCP 的方式：

方式一：从工具市场直接使用

AgentRun 提供了工具市场，包含大量预制的 MCP 工具，涵盖代码执行、浏览器自动化、数据库查询、云服务操作等常见场景。用户可以直接搜索、预览、一键添加，无需从零配置。工具市场中的 MCP 都经过测试优化，包含完善的描述和示例。

适用场景：快速上线，使用标准能力，不需要深度定制。

方式二：导入已有 MCP 并通过代理增强

如果你已经有现成的 MCP 工具（开源社区的、第三方的、自己开发的），可以通过 MCP 代理导入到 AgentRun。

MCP 代理的核心价值：让原生 MCP 工具也能享受 AgentRun 的扩展能力。导入后自动获得：

Hook 支持（前置/后置处理）
智能路由（参与规则和语义路由）
统一治理（凭证管理、审计日志、监控告警）

适用场景：已有 MCP 工具，希望增强企业级能力，不想重复开发。

方式三：多个 API 打包成 MCP

AgentRun 支持将多个相关的 API 打包成一个 MCP 工具。比如云服务的多个 API：ListFunctions、GetFunction、InvokeFunction、GetLogs，可以打包成一个 cloud-functions-mcp。

打包时可以：

配置统一的鉴权方式（通过 Hook）
配置智能路由规则
添加通用的错误处理和重试逻辑
统一管理超时、限流等参数

适用场景：企业内部系统集成，把分散的 API 整合成 Agent 容易理解的能力单元。

AgentRun 对 MCP 的扩展，本质上是将 MCP 从一个工具调用协议升级为一个企业级的工具治理平台。

核心价值：从协议到平台的进化

MCP 打包让工具从孤立的能力点变成完整的能力单元，状态共享、配置统一。

智能路由让工具选择从手工配置 Prompt 变成系统自动决策，支持模糊意图和自然语言多样性。

Hook 机制让企业级需求（鉴权、凭证、审计、合规）从分散在各处的重复代码变成统一的治理策略。

MCP 代理让已有的原生 MCP 工具也能享受这些能力，不需要推倒重来。

工具市场和打包能力让 MCP 的创建、分享、复用变得简单，形成生态闭环。

更重要的是，这些扩展是渐进式的、非侵入的。你可以先用工具市场的现成 MCP 快速上线，随着需求复杂再导入自己的 MCP 并配置 Hook，最后将内部 API 打包成定制 MCP。每一步都有价值，每一步都不需要推倒重来。

当我们谈论 Agent 应用的企业级落地时，标准化的协议只是第一步，真正的挑战在于：如何让工具好用、好管、好优化。AgentRun 对 MCP 的扩展，正是在回答这个问题。从真实场景出发，提供完整的解决方案，这才是一个基础设施平台应有的价值。

AgentRun 探秘：凭证管理让凭证下发更简单

Mon, 08 Dec 2025 00:44:46 +0800

在构建 Agent 应用时，凭证管理是一个容易被忽视但又极其重要的问题。一个典型的 Agent 应用会面临两个方向的凭证需求：向内，用户如何安全地调用你的 Agent？向外，Agent 如何安全地调用外部服务？

传统做法存在诸多问题。硬编码在代码里容易泄露且难以更新，存在配置文件中同样有安全风险，每次都手动传递不仅麻烦还容易出错，让大模型处理凭证更是巨大的安全隐患。更棘手的是，当凭证需要更新时（比如 API Key 过期、权限变更），如何在不重启服务的情况下动态更新？AgentRun 的凭证管理系统就是为了解决这些问题而生。

入站凭证与出站凭证：双向安全保障

AgentRun 的凭证管理分为两个维度，分别解决”谁能调用我”和”我能调用谁”的问题。

入站凭证：控制谁能访问你的 Agent

入站凭证用于控制外部用户或系统如何访问你的 Agent 应用。当你创建一个 Agent 并对外提供服务时，需要确保只有授权的用户才能调用。AgentRun 提供了灵活的入站凭证管理，可以为不同的调用方生成独立的凭证，设置不同的权限和配额，控制每个凭证能访问哪些 Agent、调用频率限制、有效期等。

由于所有请求都经过 AgentRun 网关，入站凭证可以实现真正的动态更新。比如你的 Agent 对外提供客服能力，可以为不同的业务部门生成不同的入站凭证，每个部门只能访问各自授权的 Agent。当某个部门的凭证泄露时，可以立即撤销并重新生成，所有变更在网关层实时生效，不影响其他部门的使用，也无需重启任何服务。

出站凭证：安全调用外部服务

出站凭证用于 Agent 访问外部服务时的身份认证。Agent 应用通常需要调用各种外部服务：大模型 API（OpenAI、Claude、Qwen 等）、数据库、第三方工具、企业内部系统等，每个服务都需要相应的凭证。传统方式下，开发者要么把这些凭证硬编码在代码里，要么通过环境变量传递，不仅不安全，更新时还需要重启服务。

AgentRun 采用了一套巧妙的定时查询与缓存机制来管理出站凭证。所有出站凭证统一存储在加密的凭证库中，代码里不再出现任何敏感信息。Agent 启动时会从凭证库拉取所需的所有凭证并缓存到本地，运行过程中直接使用本地缓存，避免频繁的网络请求带来的性能开销。同时，系统会定期进行健康检查，主动查询凭证是否有更新，发现变更时只更新发生变化的凭证。如果健康检查失败，会自动重试，确保凭证始终可用。

这种定时查询方案带来了多重价值。从性能角度看，本地缓存避免了每次调用都查询凭证库，大幅降低了延迟和网络开销；从可用性角度看，即使凭证服务短暂不可用，缓存的凭证仍然可用，不会影响 Agent 的正常运行；从安全性角度看，定时健康检查确保凭证泄露或过期时能在几分钟内完成更新，而不需要等到下次部署。最关键的是，整个更新过程对 Agent 代码完全透明，开发者无需编写任何凭证更新逻辑，专注于业务实现即可。

这种最终一致性的设计在实践中被证明是最优的平衡：既保证了性能和可用性，又实现了凭证的动态更新能力。相比于每次都实时查询（性能差）或者只在启动时加载（更新不及时），定时查询方案在三者之间找到了最佳平衡点。

实际应用：工具和模型的凭证配置

AgentRun 的凭证管理在两个关键场景发挥作用，展示了从理论到实践的完整闭环。

场景一：大模型调用的凭证管理

当你的 Agent 需要调用多个大模型时，每个模型都需要各自的 API Key。以前你可能需要在代码里硬编码这些 Key，或者通过环境变量传递，但这样做存在安全风险且更新困难。有了 AgentRun 的凭证管理，你只需要在平台上配置各个模型的出站凭证，给每个凭证命名（如 openai_key、qwen_key），然后在 Agent 配置中引用这些凭证名称。

运行时系统会自动注入实际的 Key，你的代码里完全看不到任何敏感信息。当某个模型的 Key 过期需要更新时，只需在凭证管理界面更新，几分钟后所有使用该凭证的 Agent 会通过定时健康检查自动获取新的 Key，无需修改代码或重启服务。这种体验就像是有一个智能管家在后台默默地帮你管理所有的钥匙，你只需要告诉他你要开哪扇门。

# Agent 配置示例（伪代码）
models:
  - name: gpt-4
    credential: ${credentials.openai_key}  # 引用凭证名称，不暴露实际Key
  - name: qwen-max
    credential: ${credentials.qwen_key}

场景二：工具调用的凭证注入

回到之前提到的 FunctionQ 案例，这是一个更复杂但也更能体现凭证管理价值的场景。Agent 需要通过 MCP 调用 CLI 工具查询用户的函数计算资源，这些工具需要用户的 AccessKey 和 SecretKey。关键问题是：如何在不暴露凭证给大模型的前提下，让工具能够正确调用 API？

AgentRun 通过前置 Hook 实现了优雅的动态凭证注入。用户在平台上配置自己的出站凭证后，Agent 调用工具时请求中只携带用户 ID，不包含任何凭证信息。前置 Hook 拦截请求，根据用户 ID 从凭证库获取对应的凭证，然后将凭证注入到环境变量或请求参数中。工具使用注入的凭证执行实际操作，后置 Hook 再清理敏感信息并记录审计日志。整个过程中，凭证从未暴露给大模型，也不会出现在 Agent 的代码中，真正做到了安全可控。

sequenceDiagram
    participant Agent
    participant Hook as 前置 Hook
    participant Cache as 凭证缓存
    participant MCP as MCP 工具
    participant API as 函数计算 API

    Agent->>Hook: 调用工具（仅携带用户 ID）
    Note over Agent,Hook: 请求中不包含任何凭证

    Hook->>Cache: 根据用户 ID 获取凭证
    Cache-->>Hook: 返回 AccessKey/SecretKey
    Note over Hook: 凭证来自定时更新的本地缓存

    Hook->>Hook: 将凭证注入到环境变量
    Hook->>MCP: 转发请求（已注入凭证）

    MCP->>API: 调用函数计算 API
    Note over MCP,API: 使用注入的凭证

    API-->>MCP: 返回函数列表
    MCP-->>Hook: 返回结果

    Hook->>Hook: 清理敏感信息 + 记录审计日志
    Hook-->>Agent: 返回安全结果

    Note over Agent,Hook: Agent 和大模型从未接触凭证

核心价值：让开发者专注业务逻辑

AgentRun 的凭证管理系统带来的价值远不止”管理凭证”这么简单。从安全性角度看，凭证不再出现在代码和日志中，集中加密存储大幅降低泄露风险，即使某个凭证泄露也可以快速撤销和更换。从开发效率角度看，开发者不需要关心凭证如何存储、如何传递、如何更新，只需在配置中引用凭证名称，系统自动处理剩下的事情。从运维角度看，凭证更新不需要修改代码、不需要重新部署、不需要重启服务，在管理界面更新后通过定时机制自动生效。

更重要的是，凭证管理让 Agent 应用从”能用”变成”敢用”。企业不再担心凭证泄露的风险，不再为凭证更新而头疼，不再因为安全问题而犹豫是否将 Agent 应用部署到生产环境。这种信心的建立，才是凭证管理最大的价值所在——它消除了企业拥抱 AI Agent 的最后一道顾虑，让技术真正为业务创造价值。

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

Sun, 07 Dec 2025 00:37:10 +0800

在AI创业圈流传着这样一个段子：每个月都有新的Agent框架发布，每个框架都号称”革命性创新”，但真正在生产环境稳定运行超过三个月的，屈指可数。这个略带讽刺的现象背后，隐藏着一个被集体忽视的真相：在AI Agent这个赛道上，仅有聪明的模型和先进的算法还远远不够——模型效果固然是决定性的基础，但如果没人愿意把手弄脏，去解决那些看似琐碎、实则致命的基础问题，再好的模型也只能停留在Demo阶段。

2025年的今天，当我们重新审视Agent平台的竞争格局时，一个反直觉的洞察浮现出来：那些默默处理”脏活累活”的平台，正在构建真正的护城河。阿里云函数计算AgentRun的实践，或许为我们提供了一个观察这种趋势的绝佳窗口。

繁华背后的狼狈：当Demo遇见生产环境

让我们从一个真实的故事开始。某电商企业的技术团队在2024年初兴致勃勃地开发了一个智能客服Agent，使用最先进的GPT-4模型，集成了当时最流行的LangChain框架。Demo演示时，效果惊艳：Agent能够流畅地理解用户意图，准确查询订单信息，甚至能处理一些复杂的售后问题。管理层拍板：立即上线！

然而，噩梦从上线第一天就开始了。先是并发问题：当多个用户同时对话时，Agent开始”精神分裂”，把张三的订单信息告诉了李四。技术团队紧急修复，给每个会话加了隔离。第三天，新问题出现：OpenAI的API突然限流，大量用户请求超时，客服热线被打爆。团队连夜增加重试机制，又引发了成本失控——重试导致Token消耗翻倍，一天的API费用相当于一个客服人员一个月的工资。

最致命的打击出现在第二周：一个”聪明”的用户通过精心构造的提示词，让Agent执行了一段Python代码，差点访问到了数据库的敏感信息。虽然及时发现并阻止，但这个安全隐患让管理层彻底失去了信心。这个曾经被寄予厚望的AI项目，在上线不到一个月后黯然下线。

这不是个例。根据InfoQ的报告，95%的企业AI项目以失败告终，其中绝大部分不是因为AI不够”智能”，而是倒在了这些”脏活累活”上：如何管理多租户的资源隔离？如何处理模型服务的不稳定性？如何控制不可预测的成本？如何保证代码执行的安全性？如何实现生产级的可观测性？

这些问题，没有一个是性感的，没有一个能成为技术大会的主题演讲，但每一个都可能成为项目的致命伤。

被低估的复杂性：Agent运行时的千头万绪

要理解为什么这些”脏活累活”如此重要，我们需要深入到Agent运行时的技术细节中。一个看似简单的Agent对话背后，实际上是一个极其复杂的分布式系统在运转。

首先是状态管理的挑战。传统的无状态服务很简单：接收请求，处理，返回结果。但Agent应用本质上是有状态的——它需要记住之前的对话历史、保持工具调用的上下文、管理临时文件和计算结果。在Serverless环境下，如何在保持弹性的同时管理这些状态？AgentRun的解决方案展示了这个问题的复杂性：通过”浅休眠”和”深休眠”机制，使用内存快照技术在不同级别保存状态，配合会话亲和路由确保请求总是路由到正确的实例。这套机制的实现，需要深入到操作系统层面的优化。

其次是安全隔离的难题。当Agent需要执行代码或操作浏览器时，如何确保安全？简单的Docker容器隔离是不够的——恶意代码可能通过各种方式逃逸。AgentRun使用自研的”袋鼠安全容器”，在请求、实例、会话三个层面实现了多维度隔离。更复杂的是，这种隔离还必须是高性能的——百毫秒级的冷启动要求容器技术的极致优化。

再看成本控制的精细化。一个Agent应用的成本构成极其复杂：模型调用的Token费用、计算资源的使用成本、存储和网络传输费用，每一项都可能失控。AgentRun实现了业界首创的实例级”忙/闲”状态计费——当Agent实例在等待时，自动进入低成本的闲置状态，但又能在毫秒级唤醒。这种精细化的资源调度，背后是对函数计算底层调度系统的深度改造。

最后是可观测性的挑战。当一个Agent调用出错时，问题可能出现在任何环节：是模型返回了异常结果？是工具调用超时？还是内存溢出？传统的日志系统在这里几乎无能为力。AgentRun构建的全链路追踪系统，能够完整记录从用户输入到最终输出的每一个步骤，包括模型推理、工具调用、状态变更等。但这种细粒度的追踪本身又带来了新的挑战：如何在不影响性能的前提下收集数据？如何存储和查询海量的追踪信息？

凭证管理的艺术：看不见的信任基础

在所有的”脏活累活”中，凭证管理可能是最不起眼但又最关键的一个。FunctionQ的案例生动地展示了这个问题的复杂性：Agent需要调用阿里云API查询用户的函数计算资源，这需要用户的AccessKey和SecretKey。但这些凭证绝对不能暴露给大模型，否则就是巨大的安全漏洞。

传统的解决方案要么不安全（硬编码凭证），要么不实用（每次让用户输入）。AgentRun设计了一套精妙的双向凭证管理系统：入站凭证控制谁能调用Agent，通过网关层动态验证和限流；出站凭证管理Agent调用外部服务的身份，通过定时查询和本地缓存实现高性能。

这套系统的巧妙之处在于它的”最终一致性”设计。凭证不是每次调用都实时获取（性能太差），也不是只在启动时加载一次（更新不及时），而是通过定时健康检查实现动态更新。当凭证需要轮换时，系统在几分钟内自动完成切换，整个过程对业务完全透明。

更进一步的是Hook机制。通过前置Hook，系统可以在工具调用前动态注入用户凭证；通过后置Hook，可以清理敏感信息并记录审计日志。这种设计让安全性和易用性不再是非此即彼的选择，而是可以兼得的特性。

MCP治理：从混乱到有序的工具生态

MCP协议的出现曾被视为Agent工具调用的标准化希望，但AgentRun的实践揭示了更深层的问题。当平台上有上百个MCP工具时，新的混乱出现了：Agent如何知道该用哪个工具？相关的工具如何协同工作？企业级的安全和审计需求如何满足？

AgentRun的三大扩展机制展示了如何把这个”脏活”做到极致。MCP打包机制将相关工具组织成完整的能力单元，共享底层实例和状态；智能路由通过规则和语义分析自动匹配最合适的工具；Hook机制在工具调用的前后插入企业级的治理逻辑。

这些看似技术性的改进，实际上解决的是工具生态从”能用”到”好用”的关键跨越。没有这些基础工作，MCP就只是一个协议规范，而有了这些，它才真正成为了生产级的工具平台。

模型治理：用工程手段解决不确定性

大模型的不确定性是Agent应用面临的另一个”脏活”。模型可能突然变慢、可能临时故障、可能触发限流、可能返回异常结果。这些不确定性在Demo阶段可以忽略，但在生产环境中却是致命的。

AgentRun基于开源项目LiteLLM构建的模型治理平台，展示了如何用工程手段系统性地解决这个问题。多模型Fallback确保服务永远可用，主模型故障时毫秒级切换到备用模型；智能路由根据请求特征选择最合适的模型，简单问题用小模型，复杂问题才用大模型；熔断机制避免持续调用故障模型，限流策略防止超出配额；统一代理屏蔽不同模型API的差异，让切换模型像切换数据库连接一样简单。

这套方案的价值在于，它把模型的不确定性转化为了可管理的工程问题。企业不再需要祈祷模型服务稳定，而是可以通过配置确保服务质量。

竞争力的真相：基础设施即护城河

当我们把这些”脏活累活”串联起来看，一个清晰的图景浮现出来：在Agent平台的竞争中，模型效果是根本，但真正的护城河来自于把基础设施做到极致的能力。

这种竞争力是隐性的但却是决定性的。用户可能不知道什么是会话亲和、什么是凭证注入、什么是模型熔断，但他们能感受到：Agent是否稳定可靠、成本是否可控、是否安全合规。这些由”脏活累活”支撑的特性，最终决定了即使拥有最好模型的Agent应用能否真正进入生产环境。

更深层的启示是，这反映了技术产业发展的普遍规律。每一次技术革命的早期，大家都在追求突破性创新；但当技术走向成熟，决定胜负的往往是执行力和工程能力。就像当年的互联网泡沫后，活下来的不是概念最新的公司，而是把基础服务做到最好的公司。

阿里云函数计算在Forrester和Gartner报告中进入领导者象限，靠的不是炫酷的新概念，而是在Serverless这个”脏活累活”上的深耕。这种积累成为了AgentRun的技术底座，让它能够为Agent应用提供真正生产级的运行环境。

从混沌到秩序：产业成熟的必经之路

站在2025年12月回望，Agent技术正在经历从”技术玩具”到”生产工具”的关键转变。这个过程中，那些愿意承担”脏活累活”的平台正在定义行业的基础设施标准。

AgentRun的实践给了我们一个重要启示：在追求AI的智能边界时，不要忘记那些平凡但必要的基础工作。因为历史告诉我们，改变世界的往往不是最聪明的想法，而是最可靠的执行。在Agent时代，谁能让开发者不再为运维发愁、不再为成本担心、不再为安全提心吊胆，谁就掌握了这个时代的基础设施话语权。

当市场上充斥着各种”革命性”的Agent框架时，真正革命性的可能是那些默默解决基础问题的平台。因为只有当”脏活累活”不再是负担，创新者才能真正专注于创新本身。这或许就是为什么95%的AI项目失败，而那成功的5%，往往都有一个共同特点：他们要么自己解决了这些基础问题，要么找到了替他们解决这些问题的平台。

在这个意义上，”脏活累活”不是竞争力的补充，而是竞争力的基础。它代表着一种更成熟的技术价值观：不是追求一鸣惊人，而是追求细水长流；不是创造新概念，而是解决真问题。这种价值观，或许才是Agent时代真正需要的。当优秀的模型遇上可靠的基础设施，Agent的春天才会真正到来。

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

Sun, 07 Dec 2025 00:14:53 +0800

在技术创新的浪潮中，我们常常看到这样一种现象：新进入者带着更优秀的技术指标、更完善的架构设计，试图挑战既有的市场领导者。然而，市场的反馈往往出人意料——那些”技术落后”的产品依然占据着主导地位，而技术优越的挑战者却举步维艰。这种看似反常的现象背后，隐藏着产品竞争的深层逻辑。

一厢情愿的对标思维

当我们分析竞争对手时，很容易陷入一种线性思维：发现对手产品的技术短板，认为这就是市场机会，然后全力打造一个”更好”的替代品。这种思路看似合理，实则忽略了一个关键问题——用户选择产品的决策逻辑远比技术指标复杂。

以低代码平台市场为例，某些早期进入者可能在性能、稳定性或功能完整性上存在明显不足，但依然拥有庞大的用户群体和可观的收入。新进入者往往会认为，凭借更强的技术实力，理应能够快速抢占市场份额。然而现实却是，即便新产品在各项技术指标上全面领先，用户迁移的意愿依然不高。

这种现象揭示了几个重要的洞察：如果一个产品尽管存在明显缺陷，用户仍然愿意为之付费并持续使用，这说明了几种可能性。

首先，这些用户和我们假想的目标用户可能根本不是同一群人。他们的核心诉求、使用场景、价值判断标准可能完全不同。对于他们而言，那些所谓的”缺陷”可能确实不是关键问题，而产品在其他维度上的优势——比如易用性、价格、服务支持、或是特定功能的契合度——才是他们选择的决定性因素。

其次，确实存在一部分用户关注技术优势，他们可能正是新产品的潜在目标群体。但这个群体的规模有多大？他们的付费能力如何？获客成本是否合理？这些都需要审慎评估。

最关键的问题在于：我们是否真正理解了不同用户群体的差异化需求？如果既有产品服务的是用户群体A，而我们的技术优势恰好契合用户群体B的需求，那么专注于服务B群体是明智的选择。但如果我们的目标是”抢夺”A群体的用户，仅凭技术优势可能远远不够——因为A群体选择既有产品，可能有着我们尚未充分理解的深层原因。

技术竞争的认知偏差

技术团队在进行产品规划时，往往会过度聚焦于技术层面的比较。这种倾向源于工程师文化中对技术完美主义的追求，但在商业竞争中，这种追求可能成为一种负担。

当我们将”超越某个竞品”设定为产品目标时，整个团队的注意力就会被锁定在一个狭窄的比较维度上。产品路线图开始围绕”补齐对手的功能”展开，技术架构设计着重考虑”兼容对手的数据格式”，市场宣传强调”比某某产品更好”。渐渐地，产品失去了自己的独特定位，成为了既有产品的影子。

更深层的问题在于，这种对标思维会导致战略自主性的丧失。团队不再思考”我们的目标用户真正需要什么”，而是不断追问”竞品又推出了什么新功能”。产品的发展节奏被竞争对手牵着走，创新变成了模仿，差异化优势逐渐消失。

这种认知偏差的根源，往往是对市场细分理解不够深入。我们看到竞品的成功，就假设所有使用竞品的用户都是我们的目标用户，却忽略了用户群体内部的巨大差异。有些用户可能确实需要更好的技术性能，但更多用户可能更看重产品的其他属性。

用户价值的多维度构成

要理解为什么技术优势不能直接转化为市场成功，我们需要深入分析用户价值的构成。对于企业级软件产品，不同类型的用户会有完全不同的价值判断体系。

对于技术导向型用户，他们确实会关注性能指标、架构设计、扩展能力等技术层面的优势。这类用户通常是技术决策者或者对技术有深入理解的使用者。但即便是这类用户，他们的决策也不完全基于技术指标。

生态系统的完整性往往是被低估的因素。一个成熟的产品往往已经构建起完整的生态体系：丰富的文档教程、活跃的社区支持、成熟的第三方集成、专业的服务商网络。这些看似”产品之外”的要素，实际上构成了用户体验的重要组成部分。新产品即便在核心功能上更加优秀，但如果缺乏这些配套支持，用户在实际使用中会遇到诸多障碍。

转换成本的综合评估是另一个关键因素。用户迁移到新产品的成本远不止数据迁移那么简单。团队需要重新学习新的操作界面和工作流程，已有的自动化脚本和集成需要重新开发，积累的使用经验和最佳实践需要重新建立。这些隐性成本往往被产品开发者低估，但对用户而言却是实实在在的负担。

信任关系的建立更是长期过程。企业选择一款核心业务系统，不仅仅是选择一个工具，更是选择一个长期的合作伙伴。产品的稳定性记录、公司的持续经营能力、对用户反馈的响应速度、版本更新的节奏把控，这些因素共同构成了用户的信任基础。新进入者需要时间来证明自己的可靠性。

更重要的是，不同用户群体对这些因素的权重分配完全不同。初创企业可能更看重价格和灵活性，大型企业更关注稳定性和服务支持，技术团队追求性能和可扩展性，业务团队则更在意易用性和学习成本。理解这种差异，是制定正确产品策略的前提。

寻找差异化的突破口

认识到对标思维的局限性后，真正的问题是：如何找到属于自己的市场定位？成功的策略往往不是正面竞争，而是差异化定位。

首先要明确的是目标用户群体的选择。与其试图服务”竞品的所有用户”，不如深入分析市场，找到那些现有产品无法很好满足的细分群体。这些群体可能规模较小，但如果他们的需求与我们的优势高度契合，反而能够快速建立市场地位。

深度垂直化是一个有效的策略。选择特定的行业或场景深耕，当产品功能设计、界面语言、工作流程都针对特定用户群体优化时，即便在通用功能上不如竞品完善，但在目标场景中的适配度会远超通用产品。这种”窄而深”的策略，能够在细分市场建立难以撼动的优势。

技术范式的创新提供了另一种可能。如果既有产品都基于某种技术架构或交互模式，那么采用全新的技术范式可能开辟出新的赛道。比如当所有竞品都在优化拖拽式的可视化编程时，基于自然语言的交互模式可能吸引到完全不同的用户群体。这种范式创新不是为了”更好”，而是为了服务那些被现有范式排除在外的用户。

商业模式的创新同样重要。开源与商业、本地部署与云服务、订阅制与买断制，不同的商业模式会吸引不同的客户群体。有时候，技术上的些许差距可以通过商业模式的创新来弥补甚至超越。关键是要找到那些因为商业模式不适合而无法使用现有产品的用户群体。

从竞争到共生的思维转变

产品战略的制定，需要从”打败对手”的零和思维，转向”创造独特价值”的正和思维。市场足够大，用户需求足够多样，不同的产品可以服务不同的用户群体，在各自的领域创造价值。

真正成功的产品，往往不是那些试图全面超越竞品的产品，而是那些找到了自己独特定位和目标用户的产品。它们可能在某些方面不如竞品，但在自己聚焦的维度上做到了极致。用户选择它们，不是因为它们是”更好的某某”，而是因为它们恰好满足了这些用户的特定需求。

技术创新的价值，最终要通过满足特定用户群体的需求来实现。当我们把注意力从”如何打败对手”转向”如何更好地服务我们的目标用户”时，真正的创新机会才会浮现。对标可以帮助我们了解市场格局，学习最佳实践，但绝不应该成为产品战略的核心。

理解不同用户群体的差异化需求，找到技术优势与市场需求的契合点，在细分领域建立独特价值，这才是产品成功的正确路径。在这个过程中，所谓的竞争对手，可能服务的是完全不同的用户群体，大家在各自的赛道上前进，共同推动整个行业的发展。

Agent 时代的迷茫与突围：从 AgentRun 看基础设施的真正价值

Sun, 07 Dec 2025 00:04:28 +0800

时间来到2025年12月6日，距离ChatGPT引爆AI革命已经过去了两年。当我们站在这个时间节点回望AI Agent的发展轨迹，一个悖论愈发清晰：技术的繁荣与落地的困境形成了鲜明对比。各大厂商纷纷推出自己的Agent框架，开源社区更是百花齐放，从LangChain到CrewAI，从AutoGPT到AgentScope，每个月都有新的”革命性”框架诞生。然而，当我们冷静审视这个看似繁荣的生态时，数据却揭示了残酷的真相：据IDC统计，2024年中国AI Agent市场规模仅50亿元，InfoQ的报告更是指出95%的企业AI落地项目以失败告终。

这种”繁华的迷茫”背后，隐藏着一个行业共同面临的深层困境：我们过度关注了Agent的”智能”，却忽视了让它们真正”跑起来”的基础能力。阿里云函数计算AgentRun在云栖大会的正式发布，或许为这个困境提供了一个新的视角——在这个人人都在追求大模型能力边界的时代，真正决定胜负的，可能恰恰是那些看似微不足道的”小能力”。

被忽视的真相：Agent落地的隐形门槛

MCP（Model Context Protocol）的出现曾让业界为之振奋。这个由Anthropic公司开发的协议，被形象地称为”USB-C for AI”，它承诺让Agent与工具的连接变得标准化和简单化。包括Atlassian、Confluent在内的企业纷纷推出MCP服务，一时间标准化似乎触手可及。

但实际应用中，开发者很快发现了更深层的问题。一位企业开发者的困惑很有代表性：”我之前做过很多AI应用，流量少的时候还好，流量一多最头疼的就是模型的安全稳定。”当用户说”写一段代码处理data.csv文件”时，系统需要调用多个工具：execute_code执行代码、upload_file上传文件、download_file下载结果。原生MCP把一个完整能力拆成了多个孤立工具，每个工具都需要单独配置，管理成本呈指数级增长。更棘手的是，当Agent需要调用另一个Agent时，状态如何传递？上下文如何保持？当并发量上来时，如何保证每个Agent都能获得足够的计算资源，同时又不至于让成本失控？

这些问题看似琐碎，却是横亘在POC和生产环境之间的天堑。FunctionQ的案例很能说明问题：这个函数计算智能助手在第一天通过无代码界面快速创建了基础版本，当天下午就上线服务内部测试用户。但到了第三天，问题开始暴露：Agent调用工具时报”权限不足”错误，多个用户使用时数据混乱，成本增长很快但不知道花在哪里。这些问题的根源在于缺乏企业级的基础设施支撑。

AgentRun的意义正在于此。它不是又一个Agent框架，而是一个专门为Agent运行而生的基础设施平台。通过将函数计算的Serverless能力与AI场景深度结合，它试图解决的是那些”不起眼”但却致命的问题：通过自研的”袋鼠安全容器”实现百毫秒级的冷启动、会话状态的持久化、安全隔离的执行环境、以及最重要的——基于实例”忙/闲”状态的精细化计费，真正实现按需付费。

从”能跑”到”跑得好”：技术细节中的魔鬼

让我们深入到一个具体的技术细节：会话亲和（Session Affinity）。在传统的Serverless架构中，函数实例是无状态的，这对于简单的API服务来说不是问题。但对于Agent应用，一个多轮对话可能需要保持复杂的上下文状态，包括之前的对话历史、中间计算结果、甚至是与外部系统的连接状态。

AgentRun通过巧妙的架构设计，在保持Serverless弹性优势的同时，实现了状态的持久化。它的”浅休眠”和”深休眠”机制，通过内存快照技术，让Agent实例可以在不活跃时释放资源，但又能在需要时毫秒级恢复。这种设计不仅解决了成本问题，更重要的是，它让Agent应用真正具备了企业级的可靠性。实际数据显示，单集群可支持百万规模的智能体运行时和沙箱实例，单个智能体服务能够承载百万QPS的请求量。

再看凭证管理的设计创新。AgentRun采用了双向凭证管理机制：入站凭证控制谁能访问你的Agent，出站凭证管理Agent如何安全调用外部服务。特别是出站凭证，通过定时查询与缓存机制，实现了一个巧妙的平衡：Agent启动时从加密凭证库拉取所需凭证并缓存到本地，运行过程中直接使用本地缓存避免性能开销，同时系统定期进行健康检查，发现凭证变更时只更新变化的部分。这种最终一致性的设计，在性能、可用性和安全性之间找到了最佳平衡点。

企业级Sandbox的设计更是体现了对Agent应用特性的深刻理解。阿里云在Qwen模型的强化学习训练中，就使用AgentRun Sandbox支撑了数十万核的计算规模。通过多维度的算力隔离和动态挂载技术，在请求、实例、会话三个层面实现了精细化的资源管控。这不是简单的计算任务隔离，而是在开放性和安全性之间找到微妙平衡的复杂系统工程。

演进的哲学：从低代码到高代码的无缝切换

当我们谈论AI Agent的开发时，常常面临一个两难的选择：低代码平台上手快但缺乏灵活性，一旦需求复杂就束手无策；高代码开发虽然灵活但门槛高，业务人员无法参与，验证周期长。AgentRun给出了一个优雅的答案：通过无代码快速创建Agent验证想法，当业务发展需要更复杂定制时，一键转换为高代码继续演进。

这不是简单的功能堆砌，而是深刻理解了Agent应用从0到1、从1到100的真实路径。FunctionQ团队的经历很好地诠释了这种价值：产品经理第一天通过无代码界面创建基础版本，当天下午就能上线测试。第五天遇到权限和性能问题时，团队将Agent转换为高代码，通过配置Hook实现了动态凭证注入，利用会话亲和机制隔离不同用户数据，实现智能模型选择策略后成本降低了约40%。两周后随着用户增长，团队继续优化，添加智能缓存将响应速度从2秒降到0.1秒。

如果没有这种演进能力，项目会面临什么？要么一开始就用高代码开发，验证周期从1天变成1周；要么一直用无代码，无法解决关键问题最终放弃；或者推倒重来，浪费前期所有积累。AgentRun让团队可以从最快的方式开始，随着业务发展平滑演进，没有技术债务，没有推倒重来。

生态整合的深度：不只是兼容，更是赋能

在这个每个大厂都想建立自己生态壁垒的时代，AgentRun选择了一条不同的道路。它没有试图创造又一个封闭的Agent框架，而是选择深度兼容并赋能现有的开源生态。

以LangChain集成为例，开发者几乎不需要改动现有代码，只需要简单的适配：使用AgentRun的model()函数获取自动享受高可用、熔断等能力的模型对象，使用sandbox_toolset()获取企业级安全隔离的工具集合，原有的Agent创建代码完全不需要改动。部署到AgentRun后，这些Agent自动获得了零运维的Serverless运行时、企业级的Sandbox环境、模型高可用保障、全链路可观测等能力。

ModelScope魔搭社区的合作案例很好地诠释了这种理念的价值。开发者可以一键托管模型，最快30秒就能将开源模型转化为生产级API。吉利、极氪等企业已经在使用这种模式托管文生图、文生语音等领域模型，实现了从实验到生产的无缝过渡。

MCP的企业级进化：从协议到平台

AgentRun对MCP的扩展，展现了对企业级需求的深刻洞察。原生MCP解决了”如何调用”的问题，却没有解决”如何用好”的问题。AgentRun通过三大扩展机制，将MCP从工具调用协议升级为企业级工具治理平台。

MCP打包机制让相关工具成为协作的整体。当用户需要”执行代码并处理文件”时，不再需要分别管理execute_code、upload_file、download_file等独立工具，而是使用一个完整的code-executor-mcp，所有工具自动共享同一个Sandbox实例和状态。

智能路由机制通过规则路由和语义路由的组合，自动将用户请求匹配到最合适的MCP工具。规则路由处理明确意图，语义路由使用embedding模型处理模糊请求。这不仅减轻了大模型负担，更重要的是支持了自然语言的多样性——用户怎么说都能正确匹配。

Hook机制则解决了企业级场景的核心痛点。通过前置Hook，可以在工具调用前动态获取并注入用户凭证；通过后置Hook，可以记录审计日志并清理敏感信息。整个过程中，凭证从未暴露给大模型，真正做到了安全可控。某电商企业的智能客服Agent，正是通过这种机制实现了多租户隔离和凭证安全管理。

从技术到价值：重新定义ROI

当我们谈论AI的ROI时，往往只关注模型的准确率提升带来的价值。但在实际落地中，运维成本、扩展性限制、安全合规等”非智能”因素往往成为决定项目成败的关键。某电商企业的真实案例很能说明问题：最初直接调用GPT-4，随着业务增长频繁遭遇故障、限流和成本失控。引入AgentRun的模型治理后，通过主备切换避免了服务中断，通过智能路由降低了50%的成本，通过限流告警主动管理配额。

AgentRun通过深度优化，能够将企业的总体拥有成本（TCO）降低60%。这个数字背后是对Agent应用真实成本结构的深刻洞察：传统方案为应对峰值流量预留大量闲置资源，而AgentRun的Serverless架构真正做到按需分配；通过实例级别的”忙/闲”状态独立计费，避免资源浪费；将复杂的基础设施管理抽象化，大幅降低运维门槛。

全链路可观测能力更是直击了Agent应用的”黑盒”痛点。基于全链路追踪技术，开发者可以精准还原Agent的决策路径，包括意图理解、模型推理、工具调用及知识检索等核心环节，每一步的状态与耗时都清晰可见。这种透明度不仅有助于快速定位问题，更重要的是让Token消耗和成本可控，避免了许多企业担心的”成本失控”问题。

迷茫中的方向：小能力定胜负

回到开篇的问题：在这个Agent框架层出不穷的时代，为什么真正成功的应用如此之少？答案或许就在于我们对”能力”的理解偏差。我们过度追求Agent的”大能力”——更强的推理、更复杂的任务规划、更丰富的工具调用，却忽视了那些决定成败的”小能力”——稳定的运行时、高效的资源调度、可靠的状态管理、完善的监控体系。

阿里云凭借函数计算FC的深厚积累，分别进入Forrester Wave™: Serverless Development Platforms Q2 2025领导者象限和2025年度Gartner®全球《云原生应用平台魔力象限》领导者象限，成为亚太地区唯一同时入选”领导者象限”的科技公司。这种在Serverless领域的技术领先性，为AgentRun提供了坚实的技术底座。

AgentRun的出现，为行业提供了一个重要启示：在AI Agent时代，基础设施不应该是事后的考虑，而应该是一开始就内置的能力。当每个开发者都不需要再为”如何让Agent跑起来”而烦恼时，才能真正专注于”如何让Agent更智能”。这种分工不是倒退，而是产业成熟的标志。

站在2025年12月的今天，Agent技术正处于从实验室走向生产环境的关键转折点。这个过程中，我们需要的不仅是更智能的算法，更需要像AgentRun这样的基础设施创新。因为历史告诉我们，真正改变世界的技术，往往不是最炫酷的那个，而是最可靠的那个。在Agent时代的竞争中，谁能让Agent不仅”能跑”，更能”跑得稳、跑得久、跑得省”，谁就掌握了通向未来的钥匙。

当50亿元的市场规模遭遇95%的失败率时，我们需要的或许不是更多的框架，而是让现有框架真正落地的基础设施。这正是AgentRun的价值所在——它代表了一种新的技术哲学：在追求智能的同时，不忘记那些看似平凡却至关重要的基础能力。因为在企业级应用的世界里，稳定永远比聪明更重要，可控永远比强大更关键。