11月5日，月之暗面发布Kimi Hosted Agents，把这套东西的定位说得直白：把支撑智能体运行的Harness作为云服务提供。企业不必自己搭运行框架、不必自己维护调度与升级，直接拿到一个7×24小时的托管环境，用来跑长程任务与多智能体协作。配套的治理能力也一并给到：独立沙箱、网络访问权限控制、随时中止会话、执行过程留痕与审计导出，以及按项目看用量与费用的报表。
过去一年，智能体的能力提升主要发生在模型里，但真正决定它能不能进企业系统的，是模型外面那层框架。任务怎么切分、上下文怎么在多个步骤之间传递、工具调用失败后重试几次、什么时候该停下来问人、多个智能体改了同一份文件怎么办，这些问题没有标准答案，每家团队都得自己趟一遍。趟出来的东西不在文档里，而在几个人的脑子里和一堆没写注释的脚本里。
把这层做成托管服务，等于把这部分工程经验产品化。客户要做的事被压缩成两件：定义任务、接入工具。底层运行环境的维护与升级由服务方负责，团队不必反复做基础设施适配。对多数企业来说，这个交换是划算的，因为运行框架不构成差异化，业务里的规则才构成。但也正因为如此，一旦把这一层交出去，后续换供应商的成本会变高，因为流程与权限都长在别人的接口上。
企业最担心的三件事，托管模式给出的答案各不相同。第一件是越权：沙箱与网络访问权限控制解决的是"它能碰到什么"，企业自己划边界，必要时可以中止会话。这一条比模型层面的安全对齐更实际，因为企业真正介意的往往不是模型说了什么，而是它动了什么。
第二件是追责：执行过程留痕、支持审计导出，意味着每一次工具调用、每一次文件改动都能被回溯。这在金融与运维场景里是硬要求，出问题时要能回答"哪一步开始偏的"。第三件是钱：清晰的计费规则与用量报表，让每个智能体项目的资源消耗可以被看见。这三件事凑齐了，采购流程才走得下去，因为法务、安全、财务三个部门各有各的问题要问。
值得注意的是，托管并不等于免责。审计日志能证明发生了什么，但证明不了这些动作是否被授权；沙箱能限制范围，但限制不了任务本身设计得对不对。企业把框架交出去之后，仍然要自己回答一个问题：这个智能体被允许代表公司做哪些决定。这个问题没有技术服务能代答。
官方给出的落地路径分两类。一类面向内部，把智能体接进企业自有系统，做业务监控、运维响应这类活。这类应用的特点是错误可回滚、影响范围可控，考核指标是响应时间与人工介入率。另一类面向产品用户，嵌进对外产品里，做投研助手、客服助手。这类应用一旦出错，代价直接落在用户体验与合规上，考核指标变成答案准确率与兜底话术的覆盖率。
两类应用共用一套托管环境，但内部团队很快会发现，它们的运维节奏完全不同。内部应用可以容忍每周迭代一次，对外应用需要随时能回滚；内部应用的权限模型相对简单，对外应用要处理多租户隔离与数据边界。托管服务能提供的是能力与工具，配置这些策略的仍然是人。还有一处容易被低估的差别在测试环节：内部应用的验收往往能在灰度环境里跑通，对外应用的每一条回答都会被真实用户看到，测试用例只能覆盖已知问题，覆盖不了用户随机想到的问法。
把运行框架做成标准品，会带来一个可预期的结果：这一层的利润空间被压薄，差异化往两头跑。一头往模型跑，模型在长程任务上更少走弯路的一方，托管环境就更省钱；另一头往场景跑，更懂某个行业流程与合规要求的团队，方案就更难被替换。中间的通用托管层，最终大概率会变成按调用量计价的公共设施。
对国内厂商来说，这条路还有一个本地化的机会：企业内部系统大多不是标准SaaS，而是自己长出来的老系统，接口不规范、权限模型各异。能不能把这些系统接进来，决定了托管服务在真实企业里的完成度。这件事很难靠文档解决，只能一家一家对接。做得下来的一方，手里会攒下一批别人拿不到的适配经验，这些经验反过来又变成了迁移壁垒。反过来说，接入做得粗糙的一方，客户在第一个月就会发现问题，而这类问题一旦暴露，续约基本无望。
第一件是长程任务的实际完成率。托管环境能保证跑得久，但跑得久不等于跑得对，一个需要几十步的任务在第十几步偏了方向，后面全是无效消耗。第二件是多智能体协作的冲突处理，两个智能体同时改一份配置时，是先合哪一支、后合哪一支、测试按哪一套跑，这类规则目前还没有行业共识。第三件是退出成本，当企业的流程、权限、审计记录都长在托管平台上之后，迁移一次要付多少代价，这个问题在签约时往往没人问，在续约时一定有人问。
对采购方来说，现在比较稳妥的做法是把托管层当成可替换件来设计：业务逻辑与规则留在自己手里，运行框架保持可切换，关键流程的日志自己留一份。这样做短期会多花一点集成成本，但它把选择的自由留到了下一次谈判桌上。智能体进企业才刚开始，把全部身家押在一家平台上，风险不成比例。