Kimi K3.1 Pro 评测与 API 价格，百万上下文怎么选

100 万 token 的上下文，和一封不该发出去的邮件，出现在了 2026 年 10 月 24 日这批 AI 热点里。前者让人想把整个仓库交给模型，后者提醒我们，模型读得越多，也可能接触越多藏着指令的资料。Kimi 新模型、编程 Agent、安全实验和 API 性能报告放在一起看，我更关心能力涨上去以后，工程怎么接得住。这篇沿着六条线聊，帮你判断模型怎么选、钱花在哪，以及哪些动作必须由代码守住。

一、Agent 接上业务工具后，提示词还能守住权限吗？

先说结论，我会先检查工具执行前的权限校验，再考虑给系统提示词加几句警告。

这批文章里，最值得动手的是一个本地邮件 Agent 实验。作者把假秘密放进上下文，再向待总结的文档投毒，观察模型会不会请求发送邮件。攻击包括冒充安全通知、把命令藏进 HTML 注释，以及要求给秘密逐字符插入连字符，尝试绕过精确匹配。邮件工具全部模拟，不会真的外发。本地红队实验｜dev.to

这个实验最有用的地方，是把两件容易混在一起的事拆开了。模型有没有受骗，是一层；受骗以后，执行系统有没有放行，是另一层。原文没公布实际测量结果，所以我只把它当成实验教程，不会据此认定某种防护已经有效。

模型提出了操作，不等于业务系统应该执行。

另一篇工具权限文章给出了相同方向的设计。Agent 先产生调用请求，外部系统再根据用户身份、操作范围和参数决定是否放行。这个顺序完全成立，关键是授权必须发生在真正执行之前。工具执行前授权｜dev.to

回到这块，前端和全栈团队很容易在接入时犯一个熟悉的错误。页面按钮做了权限控制，后端接口却默认相信调用方；换成 Agent，就是系统提示写了禁止外发，邮件工具却接受任意收件人。入口看着管住了，执行端仍然敞着。

下面这段 JavaScript 只演示邮件工具的一道收件人限制，收件人集合必须来自业务授权，不能由模型填写。

function authorizeEmail(call, grant) {
  if (call.name !== "send_email") return { allowed: false };

  const recipients = call.args?.to;
  if (!Array.isArray(recipients) || recipients.length === 0) {
    return { allowed: false };
  }

  const allowed = recipients.every(
    address => typeof address === "string"
      && grant.allowedRecipients.has(address)
  ); // 逐个检查，不能只验证第一个收件人

  return { allowed };
}

const grant = {
  allowedRecipients: new Set(["reviewer@company.example"])
}; // 由可信业务流程提供，不能接受模型自报授权

最容易翻车的是 grant 的来源。模型如果既能申请操作，又能填写自己的授权范围，这道检查就白做了。这段代码也没有覆盖正文敏感信息、附件、抄送和用户确认，不能直接拿去充当完整邮件网关。

攻击入口还可能比文档正文更偏。另一篇文章转述了对 2.17 亿条网页响应的扫描，在 30 个站点发现实际提示注入尝试；后续小样本测试里，当用户提示赋予网站权威时，Claude 在 9 次运行中有 7 次遵循响应头里的注入指令。这个 7/9 只说明那组提示和测试条件下的行为，不能当成普遍攻击成功率，更不能推出工具已经执行成功。HTTP 响应头注入｜dev.to

你要是也在做联网助手，今天就能拿模拟工具跑一轮。让正文、HTML 注释和响应头分别夹带同一个外发要求，分开记录模型是否申请调用、执行端是否放行。只统计模型有没有拒绝，会漏掉最关键的一半。

二、Kimi 百万上下文和接近头部的成绩，够不够换主力模型？

Kimi K3.1 Pro 是今天模型选型里绕不开的一条。几篇报道分别使用了 10 月 23 日 API 上线和 10 月 24 日发布的时间口径，放进这期日报时，我更愿意把它看成这两天集中披露的一次更新。

