Kimi Hosted Agents正式发布：AI智能体云端托管，支持7×24小时运行

做一个能回答问题的AI助手，和做一个能持续运行的AI产品，中间还差不少工程工作。

模型接好了，工具也能调用了，但任务执行到一半断开怎么办？生成的文件保存在哪里？多个Agent同时工作，谁来分配任务？接入企业数据以后，又该怎么限制权限？

很多团队不是卡在AI“不够聪明”，而是卡在让它稳定工作的那套系统上。

2026年11月5日，月之暗面正式发布 Kimi Hosted Agents（托管智能体），将支撑Agent运行的Harness作为云端服务提供给企业和开发者。

团队不必从零搭建整套运行框架，就可以使用托管环境，配置自己的智能体，执行长时间任务，并组织多个Agent协作。

这次发布不是又增加了一款聊天模型，而是把AI应用背后的运行基础设施做成了服务。

以前是把任务交给模型，现在是把模型、工具和执行环境一起组织起来，让任务有地方持续完成。

官方发布介绍：

https://www.kimi.com/news/kimi-hosted-agents

01｜Kimi Hosted Agents是什么？把Agent的运行框架搬到云端

Kimi Hosted Agents采用的产品思路叫 Harness as a Service，可以理解为“智能体运行框架即服务”。

Harness不等于大模型本身。

它负责把模型调用、工具执行、会话状态、文件处理、权限控制和异常恢复等环节组织起来，让Agent能够围绕一个目标连续工作。

举个例子，用户要求生成一份市场分析报告。

模型可能需要先搜索资料，再读取文件、整理数据、制作图表，最后输出文档。每一步产生的信息，都要能够交给后续步骤使用。

如果中间某个工具没有返回，或者执行环境出现问题，还需要知道任务停在哪里、哪些步骤已经完成。

Kimi Hosted Agents希望接手的，就是这些运行层面的工作。

开发者仍然需要定义业务目标、接入必要的数据和工具，但不必把所有会话管理、云端执行和恢复逻辑都重新实现一遍。

它减少的是基础设施的重复开发，不是把业务设计和结果验收一起省掉。

02｜与普通模型API有什么区别？一个提供推理，一个托管执行

普通模型API，主要负责接收输入并返回模型输出。

即使模型能够提出工具调用请求，应用通常仍然需要处理工具执行、结果回传，以及后续调用。

Kimi Hosted Agents则在模型之外，提供了更完整的运行服务。

按照官方文档，平台能够持久化会话历史，在云沙箱中执行内置工具，并处理执行层的重试、调度和部分故障恢复。

可以简单区分为：

模型API更适合已经有自研框架、希望精细控制每一轮调用的团队；托管智能体更适合长时间或异步任务，希望减少运行环境维护工作的团队。

但也有一个容易忽略的细节：不是接入以后，所有工具都会自动迁移到Kimi服务器。

官方文档明确，内置工具可以由平台在云沙箱中执行，而自定义工具仍可能需要开发者自己的客户端执行。

因此，接入企业内部系统时，仍然需要设计接口、身份认证和错误处理。

官方产品概览：

https://platform.kimi.com/docs/hosted-agents/overview

03｜7×24小时托管，不等于每个任务永远不会中断

全天候运行，是这次发布的重要卖点。

它意味着Agent可以在云端环境中处理长程任务，不必把执行过程一直绑在开发者电脑上的某个窗口里。

会话管理文档也提供了状态查询、当前轮次取消、会话归档等操作，让应用能够判断任务是在运行、等待输入，还是已经终止。

这对实际业务很重要。

用户不仅需要一个“正在处理中”的提示，还需要知道任务是否真的在推进，以及什么时候应该补充信息或停止执行。

但7×24小时托管，不是“所有任务100%成功”的承诺，也不等于无限运行、无限预算。

任务仍可能因为输入不完整、外部服务不可用、权限不足或业务条件变化而无法继续。

因此，评估时更值得关注的是：发生异常以后，系统能否准确记录状态，是否能够恢复，以及是否及时让用户知道。

