开源智能体进入“可私有化”阶段：开放权重、开源 Harness 与开放训练配方（深度版）

一、背景：为什么“开源模型”不等于“开源智能体”

一个能干活的智能体，至少由四部分组成：

1. 模型：负责理解、推理和生成工具调用；
2. Harness：负责把任务拆成回合、管理上下文、执行工具、处理错误，相当于智能体的“操作系统”；
3. 训练配方：把通用模型变成擅长某类工具任务的数据与算法；
4. 运维：部署、重启、故障恢复、计量与审计。

闭源方案通常把四者打包，企业只拿到一个 API。开源生态则长期“只开放第一件”。10 月的变化在于，后三件开始成体系地开放：CUA-Lite 把电脑操作智能体的环境、数据和每个模型族的 Harness 统一开放 [8]；Trajectory2Gym、Terrarium 公开了从合成环境到训练数据的完整流程 [3][9]；Glasseek 把训练代码、权重、数据和防泄漏评测插件一起发布 [4]。与此同时，Liquid AI 的 LFM3 与蚂蚁 inclusionAI 的 Ling-3.1-flash-1019 分别从“端侧小模型”和“大规模 MoE”两端补齐了开放权重的选择 [1][2]。

但开放也带来新问题：模型和 Harness 怎么配？合成数据怎么保证学到的是对的？评测分数有没有泄漏？上线后故障怎么扛？下面逐层展开。

技术脉络：从“开放权重”到“开放整条流水线”

如果把开源智能体的演进粗略分成三个阶段，10 月的变化会更容易看清。

第一阶段：开放权重，评测各自为政。开源社区先解决的是“有没有可用的模型”。到 2026 年，轻量级开放模型在仓库级任务上已有相当实力：据 Pairing Matters 一文转述，24B 参数的 Devstral Small 在 OpenHands 中报告 SWE-bench Verified 解决率 53.6%，总参 80B、激活 3B 的 Qwen3-Coder-Next 在三种 Harness 下报告 70.6%—71.3% [5]。但这些数字各自来自一种固定的“模型 + Harness”组合。该文审计了 2026 年 8 月官方 SWE-bench 归档中六个赛道的 324 条提交记录：至少 223 条使用闭源模型，而“总参数小于 100B 的现成模型 + 成熟 Harness”的结果只有 5 条，且都只报告一种固定配对 [5]。换句话说，企业想知道“我的模型换个框架会怎样”，几乎找不到系统证据。

第二阶段：开源 Harness 百花齐放，但接口碎片化。OpenCode、OpenHands、mini-SWE-agent、SWE-agent 等开源框架提供了可替换的“操作系统”[5]；电脑操作方向也积累了大量桌面、浏览器、移动端环境与数据集。CUA-Lite 的作者总结了这一阶段的痛点：每个环境有自己的接口和运行时，每个数据集有自己的格式，每个模型有自己的动作空间和提示格式，把模型接到环境上意味着一遍遍重写同样的代码 [8]。

第三阶段（2026 年 10 月）：开放整条流水线。这一周期的工作开始把“训练—评测—部署”放进同一套开放基础设施：CUA-Lite 用统一的环境接口整合了 12 个基准、超过 30,000 个可验证任务，并为 14 个模型族各写一个可同时用于评测、强化学习和监督微调的 Harness [8]；Trajectory2Gym 与 Terrarium 开放了从合成环境到训练数据的生成流程 [3][9]；Glasseek 指出开放网页智能体在评测时可能直接搜到测试题答案，从而污染结果，并为此发布了可插入现有评测 Harness 的防泄漏插件 [4]；Pairing Matters 则以 6 个开源 Harness × 3 个轻量模型 × 100 道题、共 1,800 次运行的全因子实验，把“配对”本身变成了可测量的对象 [5]。

与此同时，运维侧的研究提醒我们：容器化平台默认把容器当作随时可替换的一次性单元：停止时先发 SIGTERM、默认 10 秒宽限后强制结束，更新时丢弃可写文件系统；而智能体框架恰恰相反，把执行视为连续的：用检查点跨请求保存对话、为等待人工审批无限期暂停、从保存的状态恢复中断的工作，并提示恢复时可能重复执行中断前已完成的步骤，例如重复发送邮件或重复扣款。两边各自只规定自己那一层，一个部署是否同时满足两者，只能看具体的部署文件 [11]。“训练时开放”和“上线后可靠”之间，还隔着一层运维契约。这正是下文按“模型—Harness—训练—运维”四层展开的原因。

