长程智能体：原生模型与外挂编排方案怎么选

一、对比背景：长程任务把”模型能力”和”工程能力”的边界打乱了

过去两年，绝大多数应用把大模型当成”单轮问答组件”：输入一段文本，输出一段文本，剩下的编排交给应用层。这种分工在短任务上没问题，但一旦任务变成”在终端里跑通一整套流程””从零写出可运行的程序””跨多个软件完成办公自动化””把一个真实仓库的 issue 修到能合入”，问题就变了性质——任务跨度从几十秒变成几十分钟甚至几小时，中间会出错、会走偏、会忘记约束。

这时会自然产生一个疑问：长程能力到底应该”长在模型里”，还是”搭在模型外面”？围绕这个问题，业界形成了两类典型方案。近期某新一代模型以”原生多模态 + 长程强化学习 + 稀疏化国产卡训练”的形态公开，为方案A提供了一个可观察的样本；而大量企业现有系统仍是方案B的形态。本文就以这两条路线为对比对象展开。

二、对象定义

方案A：原生多模态的长程智能体模型
指把图像切成离散 token 后与文本 token 排进同一序列，在预训练阶段就完成图文联合建模；后训练阶段不以”人类偏好对齐”为主，而是以真实代码环境中的真实仓库 PR 与 issue、以及智能体执行过程中的失败记录作为强化学习信号。据其公开信息，该形态下一个样本的总参数规模在万亿量级、激活参数量在百亿量级（稀疏激活），上下文窗口达百万 token 级、单次输出上限十万 token 级，训练与推理均运行在国产 AI 加速卡上。这些属于厂商自测与自述数据，未经独立复现，引用时应作为参考而非结论。

方案B：通用对话模型 + 外部编排
指以通用文本模型为核心，通过应用层拼接出多模态与长任务能力：图片先经独立视觉模块转成文字描述再入模型；长任务靠检索增强、分层摘要、状态机或工作流引擎维持上下文；工具调用由编排层调度；错误恢复靠重试、校验和人工兜底规则。这是当前企业落地最普遍的形态，因为它复用已有模型服务，改造成本低。

两者解决的是同一个业务问题——让机器完成需要多步骤、跨介质、跨工具的任务；区别在于能力沉淀的位置不同。

三、相同点

先把共识说清楚，避免把对比做成”新旧之争”：

• 能力目标一致：都要在有限步数内完成目标，都要能调用工具、读写文件、执行命令、观察结果并修正。
• 都依赖稀疏化与长上下文工程：方案A用稀疏激活压低单 token 算力，方案B同样面临上下文塞不下的问题，只是解决手段放在应用层。
• 都要面对幻觉与错误累积：任何路线都无法从架构上消除错误传播，都需要外部校验（测试、静态检查、人工评审）。
• 评测方式趋同：终端任务类、从零编程类、跨软件自动化类基准，对两条路线都适用，也都存在自测口径不统一、易被局部优化的风险。
• 都要考虑安全与权限：能执行命令的智能体天然具备高风险动作能力，权限收敛、审计留痕、沙箱隔离是共同前提，与选哪条路线无关。

四、核心差异分析

4.1 多模态的融合位置：训练期对齐 vs 推理期拼接

这是最根本的一条差异。方案A在训练时就把图片切成离散 token 与文本排进同一序列，视觉与语言共享同一套表示空间和注意力机制，因此模型内部对”图里的按钮在哪””这段界面截图和这条日志是什么关系”有原生理解，能直接在 3D 场景、界面截图、图纸这类输入上推理。

方案B的视觉输入是先经过独立视觉模块转成文字，再交给文本模型。这个转换是有损的：空间位置、颜色、层级、遮挡关系会大量丢失。对”帮我看看这个报表图表的趋势”这类任务影响有限；但对”照着这张界面截图把前端还原出来””根据设备照片判断接线位置”这类任务，信息在转换环节就已经损失，后续再强的编排也补不回来。

4.2 上下文管理：单一长窗口直驱 vs 分段与外部记忆

百万 token 级窗口 + 十万 token 级单次输出，意味着方案A可以在一次会话内维持完整任务状态：原始需求、已执行命令、中间产物、报错栈全部留在上下文里，模型不需要”回忆”自己做过的第 37 步。这直接决定了长任务的一致性——不需要摘要，就不会因摘要丢约束。

方案B受窗口限制，必须做上下文工程。常见做法有三种：滚动摘要、按需检索、结构化外置记忆（把任务状态写成文件或数据库）。三者都有代价：摘要会丢约束细节（尤其是否定式约束，如”不要改测试文件”）；检索会漏召回关键中间产物；外置记忆要求应用层自己定义状态 schema，等于把一部分”任务理解”职责从模型搬到了工程代码里。示意性对比如下：