运行环境稳定，是完成任务的基础；任务结果是否正确，还需要另外验收。

04｜140余项Skills、30余个插件，减少从零接工具的工作

Kimi Hosted Agents在发布时提供了 140余项Skills和30余个插件，覆盖联网检索、专业数据查询、办公文档处理和内容生成等任务。

这些能力可以按需配置，而不是每搭建一个应用，都重新编写一套工具接入逻辑。

这里可以把Skill与插件分开理解。

Skill更偏向告诉Agent：某类任务应该按照什么方法完成，需要注意哪些规则。

插件则可以把工具与相关能力组织成一个可复用组合，让Agent连接外部资源。

平台也支持自定义Skill、插件、MCP服务和工具，便于接入企业已有的数据与业务系统。

例如，一个内容团队可以尝试配置资料检索、文档处理和写作相关能力，再接入自己的选题库，构建内部内容助手。

这属于应用设计示例，并不是平台已经替每家团队完成了内容系统。

现成工具可以减少接入工作，但资料是否可靠、输出是否合格，仍然取决于任务设计和验证。

Skills也不等于额外训练了一个专属模型，不能把挂载一份流程说明，理解成模型权重已经完成更新。

05｜多智能体协作：不是多开几个窗口，而是明确分工

Kimi Hosted Agents支持由一个协调智能体组织任务，再将部分工作委派给子线程执行，最后收集结果。

这类方式适合能够拆分、边界相对清楚的任务。

比如，要制作一份产品对比报告，可以设计这样的分工：不同子任务分别核对功能、价格和使用条件，再由协调智能体整理差异和结论。

这个例子展示的是一种可能的编排方式，并不是已经完成的官方实测案例。

多Agent的价值，在于不同工作可以使用合适的工具配置，也能分别查看执行记录。

但它并不天然优于单个Agent。

如果只是改写一段短文，强行拆成多个角色，可能只增加沟通步骤、执行时间和费用。

官方文档也提醒，不应为了使用多智能体而拆分简单任务。

复杂工作需要合理分工，简单工作更需要少走流程。

多智能体编排文档：

https://platform.kimi.com/docs/hosted-agents/multiagent-orchestration

06｜不只服务企业内部，也能嵌入自己的产品

Kimi Hosted Agents主要面向两类应用。

一类是内部业务，例如业务监控、研究分析和运维响应。

另一类是对外提供的产品，例如在App中加入研究助手、客服助手，或者在游戏中提供策略顾问。

这意味着，它更接近开发者可以调用的服务，而不是只供员工使用的独立聊天软件。

首批发布内容重点展示了8个金融Agent模板，包括研究建模、晨报、IPO跟踪和基金对账等方向。企业可以参考模板结构，再接入自己的系统和资料。

模板的价值，是提供一个可以开始修改的方案，而不是证明每个模板都能未经调整直接投入业务。

对于网站和SaaS开发者，也可以从自己的高频需求出发。

例如，一个产品资讯网站可以探索这样的流程：检索指定产品的官方更新，整理新增功能，生成编辑草稿，再交给人工审核。

这里真正需要设计的，不只是“让AI写文章”，还包括信息来源、更新时间、重复内容处理和发布权限。

托管服务解决运行问题，业务流程仍然需要开发者自己想清楚。

07｜独立沙箱、权限控制和审计，让Agent有能力也有边界

当Agent只能回答问题时，错误主要体现在内容上。

当它能够执行命令、写文件、连接数据库和调用外部服务时，错误就可能改变真实系统。

Kimi Hosted Agents提供独立沙箱、网络访问控制、过程记录和审计导出等能力，企业可以限制执行范围，并在需要时停止会话。

工具权限还可以配置为直接执行，或者等待客户端确认。

这里有一个值得开发者留意的默认行为：按照当前权限文档，未显式设置相关策略时，工具默认启用，并采用直接放行方式。

所以，不能把“平台支持权限管理”，理解为“所有重要操作默认都会询问”。

涉及写入业务数据、发送消息或修改配置时，应主动设置确认流程，或者禁用不需要的工具。