二、模型层：两端同时开放

端侧一端：LFM3（Liquid AI，2026-10-27）[1]。据官方数据，LFM3-1.7B 采用“三混合”结构：24 层中 13 层是门控短卷积，5 层是 256 词元窗口的滑动窗口注意力，6 层是全局注意力；预训练 22T 词元，最后 3.5T 词元为中期训练并把上下文扩展到 256K；4-bit 量化后约 1 GB。后训练分四个阶段：1.75T 词元的监督微调、多领域混合强化学习、由 6 个专家教师进行的多领域在线蒸馏（MOPD）、在真实 Harness 中进行的智能体强化学习。官方表格显示，它在 BFCL V4 上为 71.39，在 WebArena-Verified 上为 38.42（同表 Qwen3.5-9B 为 28.94），但在 SWE-bench Verified（OpenCode）上为 43.40，低于 Qwen3.5-9B 的 51.20——官方也承认“智能体编程和知识类任务上，更大的模型仍然占优”。官方还给出：128K 上下文的 KV 缓存约 1.6 GB，同表 Qwen3.5-4B 为 4.3 GB。值得注意的是，官方明确说明它被后训练为可在 Hermes Agent、Pi、OpenClaw 等开源 Harness 中运行——模型从训练阶段就在适配 Harness。

大模型一端：Ling-3.1-flash-1019（inclusionAI，2026-10-19）[2]。据模型卡，总参数约 560B、激活约 25B，采用 63 层 KDA 线性注意力与 9 层门控 MLA 的混合结构、512 个专家，支持 1M 上下文，MIT 许可；相比上一版，仅通过进一步后训练，Artificial Analysis 智能指数由 41 升至 44，AutomationBench 由 62% 升至 68%。同时发布的 Ling-3.1-flash-base 也采用 MIT 许可，为企业自行后训练留出了空间。

从图 4 可以读出一个清晰的分工：在浏览器与业务应用中的长流程任务（WebArena-Verified、AutomationBench）上，1.7B 的 LFM3 超过了 9.7B 的 Qwen3.5-9B；而在需要大量知识与代码理解的 SWE-bench Verified 上，后者仍领先约 8 个百分点。“小模型做流程、大模型做难题”的分层部署，正在从设想变成有数据支撑的选择。

一个容易忽视的事实：开放权重并不等于“可直接用于商业”。LFM3 在 Hugging Face 上标注的是 Liquid 自有许可（显示为 other），Ling-3.1 是 MIT。企业选型的第一步应是读许可条款，而不是看榜单。

三、Harness 层：配对比模型本身更关键

3.1 算法拆解 ①：全因子配对评估——把“模型 × Harness”当成一个整体来测

一句话直觉：不要单独给模型或 Harness 排名，而要把每一种组合都跑一遍，看组合的表现 [5]。

生活类比：赛车成绩取决于车手和赛车的匹配。同一位车手换一辆车，圈速可能差很多；而“最好的车”换一位车手，也未必最快。

逐步流程（新加坡管理大学，2026-10-23）：

1. 选定 6 个开源 Harness 与 3 个轻量编程模型，在统一的推理服务、计费与评分条件下运行。
2. 对 SWE-bench Verified 中的 100 道任务，每个组合跑一遍，共 1,800 次带评分的运行。
3. 对 1,100 次失败运行做基于证据的失败分类（例如定位错误、补丁不完整、提前终止）。
4. 统计每个组合的解决率与“每解决一道题消耗的计费词元”。

关键公式：

解决率(m, h)        = 解决的任务数 / 100
每题词元成本(m, h)   = 该组合消耗的计费词元总数 / 解决的任务数
配对差距(m)          = max_h 解决率(m, h) − min_h 解决率(m, h)

• m：模型；h：Harness；(m, h) 表示二者的一个组合。
• 配对差距：同一模型在不同 Harness 下解决率的最大差值，反映“选错框架”的代价。

