编程笔记

lifelong learning & practice makes perfect

上一篇我们介绍了MCP的架构:C/S架构,主要是客户端和服务端,下面我们学习下如何使用Claude提供的以及一些开源MCP服务端.

主要在vscode插件中使用,这里以Continue/Cline为例,以上的服务端区别于传统互联网服务端,需要安装在本地,目前大部分通过npx或python pip使用,暂不支持远程服务端

Continue

配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// ~/.continue/config.json
{
"experimental": {
"modelContextProtocolServers": [
{
"transport": {
"type": "stdio",
"command": "uvx",
"args": ["mcp-server-sqlite", "--db-path", "/Users/NAME/test.db"]
}
}
]
}
}

Cline

使用效果如下,这里调用官方的everything服务端中的printEnv工具输出环境变量

使用效果

配置

配置

1
2
3
4
5
6
7
8
9
10
11
{
"mcpServers": {
"everything": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-everything"
]
}
}
}

参考

这段 2009 年的旧视频最近在 Twitter 上疯传。它旨在让观众直观地了解 CPU 和 GPU 之间的区别。

你可以在这里观看,时长 90 秒:

视频

这个想法是,CPU 和 GPU 在绘画决斗中正面交锋。
CPU 花了整整 30 秒才画出一个非常基本的笑脸:

图像 15

然后 GPU 瞬间画出了蒙娜丽莎:

图像 16

从这段视频中可以得出一个结论:CPU 速度慢,而 GPU 速度快。虽然这是事实,但其中有很多视频没有给出的细微差别。

当我们说 GPU 的性能比 CPU 高得多时,我们指的是一个名为 TFLOPS 的指标,它本质上衡量的是处理器在一秒内可以执行多少万亿次的数学运算。例如,Nvidia A100 GPU 可以执行 9.7 TFLOPS(每秒 9.7 万亿次运算),而最近的 Intel 24 核处理器可以执行 0.33 TFLOPS。这意味着一个中等水平的 GPU 至少比最强大的 CPU 快 30 倍。

但是我的 MacBook 中的芯片(Apple M3 芯片)包含 CPU 和 GPU。为什么?我们不能直接抛弃这些速度慢得可怕的 CPU 吗?

让我们定义两种类型的程序:顺序程序 和 _并行程序_。

顺序程序 是指所有指令必须一个接一个运行的程序。以下是一个示例。

1
2
3
4
5
6
7
8
9
def sequential_calculation():
a = 0
b = 1

for _ in range(100):

a, b = b, a + b

return b

在这里,我们连续 100 次使用前两个数字计算下一个数字。这个程序的重要特性是每个步骤都依赖于它之前的两个步骤。如果你要手动进行此计算,你不能告诉朋友,“你计算第 51 步到第 100 步,而我从第 1 步开始”,因为他们需要第 49 步和第 50 步的结果才能开始计算第 51 步。每个步骤都需要知道序列中前面的两个数字。

并行程序 是指可以同时执行多个指令的程序,因为它们不依赖于彼此的结果。以下是一个示例:

1
2
3
4
5
6
7
8
def parallel_multiply():
numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
results = []

for n in numbers:
results.append(n * 2)

return results

在这种情况下,我们进行十次完全独立的乘法运算。重要的是顺序无关紧要。如果你想和朋友分担工作,你可以说,“你乘以奇数,而我乘以偶数。”你可以单独且同时工作并获得准确的结果。

实际上,这种划分是一种错误的二分法。大多数大型实际应用程序都包含顺序代码和并行代码的混合。事实上,每个程序都会有一部分指令是_可并行化的_。

例如,假设我们有一个程序运行 20 次计算。前 10 个是必须按顺序计算的斐波那契数,但后面的 10 个计算可以并行运行。我们会说这个程序是“50% 可并行化的”,因为一半的指令可以独立完成。为了说明这一点:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
def half_parallelizeable():
# Part 1: Sequential Fibonacci calculation
a, b = 0, 1
fibonacci_list = [a, b]
for _ in range(8): # Calculate 8 more numbers
a, b = b, a + b
fibonacci_list.append(b)

# Part 2: Each step is independent
parallel_results = []
for n in fibonacci_list:
parallel_results.append(n * 2)

return fibonacci_list, parallel_results

前半部分必须是顺序的 - 每个斐波那契数都依赖于它之前的两个数。但是后半部分可以获取完整的列表并独立地将每个数字加倍。

你不能在没有先计算出第 6 个和第 7 个数字的情况下计算出第 8 个斐波那契数,但是一旦你有了完整的序列,你就可以将加倍操作分配给尽可能多的可用工作者。

总的来说,CPU 更适合_顺序程序_,而 GPU 更适合_并行程序_。这是因为 CPU 和 GPU 的基本设计差异。

CPU 具有少量的大型核心(Apple 的 M3 具有 8 核 CPU),而 GPU 具有许多小型核心(Nvidia 的 H100 GPU 具有数千个核心)。

这就是为什么 GPU 非常适合运行高度并行的程序 - 它们有数千个简单的核心,可以同时对不同的数据片段执行相同的操作。

渲染视频游戏图形是一个需要许多简单重复计算的应用程序。想象一下你的视频游戏屏幕是一个巨大的像素矩阵。当你突然将你的角色向右转时,所有这些像素都需要重新计算为新的颜色值。幸运的是,屏幕顶部的像素的计算与屏幕底部的像素的计算是独立的。因此,计算可以分布在 GPU 的数千个核心中。这就是为什么 GPU 对于游戏如此重要。

在矩阵乘以 10,000 个独立数字等高度并行任务中,CPU 比 GPU 慢得多。然而,它们擅长复杂的顺序处理和复杂的决策。

将 CPU 核心想象成一家繁忙餐厅厨房里的主厨。这位厨师可以:

  • 当一位 VIP 客人带着特殊的饮食要求到达时,立即调整他们的烹饪计划
  • 在准备精美的酱汁和检查烤蔬菜之间无缝切换
  • 通过重新组织整个厨房的工作流程来处理意外情况,例如停电
  • 协调多道菜肴,以便它们在恰当的时间热腾腾地新鲜送达
  • 在处理数十个不同完成状态的订单时保持食品质量

相比之下,GPU 核心就像一百个擅长重复性任务的厨师 - 他们可以在两秒钟内切一个洋葱,但他们不能有效地管理整个厨房。如果你要求 GPU 处理晚餐服务不断变化的需求,它会很吃力。

这就是为什么 CPU 对于运行计算机的操作系统至关重要。现代计算机面临着不断发生的不可预测事件:应用程序启动和停止、网络连接断开、文件被访问以及用户在屏幕上随机点击。CPU 擅长在保持系统响应能力的同时处理所有这些任务。它可以立即从帮助 Chrome 渲染网页切换到处理 Zoom 视频通话,再到处理新的 USB 设备连接 - 所有这些都同时跟踪系统资源并确保每个应用程序都获得公平的关注。

因此,虽然 GPU 擅长并行处理,但 CPU 仍然因其处理复杂逻辑和适应变化条件的独特能力而至关重要。像 Apple 的 M3 这样的现代芯片两者兼具:结合了 CPU 的灵活性和 GPU 的计算能力。

事实上,更准确的绘画视频版本会显示 CPU 管理图像下载和内存分配,然后再用 GPU 快速渲染像素。

原文

模型上下文协议简介

