Kimi Hosted Agents发布：Harness云托管+CLI实操，开发者必看

2026 年 11 月 5 日，月之暗面（Moonshot AI）正式推出 Kimi Hosted Agents（托管智能体），将支撑 AI Agent 运行的 Harness（智能体运行框架）作为云端服务开放给企业和开发者。这意味着，开发团队不再需要从零搭建完整的 Agent 运行环境，即可使用云端托管能力完成长程任务执行、工具调用和多智能体协作。

此次发布值得关注的地方，并不只是 Kimi 增加了一项智能体产品，而是其产品能力开始从模型推理进一步延伸到 Agent 的生产运行环节。

过去，开发者可以通过 API 调用 DeepSeek、Kimi、Gemini 等大模型；但如果希望模型持续执行复杂任务，还需要自行处理上下文管理、工具调度、代码执行环境、任务恢复和权限控制等问题。

Kimi Hosted Agents 试图解决的正是这部分工程问题。通过提供云端 Harness、独立沙箱、140+ Skills、30+ 插件以及官方 Agent 模板，平台希望让开发者把更多精力放在业务流程和智能体能力设计上，而不是重复建设底层运行设施。

那么，Kimi Hosted Agents 究竟有哪些新能力？它与传统大模型 API 有什么区别？开发者又应该如何开始使用？

一、Kimi Hosted Agents 发布：从模型 API 到 Agent 运行环境

理解这次发布，首先需要区分两个概念：模型推理服务和智能体运行服务。

传统的大模型 API 主要解决模型能力如何被外部应用调用的问题。开发者向接口发送 Prompt、上下文和相关参数，模型返回文本、结构化数据或者工具调用建议；至于后续如何执行工具、保存任务状态、处理中断以及管理多个任务，通常需要应用开发团队自行实现。这种方式适合普通问答、文本生成、代码补全等相对明确的请求。

但对于一个需要持续运行的 Agent 来说，仅有模型接口还不够。

例如，企业需要开发一个自动化投研助手，任务可能包括：

• 定期获取市场行情和企业公告。
• 检索指定公司的财务数据。
• 对比不同时间段的经营指标。
• 调用工具处理 Excel 文件。
• 汇总研究结果并生成报告。
• 将结果保存到企业内部系统。

这不是一次简单的模型请求，而是一系列连续执行的操作。如果开发团队完全自行搭建运行环境，就需要考虑任务状态保存、上下文管理、工具调用、异常处理和执行权限等问题。

Kimi Hosted Agents 将这些运行基础设施整合为云端服务，开发者可以配置 Agent、接入工具并提交任务，由平台负责相应的运行环境维护。

其核心定位可以概括为：
Harness as a Service，即将智能体运行框架作为服务提供。

这也是 Kimi 此次产品升级与传统模型 API 服务之间最重要的区别。

二、Harness 是什么？为什么它会成为 Agent 开发的关键环节？

Harness 可以理解为智能体的运行与控制框架。大模型负责理解任务、分析信息和决定下一步行动，但模型本身并不会自动获得操作计算机、访问数据库或者持续运行程序的能力，这些能力需要通过外部工具、执行环境和任务管理机制实现。Harness 就是把这些组件组织起来的运行层。

一个相对完整的 Agent Harness 通常涉及以下几个部分：

1. 上下文与会话管理

负责保存用户输入、模型输出、工具执行结果和任务历史。当一个 Agent 需要执行几十个步骤时，系统必须知道此前已经完成了什么、当前处于哪个阶段，以及下一步应该执行什么。如果没有会话持久化机制，任务中断后就可能丢失执行状态。

1. 工具调用与执行管理

Agent 可以根据任务需要调用搜索、代码执行、文件处理和外部 API 等工具。Harness 需要负责解析工具调用请求、检查权限、执行操作，并将结果重新交给模型。

1. 沙箱执行环境

当 Agent 需要运行代码、读写文件或处理外部数据时，需要一个相对隔离的执行环境。沙箱可以限制智能体能够访问的资源，降低不受控制的操作带来的风险。

1. 异常处理与任务恢复

长程任务可能遇到网络断开、执行超时、工具返回错误或者服务异常。运行框架需要处理重试、状态恢复和任务调度，避免每次出现问题都从头执行。

1. 权限和安全控制

企业 Agent 可能接触内部数据、客户信息和业务系统。因此，系统需要明确哪些工具可以调用、哪些网络资源允许访问，以及哪些操作必须经过审核。

