Kimi把Agent Harness搬上云

Kimi 今日（2026 年 11 月 5 日）正式发布 Kimi Hosted Agents，把支撑智能体运行的 Harness 做成云端托管服务，企业无需从零搭建 Agent 循环、会话存储、沙箱和故障恢复系统，即可获得 7×24 小时运行的长程任务环境。

**Kimi Hosted Agents 是运行在 Kimi 开放平台基础设施上的预构建、可配置智能体服务。**它提供的不是一次模型问答，而是一套能够持续调用模型、操作工具、保存状态并在故障后恢复任务的运行系统。Kimi 将这套模式称为 Harness as a Service，即把 Harness 作为服务提供。

这次更新的重点并不是 Kimi 又多了一个 Agent 产品，而是它开始把企业最难维护、也最容易被低估的 Agent 基础设施收归平台。对于已经做过智能体原型的团队来说，模型调用通常不是最麻烦的部分；真正拖慢上线的是任务状态、工具权限、沙箱隔离、异常重试、断线续跑和审计记录。

Harness不是提示词，而是Agent的控制系统

**Agent Harness 是连接模型、工具、执行环境和任务状态的运行控制层。**如果把大模型比作智能体的大脑，Harness 更像神经系统加操作系统：它决定什么时候调用模型、模型能使用哪些工具、工具结果如何回填、任务失败后从哪里恢复，以及整个过程如何被观察和中止。

**传统模型推理接口只负责给出下一次输出。**开发者需要自己保存消息历史、解析工具调用、运行代码、处理超时，并把结果重新交给模型；一旦任务需要运行几十分钟甚至数小时，客户端断线、服务重启和第三方工具报错都会变成工程问题。

**Kimi Hosted Agents 把上述运行责任转移给了平台。**官方文档列出的托管能力包括事件化保存会话历史、云端执行内置工具、沙箱隔离、任务调度、超时重试、断线续读，以及平台故障后的自动接管和恢复。

Kimi 官方给出的判断是，企业通常需要投入数月时间才能搭建一套可用于生产的 Harness，而且系统上线后还要持续适配模型、工具和执行环境。这个说法并不夸张：能完成一次演示的 Agent 循环往往只需几百行代码，但要让它稳定运行、可审计、可限权，复杂度很快会接近一套小型工作流平台。

模型接口和托管智能体不是同一种产品

**模型推理服务解决的是如何调用模型，托管智能体解决的是如何让任务持续运行。**两者不存在绝对替代关系，选择标准主要取决于团队是否愿意把执行层交给平台。

| 对比维度 | 模型推理服务 | Kimi Hosted Agents | |---|---|---| | 核心定位 | 单次或流式模型推理 | 预构建、可配置的智能体运行平台 | | 会话历史 | 开发者自行拼接、存储和回传 | 平台以事件形式持久化，可随时拉取 | | 工具执行 | 开发者解析调用并执行 | 内置工具在云沙箱运行，自定义工具可由客户端执行 | | 沙箱环境 | 团队自行准备 | 平台提供隔离云沙箱，企业认证用户还可选择自托管环境 | | 长任务恢复 | 自行保存检查点和重建状态 | 平台故障后自动接管并恢复 | | 超时与重试 | 自行实现退避、限流和调度 | 由平台执行层承担 | | 控制粒度 | 高，可干预每一轮推理 | 较低，主要通过配置、技能与工具边界控制 | | 适合场景 | 自研框架、强定制流程、实时链路 | 长程研究、异步任务、多智能体协作 |

**Hosted Agents 最有价值的场景不是聊天机器人，而是异步、长时间和多步骤任务。**例如，投研助手需要搜索多类资料、读取企业数据库、运行计算脚本、生成图表并整理报告；运维智能体则可能持续监控告警，在满足条件时查询日志、定位问题并通知值班人员。这些任务的难点都不在第一轮回答，而在数十次工具调用后仍然保持状态一致。

**简单客服和固定流程并不一定需要托管 Harness。**如果业务只做知识库问答、分类或字段抽取，传统模型调用加一层轻量工作流通常成本更低、延迟也更容易预测。Hosted Agents 的优势要在任务足够长、工具足够多、失败恢复足够重要时才会真正显现。

140多个Skills和30多个插件降低了接工具的成本

**Skill 是由提示词、脚本、模板和领域经验组成的可复用能力包。**Kimi Hosted Agents 目前提供 140 多个 Skills 和 30 多个插件，覆盖联网检索、专业数据查询、办公文档处理及内容生成等任务。

**现成工具库减少的是重复集成，而不是业务建模工作。**开发者不必为搜索、文件读写、代码执行等通用能力分别搭建工具，但仍要定义任务边界、输入输出标准、失败条件和人工接管机制。企业也可以接入自有工具、私有数据库、内部业务系统以及 MCP 服务。

**MCP 是一种让模型应用以统一方式连接外部工具和数据源的协议。**Hosted Agents 支持 MCP，意味着企业已有的工具服务不必全部重写成 Kimi 专属形式，但协议统一并不等于权限天然安全，工具侧仍需执行身份验证、参数校验和最小权限控制。

Kimi 同步提供了首批 8 个金融 Agent 模板，覆盖投研建模、深度研究等工作。模板的实际价值主要在于展示任务拆解、技能组合和工具连接方式，而不是交付一个开箱即用的金融分析师；金融数据的授权范围、时效性、引用来源与结论复核仍然需要企业自己负责。

安全设计比工具数量更值得关注

