10月24日，月之暗面发布Kimi K3.1 Pro，开放网站、Work、Code及API入口；完整权重预告在11月4日前放出。发布材料最容易被记住的是100万Token上下文和“3T-class”模型，真正影响研发团队选型的却是另一个问题：给模型一个跨数日、跨工具的工作，它能否持续找到证据、修正错误并交付可检查的结果？厂商公布的编程、三维建模、财务研究和网络安全实验，为这个问题提供了几组观察窗口，也留下必须由用户自己验证的成本和稳定性空白。[1][2]
先看模型能做什么，再看百万Token值多少钱
官方将K3.1 Pro描述为Kimi K3经过更大规模后训练得到的版本，并表示强化学习覆盖多个下游领域；围绕训练框架、长上下文推理、沙箱和任务调度做了配套调整。[1] 这是训练与系统的组合变化，不能只靠上下文窗口解释。窗口给了模型容纳代码仓、图纸说明或财报附件的空间；答案质量仍取决于它有没有检索到正确片段、是否辨认版本、调用工具后能否读懂反馈，以及剩余预算是否足够复核。
一百万Token尤其容易造成“全放进去就会全用上”的错觉。技术上，上下文上限表示接口可接收的最大序列规模，实际任务还受模型输出空间、接口速率、费用、长文本中的定位能力、工具返回体积和持续调用时的记忆管理影响。把一个产品的全部文档灌入提示词，有时比按仓库目录、变更记录和任务相关性分批检索更难排错。企业想评价长上下文，应该准备跨文档追溯问题：要求模型给出文件名、版本、行号或原始页码，故意把一条旧规则放在新规则附近，检查它引用的是哪一版。这个测试能暴露单纯问答准确率看不出的风险。
所谓“3T-class”也要按厂商原话理解为约三万亿参数量级的系列定位。公开博客没有把可训练总参数、单次激活参数和每Token的实际计算开销逐项披露；采购团队不能据这一称谓估算部署所需GPU数量。权重在10月25日尚未按预告全面发布，自建推理的显存、并行配置和实际延迟还需等权重、许可及社区实测。现在可以试用托管入口，但托管测得的响应速度，不应直接填进自建部署预算。[1][2]
编程成绩要连同“怎么跑的”一起读
月之暗面披露，K3.1 Pro在Terminal-Bench 4.0得分65.7%，在其内部Kimi Code Bench 3.0 Long-horizon得分61.2%；后一项相对于K3的55.95%有所提高。[1] Terminal-Bench面向终端中的实际任务，评测网站提供任务与运行入口；厂商博客脚注说明其K3.1 Pro采用Claude-Code harness，默认基准结果另设高推理强度等参数。[1][3] 同一模型换一个代理框架、工具权限或预算，数值都可能变化。内部基准更适合作为版本迭代线索，尚不能替代其他团队复测。
博客里一项人类步行模拟器的案例很能说明长任务的难点：官方称模型在现有解剖模型上完成167项任务、经过420次独立审查，逐步修正控制器；发现单纯调整奖励函数不能改善手臂动作时，它去检查模拟器动力学，并修正36处肩部肌肉力臂计算错误。[1] 这是厂商展示的案例，不能当作任意工程项目都会有同等成功率的统计证据。但它指出了一个务实的验收点：好的编程代理不能只生成补丁，还要知道实验失败后到底该查参数、数据、物理模型还是验证流程。
研发团队可以用本地真实任务建立自己的测试包。每项任务保存起始仓库提交、用户需求、可用工具、时间和调用预算；输出除了代码，还要有测试日志、运行命令及未解决问题。评分拆成构建成功率、回归测试、需求验收、人工复核成本和每个合格任务的费用。需要跨多个工作日的项目，还应人为中断一次运行，检查恢复后会不会重复改已经完成的文件。得出“能不能用”的结论，比比较不同厂商榜单中的小数点更扎实。
三维和财务案例，恰好暴露两个不同的验收边界
三维内容是此次发布的另一个重心。官方报告K3.1 Pro在BenchCAD借助工具取得92.7%，并展示通过Blender、CAD脚本制作参数化零件、场景与资产的样例。[1] 用模型写脚本生成零件，效率收益来自可编辑、可再生：工程师改孔径、约束和材料后，可以重新运行脚本，比只收到一张渲染图更有用。然而图形漂亮不能替代工程验收。想把结果送去打印或装配，仍要检查封闭实体、干涉、壁厚、装配公差和单位；这些指标不能从宣传视频反推。面向游戏的视觉资产与面向机械制造的实体模型，也不能沿用同一套“看起来不错”的评分。
财务场景则检验事实链条。厂商称K3.1 Pro在OfficeQA Pro v2得到64.4分；内部Financial Modeling、Financial Research等测评也有提升，内部Kimi Hallu Bench Hard的claim-level幻觉率由K3的23.4%降至8.3%。博客特别指出，该基准专挑易错提示做压力测试，数值不代表普通使用时的总体错误率。[1] 企业若据此引入财务研究，应保留引用页码、表格版本、币种、合并口径和计算公式。一个模型能生成漂亮的现金流表，不代表审计人员能追溯其中每个数字的来源。
这里有一个共通要求：交付物必须是“可重新算一遍”的。代码有测试；CAD有尺寸检查；财务研究有原始披露与公式引用。模型是否写得流畅，可以排在这些验收之后。
安全控制实验：9.5个百分点的差距，仍有剩余能力
K3.1 Pro的发布还包含少见的训练侧安全说明。月之暗面称，在中期训练数据和强化学习环境中清理部分网络攻击相关材料，保留通用编程任务。其内部xdev-bench-hard采用源代码漏洞研究与利用任务：在给定漏洞源代码、提示和二进制文件的环境下，智能体尝试完成沙箱中的验证目标。博客报告未做相同清理的训练检查点pass@3为90.5%，最终模型为81.0%，相差9.5个百分点。[1] 这个对照支持“所做调整降低了相对于同训练管线对照组的能力”的厂商判断；81.0%也提示剩余能力不可忽略。数据清理影响幅度、迁移到真实环境后的风险以及第三方复现，目前都不能由单项内部测试直接推出。
网络安全能力与通用代码能力彼此牵连。合法维护者希望模型找出旧库中的漏洞，攻击者也可能利用同样的代码理解与工具使用能力。发布方提出开放权重前降低进攻能力的原则，同时主张让更多防守团队能自行审查其软件。[1] 对企业来说，这意味着模型层“清理训练数据”只是保护链的一环：工具的文件权限、命令范围、出网边界和操作审计仍由部署方负责。尤其在模型权重开放后，服务端的统一拒答策略不一定覆盖所有下游部署场景。
试点网络安全助手，较合适的起点是只读代码仓和隔离沙箱。先让它解释一段已知修复的漏洞为何成立，核查它引用的文件与提交，再判断误报；不要直接授予线上系统写权限，也不要把一次成功定位当成自动修复能力。跟踪指标至少包括漏检、误报、工具调用成本，以及修补版代码能否被正确判为已经不存在该问题。这样的双阶段测试恰与安全评测领域近期的做法相呼应，但不同任务集的成绩不能横向混算。
Highspeed怎么选：先测完整任务的花费
官网介绍，Highspeed版本响应速度约为普通版的2至3倍，两个版本都已在Kimi产品及API提供；API文档列出kimi-k3.1-pro与kimi-k3.1-pro-highspeed标识，并说明不同的接入格式。[1][2] 速度是厂商标称，不保证企业现有代理链、地区网络或特定负载都得到相同提升。更快的逐次输出若诱使代理多走几轮，完整任务的开销未必更低；反过来，交互式开发中的等待时间减少可能十分值钱。
建议把评估单位定为“一件完成且通过验收的工作”，记录从提交到验收的总时长、输入输出Token、工具调用次数和返工次数。在同一批需求上固定提示、仓库状态与工具权限，分别运行两个版本，报告平均值之外也报告最慢那组。对于超长文档，再测不同长度下的回答准确性和引用质量，而不是只测接口能否接受输入。供应商宣称的上下文规模，是要设计实验验证的能力边界，不是交付承诺。
10月25日可以确认的是：官方已开放托管体验，并承诺11月4日前提供完整权重；代码、三维、财务与安全数字主要来自厂商披露。[1] 想部署的团队可先挑十件最常见的真实任务，建立结果、成本、错误原因可回放的台账。等权重实际发布，再补上自建吞吐和治理测试。把这些工作做完，“百万Token”才会从海报上的数字变成可管理的工程能力。
从试用账号到组织部署，先补上四张表
团队采购会议很容易陷进一串榜单。更有效的准备，是先列四张表。第一张是任务表：每行写明业务问题、输入资料所在位置、允许的工具、应交付的文件，以及谁有资格签收。例如“根据近三年的年度报告核对一项指标”与“按最新需求修改支付接口”，都叫长任务，证据边界和风险等级却不同。将任务拆成可以复现的输入，后续才知道一次失败是模型能力问题，还是测试员临时换了要求。
第二张是数据表：输入里有没有个人信息、客户源代码、尚未公开的财务资料或第三方授权限制？供应商文档提到API客户可选择Zero Data Retention服务，也介绍企业组织的账户隔离能力。[1] 采购时仍须核对实际合同、地域、日志保留与管理员权限；文档上“支持”某种选项，并不表示你已购买或启用该选项。对于不能外传的仓库，先做脱敏样本；如选择自建，待权重与许可到手之后再计算隔离、监控和更新的完整成本。
第三张是失败表。把错误按资料没读到、读到却误解、工具命令错误、数值计算错误、证据断链、运行中断和越权请求分开统计。后一类即使频率低，也不能用平均成功率掩盖。开发负责人最需要知道的是一类错误能否靠仓库索引、单元测试、权限收缩或人工复核解决；若只能靠反复提醒模型“仔细一点”，这样的改进通常难以持续。
第四张是价格表，但别只填每百万Token单价。计入长提示的重复传输、生成失败后的重试、沙箱运行、审查者工时及最终保留的合格结果。如果Highspeed降低等待却增加了单位成本，用户研究员可能仍愿意选它；夜间批处理则可能偏向普通版。把两种版本放在同一个任务包里测完，再按工作类型分流，比全员一键切换更稳。
这些表还可以避免一种常见的“试用幻觉”：演示时模型在干净的项目里一次成功，上线后面对命名混乱、历史接口和相互矛盾的文档，便开始在多轮工具调用中迷路。先用真实、可公开的旧项目测试它；成功之后，再逐步扩大输入规模和权限。权重发布若按计划兑现，还要重复同一套任务包比较托管与自建结果，避免把模型同名误当成服务配置相同。
参考资料
- Moonshot AI, Kimi K3.1 Pro Tech Blog: Advancing Open Intelligence，2026-10-24（发布、基准口径、训练侧控制、开放权重计划）。
- Moonshot AI, Kimi K3.1 Pro API guide；API Quickstart（模型标识、接口及上下文说明；部分页面存在未填完的基准占位文字，具体成绩以[1]为准）。
- Terminal-Bench, 官方任务与运行入口（基准任务背景；文章引用的65.7%为厂商自报，不冒充本站独立核实结果）。
图像为概念示意。文中建议系面向企业选型的评估方法，不表示已对模型执行独立测试。