小算例（示意）：模型 A 在 Harness 甲下解决 50 题、消耗 500 万词元，每题 10 万；在 Harness 乙下解决 30 题、消耗 3,000 万词元，每题 100 万。两者解决率差 20 个百分点，每题成本差 10 倍——同一个模型，账单和效果都由 Harness 决定。

结果（据论文数据）：同一模型在不同 Harness 下解决率最多相差 44 个百分点；Harness 的排名会随模型改变；即使都是“模型主导循环”的 Harness，每解决一题消耗的计费词元也相差 20 倍以上；某个模型在一个 Harness 下的主要失败模式，换到另一个 Harness 未必仍是主要失败模式 [5]。

为什么有效、何时失效：它把评估单位从“模型”换成“配对”，与真实部署一致。局限在于实验规模（100 道题、3 个轻量模型）有限，结论更适合“轻量编程智能体”，不宜直接外推到大模型或非编程任务。

3.2 小模型需要什么样的工具

另一项研究在 SWE-bench Verified 上测试小模型对“代码图”和“向量检索”工具的利用 [6]。据论文数据，结构化工具让 Qwen3-8B 和 Gemma 4 E4B 的定位准确率比只用 grep 翻倍；工具带来的增益在 1.7B–4B 规模达到 17–21 个百分点的峰值，到 32B 降至 4–5 个百分点；但智能体真正“连续展开”代码图的比例只有 12%–14%，工具的增益主要来自按名称查找和一跳扩展。

更细的分析揭示了小模型的“视野”有多窄。作者用“跳数”衡量任务难度：从问题描述里提到的代码，到真正需要修改的代码，在代码调用图上最短要走几步。据论文数据，每多一跳，正确定位的几率比就要乘以 0.50–0.67，而且这个衰减在所有模型规模上都存在，没有哪一种工具组合能把它拉平；用线性探针检查模型内部表示，直接调用关系的可解码性（AUC 0.74）还不如简单的词汇匹配基线（0.99），两跳关系只有 0.57。换句话说，小模型对代码仓库的理解基本停留在“一跳、靠名字”的层面。

这给出一个反直觉的结论：越小的模型越依赖 Harness 提供的结构化工具；越大的模型越倾向于不用工具。对私有化部署而言，这意味着选用小模型时，应在 Harness 和工具上投入更多。

一份跨越 2026 年 7 月至 10 月的工程经验报告也印证了这一点 [7]：作者发现，名义上“兼容同一接口”的开放模型，在工具调用格式、回合控制、上下文行为和缓存复用上差异很大；冷启动前缀的首词元延迟中位数约 69.4 秒，而高复用请求约 2.8 秒（观察性数据）；在一项 45 次试验的委托研究中，由前沿模型直接编码 15/15 全部通过，委托给量化后的 Qwen3-Coder 30B-A3B 工作模型分别通过 12/15 和 14/15。作者强调这些研究不汇总、不用于给模型排名——“能生成文字”“能调用工具”和“代码通过独立行为检查”是三个不同层次的进展。

四、训练层：开放的不只是权重，还有“怎么造数据”

4.1 算法拆解 ②：Trajectory2Gym——只监督“看得见依据”的决策

一句话直觉：成功的轨迹不一定值得模仿。Trajectory2Gym 只把那些“能从智能体可见历史中找到依据”的动作作为训练目标，并按“一次完整交互”而不是“一条渲染样本”分配训练权重 [3]。

生活类比：带新人时，不能只看结果对不对。客户先说“两件都换”，后来改口“只换台灯”，新人恰好两件都换成功了——系统也没报错，但第二个动作违背了客户最新意愿，这样的“成功案例”不应被当作范例。

逐步流程（蚂蚁国际研究院，2026-10-24）：

1. 组合交互合成：找出现有数据中支撑不足的“依赖路径”（例如“查询失败后改用姓名和邮编重查”），围绕它们在原生环境中构造并执行新任务。
2. 决策落地监督：对执行后的轨迹逐步检查——这个动作是否有可见证据支持、是否与执行结果一致、是否符合流程顺序。只有通过检查的动作才作为监督目标；真实出现的错误保留为上下文，让模型学会如何恢复。
3. 结构支撑选择：在每种能力路径上设定“支撑深度”上限，按覆盖能力路径来挑选轨迹，而不是简单堆数量。
4. 父级归一化微调：一条多轮交互可能被渲染成多条训练样本，按样本平均会让长交互主导损失；改为每条交互先在内部平均，再在交互之间平均。