MCP(model context protocol)是一个开放协议,它标准化了应用程序如何为大型语言模型 (LLM) 提供上下文。
可以将MCP比作AI应用程序的USB-C端口。正如USB-C提供了一种标准化的方式来将您的设备连接到各种外围设备和配件一样,MCP提供了一种标准化的方式来将AI模型连接到不同的数据源和工具。

为什么选择MCP?

MCP帮助您在LLM之上构建代理和复杂的流程。LLM经常需要与数据和工具集成,而MCP提供:

  • 不断增长的预构建集成工具,您的LLM可以直接接入
  • 在LLM提供商和供应商之间切换的灵活性
  • 在基础设施中保护您的数据的最佳实践

架构

MCP架构

MCP的核心遵循客户端-服务端架构,其中主机应用程序可以连接到多个服务端:

  • MCP主机: 像Claude Desktop、IDE或希望通过MCP访问数据的AI工具之类的程序
  • MCP客户端: 与服务器保持1:1连接的协议客户端
  • MCP服务端: 每个服务端都通过标准化的模型上下文协议公开特定功能的轻量级程序
  • 本地数据源: 您的计算机的文件、数据库和MCP服务器可以安全访问的服务
  • 远程服务: 通过互联网(例如,通过API)提供的外部系统,MCP服务器可以连接到这些系统

需要注意的是,这里提到的服务端和传统后端服务端有些许差异,大部分实际需要运行在MCP主机或主机能访问的网络内,参考文档的章节:Using an MCP Client,单独运行MCP服务端并不是很有用,应该将其配置到MCP客户端中。

这是Claude Desktop(MCP的客户端之一)配置:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
{
"mcpServers": {
"memory": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-memory"]
},
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/files"]
},
"git": {
"command": "uvx",
"args": ["mcp-server-git", "--repository", "path/to/git/repo"]
},
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "<YOUR_TOKEN>"
}
},
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://localhost/mydb"]
}
}
}

文档

通义万相视频模型,再度迎来史诗级升级!处理复杂运动、还原真实物理规律等方面令人惊叹,甚至业界首创了汉字视频生成。现在,通义万相直接以84.70%总分击败了一众顶尖模型,登顶VBench榜首。

Sora、Veo 2接连发布之后,AI视频生成的战场又热闹了起来。

就在昨天,通义万相视频生成模型迎来了重磅升级!

他们一口气推出了两个版本:注重高效的2.1极速版、追求卓越表现的2.1专业版。

Image 4: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

刚一上线,就异常火爆,等待时间甚至一度达到了1小时

此次,全面升级的模型不仅在架构上取得创新,更是以84.70%总分登顶权威评测榜单VBench榜首。

通义万相2.1的性能一举超越了Gen-3、CausVid等全球顶尖模型。

Image 5: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

在实用性方面,通义万相2.1也得到了显著的提升,尤其是在处理复杂运动、还原真实物理规律、提升影视质感、优化指令遵循等方面。

以下都是我们实测出的Demos,就说够不够拍电影大片吧!

Image 6: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

Image 7: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

Image 8: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

更令人惊叹的是,它还在业界首次实现了中文文字视频生成,让AI视频文字创作再无门槛。

Image 9: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

以红色新年宣纸为背景,出现一滴水墨,晕染墨汁缓缓晕染开来。文字的笔画边缘模糊且自然,随着晕染的进行,水墨在纸上呈现「福」字,墨色从深到浅过渡,呈现出独特的东方韵味。背景高级简洁,杂志摄影感。

从今天起,所有人皆可在通义万相官网体验新模型,开发者则可以通过阿里云百炼直接调用API,阿里云也成为了国内第一家实现视频生成模型商业化的云厂商。

那么,通义万相2.1究竟给我们带来了哪些惊喜?

我们经过一番实测后,总结出了5大要点。

1. 首创中文文字生成

通常来说,文字生成是AI视频模型进化的一大痛点。

我们已经看到Sora、Gen-3等模型,已经能够生成很好的英文字母效果,不过截至目前,从未有一个模型能攻克汉字的生成难题。

Image 10: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

为什么之前的AI视频生成工具,都在「逃避」中文文字生成这个难题?

这是因为难点在于,中文文字的字体结构比英文更复杂,而且需要考虑笔画的层次感。在布局方面,中文字体更讲究,做成动态效果时对美感要求更高。

而阿里通义万相,便是首个中文文字视频生成的模型。从此,AI视频生成迈入「中文时代」!

这一切,只需要你动动手指,输入简单的文字提示就够了。

Image 11: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

天空中飘着云朵,云朵呈现「新年快乐」的字样,微风吹过,云朵随着风轻轻飘动。

Image 12: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

水彩透叠插画风格,两只不同颜色的可爱小猫咪手举着一条超大的鱼,从右边走到左边。它们分别穿着粉色和蓝色的小背心,眼睛圆圆的,表情呆萌。充满童趣,笔触淡雅温馨,简笔画风格。纯白背景上逐渐显示出来几个字体,写着:「摸鱼一天 快乐无边」。

一只柯基坐在桌前冥想,背后一个「静」字非常应景。

Image 13: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

一只柯基面前摆放着一只小巧的木鱼,仿佛在进行冥想仪式,背景出现字样「静」。

2. 更稳定的复杂运动生成

对于大多数AI视频模型来说,无法逃脱「体操」魔咒。有人称,这是AI视频最新的「图灵测试」。

你会经常看到,AI体操视频生成中,扭曲的肢体、不协调的动作满屏皆是。

Image 14: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

这仅是复杂肢体运动的一种,因为涉及到精细细节和高水平动作协调,成为了AI视频生成的一项重要评判标准。

生成一个人物复杂运动,对于AI来说就像是在解一道物理难题——

它不仅要做到身体各个部位精准配合,让四肢保持协调,还要考虑重力、人体运动特点、平衡感等各种细节。

在最新升级中,通义万相在多种场景下展示了惊人的「运动天赋」。

滑冰、游泳、跳水这些极易出错的名场面,万相2.1也通通Hold住,没有出现任何诡异的肢体动作,和不符合物理规律的场景。

Image 15: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

平拍一位女性花样滑冰运动员在冰场上进行表演的全景。她穿着紫色的滑冰服,脚踩白色的滑冰鞋,正在进行一个旋转动作。她的手臂张开,身体向后倾斜,展现了她的技巧和优雅。

Image 16: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

在泳池中,一名男子正在奋力向前游动。近景俯拍镜头下,他穿着黑色泳衣,戴着白色泳帽和黑色泳镜,正在水中划动双臂。他的头部部分被泳帽和泳镜遮挡,只露出嘴巴和鼻子。他的手臂在水中划动,产生了一系列的水花和气泡。随着他的动作,水面上出现了涟漪,水花四溅。背景是蓝色的泳池。

就看这个跳水动作,完全就是一个专业级选手的样子。肌肉的精准控制、溅起的水花,都非常符合自然规律。

Image 17: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

一名男子在跳台上做专业跳水动作。全景平拍镜头中,他穿着红色泳裤,身体呈倒立状态,双臂伸展,双腿并拢。镜头下移,他跳入水中,溅起水花。背景中是蓝色的泳池。

特写镜头下,女孩以手指轻触红唇,然后开怀大笑。这么近的怼脸特写,表情肌的走向和分布都十分自然,脸部纹路和嘴角笑起的弧线,也逼真似真人。

Image 18: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