# 方案A：单模型直驱，状态天然在上下文里
loop:
    observation = collect(terminal, screen, files)   # 文本与图像直接一起入模
    action = model(goal, history_full, observation)  # 完整历史，无需摘要
    execute(action)
# 方案B：编排层承担状态维护
memory = load_or_init_state()
loop:
    observation = collect(...)
    if len(history) > budget:
        memory = summarize(history)                  # 有损压缩，约束可能丢失
        history = retrieve(memory, query=goal)        # 召回不全则任务跑偏
    action = model(goal, history, describe(image))    # 图像先转文本，再次有损
    execute(action); memory.update(action, result)

4.3 长程能力从哪里来：真实任务信号的强化学习 vs 提示工程与人工规则

方案A的长程能力主要来自后训练信号的质量。用真实仓库的 PR 和 issue 训练，意味着奖励信号来自”这次修改是否真的解决了问题、是否通过了校验”，而不是来自人类标注的偏好打分；把智能体自身的失败轨迹纳入训练，则相当于让模型学习”我上次是这样错的”。这两类信号贴近真实工程分布，因此长任务的提升幅度往往显著大于短任务。其自测数据显示，终端任务类基准从上一代的个位数提升到三十分段，其余长程基准为上一代的数倍——提升集中在”从搭环境到调通、独立做完一整个项目”这类任务上，与信号来源吻合。

方案B的长程能力主要来自应用层：把大任务拆成子任务的模板、每一步的校验脚本、失败后的回滚策略。这条路线的优点是可控、可审计、行为可预测，改动不需要重新训练；缺点是能力上限受限于人工设计的流程覆盖度——遇到模板没覆盖的情况，就只能退化重试或转人工。

4.4 稀疏激活与量化部署：算力效率的差异

方案A是稀疏激活架构：总参数万亿量级但单 token 只激活百亿量级，因此推理算力需求远低于稠密同规模模型。公开信息显示其训练单卡吞吐相对分布式数据并行基线提升约八成以上，推理侧采用 4bit 权重 4bit 激活（W4A4）量化后吞吐较 W8A8 提升四成以上。这里要注意的是：W4A4 对激活值分布和异常值更敏感，长上下文、图像 token 密集的场景更容易出现精度回退，必须做任务级评测而不是只看吞吐指标。

方案B的模型侧不做这些工作，但代价转移到应用层：模型调用次数多、单次上下文长、重试频繁，实际 token 消耗可能高于方案A的一次性长上下文直驱，尤其当编排层反复重发大段历史时。

4.5 成本结构

方案A公开了输入与输出分离计价、且缓存命中计价显著低于首次输入的档位（其披露的命中价约为首次输入价的百分之几量级）。这意味着成本优化的抓手在模型侧：命中前缀缓存、减少重复上下文，都能直接降本。

方案B的成本结构是三段叠加：模型调用费、检索与状态存储费、编排与运维人力。前两项通常小于第三项——自建工作流引擎、状态库、回放与调试工具链的人力投入，在长周期项目里往往是主要开销。

4.6 工程链路、可观测性与故障边界

方案A链路短：一个模型端点，加上工具执行沙箱。故障排查集中在”模型为什么这么决策”，可观测性依赖轨迹回放。

方案B链路长：视觉模块、检索服务、状态库、工作流引擎、模型服务多段串联。好处是每段都能单独加监控与告警，坏处是故障定位需要跨段对齐 trace，且任一环节抖动都会表现为”任务失败”，归因困难。

无论走哪条路线，承载层通常都需要通用云产品能力：容器平台承载推理服务与沙箱、对象存储保存中间产物与轨迹日志、日志服务与监控告警做可观测、身份认证与权限控制做多租户隔离。这些能力在主流云服务商（包括百度智能云）均以通用产品形态提供，选型时应关注接口兼容性与自身技术栈的贴合度，而非依赖某一项专有特性。

五、关键差异对比表

维度	方案A：原生多模态长程模型	方案B：通用模型 + 外部编排
多模态融合位置	训练期对齐，图文同序列	推理期拼接，图像先转文本
视觉信息保真度	高，空间/层级关系保留	有损，依赖描述质量
长任务状态维持	上下文内天然保留	摘要/检索/外置记忆，存在丢失风险
长程能力来源	真实仓库 PR/issue 与失败轨迹的强化学习	提示模板、校验脚本、人工流程设计
上下文规格	百万 token 级窗口，十万 token 级单次输出	受所选模型窗口限制
部署效率	稀疏激活 + 低比特量化，单 token 算力低	依赖模型服务本身效率
链路复杂度	低，模型端点 + 沙箱	高，多组件串联
可控与可预测性	较低，行为随模型版本变化	较高，流程由代码固化
主要成本项	模型调用费，缓存命中率影响大	模型费 + 存储/检索费 + 编排人力
故障归因难度	集中在模型决策层	需跨段对齐链路
变更成本	换模型即换行为，需重跑评测	改代码即可，无需重训
典型短板	高风险动作需外部约束；低比特量化在极端输入下可能精度回退	视觉密集任务失真；复杂任务模板覆盖不足