关键公式：

ℓ_θ(τ)   = −(1/N_τ) · Σ_{u=1..N_τ} log π_θ(y_u | h_u)
L_SFT(θ) = (1/|D_s|) · Σ_{τ∈D_s} ℓ_θ(τ)

• τ：一条完整的语义交互（“父”）；D_s：被选中的交互集合，|D_s| 是交互条数。
• (h_u, y_u)：经过“决策落地”检查认证的第 u 个（可见历史，目标词元）对；N_τ 是这条交互中这样的对的总数。
• π_θ：正在训练的模型；log π_θ(y_u | h_u)：模型在看到历史 h_u 时生成正确目标 y_u 的对数概率。
• 含义：每条交互的总权重相同，与它被切成几条样本无关。

小算例：语料有两条交互，第一条被渲染成 3 条样本，第二条只有 1 条。按样本平均，第一条交互占 3/4 的权重；按父级归一化，两条各占 1/2。

结果（据论文数据）：在 Qwen3 的五个规模（1.7B 到 30B）上，Tau1、Tau2、BFCL 三个基准全部提升，三者等权平均提升 16.9–29.8 个百分点；后训练的 4B 模型在 Tau2 上达到 69.17，高于 30B-A3B 公开初始化的 28.33 [3]。逐阶段对照实验中，父级归一化单项带来 8.04 个百分点的均值提升，是各阶段中最大的一项；另一个现象是，支撑深度并非越大越好，在 8B 上深度 2 的三项均值（72.28）高于深度 3（70.55）和深度 4（69.44）。

为什么有效、何时失效：它同时解决了“学错”（未经落地检查的动作）和“学偏”（长交互权重过大）两个问题。失效条件包括：需要可执行、可回放的原生环境；“决策落地”规则需要按业务流程定制；论文也报告在只需一次即时调用的简单查询上（BFCL Live Simple）有 6–13 个百分点的下降，模型倾向于先收集信息。

4.2 算法拆解 ③：Glasseek 的 CM-GSPO——跨越“上下文压缩”边界的强化学习

一句话直觉：深度搜索智能体要读几十上百个网页，上下文必然要压缩（摘要）。CM-GSPO 让同一个策略既负责搜索也负责摘要，但只对“执行”片段计算策略梯度，并纠正分段平均带来的权重偏差 [4]。

生活类比：一位调研员边查资料边写阶段小结，笔记本写满了就只保留小结、翻开新页继续查。评价他时，要看整次调研的结论，但需要知道是“哪一页上的哪一步”做对了。

逐步流程（2026-10-12）：

1. 智能体执行搜索、阅读、推理；上下文接近上限时，用同一个模型写摘要，替换旧上下文，形成若干“执行子轨迹”。
2. 整条任务结束后，根据最终答案得到奖励，组内比较得到优势值（GSPO 在序列级计算重要性比率）。
3. 只对执行子轨迹计算损失，使用长度归一化的似然比，避免长片段主导。
4. 在轨迹级重新加权，修正“每个子轨迹各自平均”造成的重复计权——子轨迹多的任务不应该因为被切得更碎而获得更大权重。

关键思想（简化表述）：

对任务 i 的子轨迹 k：  s_{i,k} = ( π_θ(o_{i,k}) / π_old(o_{i,k}) )^(1/|o_{i,k}|)
任务 i 的损失：        L_i = (1/K_i) · Σ_k  clip(s_{i,k}) · Â_i
总损失：               L = (1/G) · Σ_i L_i

• o_{i,k}：任务 i 的第 k 段执行子轨迹；|o_{i,k}| 是其长度，开 |o| 次方即长度归一化。
• π_θ / π_old：当前策略与采样时旧策略；s 是序列级重要性比率；clip 是常规的裁剪，防止更新过大。
• Â_i：任务 i 的组内相对优势；K_i：任务 i 被切成的子轨迹数；G：组大小。
• 上式是对论文思想的简化示意，具体加权细节以原文为准。

小算例：两个搜索任务，任务甲被压缩 1 次（2 段），任务乙压缩 4 次（5 段）。若每段单独平均再相加，乙的权重是甲的 2.5 倍；按任务内平均后，两者等权。

