刘博说云

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的价值所在——它代表了一种新的技术哲学：在追求智能的同时，不忘记那些看似平凡却至关重要的基础能力。因为在企业级应用的世界里，稳定永远比聪明更重要，可控永远比强大更关键。

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

Wed, 20 Aug 2025 21:52:11 +0800

在云计算行业工作的这些年里，我先后经历了腾讯云、阿里云和亚马逊云。从后台研发到产品经理，再到直接面对客户的TAM，角色的转变让我得以从不同维度观察这个行业。如今，当我即将转向AI Infrastructure领域时，回望这段经历，最让我印象深刻的不是技术的演进，而是一个看似简单却充满矛盾的理念——“用户第一”。

每一家云厂商都在标榜”用户第一”，这几乎成了行业的政治正确。然而，当你深入观察这些公司的产品形态、设计理念和市场策略时，会发现一个有趣的现象：同样喊着”用户第一”的口号，做出来的产品却大相径庭，甚至在某些方面完全相反。这种差异背后，隐藏着云产品设计中一个根本性的悖论。

可爱的迷茫

我把云厂商的这种状态称为“可爱的迷茫”。说它可爱，是因为每个产品团队都真诚地想要服务好用户；说它迷茫，是因为一个残酷的事实——很多时候，用户自己都不清楚自己需要什么。

这种迷茫在产品设计中表现为三种典型的风格。第一种是自嗨型团队，他们对技术和产品有着强烈的信念，相信自己的判断胜过用户的表达。当这种直觉正确时，他们能创造出引领行业的产品；但更多时候，他们做出的是”自己认为很牛，但用户用起来一言难尽”的产品，最终草草下线。

第二种是纠结型团队，他们总是担心顾此失彼，想要A功能，又担心丢了B用户。这种患得患失不仅让他们错过市场先机，更容易走向”既要又要”的误区。如果幸运，可能做成一个All in One的产品；如果不幸，就是一个四不像，从产品命名到功能定义，每个层面都充满了妥协和矛盾。

第三种是拿来主义型。我曾经和某国内Top3云厂商的产品经理交流，当我问他为什么要这样设计产品时，他的回答是”因为友商这样做”。当我进一步追问”你怎么知道友商做的是正确的，或者适合你们的”时，他陷入了沉默。这种简单的跟随策略，忽视了每家公司用户群体的差异性，也放弃了自己的思考。

FaaS的成本辩证法

要理解”用户第一”的复杂性，FaaS（Function as a Service）产品提供了一个绝佳的案例。在我接触的用户中，对FaaS成本的认知呈现出两极分化：有人认为它非常昂贵，甚至比EC2还贵；也有人认为它很便宜，对业务来说性价比极高。

有行业大佬一语中的：“FaaS是用成本换效率，换时间”, 这个表述精准地指出了FaaS的价值本质。还有人认为FaaS天然适合中长尾客户，因为他们更看重灵活性而非绝对成本。这些观点都有其道理，但也都只是部分真相。

这种认知差异的根源在于不同用户对”成本”的定义完全不同。对于个人开发者和初创企业来说，FaaS的按需付费和零运维成本极具吸引力，他们看重的是试错效率和人力成本的节省。但对于那些把FaaS当作EC2使用的用户——比如24小时运行爬虫任务、业务负载稳定无波动的场景，FaaS的成本确实高得离谱。

更深层的问题在于，很多时候我们是 “拿着锤子找钉子”。当有人说”FaaS适合某某业务”时，往往是从”我们已经有了FaaS，哪些用户应该来用”的角度思考，而不是真正从用户角度出发——用户需要什么？为什么需要？我们要关注哪部分用户？如何服务他们？

这种思维方式的差异，其实也反映了不同角色的视角。对产品经理而言，必须从用户需求出发去设计产品；而对解决方案架构师来说，基于现有产品去寻找合适的应用场景也无可厚非。但问题是，这两种视角如何有机结合？如何避免产品设计与用户需求的脱节？

这个案例揭示了一个深刻的问题：当两类用户的需求出现根本性冲突时，产品该如何选择？如果为了降低计算成本而引入预留实例，就会削弱FaaS的弹性优势；如果坚持纯粹的Serverless理念，就会把高负载用户拒之门外。任何选择都意味着取舍，而这种取舍恰恰与”服务所有用户”的理想背道而驰。

真正的挑战在于，如何在产品设计的前瞻性和用户需求的现实性之间找到平衡。这不仅需要产品经理深入理解用户，也需要解决方案架构师准确把握产品价值，更需要整个团队在”用户需要什么”和”我们能提供什么”之间建立有效的反馈循环。只有这样，”用户第一”才不会沦为一句空洞的口号。

中庸之道的智慧

在三家云厂商的工作经历让我深刻理解了 “中庸之道” 在产品设计中的重要性。这里的中庸，不是和稀泥式的折中，而是在充分理解矛盾的基础上做出明智的选择。

