背景
本来不想写这个，刚出来我看了，没啥特色值得使用的功能，朋友给我分享别人写的dify1.8.0更新的文章，问我对dify1.8.0更新的功能怎么看，我看了一下，完全是大模型生成的模型，而且把更新内容都曲解了，容易误导用户，而且没有一点实操性。
本次更新内容
• 多模型凭证管理 • MCP 整合OAuth • 工作流变量支持默认值 • Agent 节点令牌用量统计 • 知识库文档排序（文档状态检索） • 性能与基础设施
升级
# 备份
cd docker
cp docker-compose.yaml docker-compose.yaml.$(date +%s).bak
# 修改docker-comose.yaml中的版本
langgenius/dify-api:1.8.0
langgenius/dify-web:1.8.0
# 停止服务并清除容器
docker compose down
# 启动服务
docker compose up -d需要注意的是，升级以后会出现内部服务异常，接口500，直接进入到api服务里，在
/app/api目录中执行下uv run flask db upgrade即可。
新功能
多模型管理支持
具体表现在如上图：
• 点 1在模型的配置中• 可以通过 2编辑原有的key配置• 也可以通过 3添加api密钥
当有多个key的时候，默认只有一个key生效。
在设置默认模型的是，没有选项，底层肯定是根据选中的模型路由。如果想做模型路由，修改获取租户模型的方法即可。
mcp 支持 OAuth
果然如猜测那般，添加以后直接授权。
start节点支持默认值
在start的节点中，支持设置默认值。方便后续的管理使用
Agent 节点令牌用量统计
此前 Agent 节点把 所有 token 都算进了 completion，导致监控与成本数据失真；甚至部分场景显示为 0。v1.8.0 修复后，输入（prompt）与输出（completion）分开计数。
知识库文档排序（文档状态检索）
按官方的说法，升级以后支持文档状态排序，实际测试中并没有后看到状态的排序。到是看到了根据文档状态检索的功能。
性能与基础设施
之前 Dify 的 工作流执行（WorkflowRun / WorkflowNodeRun） 是基于同步阻塞的Repository实现的。 这意味着：
• 每个节点执行时，数据库写入/读取必须等待完成，才能继续下一个节点。 • 在包含多个节点、并行分支的复杂工作流中，瓶颈明显（尤其是 I/O 等待）。
新版本改为了 Async Repositories
• Dify 在 WorkflowRun和WorkflowNodeRun层面引入了 异步非阻塞存储，大幅减少数据库访问对执行主流程的阻塞。• 在流程运行时，不需要每一步都等数据库写入确认，很多操作可以“边跑边写”，或者通过异步队列/调度机制延迟处理。