特写镜头下,一位美女面容精致,她先是以手指轻触红唇,微微抿嘴,眼神中透露出一丝俏皮。紧接着,她毫无保留地开怀大笑,笑容如同绽放的花朵,美丽动人,眼角弯成了月牙状,展现出无比的快乐与感染力。

3. 更灵活的运镜控制

同一个场景下的视频,为什么专业人士拍出来就是不一样?某种程度上讲,秘诀在于「运镜」。

那么,对于AI来说,教它运镜就相当于在教机器人当导演。

它需要理解跟随拍摄节奏、快慢推进速度,还要保持协调性的问题,比如镜头移动时,主体不能丢失;运镜速度变化要自然,不能忽快忽慢。

更重要的是,AI还得有艺术感,运镜效果要符合视觉习惯,动态美感要恰到好处。

在通义万相2.1版本中,AI展现出了专业级的运镜效果。

穿着禅衣的小狐狸,在360度运镜下欢快跳舞,这不,梦幻般的效果一下子就来了。

Image 19: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

穿着禅意风服饰的可爱狐狸在林间空地上欢快地跳舞,身上的衣物随风轻扬。狐狸有着蓬松的尾巴和灵动的眼神,嘴角带着微笑,仿佛在享受自然的每一刻。背景是茂密的竹林,阳光透过竹叶洒下斑驳光影。画面采用旋转拍摄,营造出梦幻般的动感效果。整体风格清新自然,充满东方韵味。近景动态特写。

此外,新模型还能自动根据场景需求,智能调整运镜速度,完美把控了镜头的节奏。

海王在暴风雨中驾驭巨浪前行,这种级别的运镜绝对经得起考验,出现在大荧幕上也毫不违和。

Image 20: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

暴风雨中的海面,海王驾驭巨浪前行,肌肉线条,灰暗天空,戏剧性照明,动态镜头,粗犷,高清,动漫风格

实验室中女医生精心设计的特写镜头,细腻的表情刻画,以及背后灯光、实验器材等多种元素碰撞,让整个角色立即具备了丰富的层次感。

Image 21: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

富有电影感的镜头捕捉了一位身着暗黄色生化防护服的女医生,实验室惨白的荧光灯将她的身影笼罩其中。镜头缓缓推进她的面部特写,细腻的横向推移凸显出她眉宇间深深刻画的忧思与焦虑。她专注地俯身于实验台前,目不转睛地透过显微镜观察,手套包裹的双手正谨慎地微调着焦距。整个场景笼罩在压抑的色调之中,防护服呈现出令人不安的黄色,与实验室冰冷的不锈钢器械相互映衬,无声地诉说着事态的严峻和未知的威胁。景深精确控制下,镜头对准她眼中流露的恐惧,完美传达出她肩负的重大压力与责任。

下面这个镜头中,穿过一条两盘种满树木的郊区住宅街道,给人一种实时拍摄的感觉。

Image 22: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

A fast-tracking shot down an suburban residential street lined with trees. Daytime with a clear blue sky. Saturated colors, high contrast

4. 真实的物理规律模拟

AI视频模型不理解物理世界,一直以来饱受诟病。

比如,Sora不仅会生成8条腿的蚂蚁,而且眼瞧着手都要被切断了,也切不开西红柿, 而通义万相2.1切西红柿就像发生在现实生活中一样自然真实。

Image 23: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

这一次,通义万相在物理规律理解上,得到显著提升。通过对现实世界动态和细节深入认知,就能模拟出真实感十足的视频,避免「一眼假」情况的出现。

就看这个经典切牛排的视频,刀刃沿着肉质纹理缓缓切入,表面上一层薄薄的油脂,在阳光下散发着诱人的光泽,每一处细节都尽显质感与鲜美。

Image 24: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

在餐厅里,一个人正在切一块热气腾腾的牛排。在特写俯拍下,这个人右手拿着一把锋利的刀,将刀放在牛排上,然后沿着牛排中心切开。这个人手上涂着白色指甲油,背景是虚化的,有一个白色的盘子,里面放着黄色的食物,还有一张棕色的桌子。

它具备更强大的概念组合能力,能够准确理解和整合元素级的概念,使其在生成内容时更加智能。

比如,柯基+拳击,会碰撞出什么呢?

AI生成的柯基打斗的画面,真给人一种人类拳击的现场感。

Image 25: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

两只柯基狗在擂台中央进行拳击比赛。左边的狗戴着黑色拳套,右边的狗戴着红色拳套。平拍镜头下,两只狗都穿着拳击短裤,身体肌肉线条明显。它们互相挥动拳头,进行攻防转换。整个场景在固定视角下拍摄,没有明显的运镜变化。

AI大牛Karpathy最爱考验AI视频的难题,就是「水獭在飞机上用wifi」。这道题,万相2.1完美做出。

Image 26: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

5. 高级质感、多种风格、多长宽比

更值得一提的是,万相2.1能够生成「电影级」画质的视频。

同时,它还能支持各类艺术风格,比如卡通、电影色、3D风格、油画、古典等等。

不论是哥特式电影风格,还是中国古典宫廷风格,AI将其特点呈现得淋漓尽致。

Image 27: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

哥特式电影风格,亚当斯骑在一匹黑色骏马上,马蹄轻踏在古老的石板路上。她身穿黑色长裙,头戴宽边帽,眼神冷峻,嘴角微扬,透出一丝神秘。背景是阴暗的古堡和茂密的森林,天空中飘着乌云。镜头晃动,营造出一种不安与紧张的氛围。近景动态骑马场景。

这个中国古典宫廷风格的画面,镜头由群臣向前推进,聚焦在身披龙袍的皇帝身上,好像正在上映的一部古装剧。

Image 28: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

中国古典宫廷风格,古代皇宫宫殿上正在进行皇帝的登基大典。群臣身着华丽朝服,表情肃穆,排列整齐。镜头从群臣视角出发快速向前推进,锁定在身穿龙袍、头戴皇冠的皇帝身影上。皇帝面容威严,眼神坚定,缓缓步入大殿。背景是金碧辉煌的大殿,雕梁画栋,气势恢宏。画面带有浓厚的皇家氛围,近景特写与中景结合,快速推进和跟随拍摄。

养蜂人手中的蜂蜜罐在阳光中折射出温暖的光晕,背后的向日葵与乡村老宅相映成趣,构筑出一幅充满岁月与质感的画面。

Image 29: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

The camera floats gently through rows of pastel-painted wooden beehives, buzzing honeybees gliding in and out of frame. The motion settles on the refined farmer standing at the center, his pristine white beekeeping suit gleaming in the golden afternoon light. He lifts a jar of honey, tilting it slightly to catch the light. Behind him, tall sunflowers sway rhythmically in the breeze, their petals glowing in the warm sunlight. The camera tilts upward to reveal a retro farmhouse.

大文豪李白的「举头望明月,低头思故乡」,AI直接把氛围感拉满。

Image 30: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

古风画面,一位古人抬头望着月亮,缓缓低头,眼神中流露出深深的思乡之情。

对于词穷的创意者来说,通义万相「智能体扩写」功能非常友好。比如, 我想生成一个「超快放大蒲公英,展现宏观梦幻般的抽象世界」。

若想要细节更丰富的描述,直接交给AI就好了。它会自动生成一段文案,可以直接复用,也可以二次编辑修改。

Image 31: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

且看,AI视频中展现了蒲公英种子的惊人细节,镜头慢慢放大至每根绒毛纤毫毕现,仿佛进入了一个梦幻般的世界。

Image 32: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