腾讯云曾经在Serverless领域取得过辉煌成就，Forrester评测亚洲第一的成绩证明了其技术实力。但在后续的发展中，面对电信云和火山引擎等新兴力量的挑战，如何在保持技术领先和满足更广泛用户需求之间找到平衡，成为了一个难题。

阿里云作为国内市场份额最高的云服务商，其高度的自研能力和开源文化都值得称道。但在面对国资云和运营商云的竞争时，如何在保持技术纯粹性和适应本土化需求之间寻找平衡，同样充满挑战。最近在AI领域的发力，某种程度上也是在寻找新的平衡点。

亚马逊云作为全球领导者，其产品哲学更多体现在”固执”上——坚持自己认为正确的方向，即使短期内不被理解。这种看似不够”用户第一”的做法，反而赢得了特定用户群体的高度认可。在AI时代初期的相对缓慢，以及后续通过Claude合作、Nova推出等一系列动作的加速，都体现了在坚持与适应之间的平衡艺术。

产品设计的减法哲学

真正的”用户第一”，或许恰恰需要承认一个事实：你无法服务所有用户。产品成功的关键，往往不在于你能做什么，而在于你选择不做什么。

这种减法哲学在云产品设计中尤为重要。当一个产品试图既满足个人开发者的便捷性需求，又满足大企业的安全合规要求，还要兼顾成本敏感用户的价格诉求时，最终的结果往往是谁都不满意。相反，那些在特定领域做到极致的产品，虽然服务的用户群体可能较窄，但却能获得这些用户的高度认可和忠诚。

小而美不是退而求其次，而是一种清醒的选择。在技术迭代如此迅速的今天，与其追求大而全的幻象，不如在细分领域建立真正的竞争优势。这需要产品团队有足够的勇气说”不”，有足够的定力抵制”既要又要”的诱惑。

走向AI时代的思考

当我即将转向AI Infrastructure领域时，我发现这个新兴领域正在重复云计算早期的某些模式。各种AI平台都在宣称”让AI变得更简单”、”人人都能用AI”，这与当年云计算”让计算变得更简单”的口号如出一辙。

但云计算十多年的发展历程已经告诉我们，技术民主化的理想与现实之间存在巨大鸿沟。不是每个人都需要成为AI专家，正如不是每个人都需要直接操作云资源。真正的价值在于找到合适的抽象层次，为不同层次的用户提供恰当的工具。

AI Agent Infrastructure作为我关注的重点方向，同样面临着”用户第一”的挑战。是追求通用性，让每个人都能构建AI Agent？还是聚焦特定场景，为专业用户提供强大工具？这些选择将决定产品的最终形态。

从云计算到AI，技术在变，但产品设计的本质挑战并未改变。”用户第一”依然是正确的方向，但如何解读和实践这个理念，需要更多的智慧和勇气。承认无法服务所有人，在看似矛盾的需求中找到自己的定位，用减法思维打造产品的核心价值——这些从云计算时代积累的经验，在AI时代同样适用。

或许，真正的”用户第一”，是帮助用户发现他们真正需要什么，而不是简单地满足他们认为自己需要的东西。这需要产品设计者既有同理心去理解用户，又有远见去引领方向。在这个意义上，”中庸之道”不是妥协，而是一种更高层次的智慧——在理想与现实、坚持与适应、服务与引领之间，找到属于自己产品的平衡点。

五个人教一个人点鼠标：云服务的荒诞现实

Sat, 09 Aug 2025 23:26:32 +0800

最近一位创业者朋友向我诉苦，他们公司在使用某云服务时遇到了配置问题，售后安排了一场视频会议。原本以为很快就能解决，结果画面令人啼笑皆非：屏幕那头先后出现了5个人，每个人都在指挥他”点这里”、”试试那个”，折腾了整整一个小时，问题依然没有解决。最后，对方建议他提工单或者”再找找其他同事”。

这个场景可能很多人都不陌生。在云服务的售后支持中，”多人会诊”式的远程协助已经成为一种常态。当然，我们需要公平地说，这种模式下会出现三种情况：

第一种，遇到真正的专家。这些人对产品了如指掌，通过简短的沟通就能准确定位问题，三下五除二就帮用户解决困扰。这种体验是美好的，用户会感受到专业的力量。

第二种，遇到经验丰富的老手。他们可能不是这个具体产品的专家，但凭借丰富的经验和扎实的技术功底，通过合理的试错和推理，也能较快地帮助用户找到解决方案。这种体验也是可以接受的，毕竟不是每个问题都能一眼看穿。

但第三种情况，就让人深思了。支持人员明显不熟悉产品，不断地和用户确认最基础的信息，反复尝试各种可能，甚至在视频中能听到他们内部的讨论声：”这个按钮是干什么的？””要不你试试看？”一个小时过去了，问题没有任何进展，最后只能建议用户走其他渠道。

