让模型读一份材料，再写个摘要，几行代码就能跑起来。

但如果要求变成“每天九点前读取三处数据，做成报告，遇到数据缺失先等，失败了还能接着跑”，事情就开始复杂了。进程谁守着，文件存在哪，断线后怎么续，已经发过的消息会不会再发一次？

这些活儿不太适合放在模型发布会的大屏上，却是项目上线后每天都要面对的东西。

11 月 5 日 11:15，IT之家报道 Kimi 宣布推出 Hosted Agents，将支撑 Agent 运行的 Harness 作为云端服务提供。[1] 这里先补一个时间细节：Kimi 官方更新日志在 2026 年 9 月已经记录了 Hosted Agents Beta。本轮追踪的是今天的产品发布报道与当前能力说明，不是声称托管智能体今天才第一次出现。[2]

我觉得这条新闻有意思，就在于它把“能调用模型”和“能持续交付任务”之间那一大段工作，单独拿出来卖了。

接通 API 之后，谁负责剩下的事情？

模型推理 API 主要处理输入与输出。你发送消息，它返回文本或工具调用意图。至于工具在哪里执行、结果怎么持久化、断线之后能不能恢复，通常要由外面的应用处理。

Harness 可以理解为让 Agent 真正跑起来的那套执行与管理框架。不是一个更复杂的提示词，也不是简单把聊天页面挂在云端。

按 Kimi 当前官方文档，托管服务涉及会话历史、沙箱、执行层重试、恢复和多智能体协作。内置工具在平台沙箱中执行，自定义工具仍由你的客户端执行。这个边界值得读两遍：托管不等于你接入的每个内部系统都从此有人替你维护。[3]

图 1：Kimi 官方原图，来自 Hosted Agents 产品概览，保留原有标识与完整内容。图中区分平台服务、Harness 核心和企业能力；自定义工具执行位置与企业能力的开放条件，以同页正文说明为准，不把架构图理解为全自动交付保证。

拿每日经营简报举例，模型可以帮你理解异常趋势，但营业数据是否已经同步完成，要由取数系统确认；消息要发给谁，要由身份和权限配置决定；同一天的报告有没有发过，要有可靠记录。

如果这些规则都只写在提示词里，程序重启一次，模型未必知道之前发生了什么。持续工作的能力来自完整运行环境，不是来自一段特别长的“你是一位优秀助手”。

每小时 0.072 元，只是账单的一部分

官方定价页给出的公式是：沙箱运行时长乘以每小时 0.072 元，再加模型推理费用，以及各插件的调用费用。[4]

举个算术例子：假设某个沙箱确实计费运行了 24 小时，那么对应沙箱费用是 1.728 元。这个数字不包括那一天的 token 与插件消耗，也没有说明会话空闲、暂停等各种状态都如何计费。实际计费规则要按平台说明核对。

所以，“一天不到两块钱雇一个 AI 员工”，不是这份价目表能支持的结论。

更合理的核算对象是一份合格产物。生成一份报告花了多少 token，查了几次付费数据，失败重跑了几轮，最后人工花多久修正，这些加起来才接近业务成本。

还有一点经常在试用时被低估：平均费用低，不等于最高费用可控。任务陷入反复搜索、上下文不断增长或工具连续失败时，消耗可能与平时不同。上线之前要有单任务预算、超时策略和停止开关，不能等月底账单出来再研究它为什么那么努力。

技能很多，先别急着全打开

当前官方概览列出 140 多个技能、30 多个插件，以及首批 12 个 Agent 模板。今天的媒体报道重点介绍了其中 8 个金融模板，两种口径并不必然冲突，不能简单把“8 个金融”写成“总共只有 8 个”。[1][3]

图 2：Kimi 产品概览中的“已接入数据源和插件”原图。它展示官方列出的任务和服务范围，不能据此推断每个账户都自动获得所有第三方数据权限，也不表示相关插件全部免费。原图完整保留，仅转为 PNG 方便 CSDN 展示。

预置生态能节省接入时间，这很实际。但每增加一个工具，也增加一组权限、费用、返回格式和故障方式。

我会先选一个只读任务。比如用三份经过授权的内部材料，生成一份带出处的周报草稿。先不发邮件，不改数据库，不自动同步到客户群。把取数、生成、验收跑顺了，再一点点增加动作。

官方还提供独立的 Kimi Inference Hook，可在推理前对接企业安全检查；当前属于企业认证用户定向开放能力。[3] 它有助于在输入与工具返回进入模型前执行企业规则，但不该被当成“从此没有提示词注入或泄露风险”的保证。

安全组件解决的是特定检查位置。能访问哪些系统、能写哪些目录、哪些动作需要批准，依然要靠执行层和权限配置落实。

自托管，也要看究竟托管了哪一层

Kimi 文档还有“自托管环境”选项，让沙箱工具在企业自己的主机上执行；模型调用、编排和会话管理仍由平台负责，且该能力面向企业认证用户。[3]