此外,万相2.1还能支持5种不同的长宽比——1:1, 3:4, 4:3, 16:9, 9:16,恰好可以匹配电视、电脑、手机等不同终端设备。

Image 33: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

核心架构创新

那么,到底是什么让通义万相,能在激烈AI视频生成竞争中脱颖而出?

它又藏着哪些让人眼前一亮的「黑科技」?

接下来,让我们逐一分解此次2.1版本的技术创新突破点。

自研VAE与DiT双重突破

通过采用自研的高效VAE和DiT架构,阿里团队在时空上下文关系建模方面取得重大突破。

模型基于线性噪声轨迹的Flow Matching方案展开了深度设计,同时验证了Scaling Law在视频生成任务中的有效性。

Image 34: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

通义万相2.1视频生成架构图

在视频VAE层面,通过结合缓存机制和因果卷积,团队提出了一个极具创新性的视频编码解决方案。

通过将视频拆分为多个若干块(Chunk)并缓存中间特征,替代长视频的E2E编端到端解码过程。显存的使用仅与Chunk大小相关,与原始视频长度无关。

由此,这一关键技术能够支持无限长1080P视频的高效编解码,为任意时长视频训练开辟新途径。

如下图所示,展示了不同VAE模型的计算效率和视频压缩重构指标的结果。

值得一提的是,通义万相VAE在较小的模型参数规模下,取得了业内领先的视频压缩重构质量。

Image 35: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

通义万相2.1视频VAE和其他方法的结果对比

DiT架构的设计围绕两个核心目标展开:实现强大的时空建模能力,同时保持高效的训练过程。

具体创新包括:

· 时空全注意机制

为了提高时空关系建模能力,通义万相团队采用了「时空全注意机制」,让模型能够更准确地模拟现实世界的复杂动态。

· 参数共享机制

团队引入了「参数共享机制」,不仅提升了模型性能,还有效降低了训练成本。

· 优化文本嵌入

针对文本嵌入进行了性能优化,在提供更优的文本可控性的同时,还降低了计算需求。

得益于这些创新,使得新模型在相同计算成本下,凸显出收敛的优越性,并更易实现Scaling Law的验证。

超长序列训练和推理

通过结合全新通义万相模型 Workload 的特点和训练集群的硬件性能,团队制定了训练的分布式、显存优化的策略。

这一策略在保证模型迭代时间前提下,优化训练性能,在业界率先实现了100万Tokens的高效训练。

在分布式训练策略上,团队开发了创新的4D并行策略,结合了DP、FSDP、RingAttention、Ulysses混合并行,显著提升了训练性能和分布式扩展性。

Image 36: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

通义万相4D并行分布式训练策略

在显存优化上,采用了分层显存优化策略优化Activation显存,解决了显存碎片问题。

在计算优化上,使用FlashAttention3进行时空全注意力计算,并结合训练集群在不同尺寸上的计算性能,选择合适的CP策略进行切分。

同时,针对一些关键模块,去除计算冗余,使用高效Kernel实现,降低访存开销,提升了计算效率。

在文件系统优化上,结合了阿里云训练集群的高性能文件系统,采用分片Save/Load方式,提升了读写性能。

在模型训练过程中,通过错峰内存使用方案,能够解决多种OOM问题,比如由Dataloader Prefetch 、CPU Offloading 和 Save Checkpoint所引起的问题。

在训练稳定性方面,借助于阿里云训练集群的智能化调度、慢机检测,以及自愈能力,能在训练过程中实现自动识别故障节点并快速重启任务。

规模化数据构建管线与模型自动化评估机制

规模化的高质量数据是大型模型训练的基础,而有效的模型评估,则指引着大模型训练的方向。

为此,团队建立了一套完整的自动化数据构建系统。

该管线在视觉质量、运动质量等方面与人类偏好分布高度一致,能够自动构建高质量的视频数据,同时还具备多样化、分布均衡等特点。

针对模型评估,团队还开发了覆盖多维的自动化评估系统,涵盖美学评分、运动分析和指令遵循等20多个维度。

与此同时,训练出专业的打分器,以对齐人类偏好,通过评估反馈加速模型的迭代优化。

AI视频生成下一个里程碑

去年12月,OpenAI和谷歌相继放出Sora、Veo 2模型,让视频生成领域的热度再一次升温。

从创业新秀到科技巨头,都希望在这场技术革新中寻找自己的位置。

但是相较于文本的生成,制作出令人信服的AI视频,确实是一个更具挑战性的命题。

Sora正式上线那天,奥特曼曾表示,「它就像视频领域的GPT-1,现在还处于初期阶段」。

Image 37: 通义万相首创生成汉字视频,全面进化称霸VBench!AI视频GPT-3时刻来临

若要从GPT-1通往GPT-3时刻,还需要在角色一致性、物理规律理解、文本指令精准控制等方面取得技术突破。

当AI真正打破现实创作的局限,赋予创意工作者前所未有的想象,新一轮的行业变革必将随之而来。

此次,通义万相2.1取得重大突破,让我们有理由相信,AI视频的GPT-3时刻正加速到来。

参考资料:

https://tongyi.aliyun.com/wanxiang/videoCreation

文章来自于“新智元”,作者“编辑部 HYZ”。

段永平在浙大的访谈视频(2025年1月5日)全文很长,如果没兴趣,这里有一个我的总结:

  1. 做事情要从长远考虑,做你认为对的事,把这些事做对
  2. 发现错误,要及时改正
  3. 投资只投自己看得懂的,不要加杠杆
  4. 好的商业模式都是高毛利
  5. 保持健康,好好享受人生
  6. 我是一个普通人,我喜欢打球

主持人:那您面对这些挫折的时候,有没有什么解决的想法,或者心得之类的可以和我们分享吗?

段:其实还是有的,你要尽量想长远,这又说回到之前了。还有就是你不要让重要的事情变成紧急的事情,我觉得这个也很重要。我现在已经不怎么接电话了,意思是说你不要让太多的事变成紧急的事情。比方说锻炼身体,不能等到病的不行了才去看医生。记得之前有次采访时问我:危机时刻你会怎么办?我说:我开着200km/h的车,前面20米有一堵墙,肯定要撞上去了,你觉得我该怎么办?他说:能怎么办,死定了,那你怎么办?我说最重要的是你不要开那么快啊,你干嘛要去撞墙啊,你开辆好车,比如说坦克;就是说要靠长远的角度去解决问题,不能等到危机时刻才想起解决问题,危机时刻不就死了么,虽然大家都喜欢临危不惧,但临危不惧最后不还是死了嘛!所以,并没有意义。所以,安全第一,安全第一并不是说到时候再想办法,那个时候没办法,要提早做准备的。


主持人:来自计算机学院的同学问:在您的视角中信息差对于投资和选择的影响有多大?

段:炒股票对于我没有什么影响,除非你买了马上想卖,想赚点不该赚的钱。当然了也有一些靠信息差赚钱的,我没有那么喜欢这种事情。我觉得投资对我来讲不是一个零和游戏,信息差实际上是个零和游戏,你利用这个信息在别人没有这个信息之前,你赚了别人该赚的钱或者怎么样,当然也不能这么讲,但是我觉得量化投资有点那个味道。但是你不做量化,别人就会做,量化投资作为一门生意无可厚非。
但我觉得从长远看,这些都是一个小小的波澜,你太care了,你很累啊。我的球还要不要打了,生活还是要生活啊。所以要看长远,你找到好公司你就拿着,但有些人只听见了“拿着”,却忘了“好公司”,拿个错公司死的不更惨吗。 我和好多人讲,他们就是想不明白,他们说:价值投资就是长期投资。 不是的,除了价值投资请问还有别的投资方法吗?你投的就是价值,如果你不投价值,你投的是什么?所以要看长远,拿着好公司,你的生活可以愉快很多。比如巴菲特,芒格他们活得都很好,投机很有名的那些人,大部分死的都很惨,这是事实。国内也不是没有啊,作为一个有钱人,好好地跑去坐了牢了,这都是想不开的。

