11 月 5 日，月之暗面发布 Kimi Hosted Agents（托管智能体），把支撑 Agent 运行的 Harness 作为云端服务对外提供。官方说法很直白：企业不用自己搭运行框架，就能拿到 7×24 小时的托管环境，支持长程任务和多智能体协作。
这条消息在技术圈的反响不算大，但在做企业 Agent 的团队里应该算个信号。原因不在模型，在计价方式：沙箱运行时长按小时收费，插件按次收费，模型推理按 token 收费。这三样分开列，意味着 Agent 的”运行环境”第一次被单独标了价。
事实梳理：Harness 从自建变成按小时租
先说清楚发了什么，再说为什么值得看。
产品定位是 Harness as a Service。核心是一套叫 Kimi Durable Harness 的运行时，官方列的能力包括：可定制的 Agent Loop、长程执行（事件溯源、断点续跑）、多 Agent 协调（coordinator / agent team 等编排范式）、会话与上下文管理、技能与插件体系、项目级权限治理、记忆与环境共享。
配套给的东西也挺实在：140 多项 Skills、30 多款插件，覆盖联网检索、专业数据查询、办公文档处理和内容生成；插件库里能看到万得、同花顺 iFinD、东方财富、恒生聚源、标普全球市场财智、SEC EDGAR、财联社、财新、天眼查、元典法律这些数据源。使用方式有三种：网页控制台、命令行工具、API。
时间线上有个细节值得注意：这套服务今年 9 月就开了 Beta，当时只面向国内企业认证用户，11 月 5 日是正式发布。也就是说，它的定价和能力清单是被真实企业客户磨过一轮才拿出来的，不是纯 PPT 产品。
安全侧给了四样：独立沙箱、网络访问权限控制（可设操作边界、可随时中止会话）、执行过程留痕可查并支持审计导出、清晰的计费规则与用量报表。另外有一个独立组件 Kimi Inference Hook，在每次模型推理前检查任务输入和工具返回内容，按企业自定义规则放行或拦截，官方明确说平台不额外留存提示与响应内容，只记录裁决结果、时间戳这类元数据。
背景补一句：10 月 24 日发布的 Kimi K3.1 Pro 是 3 万亿级 MoE、100 万上下文，同步有 Highspeed 版（速度提升 2 到 3 倍），API 定价 13 元 / 68 元每百万 token，缓存命中 1.3 元。Hosted Agents 就是架在这个基座上的。
定价拆开看：三块成本，最贵的那块不在模型上
官方定价公式是：总费用 = 沙箱运行时长 × 0.072 元/小时 + 模型推理费用 + 插件调用次数 × 单价。
三个数先摆出来。沙箱是 1 核 CPU、1GB 内存规格，0.072 元/小时，最小按秒计费；一个云沙箱连续开 30 天，费用约 51.84 元。插件调用单价从每次 0.001 元到 0.45 元不等，其中联网搜索 0.03 元/次、搜图 0.045 元/次、天眼查相关插件 0.02 元/次，部分金融数据插件 0.35 元或 0.45 元/次。
把这三个数放在一起，结论有点反直觉：沙箱是最便宜的一块，插件才是变量。
算一笔具体的账。假设一个投研建模任务，跑 8 小时沙箱，沙箱成本 0.58 元；过程中调了 200 次工具，其中 50 次是金融数据插件按 0.45 元、150 次是联网搜索按 0.03 元，插件成本是 22.5 + 4.5 = 27 元。模型推理按 20 万输入、3 万输出估，输入 2.6 元、输出 2.04 元，合计 4.6 元。总成本约 32 元，其中沙箱占 1.8%，插件占 84%。
这个结构决定了两件事。第一，想省钱不该去压运行时长，应该去压无效工具调用——重试、参数写错导致的重复查询、同一个数据源反复取同一批数，这些才是钱袋子上的洞。第二，工具调用次数必须进预算表，而且要和任务成功率一起看；单看调用次数会逼着团队把重试关掉，最后省钱省出事故。
0.072 元/小时这个数还有个隐含意义：它给”自建 Harness”标了价。企业自建一套可靠的 Harness 通常要几个月，加上持续的运维和升级投入。托管版把这块换成了按小时租，一个沙箱开满一个月五十块钱——单看这个数字，很难论证自建划算。真正的权衡不在钱上，在下面要说的三条边界。
成本这块的通用算法可以看成本怎么算怎么省，那篇讲的是 token 和工具调用的口径，配上本文的沙箱与插件单价格式，基本能拼出一张完整的单位经济模型。
能力清单：对照自建，真正值钱的是五项
官方给了一张自建 vs 托管的对照表，五项。我把它翻译成人话，顺便说说每项实际值多少钱。
会话历史。自建做法是自己拼接、存储、回传消息；托管做法是平台以事件形式持久化完整历史，随时可拉取。这一项的价值不在存储，在”事件化”——事件流才能做重放和审计，消息数组只能做上下文拼接。这块我们在AgentOps 可观测性里讲过，事件轨迹是能不能复盘的分水岭。
工具执行。内置工具由平台在云沙箱里跑，自定义工具仍由你的客户端执行。这条边界要说清楚：不是所有工具都托管了，接内部系统的那些还得你自己扛，网络打通、凭证管理、超时处理一样都跑不掉。
沙箱。自建要自己准备运行命令、读写文件的环境、依赖和网络策略；托管给的是隔离沙箱，可按需配网络与依赖。这块的技术难点其实是冷启动和依赖复现，自己搞过的人都懂。Agent 沙箱要隔离哪四样东西那篇是这块的入门。
失败恢复。自建要自己处理崩溃、断线后的状态重建；托管是平台故障后自动接管并恢复执行，保证行为与中断前一致。这是长程任务能不能跑过夜的关键，也是自建 Harness 最难做对的一块——长时任务怎么设计里讲的检查点和状态恢复，落实起来就是这一项。
超时重试。自建要自己实现重试与限流退避；托管由平台在执行层承担。听起来最不起眼，实际最容易出问题：重试策略写错，一次任务能把配额打空。
五项里，会话历史事件化、失败恢复、超时重试这三项是最难自建的，也正好是Agent = Model + Harness那个框架里最容易被低估的部分。沙箱和工具执行反而是相对成熟、有现成方案的两项。
模板与客户：为什么第一批全是金融
首批 8 个官方 Agent 模板，全部是金融场景：投研建模（输入 ticker 输出三表 + DCF + 可比的 Excel 模型，公式驱动、可追踪）、深度研究（研究报告 + 投研 PPT 长链路交付）、晨报生成（定时任务，盘前生成持仓早报）、港股 IPO 扫描（定时扫港交所 Filing，输出 A/H 对标）、持仓监控与组合复盘（上传持仓文件，首次全量、后续增量）、监管判例日报（定时抓监管处罚公示，滚动统计处罚事由与罚没规模）、基金对账（总账与子账逐条比对，差异附行号分录号，只诊断不记账）。
选金融打头阵是有道理的：任务长、材料多、单次价值高、对错误容忍度低、而且天然有付费能力。更关键的是，金融任务的”可验证性”最好——对账对不对、模型勾稽平不平，机器能判，人也能一眼看出。这类场景最适合证明托管 Harness 到底行不行。
公开的两个客户是顺丰同城和中信建投证券。中信建投那边的说法值得抄：他们先自建了一套主客观结合的评测体系，围绕金融真实任务评了多家模型的端到端交付能力，然后才谈接入；接入时还配了风险评估网关，管数据边界、工具调用和过程留痕。这个顺序是对的——先有验收标准，再谈平台选型。
三个边界：不开源、只认证用户、数据出域
第一，不开源。140 多项 Skills、插件库和 Harness 调度框架都不开源，只能通过云端 API 调用；能自定义新增 Skill、对接自有接口，但源码拿不到，也没法整体搬到私有环境。想私有化只有一条路：等 K3.1 Pro 权重开放，自己基于开源生态重搭工具调用体系。这条路可行，代价是研发投入回到自建原点。
第二，Inference Hook 只对企业认证用户定向开放。这个组件是整套东西里最像”合规入场券”的部分：它在推理前检查输入和工具返回，规则由企业定义，放行还是拦截由它执行。但定向开放这个做法说明它现在是商务谈判的一部分，不是标准能力。要拿它过合规评审的，先谈商务。
第三，数据出域。沙箱在 Kimi 云端，企业内部数据要进去。官方说平台不额外留存提示与响应内容，但这和”数据不出企业网络”是两件事。强监管行业接入前，这项要过法务和信息安全两道门，别等上线前一周才发现过不去。
老达点评
一、0.072 元/小时不是价格，是锚。它锚定的不是沙箱成本，是”你不用再养一套 Harness”。这个数字低到几乎可以忽略，作用是让采购在对比时把自建方案的隐性成本摆到台面上——几个月的研发、持续的运维、每次模型升级后的适配。真正的价格谈判发生在插件单价和模型 token 上。
二、插件按次收费，是这门生意里最有想象力也最危险的一环。有想象力是因为它跟着业务量走，用得越多收得越多；危险是因为它把成本从”固定投入”变成了”随任务波动”，财务最怕这种。0.45 元一次的金融数据插件，一个任务调 500 次就是 225 元，比模型费高一个量级。企业接入前必须先量清楚自己的调用结构，否则第一个月账单会很难看。
三、Harness 云化是必然，但”托管”和”可控”永远拉扯。Harness 这东西本来就是脏活：会话管理、断点续跑、限流重试、沙箱隔离，每一项都要踩坑。让专业团队做一层、大家按需租用，效率上是对的。但企业级客户要的从来不只效率，还有”出问题我能自己进去看”的权力。不开源这件事，会在中大型客户那里反复被拿出来谈。
四、Inference Hook 的设计比产品本身更值得学。把安全检查放在”推理前”而不是”输出后”，检查对象是输入和工具返回而不是模型输出，这个位置的选取很讲究——它挡的是数据进模型，不是模型说的话。它还明确说了只记裁决和时间戳、不留存内容，这是在给合规一个可接受的答案。做企业 Agent 的团队可以照抄这个位置。
五、计价口径正在集体从”按 token”往”按任务”挪。前天 Claude 的 message threads 是把上传时间省下来（那篇算过账，只削延迟不省 token），昨天混元 Hy4 把缓存价定到输入价的二十分之一（Co-Design 那篇），今天 Kimi 把沙箱和插件单独列项。三家的动作方向一致：token 越来越不像唯一的计价单位，谁先把”一次任务的真实成本”算清楚，谁在采购桌上就有话语权。
三个能马上用的判断
第一，先量，再判断贵不贵。挑一个你们最常跑的任务，记三个数：沙箱跑了多少小时、工具调了多少次、其中高价插件占几成。这三个数出来，贵不贵一目了然。凭感觉判断”云上一定更贵”或”托管一定更省”，两种都会错。
第二，自建 Harness 的团队，重点抄那五项。不用抄产品，抄结构：会话历史做成事件流而不是消息数组、失败恢复要有断点续跑而不是从头重来、超时重试要带退避和上限、沙箱网络策略要能按任务配、留痕要能导出成审计能看的格式。这五样做对，自建和托管之间的差距会小很多。
第三，数据边界在写第一行代码前定。哪些数据能进云沙箱、哪些必须留在内网、工具返回的内容要不要过一遍过滤——这三条定不下来，后面所有架构讨论都是白搭。相关的权限设计可以对照Agent 权限管理那篇的最小权限和工具白名单做法。
一句话总结：这次发布的重点不是”又多了个托管平台”，是 Agent 的运行环境第一次有了公开价目表。价目表一出现，所有”我们有自研 Harness”的说法都得重新算一遍账。
