一周AI大模型与Agent进展：机器人推理、视频生成与部署实战盘点

周五下午，我把这周社区里刷屏的AI大模型和Agent相关讨论又翻了一遍，挑出16个值得看一眼的新进展。它们从机器人推理一路铺到视频生成，跨度不小，但有一个共同点：都在解决“从演示到能用”之间的那一段距离。不管是做算法、做产品还是做内容，这篇文章能帮你快速确认哪些东西值得跟进、哪些只是热闹。下面的内容我会按四个方向展开：机器人推理与具身智能、Agent开发工具链、视频生成与多模态、模型部署与垂直场景落地，最后把这一周最容易踩的坑一起列出来。

1. 一周值得关注的AI进展：先看全景

先说结论：这一周的新东西里，真正值得花时间动手试的其实没那么多。16个进展听起来很多，但大部分是同一类能力的延伸，真正算得上“方向级”变化的，集中在三个地方。

第一是机器人推理。过去我们谈机器人控制，更多是“感知+规划+执行”的老三段，现在大模型直接参与闭环推理，让机器人能根据环境反馈调整动作，这在以前是很难想象的。这不是概念，这一周已经有开源项目把这一步跑通了，后面我会展开讲。

第二是Agent的工具链成熟度。上半年大家还在讨论Agent是不是炒作，这周的开源框架、编排工具、调试手段明显上了一个台阶。最直观的表现是：Agent执行出错的报错信息开始变得可读，排查一套完整链路不再像大海捞针。这个变化是无声的，但对做工程的人非常重要。

第三是视频生成从“玩具”走向“生产力”。2K分辨率、多镜头一致性、可控帧生成，这些词这周反复出现。免费入口和开源工具也越来越多了，门槛在快速下降。

我把这16个新进展按这四个方向做了归类，下面每个方向挑几个重点展开，每个进展我都会说明它解决什么问题、适合谁用、实际跑起来要注意什么。

2. 机器人推理与智能体边界：从环境感知到长期记忆

2.1 Pi Agent：机器人推理系统的“开箱”体验

这一周机器人推理方向热度最高的是Pi Agent相关的一批项目。它做的事情说起来很简单：让机器人不只会执行固定动作序列，而是能拿着传感器数据、环境地图、任务描述，在模型内部完成推理，再输出控制指令。过去这类系统要自己拼视觉模块、控制模块、规划模块，现在模型把这几步压缩进了端到端的推理过程。

我看了几个复现帖，普遍反馈是“第一次跑起来的感受很震撼”。机器人面对突然出现的障碍物，不再需要预编程的避障逻辑，而是靠多模态推理临时决定绕行路线。这种能力的价值在于，它把“泛化”从实验室带到了真实场景。

但这东西现阶段不是拿来就能用的。一个有代表性的坑：实物机器人和仿真环境的动作空间差异很大，同一个模型在MuJoCo里表现完美，换到真机上会因为关节延迟出现累积误差。我的建议是，先跑通官方Demo，再逐步替换真实传感器数据，不要一上来就指望它接管完整任务。

2.2 VLA模型与通用Agent的配合方式

Vision-Language-Action模型这段时间被讨论的频率明显上升。它本质上是把视觉、语言、动作三个模态整合进一个大模型，机器人看到一个场景，理解指令，直接输出动作。VLA和通用Agent的配合方式，这周讨论出的一个共识是：不要让VLA什么都干，而是让它作为“底层执行器”，上层由Agent负责任务拆解和状态管理。

例如一个清理桌面的任务，上层Agent先判断“桌面有哪些物品、分别该放哪”，VLA模型再负责“手怎么伸过去、握力怎么控制”。这种分层设计的好处是，任务规划出错时只需要修上层逻辑，不需要重新训练运动控制部分。

实操时要注意动作空间的定义。不同机器人厂商的关节限位、速度上限都不一致，跨平台迁移VLA时，动作头的标准化比模型结构本身更影响复现效果。我见过有人换了机械臂型号之后，模型输出动作直接打到关节限位，排查了半天才发现是动作空间没做缩放。

2.3 仿真到真机迁移：机器人推理的训练与评测

机器人推理方向的第三个新进展，是仿真到真机迁移的工具链终于有了一套相对完整的评测体系。以前大家各自用不同的仿真环境，结果没法横向对比。这周几个开源项目开始统一评测标准，包括任务成功率、平均完成步数、真机部署耗时这些指标。