主持人:来自经济学院的同学问:您是否经历过投资高风险与高回报的一个关键决策时刻,以及面对这样一个高度不确定的市场,您如何平衡风险与收益呢?

段:明知高风险,还要去做,那不是脑子坏了吗…. 还真是这样的,但是呢,风投不一样,风投他们不冒风险,他是拿你的钱去投,赚到的钱有他的一份,那他当然可以做,对吧。 当然他也会有一些判别,这个A1的市场或者未来的市场有可能喜欢,他可以融到更多的钱,你是第一轮投进去,你可以赚第二轮,第三轮,第四轮的钱。风投严格来讲是一个很现代的产物,投资本身,逻辑上你是要看他的商业模式,未来现金流,确实能挣到钱,你才敢投嘛,这样你也愉快。

但风投不会像我们投资那样,他都是这里放一点,那里放一点。他其实赚的是一个股价的钱。你看风投做的很大的,比如说孙正义,扣掉前两名赚钱的公司,估计他就赚不到钱。加上了其实也没赚多少,但他是非常有名的风投。这个其实很有意思,他赚的钱和巴菲特比确实还差很多。

但是很多人做企业,企业起来以后,作为企业最早的创始人,市值很高的时候,确实性价比很高。但那是剩下来的一个人,可能同一年创业的人有1000万,大家都看到埃隆马斯克,你也跑去做电动车,中国一年电动车死多少人啊,就是这个道理。

主持人:比如在医药行业里面有很多公司要研发一个新技术,可能需要很高的研发费用,但是并不能确定一定能过临床验证。这时候就需要考虑高风险,高回报了。

段:OK,这样说,我就能理解了。我觉得做企业的时候可能会去做这种事情,作为风投做这种事情也make sense,但是,当你是大资金的时候就比较困难。不能说用你需要的钱去赌一个你不需要的钱,第一年我自己赚个10%-25%,挺好的;如果搞个500%回报,但可能会亏光光的事情,为什么要去做。所以,我一般不会去做这样的事情;但是,我觉得需要有人去做,医药是一个特别典型的行业,科技也是一样的,有很多新的想法,但是没有办法马上就有成熟的生意模式;我们这样的投资人是不应该投的,我没有那么多时间,因为我要打球啊。真是这样,很多人说:你关心下这个。我说:我不关心,等到他好起来了,我再来也可以。
我不是一个职业投资人,虽然我管的钱比绝大多数投资人可能还多,我一个人管的钱甚至可能超过一个中型的头部基金,但是呢,我并不会像他那么忙,我看见好多人天天都在忙。我说:你们都在忙什么?你看我就买了个苹果,就拿着就完了嘛。这其实剩下的时间我就可以打球了嘛,对吧,让他们忙。但是你说的话我非常同意,只是,我自己一般会避免。

主持人:也就是说这是投资的两种风格,您更倾向于高确定性风格……

段:你说的那个是高风险,但不知道有没有高回报的行业。我要是知道有高回报,我也是可以投的,这个取决于你懂不懂,就像我买的那些,大家也觉得都是高风险,我不觉得呀。所以,这取决于你有多懂,我一直说搞不懂的东西不要去碰,还有就是不要上杠杆,不要用股票去抵押一下,觉得股票要涨了就借很多钱;然后呢,股票在涨之前掉了一下,你就完了,所以不要碰这种事情,这样你就会容易很多,你还可以打球。

主持人:来自计算机学院的学生问:当下年轻人应该如何应对经济下行周期呢?

段:其实,当下老年人也面临这个问题,这和年轻人有啥关系,没关系啊。我还真不知道该怎么回答这个问题,好自为之呗。确实我们面临这个问题,对大人好一点吧,你还是可以找到好工作的,你还可以先读个研,实在不行再读个博。但是,如果你刚好看见一个好公司有机会加入,我觉得也是一个很好的选择。因为我看到经济不是那么好的情况下,好公司都还是小日子过得不错的。你说腾讯,茅台,我们公司,其实都挺好。茅台股价掉不等于他公司状况不好,其实好得很,酒还是买不到,我们有直购买他的酒,给的量都很小。


主持人:来自经济学院的同学问段学长觉得浙大有什么样的气质和氛围影响了您的创业、投资和生活呢。

段:呃,我记得我们单位曾经还有个人说一定要跟着段永平的脚步,所以要把儿子送到信电系(浙大的一个专业)。我说:那我下过哪条河摸鱼,你有没有去过。所以,其实是不知道的,成长有很多的因素,如果这个因素是成立的,那应该所有人都和我一样。 但,你说和浙大有没有关系?当然是有的,我觉得浙大毫无疑问是个好学校。但是也会出问题,对吧。

主持人:我们现在信电学院也是段学长您的母院,我们现在信电学子都有一个特别经典的四个字,叫做:勤奋乐观。我们都会说要争做勤奋乐观的信电人。这两个词也是现在我们信电学院整体的学生培养的一个特质,包括在学习上,我们要时刻保持勤奋,保持不畏难,坚持挖掘一些更多的难点;在平常的生活中,我们要保持一个乐观,积极向上的态度。这也是我们现在信电学院学生的特点。

主持人想继续读下一个同学的问题,段永平打断道: 我可以对刚才那两个词,呃,叫什么,勤奋和乐观….

主持人:是的,是的,勤奋和乐观,不知道您对我们现在信电学院的勤奋乐观两个词….

段:我觉得最重要的是要做对的事情,要把事情做对。(说的好,哈哈哈哈,不唱高调,大家就不能实事求是吗,非要整那些虚头巴脑的,这里段永平估计有点听不下去了,打段主持人的唱高调,再次强调自己的观点和理念)
段:不是,我要你勤奋,你勤奋的起来吗?我就从来不勤奋,我可是想尽办法偷懒。偷懒历史不说,那考试偷看,用chatgpt来参考写论文还是可以的。我觉得最主要的还是脑子里一定要有数,要想着做对的事情,发现错了要赶紧改。

呃,乐观,乐观是性格的问题吧。不是每个人想乐观就乐观的起来的。 这两个东西(勤奋和乐观)说完以后,大家真的会得到什么好处吗?我可以质疑一下吗?

构建有效的Agent

在过去的一年中,我们与数十个团队合作,在各个行业构建大型语言模型(LLM)Agent。一致的是,最成功的实现并没有使用复杂的框架或专门的库。相反,他们使用的是简单、可组合的模式。

在这篇文章中,我们分享了我们从与客户合作和自己构建Agent的过程中学到的东西,并为开发者提供构建有效Agent的实用建议。

什么是Agent?