按报道，它支持百万 token 上下文，提供普通版和 Highspeed 版本，已经接入 Kimi Code 和 API，完整权重计划在 11 月 4 日前发布。这里要把时态读清楚，现在能调用，与权重已经开放，是两回事。Kimi 发布报道｜IT之家

说实话，百万上下文对程序员很有吸引力。跨文件改造最烦的就是不断补材料，组件、接口定义、测试约束和历史决策散在各处。能一次提交更多内容，确实提供了减少来回沟通的可能。

但容量只是起点。

Moonshot 披露的 Terminal-Bench 4.0 成绩是 65.7%，接近同表中 Claude Opus 5.5 的 66.4%。MarkTechPost 还说明，大部分测试采用 Claude Code 执行框架，使用最高推理强度。因此，这个成绩同时受到模型、工具组织方式和运行配置影响。评测配置与模型规模｜MarkTechPost

另一条证据来自第三方综合评测。The Decoder 转述 Artificial Analysis 智能指数，K3.1 Pro 得到 55 分，排名第四，榜首 Claude Opus 5.5 为 58 分。综合榜单接近头部，足以支持把它放进候选名单；它没有替我们测过组件库升级、复杂表单改造和老项目排错。第三方综合指数｜The Decoder

我会给它一个测试名额，暂时不会只凭榜单替换主力。

这里有个坑，3 万亿级参数也容易被读成强模型终于可以随便本地跑了。另一篇报道给出的规模是总参数 2.8 万亿、每次激活约 1040 亿。激活量影响计算，但不等于部署只需要容纳激活的那部分权重。文中引用的还是前代 K3 的部署建议，不能拿来当 K3.1 Pro 的精确配置。MoE 与部署边界｜MarkTechPost

真要判断换不换，我会拿仓库里六到十个半天内能验收的小任务，固定工具、权限和推理档位，让两个候选分别完成。记录测试通过情况、人工修改时间、总费用和完成耗时，再加一道跨文件约束，看看它能不能持续记住。对技术管理者来说，这些结果比一次生成多少行代码更接近采购依据。

三、模型输出越来越快，为什么 AI 应用还是让人等？

顺着上面聊，Highspeed 的速度承诺很容易让人直接算出任务可以快两三倍，但现在还不能这么算。

Simon Willison 的短评给出了比较具体的价格。K3.1 Pro 标准版每百万输入 token 2 美元、输出 token 10 美元；Highspeed 宣称输出速度为普通版的 2 至 3 倍，非缓存命中部分价格翻倍。究竟省了多少整项任务时间，还取决于调用轮数、工具等待和返工。API 价格与高速版｜Simon Willison

信通院的报告正好补了另一面。按 IT之家转述，监测使用的是 2026 年 1 至 8 月数据。国内模型 8 月平均输出速度为每秒 78.23 token，高于 2025 年均值的 38.25；首词时延却从 2025 年均值的 0.78 秒，升至 8 月的 1.26 秒。模型 API 性能报告｜IT之家

回答展开更快，开始回答之前也可能等得更久。

对前端界面，这两个阶段需要分别观察。首词时延影响用户盯着加载状态的时间，输出速度影响答案展开的速度。对于编程 Agent，工具执行、测试和重试又会继续增加等待。只盯着每秒 token，很容易把用户真正感受到的时间漏掉。

缓存也要分清用途。一篇缓存实践文章把响应缓存和提示词缓存拆开讨论。前者直接复用旧答案，后者复用输入前缀的处理结果，每次仍然生成新答案。稳定 FAQ 可以考虑复用答案，持续读代码、改文件的 Agent 则更适合检查前缀缓存是否可用。AI 缓存适用边界｜dev.to

大概率你也遇到过这种需求，同一句问题，今天和昨天应该得到不同答案。订单状态会变，检索文档会更新，用户权限也可能变化。语义相似不等于答案可以共用。

Mixdog 的作者则从执行过程省开销。他报告，在 89 个 Terminal-Bench 2.1 任务、每个运行 5 次的测试中，使用同一模型时 token 消耗减少约 63%。但具体成功率、波动和部分配置没在正文里展开，自动推理降档是否参与测试也需要核对。我对把这个数直接写进预算持保留意见。Mixdog 成本测试｜dev.to