这里我要多说一句：仿真环境里的成绩要打折扣看。光照变化、物体材质差异、电机响应延迟，这三个变量在sim里经常被忽略，到了真机上却是致命的。我见过一个抓取任务，仿真成功率98%，真机只有67%，差距基本都出在这三个地方。

建议的做法是领域随机化。在仿真里随机改变物体位置、光照角度、纹理贴图，让模型见过足够多的变化，再上真机。这一周看到有团队把随机化参数调得特别激进，真机成功率反而上去了，因为模型学会了关注真正的关键特征，而不是过拟合某个固定的场景。

2.4 长期记忆与规划分离：具身智能的架构取舍

具身智能方向的最后一个重点，是长期记忆和任务规划的架构分离。过去Agent的记忆都塞在context里，长了就乱。这一周出现的方案开始把记忆模块外置，变成独立的向量检索库，机器人需要的时候才去查，不需要的时候不占用推理空间。

这套架构对机器人场景格外重要。一个清洁机器人如果要在办公楼里连续工作一周，它需要记住“会议室周二下午通常没人”“茶水间门口有个台阶”这类长期信息，但又不能每次做决策都把这些信息全过一遍。检索式记忆刚好解决这个问题。

我试过类似思路：把记忆按场景切片，每个切片带时间戳，检索时按“当前任务+最近执行结果”做召回，效果比全量塞context稳定得多。要注意的是，记忆写入的时机很关键，写早了信息不全，写晚了又来不及影响决策，这块需要结合任务节奏调。

3. Agent开发工具链：框架选择、微调与落地

3.1 Harness与Agent的区别：别再混为一谈

这一周翻社区，我发现“Harness和Agent区别”成了高频问题，说明大家在选型时开始认真思考底层框架了。简单说，Harness是承载Agent运行的框架，负责工具调用、上下文管理、执行循环这些底层机制；Agent是里面真正做决策的那个智能体，它调用模型、解读结果、决定下一步动作。

用生活类比的话，Harness是厨房的操作台和水电气管道，Agent是拿着菜谱做菜的厨师。管道不通，厨师再厉害也没用；厨师不会做菜，管道再通畅也端不出菜来。工程上这俩经常被混在一起讨论，导致排查问题时定位不准。

实操建议是：遇到Agent执行结果不对，先分清楚是Harness层的问题还是Agent层的问题。工具调用参数传错了，属于Harness层；模型理解指令有偏差，属于Agent层。这一周我看到的报错里，有一大半其实是Harness层工具定义不严谨造成的，跟模型本身没关系。

3.2 开源Agent编排框架怎么选

Agent编排框架这周又多了几个新选项，加上之前的，现在市面上的开源方案可以归成三类。第一类是轻量级编排，适合快速验证想法，配置简单但功能有限；第二类是重量级框架，带完整的记忆、规划、工具管理模块，适合正式项目但有学习成本；第三类是可视化编排，拖拽节点就能串流程，适合非工程师团队用。

选择标准我给三条。第一看团队技术栈，Python团队和TypeScript团队选型完全不同；第二看工具生态，你需要调用的服务和已有框架的适配程度；第三看社区活跃度，这个周更新的框架和三个月更新一次的框架，坑的多少完全不是一个量级。

我不建议一上来就上重量级框架。先用轻量级方案跑通一个最小流程，确认Agent的行为逻辑符合预期，再迁移到正式框架。这周有团队从重量级框架退回轻量级，就是因为前期业务逻辑还没弄清楚，框架的限制反而成了瓶颈。

3.3 Hermes Agent：轻量级Agent外壳的语义接口

Hermes Agent这周在社区里的讨论度不低，它主打的是“语义接口”这个概念。传统Agent工具调用靠函数签名，参数名、类型、顺序都写死；Hermes Agent的做法是用自然语言描述工具能力和参数含义，让模型自己理解怎么调用。

这个方向我比较看好。它解决的问题很实际：工具多了之后，模型经常把相似功能的工具搞混，比如“发送邮件”和“发送消息”，参数明明差不多，但调用错一个就会出问题。语义接口相当于把工具的意图也喂给了模型，匹配准确率会高不少。

不过要注意，语义接口对模型能力要求更高。像GPT-4级别的大模型用起来很顺，换小参数模型就容易理解偏。如果你的Agent跑在7B、13B这类小模型上，建议还是保留结构化工具定义，别为了赶时髦全改成语义接口。

3.4 OpenCode：Agent工作流里的代码与视频生成联动