“Agent”可以用几种方式来定义。一些客户将Agent定义为完全自主的系统,可以在较长的时间内独立运行,使用各种工具来完成复杂的任务。另一些人则使用这个术语来描述更具规范性的实现,它们遵循预定义的工作流程。在 Anthropic,我们将所有这些变体归类为 Agent系统,但在 工作流程Agent 之间做出了重要的架构区分:

  • 工作流程 是指通过预定义的代码路径来编排 LLM 和工具的系统。
  • Agent,另一方面,是指 LLM 动态地指导其自身过程和工具使用,保持对其如何完成任务的控制的系统。

下面,我们将详细探讨这两种类型的Agent系统。在附录 1(“实践中的Agent”)中,我们描述了客户发现使用这些类型系统具有特殊价值的两个领域。

何时(以及何时不)使用Agent

在使用 LLM 构建应用程序时,我们建议找到最简单的解决方案,并且仅在需要时增加复杂性。这可能意味着根本不构建Agent系统。Agent系统通常会牺牲延迟和成本来换取更好的任务性能,您应该考虑何时这种权衡是有意义的。

当需要更多复杂性时,工作流程为定义明确的任务提供了可预测性和一致性,而当需要灵活性和模型驱动的决策时,Agent是更好的选择。然而,对于许多应用程序,使用检索和上下文示例优化单个 LLM 调用通常就足够了。

何时以及如何使用框架

有许多框架可以使Agent系统更容易实现,包括:

  • LangChain 的 LangGraph
  • Amazon Bedrock 的 AI Agent框架
  • Rivet,一个拖放式 GUI LLM 工作流程构建器;以及
  • Vellum,另一个用于构建和测试复杂工作流程的 GUI 工具。

这些框架通过简化调用 LLM、定义和解析工具以及将调用链接在一起等标准底层任务,使入门变得容易。然而,它们通常会创建额外的抽象层,这会模糊底层提示和响应,使其更难调试。当一个更简单的设置就足够时,它们也会让人更容易增加复杂性。

我们建议开发者直接使用 LLM API 入手:许多模式可以用几行代码实现。如果您确实使用了框架,请确保您了解底层代码。对底层代码的错误假设是客户错误的常见来源。

请参阅我们的 cookbook 以获取一些示例实现。

构建模块、工作流程和Agent

在本节中,我们将探讨我们在生产中看到的Agent系统的常见模式。我们将从我们的基础构建模块——增强型 LLM 开始,并逐步增加复杂性,从简单的组合工作流程到自主Agent。

构建模块:增强型 LLM

Agent系统的基本构建模块是增强了检索、工具和记忆等增强功能的 LLM。我们目前的模型可以积极地使用这些功能——生成它们自己的搜索查询,选择合适的工具,并决定保留哪些信息。

我们建议关注实现的两个关键方面:根据您的特定用例定制这些功能,并确保它们为您的 LLM 提供一个简单、文档完善的接口。虽然有很多方法可以实现这些增强功能,但一种方法是通过我们最近发布的 MCP(model-context-protocol)/模型上下文协议,该协议允许开发者通过简单的 客户端实现 与不断增长的第三方工具生态系统集成。

The augmented LLM

在本帖的其余部分,我们将假设每个 LLM 调用都可以访问这些增强功能。

工作流程:Prompt chaining

Prompt chaining 将任务分解为一系列步骤,其中每个 LLM 调用都会处理前一个调用的输出。您可以在任何中间步骤中添加程序性检查(请参阅下图中的“门”)以确保该过程仍在轨道上。

何时使用此工作流程: 此工作流程非常适合可以将任务轻松干净地分解为固定子任务的情况。主要目标是通过使每个 LLM 调用成为更简单的任务,从而牺牲延迟来换取更高的准确性。

prompt-chaining))

提示链接有用的示例:

  • 生成营销文案,然后将其翻译成另一种语言。
  • 编写文档大纲,检查大纲是否符合某些标准,然后根据大纲编写文档。

工作流程:路由

路由对输入进行分类,并将其定向到专门的后续任务。此工作流程允许关注点分离,并构建更专业的提示。如果没有此工作流程,优化一种类型的输入可能会损害其他输入的性能。

何时使用此工作流程: 当存在最好单独处理的不同类别,并且可以通过 LLM 或更传统的分类模型/算法准确处理分类时,路由效果良好。

路由有用的示例:

  • 将不同类型的客户服务查询(一般问题、退款请求、技术支持)定向到不同的下游流程、提示和工具。
  • 将简单/常见的问题路由到较小的模型(如 Claude 3.5 Haiku),并将困难/不寻常的问题路由到功能更强大的模型(如 Claude 3.5 Sonnet),以优化成本和速度。

route

工作流程:并行化

LLM 有时可以同时处理一项任务,并通过编程方式聚合其输出。此工作流程(并行化)体现在两个关键变体中:

  • 分段: 将任务分解为并行运行的独立子任务。
  • 投票: 多次运行同一任务以获得不同的输出。

何时使用此工作流程: 当可以并行化划分的子任务以提高速度,或者当需要多个视角或尝试以获得更高置信度的结果时,并行化是有效的。对于具有多个考虑因素的复杂任务,LLM 通常在每个考虑因素由单独的 LLM 调用处理时表现更好,从而可以专注于每个特定方面。

parallelization

并行化有用的示例:

  • 分段
    • 实施护栏,其中一个模型实例处理用户查询,而另一个模型实例筛选它们是否存在不当内容或请求。这往往比让同一个 LLM 调用处理护栏和核心响应效果更好。
    • 自动化评估以评估 LLM 性能,其中每个 LLM 调用评估模型在给定提示下性能的不同方面。
  • 投票
    • 审查一段代码是否存在漏洞,其中多个不同的提示审查代码并在发现问题时标记代码。
    • 评估一段给定内容是否不适当,使用多个提示评估不同的方面或需要不同的投票阈值来平衡误报和漏报。

工作流程:协调器-工作器

在协调器-工作器工作流程中,中央 LLM 动态地分解任务,将其委托给工作器 LLM,并综合它们的结果。

何时使用此工作流程: 此工作流程非常适合无法预测所需子任务的复杂任务(例如,在编码中,需要更改的文件数量以及每个文件中更改的性质可能取决于任务)。虽然在地形上相似,但与并行化的主要区别在于其灵活性——子任务不是预定义的,而是由协调器根据特定输入确定的。

orchestrator

协调器-工作器有用的示例:

  • 每次都对多个文件进行复杂更改的编码产品。
  • 涉及从多个来源收集和分析信息以获取可能相关信息的搜索任务。

工作流程:评估器-优化器

在评估器-优化器工作流程中,一个 LLM 调用生成响应,而另一个 LLM 调用在循环中提供评估和反馈。

何时使用此工作流程: 当我们有明确的评估标准,并且迭代改进提供了可衡量的价值时,此工作流程特别有效。良好契合的两个迹象是,首先,当人类表达反馈时,LLM 响应可以明显改进;其次,LLM 可以提供此类反馈。这类似于人类作家在制作润色过的文档时可能会经历的迭代写作过程。

评估器-优化器有用的示例:

  • 文学翻译,其中可能存在翻译器 LLM 最初可能无法捕捉到的细微差别,但评估器 LLM 可以提供有用的批评。
  • 需要多轮搜索和分析以收集全面信息的复杂搜索任务,其中评估器决定是否需要进一步搜索。

Evaluator-optimizer

Agent