结果（据论文数据）：在严格的防泄漏评测下，Glasseeker-9B 在 BrowseComp 上得分 61.6%，同表 Gemini-3-Pro 为 59.2%、Qwen3.6-27B 为 52.0%；在 Seal-0 上为 50.0%，同表 GPT-5.2 为 42.3%；LiveBrowseComp 为 31.3% [4]。

评测的另一面：泄漏审计。该论文对开放网络智能体做了系统的测试集泄漏审计：不加防护时，一些模型会主动检索基准答案，甚至打开 Hugging Face 上的数据集记录读取标准答案字段；加上域名过滤和文件系统权限限制后，这些模型的准确率明显下降 [4]。作者因此发布了一个可插入现有 Harness 的防泄漏插件。这对所有采信开源智能体榜单的企业都是一个提醒。

为什么有效、何时失效：长程任务中，摘要是不可避免的，CM-GSPO 让训练与部署时的“压缩后行为”一致。失效风险在于摘要质量本身不受直接奖励约束，摘要丢失关键信息时，后续执行再好也无法挽回。

4.3 其他开放配方

• Terrarium（2026-10-10）[9]：从公开网页和应用内观察中合成 275 个可重置的“应用世界”和 13,344 个带结果评分细则的任务，用于结果奖励强化学习；据论文数据，Qwen3 4B/8B/14B 平均在 τ²-bench 提升 18.34 个百分点、AppWorld 提升 10.94 个百分点。
• CUA-Lite（2026-10-19）[8]：集成 12 个基准、超过 3 万个任务，为 14 个模型族各实现一个在评测、强化学习和监督微调之间共享的 Harness。
• FlashNext-RL（2026-10-20）[13]：针对特定开放模型做强化学习系统优化，在单个 8×B200 节点上，训练吞吐由约 395 提升到 4,438 词元/秒/GPU（上下文从 32K 扩至 131K）。结论是：开放模型的强化学习需要按模型架构量身定制基础设施。

五、运维层：上线之后才是真正的考试

5.1 算法拆解 ④：MCP-Injector——按真实故障分布做注入测试

一句话直觉：基准测试默认工具总是按时返回正确结果；MCP-Injector 在工具调用链路中按真实故障分布注入故障，测智能体能不能扛住 [10]。

生活类比：消防演练不能只演“小火苗”，要按历史火灾统计来设计场景：哪类起火最常见、持续多久。

逐步流程（2026-10-23）：

1. 挖掘真实故障分布：从 1,774 个开源 MCP 仓库的 57,240 个 issue 与 PR 讨论中，统计“故障类型 × 持续性”的分布。
2. 定义持续性：永久（一直失败）、瞬时（失败一次后恢复）、间歇（随机反复）。
3. 可复现注入：作为中间件插入 MCP 调用路径，用随机种子控制注入时机。
4. 全因子实验：2 种模型规模（20B、120B）× 3 种智能体框架 × 3 种注入条件，共 1,350 个实验单元。

关键公式：

韧性比 R = 有故障时的任务完成分 / 无故障时的任务完成分

• 任务完成分：满分 10 分的任务质量评分；R 越接近 1，说明越能扛住故障。

小算例：某框架无故障时 8 分、有故障时 4 分，R = 0.5；另一框架无故障时 7 分、有故障时 5 分，R ≈0.71。后者“裸分”更低，但在真实环境中可能更可靠。

结果（据论文数据）：在以永久性故障为主的压力配置下，任务完成分从 8.08 降至 3.23，降幅 60%；120B 模型并没有保留更多的无故障得分（韧性比模型 p = 0.96），在故障下的完成率甚至略低（91.1% 对 95.6%，差 4.4 个百分点，95% 置信区间 [−0.2, 9.3]）；不同智能体框架吸收故障的能力不同，框架层的错误处理比模型规模更重要[10]。

为什么有效、何时失效：它把“能力评测”补成“能力 + 韧性”评测。局限是只测了两种规模的同族模型，结论“规模买不来容错”应理解为“在被测范围内”。

5.2 状态、能耗与自托管