今天可以先拿一组固定请求比较普通版和高速版，把首词时间、完整响应时间、重试次数和账单分开记。缓存则先挑答案稳定的一小类流量，在缓存键里纳入租户、权限范围和知识版本，别用一个漂亮命中率掩盖旧答案。

四、JSON 校验都过了，为什么 AI 还是把业务数据填错？

做 AI 办公提效时，最容易制造安全感的东西之一，就是一份整齐的 JSON。

结构化输出文章提醒了一个很实际的问题。Schema 只允许 high、medium、low 时，模型即使更想表达不知道，也可能被迫从合法选项里选一个。文章中的概率用于解释机制，并非准确率实验，但这个设计漏洞很好理解，下拉框没有未知选项，表单照样能提交。结构化输出的内容风险｜dev.to

格式校验通过，只证明数据装进了规定的格子。

另一篇技术文档阅读文章给了配套办法。别让模型笼统总结 API 文档，而是按章节提取必填参数、类型、限流、超时和错误码，没写清楚的地方明确留下，再合并速查表并回查原文。技术文档四步提取｜dev.to

我的读法是，这两篇其实在解决同一个交付问题。抽取系统必须允许停在不知道，业务代码也得接受这个状态。否则前面要求模型诚实，后面却对空值做默认填充，错误还是会悄悄进入数据库。

下面用 JavaScript 表达一份超时配置抽取结果，缺少证据时直接进入复核分支。

const extracted = {
  timeoutMs: null,
  evidence: null,
  status: "unknown"
};

function decideTimeout(result) {
  const valid = result.status === "found"
    && Number.isInteger(result.timeoutMs)
    && result.timeoutMs > 0
    && typeof result.evidence === "string"
    && result.evidence.trim().length > 0;

  if (!valid) return { action: "review" };

  return {
    action: "review_evidence",
    proposedTimeoutMs: result.timeoutMs
  }; // 有引用仍要核对，不能直接当成真实配置
}

最容易翻车的是把 evidence 非空当成证据真实。引用可能找错位置，数值也可能抄错，所以这段代码只负责分流，没有自动写配置。

Android 定位器迁移案例也很有代表性。作者报告，模型不带规则转换时出现 7% 至 9% 的选错问题；补充规则后，错误降到 1 至 4 个，仍没超过专用转换器。一个典型陷阱是名称相似的 API，大小写匹配语义却不同，生成代码能运行也可能点错元素。定位器规则与模型实测｜dev.to

要我选，规则明确、可机械转换的部分会先交给专用代码，模型处理规则覆盖不到的部分。今天挑十几条文档记录，把缺字段、章节冲突和明确答案混在一起测，看系统会不会把未知自动补成默认值，再逐条核对原文就够有收获了。

五、百万上下文来了，RAG 分块和会话压缩还需要做吗？

需要，而且我会继续把它们当成数据组织问题来做。

长窗口扩大了输入容量，却没有替我们决定哪些材料应该一起出现。RAG 分块文章举的例子很直观，术语定义在前面，适用条款在后面；检索只命中了后者，回答就可能漏掉限定条件。重排序能调整已有候选的顺序，补不回没有进入上下文的材料。RAG 分块与索引结构｜dev.to

作者建议把用于定位的小片段，与交给模型阅读的上下文分开。索引中保留文档、位置、父章节和相邻片段关系，命中以后再扩展必要内容。这里的小片段大小只是设计选择，文中的 50 token 示例不能直接照搬成统一配置。

回到业务问题，用户问某个退款条件，命中的句子可能只写了可以退款，真正重要的期限和例外却在旁边。这个时候继续换 embedding，未必比补齐所属小节有效。

会话压缩处理的是另一种材料缺失。相关教程把磁盘完整记录和模型工作上下文分开，旧轮次可以压缩，最新用户消息开始的当前轮次保留，避免把工具调用和结果切断。上下文压缩与会话管理｜dev.to