这几个部分共同决定了 Agent 能否从演示环境进入真实生产流程。Kimi 官方文档也将会话历史、工具执行、沙箱、失败恢复和超时重试列为托管服务的重要能力。其中，平台支持持久化会话历史，并提供执行环境与会话状态管理；对于符合条件的任务，平台还可以在发生故障后恢复执行。

这意味着开发者需要自行维护的运行基础设施有所减少，但业务逻辑、工具权限和结果验证仍然需要开发团队负责。

三、Kimi Hosted Agents 有哪些值得关注的新功能？

这次发布的核心能力，可以从运行环境、工具生态、安全管理和多智能体协作四个方向理解。

1. 7×24 小时托管运行，支持长程任务

Kimi Hosted Agents 提供云端托管运行环境，支持长时间跨度的任务执行。对于企业来说，这项能力的价值不在于让模型回答得更快，而在于能够让 Agent 持续处理需要多个步骤才能完成的工作。

例如：

• 企业运维：持续监控系统指标，发现异常后收集日志并生成分析结果。
• 金融研究：定期读取市场信息，整理数据并生成研究报告。
• 客户服务：处理客户问题，根据不同业务规则调用相应工具。
• 企业办公：定时汇总文件、整理数据并生成文档。

官方将其定位为适合长程任务和异步工作的托管服务。

需要注意，7×24 小时托管指的是运行环境和服务形态，并不等于所有 Agent 任务都能保证无错误完成。任务本身仍然受到模型能力、工具可用性、权限配置和执行资源等因素影响。

1. 140+ Skills 与 30+ 插件，降低工具接入成本

工具生态是 Agent 能否真正完成任务的重要因素。Kimi Hosted Agents 当前提供 140 余项 Skills 和 30 余种插件，覆盖以下方向：

• 联网检索与信息收集。
• 专业数据查询。
• 办公文档处理。
• 内容生成。
• 外部工具和业务系统接入。

Skills 与插件并不是同一种东西。Skill 更侧重于为智能体提供可复用的知识、操作步骤和工作流程；插件则可以整合技能、MCP 服务等能力，让 Agent 通过统一入口使用外部工具。

此外，企业还可以接入自己的数据源、自定义工具和 MCP 服务。例如，一家企业已经拥有内部客户管理系统，不一定需要重新开发一套完整的客户查询能力，而是可以通过适当的工具接口，让 Agent 在权限允许的范围内访问相关业务数据。

这可以减少重复开发，但并不意味着所有第三方系统都能直接接入。具体仍然取决于接口形式、身份认证和权限配置。

1. Kimi Inference Hook：把安全检查放在模型推理之前

企业使用 Agent 时，一个容易被忽略的问题是：模型在执行任务过程中，可能接触到不应该进入模型上下文的信息。例如，企业内部数据库包含客户联系方式、交易记录和业务机密；如果 Agent 在检索过程中获取了这些信息，就需要有机制判断哪些内容可以进入后续推理。

Kimi 为此提供了独立安全组件 Kimi Inference Hook。它的基本工作流程是：

• Agent 接收到任务输入。
• 安全组件检查任务输入内容。
• Agent 调用外部工具后，安全组件继续检查工具返回的数据。
• 根据企业预先定义的规则，决定放行或者拒绝。
• 只有通过检查的内容才会进入模型推理。

这种方式把安全检查放到了每次模型推理之前，而不是只在用户提交任务时检查一次。它对于需要访问内部数据的企业应用具有一定意义。

不过，Kimi 官方明确说明，Kimi Inference Hook 目前仅向企业认证用户定向开放，需要联系官方申请。因此，普通开发者不能直接将其视为所有账户默认具备的安全能力。

1. 多智能体协作：将复杂任务拆分执行

多智能体协作是此次产品发布的另一项重点。在传统的单 Agent 模式中，一个智能体需要同时完成资料检索、数据分析、代码执行和结果整理等工作；任务复杂度增加后，单个智能体容易出现上下文负担过重、执行步骤混乱等问题。

多智能体编排则允许一个协调智能体将任务拆分，并交给不同的子线程处理。例如，企业需要生成一份行业研究报告，可以按照以下方式组织任务：

• 协调 Agent：接收任务，制定执行计划并分配工作。
• 资料 Agent：负责检索行业报告和公开信息。
• 数据 Agent：负责整理财务数据和市场指标。
• 分析 Agent：负责对数据进行比较和分析。
• 协调 Agent：汇总子任务结果，生成最终报告。