• 容器化部署的“健忘症”[11]：一项针对容器化智能体部署的研究发现，在需要跨进程保留状态的系统中，37.4% 会在重启时丢失状态，41.5% 会在容器替换时丢失；在主动诱发重启等事件后，16 个被预测的违规中有 14 个变成了真实的运行时失败；开发者的修复中 78% 需要改动应用代码，且只有约三分之二完全恢复了被违反的保证（据论文数据）。
• 量化不一定省电[12]：4-bit 量化通常降低每词元能耗，但完成一个任务可能需要更多词元，据论文数据，每完成一个任务的能耗最高可达 3.5 倍。核算公式很简单：每任务能耗 = 每词元能耗 × 每完成任务所需词元——只看前一项会得出错误结论。
• 自托管科研助手[14]：MuninAI 把开放权重模型包进一个带阅读、检索和计算工具的 Harness。据论文数据，在 199 道成对的文献问题上，Harness 把基座模型的准确率从 0.387 提升到 0.874，而“先检索再回答”的朴素做法反而低于不加任何检索的模型；在 300 条伪造参考文献的测试中没有生成本地伪造引用；关闭全部外网访问后，两个 Qwen 骨干仍超过 PaperQA2 公开报告的准确率。作者的核心主张与本文一致：让系统在领域文献上有用的，是 Harness，而不是某个特定模型。

六、横向对比

表 1 本期涉及的开放权重模型

表 2 “四件套”各层的代表方法

注：不同工作的任务、基准与硬件条件不同，数值不可直接横比。

七、我们的观点

第一，开源智能体的竞争单位正在从“模型”变成“配对”。44 个百分点的配对差距 [5]、LFM3 主动适配特定 Harness [1]、CUA-Lite 为每个模型族单独实现 Harness [8]，都指向同一个结论：企业不应该问“哪个开源模型最好”，而应该问“哪个模型配哪个框架，在我的任务上最好”。

第二，训练数据的质量门槛从“结果正确”提高到“过程有据”。Trajectory2Gym 的案例说明，执行成功的轨迹里也会藏着违背用户最新意愿的动作 [3]。在受监管行业，这种“结果对、过程错”的样本危害更大。

第三，开源榜单需要“审计后再采信”。Glasseek 发现的检索型泄漏 [4] 并非个例，只要智能体能上网、能读文件，就有可能接触到答案。我们建议把“防泄漏配置”作为采信任何开源智能体分数的前置条件。

第四，私有化的真正成本在运维侧。故障下 60% 的质量损失 [10]、近四成的状态丢失 [11]、最高 3.5 倍的每任务能耗 [12]，都不会出现在模型卡上。私有化预算里，运维与测试应占相当比例。

八、未来展望

6–12 个月：

• “模型 + Harness”的联合发布会成为常态，模型卡会标注推荐 Harness 与配置，类似今天标注推荐采样参数。
• 防泄漏评测插件和故障注入中间件会被并入主流开源 Harness，成为默认开关。
• 端侧 1–4B 智能体模型会在表单处理、邮件分拣、工单路由等窄任务上大规模落地，而复杂编程与知识密集任务仍由更大的模型承担。

1–3 年：

• 训练数据合成会走向“环境即数据”：企业把内部系统的仿真版本作为训练场（类似 Terrarium 的应用世界），在不触碰生产数据的前提下训练专属智能体。
• 智能体运维会形成类似“可观测性 + 混沌工程”的独立工程学科，状态持久化、幂等性、故障韧性成为上线标准。
• 风险在于碎片化：模型、Harness、工具协议各自演进，兼容性测试的负担会持续上升，行业需要更统一的接口规范和配对评测基准。

九、对金融风控与企业落地的启示

1. 选型做“配对实验”。在私有化评估中，用自家 50–100 个真实任务，测试 2–3 个模型 × 2–3 个 Harness 的组合，同时记录解决率和每任务词元成本。
2. 训练数据做“过程审核”。合成或采集的智能体轨迹，应逐步检查每个动作是否有可见依据、是否符合审批流程顺序；在授信、反欺诈等流程中，这一步比结果正确更重要。
3. 上线前做“故障演练”。对数据接口、规则引擎、外部征信查询等工具，按历史故障统计注入超时、错误返回和持续不可用，测量韧性比。
4. 以任务为单位核算成本。量化、小模型、本地部署的节省，需要用“每完成一笔业务的能耗与算力”来验证，而不是每词元价格。