这个实现的边界也很明确。当前一轮本身已经产生大量内容时，没有足够旧历史可压缩，依然可能超出窗口。摘要还可能漏掉约束，原文没有给可靠性评测。

上下文装得下，只是事情能继续的一个条件。

我更在意摘要是否保留了已经失败的尝试。只写完成了哪些文件，却漏掉测试仍然失败，后续 Agent 就可能建立在错误进度上继续干。RAG 也是一样，材料看着相关，却漏了一个例外，回答就可能偏离业务规则。

今天可以各取五个跨段落问题和一段长会话做回放。RAG 比较只给命中块与补齐父章节的答案，会话则压缩后追问原来的限制、失败测试和未完成任务。先看关键事实能否完整回来，再讨论窗口该买多大。

六、多 Agent 同时写代码，人工审查应该放在哪里？

Coppice 的看板把两个关口放得很直白，计划先审，diff 再审；接受改动与合并还分成独立操作。它把已有 CLI Agent 集中到本地桌面工作流里，但文章没有证明这种方式能减少多少错误。Coppice 审查流程｜dev.to

我喜欢这个区分。计划阶段纠正需求理解，和代码阶段检查实现，是两种不同的判断。如果等到几千行 diff 出来才发现方向偏了，审查者会很难受。

不过，增加审批也会增加等待。小范围、容易回滚的修改，未必都值得停下来审计划。更适合提前看方案的，是跨模块改造、数据迁移和影响外部系统的任务，具体还得按团队风险来定。

权限检查同样不能只看 Agent 读了什么。另一篇文章举了一个支持助手的例子，定价规则与客户续约日期分别都允许读取，组合成客户谈判判断以后，又被写进更多人可见的工单。问题已经从读取资格，变成结果能发给谁。组合推断与输出边界｜dev.to

审查代码之外，还要审查结果准备进入哪里。

Muse 分享事件让这个问题变得更具体。按报道，研究人员通过被动 DNS 发现超过 6800 个分享页面主机名，部分免登录页面包含敏感资料，标题还进入了子域名。这个数字是发现的主机名数量，不能写成 6800 多份敏感聊天全部泄露；也没有恶意利用证据。Muse 分享链接隐私问题｜IT之家

所以自动发布摘要、生成分享链接、把分析写回工单，都值得像合并代码一样看待。确认模型可以读资料，只完成了一部分授权。

两人借助编程 Agent 推进 M4 Linux GPU 驱动的案例，则提供了另一种审查支点。按作者报告，成果通过 OpenGL ES 3.0 一致性测试，但仍处于开发者 alpha 阶段，也没有进入 Linux 内核上游。成熟测试能支持具体能力的判断，不能直接替整机稳定性或项目接纳背书。M4 Linux GPU 驱动案例｜dev.to

技术管理者今天可以挑一个正在推进的 Agent 任务，把计划批准、diff 接受、合并和对外发布分别走一遍，再用一个低权限账号检查最终结果是否可见。哪一步沿用了执行者权限、忘了接收者权限，通常比看板上有几个 Agent 更值得先修。

总结

按这批报道能确认到的发布状态，Kimi K3.1 Pro 已有在线产品和 API，权重仍处于承诺开放的阶段。第三方综合评分、厂商终端测试和作者自测，也都各有具体出处，不能混成一句已经全面追平。

我的取舍是，把新模型放进候选名单，把更多精力放到验收、权限和执行成本上。前端页面能显示流式输出，后端能接工具，只代表链路跑通；模型受骗以后能不能阻止外发，未知字段会不会被乱填，结果会不会落进错误的共享范围，才决定这套东西能走多远。

至于百万上下文能减少多少返工、高速版能缩短多少任务时间、多 Agent 能省多少人工，目前这些文章还没有替我们的仓库给出答案。

今天这批 AI 编程消息里，我最想带走的，是一种更具体的比较方式。看完成并验收一个任务花了多少钱、多久，以及中间哪些操作被可靠地拦住。对天天写业务代码的程序员，这比继续追一个孤立分数更有用。

参考

一、Agent 接上业务工具后，提示词还能守住权限吗？

先说结论，我会先检查工具执行前的权限校验，再考虑给系统提示词加几句警告。

模型提出了操作，不等于业务系统应该执行。

下面这段 JavaScript 只演示邮件工具的一道收件人限制，收件人集合必须来自业务授权，不能由模型填写。

function authorizeEmail(call, grant) {
  if (call.name !== "send_email") return { allowed: false };

  const recipients = call.args?.to;
  if (!Array.isArray(recipients) || recipients.length === 0) {
    return { allowed: false };
  }

  const allowed = recipients.every(
    address => typeof address === "string"
      && grant.allowedRecipients.has(address)
  ); // 逐个检查，不能只验证第一个收件人

  return { allowed };
}

const grant = {
  allowedRecipients: new Set(["reviewer@company.example"])
}; // 由可信业务流程提供，不能接受模型自报授权

二、Kimi 百万上下文和接近头部的成绩，够不够换主力模型？

但容量只是起点。

我会给它一个测试名额，暂时不会只凭榜单替换主力。

三、模型输出越来越快，为什么 AI 应用还是让人等？

顺着上面聊，Highspeed 的速度承诺很容易让人直接算出任务可以快两三倍，但现在还不能这么算。

回答展开更快，开始回答之前也可能等得更久。

四、JSON 校验都过了，为什么 AI 还是把业务数据填错？

做 AI 办公提效时，最容易制造安全感的东西之一，就是一份整齐的 JSON。

格式校验通过，只证明数据装进了规定的格子。

下面用 JavaScript 表达一份超时配置抽取结果，缺少证据时直接进入复核分支。

const extracted = {
  timeoutMs: null,
  evidence: null,
  status: "unknown"
};

function decideTimeout(result) {
  const valid = result.status === "found"
    && Number.isInteger(result.timeoutMs)
    && result.timeoutMs > 0
    && typeof result.evidence === "string"
    && result.evidence.trim().length > 0;

  if (!valid) return { action: "review" };

  return {
    action: "review_evidence",
    proposedTimeoutMs: result.timeoutMs
  }; // 有引用仍要核对，不能直接当成真实配置
}

最容易翻车的是把 evidence 非空当成证据真实。引用可能找错位置，数值也可能抄错，所以这段代码只负责分流，没有自动写配置。

五、百万上下文来了，RAG 分块和会话压缩还需要做吗？

需要，而且我会继续把它们当成数据组织问题来做。

上下文装得下，只是事情能继续的一个条件。

六、多 Agent 同时写代码，人工审查应该放在哪里？

我喜欢这个区分。计划阶段纠正需求理解，和代码阶段检查实现，是两种不同的判断。如果等到几千行 diff 出来才发现方向偏了，审查者会很难受。

审查代码之外，还要审查结果准备进入哪里。

所以自动发布摘要、生成分享链接、把分析写回工单，都值得像合并代码一样看待。确认模型可以读资料，只完成了一部分授权。

总结

至于百万上下文能减少多少返工、高速版能缩短多少任务时间、多 Agent 能省多少人工，目前这些文章还没有替我们的仓库给出答案。

AI日报

今日看点

一、Agent 接上业务工具后，提示词还能守住权限吗？

二、Kimi 百万上下文和接近头部的成绩，够不够换主力模型？

三、模型输出越来越快，为什么 AI 应用还是让人等？

四、JSON 校验都过了，为什么 AI 还是把业务数据填错？

五、百万上下文来了，RAG 分块和会话压缩还需要做吗？

六、多 Agent 同时写代码，人工审查应该放在哪里？

总结

参考

AI日报

今日看点

一、Agent 接上业务工具后，提示词还能守住权限吗？

二、Kimi 百万上下文和接近头部的成绩，够不够换主力模型？

三、模型输出越来越快，为什么 AI 应用还是让人等？

四、JSON 校验都过了，为什么 AI 还是把业务数据填错？

五、百万上下文来了，RAG 分块和会话压缩还需要做吗？

六、多 Agent 同时写代码，人工审查应该放在哪里？

总结

参考