MiCo发布一个月，开源社区把它接进了哪些Agent框架

从一篇论文到一个工具调用对象

6月中旬，上海AI实验室把MiCo（Multimodal Context）的预训练权重和推理代码一并推上了Hugging Face和GitHub。根据量子位和腾讯云开发者社区的报道，MiCo在发布同期就拿下了37项多模态SOTA，覆盖图像、视频、音频和文本四路输入（量子位2024年6月16日报道、腾讯云开发者社区）。

一个月过去，社区对它的兴趣点已经从"能不能跑通"转到"怎么塞进Agent".下面是我们盘点到的几条主线接入路径，以及一份可以照搬的工具调用模板。

书生万象3.0与MiCo的协同定位

在聊Agent接入之前，有必要先说清楚MiCo和书生·万象的关系。书生·万象3.0把文本和视觉拉进同一个预训练阶段，MiCo则继续往前推一步，把视频和音频也纳入训练上下文。我们在《书生·万象3.0与MiCo，把多模态融合提前了》一文里讨论过这个时间点前移的意义，但对开发者来说更实际的问题是——接入MiCo时，是直接在Agent里换模型，还是用书生万象+MiCo做混合路由？

社区目前的倾向是混合路线：长文档、图表理解这类任务交给书生万象3.0，视频抽帧、音频转写交给MiCo。原因很简单，MiCo的4路输入在Agent节点里会显著抬高显存峰值，单独跑一段比四路同时开要省心得多。

在LangGraph里接入MiCo

LangGraph是目前我们看到接入MiCo最干净的一条路，因为它的节点抽象本身就是"模型+工具"。

一个常见写法是把MiCo封装成一个Tool，Agent在需要处理图像或视频帧时调用它，而不是把它设为默认LLM。具体代码片段大致是这样的：

from langgraph.graph import StateGraph
from langchain_core.tools import tool
import torch
from transformers import AutoModel, AutoProcessor

@tool
def mico_understand(media_path: str, prompt: str) -> str:
    """使用MiCo对图像、视频或音频做多模态理解。"""
    processor = AutoProcessor.from_pretrained("internlm/MiCo")
    model = AutoModel.from_pretrained("internlm/MiCo",
        trust_remote_code=True, torch_dtype=torch.bfloat16
    ).cuda()
    inputs = processor(media_path, prompt, return_tensors="pt").to("cuda")
    with torch.no_grad():
        output = model.generate(**inputs, max_new_tokens=512)
    return processor.decode(output[0], skip_special_tokens=True)

builder = StateGraph(dict)
builder.add_node("planner", planner_node)
builder.add_node("vision", mico_understand)
builder.add_edge("planner", "vision")

这样做的好处是MiCo只承担"视觉/听觉工种"，上下文长度可控，不会因为一段长视频把对话历史挤爆。LangGraph社区的开发者已经提交了对应的Tool wrapper，GitHub上搜索mico-langgraph可以看到一个还在迭代的实现。

Dify和Coze：低代码平台的接入更看配置

Dify和Coze这两条线，社区走的是另一套思路——把MiCo注册成外部模型，再通过工作流节点调用。

Dify侧的接入重点在推理服务部署。MiCo官方推荐先用vLLM起一个OpenAI兼容的推理端点，再在Dify的"模型提供商"里填上地址。Dify 1.x之后的版本已经支持自定义vision输入，可以直接传图片URL或base64。我们实测时遇到的第一个坑是：MiCo默认的最大序列长度比纯文本模型大不少，Dify的请求超时和上下文窗口是分开计的，超时设短了会切掉短视频片段。

Coze这边的情况类似，但因为Coze工作流节点对媒体类型的限制更细，需要先把视频切片成帧序列再传。社区的做法是用FFmpeg预处理，每秒抽1帧，然后按10帧一组打包上传。这套流程如果直接给Agent自己调度会很慢，建议在Coze里做成"前置预处理节点"，把视觉理解这一步做成纯函数。

CrewAI和AutoGen：多智能体协作的显存账

CrewAI和AutoGen里接MiCo，坑主要在多Agent协作时的显存占用。我们记录了一次真实排错过程：

一个4 Agent的crew里，两个Agent都被配置为"可调用MiCo进行视觉理解"。RTX 4090 24GB单卡，跑起来之后发现两个Agent串行调用时MiCo还能稳在18GB以内，但只要其中一个Agent把视频长度传到了2分钟以上（大约1200帧），显存立刻冲到23GB以上，把另一个Agent挤掉。

解决方法是显式约束MiCo节点的最大帧数。MiCo自带一个max_frames参数，社区工具里默认开的比较激进（针对长视频优化），我们改成max_frames=64后，显存掉到12GB，另一个Agent也能正常排队。

如果你在三模型路由里跑Agent，可以参考《Agent 选型别押一家，三模型路由怎么搭》的思路，把MiCo作为视觉/音频专才独立成一个路由槽位，而不是塞进主模型。

一次坑点记录：MCP接入时的工具描述粒度

Anthropic的MCP协议（MCP，Multi-Call Protocol）正在成为Agent工具调用的事实标准（OpenCSG活动页）。我们把MiCo包成MCP Server后，遇到的第一个问题不是协议本身，而是工具描述的粒度。

MiCo的输入可以是"图+问"，也可以是"视频+问"，还可以是"音频+问"。最初我们只写了一个mcp_mico_understand工具，描述里塞了所有支持的媒体类型。结果Agent在调度时频繁误判——把纯文本问题也丢给MiCo，浪费一次推理。

拆成三个Tool（mico_image、mico_video、mico_audio）之后，误调用率明显下降。这条经验在《从Claude 4到Qwen3，Agent开发者的工具调用实战手册》里也有类似结论：工具描述不能图省事，写得越具体，Agent调度越准。

接入清单与下一步

把目前社区能看到的状态做个总结：

• LangGraph：Tool封装路线最稳定，适合把MiCo当作视觉/听觉工人。
• Dify：需要先部署vLLM推理服务，注意超时和上下文窗口分开配。
• Coze：视频抽帧前置到工作流节点，避免Agent自己调度慢。
• CrewAI/AutoGen：多Agent协作时，强制约束max_frames，否则显存账很难看。
• MCP：工具按模态拆细，描述写清楚输入约束。

Agent上下文的计费和监控也是这一阶段的痛点，《模型上下文太长扯不清账，三套Agent计费监控开源脚本》里给出的TELOS SDK、AgentMemory等方案，可以直接接进这套多模态Agent流水线做Token流向监控。

如果你正在赶WAIC 2026后的多模态集成窗口期，建议先把MiCo当作一个"专才节点"放进现有Agent系统，而不是直接替换主模型。一个月下来，这条路是社区验证下来坑最少、上手最快的。