Kimi 官方文档采用协调线程（Coordinator Thread）和子线程（Child Thread）的架构。这里有一个需要注意的技术限制：子线程不能继续创建下一级线程，因此它并不是可以无限递归扩展的多智能体集群。

官方建议将其用于任务边界清晰、能够并行处理的工作。如果任务本身不需要拆分，直接使用普通 Agent 即可，避免增加不必要的编排复杂度。

四、首批 8 个金融 Agent 模板，企业可以直接参考哪些应用？

除了基础运行环境，Kimi 还提供了官方 Agent 模板，帮助企业缩短从原型设计到业务验证的时间。

11 月 5 日的发布公告重点介绍了首批 8 个金融 Agent 模板，主要覆盖投研建模、深度研究、晨报生成、IPO 跟踪和持仓监控等任务。当前开放平台文档进一步列出了 12 个官方模板，覆盖金融研究、游戏开发、运维响应和出海社群运营等场景。

这类模板的意义在于，企业不必完全从空白配置开始，可以在已有工作流基础上修改任务要求、接入内部数据和调整工具权限。几个值得关注的应用包括：

金融深度研究 Agent
从数据获取、信息检索到研究分析，最终生成 Word 报告和可编辑的路演 PPT。

金融晨报 Agent
按照预设周期汇总行情、财报和资讯，生成持仓早报，适合需要定期获取市场信息的业务团队。

港股 IPO 扫描 Agent
定期扫描新递交的上市申请文件，提取招股书信息并生成周报。

基金对账 Agent
读取相关对账单，识别异常数据并生成报告，辅助工作人员完成后续复核。

SRE 事故响应 Agent
并行核查系统日志、近期变更和运行指标，辅助定位故障原因并生成修复补丁。

需要强调的是，官方模板提供的是可复制和调整的任务架构，并不意味着复制之后就能直接适配所有企业的业务系统。企业仍需配置内部数据源、工具权限和具体业务规则。

五、Kimi Hosted Agents 怎么使用？CLI 与 API 实操流程

对于开发者来说，了解产品功能之后，更重要的是如何实际创建一个 Agent。Kimi 官方目前提供三种使用方式：

表格

官方推荐使用 kha CLI 完成第一个任务。

1. 创建 Kimi 开放平台账号

首先进入 Kimi 开放平台，注册账号并完成相应配置。使用 CLI 或 API 时，需要在组织管理的 API 管理页面创建 API Key，并将密钥配置到环境变量中：

export KIMI_API_KEY="你的_KIMI_API_KEY"

注意不要把 API Key 直接写进公开代码仓库，也不要在日志中输出完整密钥。

1. 安装 kha CLI

在 macOS 或 Linux 环境中，可以根据官方快速开始文档执行安装命令：

curl -fsSL https://ha-static.moonshot.cn/kha/install.sh | sh
export PATH="$HOME/.local/bin:$PATH"
kha login

完成安装后，使用 kha login 进行身份认证。

官方文档还说明，kha CLI 可以配合 Kimi Code、Claude Code 和 Codex 等 AI 编程助手使用。开发者可以通过自然语言创建智能体、提交任务和查看执行状态，不必一开始就手动编写完整的 API 请求。

1. 查看可用 Agent

完成认证后，可以先查看当前账户下可用的智能体：

kha agents list

也可以通过 REST API 获取：

curl -sS "https://api.moonshot.cn/v1/agents" \
   -H "Authorization: Bearer $KIMI_API_KEY" \
   -H "kimi-api-version: 2026-09-01-beta"

响应中包含智能体定义及其 ID。选择需要使用的 Agent，并保存对应的 ID：

export AGENT_ID="agent_..."

这里的 ID 需要替换为实际接口返回值。

1. 创建云端执行环境

接下来需要为智能体创建执行环境。官方 API 使用 POST /v1/environments 创建环境。下面是一个云端沙箱配置示例：

curl -sS -X POST \
   "https://api.moonshot.cn/v1/environments" \
   -H "Authorization: Bearer $KIMI_API_KEY" \
   -H "kimi-api-version: 2026-09-01-beta" \
   -H "Content-Type: application/json" \
   -d '{
     "name": "PPT制作环境",
     "description": "用于生成和保存PPT文件",
     "config": {
       "type": "cloud"
     }
   }'

创建成功后，需要保存返回的环境 ID：

export ENVIRONMENT_ID="env_..."

