Agents API托管智能体循环：省掉编排，也交出一层控制权
创作者经济 2
Kimi把Agent Harness搬上云，长任务可全天候运行
月之暗面旗下Kimi在2026年11月5日的发布稿中正式推出Kimi Hosted Agents，把支撑智能体运行的Agent Harness作为云端服务提供给企业和开发者：托管环境支持7×24小时运行、长程任务和多智能体协作，首批配有140多项技能、30多款插件及8个金融Agent模板。企业可以通过Kimi开放平台使用该服务；平台提供独立沙箱、网络访问控制、会话中止、执行留痕和审计导出。
这次发布意味着小团队可以把会话保存、内置工具执行和故障恢复交给平台维护，同时保留对任务、数据和权限的业务决策。Unite.AI的发布报道指出，服务曾在2026年9月面向国内企业认证用户开放测试，11月5日是正式推出；报道还说明，内置工具在云端沙箱执行，自定义工具仍可由客户的客户端执行。
会话和故障恢复交给云端后，团队少维护什么
Agent Harness是让智能体在多轮模型调用之间保持工作状态的运行框架。自行搭建时，团队不仅要发送提示词，还要保存历史、接收工具调用、执行工具、回填结果，并在任务中断时找回进度。长任务越依赖文件、代码和外部数据，这些环节之间的衔接越需要持续维护。
- 会话历史由平台按事件保存。应用断线后，已有任务不必依靠客户端临时保存的消息列表来重建。
- 内置工具由平台安排在隔离的云沙箱中执行。团队可以把精力放在任务所需的数据源和自定义工具上，但自定义工具运行在客户客户端时，其可用性仍要由客户保障。
- 平台承担执行层的调度、重试及故障后的恢复。业务系统仍要决定失败结果如何处理，以及何时需要人工介入。
这里的“全天候”指托管环境能够持续承接任务，并不等于每个会话都要不间断地调用模型或占用沙箱。一次需要先检索资料、再运行代码、最后生成文件的任务，可以在多个步骤之间保留状态；使用方仍需判断输入是否充分、产物是否达到业务要求。对原本要轮值维护会话服务和执行环境的团队，这减少的是运行框架的工程工作，而非结果复核。
模板能缩短接入起点，业务材料仍要自己提供
Kimi把应用位置分为企业内部系统和面向产品用户的功能。前者包括业务监控、运维响应，后者包括应用内投研助手和客服助手。两类应用都需要把智能体的进度、工具调用和最终产物接回既有流程；托管环境负责运行，企业负责定义流程中的数据来源和交付标准。
首批金融模板覆盖投研建模、深度研究、晨报生成、IPO跟踪和持仓监控等任务。团队可以复制模板，再连接自己的内部研报、私有数据库或业务工具。模板提供的是任务结构和配置起点：企业掌握的材料、数据授权、指标口径以及谁来复核输出，仍须在自己的业务系统中确定。
这一区别在长程分析中很实际。智能体可以分步取数、计算并生成表格或报告，但内部研报不会因为选用了模板就自动进入任务，缺少授权的数据也不会由托管平台补齐。多智能体协作能把研究、计算等子任务分开执行；如果各子任务采用不同数据口径，最终仍需业务方核对。云端提供连续运行的条件，任务定义的质量决定产物是否可用。
网络权限、审计和终止会话仍有企业边界
独立沙箱隔开执行环境，网络访问控制决定它能连接哪些外部地址。企业需要把可访问的数据源、可调用的工具和允许的操作写进任务配置，而不能把“有沙箱”理解为权限已经合适。接入内部数据库时，数据授权和凭据管理尤其关键：平台可以执行已获准的操作，授权范围却只能由数据持有方确定。
会话可以中止，执行过程也可以留痕并导出审计记录。这使团队有机会回看智能体调用了什么、在哪一步取得数据以及产物如何形成；它不能代替运行前的权限设置，也不能证明自动生成的结论正确。需要处理敏感输入的企业还可关注Kimi Inference Hook：它能在模型推理前接入企业定义的检查规则，但目前仅向企业认证用户定向开放。
这些控制对应不同时间点。网络权限限制运行中能够接触的资源；中止会话用于阻断正在进行的操作；审计记录用于事后追溯。把三者放进同一业务流程，使用方才能明确谁有权启动任务、什么情况必须停下，以及哪些输出需要人工确认。平台提供控制手段，具体边界由企业设置。
云端托管、自建Harness和自托管沙箱是不同选择
直接调用模型推理接口并自建Harness，适合需要自行决定会话存储、工具调度和恢复机制的团队，代价是持续维护这些组件。使用Kimi Hosted Agents，团队主要定义智能体、接入工具和配置权限，由Kimi维护底层运行环境。两者的关键差别在于谁负责长期运行框架，而不是任务能否调用同一类模型。
还有介于两者之间的执行位置：企业认证用户可以使用自托管环境，把沙箱工具放到自己管理的主机上运行。此时模型调用、智能体编排和会话管理仍由Kimi平台负责；工具输入和执行结果仍可能经过平台的推理接口。因此，团队若需要在自有网络内运行代码或访问内网服务，仍须区分“沙箱在自有主机”和“整套服务在自有主机”。
对小团队而言，决策可以落到具体任务上：如果主要障碍是维护会话、沙箱和恢复服务，云端托管覆盖了最费工程时间的部分；如果障碍是代码必须在自有环境执行，自托管沙箱改变的是工具执行位置；如果连会话与编排也必须自行控制，就需要评估自建Harness。无论采用哪种方式，数据授权、输出复核和业务责任都留在使用方。
费用要按任务算，沙箱单价只是其中一项
Kimi的金融建模成本说明给出云沙箱每小时¥0.072的单价，并以耗时45—90分钟的建模任务估算一次完整运行约¥30—50，后者不含付费插件费用。该案例的主要支出来自模型Token；材料规模、调用轮次和返工都会改变实际账单。这是特定建模配置的估算，不能当作所有托管任务的固定报价。
按2026年11月9日可见的上述沙箱单价，下面是仅计算沙箱时长的条件示例，均未计入模型Token、插件和人工复核：
- 一个任务累计使用沙箱1小时，沙箱费用按单价计算为¥0.072。
- 每个工作日运行一个耗时90分钟的任务，累计20个工作日即30小时，沙箱费用为¥2.16。
- 若某项任务确实连续占用沙箱24小时，沙箱费用为¥1.728；托管环境全天可用，并不意味着所有任务都会产生这笔费用。
这些金额展示了沙箱时长与完整任务成本的差距。模型推理按实际Token消耗计费，付费插件按调用计费，企业还要承担接入和复核成本。Kimi已公布计费组成和沙箱单价，但不同任务没有统一的总价；部署后的用量报表与实际账单，才会给团队提供可用于比较自建维护成本的数字。
相关阅读：
相关文章
订阅我们的新闻通讯
将最新 Web3、AI 和加密货币新闻直接发送到您的邮箱。
0