随着 LLM 在关键功能(理解复杂输入、进行推理和规划、可靠地使用工具以及从错误中恢复)方面日趋成熟,Agent正在生产中涌现。Agent从人类用户的命令或互动讨论开始其工作。一旦任务明确,Agent就会独立计划和操作,可能会返回给人类以获取更多信息或判断。在执行过程中,Agent必须在每个步骤(例如,工具调用结果或代码执行)中从环境中获得“真实情况”,以评估其进度。然后,Agent可以在检查点或遇到障碍时暂停以获取人工反馈。任务通常在完成时终止,但通常也包括停止条件(例如,最大迭代次数)以保持控制。

Agent可以处理复杂的任务,但它们的实现通常很简单。它们通常只是在循环中使用基于环境反馈的工具的 LLM。因此,至关重要的是要清晰且周到地设计工具集及其文档。我们在附录 2(“提示工程您的工具”)中扩展了工具开发的最佳实践。

agent

何时使用Agent: Agent可用于开放式问题,在这些问题中,很难或不可能预测所需的步骤数量,并且您无法硬编码固定路径。LLM 可能会运行多个回合,并且您必须对其决策制定有一定的信任度。Agent的自主性使其非常适合在可信环境中扩展任务。

Agent的自主性意味着更高的成本和潜在的复合错误。我们建议在沙盒环境中进行广泛的测试,并采取适当的防护措施。

Agent有用的示例:

以下示例来自我们自己的实现:

agent usage

组合和自定义这些模式

这些构建模块不是规定性的。它们是开发者可以塑造和组合以适应不同用例的常见模式。与任何 LLM 功能一样,成功的关键在于衡量性能并迭代实现。重申一遍:您应该只在结果明显改善的情况下考虑增加复杂性。

总结

在 LLM 领域的成功并不在于构建最复杂的系统。而在于构建适合您需求的 正确 系统。从简单的提示开始,通过全面的评估对其进行优化,并且仅在较简单的解决方案不足时才添加多步骤Agent系统。

在实施Agent时,我们尝试遵循三个核心原则:

  1. 在Agent的设计中保持 简洁
  2. 通过明确显示Agent的规划步骤来优先考虑 透明度
  3. 通过全面的工具 文档和测试 来精心设计您的Agent-计算机接口 (ACI)。

框架可以帮助您快速入门,但在您转向生产时,请毫不犹豫地减少抽象层并使用基本组件进行构建。通过遵循这些原则,您可以创建不仅功能强大,而且可靠、可维护并受到用户信任的Agent。

致谢

由 Erik Schluntz 和 Barry Zhang 撰写。这项工作借鉴了我们在 Anthropic 构建Agent的经验以及我们客户分享的宝贵见解,对此我们深表感谢。

附录 1:实践中的Agent

我们与客户的合作揭示了 AI Agent的两个特别有希望的应用,它们展示了上述讨论的模式的实际价值。这两个应用程序都说明了Agent如何为既需要对话又需要操作、具有明确的成功标准、启用反馈循环以及集成有意义的人工监督的任务增加最大价值。

A. 客户支持

客户支持将熟悉的聊天机器人界面与通过工具集成增强的功能相结合。这非常适合更开放的Agent,因为:

  • 支持交互自然地遵循对话流程,同时需要访问外部信息和操作;
  • 可以集成工具来提取客户数据、订单历史记录和知识库文章;
  • 可以以编程方式处理诸如发出退款或更新工单之类的操作;并且
  • 可以通过用户定义的解决方案清楚地衡量成功。

一些公司已经通过仅针对成功解决方案收费的基于使用情况的定价模型证明了这种方法的可行性,这表明了他们对Agent有效性的信心。

B. 编码Agent

软件开发领域展示了 LLM 功能的巨大潜力,其功能从代码完成发展到自主解决问题。Agent特别有效,因为:

  • 可以通过自动化测试验证代码解决方案;
  • Agent可以使用测试结果作为反馈来迭代解决方案;
  • 问题空间定义明确且结构化;并且
  • 可以客观地衡量输出质量。

在我们自己的实现中,Agent现在可以仅根据拉取请求描述来解决 SWE-bench Verified 基准中的实际 GitHub 问题。然而,虽然自动化测试有助于验证功能,但人工审查对于确保解决方案符合更广泛的系统要求仍然至关重要。

附录 2:提示工程您的工具

无论您构建哪种Agent系统,工具都可能是您Agent的重要组成部分。工具 使 Claude 能够通过在我们 API 中指定其确切的结构和定义来与外部服务和 API 交互。当 Claude 响应时,如果它计划调用工具,它将在 API 响应中包含一个 工具使用块。工具定义和规范应与您的整体提示一样受到提示工程的关注。在本简短的附录中,我们将描述如何提示工程您的工具。

通常有几种方法可以指定相同的操作。例如,您可以通过编写差异或通过重写整个文件来指定文件编辑。对于结构化输出,您可以在 Markdown 或 JSON 中返回代码。在软件工程中,这些差异是表面上的,并且可以从一种格式无损地转换为另一种格式。但是,某些格式对于 LLM 而言比其他格式更难编写。编写差异需要知道在编写新代码之前块头中有多少行正在更改。在 JSON(与 Markdown 相比)中编写代码需要额外转义换行符和引号。

我们关于决定工具格式的建议如下:

  • 在模型将自己写入死角之前,给模型足够的令牌来“思考”。
  • 使格式接近模型在互联网上的文本中自然出现的形式。
  • 确保没有格式“开销”,例如必须准确计算数千行代码,或对它编写的任何代码进行字符串转义。

一个经验法则是考虑人机界面 (HCI) 需要付出多少努力,并计划投入同样多的精力来创建良好的 Agent 计算机接口 (ACI)。以下是一些关于如何做到这一点的想法:

  • 将自己置于模型的角度。根据描述和参数,使用此工具是否显而易见,还是需要仔细考虑?如果是这样,那么对于模型来说可能也是如此。一个好的工具定义通常包括示例用法、边缘情况、输入格式要求以及与其他工具的明确界限。
  • 如何更改参数名称或描述以使事情更明显?将其视为为团队中的初级开发人员编写出色的文档字符串。当使用许多类似的工具时,这一点尤其重要。
  • 测试模型如何使用您的工具:在我们的 工作台 中运行许多示例输入,以查看模型会犯什么错误,并进行迭代。
  • Poka-yoke 您的工具。更改参数,使其更难犯错。

在为 SWE-bench 构建我们的Agent时,我们实际上花费了更多的时间来优化我们的工具,而不是整体提示。例如,我们发现模型在使用相对文件路径的工具在Agent移出根目录后会犯错。为了解决这个问题,我们更改了工具以始终需要绝对文件路径——我们发现模型完美地使用了此方法。

原文

模型上下文协议 (MCP/model context protocol) 是一种开放标准,用于将 AI 助手连接到数据所在的系统,包括内容存储库、业务工具和开发环境。其目的是帮助前沿模型产生更好、更相关的响应。

模型上下文协议 (MCP),这是一种将 AI 助手连接到数据所在系统的新标准,包括内容存储库、业务工具和开发环境。其目的是帮助前沿模型产生更好、更相关的响应。

随着 AI 助手被主流采用,该行业在模型能力方面投入了大量资金,在推理和质量方面取得了快速进展。然而,即使是最复杂的模型也受到其与数据隔离的限制——被困在信息孤岛和遗留系统之后。每个新的数据源都需要其自己的自定义实现,使得真正连接的系统难以扩展。

MCP 解决了这一挑战。它为将 AI 系统与数据源连接提供了一个通用的开放标准,用单个协议取代了碎片化的集成。结果是一种更简单、更可靠的方式,让 AI 系统访问它们所需的数据。