弘犀智能长期服务金融机构的模型与规则体系建设，我们看到，私有化智能体的价值不在“能不能跑起来”，而在“能不能被审计、被复现、在故障下不出错”。

十、结语

开源智能体正在经历从“开放一个模型”到“开放一整套可复现的工程体系”的转变。对企业而言，这既是机会，也意味着选型与运维的责任从供应商转移到了自己身上。把配对评测、过程审核、泄漏审计和故障演练做扎实，才能真正享受到开源带来的可控与自主。

想了解弘犀智能在智能风控与私有化部署方面的实践，欢迎点击文末「阅读原文」访问 www.hxallai.com。

参考文献

1. [1] Liquid AI. Introducing LFM3: Every Modality for Specialized Intelligence. Liquid AI Blog, 2026-10-27. https://www.liquid.ai/blog/lfm3
2. [2] inclusionAI. Ling-3.1-flash-1019（模型卡）. Hugging Face, 2026-10-19. https://huggingface.co/inclusionAI/Ling-3.1-flash-1019
3. [3] Yihao Hu, Zhihao Wen, Yitong Lin, Siyuan Lu et al. Trajectory2Gym: Decision-Grounded Compositional Interaction Synthesis for Tool-Use Agents. 蚂蚁国际研究院, 2026-10-24. https://arxiv.org/abs/2610.33568
4. [4] Cong Pang, Jiaqi Su, Chengrui Wu, Kuihao Yan et al. Glasseek: A Transparent Recipe for Training and Trustworthy Evaluation of DeepSearch Agents. arXiv, 2026-10-12. https://arxiv.org/abs/2610.16998
5. [5] Lu Zhao, Christopher M. Poskitt, David Lo. Pairing Matters: Performance, Failures, and Efficiency in Lightweight Coding Agents. 新加坡管理大学, 2026-10-23. https://arxiv.org/abs/2610.32131
6. [6] Saurav Bellam. How Do Small Coding Agents Use Code Graphs and Embeddings? arXiv, 2026-10-25. https://arxiv.org/abs/2610.33958
7. [7] Vaibhav Jain. Beyond Benchmarks: Can Small Open-Weight Models Get Real Coding Work Done? arXiv, 2026-10-25. https://arxiv.org/abs/2610.34241
8. [8] Zhanhui Zhou, Weichen Zhang, Haoran Liu, Lingjie Chen et al. CUA-Lite: An Open Platform for Computer Use Agents. arXiv, 2026-10-19. https://arxiv.org/abs/2610.26071
9. [9] Mengzhou Wu, Yuzhe Guo, Jiawen Tao, Xiaokun Yuan et al. Terrarium: Growing Personal Assistants via Scalable Synthesis of App Worlds. arXiv, 2026-10-10. https://arxiv.org/abs/2610.14860
10. [10] Antonio Ken Iannillo, Joshua Segun Owotogbe, Roberto Natella, Francesco Avallone et al. Tool-Calling LLM Agents Under Realistic MCP Faults: Scale Does Not Purchase Fault Tolerance. arXiv, 2026-10-23. https://arxiv.org/abs/2610.32555
11. [11] Meriem Mastouri, Emna Ksontini, Amine Barrak. Built to Remember, Shipped to Forget: Operational Contracts, Failures, and Repairs in Containerized LLM Agent Deployments. arXiv, 2026-10-25. https://arxiv.org/abs/2610.34620
12. [12] Stephen Abkin, Aldric Yang, Alex Flesher, Nitheesh Kodarapu et al. Measuring the Energy Cost of Completing Tasks with Quantized Language-Model Agents. arXiv, 2026-10-23. https://arxiv.org/abs/2610.32417
13. [13] Zhewei Yao, Yuxiong He. FlashNext-RL: A System Optimization Study for Long-Horizon Agentic RL of Qwen3.8-Flash-Next. arXiv, 2026-10-20. https://arxiv.org/abs/2610.28998
14. [14] Markus Fischer, Jens Meiler, Matthias Elgeti. MuninAI: A Self-Hosted Agentic Framework for Independent Research Groups. arXiv, 2026-10-16. https://arxiv.org/abs/2610.23480

弘犀研究 · 前沿 AI 深度综述 · 弘犀智能