需要注意，云沙箱镜像创建后还需要一定时间进行异步构建。如果环境尚未就绪，创建会话时可能出现错误，可以等待环境完成初始化后重试。

1. 创建 Agent 会话

环境准备完成后，将 Agent 和执行环境关联，创建一个新的会话：

curl -sS -X POST \
   "https://api.moonshot.cn/v1/sessions" \
   -H "Authorization: Bearer $KIMI_API_KEY" \
   -H "kimi-api-version: 2026-09-01-beta" \
   -H "Content-Type: application/json" \
   -d "{
     \"agent_id\": \"$AGENT_ID\",
     \"environment_id\": \"$ENVIRONMENT_ID\",
     \"title\": \"生成金融市场分析PPT\"
   }"

从响应中获取会话 ID：

export SESSION_ID="sesn_..."

一个会话对应一次智能体运行实例，可以在其中持续提交任务和获取执行结果。

1. 发送任务并获取执行结果

例如，需要 Agent 汇总近期金融行业信息并生成一份 PPT，可以通过以下请求发送任务：

curl -sS -X POST \
   "https://api.moonshot.cn/v1/sessions/$SESSION_ID/events" \
   -H "Authorization: Bearer $KIMI_API_KEY" \
   -H "kimi-api-version: 2026-09-01-beta" \
   -H "Content-Type: application/json" \
   -d '{
     "events": [
       {
         "type": "user.message",
         "data": {
           "content": [
             {
               "type": "text",
               "text": "汇总近期金融行业市场信息，分析重点变化，并生成一份用于晨会的PPT。"
             }
           ]
         }
       }
     ]
   }'

任务提交之后，可以通过 SSE（Server-Sent Events，服务器发送事件）订阅会话事件流，实时查看 Agent 的执行状态：

curl -sS -N \
   "https://api.moonshot.cn/v1/sessions/$SESSION_ID/events/stream" \
   -H "Authorization: Bearer $KIMI_API_KEY" \
   -H "kimi-api-version: 2026-09-01-beta" \
   -H "Accept: text/event-stream"

事件流可以帮助开发者观察智能体是否正在运行、是否调用工具，以及是否已经生成最终结果。当会话状态变为 idle 时，代表本轮执行已经完成。之后可以通过 Artifact 接口查询和下载智能体生成的 PPT 文件。

这一流程基本覆盖了从 Agent 选择、环境创建、会话启动到任务执行和文件交付的主要步骤。

需要说明的是，上述示例展示的是官方文档中的核心调用流程，实际运行还需要根据账户权限、Agent 配置和环境状态进行调整。

六、Kimi Hosted Agents 如何计费？企业需要关注哪些成本？

Agent 的成本不能只看模型 Token 价格。这是因为一个长程任务除了模型推理，还可能涉及沙箱运行、工具调用和多次任务重试。

Kimi Hosted Agents 采用按量计费模式，费用主要由三个部分组成：

• 模型推理费用：根据模型实际输入和输出 Token 用量计算。
• 沙箱运行费用：根据执行环境实际运行时长计算。
• 插件调用费用：根据插件调用次数及相应单价计算。

沙箱运行参考价格为每小时 0.072 元，最终费用还需要叠加模型推理和插件调用费用。因此，不能简单地将 0.072 元理解为完成一个 Agent 任务的全部费用。

企业在正式投入生产前，建议至少统计以下指标：

表格

例如，一个每天执行一次的研究任务，如果需要持续检索数据、分析文件并生成报告，那么模型推理、沙箱运行和插件调用都会影响最终账单。因此，企业应该先用小规模任务测算实际成本，再决定是否扩大运行规模。

七、Kimi Hosted Agents 与传统 API 有什么区别？

需要明确，Kimi Hosted Agents 并不是传统意义上的大模型 API 替代品，两者解决的问题不同。传统模型 API 主要负责提供推理能力，而 Hosted Agents 进一步提供智能体运行所需的环境和管理能力。

表格

如果只是开发一个普通的聊天机器人，传统模型 API 通常已经足够。如果需要让 Agent 长时间运行、处理多个工具、执行异步任务并保留完整的任务状态，那么托管运行环境就具有更明显的价值。

对于企业开发团队而言，两种方式也不是绝对互斥的，可以根据业务要求选择自行维护 Harness，或者使用托管运行服务。

八、多模型时代，Agent 开发为什么还需要关注 API 接入？