平台还可以结合独立安全组件 Kimi Inference Hook，在模型推理前检查任务输入和工具返回内容，并根据企业定义的规则放行或拒绝。

不过，Inference Hook目前仅向企业认证用户定向开放，不是所有账号默认具备的能力。

工具权限说明：

https://platform.kimi.com/docs/hosted-agents/permissions

08｜支持自托管，但不能直接理解为完整私有化

对于需要访问内部服务的企业，官方还提供自托管执行环境。

它允许沙箱工具运行在企业管理的主机上，但模型调用、智能体编排和会话管理仍由平台负责。

工具在自己的机器上运行，不代表整个Agent系统都留在企业内部。

官方文档明确说明，自托管环境不严格等于私有化部署，工具输入和执行结果仍会经过平台的模型推理接口。

因此，选择这种方式时，还应核对哪些数据会传出、由谁处理，以及是否满足自己的数据管理要求。

自托管环境也不意味着完全免运维。企业仍然需要管理自己的执行主机、依赖、权限和凭据。

这个模式目前只向企业认证用户开放，适合有明确内部访问需求、也能够维护相应环境的团队。

自托管环境说明：

https://platform.kimi.com/docs/hosted-agents/self-hosted-environments

09｜Kimi Hosted Agents多少钱？不能只计算Token

官方产品文档说明，托管智能体采用按量计费，主要包含三部分：

模型推理Token、沙箱运行时长，以及插件调用次数。

也就是说，完成一项任务的费用，不一定等于最后那段回答消耗了多少Token。

例如，一个任务需要处理文件、执行程序、查询数据，再生成报告，那么中间的模型调用和运行资源都应纳入计算。

多Agent协作也一样。并行执行可能缩短等待，但不代表总费用一定更低。

因此，评估性价比时，建议以一个完整任务为单位，观察结果质量、总消耗、等待时间和人工返工量。

具体单价、计费范围和规格，应以官方定价页面与实际账单为准，不能套用普通聊天会员的价格，也不应默认所有插件都免费。

官方定价说明：

https://platform.kimi.com/docs/pricing/hosted-agents

10｜怎么开始使用？控制台、CLI和API三种方式

官方提供控制台、kha CLI和API三种接入方式。

控制台适合先体验基础流程。 登录后配置智能体与环境，提交任务，查看运行过程和产物，不必先编写接口请求。

kha CLI适合在开发环境里管理任务。 可以通过命令行创建和配置智能体、提交任务、检查状态并获取文件。

API适合接入自己的产品。 应用可以创建会话、发送任务、订阅执行事件，并下载生成结果。

一个基本流程是：先确定智能体需要的模型、工具和Skills，再准备执行环境，创建会话，最后提交任务并检查交付文件。

第一次尝试，不必从复杂的企业流程开始。

可以先上传一份不含敏感信息的资料，让它整理成一份简报，检查三个问题：是否正确使用输入、是否留下可查看的执行记录、最终文件能否正常使用。

确认这条流程之后，再增加定时执行、多Agent分工或企业系统连接。

先把一个小任务完整跑通，比一次接入所有工具更容易判断实际价值。

Kimi开放平台：

https://platform.kimi.com/

官方快速开始：

https://platform.kimi.com/docs/hosted-agents/quickstart

总结｜AI Agent的下一步，不只是更聪明，还要更容易上线

Kimi Hosted Agents这次解决的，不是“模型会不会回答”这个问题。

它更关注模型如何持续调用工具、保存执行状态、处理异常，并以可观察、可管理的方式完成任务。

对开发团队而言，这有机会把一部分基础设施工作交给平台，让更多精力回到业务功能本身。

但托管不等于无需配置，多Agent不等于一定更高效，全天候环境也不等于任务永远不会失败。

真正值得验证的，仍然是自己的业务：能否稳定执行，费用是否可接受，权限是否可控，以及最终结果是否减少了人工返工。

把Agent做成演示是一回事，让它在真实业务里长期工作，是另一回事。

Kimi Hosted Agents尝试缩短的，正是这两者之间的距离。