OpenCode这周的出现让我挺意外，它把代码生成和视频生成结合起来，形成了一个有趣的Agent工作流。具体来说，它可以读取你的工程代码，理解业务逻辑，然后根据代码运行结果生成对应的可视化视频。对做数据分析、产品演示、算法讲解的人来说，这个效率提升非常明显。

我试用的感受是：它能自动分析代码里的数据变化，把每个阶段的输出转成一帧画面，再串成视频。以前做算法效果展示，要写一遍视频渲染代码，现在直接让OpenCode从代码里理解上下文，省掉大量重复劳动。

但说句实话，它生成的视频风格还是偏工程化，艺术感就别奢求了。适合内部评审、技术汇报这类场景，拿去做宣传片还差得远。如果你有二次开发能力，可以改造它的渲染参数，能做出更定制化的效果。

3.5 大模型微调实战：LoRA、QLoRA与全参微调怎么选

这一周大模型微调的话题依然很热，特别是LoRA、QLoRA和全参微调的选型。我结合实战感受说一下。数据量在几万条以内，LoRA基本够用，训练快、显存占用低，效果和全参微调的差距也没有传说中那么大。数据量上了十万条还要追求更高效果，全参微调的优势才能明显体现出来。

QLoRA适合显卡不够的情况。简单说，它先把模型量化到4bit，再加一个低秩适配器训练，一张16G显存的卡就能微调7B模型。我试过用QLoRA微调7B模型，效果比LoRA稍好一点，因为它在较低精度下保留了更多原始参数信息。

这里有一个新手很容易犯的错误：微调数据质量比数量重要得多。5000条高质量数据往往能打过5万条从网上爬来的数据。这周看到好几个案例，数据量够了但没做清洗去重，模型不仅没变聪明，反而学到了重复样本里的偏见。数据预处理这一步，该花的功夫一分都不能省。

4. 视频生成与多模态：从可玩到可用的关键几步

4.1 ComfyUI生成视频：节点式工作流为什么值得学

ComfyUI这周的热度主要靠视频生成带起来的。以前大家用它做图，现在视频工作流也成熟了。节点式工作流的优势在于，它是可视化的管道思维，加载模型、编码文本、采样、解码、保存视频，每个环节都是一个节点，你可以随时插一个节点进去观测中间结果。

我第一次跑视频工作流时的感受是，它和用Stable Diffusion WebUI的体验完全不同。WebUI是黑盒，点一下按钮等结果；ComfyUI是把整个流程摊开给你看，哪里出了问题一眼就能定位。生成视频出现鬼影、闪烁，检查采样器参数就能解决大半问题。

上手建议：先别急着下载几十个自定义节点，用官方工作流跑通一遍，理解每个节点的作用，再逐步替换模型和调整参数。我见过太多人一上来就装一大堆节点，结果依赖冲突、版本不匹配，光排查环境就花了两天。

4.2 MiniMax视频生成：2K分辨率在不同显卡下的实测

MiniMax这周的2K视频生成能力和显卡适配问题讨论得非常多。我在自己的机器上跑了测试，也在群里对比了其他显卡的数据，发现不同显卡的差距主要体现在两个地方：编解码速度和采样速度。显存决定你能跑多大分辨率，算力决定你跑多快。

实测下来，8G显存是2K视频的门槛，低于这个配置基本不用想。16G显存可以在2K分辨率下流畅跑，但长视频依然吃紧。同一条提示词生成20秒视频，旗舰卡和入门卡的耗时差距能到三倍以上，而且越高分辨率的差距越明显。

如果你显卡不够但还想试，我有两个建议：一是降低帧率，从30fps降到24fps，生成速度能快不少；二是分段生成再拼接，这个方法特别适合没有大显存的用户，用16段2秒的片段拼出32秒视频，比一次生成32秒稳得多。

4.3 免费视频生成入口整理：先别急着付费

免费视频生成入口这周冒出来不少，我整理了一圈，发现真正能稳定用的其实就几个方向。第一类是产品官方的免费额度，注册就能用，但次数有限且排队严重；第二类是开源项目的在线Demo，免费用但功能往往不完整；第三类是社区分享的ComfyUI工作流加在线算力平台，效果上限高但需要一点技术基础。

我建议的顺序是：先用官方免费额度体验当前视频生成的上限，再玩开源模型本地跑，最后再考虑付费。这周有朋友直接买了一年会员，结果发现模型更新太快，一个季度前的收费标准就不划算了。视频生成的核心成本在算力，但模型快速迭代意味着你为算力支付的价格一直在变化。