Kimi Hosted Agents 的发布，也反映出一个值得关注的行业变化：AI 应用的竞争正在从单纯的模型能力，延伸到工具、运行环境和业务工作流。

对于开发者而言，模型只是整个系统的一部分。例如，一个企业级智能体可能需要使用 Kimi 完成复杂任务分析，使用 DeepSeek 处理成本敏感型文本任务，使用 Gemini 处理多模态信息，还可能通过 Codex 辅助开发和维护代码。

这里需要区分模型、开发工具和运行框架：

• Kimi、DeepSeek、Gemini：属于大模型产品或模型服务。
• Codex：属于 AI 编程工具，可以辅助开发者编写和维护代码。
• Harness：负责组织 Agent 的执行过程。
• MCP：负责连接智能体与外部工具、服务和数据源。

它们之间可以形成协作关系，但并不是同一种产品。

尤其是当应用需要同时接入不同模型时，开发团队还要考虑接口格式、身份认证、模型选择和用量统计等问题。如果每接入一个模型都需要重新维护一套请求逻辑，项目规模扩大之后，接口管理和运维工作也会随之增加。

这时，可以根据实际模型支持情况，使用统一 API 接入方式管理不同模型的调用。例如，星链 API 提供多模型聚合与统一 Key 接入能力，适合需要管理多个模型供应商、希望减少接口适配工作的开发场景。

不过，统一 API 接入与 Agent 托管运行仍然是两个不同层面的能力：前者主要解决模型访问和接口管理，后者解决任务执行、会话和运行环境问题。企业在设计架构时，需要分别评估。

未来，一个完整的 AI 应用可能同时包含模型 API、Agent Harness、MCP 工具服务、企业数据层和安全控制系统。如何让这些组件稳定协作，将成为工程落地的重要课题。

九、企业是否应该使用 Kimi Hosted Agents？上线前需要检查什么？

Kimi Hosted Agents 降低了 Agent 运行基础设施的建设门槛，但并不代表所有业务都适合直接迁移到托管模式。企业可以从以下几个方面进行判断。

第一，任务是否需要持续运行。

如果只是一次性问答、简单文本生成或者普通数据查询，没有必要为了使用托管环境而增加额外架构。如果任务需要定时执行、连续处理多个步骤，或者在网络中断后继续恢复，那么托管运行模式值得评估。

第二，是否需要访问企业内部数据。

如果 Agent 需要连接内部数据库、业务系统和私有文件，需要提前确认网络访问方式、身份认证和权限边界。Kimi 提供自托管沙箱环境，但官方文档明确说明，即使沙箱工具运行在企业自己管理的主机上，模型调用、智能体编排和会话管理仍然由平台负责。因此，自托管沙箱不等同于完整的私有化部署。

第三，能否控制工具调用风险。

企业应该对工具执行权限进行分级管理。例如，查询数据可以设置为只读权限，修改数据、发送消息和执行重要业务操作则应该增加人工审批或额外校验。

第四，是否能够核算完整成本。

不能只计算模型 Token，还需要考虑沙箱时长、插件费用和失败重试。尤其是多智能体任务，多个子线程可能同时执行工作，实际消耗需要通过用量报表进行核算。

第五，是否建立结果验证机制。

Agent 完成任务不等于任务结果一定正确。金融报告、企业运维、财务数据处理等业务，都应该设置输出校验、异常告警和人工复核流程。

十、总结：Agent 竞争正在从模型能力走向运行基础设施

Kimi Hosted Agents 的发布，反映了大模型厂商正在进一步向 AI Agent 的工程化和生产化环节延伸。

从产品设计来看，它将 Harness、云端沙箱、会话管理、工具调用、多智能体编排和安全控制整合到托管服务中，减少了开发团队重复搭建底层运行环境的工作。140+ Skills、30+ 插件以及官方 Agent 模板，则进一步降低了部分常见业务场景的工具接入和流程设计成本。

但企业仍然需要自行解决业务规则、数据权限、工具安全和结果验证等问题。托管服务并不能替代完整的企业应用架构。

对于开发者来说，比较合理的落地方式是先选择一个任务边界清晰、执行流程相对固定的业务场景，使用官方模板或 CLI 完成原型验证，再逐步增加工具、数据源和多智能体协作能力。

从更长远的角度看，未来 AI 应用的竞争不再只是比较哪一个模型的参数更多、推理速度更快，而是要看模型能否与工具、数据和运行环境形成稳定的协作体系。Kimi Hosted Agents 正是这一发展方向下的一次产品尝试。