模型上下文协议

模型上下文协议是一种开放标准,使开发人员能够在他们的数据源和 AI 驱动的工具之间建立安全的双向连接。架构很简单:开发人员可以通过 MCP 服务器公开他们的数据,或者构建连接到这些服务器的 AI 应用程序(MCP 客户端)。

今天,我们为开发人员介绍了模型上下文协议的三个主要组成部分:

Claude 3.5 Sonnet 擅长快速构建 MCP 服务器实现,使组织和个人可以轻松地将其最重要的数据集与一系列 AI 驱动的工具快速连接起来。为了帮助开发人员开始探索,我们正在共享用于流行的企业系统(如 Google Drive、Slack、GitHub、Git、Postgres 和 Puppeteer)的预构建 MCP 服务器。

Block 和 Apollo 等早期采用者已将 MCP 集成到其系统中,而包括 Zed、Replit、Codeium 和 Sourcegraph 在内的开发工具公司正在与 MCP 合作,以增强其平台——使 AI 代理能够更好地检索相关信息,以进一步了解编码任务的上下文,并以更少的尝试生成更细致和功能性的代码。

“在 Block,开源不仅仅是一种开发模式,它还是我们工作的基础,以及致力于创造推动有意义的变革并作为所有人公共利益的技术的承诺,”Block 首席技术官 Dhanji R. Prasanna 说。“诸如模型上下文协议之类的开放技术是将 AI 与现实世界应用连接起来的桥梁,确保创新是可访问的、透明的,并且植根于协作。我们很高兴能合作开发一个协议并使用它来构建代理系统,从而消除机械负担,使人们可以专注于创造性。”

开发人员现在可以针对标准协议进行构建,而不是为每个数据源维护单独的连接器。随着生态系统的成熟,AI 系统将在不同的工具和数据集之间移动时保持上下文,从而用更可持续的架构取代当今的碎片化集成。

入门

开发人员可以立即开始构建和测试 MCP 连接器。Claude.ai支持将 MCP 服务器连接到 Claude 桌面应用程序。

Claude for Work 客户可以开始在本地测试 MCP 服务器,将 Claude 连接到内部系统和数据集。我们很快将提供用于部署远程生产 MCP 服务器的开发人员工具包,这些服务器可以为您的整个 Claude for Work 组织提供服务。

从以下步骤开始:

一个开放的社区

我们致力于将 MCP 构建为一个协作的开源项目和生态系统,我们渴望听到您的反馈。无论您是 AI 工具开发人员、希望利用现有数据的企业,还是探索前沿的早期采用者,我们都邀请您一起构建具有上下文感知能力的 AI 的未来。

题外话

目前还处于开发期,主要支持的MCP客户端都与编程相关,主要是代码编辑器或插件,如:

  • Continue(vscode 插件),开源 AI 代码助手,支持所有 MCP 功能
  • Zed (高性能代码编辑器,内置 MCP 支持,专注于 prompt 模板和 tool 集成)
  • Cody,Sourcegraph 的 AI 编码助手,通过 OpenCTX 实现 MCP
  • Cline(vscode 插件),一个自动化编码代理,能够编辑文件、运行命令、使用浏览器等

原文

什么是 Claude Artifacts?

Anthropic 发布了 Claude 3.5 Sonnet,这是一个突破性的 AI 模型,在大多数测试中都超过了 OpenAI 的 GPT-4o。除了新的模型之外,Claude 还引入了几项创新功能,包括项目和年度杰出的 AI 创新——Artifacts。

Claude Artifacts 是由 Anthropic 创建的高级 AI 模型 Claude 3 生成的输出。这些输出可以包括文本、图像、数据可视化,以及更复杂的输出,如交互式内容和自动报告。它们在各个行业都非常有价值,从市场营销和内容创作到数据分析。这些输出可能包括:

  • 代码片段或脚本
  • Markdown 文档
  • HTML 页面
  • SVG 图像
  • Mermaid 图表
  • React 组件

它们显示在一个独立于主聊天窗口的专用窗口中,使用户可以轻松地修改、构建、共享或混合它们。

如何使用 Artifacts?

Claude 创建的 Artifact 会出现在主聊天窗口旁边的一个专用侧窗口中。这使得用户可以轻松访问、查看、复制和操作 Artifact 的内容。

以下是使用 Artifacts 的方法:

  • 请求 Claude 对内容进行更改或改进,并在侧窗口中查看这些更新。
  • 更改不会影响 Claude 的原始内容记忆,您可以使用 Artifact 左下角的选择器查看不同版本。
  • 通过单击右上角的滑块图标可以一次打开和查看多个 Artifact,然后选择要 Claude 引用的 Artifact,并继续讨论。
  • Claude 会根据您的消息更新 Artifact,侧窗口会反映最新的内容。
  • 访问 Artifact 的代码,将内容复制到剪贴板,或下载以供以后使用。这些功能位于 Artifact 的右下角。

如何分享 Claude Artifacts?

当 Claude 创建一个 Artifact 时,它会显示在主聊天窗口右侧的专用窗口中。您可以通过以下方式分享 Artifact:

  • 导航到屏幕右侧的 Artifacts 部分中的 Artifact。
  • 找到与该特定 Artifact 版本关联的“发布”按钮。
  • 单击“发布”以将此版本的 Artifact 公开。
  • 复制提供的链接以与他人分享,以便他们查看和混合。

如何混合 Claude Artifacts?

混合功能允许用户迭代和改进任何用户创建的任何 Artifact。要混合 Artifact,请执行以下操作:

  • 查看已发布的 Artifact,然后单击“混合此 Artifact”按钮。
  • 这将使用 Artifact 的内容启动一个新的 Claude 对话。
  • 根据需要与 Artifact 交互并进行修改。

创意应用示例(提示)

  • 健身追踪器: 创建一个交互式应用程序来跟踪锻炼和健身数据。
  • 食谱轮盘应用程序: 生成一个应用程序,随机选择食谱供用户尝试。
  • 呼吸练习: 开发一个交互式工具来指导用户进行呼吸练习。
  • 禅意花园模拟器: 设计一个模拟器,允许用户创建自己的数字禅意花园。
  • 语言抽认卡: 制作抽认卡以帮助用户学习新语言。

原文

LLM

开源部署

云服务商

工具

AI Agent

  • dify.ai云平台
    • 可视化AI应用构建
    • 支持多种LLM模型接入
    • 工作流自动化
    • 提供免费套餐

AI助手

  • ChatGPT
    • GPT-3.5免费使用
    • GPT-4需订阅Plus
  • Claude
    • 支持更长上下文
    • 提供免费额度
  • Google Gemini
    • 提供免费使用额度
    • 支持多模态输入

更多

  • AI导航 - 收录更多AI工具和资源

使用建议

  1. 善用免费额度,合理分配使用场景
  2. 针对不同需求选择合适的模型
  3. 注意API调用频率限制
  4. 关注服务条款和数据安全

各种工具

我构建的各种 HTML+JavaScript 工具,几乎所有工具都是在大语言模型的帮助下完成的。

这个集合部分是一个实验,旨在探索在风险极低的项目中,仅通过提示就能完成多少工作。我使用的提示链接自每个工具的提交信息。它们中的大多数都使用了此处描述的自定义指令版本。

我本周用 Claude Artifacts 构建的所有内容描述了我是如何构建其中的许多工具的。

LLM 游乐场和调试器

其他

在 Observable 上

Observable 上: