2026 年 9 月 16 日

1 / 3

Salesforce Koa：用 Nemotron 3 Super、合成 CRM 轨迹和 GRPO 训练专用业务模型

Salesforce 与 NVIDIA 9 月 15 日发布 Koa，这是 Salesforce 第一款专门面向 CRM Agent 的 reasoning model。底模是 NVIDIA Nemotron 3 Super，但 Salesforce 没有把通用模型直接塞进 Agentforce，而是重新做了一轮领域 post-training：训练数据是根据其近三十年 CRM 产品经验构造的合成业务场景，覆盖销售线索、机会管理、服务 case 等流程以及 14 个以上行业。Salesforce 明确称没有使用客户数据训练 Koa。Salesforce 公告

训练方法本身值得注意。Salesforce 先用 SFT，再用 GRPO 做强化学习，基础设施采用 NVIDIA NeMo RL、NeMo Gym 和 NeMo AutoModel。每个合成场景不只有“问题—答案”，还包含 persona、目标任务，以及完成任务所需的一系列 action 和 tool call。换句话说，它训练的对象已经接近业务 Agent 的完整决策轨迹：理解当前 CRM 状态，选择下一步动作，调用正确工具，再继续推进流程。

Salesforce 报告，在自己的 CRM Benchmark 上，Koa 在更新 opportunity、路由 case、安排 follow-up 等任务中可以匹配或超过所比较的领先模型，同时错误数少约三倍。这个数字目前只能作为厂商报告结果理解：公告没有提供足够完整的公开 leaderboard、各模型 harness 配置和可独立复现的测试集，因此暂时无法判断三倍错误差距中有多少来自模型 post-training、有多少来自更贴近 Salesforce runtime 的训练分布。

这项工作的结构与通用 frontier model 路线有明显差别。企业软件公司本身拥有大量关于“工作应该怎样完成”的隐性知识：字段关系、业务规则、操作顺序、工具权限和异常处理。Koa 尝试把其中一部分转换成合成轨迹，再通过 SFT + RL 写进一个可控制权重的中型基础模型，而不是每次运行都依赖更大的通用模型从 context 中重新推断这些规则。

这里也出现了一个很适合业务 eval 检验的问题：如果模型训练数据本身就是按照某套业务流程合成出来的，那么 benchmark 需要特别区分“复现标准工作流”和“处理工作流之外的异常状态”。例如缺字段、权限变化、互相冲突的 CRM 记录或工具返回错误，可能比标准 opportunity update 更能测出领域模型是否真正理解业务状态。

Koa 目前已经在 Salesforce 内部使用，并向包括 1-800Accountant、Baxter Credit Union、Engine、Formula 1、UChicago Medicine 和 Xero 在内的少量客户开放 pilot；美国地区 GA 计划在 2026 年冬季进行。模型权重、post-training 和 inference 均由 Salesforce 控制在自己的 trust boundary 内。Salesforce 公告

2 / 3

Real-SWE：私有企业代码上的最好 coding agent 只有 38.8%

Specific Labs 最近公开的 Real-SWE 把 coding-agent evaluation 换到了一个很难通过继续扩充公开 benchmark 解决的问题上：测试代码本身不公开。任务来自获得授权的真实企业私有生产仓库，包括拥有 20 万以上用户的应用、处理十万级银行账单的 fintech 系统和企业销售软件；任务也来自这些公司工程师实际完成过的工作。Y Combinator 对 Real-SWE 的项目说明

公开结果里，Claude Fable 5.1 + Claude Code 的 resolution rate 为 38.8%，GPT-6 Astra + Codex CLI 为 33.8%，Gemini 3.8 Flash + Gemini CLI 为 31.2%；GLM 5.3 + Claude Code 达到 28.8%。测试按“模型 + harness”作为完整系统运行，而没有强行把模型从实际 coding environment 中剥离出来。Real-SWE 方法与结果整理

后一个设计尤其重要。GLM 5.3 在 Claude Code 中超过 Grok 4.6 + Grok Build 和 Muse Spark 1.3 + Muse Code，至少说明在这组任务上，底模排名不能直接推出 Agent 系统排名。不过 Real-SWE 当前公开样本只有 10 个任务、每个系统运行 8 次，因此相邻模型之间几个百分点的差异不适合当成稳定 leaderboard 顺序。

更有解释力的是失败类型。Specific Labs 将失败归入 missed requirement、integration error、unverified assumption、regression 和 wrong file 等类别，其中 missed requirement 在不同模型中占失败的 28.3%–67.2%。Agent 经常并非不会写代码，而是没有从陌生代码库、业务规则和 ticket 中还原出完整需求；integration error 和未经验证的假设也是主要来源。Real-SWE 结果整理

私有代码还有一个评测层面的价值：它显著削弱了训练数据污染和公开解题轨迹带来的解释歧义。SWE-bench 一类公开 benchmark 的 repository、issue 和历史 patch 都存在于互联网；即使采取 contamination control，也很难完全知道模型在 pre-training 或后训练阶段接触过多少相关材料。Real-SWE 的代码和真实修复没有公开出现，因此至少把“是否见过这道题”这一变量压低了很多。

但它同时带来另一类问题：可复现性下降。外部研究者无法获得相同私有仓库，就很难独立检查任务设计、grader 和失败 taxonomy；十个公开任务也不足以代表完整企业软件工程分布。因此 Real-SWE 当前最可靠的结论是：当代码库转向模型未见过的私有生产系统时，现有 coding agents 的成功率明显下降，而且需求理解和系统集成成为主要失败来源。至于具体模型之间谁高 5 个百分点，还需要更大的私有任务池和独立运行。

3 / 3

GT Bench：同一个图问题换一种表示，模型准确率就会改变

GTA / Graph Theory Bench 是本期唯一补报，原始论文 9 月 10 日提交；此前近几期日报没有实质介绍。它测试一个容易被 benchmark 忽略的变量：任务语义保持不变，仅改变输入表示，模型能力测量会不会发生明显变化。论文

GT Bench 包含 24 种经典图问题、44 种 task-structure 设置和超过 10 万个样本。同一张图可以表示成自然语言、结构化语言、邻接表或邻接矩阵。作者测试八个 LLM 后发现，没有一种表示在所有模型和图结构上稳定最好；最佳 representation 会随图的规模、密度、拓扑以及模型本身变化，即使较强 reasoning model 的敏感性有所降低，也没有消失。

这件事对 benchmark 的意义比“图论能力”本身更广。很多评测默认 prompt serialization 只是包装：JSON、表格、自然语言或某种 KV 结构只要包含相同信息，就认为测量的是同一个能力。但 GT Bench 的结果说明，表示方式实际上进入了模型的计算条件。一个模型在邻接矩阵上得到 60 分、邻接表上得到 75 分，不能简单把其中任一数字理解为纯粹的 graph reasoning capability。

作者随后构建 GTA，让一个经过 preference training 的 selector 根据具体问题选择表示，再配合 plan-and-decompose scaffolding，底层 executor 模型保持冻结。Phi-4 在 easy split 从 53.5% 提高到 69.1%，hard split 从 33.0% 提高到 41.5%，并在 GraCoRe 和 NLGraph 上无需重新训练即可迁移。论文

这也构成一个很干净的 harness 效应：模型参数完全不变，只改变输入表示选择和推理脚手架，最终 benchmark 分数就发生两位数变化。对于 structured extraction、tool calling 或业务 Agent 评测，同样值得检查 serialization sensitivity——至少对少量代表题同时生成自然语言、JSON/KV、表格或不同 tool schema 版本。如果模型排名随表示发生大幅交换，那么 benchmark 测到的已经不只是目标业务能力，还包含 harness 与数据表示的适配程度。