**独立沙箱是将Agent代码、文件和命令限制在隔离执行环境中的安全机制。**Kimi Hosted Agents 为任务提供独立沙箱和网络访问权限控制，企业能够设定 Agent 可访问的资源范围，并在异常情况下中止会话。

**执行留痕让Agent从黑盒操作变成可追溯流程。**平台保存任务执行过程并支持审计导出，企业可以回看模型何时调用了什么工具、工具返回了什么结果，以及任务在哪一步发生偏差。对于金融、运维和企业数据分析场景，这项能力比回答看起来是否聪明更重要。

**Kimi Inference Hook 是在每次模型推理前执行企业安全检查的独立组件。**它可以把任务输入和工具返回内容送往企业自建或采购的安全服务，由企业规则决定放行或拒绝，只有通过检查的内容才会进入后续模型推理。

Kimi Inference Hook 的设计思路是把敏感信息拦截点放在模型之前，而不是等模型生成结果后再补救。企业可以用它识别个人信息、商业秘密、受限文件内容或不允许外发的数据字段，这对接入内部数据库的 Agent 尤其关键。

**推理前检查不能覆盖Agent的全部安全风险。**工具调用参数是否越权、外部网页是否包含提示注入、生成文件是否携带敏感信息，以及自定义工具本身是否可信，仍需要额外防护。Inference Hook 是一道重要闸门，但不能替代工具权限、网络隔离和输出审查。

计费从Token扩展到整个任务运行过程

**Kimi Hosted Agents 采用按量计费，费用由模型 Token、沙箱运行时长和插件调用次数三部分构成。**这种计费结构比单纯按模型 Token 更接近真实 Agent 成本，因为长任务即使没有持续生成文本，也可能占用执行环境并频繁访问外部工具。

| 成本项目 | 主要影响因素 | 常见优化方向 | |---|---|---| | 模型 Token | 上下文长度、推理轮数、工具返回内容 | 压缩历史、裁剪工具结果、按任务选择模型 | | 沙箱运行时长 | 代码执行时间、任务等待时间、并发数量 | 设置超时、拆分任务、及时释放空闲会话 | | 插件调用次数 | 搜索轮数、数据查询频率、失败重试 | 缓存结果、合并查询、限制无效循环 |

**官方目前披露的是计费维度，而不是参考资料中可核验的完整单价表。**因此，企业在评估成本时不能只拿模型 Token 价格乘以请求量，还应通过真实任务压测，统计平均运行时长、工具调用次数、失败重试率和并发峰值。

**用量报表能解决项目归因问题，但不能自动阻止成本失控。**长程 Agent 最常见的风险之一是陷入搜索、修改、验证的循环，连续消耗模型和沙箱资源。生产环境仍应为单会话设置预算上限、最大步骤数、最长运行时间与人工审批节点。

迁移的本质是删掉自建循环，但保留业务定义

**从自建Agent迁移到Hosted Agents，本质上是把怎么运行交给平台，把做什么留给企业。**原有系统提示词会变成 Agent 配置，自定义业务工具仍可由客户端执行，搜索、文件操作和命令运行等通用工具则可以交给云沙箱。

**会话和Agent配置被拆成了两个生命周期。**Agent 配置可以持续复用，并通过版本机制更新；每次实际任务则运行在独立会话中，历史以事件方式保存。这个设计比把提示词、消息列表和工具状态混在一个请求循环里更适合生产管理。

**事件流断线续读是长任务可靠性的关键细节。**客户端重新连接后可以从上次事件位置继续获取进度，而不是因为浏览器刷新或网络波动就丢失整个任务。平台还负责执行层重试、调度和上下文压缩，客户端主要处理自身业务请求与界面状态。

**自定义工具仍然是企业必须维护的边界。**Kimi 可以托管内置工具的执行，但访问订单系统、客户数据或内部审批流的业务工具通常仍掌握在企业手中。这样的分工是合理的：平台负责通用运行时，企业保留核心数据和业务操作权。

Kimi卖的不是更聪明的模型，而是更省事的生产环境

**Kimi Hosted Agents 的竞争力取决于可靠任务时长，而不只是模型跑分。**企业不会因为一次演示成功就把运维、投研或客服流程交给 Agent，它们更关心任务运行一小时后能否恢复、每一步是否可查、失败成本是否可控。

**这项产品更新对中小团队尤其有吸引力。**没有专门平台工程团队的公司，很难长期维护沙箱、状态机、事件流、调度系统和审计链路；直接采用托管方案，能够把原型到上线之间的基础设施缺口压缩到配置与集成工作。

**大型企业则需要权衡效率与平台绑定。**Agent配置、事件历史、技能体系和沙箱行为一旦深度依赖某个平台，后续迁移成本会高于更换一个模型接口。企业应尽量保持自定义工具协议、业务数据层和评估体系独立，并验证关键会话与审计数据是否能够完整导出。

**Kimi Hosted Agents 目前更像一套有明确边界的Agent PaaS，而不是万能智能员工。**它解决了运行框架的重复建设，也给出了沙箱、审计和推理前检查等企业能力，但任务准确率、工具可靠性、权限治理与最终业务责任仍不会因为托管而消失。

Kimi 这次真正押注的是一个正在形成的行业判断：当模型能力逐渐接近时，Agent 产品的差距将更多来自 Harness。谁能让智能体运行得更久、恢复得更稳、成本更透明、安全边界更清晰，谁才更可能进入企业的真实工作流。

参考来源

• IT之家：Kimi Hosted Agents 托管智能体发布，将 Harness 作为云端服务提供——报道产品发布时间、托管能力、Skills与插件数量，以及Kimi Inference Hook等核心信息。