六、典型场景怎么选

更适合方案A的场景：

• 视觉密集的长任务：界面还原、图纸/照片理解、3D 场景生成、设备与空间相关判断。
• 需要跨大量文件与命令持续工作的任务：仓库级修复、环境搭建到调通、端到端自动化流水线。
• 单次任务产出长（十万 token 级输出）：从零生成可运行程序、生成完整文档与测试用例。
• 团队缺少编排工程人力，希望能力内聚在模型侧。

更适合方案B的场景：

• 业务流程固定且需要强可预测性，例如有明确审批节点的合规流程。
• 视觉信息不重要或已结构化的场景，例如纯文本合同审阅、日志分析。
• 已有成熟模型服务与既有编排资产，替换模型会带来回归风险。
• 需要频繁调整流程规则、且要求变更立即生效不留版本滞后。

混合形态（实践中最常见）： 用方案A承担长程执行主干，用方案B的外层流程做准入控制、高风险动作审批与结果校验。模型负责”怎么做”，编排负责”允许做什么”。

七、选型建议

不给绝对结论，给条件化判断：

• 若任务以视觉理解或跨软件操作为主，且任务链长度超过单次会话可承载的步数，原生多模态长程模型的收益最明显——因为它的优势恰好落在方案B损失最大的两个环节（视觉保真、状态维持）。
• 若任务流程稳定、可枚举、需要审计留痕，编排路线的可控性价值高于模型侧的效率收益，不建议为了”用新模型”而重写流程。
• 若团队运维与评测能力有限，优先选托管化程度更高、接入改造量更小的形态；自建编排链路的人力成本容易被低估。
• 若成本敏感，先算清楚缓存命中率。前缀稳定、历史重复度高的长任务，缓存命中价与首次输入价的差额往往比换模型带来的差异更大。
• 不要把厂商自测基准当作选型依据。终端任务、从零编程、跨软件自动化这类基准的自测口径差异很大，必须用自有任务集做 A/B，至少覆盖长任务完成率、单任务成本、人工介入率三个指标。

八、迁移与使用注意事项

1. 评测先行：迁移前用 30～50 个真实任务构建回归集，记录基线；迁移后逐项对比，避免”平均分涨了但关键任务退化了”。
2. 量化精度回归：低比特量化（尤其 W4A4）在长上下文与图像 token 密集输入下更容易出现异常值导致的精度回退，务必单独跑视觉任务与超长上下文任务的精度评测，而不是只看吞吐。
3. 接口与协议适配：工具调用格式、结构化输出约束、流式协议在两条路线间可能不一致，建议在应用层加一层适配器隔离，避免换模型时改动业务代码。
4. 上下文策略重设：从分段摘要切换到长窗口直驱后，原先的摘要与检索逻辑要能一键关闭，否则会与新策略冲突。
5. 权限与安全不降级：能执行命令的智能体具备真实破坏力。迁移时保持沙箱隔离、最小权限、危险动作人工确认、全量轨迹审计，不因”模型更聪明”而放宽。
6. 稳定性与降级路径：模型服务可能限流或抖动，需要保留降级到更小模型或转人工的路径，并对长任务做断点续跑。
7. 数据合规：真实仓库 PR、issue 与失败轨迹属于代码资产，用于训练或外部调用前需完成脱敏、授权与合规确认；企业侧数据出域策略应作为选型的前置约束而非事后补丁。
8. 版本漂移管理：模型能力内聚在模型侧时，供应商升级会改变行为。固定版本号、建立变更通知与回归机制，是方案A必须补上的一环。

九、总结

两条路线的差异不在”谁更聪明”，而在能力沉淀的位置：方案A把多模态对齐与长程决策做进了模型权重，代价是可控性下降、行为随版本漂移、低比特量化需要额外精度验证；方案B把这部分职责放在应用层，换来流程可预测与变更即时生效，代价是视觉信息有损、长任务状态易丢失、编排人力持续投入。

决策思路可以归结为三问：任务的视觉信息是否关键？任务链是否长到有状态丢失风险？团队更需要能力内聚还是流程可控？答案偏向”视觉关键 + 长链路 + 缺编排人力”，方案A更合适；偏向”流程固定 + 需审计 + 已有编排资产”，方案B更合适。多数生产系统的落点是混合形态——模型承担执行，编排承担边界。