前两种情况证明了专业支持的价值，但第三种情况的大量存在，恰恰暴露了云服务行业最深层的问题。

产品的原罪：当”易用性”成为奢侈品

让我们直面一个尖锐的问题：如果一个云产品需要多人视频指导才能完成基础配置，那这个产品从设计上就是失败的。

优秀的产品设计应该遵循”Don’t make me think”原则。用户界面应该是自解释的，操作路径应该是直观的，错误提示应该是明确的。当用户需要专人指导才能完成操作时，每一次”点击这里”的指令，都是在为产品设计的缺陷买单。

更讽刺的是，这种人力密集型的支持模式，恰恰违背了云计算”规模化”和”自动化”的核心理念。我们用最原始的方式，在支撑最先进的技术产品。这就像用马车运送火箭零件，不是不能做，而是根本上就错了。

伪服务的陷阱：专业的缺位与时间的浪费

在那些”多人会诊”的场景中，最令人不安的恰恰是第三种情况的普遍存在。当支持人员自己都不熟悉产品，却在指导用户操作时，这种”伪服务”比没有服务更可怕。

想象一下这个画面：用户满怀期待地等待专业支持，结果发现对方在不断试错，反复确认最基本的信息，甚至在内部讨论”这个按钮是干什么的”。这不是服务，这是一场关于”不专业”的现场直播。

真正的专业服务，应该是一次就能诊断问题，两次就能提供方案，而不是把用户当成小白鼠进行集体实验。当4-5个人围观一个用户操作一小时还解决不了问题时，这已经不是能力问题，而是整个服务体系的结构性缺陷。

这里有一个残酷的真相：很多所谓的”产品研发”或”售后专家”，其实对自家产品的了解程度，可能还不如一个经常使用的资深用户。这种专业能力的倒挂，是云服务行业的一大讽刺。

信任的雪崩：云计算的哲学危机

这里触及了一个更深层的问题：云计算的本质是什么？是信任。

用户选择云服务，本质上是一种信任托付——把数据、业务、甚至公司的命脉交给你。这种信任是云计算商业模式的基石。然而，每一次低效的支持体验，都在悄然侵蚀这个基石。

当用户看到连你们自己的员工都搞不清楚产品怎么用时，他们心中会产生一个可怕的疑问：“如果你们连自己的产品都不了解，我怎么相信你们能保护好我的数据？”

这种信任的流失是渐进的、累积的，但崩塌却可能是瞬间的。正如金融行业至今对公有云保持警惕，各种等保合规要求的本质，就是试图用制度和规范来弥补信任的缺失。但信任一旦失去，再多的合规认证都无法完全修复。

更糟糕的是，这种低效的支持模式会产生负面的情绪价值。用户本来带着问题来寻求帮助，结果不仅问题没解决，还要忍受一个小时的无效沟通，这种挫败感会深深印在用户心中。下次再遇到问题时，他们可能会直接选择换一家服务商。

真正的最佳实践：回归产品的本质

那么，什么才是真正的最佳实践？

首先，产品要回归”可用性”的本源。与其投入大量人力进行低效的售后支持，不如把这些资源投入到产品优化中。一个真正优秀的云产品，应该让80%的用户能够自助完成80%的操作。

其次，建立真正专业的支持体系。这不是人数的问题，而是专业度的问题。一个真正了解产品的工程师，抵得上10个”点这里点那里”的指挥官。专业的支持应该是分层的：自助文档解决基础问题，社区解答常见疑问，专家介入复杂场景。

再次，要有清晰的问题升级机制。如果一线支持无法解决，应该快速升级到更专业的团队，而不是让更多不懂的人加入”指挥”。用户的时间是宝贵的，每一分钟的等待都在消耗信任。

最后，也是最重要的，要意识到每一次用户交互都是在经营信任。高效、专业的支持体验会增强信任，而混乱、低效的”人海战术”则在透支信任。在云计算时代，信任比技术更稀缺，也更脆弱。

写在最后

“五个人教一个人点鼠标”看似是一种重视，实则是一种无奈。它反映的不是服务的充分，而是产品的不足、组织的低效和专业的缺失。

云计算走到今天，技术已经不是主要瓶颈，信任才是。每一次”点这里、点那里”的指令背后，都是信任账户的一次提取。当余额不足时，再先进的技术、再庞大的团队，都无法挽回用户的离去。

真正的最佳实践，不是派更多人去指挥用户，而是让用户不需要任何指挥就能完成想做的事。这不仅是产品设计的目标，更是云计算行业重建信任的必由之路。

当下一次用户需要帮助时，请记住：他们需要的不是一群指挥官，而是一个真正懂行的专家。如果做不到这一点，那么所谓的”客户至上”，就只是一句空洞的口号。