免费和开源的差距主要在执行细节上。开源模型拟合度、运动幅度、镜头控制都需要自己去调，但效果天花板并不低，只要能接受调试成本，完全可以用免费方案做出不错的结果。

4.4 视频帧生成与开源模型选型

视频帧生成是本周多模态方向的一个亮点。它的思路是先抽关键帧让模型生成，再用帧插值模型把中间帧补上，这样能大幅减少生成计算量。同样生成一段10秒视频，全帧生成和关键帧加插值相比，耗时能减少一半以上，但流畅度会略受影响。

开源模型选型方面，现在分成两条路线：通用视频生成模型和专用帧插值模型。我做了一个简单对比。

通用模型适合做整段视频，一次性出片；帧插值模型适合已有素材做补帧，和关键帧生成配合能省大量算力。我现在的组合是：关键帧用生成模型出，中间帧用插值模型补，成片质量兼顾了效率和效果。

5. 大模型部署、端侧与垂类场景：真正跑起来的经验

5.1 Android端集成本地GGUF：手机也能跑大模型

这周Android App集成GGUF格式大模型的讨论很火。GGUF是把模型量化后打包的一种格式，用llama.cpp调用，可以在手机上跑7B甚至13B模型。我实际验证过，7B模型量化到Q4_K_M，在骁龙8系处理器上能流畅对话，速度虽然比不上云端，但胜在完全离线、隐私安全。

集成步骤不复杂：先把模型文件放到应用目录，再通过llama.cpp的Android版本加载，最后封装一个对话接口。要注意的是内存占用。7B模型Q4量化后文件约4G，加载进内存还要多出运行开销，低端手机会吃紧。建议先测你目标机型的可用内存，再决定模型尺寸。

另一个坑是模型文件的下载和版本管理。GGUF格式本身有版本兼容性，同一个模型用不同版本的工具链转换，推理结果可能有细微差异。我的建议是固定工具链版本，别频繁升级，否则用户端出现行为不一致时很难排查。

5.2 AMD显卡（RX 6750 GRE）跑大模型和视频生成的实测感受

AMD显卡在AI圈的待遇一直比较尴尬，这周RX 6750 GRE跑大模型的相关讨论让我觉得情况在变好。实测下来，用llama.cpp配合Vulkan后端，跑7B模型的速度已经可用了，虽然比同价位N卡慢一些，但没到不能接受的地步。我自己的体感是，日常对话完全没问题，速度比CPU快很多。

视频生成方面，RX 6750 GRE的表现更复杂。ComfyUI配合AMD显卡需要额外配置，很多工作流默认用CUDA，你得手动换成Vulkan或者DirectML后端。一旦配置好，生成速度还是可以的，和N卡的主要差距在兼容性和生态支持。

如果你正在用A卡做AI，我给三个建议：一是优先选择支持Vulkan的软件框架，llama.cpp、ComfyUI都可以；二是不要迷信某些转换层工具，稳定性和性能提升没有宣传的那么大；三是显存带宽对A卡更重要，6750 GRE的显存配置决定了它在AI任务上的上限。

5.3 科研写作与专利辅助：垂直场景里的Prompt工程

科研写作和专利辅助是这周被问到最多的垂直场景。用大模型辅助写论文、处理专利文档，确实能大幅提升效率，但前提是方法得当。我看到不少失败案例，都是直接把摘要丢给模型让它写全文，结果胡编乱造，这种用法在科研场景里风险极大。

正确的做法是分步骤用。检索文献用大模型做语义匹配，初稿用大模型生成框架，润色时用大模型改句子逻辑，但每个环节都必须有人工审核。专利辅助更要注意合规，专利涉及技术交底书撰写、对比文件检索、权利要求书描述，这些都是有严格格式和质量要求的。

我推荐的做法是：把大模型当成聪明的实习生，让它做前期的信息整理、格式规范、语言润色，让人类的专业判断做最终决策。这周看到一个朋友用大模型生成技术交底书的初稿，效率提升了一倍，但他还是花了大量时间核对技术细节。这才是正确的使用姿态。

5.4 免费API与本地部署的取舍清单

免费大模型API和本地部署，这两种方案的取舍这周被讨论得很充分。我列了一张对比清单帮大家选型。