这对访问内网系统有用，但不是整套系统完全离线的同义词。工具输出里包含什么、哪些内容会进入模型与平台、日志如何保留，都需要具体核查。

判断是否适合自己的团队，我会看三个条件：业务是否允许相应数据流转，现有工具能否接入，以及团队愿意为多少控制权承担运维工作。

如果想快速跑一个长任务，平台托管有吸引力；如果已有成熟的队列、权限、任务状态和监控体系，继续保留自建运行层也合理。没有必要把这道选择题变成“自建落后”或“托管不专业”。

胜算云怎么接？这里是另一条明确的路线

以下为胜算云产品接入示例。 如果团队决定保留自己的任务框架，可以通过胜算云兼容 API 接入账户支持的模型，把取数、状态持久化、审批和发送保留在自己系统中。[5]

这是一条“自建运行层加模型 API”的替代路线，不是声称可以给 Kimi Hosted Agents 任意换成胜算云后端。当前核对的资料没有建立这种兼容关系。

下面只演示报告里的摘要节点。输入是虚构的结构化数据，不连接财务系统，不发送报告，也不实现完整的中断恢复。使用 Python 标准库，先设置 SSY_API_KEY 和账户实际可用的 SSY_MODEL。

import json
import os
import urllib.request

job = {
    "job_id": "demo-weekly-20261105",
    "input_version": "v1",
    "facts": [
        {"source": "demo-table-01", "text": "本周收到 12 条反馈，已核实 8 条"},
        {"source": "demo-table-02", "text": "另有 4 条等待负责人确认"}
    ]
}
payload = {
    "model": os.environ["SSY_MODEL"],
    "messages": [
        {"role": "system", "content": (
            "依据给定事实写一段周报草稿，每项结论标出 source。"
            "把待确认事项单列，不编造已完成的动作，不发送任何消息。"
        )},
        {"role": "user", "content": json.dumps(job, ensure_ascii=False)}
    ],
    "stream": False,
    "max_tokens": 1800
}
request = urllib.request.Request(
    "https://router.shengsuanyun.com/api/v1/chat/completions",
    data=json.dumps(payload, ensure_ascii=False).encode("utf-8"),
    headers={
        "Authorization": "Bearer " + os.environ["SSY_API_KEY"],
        "Content-Type": "application/json"
    },
    method="POST"
)
with urllib.request.urlopen(request, timeout=60) as response:
    result = json.load(response)
choice = result["choices"][0]
if choice.get("finish_reason") != "stop":
    raise RuntimeError("草稿生成未完整结束")
draft = choice["message"].get("content")
if not isinstance(draft, str) or not draft.strip():
    raise ValueError("没有可供验收的草稿")
print(json.dumps({
    "job_id": job["job_id"],
    "input_version": job["input_version"],
    "status": "needs_review",
    "draft": draft,
    "usage": result.get("usage")
}, ensure_ascii=False, indent=2))

接下来要补的工程工作也很明确：将任务状态与输入版本持久化，记录审核人，给发送动作设计去重标识，保存外部系统返回的结果。一个 job_id 字段本身并不提供幂等能力，更不能保证进程重启后自动接着跑。

模型输出只进入 needs_review，不直接进入 published。这种状态分法看起来普通，却比让模型口头保证“我会谨慎”更可靠。实际请求费用以模型账单为准，本文代码只做模拟响应测试，没有发起付费调用。

我更看重托管服务解决的那段麻烦

如果把 Agent 看成一个会回答问题的窗口，托管服务似乎只是多套了一层。把它放进每天必须按时产出、会失败、会重试、会接触业务数据的环境里，维护这层运行框架就不再是小事。

我看好这种产品化方向，但不会按技能数量选购，也不会按沙箱最低单价算回报。

真正值得试的，是让它完成一个原本需要有人盯着的小任务，然后故意中断一次、给一份缺数据的输入、触发一次工具失败。看看它留下什么记录，恢复后做了什么，最终产物还能不能验收。

一次顺利演示只能说明能跑。出了问题仍然知道该怎么收拾，才接近能长期用。

---

来源与说明

1. IT之家：Kimi Hosted Agents 托管智能体发布，北京时间 2026-11-05 11:15；AIHOT 收录。
2. Kimi 平台更新日志，2026 年 9 月已有 Hosted Agents Beta 记录。
3. Kimi Hosted Agents 产品概览，用于核对职责、技能模板、Inference Hook 与自托管边界。
4. Kimi 托管智能体定价，沙箱、模型、插件分项计费，后续以官方最新定价为准。
5. 胜算云 OpenAI 兼容 API 文档；API Key 控制台。

本文为产品资料分析，不是两家服务的实测对比。两张配图均来自 Kimi 官方文档，权利归原作者；API 示例不实现图中完整托管 Agent，也不宣称可以替换 Kimi 的模型后端。

CSDN 标签： Kimi、智能体、云计算、API、胜算云