11 月 5 日，月之暗面发布 Kimi Hosted Agents（托管智能体），把支撑 Agent 运行的 Harness 框架做成云端服务：企业不用自己搭运行框架，就能获得 7×24 小时的托管环境，支持长程任务执行与多智能体协作（官方发布）。
这不是又一个智能体应用，而是把智能体项目里最不显眼、也最容易拖工期的那一层——运行底座——拿出去托管。
被托管的具体是什么
官方给出的两类用法很具体：一类面向内部业务，接进企业系统做业务监控、运维响应；一类嵌进对外产品，做 App 内的投研助手、客服助手。企业按需配置 Agent，可接入自有工具和数据源；平台侧提供 140+ Skills 与 30+ 插件，覆盖联网检索、专业数据查询、办公文档处理和内容生成。
可控性方面，官方列出的是独立沙箱、网络访问权限控制、随时中止会话、执行过程留痕可查并支持审计导出，以及清晰的计费规则与用量报表。另有一个独立安全组件 Kimi Inference Hook，在每次模型推理前检查任务输入与工具返回内容，放行或拒绝的规则由企业定义；该组件目前只对企业认证用户定向开放。
按官方说法，企业要让 Agent 上生产，通常需要几个月搭一套可靠的 Harness：代码执行环境、上下文与会话管理、工具调用、权限控制、任务中断恢复，上线后还要持续维护。这个"几个月"是厂商表述，具体项目差别很大，但方向不难理解：这部分工作重复度高、与业务差异无关，却直接决定 Agent 能不能长时间稳定运行。
对定制项目的影响：报价单要改
过去接一个智能体项目，交付清单里往往默认包含"自建运行平台"。需求评审时它只是几行字，真做起来却是沙箱隔离、会话持久化、工具鉴权、失败重试、日志审计一整摊，工期和人力很容易被低估。
底座被托管后，这部分从"必须自己做"变成"可以买"。定制方的报价结构需要跟着调整：不再按"搭一套平台"报固定人天，而是把工作拆成业务梳理、工具与数据接入、权限与审计设计、上线后运营四块。继续按老口径报价，要么贵得没有竞争力，要么把平台能力当白工送出去。
同时也要克制：托管省掉的是通用运行层，不是项目里所有基础设施。与企业已有系统（ERP、CRM、工单、数据仓库）的对接、数据口径统一、异常处理流程，仍然要逐项完成。把"用了托管平台"当成缩短全部工期的理由，最后会在联调阶段还回来。
托管解决"跑得稳"，不解决"跑得对"
平台给的是能力开关：沙箱、网络权限、会话中止、审计导出。但"Agent 在什么条件下可以改动哪张单据""查到敏感字段要不要拦住""任务失败几次后转人工"，这些规则平台不会替企业定义。
官方把安全规则的设计权交给企业、只负责执行，这个分工是合理的，也意味着项目里必须有人真正把边界写清楚。对做定制和 AI 落地的团队来说，这块反而是更难被替代的价值：懂业务规则、能把权限和审计落到具体流程上，比会调接口稀缺得多。
另一个容易被忽略的是成本治理。托管环境按用量计费，Token 与运行时长的消耗会随任务复杂度上升。用量报表只有被拿来做预算上限、按项目分摊和异常告警，才算真的用上；否则常见的结果是验证阶段效果不错，上线三个月后发现账单比预期高出一截，却说不清花在哪个环节（平台更新记录）。
三个需要提前问清的问题
一是能力边界。该服务仍处于 Beta 阶段，功能、配额和计费口径都可能调整，关键业务流程上线前要按实际文档核对，不按发布会描述做容量规划。
二是数据与退出。会话记录、工具调用日志、执行留痕都产生在平台侧。合作前应约定导出格式、保留周期和停用后的数据处置方式，避免迁移时发现历史记录带不走。
三是单一依赖。把运行底座交给一家平台，换来的是开发速度，付出的是议价空间。核心业务链路保留可替换的接入层，比事后重构便宜。
一句话
智能体的竞争，正在从"谁的模型更强"下沉到"谁的运行底座更省事"。对软件定制和企业数字化团队来说，这不是坏消息：一层通用能力被商品化，意味着真正决定项目成败的部分——业务理解、流程设计、权限与审计——变得更值钱，也更该被单独计价。