我的建议是：数据敏感程度决定选择。测试功能、玩一玩用免费API没问题，但涉及隐私数据、业务数据的场景，还是本地部署更稳妥。本地部署的成本没想象中高，16G内存加一张8G显存的显卡，跑7B量化模型就足够了。

一个容易被忽略的细节是API的限流策略。有些平台免费额度看着多，但并发限制非常严格，调用稍频繁就报错。做产品之前一定要做好限流适配，否则上线后总要给用户道歉。我见过一个团队上线第一天API就被限流，原因是没看文档里的每分钟调用上限。

6. 这周上手时最容易踩的坑

6.1 显存不够：量化、卸载与投机采样三板斧

显存不够是这周被问得最多的问题，尤其是想本地跑大模型但显卡只有8G、6G的用户。我总结下来就三板斧。第一板斧是量化，Q4_K_M是品质和占用最平衡的选择，比FP16直接少一半还多的显存占用；第二板斧是层卸载，把一部分模型层留到CPU算，牺牲一点速度换容量；第三板斧是投机采样，小模型草拟大模型验证，实际生成速度能提升不少。

这三板斧的顺序很重要。先量化，解决显存容量问题；再层卸载，解决稍大模型跑不动的问题；最后投机采样，解决速度问题。我看到很多人一上来就用投机采样，结果显存不够直接报错。

还有一个隐藏优化是上下文窗口。别一味追求长上下文，它比想象中更吃显存。如果你的任务场景不需要一万个token的上下文，调小一点能省下大量显存，速度也能上去。

6.2 Agent报错：execution terminated due to error排查

这周很多人遇到“Agent execution terminated due to error”这类报错，其实是Agent执行循环被中断的通用提示。报错信息本身没给出具体原因，需要逐层排查。我总结了一套排查顺序：先看工具调用参数是否有误，再看上下文是否超过模型限制，最后看是不是外部服务超时。

工具调用参数错误是最常见的原因。函数定义里的参数名和模型生成的不一致，或者必填参数没填，Agent就会终止执行。排查方法是在Harness层加日志，把模型生成的工具调用原始输出打出来，一眼就能看出问题。

上下文超限和外部服务超时排在后面，因为它们的报错信息更明确一些。这里有个实操技巧：给Agent加上自动截断机制，当上下文快到限制时自动压缩旧对话，能减少很多无谓的执行终止。

6.3 视频生成爆内存：分辨率、帧数与显存管理

视频生成爆内存几乎是每个玩过的人都会遇到的。这一天最常见的场景是：明明跑图没问题，视频一跑就崩。原因在于视频生成要同时在显存里放多个帧的隐空间张量，占用是图片生成的几倍。

控制方式有三个维度：分辨率、帧数、批次大小。先降分辨率到512以下测试，再降帧数，最后调小批次，三个都压到最低还爆，就只能换量化版模型或者减少模型副件了。我见过最极端的情况是8G显存硬生生跑了1080P视频，方法是逐帧生成加上CPU内存辅助，速度很慢但确实能跑。

这里有个经验之谈：视频生成不像图片生成，爆内存往往发生在采样的中期，所以测试时不能只看加载模型阶段的显存占用，要跑完一段短视频再判断。

6.4 微调完没效果的检查清单

微调完模型没效果，是这周另一个高频问题。我整理了一张检查清单，按顺序过一遍基本能找到原因。

第一，检查训练损失是否真的下降。如果训练集损失都没降，问题出在训练设置；如果训练集降了但验证集没降，问题出在过拟合。

第二，检查数据格式和任务是否匹配。很多模型在微调时需要特定的指令格式，格式错了模型学到的都是噪音。

第三，检查基座模型选择。同参数量的基座模型本身能力差异很大，换一个能力更强的基座往往比微调更有用。

第四，检查评估方式。直接问“效果变好了吗”很难得到客观结论，我建议设计几个固定的测试用例，微调前后跑一遍对比，才看得出真实变化。

这周我看到的最典型失败案例，是有人微调了一个7B模型花了整整两天，最后发现损失曲线一直没降，排查半天是学习率设置太高直接震荡了。先小规模跑几步确认训练流程正常，再全量训练，能救你很多时间。

这周我盯着那台跑微调的机器时，最深的感受是：AI大模型和Agent的进展越来越快，但真正能落到你工作流里的，往往不是最热门的那一个。16个新进展里，找到一个解决你当下问题的，就值回这一周的时间。先跑通最小的例子，再考虑扩展，这个节奏不管在哪个方向都不会错。